Hi All,

I want to reduce render time for millions of particle (2 million in my current file). For now mantra takes 20-30 mins per frame.

Of late i am researching on particle rendering inspired from krakatoa(Max plugin). I have managed to create a wedge simulation otl. So i would actually work on a few thousand but can distribute and simulate millions with different seed and that too in less than 4-5mins.
Now the issue comes on rendering. I have a custom constant shader with edge fall of to make particles soft. i Dont wanna use Render as points or they lose the softness. I even tried writing ifd and modifying parameters directly to save re render write read process. But ended up in 200-300MB ifd per frame files. which still take 5-10 mins to render per frame.

I had tried using cluster this, even added my custom script to multiply particles at render time. But im not getting enough control nor the desired look. The render looks like bunches of particles traveling.

Please suggest a way to speed up my renders. Or if anyone has made a krakatoa like plugin. Kindly guide me to the same.

Thanks

A former student here at SCAD, Hosuk Chang, explored a technique called slice rendering. This uses the distance from the camera to define groups of particles. Renders out the separate slices of the particle system and then they can be composited back together.

The compositing can be done in the renderer-
1. Render farthest slice
2. Render the next farthest slice using the previous render as a background image.
3. Repeat.

He used this as a means of Data Expansion but I'm curious as to whether implementing such a technique could also lower render times for smaller particle counts?


Hosuk's Website-

http://s204357084.onlinehome.us/project/dataExpansion_1/dataExpansion_1.html [s204357084.onlinehome.us]

With 2 million points you need to render as points.
The reason for this is that only a single shader call will be made when rendering as points, that is basically what slows your render down if you don't use it.
They will need some motionblur to sit well together.
Whatever you do with your scene, you will want to bring your particles back in through delayed load, not straight into your ifd file.

You can instance delayed loads as well and use the instancpoint() expression to change the filename of the delayed load.
You can have a look at this post to see how to set it up (even though it's with curves it's the same kind of principle):
http://forums.odforce.net/index.php?/topic/10741-white-swann%c2%b4s-growing-cotton-candy/page__view__findpost__p__70081 [forums.odforce.net]

You'll want to stay away from raytraced shadows and instead use depth map shadows. raytraced will force the delayed loads to be kept into memory.

Ideally you will write your points to disk in space partioned boxes (an octree is preferable, but a grid will do as well), check “Eetu's lab” on odforce. Those boxes will form the bounds of your delayed loads.

One of the strengths of krakatoa lies in its' file format. It is possible to read part of a file without loading in the entire thing.

hey peter,

One of the strengths of krakatoa lies in its' file format. It is possible to read part of a file without loading in the entire thing.

i thought this is added to bgeo as well, when I got the journals right

Houdini 10.0.589: Support for loading tiled .bgeo files created with future versions of Houdini.

but i think it is not used in the current builds

sanostol
i thought this is added to bgeo as well, when I got the journals right

Houdini 10.0.589: Support for loading tiled .bgeo files created with future versions of Houdini.

but i think it is not used in the current builds

Ah learned something new. This is a very recent development.

One more idea might be to render your wedged particle passes separately into deep camera maps - that way you should be able to properly composite the whole bunch together afterwards.

(Never tried it, though..)

eetu.

sanostol

Houdini 10.0.589: Support for loading tiled .bgeo files created with future versions of Houdini.

Amazing, they make a current version future compatible! Very cool.


I tried a 4 million point render below. It took under 2 mins to render. I varied the particle size and coupled opacity with it. DOF and motionblur to make them more realistic and render out as points with one light and a depth shadow map. Memory is the main issue.

Wow glad to see so many replies just in a night (in india)

sanostol
I tried a 4 million point render below. It took under 2 mins to render. I varied the particle size and coupled opacity with it. DOF and motionblur to make them more realistic and render out as points with one light and a depth shadow map. Memory is the main issue.

Thats an awesome time saver dude but how u managed to do it? Also rendering as points wont give me the soft look which i get otherwise with edge fall off. I want to create wispy smoke kinda effect from particles.

Heres sumthin i attempted with 2Million particles at the expense of time and space! Tuk me 3 hours to render a 100frame sequence on a 16core 12GB RAM machine.

im though still to look into delayed load concept. would work on that an update what i get

If it is possible and you want to, you can upload the hip file and I can see if and how I can reduce render time while maintaining the softness.

I wonder if you have any unneeded extra attributes on your points. If you do a wispy effect I guess you are using particles. A popnet will often create tons of attributes that you should delete.

The stills look nice by the way.

We render 50-100 M of particles with mantra.

1. We don't use particles due to a lot of unnecessary data. And we removed all unnecessary point/vertex/primitive data at all.
2. We wrote splicer - a node, which build sparce boundbox system. Here is an example of sceneview
http://www.google.com/buzz/iqcook/ZgHLUwCruBE/Houdini-look [google.com]
3. By CopySOP-based chains we sliced and save to disk that big pointcloud to a lot of bgeo chunks, and reused them in render chain with delayed load CopySOP-based chain.
4. mantra has problem with rendering of > 100M, even with dense chunks.
5. We converted that bgeo to volume grids and tried to render them, but we have no good result with mantra - but with prman's volumetric renderer it was all ok.
6. Indeed - no raytrace at all, bounds were corrected to count with motion-blur, compressed bgeo used.

Soothsayer
If it is possible and you want to, you can upload the hip file and I can see if and how I can reduce render time while maintaining the softness.

I wonder if you have any unneeded extra attributes on your points. If you do a wispy effect I guess you are using particles. A popnet will often create tons of attributes that you should delete.

The stills look nice by the way.

Ya i already made sure i remove all unnecessary attributes. Only the ones i need r there like V, alpha, Cd, Id.

Thanks dude. If the render issue is solved i can work on improving the looks even more!
My hip file only has my custom otl which reads the already written wegged bgeos and adds pscale and custom constant material and renderes. i doubt i hve rights to upload hip files here

Ya im looking in the options posted here. would let you kno soon!

rubens83
Ya im looking in the options posted here. would let you kno soon!

Just a single bgeo file with the points would do it I guess.

JoeMislang
We render 50-100 M of particles with mantra.

1. We don't use particles due to a lot of unnecessary data. And we removed all unnecessary point/vertex/primitive data at all.
2. We wrote splicer - a node, which build sparce boundbox system. Here is an example of sceneview
http://www.google.com/buzz/iqcook/ZgHLUwCruBE/Houdini-look [google.com]
3. By CopySOP-based chains we sliced and save to disk that big pointcloud to a lot of bgeo chunks, and reused them in render chain with delayed load CopySOP-based chain.
4. mantra has problem with rendering of > 100M, even with dense chunks.
5. We converted that bgeo to volume grids and tried to render them, but we have no good result with mantra - but with prman's volumetric renderer it was all ok.
6. Indeed - no raytrace at all, bounds were corrected to count with motion-blur, compressed bgeo used.

sweet,I'm going to write one too - should provide a good exercise in HDK. I've already got my own instancer with delayed loads, the key of what you guys are doing is in the nice way of partitioning it and the controls you've got there.
Thanks for sharing!

We plan to publish whole solution nearest future, here you are!