Horde3D http://horde3d.org/forums/ |
|
instancing and impostors http://horde3d.org/forums/viewtopic.php?f=1&t=696 |
Page 1 of 1 |
Author: | SpOOky [ 07.04.2009, 22:41 ] |
Post subject: | instancing and impostors |
I remember this mater being discussed in the crowd scaling topic. Since then are there any new developments? I am starting a new project, that's centered around a vegetation system. Horde3D already comes in handy with deferred lighting but the actual scaling of the ecosystem largely depends on these two features. Are there any plans for these(especially instancing) in the near future? |
Author: | DarkAngel [ 09.04.2009, 05:28 ] |
Post subject: | Re: instancing and impostors |
IIRC, instancing was only added to OpenGL in GL3.0 or 3.1. There is of course the hacky "pseudo instancing" demo (made by NVidia I think) built on GL2.0 - I don't know Marciano's thoughts on this technique. Impostors can currently be implemented at the application level. Using render-to texture, you can render a particular 3D model down to a 2d texture, which is in turn used by a simple "quad" 3d model - A billboard node would be helpful here. |
Author: | SpOOky [ 09.04.2009, 09:00 ] |
Post subject: | Re: instancing and impostors |
i was looking into nvidia's technique and from what i've seen its made using glsl.(?) so horde being shader based, it just a matter of making a shader? regarding rtt, i came across this. Is there another aproach, a shader one? |
Author: | DarkAngel [ 09.04.2009, 11:04 ] |
Post subject: | Re: instancing and impostors |
RTT is already implemented in horde. The camera node has a param called "OutputTex" which is the ID of a texture resource to render to (or default 0 renders to the screen). NVidia's pseudo instancing is not just a shader-based technique - it requires the way that the matrices are sent to GL by the CPU to be modified in the engine. NVidia use a hack where they store world matrices inside the texture coordinate storage instead of GLSL uniform storage, which is slightly easier for their drivers to deal with. From the PDF: Quote: Pseudo-instancing applies well to geometry with a small number of per-instance attributes. So this technique would not work for a lot of horde models, such as animated characters - but probably would work for your vegitation.The technique does not scale well to complex mesh rendering techniques like skinning; there are not enough vertex attributes to store all of the bone transforms for each instance. Quote: Direct3D instancing reduces the number of DrawIndexedPrimitive() calls from many to one. This points out that instancing solves different problems in GL and DX - in DX, each draw call is very slow, so instancing is used to group them together. In GL, draw calls are much faster, so instancing doesn't help as much here. This DrawIndexedPrimitive() call reduction has a large performance benefit in Direct3D. In OpenGL, the application still calls glDrawElements() (or the like) for every instance. This isn’t too much of a performance hit because glDrawElements() is very efficient in OpenGL. Furthermore pseudo instancing doesn't actually reduce draw calls at all - you need the real deal (in GL3.1) to achieve that. Pseudo instancing is only used to slightly speed up the calculation of the world-view-projection matrix. It should be pretty easy to add to the engine - the only modification is the way in which the world matrix is sent to the shader. Shader resources would require a flag of some sort to indicate to the engine which method to use. |
Author: | marciano [ 09.04.2009, 22:08 ] |
Post subject: | Re: instancing and impostors |
DarkAngel is right, instancing is actually a hack that is required in D3D9 since the drawcalls are so slow. Here is an interesting benchmark: http://www.ozone3d.net/blogs/lab/?p=87 As you can see, in OGL instancing has only an advantage for models with a small number of polygons. Besides that it will not work with characters that require all shader registers for the joint matrices. Real or pseudo instancing could be a nice option for a vegetation system extension (anyone willing to write one? ![]() |
Author: | SpOOky [ 13.04.2009, 22:25 ] |
Post subject: | Re: instancing and impostors |
DarkAngel wrote: This points out that instancing solves different problems in GL and DX - in DX, each draw call is very slow, so instancing is used to group them together. In GL, draw calls are much faster, so instancing doesn't help as much here. I understand the method better now. Furthermore pseudo instancing doesn't actually reduce draw calls at all - you need the real deal (in GL3.1) to achieve that. Pseudo instancing is only used to slightly speed up the calculation of the world-view-projection matrix. Is the instancing in GL3.1 based on an existing extension that has been moved to the core or is it brand new? marciano wrote: As you can see, in OGL instancing has only an advantage for models with a small number of polygons. Besides that it will not work with characters that require all shader registers for the joint matrices. Real or pseudo instancing could be a nice option for a vegetation system extension (anyone willing to write one? &&![]() DarkAngel wrote: It should be pretty easy to add to the engine - the only modification is the way in which the world matrix is sent to the shader. Shader resources would require a flag of some sort to indicate to the engine which method to use. Would the "flagged" way to send the matrices be added to Horde3D? Does the extension system provide enough access to achieve that?So let me get this straight, pseudo instancing brings a performance increase for objects that have few transforms, like static props, right? LE: I came across this extension, ARB_draw_instanced This is the real deal. Even used with opengl 2.1. An extension build on this could be plausible. |
Author: | swiftcoder [ 23.10.2009, 01:10 ] |
Post subject: | Re: instancing and impostors |
SpOOky wrote: LE: I came across this extension, ARB_draw_instanced This is the real deal. Even used with opengl 2.1. An extension build on this could be plausible. That is the extension which was integrated into GL 3.x. Note that it doesn't seem to offer performance benefits in very many cases - large numbers of static low-polygon models is the only case I have found where there is a benefit.
|
Page 1 of 1 | All times are UTC + 1 hour |
Powered by phpBB® Forum Software © phpBB Group https://www.phpbb.com/ |