🔒 Locked

optimizing my engine

Started by Wilhelm van Huyssteen Mar 2, 2009 at 2:23 AM 2 replies 700+ views

Original Post

Mar 2, 2009 at 2:23 AM

hey. ive been working on my engine for a while now and its finaly begining to look like something, but ive pretty much neglected performance ultil now and i would like to have some pointers as to how i can improve it. im going to try and explain how i currently go about it (try not to vommit at it plz ;p) i have 3 threads. 1 for resource loading, 1 for rendering and one for game logic and whatever else my engine loads models and textures dynamicaly as my application requests it. each static mesh goes into its own VBO (thats probely bad...) my render loop goes through my scene graph and where ever it encounters a visible node(static mesh) it binds the apropriate VBO for that mesh,loops through all the textures that the mesh uses and calls a glDrawArrays each iteration (when loading my meshes i sort the poly's by texture and i store the offsets and lenghts of these 'texture ranges' for this purpose) im not even going to mention the weird way im doing lighting. anyway. what i think i should be doing firstly is to change DrawArrays to DrawElements (obviously changing the way i load my meshes) and at the same time use one VBO for more that one mesh (is it a good idea to put all static meshes in one big posible 30meg or more VBO? should it be interleaved?) and then i think i should batch my glDrawElements together by VBO/texture is my line of thoughts going the right way? i just want to know what i missed/got wrong before i start making any changes Thnx in Advance!

JohnnyCode

Mar 2, 2009 at 8:22 AM

yes, use grdrawelements,
batching depends. if you do collision detection on your terrain, batching would caouse that all objects will be tested, even those which would have their bounding box out of the colliding object, thus could have been droped from cl test, so batching can be sometimes, bad, and also if you have dynamicly constructed scene, big mesh would couse a visible delay when getting loaded to memory again. Definitely share resources, it can then couse fast objects load, as you will just pass pointers of shared data instead of creating them over again. Do yorself at least a camera frustum culling. Also do not swap buffers when you have done rendering, but swap buffer just before you start rendering. Also I do not know wheather sepparate threads are a good solution, don't they have to wait for each other? GPU rendering is a sepparate thread nativly, so after you've rendered you actulay have just posted instructions to be done on GPU and at swap buffers CPU waits for GPU to finish, have you rendering loop like this

ProcessGameAndPhys() // gpu is working
SwapBuffers() // cpu has finished wait until gpu has finished too
render() // gpu starts working

so a sepparate thread for gpu rendering and for resource loading sounds quite strange for me, du no , may be it gains some

V-man

Mar 2, 2009 at 8:55 AM

No, a 30MB VBO is not a good idea.
http://www.opengl.org/wiki/VBO_-_more

Wilhelm van Huyssteen

Mar 3, 2009 at 1:17 AM

thnx for clearing that up for me a little

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.