Jump to content

  • Log In with Google      Sign In   
  • Create Account


Starting with GL Instancing, advice?


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
4 replies to this topic

#1 spek   Prime Members   -  Reputation: 993

Like
1Likes
Like

Posted 23 February 2013 - 09:37 AM

Hey, I'm thinking about implementing Instancing, but before doing so, I need some general advice.

 

So far, most of the rendering is done by looping through (sorted) lists and call a VBO for each object. In some other cases, like drawing a simple sprite, I still use the good old "glVertex3f(...) <4 times>) method. And then for particles, I use a VBO containing many particles that can be updated with OpenGL Transform Feedback.

 

It makes sense that using Instancing helps when rendering lots of the same object (but at a different position, or with slight differences). But in practice, most of my objects only come in small numbers. 3 boxex, 5 decals, 1 barrel, et cetera. Does it still make sense to implement instancing, or does it actually slow down things with overhead? Or to put it different, when rendering a single quad, is instancing equal or faster than doing it the old 4x glVertex3f way?

 

 

Second, some of my objects are animated, and use Transform Feedback to let a Vertex Shader calculate the skinned vertex positions. Each animated model would have its own secundary VBO to write back the transformed vertices. This takes extra memory of course, then again the amount of animated objects is very small compared to the rest. I'm guessing this technique does not co-operate with instancing in any way right?

 

 

Third. My meshes use a LOD system. So when getting further away from the camera, they toggle to a simplified mesh. Is it possible to put all LOD models (usually I have 3 to 5 variants) in a single buffer and let the Instancing somehow pick the right variant depending on the distance? Or would using LOD's being less needed anyway?

 

 

Any other things I should keep in mind when working with Instancing?

 

Merci beaucoup

Rick


Edited by spek, 23 February 2013 - 09:40 AM.


Sponsor:

#2 Ashaman73   Crossbones+   -  Reputation: 7139

Like
1Likes
Like

Posted 26 February 2013 - 03:21 AM

I'm still developing on OGL2.0+extensions, though here are my experiences/knowledge:

1. I draw gui elements (including letters for text!!) the old way (glVertex..,glColor, etc.), not using any buffers or lists and still the performance is remarkable (300-500 + few thousand letters,this will slow down the game, but most often only half the FPS on my nvidia8800).

2. Particles and decals are in a VBO (dynamic), no CPU update once they have been spawned (they move along a spline which is calculated on the GPU alone).

3. Static ad-hoc batching for grass, stones,small plants.

4. Every other object is rendered as single VBO call.

 

In my pipeline the most significant impact has the post-processing effects (screensize-bottleneck). I see it like that, that we (hobby-indie) devs have so much GPU/CPU power at hands, that up-front over-optimization is seldom necessary smile.png , your game will most likely benefit more from maintainable code.

 

Best to check, if you are pixel shader bound (screensize test), then try to check, if some state changes (texture switches etc.) are limiting your performance and eventually check if really draw calls are a limiting factor. I.e. most of my models don't have less then 1000 vertices, I never use LOD after seening no performances improvements.

 

But it depends on your hardware target and what you render (200 zombies  or 10 enemies ? A forest ? ).

 

If you want to optimize I would take a look at the particle system. The geometry shader could be used to improve the particle throughput (one vertex expanded to 4), though particles are most likely although pixel-bound.


Edited by Ashaman73, 26 February 2013 - 03:22 AM.


#3 spek   Prime Members   -  Reputation: 993

Like
0Likes
Like

Posted 27 February 2013 - 04:09 PM

Your approaches look pretty much like the techniques I also uses. Manual drawn stuff for quadlike HUD stuff, VBO's with transform feedback for decals, and 1 VBO call per object.

 

The amount of objects is most likely not a performance killer in my case indeed. Asides from particles, enities are rarely duplicates more than 10 times. Yet the goal now is not to make things faster, but just to be prepared in case we do actually need a high number of the same objects or decals. Which is not unrealistic when thinking about scenes with a lot of rubble, or foliage.

 

So, if Instancing comes for "free" even if you don't really make good use of it, it wouldn't hurt either to implement it, just in case. I'm not really worried about the code getting more stiff, as most of the objects to draw are grouped and sorted for batching already anyway.

 

