Hi list and SESI.
I am making some particle effects that i am rendering as sphere primitives using the Primitive SOP and mantra.
My question is why i only get motion blur with velocity MB.
Neither transformaton nor deformation blur works.
I think that transformation blur should work because the spheres are moving.
And of course, velocity MB is very very expensive, the frame cost seven times to render compared with the no MB frame.
In the other hand, with renderman, that doesn't have velocity MB how i can get MB if trandformation and deformation don't work?

Thanks

Anytime you use particles, you have to use Velocity blur, because the point count is changing. However, if the point count does not change (no particles are born or die) then you should be able to use Deformation blur too.

This is because Deformation blur works by comparing the points at the start of the frame to the points at the end of the frame (effectively, the next frame) and if they are different, bad things happen )

As far as I know, Renderman should be able to render Velocity blur, but I don't know the details about how to make it work.

Cheers,

Peter B

Thanks Peter.
So when mantra detects that the topology between frames is not equal then deactivates the transformation/deformation MB.
Another doubt, is that i have seen that increase a lot it render times if you have many semi transparent surfaces, like sprites or spheres with a smoke shader, constrained in a little volume space, like many spheres coinciding in a bucket.
There are any ways to optimize these situations?, because i have frames that, except a few buckets the rest are very fast to render, but these few buckets are very expensive in time to be rendered.

thanks

you could try making your bucket size a bit smaller

Hi there,

If you know that you have a lot of transparency that never reaches opacity of 1, you should adjust Mantra's Opacity Limit down a bit. THat could help speed transparent object rendering up a little. ALso things such as Ray Tracing LOD and shading quality might help too.

Take care,
Alex

For arctor: iahev the idea that the greater bucket sizes the faster bur more expensive in memory, iam in a mistake? can i decrease these render times usig a small bucket size?, for instance 8
For TheUsualAlex: i have tried to play with the opaciti threshold but i didn't good results, the are to be rendered have opacitieas in the whole range 0-1, Playing with the LOD dosn't help because i am not using raytracing. And i am using a standar shading quality, shading rat 1, supersample 3.

Thanks

You can try turning off rendering with micropolygons under mantra render options. If the image gets noiser turn up sampling higher to compensate.

You can try turning off rendering with micropolygons under mantra render options

So micropolygons are not needed for rendering sphere primitives or sprites?
Then how are they rendered?

If you turn off micropolygon rendering, then I believe that primitive spheres are rendered as pure primitives and the cards are just 4 point quads I believe rendered as polygons as a procedural. Nothing gets diced up in to micropolygons and the render tends to use more memory. The look will also change.

As for rendering many opaque surfaces, well this will just take a long time to render. Firing rays through all those surfaces just takes a lot of time in rendering. In some cases if you are looping through lights at every surface hit, then it can get quite expensive time-wise. Sometimes it is faster to just raymarch through a volume than use sprites. Manipulating the Opacity Limit as mentioned before is the most obvious way to speed up your renders. May lead to a tich of flickering but probably is unnoticeable.

jeff
If you turn off micropolygon rendering, then I believe that primitive spheres are rendered as pure primitives and the cards are just 4 point quads I believe rendered as polygons as a procedural. Nothing gets diced up in to micropolygons and the render tends to use more memory. The look will also change.

As for rendering many opaque surfaces, well this will just take a long time to render. Firing rays through all those surfaces just takes a lot of time in rendering. In some cases if you are looping through lights at every surface hit, then it can get quite expensive time-wise. Sometimes it is faster to just raymarch through a volume than use sprites. Manipulating the Opacity Limit as mentioned before is the most obvious way to speed up your renders. May lead to a tich of flickering but probably is unnoticeable.

So you advice to normally use micropolygons.
I am not using raytracing.
Inraymarching, normally, you gat lighting info too so the problem is the same i think.

Thanks

Yep. It is just a matter of where you create the data to test against: Geometry vs. voxel data.

Pick your poison.

jeff
Yep. It is just a matter of where you create the data to test against: Geometry vs. voxel data.

Pick your poison.

Hi Jeff, there are any way to convert the voxel data in a 3dtxture to a bunch of sprites?

Thanks

No, not that I know of.

Now what you can do is render sequences of small bits of cloudy stuff and then use these sequences looped on your sprite cards!

If you render normal maps and do the work such that they render on flat cards lit front to back, it can look awful ‘purdy’.


Still expensive to render though…

Note that it is possible to convert an i3d texture file to a lattice of points. On the command line:

i3dconvert test.i3d test.bgeo

Then you can load the geo in Houdini and render as points, or sprites if you prefer.

Now what you can do is render sequences of small bits of cloudy stuff and then use these sequences looped on your sprite cards!

If you render normal maps and do the work such that they render on flat cards lit front to back, it can look awful ‘purdy’.


Still expensive to render though…

Yes i have tried it.This kind of effects are always expensive. But i want to research a clever way to get textures from the 3dtexture and render it like sprites not like a volume.

Note that it is possible to convert an i3d texture file to a lattice of points. On the command line:

Yes i know it too, the only problem is that you need to generate a very high resolution texture to get enough points, and this is very expensive.