david_aiken
david_aiken
About Me
Connect
LOCATION
Not Specified
WEBSITE
Houdini Skills
Availability
Not Specified
Recent Forum Posts
a few VRAY questions May 5, 2011, 6:19 p.m.
hi all..
I'm just getting into a VRAY procedural implementation and would like to optimize performance without getting into multithreading the procedural (we depend on an infrastructure which is not multithreaded). The procedural is expected to deliver geometry for large crowds. With that in mind, i had a few questions:
1) Can batching similar geometry and materials when calling addGeometry() from within the procedural significantly improve Mantra's performance? i.e. submit all instances of a particular mesh or material together. In OpenGL renderers this minimizes the number of state changes, but i'm not sure if Mantra cares.
2) If i have a bounding box with 1000 instances of a mesh with the same topology, but displaced vertices and different materials, is there a way to optimize the rendering of that geometry from within a procedural? Something like NVidia's demo at http://developer.download.nvidia.com/SDK/10/direct3d/Source/SkinnedInstancing/doc/SkinnedInstancingWhitePaper.pdf [developer.download.nvidia.com] , though i suspect it's a bit harder to do on non-NVidia hardware :>).
3) when render() is called, is it possible to determine the visible, 3D portion of the bounding box which needs to be rendered? This might result in significant savings if bounding box size is increased.
4) given that the procedural is single-threaded, are there recommended practices to balance the rendering so that it is not bound by the procedural's performance? I'm thinking along the lines of:
a) tuning the size of the micropolygon buckets, or other parameters which might increase the amount of time between calls to the procedural render()
b) controlling shader complexity
c) increasing the procedural's bounding box size
d) increasing the number of characters within the bounding box
Hope they're not FAQs..
Thanks!
I'm just getting into a VRAY procedural implementation and would like to optimize performance without getting into multithreading the procedural (we depend on an infrastructure which is not multithreaded). The procedural is expected to deliver geometry for large crowds. With that in mind, i had a few questions:
1) Can batching similar geometry and materials when calling addGeometry() from within the procedural significantly improve Mantra's performance? i.e. submit all instances of a particular mesh or material together. In OpenGL renderers this minimizes the number of state changes, but i'm not sure if Mantra cares.
2) If i have a bounding box with 1000 instances of a mesh with the same topology, but displaced vertices and different materials, is there a way to optimize the rendering of that geometry from within a procedural? Something like NVidia's demo at http://developer.download.nvidia.com/SDK/10/direct3d/Source/SkinnedInstancing/doc/SkinnedInstancingWhitePaper.pdf [developer.download.nvidia.com] , though i suspect it's a bit harder to do on non-NVidia hardware :>).
3) when render() is called, is it possible to determine the visible, 3D portion of the bounding box which needs to be rendered? This might result in significant savings if bounding box size is increased.
4) given that the procedural is single-threaded, are there recommended practices to balance the rendering so that it is not bound by the procedural's performance? I'm thinking along the lines of:
a) tuning the size of the micropolygon buckets, or other parameters which might increase the amount of time between calls to the procedural render()
b) controlling shader complexity
c) increasing the procedural's bounding box size
d) increasing the number of characters within the bounding box
Hope they're not FAQs..
Thanks!
Dust Effect Dec. 15, 2010, 12:32 p.m.
Cinesite did dust strikes using custom microsolvers for Clash of the Titans (http://www.sidefx.com/index.php?option=com_content&task=view&id=1838&Itemid=68 [sidefx.com]), an approach which requires significantly more expertise. But it's a true volumetric effect which is also capable of handling depression of the ground so perhaps it is worth it for some frames.