I have been working on a pet project (lbz3d.com) for a few years now. (about 8 years i think).
This is a simple and small cross platform game aimed at people that have propper rendering hardware. (nvidia… ati…)
I want to prepare this game for the future and make it compatible with openGL 3 and future opengl versions, since i want to keep updating it and i dont like using “deprecated” methods.
My project currently still uses a lot of fixed function geometry.
(including the model system and gui components, and sprites)
A quick “grep glBegin * | wc -l” told me that i have a lot of code to “rewrite”.
What is the best way for my project to stop using fixed function stuff? Should i work with VBO for all geometry?
I tryed VBO for models a while back but i could not get it to run fast enough…
so… can anyone tell me a future oriented stragety for my geometry?
Exactly, i think i am not using VBO correctly.
So far i have only managed to get it fast enough for my 3d levels, that geometry does not change much and thus can be uploaded once and rendered lots of times.
My other geometry: player models, sprites, objects needs to be uploaded lots of time because it’s changing geometry.
So my question becomes:
How do i implement VBO efficiently for quickly changing geometry like player models and dynamic game objects?
VBO are the better approach for dynamic meshes since memory management is better with them. For example, you can suggest the driver that one particular VBO will be updated often or not, setting for GL_STATIC_DRAW, GL_DYNAMIC_DRAW,… for memory usage.
A vertex array would be enough for static meshes like terrain, but VBO are heavily recommanded for dynamic objects like I said.
If you don’t already know this paper, it would be interesting for you. It explains in details what I am trying to tell you.
Thank you or the reply and the paper.
I have read this, but it does not answer all of my questions:
Do i overwrite/draw the same buffer lots of times?
Or do i create 1 large buffer and play with offsets?
I am guessing a seperate buffer for each object is out of the question? (would be a buffer for only a few triangles?)
Also: while testing the VBO extension for 3d levels i noticed that ELEMENT arrays in VBO buffers is very slow? (only on my ATI test system though) is it better to use client-side memory for the element buffers?
I am not experienced enough I think, to give you a very sure answer, but this is what I think:
It is better to have one VBO for a whole character or animated object. Then if you need to update a part of the data (for instance a head expression) you can call (with a VBO) glBufferSubDataARB (useful to replace small chunck of memory). Or if you need to read back goemetry data to then modify it, you can map the buffer using glMapBufferARB (taking care to call glBufferDataARB with a NULL data pointer as it is said in the paper).
Then if you have many different nanimated objects, you can try to group them, but I don’t how the number of buffers affects performances (Maybe someone else can tell you).
For 3D levels that are static meshes, calling glDrawElements may be slower than a glDrawArrays call, since there more things to do with glDrawElements.
So I advice you to arrange your 3D level data for vertex arrays which are very good for static geometry.
I’ve tended to use client-side arrays with glDrawElements. I haven’t done any performance testing on that, though. It’s just the method that I find easiest to code. I suspect VBOs (for direct graphics memory access) with glDrawArrays (which is very cache-coherent) would give the best performance, at least for static geometry.
Depending on the complexity of the mesh, a frequently-updated model may be better off with glDrawElements, since less data has to be transferred to the graphics card to use that call.
You should better specify what do you means with “animated”.
A rigged character can be achieved in various way with vertex shader.
Until now (oGL 2) the most common way was to specify the bones position as uniform and bones weight as vertex attribute.
If “animated” is a soft object deformed by physics than you have to update the buffer every frame (groan).
Other various “animated” effect can be achieved with vertex shader. (wave, morphing, ecc…)
I would not recommend using non-indexed vertices (glDrawArrays) because you would lose a post-vertex-shader cache and triangle strips although useful may reduce the efficiency of that cache because of index ordering. Indexing may cut down your vertex count to about 20% and I got 11% in extreme cases.
i currently use VBO’s for my levels (static geometry) and that works pretty well as long as i leave the ElementArray client-side.
i think i’m gonna run some test with VBO for characters also… but the current code is pretty much:
Build up client-side array with vertices transformed by bone matrix.
Loop trough draw commands,
glBegin (Trianglefan or strip)
Some vertices && stuff:
glEnd();
This is all not much of a problem, just need to test it good
what i am having trouble with is: what to do with UI/HUD’s and debug lines and stuff… it’s so easy to use glBegin/End stuff for that… what do i do when those or gone?
Thank you… that was so obvious i didnt see it :eek:
I think i better spend a bit more time and write an abstraction layer for GL so i dont have to dive into every little piece of rendering code when opengl 4 hits the shelves…
