ANY way to render 360000 particles with a 5k tris mesh per particle?

Hi,
I’m not sure if this is Autodesk related issue or vray but PFlow is apparently nieither instancing particles nor does it support VRayProxies. I need to render 360000 particles (Which isnt much for todays strandards I think) with a 5k poly mesh each. I could propably reduce the mesh size more but nonetheless I just cant get it to work due to memory allocation failures. My current workaround would be to scatter tris as particles, mesh them, then use Multiscatter with the scattered tris as distribution object. It works generally, but I need to have one particle only per tri, I want to get the exact same result as if I would have scattered the meshes via PFlow itself and not via Multiscatter. Is there a way to do this?

I am not sure if this could help you: http://jokermartini.com/reducing-pflow-render-times/

There was a script somewhere that could place instances of a given object at the location of each PFlow particle - perhaps it could do the job?

Best regards,
Vlado

Hi, thanks for the link, I actually was on that exact site already. It is not really the preparing step which takes ages, I can’t get it to actually render since I get memory allocation failures. :frowning:

Hmmm, I’ll have a look into it. But having 360000 instances in the viewport would slow it down incedibly or I guess the “Updating Instances” step would take ages. I somewhere saw something you or one of your colleagues posted about the possibility of having VRay instance the particles in a future 3.0 service pack?

Yes, however it is not ready for use yet - will be in a month or two.

Best regards,
Vlado

This would be so awesome. It’s really a pain to render particles with max/VRay. On another note - I don’t know if this is at all possible: Maybe VRay could, at render time, “interpolate” particles? As in nearest-neighbour-lookup then adding a particle inbetween, or something like that. Having to calculate less particles in max, and let VRay do the rest.

Might be worth looking into the prt, krakatoa and frost workflow for this? It does a tonne of uprezzing of particle systems and allows you an easy way to swap a particle to a custom mesh with lots of variation options…

Hi,
I know particle renderers are capable of this. A simplified version of that for VRay (really simplified, really only maybe uprezzing) shouldn’t be that hard to code, right? It would instantly make VRay more appealing for particle rendering I think. I dont want to buy new software for this project which we dont get too often.

On the contrary, it is quite non-trivial to code this (in a good way, at any rate).

Best regards,
Vlado

This kind of more comes under the category of particle manipulation rather than being a renderer’s task. You’re right though about buying software for bits you don’t do too often - if you’re only ever going to do this once then you could either muddle through with the various scripts and workarounds which will be a bit painful or you could look into renting a few thinkbox licenses for the duration of the job. In terms of the uprezzing, you’re thankfully only looking at changing the birth and position seed of your particle system and baking out those particles to nulls - it’s a bit of a boring task but it’s doable.

Are your particles moving at all? I wrote a few simple scripts to use pflow as a method of distributing grass a few years back where I’d bake the particles to nulls with position, rotation and scale, then use another script to swap the nulls with custom geometry - again it might be a bit slow with 360000 particles but you’d be better off trying to it in batches of 10,000 particles instead of one large go.

Renting could be an option. But there is also the fact that I am not very well versed with TP/Krakatoa et cetera, so softwareskills matter, too.
ANd yes my particles are moving, needed a windy turbulent image at the end, so no way around running an animation :frowning:

Hmm - next thing is can you get away with any kind of level of detail stuff or partition the particles that don’t get as near the camera? How many pixels will they be on screen so you might be able to drop your poly count?