Hi.
I have a particle system that use Instance Shape for the particles, and i want to generate a Frost mesh that make use of the texture that the original particles have.
Can i do that?
When i generate the geometry, mental ray says that my frost mesh does not have any mapping.
Cheers.
Which Frost meshing mode are you using? (For example: Geometry, Metaballs, etc.)
I tried with anisotropic and zhu/Bridson.
Cheers.
Unfortunately I don’t think Frost can do what you want directly. In Zhu/Bridson and Anisotropic modes, Frost gets a single Mapping coordinate per particle, and it doesn’t look at the instance geometry at all.
I think it may be possible to do what you want by using Frost, Genome, and a Mesher compound object. I’ll try it and let you know here.
I think this might do what you want. Please let me know if you’re trying to accomplish something else. It requires Genome. Please contact our Sales Department if you’d like to request a Genome trial.
If anyone knows a better way to do this, I’d love to hear about it!
Here’s a rendering of the result. The original Shape Instanced Geosphere is on the left, and the output Frost mesh is on the right:
TextureCoord_from_nearest_Instance_Shape.zip (26.8 KB)
Thanks Paul, i’ll ask Radka about a trial for Genome too, but i don’t think i can acquire Genome too right now (i’m acquiring frost and Krakatoa MX, and probably xmesh too, soo it’s a big investment for me right now 
)
But anyways, should it work with other type of meshing system like metaballs? it can be fine because i have to mix it with another particles in this is going to be something to fill some gaps behind another particles, so it could work even with a simpler meshing system.
Cheers and thanks!
For sure, I understand. There may be some way to do the same thing without Genome, but nothing is coming to mind for me.
Yes, it should work for any meshing mode that creates a mesh: Metaballs, Union of Spheres, Zhu/Bridson, Anisotropic, and Geometry.
What i meant if that acquiring UV’s from particles should be working on other meshing systems like Metaballs or Union of Spheres without using Genome, i assume that using Genome it should work with any meshing mode 
Other thing, if i render over the network with Frost, should i be worried about problems with meshing in other computers different frames of the same animation? it’s mandatory to use Xmesh?
And this is abit off topic from this thread, but i’ll take leverage that i’m here and you are here hehe, can Xmesh cache a particle system as a cache? it’s mandatory to use frost if i want to do that? and will xmesh reduce the geometry memory footprint if i cache the particle system?
This is all for rendering with iRay, so memory is pretty important.
Thanks for your time Paul.
Cheers.
The results of Frost should be identical on all network machines.
Also, since Frost does not use a license when rendering on a network machine, it should be ok to render directly without XMesh. But when submitting the scene to the network for rendering, the Frost object must be saved with a valid license in order for the scene to generate a mesh on the network machines. So if you have a limited number of Frost licenses in a large company, XMeshing can be a good practice so all artists can see and render the Frost mesh in their scenes. Note that XMesh Loader does not require a license at all.
Using XMesh is also a good idea if you are playing back a Frost animation interactively, or if the meshing time is relatively long and you have to rerender the same animation multiple times. 10 million particles usually take around 30 seconds to mesh in most modes, so saving an XMesh and loading it on the network can save some time in that case.
Yes. It works with anything producing geometry, with very few exceptions (for example Max Hair&Fur as Geometry is currently not supported).
XMesh works with both PFlow and TP.
The TriMesh loaded by XMesh will be IDENTICAL to the mesh generated by the particle system at render time. The main difference is that the particle system itself will be off (or even deleted from the scene), so the overall memory footprint of the scene would be reduced (depending on the complexity of the particle system, of course).
Unfortunately not. It won’t acquire UVs from Instance Geometry particle meshes in any meshing mode.
Basically the way Particle Flow works is that it has per-particle channels for any relevant data. For example Position, Velocity, Orientation, Spin etc.
Each particle can have a MtlIndex (similar to the per-face Material ID in geometry faces) determining which sub-material should be applied to it.
Each particle can also have a TextureCoord (mapping channel 1), Vertex Color (mapping channel 0) and Mapping2 to Mapping99 channel (the other mapping channels) that 3ds Max geometry can have, but just in the form of a Point3 value without any mapping faces. And then each particle can have a Shape channel which contains an instance of a TriMesh - the geometry associated with that particle.
This TriMesh itself can have its own per-face Material IDs, Texture Coordinates (0 to 99) etc. which are independent from the per-particle data.
When a mesh renderer like Scanline, mental ray or VRay asks PFlow for the geometry to render, PFlow assembles one or more TriMeshes by combining the Shape channel’s TriMeshes of all particles found in the renderable events. In this process, the data acquired by the ShapeInstance operators is taken more or less As Is and attached to a large renderable mesh.
On the other hand, both Krakatoa and Frost don’t care about the Shape channel at all. All they acquire is the particle channels including the per-particle positions, velocities, mapping coordinates, colors etc., but completely ignore the TriMeshes stored in the Shape channel.
What Paul proposed here is to use the Mesher to turn the PFlow’s Shape channel into a TriMesh. When Frost sees a TriMesh (as opposed to a PFlow system), it takes the data from its vertices instead. Unfortunately, it does NOT take the mapping data from the TriMesh, mostly because each vertex can have many corresponding mapping values, up to one per face using that vertex. The workaround via Genome steals the mapping value of the closest point on the Mesher into the Frost, thus providing a more or less valid mapping value to each vertex. Of course, with Blobby meshes, the result can be a bit messy…
Hope this helps.
EDITED
Sorry Bobo, i didn’t saw your answer, then, there is no clean wayto generate mapping for a genated mesh for a liquid or something like that, right?
I’ll try the genome solution when a 2013 trial version is released, but i guess it won’t be enough
Cheers,
