property node slow?

[borisb2]

Hi.

I'm setting up particle-simulations. At the moment I'm testing with about 5 mio. particles (rendered as disks). The render-time was fine for me (about 15 min with hdr-PBR etc.), but as soon as I add a property-node to change particles $PSCALE over time, the rendertime shoots up to 30-40min and above.

Also caching out the particles didn't decrease rendertime (???) .. bgeo-files were about 440 MB per frame

Is there a lighter way to change the scale of particles based on age, or is something wrong with my scene?

Thanks for any help!

[borisb2]

well I made another test:

700k particles render about 2.30 min - just adding the property-node in the POP-network and activating PSCALE in the misc-tab (without changing anything) shoots up the rendertime to more than 5 minutes !!!

Now this is what I would consider a slooow node.

Is that really normal ??

[glomm]

try editing pscale attribute in sops with vop sop node.

its multithreaded and will work much faster

[symek]

well I made another test:

700k particles render about 2.30 min - just adding the property-node in the POP-network and activating PSCALE in the misc-tab (without changing anything) shoots up the rendertime to more than 5 minutes !!!

Now this is what I would consider a slooow node.

Is that really normal ??

Did you time it for a sim and render, only sim, or only render? Property node may take a time, since you're editing properties per particle. As mentioned earlier, using vopSOP may help. More over is PropertyPOP at the end of a chain? If not, note that pscale attrib may be used by other pops (Interact, Collision etc), so changing it changes simulation.

If we talk only about render time (without simulation or exporting IFD file, which may take a while with ~million of points), when you change a size of a particles, you actually change the conditions of rendering, thus render time may change also. Did you increase a size of your particles? Default is 0.01 (?), changing it for anything higher == more pixels occupied by particles == longer time to render.

Edited October 12, 2010 by SYmek

[borisb2]

thanks.

But do I have access to $LIFE in SOP-Level? (want to fade out particle-size based on age).. not quite sure

Do you have eny example for that?

[ikarus]

my experience is $LIFE exists in the sop level, i usually have to make an extra attribute and assign $LIFE to it though, as any direct calls to $LIFE give me errors

[anim]

life attribute from POPs is easily accessible in SOPs

either as expression:

life is float2 attribute which contains age of the particle and lifespan so in sops it is accessible as 2 variables $AGE and $LIFESPAN

but $LIFE would also work for expressions

or in VOPs:

to get it in VOPs however you need to calculate it from age and lifespan attributes

you can't access life attribute directly through parameter VOP but it actually exists in Global Variables as age and life

so to get the actual life of the particle (0-1) you simply use Divide VOP do divide age/life from Global Variables

EDIT: it seemes that $LIFESPAN is not working in SOPs, only in POPs, but $LIFE and $AGE is so never mind

Edited October 13, 2010 by anim

[symek]

thanks.

But do I have access to $LIFE in SOP-Level? (want to fade out particle-size based on age).. not quite sure

Do you have eny example for that?

See attachment for an example of what anim said (sorry, I have not Houdini at the front of me yesterday).

Generally any attribute from any context (SOP, DOP, POP for geometries' attributes + CHOP and COP for samples) is accessible in other contexts. This is what Houdini is all about. You can at infinitum exchange data between contexts. What can be missing is a local variable (since it's local to a context...) to get to the data (like in case of $LIFESPAN), but variable is a shortcut to an attribute which is always to your disposal.

cheers,

skk.

life_in_sops.hip

Edited October 13, 2010 by SYmek

[borisb2]

thanks for the example! .. Did I already mention that I'm normally a Maya-TD? That's why I have to ask these beginner-questions

Well I found out the following - which is somewhat weired to me, but good to know:

I was rendering the particles with an env-light and an hdr-map mapped to it. Using the property-node more than doubles the rendertime in this case - or at least in my case. Rendering just with spotlight with deep-shadows shows almost no difference in rendertime with or without the property node.. Luckily I don't need the env-light that much (using the same hdr for reflecting the particles a little gives me almost the same look).. but it would be interesting to know why this happens

Edited October 15, 2010 by borisb2

