Maybe this isn't the place for this question, but:
I assume it's possible to use a single static VBO pattern in GPU memory while still having multiple instances of it displayed at different locations on the map - e.g., use a single VBO for a tree model but have a thousand trees at different locations on the landscape?
If so, is it also possible to rotate different instances each at different angles, or modify them in other ways, perhaps using vertex shaders?
Static VBOs
-
ChaiRuiPeng
- Posts: 363
- Joined: Thu Dec 16, 2010 8:50 pm
- Location: Somewhere in the clouds.. drinking pink lemonade and sunshine..
-
Lonesome Ducky
- Competition winner
- Posts: 1123
- Joined: Sun Jun 10, 2007 11:14 pm
You usually upload one mesh buffer to the card, then use glDrawElementsInstancedEXT to draw it many times at different locations in your shader. You still have to do frustum culling for each instance and as the objects move each frame you upload all the transformations, but it means you get batched draw calls without the memory drain, and don't have to upload the mesh data each time a mesh moves. Useful if you have many thousands of the same object.
If your card supports geometry shaders then you can upload the geometry data into one buffer and the positions into another, then do the culling in the shader. Not sure how to do this, but it should take some weight off the CPU at the expense of the GPU.
There are other methods too, but unless you have identified a specific need for instancing then you probably won't need it anyway.
If your card supports geometry shaders then you can upload the geometry data into one buffer and the positions into another, then do the culling in the shader. Not sure how to do this, but it should take some weight off the CPU at the expense of the GPU.
There are other methods too, but unless you have identified a specific need for instancing then you probably won't need it anyway.
I think this would be useful enough to add as a standard feature - I'm surprised it already hasn't been.
Here's why it could be used in _most_ programs to dramatically speed up rendering:
Most applications make use of objects that are composed of the same set of standard components - many buildings have remarkably similar windows, doors, columns, roof joists, etc; trees have similar branches, clumps of leaves, etc; people all have similar arms, legs, hands, and other standard components; even clouds could be composed of a relatively small set of puffy clumps grouped together in different combinations to create varied clouds. If each component could be stored permanently on the video card, you obviously save enormous amounts of time - I came across one application which achieved FPS rates of up to 3000 using static VBOs.
I don't know if I could write it, but someone who is familiar with this type of thing could do it as a standard add-on.
Here's why it could be used in _most_ programs to dramatically speed up rendering:
Most applications make use of objects that are composed of the same set of standard components - many buildings have remarkably similar windows, doors, columns, roof joists, etc; trees have similar branches, clumps of leaves, etc; people all have similar arms, legs, hands, and other standard components; even clouds could be composed of a relatively small set of puffy clumps grouped together in different combinations to create varied clouds. If each component could be stored permanently on the video card, you obviously save enormous amounts of time - I came across one application which achieved FPS rates of up to 3000 using static VBOs.
I don't know if I could write it, but someone who is familiar with this type of thing could do it as a standard add-on.
The main advantage would be to greatly reduce the amount of video card memory needed to store the static geometry, while still gaining the performance of a static VBO - i.e., instead of having to store an entire landscape with millions of polys, you could break the landscape into standard components (trees or tree branches; grass clumps; different rock models; etc) and then use multiple instances of each VBO. Or is the performance reduced by from the methods that need to be used in order to render multiple instances of the same VBO?hybrid wrote:Static VBOs as well as all other VBOs are part of Irrlicht since version 1.4. Instanced rendering has not so much performance gain, but if someone finds a place where this could be easily added into Irrlicht, we will take a look.
For the general case you'd have to group and sort all of those things by material, each frame in the worst case. All the mesh loaders would have to take advantage of this strategy, you'd maybe need to make a modelling program that takes advantage of it, and it certainly wouldn't work with fixed function materials, meaning special materials for instanced geometry.
It would add a lot of complexity and overhead to the scene manager to aid a special case that would be rarely beneficial. For these reasons it's not worth it as a general strategy, but could be useful in some cases for special types of geometry, like a forest or an asteroid field. In these cases it's best left to the user, rather than being automatic.
It would add a lot of complexity and overhead to the scene manager to aid a special case that would be rarely beneficial. For these reasons it's not worth it as a general strategy, but could be useful in some cases for special types of geometry, like a forest or an asteroid field. In these cases it's best left to the user, rather than being automatic.
-
hybrid
- Admin
- Posts: 14143
- Joined: Wed Apr 19, 2006 9:20 pm
- Location: Oldenburg(Oldb), Germany
- Contact:
Yeah, this is the problem with getting the maximum gain from massively instanced VBOs. When I made my VBO sphere test I had to sort all meshes manually prior to rendering. Then I had to avoid any material changes which might occur due to the generic approach we use in our render calls. It's often the case that even though nothing actually changes, the driver still cannot be sure whether the data is still valid and would rearrange the VBO setup.
I see the following approach as best support that we can give: Add a new driver call which calls the necessary low-level calls (such as drawInstanced) and assumes certain things to be prepared by the user. This would give the ooportunity to add new custom scene nodes which make this kind of special geometry. It might even be worth adding an option to the particle system, which could be used for instanced rendering as well. Maybe sio2's demo would also give some hints about possible implementations.
I see the following approach as best support that we can give: Add a new driver call which calls the necessary low-level calls (such as drawInstanced) and assumes certain things to be prepared by the user. This would give the ooportunity to add new custom scene nodes which make this kind of special geometry. It might even be worth adding an option to the particle system, which could be used for instanced rendering as well. Maybe sio2's demo would also give some hints about possible implementations.