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
Motion Blur questions
7539 14 3- lisux
- Member
- 581 posts
- Joined: July 2005
- Offline
- pbowmar
- Member
- 7025 posts
- Joined: July 2005
- Offline
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
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
- lisux
- Member
- 581 posts
- Joined: July 2005
- Offline
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
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
Un saludo
Best Regards
Pablo Giménez
Best Regards
Pablo Giménez
- goldfarb
- Staff
- 3455 posts
- Joined: July 2005
- Offline
- EigenAlex
- Member
- 639 posts
- Joined: July 2005
- Offline
- lisux
- Member
- 581 posts
- Joined: July 2005
- Offline
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
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
Un saludo
Best Regards
Pablo Giménez
Best Regards
Pablo Giménez
- AdamJ
- Member
- 268 posts
- Joined: July 2005
- Offline
- lisux
- Member
- 581 posts
- Joined: July 2005
- Offline
- old_school
- Staff
- 2540 posts
- Joined: July 2005
- Offline
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.
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.
There's at least one school like the old school!
- lisux
- Member
- 581 posts
- Joined: July 2005
- Offline
jeffSo you advice to normally use micropolygons.
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.
I am not using raytracing.
Inraymarching, normally, you gat lighting info too so the problem is the same i think.
Thanks
Un saludo
Best Regards
Pablo Giménez
Best Regards
Pablo Giménez
- old_school
- Staff
- 2540 posts
- Joined: July 2005
- Offline
- lisux
- Member
- 581 posts
- Joined: July 2005
- Offline
- old_school
- Staff
- 2540 posts
- Joined: July 2005
- Offline
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…
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…
There's at least one school like the old school!
- andrewc
- Member
- 1002 posts
- Joined: July 2005
- Offline
- lisux
- Member
- 581 posts
- Joined: July 2005
- Offline
Now what you can do is render sequences of small bits of cloudy stuff and then use these sequences looped on your sprite cards!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.
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: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.
Un saludo
Best Regards
Pablo Giménez
Best Regards
Pablo Giménez
-
- Quick Links