Jump to content
  • Advertisement
Sign in to follow this  
blueshogun96

OpenGL A practical approach to pseudo instancing for OpenGL ES 2.0?

This topic is 836 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Okay, the reason I'm asking about pseudo instancing is because last I checked, OpenGL ES 2.0 devices still dominate the market.

 

Sources:

http://developer.android.com/about/dashboards/index.html

*shoot, I can't find a single article on the statistics of iOS devices capable of using 3.0+*

 

Eventually, OpenGL ES 3.x will overtake the marketshare, and ES 2.0 only devices will dwindle as it did with ES 1.1 and below.  Until that day comes along, I want to consider the most practical approaches for pseudo instancing where hardware assisted instancing is not supported.  My engine is crossplatform, and I intend for it to work on iOS, Android and Blackberry.  Ever since iPhone 5S, iPad Air/Mini w/ Retina, iOS has supported OpenGL ES 3.0 and also Blackberry since the Z30.  So it seems that it's becoming easier to get away with having an ES 3.0 only game engine, but I'd rather not do that at the moment.

 

So, what is my actual question?  I'm glad you asked.  When I think of two implementations of pseudo instancing, two things come to mind:

 

1. Use separate draw calls in a loop for each mesh and use an array and index to access attributes (not literal vertex attributes) related to that instance.

Example: http://carloscarrasco.com/faking-mesh-instancing-in-opengl-es-20.html

 

2. Use a dynamic VBO and encode the instance data into the vertex structure in order to limit everything to one draw call.

 

Example:

struct PseudoInstanceVertex
{
   /* Standard vertex attributes */
   vec3f position;
   vec3f normal;
   vec4f diffuse;
   vec2f texcoord;
   ...

   /* Instance vertex attributes */
   vec3f rotation;
   vec3f translation;
   ...
}

Then for each geometric shape, update per frame.

 

So, which one do you think is better?  My assumption is that #1 would be best suited for static geometry like trees in a forest that are primarily stationary and generally do not move, and that #2 would be best suited for dynamic geometry such as NeHe style butterflies made up of two procedurally generated triangles.  #2 would also have a bigger memory requirement and #1 is a bit heavier on the CPU.  I'm having a bit of trouble deciding which one has the better tradeoff.  So, any ideas?  Thanks.

 

Shogun.

Share this post


Link to post
Share on other sites
Advertisement

It's going to depend largely on the size of the mesh, I think. Option #2 is definitely better for particles/butterflies, and I reckon it'll continue to be better even up to a couple of hundred triangles and maybe much more because draw calls can be so very expensive on mobile devices.

 

There is always option #3. Create a static VBO in which your mesh is duplicated say 16 times. Add an instance index via a vertex attribute. Then you can render your mesh up to 16 times in a single render call by having each vertex transform itself by looking up into an uniform array.

 

Still, I would generally default to option #2 until it's a known bottleneck.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!