My first post to this forum and I am diving right away into the fun stuff
I have written my own particle mesher for blobmeshes some time ago. Since we now have Krakatoa in our pipeline we have changed our workflow for fluids. We use the PRT loader for loading simulations now. I am trying to hook the PRT Loader into my mesher object.
The first surprising thing is:
tos.obj->IsParticleSystem() returns false for the PRTLoader (tos is the node I have picked)
Which means I can’t cast it to a particle object.
tos.obj->IsSubClassOf(triObjectClassID) also returns false.
So I can not cast it to a triObject either to get vertex positions.
At least
tos.obj->SuperClassID()==GEOMOBJECT_CLASS_ID
leads to a true, but doesn’t help too much for getting anything useful out of it.
Should I use the maxscript interface from c++?
Is there some kind of header file for the interface?
Or is there another way ?
perhaps a header and lib file I can simply add?
Your findings are correct.
We decided to make the PRT Loader a GeometryClass object, but it is not a Particle System and it is not a Mesh.
It does abuse some of the mesh channels internally to pass data to modifiers up the stack, but it does not do this the normal way (create a mesh and let it go), it calls the modifiers in the right order and passes small meshes through them and gets the results back into its particle channels. So there is no real mesh existing in memory (which would be bad given we are trying to squeeze as many millions of particles into memory without Max getting in the way).
So at this point, it is not a surprise you cannot get any usable data in a form Max would support.
What we could do:
Expose an interface to get a mesh with vertices and some mapping / color channels.
Start shipping our own Particle Mesher which was built around the same data channels as the PRT Loader and is damn fast on top of that (but I understand if you want to use your own code since it gives you more control over the final output).
For your specific needs, the first approach might be the optimal one.
For general audience, the second approach would be more flexible since it would allow the reading, modifying and writing back new versions of existing PRTs as a side effect.
I would also prefer option 2. This would allow me to access the other channels in the future, too. For now I am only interested in position and velocity. If you are using the standard FPInterface for exposing to maxscript, I should be able to access it from c++ as well, if you provide the header file.
Whom do I send the official feature request for this ?
Another good idea! I can directly raytrace with VRay which is nice in some situations, especially with large particle counts.
Btw Jerry from the Chaosgroup forum is currently writing his own implementation for this and plans to release it for free. chaosgroup.com/forums/vbulle … hp?t=44754
