TexmapEval vs InputTexmap?

InputTexmap does some extra stuff that I wish it didn’t. For example, it automatically grabs the particle’s Position, Normals, UVWs, etc. unless you explicitly override them. TexmapEval doesn’t make any assumptions about what you are operating on, it just has regular input sockets for the things the Texmap needs.

My proposed solution is to add TexmapEval to Krakatoa, and slowly phase out InputTexmap (or alternatively we just leave them both in Krakatoa).

ToCamera is another “Krakatoa only” node because as a renderer, Krakatoa has a pretty well defined idea about what the camera is. In Genome, which operates in the modifier stack, there is no particular aspect of 3ds Max that indicates what the camera is. There is some view information in the GeomObject::GetRenderMesh() call, but that information is only available to the base object and isn’t present while evaluating the modifier stack. We couldn’t figure out a good way to automatically pick a camera, so we figured you could just use a (To/From)Space node with a camera picked to achieve the same effect.

Yes. The original design was to automatically connect particle channels directly to their corresponding Texmap inputs (ie. Position, Normal, UVWs, MtlID, etc.) and was modified to accept explicit values at a later time so that you could do stuff like finite differences or evaluating a texmap after an IntersectRay. The legacy behavior was kept around, but it doesn’t make sense when one isn’t working on particles. In Genome for example, a Vertex doesn’t have UVWs or a Normal to automatically connect, and a TVert doesn’t have a position, etc.