Greets



#4 Vincent_M   Members   -  Reputation: 621

Like
0Likes
Like

Posted 27 February 2013 - 06:51 PM

I haven't used VBOs much, but if you're building a sprite system, I would recommend a "sprite batch". You'd have two classes: Sprite and SpriteBatch. SpriteBatch holds an STL vector of vertices and an STL list of Sprite objects (could go with pointers and allocate too, and that would cut down on copy operations when manipulating the Sprite list). Then, each group of vertices in that vector correspond a sprite object. That sprite object would contain your sprite's properties list its transform matrix, position, dimensions, blit parameters, etc. the Sprite class would have a pointer to its "parent" SpriteBatch it belongs to so that it has access to the vertices it's manipulating. You could also add animation and physics properties to Sprite.

 

Sprite batch would also contain the texture you're using, and handle all rendering. The pros are that you draw all of your objects using that texture in one call. The drawback is that your'd software-transform each sprite using matrix math on the CPU. Still, you only transform the vertices when a change occurs instead of each frame. This could be costly for particle systems, but then again, you'd want point sprites for that!

 

 

EDIT: I forgot to mention models.

I would say it's a good idea to use VBOs with static models. Again, you'd have two classes similar to my sprite example about: Model and ModelObject. The model is in charge of loading the 3D model data from your file, and storing a copy of the data. Then, each ModelObject would be allocated to store a "parent" pointer to the loaded "Model" object it wants to take the form of, and hold world-space properties like a transform matrix, attachment matrix, physics properties, bounding volumes for frustum checks, etc. Model will contain an STL list of ModelObjects, all of whom can be positioned, rotated, attached, scaled, targeting other objects, etc. Then, run Model through your Update and Render loops. Model's Update() and Render() methods will set the shader that model uses, and call each ModelObject's corresponding Update() and Render() methods respectively. The Object's Update() and Render() properties will render the model's data using it's transform data, physics, etc. You can even add an "isRendering" property to ModelObject and check if it's TRUE each frame before rendering.

 

The same can go for dynamic models, but you'll be running vertex skinning code on its vertices for each ModelObject's Render() call so the vertices are temporarily transformed for that instance. Additional animation data would be required such as an Animation class that holds all animation data once (you can store a list of Animation objects in Model), and each ModelObject instance will only hold the animation(s) being applied to it and current frame so the vertices can be skinned either on the GPU via vertex shader, or in real-time on the CPU each frame per Render() call.


Edited by Vincent_M, 27 February 2013 - 07:08 PM.


#5 spek   Prime Members   -  Reputation: 993

Like
0Likes
Like

Posted 28 February 2013 - 04:10 PM

Well, particles, objects and skinned characters are already optimized in terms of using VBO's, and letting the GPU do all the work (converting vertices to sprite quads, moving the particles, and storing skinned vertices back into a second VBO). The real question is, would it hurt (performance wise) to apply instancing (like shown here http://sol.gfxile.net/instancing.html) even if the majority of entities doesn't come in huge numbers?

 

The question arised when I was spawning bullet cases, which tend to come in big numbers when shooting machine guns. So far, these are rendered like any other object in my engine, which comes down to this:

loop through sorted list // sorted on material
{
     sortedList[x].referenceObject..material.apply; // applies shaders, textures and parameters
     for each object in sortedList[x].objects
     {
          object.applyMatrix;
          sortedList[x].referenceObject.vbo.draw;
     }
}

But since these particular bullet cases come in larger numbers, it could be done with instancing, which changes the code "slightly" into something like this

 

loop through sorted list // sorted on material
{
     sortedList[x].referenceObject..material.apply; // applies shaders, textures and parameters
     pushMatrices( sortedList[x].objects.allMatrices );
     sortedList[x].vbo.drawMultipleTimes( sortedList[x].objects.count );
}

It might make the bullets being drawn a bit faster, though most other types of objects may not benefit. Yet, if it doesn't harm either, I prefer to write the drawing approach in a single way, rather than having to split the instanced objects from the non-instanced objects and do things in two different ways...






Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS