Optimizing Dust Renders

[deecue]

hey everybody,

yet another question for you fine folks. what approaches are people taking to get optimized render times when dealing with demolition dust like elements (and also not having proprietary voxel renderers and not wanting to go down the i3d route)? currently we're taking a sprite approach with a simple shader to get the effect we're wanting but it's not giving us the turn around times we were hoping for (30 min to 2 hours per frame at almost 2k). the sprites can be dang fast but once they get big and transparent, render time sky rocket which is no surprise. but it's frustrating to be able to render 20,000 sprites with 10% opacity that are really tiny in seconds, but 200 sprites with the same opacity that are large enough to overlap take forever. then once you introduce self shadowing via either deep shads or filtered shads, it just make it near impossibly to iterate as fast as we would want to. the size of the sprites is killing us but we also don't want them small enough to not see the detail in the shader and be able to keep the dust soft enough so it doesn't look like sand.

so any thoughts would be appreciated. i'd love to hear some feedback as maya's hardware rendered sprites with almost realtime preview of textures and transparency in the gl is constantly being brought up (even though you have to hack their shadows).. so i'd love to knock these preview times down just for iteration purposes if anyone has some suggestions.

thanks everyone,

dave

[MIguel P]

I never had large rendering times using sprites. Maybe you can try dividing the dust in different layers and composite them and use deep shadows with different qualities.

[stevenong]

Hey Dave,

First, convert your sprite textures to .rat if you haven't. This allows some memory optimisation & also filtering, if needed.

Next, under the Specific tab of a Mantra ROP, there is an Opacity Limit parameter which you can use to help speed renders up. Render a frame with the Opacity Limit set to 1 for reference then send off 10 frames to the network with 0.1 increments (0.1, 0.2, 0.3 etc) & see what value matches the reference frame and reduces the rendering time.

Please let us know how it goes.

Cheers!

steven

[deecue]

thanks for the quick replies miguel and steven.. we're currently breaking up the dust layers for compositing sakes but i'm still investigating how to optimize things as much as possible.. i went ahead and reworked the shader from scratch today to something very minimal and i'm getting better results at much lower point counts. so that's helping out a lot on render times. i have a feeling i was using only a small portion of the area per sprite which meant more points and much larger spritescales to accommodate the look. now that i attempting to use as much of the sprite area as possible per particle, i'm getting away with a lot less and smaller scales. still want to keep pushing it and see where i can make it better though.

it might be good to actually output some texture maps in .rat.. didn't think of that. the only thing is that i'm using a lot of custom attribs on my particles to drive different parameters of the shader.. so i would lose that control if i went with a map based approach rather than a procedural shader one.

the opacity threshold on mantra should prove useful on our really thin stuff. thanks steven for that. unfortunately most of the elements range from the very condensed and thick to the spread out and thin so it will clip a good amount in those passes. but useful to have and will come in handy.

i'm just looking forward to 9 and see what these volumetric objects are about that i keep hearing so much of. sounds friggin awesome.. can't wait to play with those gas solvers..

thanks guys..

dave

[deecue]

has anybody seen render errors along the frame edges of an image when rendering sprites? it seems to be pretty random in it's occurence.. some times it does it, sometimes it doesn't. and they're random on everyframe so they flicker like crazy.. here's an example of what i mean:

left image with wierd render issues along the bottom frame, right image is fine. nothing changed to create the renders. (and these aren't the edges of the sprites themselves showing through)..

thanks all,

dave

[aracid]

hey dave

ive done a bit of sprite rendering.

does this happen with all your sprite rendering or just that sequence?

is there any way of submitting a hip?

[deecue]

hey aracid,

it's pretty random.. i saw it a little while back and didn't see it again until it popped up in my renders from last night so i don't think it something specific causing this. if i get some more time i might just run a whole bunch of tests with things riding along the borders of the frame and see what i can track down. but even as you can see in the image above, it can render badly and it can render perfectly fine, so it's kind of an odd game to start locating where the issue may be.

unfortunately i can't post the hip.. i was just curious to see if anyone ever came across or had seen anything like that before hand.

cheers,

dave

[3dbeing]

Does it happen on a seq run locally or only on the farm?

[hoknamahn]

Hey deecue. I had the same problem before. For some tasks sprites was faster but for other the best choice was volumetrics. Yea they was much faster than sprites (in some cases). So keep in mind - volumetrics not as slow as people think

[MIguel P]

So keep in mind - volumetrics not as slow as people think

Yes, but i3d...

[hoknamahn]

What is wrong with i3d? i3d is not bad. One thing missing in i3d - texture compression (not deflate but wavelet) and the ability to use different levels of complexity than you get the value from 3d texture (octrees, kd-trees etc).