[borisb2]

..If we talk only about render time (without simulation or exporting IFD file, which may take a while with ..

A little off-topic question: Is there a way to export an ifd-file from houdini to render a sequence or is it always like one ifd-file per frame? (need to know that for RenderPal)

Thanks again.

[symek]

A little off-topic question: Is there a way to export an ifd-file from houdini to render a sequence or is it always like one ifd-file per frame? (need to know that for RenderPal)

Thanks again.

single ifd == single frame. This is by design, which comes from the Renderman idea.

PS as a side note, I haven't tried this yet but it seems to me that theoretically one could render whole animation from a single ifd after placing many cameras in it, but this wouldn't alter any geometry/scene elements.

Edited October 15, 2010 by SYmek

[borisb2]

single ifd == single frame. This is by design, which comes from the Renderman idea.

Thanks for clarifying.

But then it gets tricky : I have now 6 different takes (for diferent passes) merged together to render with 1 render-button. If I would output all the passes as ifd-files I would get like 100 frames * 6 passes ifd-files? Is there a way to output at least this merge-node as one ifd-file (per frame of course)?

If not, I guess I stick with rendering from houdini - even if I just spent some dollars for RenderPal. But to have for my current job (which is about 12 shots/30s) several thousand ifd-files in the end - thats too much. And they all would have to be loaded in RenderPal.

Edited October 15, 2010 by borisb2

[symek]

Thanks for clarifying.

But then it gets tricky : I have now 6 different takes (for diferent passes) merged together to render with 1 render-button. If I would output all the passes as ifd-files I would get like 100 frames * 6 passes ifd-files? Is there a way to output at least this merge-node as one ifd-file (per frame of course)?

If not, I guess I stick with rendering from houdini - even if I just spent some dollars for RenderPal. But to have for my current job (which is about 12 shots/30s) several thousand ifd-files in the end - thats too much. And they all would have to be loaded in RenderPal.

As I understand what is prohibitive for you is an export time of ifds. There are a couple of steps to consider.

1. In an optimal scenario, exporting ifd file shouldn't take much time. First of all, your geometry which takes more than a few megabytes should be baked along with all shaders into delayed load archive. This way Houdini won't place it into a main ifd file every frame and won't compile these shaders. In some cases it will cut down ifd export time into a seconds instead of a minutes. This won't help much if long export time comes from things like instancing. This will take a while in case of many instances, but still you can make some optimization.

2. My favorite one is python ifd filtering. Basically many from a properties of objects/lights already put in ifd can be altered by mantra before rendering with python script. You can enable/disable objects visibility, switch shaders, turn on/off lights, mattes, phantoms and similar. So actually from a single ifd file you can get many different pictures. This takes some time for setup, but may help. We have a custom Mantra ROP which setups python filtering in GUI. For details look here: http://www.sidefx.com/docs/houdini10.0/rendering/python

hth.

skk.

PS Perhaps I should note that I know nothing about RenderPal, so all of these may be complete useless for you.

Edited October 15, 2010 by SYmek

[borisb2]

Thanks SYmek..

I found this in the houdini docs:

---

Render a .hip file directly from the command line:

Use the provided hrender script in $HFS/bin. This script is written in csh. To use this script on Windows, you will need to use a UNIX-like environment such as Cygwin.

---

If I would manage to get that working, I think I could setup the executable in RenderPal for the houdini renderer to render that script. Has anybody used this workflow?

EDIT:

another question: I'm loading in the particles with a file-SOP. But the ifd-files seem to include all the particle-data. You mean, only with the delayed load archive I would avoid that?

Edited October 19, 2010 by borisb2

[symek]

I'm loading in the particles with a file-SOP. But the ifd-files seem to include all the particle-data. You mean, only with the delayed load archive I would avoid that?

Yes, this is how it usually works. DLA makes mantra to load your particles directly from disk, just like a rib archive in renderman or proxies in Vray. Important note: put render flag on a nullSOP inside the object, and then apply delayed load procedural to it. Otherwise particles will go to your ifd file despite of procedural applied.