Proxies and Particles

[dellis]

I mentioned this technique before in a thread about different methods for distributing trees. Its cool cause PFlow allows you a bunch of different ways to emit particles....my favourite is to paint up a black and white distribution map.

[joconnell]

Yeah it's a great way to deal with any kind of randomness - scatter hasn't really been updated in any way in comparison with pflows abilities to randomly assign materials, ids and positions / scales - great stuff entirly.

[Dynedain]

If you don't need to animate the distribution of the trees, scatter would give you quicker results.

[Da_elf]

im confused. this script dellis mentioned doesnt work to use vray proxies with pflow?

[joconnell]

Not directly - it will allow you to transfer the position, rotation and scale keys from a particle flow to objects in your scene as if your scene objects are being tracked onto particles within the pflow. the script is not giving pflow the ability to use lazy loading and deal with massive numbers of high poly instanced objects. It's as if you were to use the align tool on a vray proxy object and align it's position, rotation and scale to a specific particle within a pflow for each frame and repeat the same process for a load of other scene objects.

You can use the script to transfer pflow transforms to any scene object at all so it's not doing anything clever to make vray proxy objects suddenly compatible with pflow. The end result of having vray proxies animate like particles is the same though. One disadvantage is that there is no way to kill off a scene object after a lifespan in the same way that you can with a particle so in this case the script is placing the scene object really far below camera which will cause a huge motion blur at the frame where it's moved. you could edit it to use visibility frames instead though.

[RErender]

you could have an object check where it is in space and if out of a certain threshold, poof!

[panthon]

The problem with this script in PF method is that it makes u create a huge amount of dummy objects (in our case, we need 80000) and this will slowdown performance in max. Basically u need to create the exact number of dummys u will be using to control the vrayproxies.

80000 dummies = 80000 vrayproxies.

Even if u use point dummys, viewports freeze and 3dsmax is likely to crash.

The render goes without a hassle, because vrayproxies don't take much memory as u know, but moving around the scene is a pain.

[joconnell]

Yup - maybe best off making a few different pflow sources so you don't have the same load all at one stage.

[studioDIM]

There is a specific max object that takes care of baking the PFlow system (or specific event of) into a mesh.

Under compound objects, pick the Mesher.
Align it with your PFLOW emitter/icon (even if emitting particles from objects: this is important.), then under the mesher properties, pick the pflow icon (for which you have set the display of particles to NONE, to save on resources).
It will create a proper mesh of your PFlow system.
If you set the viewport to bounding box visualisation, you might even save more resources in case the polycount is extremely high.
Then is just a case of exporting the mesher object to a vray mesh.

Of course, make sure you split your pflow system into as many events as you find suitable (say, split the trees generation in four or five events, and mesh each one separately).

With this technique i managed to export to vraymeshes some 200k 3d pebbles, 50k pine needles, and 10k 3d leaves, as static objecs.
The mesher, though, supports animations, as well, or so it seems.
You'd have to write a script to load a different vraymesh per frame on the proxy, though.


re,
Lele

[studioDIM]

I prepared a set of three tiny scripts that apply particle transforms to vray proxies.

EDIT: they can be found here

The first "Tags" the source proxy (say, the mother tree) with a custom property.

The second, a script operator that goes within the PF tree checks the scene for two things:
A) if a vrayproxy object with a custom tag is present
B) if there are enough instances of that object to use one per emitted particle (it dumbly checks for the default birth operator name: $Birth01, or whatever the name is, for the moment. so go in and change it if you need something else)

In case A is false (no vray proxy in the scene with a custom tag) it creates a proxy and pops a file requester dialog to choose the associated vray mesh.
In case B is false, it will take whatever the result of A (either a tagged proxy made by hand, or a custom, new proxy) and instances it as many times as there are particles (total number of emitted, not particles present at the current frame)

The thrid script goes in the PF per-step update
This is the one responsible for the transfer of the transform matrix from the particles to the vray proxies.

I couldn't check moblur, as i am stuck with 1.47.03, but given the premises (TM updated at each RENDER integration step), it should work nicely.

Bear in mind that at the moment proxies will NOT change their mesh on a per frame/per interation step basis.

It will still plant all the trees you want...

Have fun,

Lele

[panthon]

Thanks for your tips and your scripts, Lele!

[jacksc02]

your a legend lele!

[panthon]

your a legend lele!

How many legends around, jacksc!

[studioDIM]

lmao, too kind chris!
Legendary neer-do-well, that i am

I'm going to try the script myself soon btw, i wonder how it will cope with a few hundred thousand blades of grass...

Lele