Jump to content

  • Log In with Google      Sign In   
  • Create Account

#ActualVincent_M

Posted 27 February 2013 - 07:08 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.


#1Vincent_M

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!


PARTNERS