I am having trouble sometimes know where I enable different channels, whether they are mapping channels, or texture coords (UVs), or colros, etc.
I have a PRTLoader loading a .bin sequence from RealFlow. This has texture coordinates. These come in and get transferred to my Frost (which uses the loader as the input) automagically.
I then have a PRTVolume which takes the Frost as its source. This is getting its Texture Coords (or Map Channel 1… are these the same in Max?) automagically from the Frost input.
Now I have that PRTVolume as the distribution source for a Stoke object. But I can’t figure out how to get the texture coords onto the Stoke object for surfacing. I tried adding a Magma to the Stoke object that has input of texture coords and output of texture coords. This did not seem to do anything, even if I re-simulate. When I try to render I get an error that there is no channel texture coords…
Note that I do not see TextureCoords in the list of channels in Stoke, like I did when I use the PRTLoader as the source.
So, how can I get the texture coords from my PRTVolume onto my Stoke particles?
NOTE: I am not using the Frost directly as a distribution source in Stoke because I am getting hangs when I do that. I will send you the scene and bin sequence…
First, a quick word about UV coordinates.
3D Studio MAX 1.0 in 1996 had only one UV channel for texture mapping.
3D Studio MAX 2.0 in 1997 added a second channel for Vertex Colors.
3D Studio MAX 3.0 in 1999 added 98 additional channels to round them up to 100.
To keep the new system compatible with the old versions, the channels are now
Mapping Channel 0: Vertex Color (new Max 2.0 channel)
Mapping Channel 1: Texture Coordinates (original Max 1.0 channel)
Mapping Channel 2 to 99 : New Max 3.0+ channels.
To reflect this and to stay close to the MAX UI paradigm where Vertex Color channel is often exposed as a separate radio button option and NOT channel 0 for backward compatibility/historical reasons, our tools (Magma etc.) use the same names - Color, TextureCoord and Mapping2 to Mapping99.
When PRT Volume is filling a mesh volume with particles, it is supposed to find all channels available in the mesh, and create the same channels, acquiring data from the closest point on a surface.
For example:
*Create a Teapot (it has TextureCoord channel by default)
*Create a PRT Volume from it. Add a Magma modifier and set it to TextureCoord–>Color to visualize the mapping.
*Create a Frost object from the PRT Volume - it will have the TextureCoord of the Teapot passed via the PRT Volume.
*Create a second PRT Volume from the Frost, add the same Magma modifier with TextureCoord–>Color - you will get almost the SAME colors as in the first PRT Volume, but of course translated from the Teapot to the PRT Volume to the Frost to the second PRT Volume.
It works for me here, it should work for you there.
If I pick that second PRT Volume as source of Stoke, I can see the following channels:
*Normal - this is the normal of the Frost mesh as acquired by the second PRT Volume
*SignedDistanceGradient - this is a vector pointing in the direction of increasing SignedDistance value (see below)
*Color - this is the Color of the PRT Volume as generated by the Magma modifier from the TextureCoord channel
*TextureCoord - this is the actual Mapping channel 1 coming from the Teapot via PRT Volume, Frost and another PRT Volume.
*SignedDistance - this is the distance of the PRT Volume particle to the surface of the Frost mesh that generated it. Negative values denote the particle is inside a volume.
*Density - this is the Density value of the PRT Volume.
Can you repeat this experiment and see whether you get the TextureCoord channel passed around? Note that the BIN file does NOT contain the same channels, we are converting some channels internally from the BIN specification to ours, so a “uvw” channel in the BIN becomes a “TextureCoord” channel in Magma/Stoke/Krakatoa etc. Not all BIN sequences have valid mapping coordinates. But if you can see the mapping on the Frost mesh, but a PRT Volume made from the Frost mesh does not show a TextureCoord channel in Stoke, then it would be unexpected…