Magnus Pettersson

I can second this memory problem with mantra (which is a big problem, were constantly fighting this issue).

Were doing heavy fluid sims right now for a feature production and when having highres fluid meshes of 100+ mil polys there is no way to render on a 24GB farm node, even 48GB blades is having trouble sometimes when having a single big bgeo. We have tested same geo in Renderman and it just eats millions of polys for breakfast while mantra eats the ram instead hehe.

Absolutely amazing with this kind of speed! Keep up the good work, i will definitely keep an eye on this thread

Hey there. Yes in a VOP POP node the “P” is the particles position.
If you want the particles to always be born and stay at (0,3,0) you dont need to worry about the global “P”.. you can just put a constant vector node (or a parameter node set to vector, if u want to change it in pop context on the vop node) and plug the output of that node into “P” on the output node.. then your particles will always have the position P.

If thats the only thing u want to do then you can use the position pop too and just write in 0,3,0 instead of $TX,$TY,$TZ … And you could even have a group to only put particles there based on life, or if they just been born and so on.

Correct the “v” parameter is the velocity.. you can use the global “v” which is the current velocity of the particle, and do some operations on it (lets say add it with another vector) and then plug the sum to “v” in output