OpenGL drawlist optimisation

About Monkey 2 Forums General Programming Discussion OpenGL drawlist optimisation

This topic contains 7 replies, has 2 voices, and was last updated by  Angus 1 year, 8 months ago.

Viewing 8 posts - 1 through 8 (of 8 total)
  • Author
  • #11380


    Translating monkey code to mx2 recently had me going through my drawing process and thinking about how to make it reasonably fast.  I’m sure that this is a well worn topic, but it’s hard to find definitive answers.  I suppose that means that there aren’t absolute rules.

    I understand that State changes are costly.  Binding new textures, changing blend mode, changing primitives that are being drawn (I think.. going from triangles to quads for example.)  Also that making calls to OpenGL in general are costly, each vertex having some cost.  (I use the word “understand” in it’s loosest sense)

    So here’s a question:  Assuming that I’m using indexed vertexes, so there’s no transformation overhead;  is it worth reducing all graphics to triangles?  Assuming I can limit other changes to the state, does the benefit of only having one long list of triangles to draw outweigh the time consumed having to add the extra vertexes?  A quad made of two triangles requiring 6 vertexes to be passed in.

    And here’s a follow up:  I also want to draw a lot of strips of triangles.  Assuming I can tweak the innards of mojo to do this, would a long set of triangle strips of varying length provide a real benefit?  Bearing in mind the vertex transformations are not duplicated.  Would modern openGL open a new Begin-End block for each strip of different length in a way that would actually be slower than incorporating all those varying strips into one huge triangle list?

    Lots of triangle strips would mean a reduction in vertex calls by at least a third I think (possibly much more) but the constant start stop drawing of them might eat up all the savings.

    I realise these may be pretty daft sounding questions.  I’m pretty ignorant about it, and like I say I mainly expect there to be no solution that’s certain to be best.

    Edit:Also, all this is probably dancing on the head of a pin for desktop apps, I dont think I’ve ever been starved of power on modern pcs.  But I think about it more for android apps.



    modern opengl doesn’t use begin/end blocks anymore. it’s vbo and shaders now
    in essence you:
    – (pre) design what a vertex contains. Usually position, maybe uv and normals, maybe other stuff as well
    – (pre) decide the vertex structures (vertex buffers) for each object
    – (pre) construct the shaders

    note that all of this is pre. you should set up this once at the start. and it remain unchanged during the render process (you can regenerate the vbo’s if needed though).

    for each render loop, you will probably have some form of scene management – what it is and how it works is up to you.
    – change shader
    – draw the models with that shader
    – change to another shader
    – draw the models
    – maybe change other stuff like blend mode
    – change shader
    – draw models
    make sure that the bindings of any bitmaps is correct for each shader change
    you can change drawing methods (triangles, triangle strips, etc, as much as you want.

    When you draw a model you will need to feed the shader a model matrix giving the model it’s position
    the shader will also have a view matrix (for perspective, etc) and a view position – maybe other matrix stuff as well

    the shaders are split in 2 vertex (moves the vertexes around), and fragment (gives the look)



    Yes, I’ve picked some of these things up looking through the mojo code.  I wasn’t sure if the was still a Begin-End structure in there deeper than I’d looked 🙂

    I guess I’d ultimately only be drawing triangle strips, with one or more triangles.  Interesting that a set of these of varying length wont be troublesome?

    In terms of minimising other state changes, I just take care.  I use a layered display, which makes it somewhat easy to decide when some changes take place.  For example I can elect to have a layer or range of them all be drawn from one texture, or one layer to draw only additive blended graphics objects.  I dont have to stick to these rules, but can use them to avoid masses of changes.

    I think I may have a go at switching from triangles to strips.



    strips will be faster – as you are sending less vertexes.

    Question for you?
    Are you using mojo as the base with GLWindow (and your own 3d code)? or Mojo3d?



    If it’s really the case that drawing a set of strips with varying lengths is fine then that’s great.

    I’m using mojo(2D) slightly tweaked to allow me to determine draw operations and send individual vertexes.

    It’s a 2D system I’m using/making which sort of makes it more difficult to know whats best.  A lot of my shapes will be quads (sprites more or less) but more and more often now I’m trying to make things from curves, which obviously benefit from being thought of as larger groups of polys.  Many of my objects could be rendered best as strips rather than fans, but I think I could tweak mojo a bit more to make that happen.



    Also, I’m using a normal Window… I’m pretty new to mx2 and I guess I’ve just been doing what’s “comfy-est” should I use a GLWindow?  You don’t really need to answer that, I’m sure I can look into it 🙂


    PS. Also also, thanks for your reply, motivates me to give some changes a go!



    no problem 😉

    OK. I’m currently writing a 3d system for monkey2 using OpenGL. so can help if any is needed. I can also show you some of the code to get things done as well (if wanted).

    My code is heavily customised, but I am starting from an optimised view with lots of little 3d things making the big picture…

    I know you are looking into modifying the mojo canvas class to allow you to do some custom vertex manipulations. (I’ve done some modifications myself to add some missing things, so I use the the canvas stuff)

    some things to think about with 2d and 3d in monkey2:
    – use mojo.canvas for 2d stuff – adding things to allow for curved surfaces in 2d if needed
    – you can use shaders in mojo.canvas for dealing with images. but it’s not documented or obvious.
    – use GLWindow for writing your own 3d stuff
    – use mojo3d if opengl or 3d matrix stuff scares the hell out of you



    Thanks for the offer, and hope your code goes well.

    Yeh I’ve just done a tiny thing to the canvas, but in doing it I read a fair bit of the mojo graphics code.  I’m pretty inexperienced, but it seems like one of the things about monkey that really isn’t appreciated enough.  Though the api is clean and straightforward, the amount of OpenGL “stuff” that’s right there in mx2 code is eye-opening.

Viewing 8 posts - 1 through 8 (of 8 total)

You must be logged in to reply to this topic.