Speeding Up Obj Loader for OpenGL

This is a discussion on Speeding Up Obj Loader for OpenGL within the Game Programming forums, part of the General Programming Boards category; Iv'e just got my latest project up and running, which is an .Obj loader iv'e been working on for the ...

  1. #1
    Master n00b Matty_Alan's Avatar
    Join Date
    Jun 2007
    Location
    Bloody Australia Mate!
    Posts
    96

    Speeding Up Obj Loader for OpenGL

    Iv'e just got my latest project up and running, which is an .Obj loader iv'e been working on for the last few days, However it runs very slowly... like .5 fps if the object is mildly complex

    This is due because I call glBegin and glEnd for every pollygon, and when there 13,500 pollygons to draw, thats alot of calls to glBegin and glEnd so my main question is this...
    Is there a way to Draw Multipul Polygons without calling glBegin And glEnd For Every Single One? like some kind of seperator command

    Also I havn't yet but will put in a binarey tree (as soon as i can get the thing to work) How much speed increase can i expect from putting from a linked list.

    Any other tips or sugestions are VERY welcome.

  2. #2
    spurious conceit MK27's Avatar
    Join Date
    Jul 2008
    Location
    segmentation fault
    Posts
    8,300
    In fact, glBegin/End() and all the related functions have been depreciated in openGL 3.2. They are referred to as "immediate mode" functions and you are right, with complex objects they become very cumbersome, partially due to the outrageous number of function calls required.

    There are a few different ways of doing things without immediate mode. One is to use "Vertex Buffer Objects". These are kind of neat because it means placing all your vertices directly in video memory. The point of the immediate mode functions is to transfer data to the video card from normal RAM, and witness this occurs every single damn frame. So as an added advantage, with the VBO you can skip that -- nb, shuffling that data from RAM thru the processor to the video card involves some bottlenecks, such as the Front Side Bus speed. VBO's are like outrageously faster than immediate mode.

    Further bonus: your code base is smaller. Disadvantage: you are going to be very steamed about the amount of re-coding your stuff that's required. It is kind of unfortunate that most GL beginner books, etc, never seem to explain that you are only learning a way, and not the way. However, if you have hit the wall with immediate mode (I imagine using stuff from model shops will do this pretty quick), you really and truly have no choice.

    VBO's aren't very well documented. I was so p'offed with this by the time I got it all straight I decide to write a tutorial:

    Intro to GL VBOs 1

    I submitted this to the openGL forum users and had them review it, and I get a fair number of hits on it too. There are still some minor desciptive errors I need to correct (eg, "every function call in C/C++ requires a stack be created, then freed at the end." is not true), but all the actual code is fine*. It's quite a nice tutorial IMO (of course ).

    If you want to look at the responses/corrections from the forum review, here's the thread:
    VBO Tutorial ready for review! - OpenGL.org Discussion and Help Forums
    I'm "akashiraffee". Everyone else is a curmudgeon Some (but not all) of the observations are a little off base, I believe this turned out to be because some people read part of the tutorial and then complained I didn't cover such and such or present it in it's full light -- the dynamic aspect of VBO manipulation isn't discussed until the third section.

    You may also want to ask on that forum about the other alternatives to immediate mode, with which I am not familiar, altho I think VBOs are usually taken to be the best method.

    * the texture loading function I use has a wee flaw but it works fine in context and is not important wrt VBO's anyway.
    Last edited by MK27; 04-23-2010 at 01:00 PM.
    C programming resources:
    GNU C Function and Macro Index -- glibc reference manual
    The C Book -- nice online learner guide
    Current ISO draft standard
    CCAN -- new CPAN like open source library repository
    3 (different) GNU debugger tutorials: #1 -- #2 -- #3
    cpwiki -- our wiki on sourceforge

  3. #3
    Registered User
    Join Date
    Aug 2003
    Posts
    1,197
    You do not need to call glBegin and glEnd for each polygon. Say you call glBegin and state you want to draw triangles, and you want to draw 2 triangles, you just put 6 calls to glVertex3f before you do glEnd and thats the end of it. OpenGL will figure out the rest.

  4. #4
    Programming Wraith GReaper's Avatar
    Join Date
    Apr 2009
    Location
    Greece
    Posts
    1,602
    That only works for points, lines, triangles and quads though, not for polygons with an arbitrary number of vertices
    Devoted my life to programming...

  5. #5
    Registered User
    Join Date
    Aug 2003
    Posts
    1,197
    So split it all up into triangles at load-time. IIRC OpenGL deals with triangles when it gets down and dirty anyway so you will probably get a speed-increase just by splitting it all up into triangles once and not let opengl do it at run-time.

  6. #6
    Master n00b Matty_Alan's Avatar
    Join Date
    Jun 2007
    Location
    Bloody Australia Mate!
    Posts
    96
    I tryed to compile the VBO tutorial Posted above and got these errors

    Does this mean my version of OpenGL does not support this? or am I missing something?

    Im using DevC++ with the OpenGL Headers that come with it.
    Attached Images Attached Images  

  7. #7
    Super Moderator VirtualAce's Avatar
    Join Date
    Aug 2001
    Posts
    9,586
    Meshes should only consist of triangles. If you are drawing polygons that are not triangulated you are doing something wrong.

  8. #8
    Master n00b Matty_Alan's Avatar
    Join Date
    Jun 2007
    Location
    Bloody Australia Mate!
    Posts
    96
    Quote Originally Posted by Bubba View Post
    Meshes should only consist of triangles. If you are drawing polygons that are not triangulated you are doing something wrong.
    Iv'e put the Mesh into quads but not triangles yet, it seemed to work with quads fine.
    This is the first time iv'e ever really worked with this kinda stuff so it's a massive learning curve right now

  9. #9
    spurious conceit MK27's Avatar
    Join Date
    Jul 2008
    Location
    segmentation fault
    Posts
    8,300
    Quote Originally Posted by Matty_Alan View Post
    I tryed to compile the VBO tutorial Posted above and got these errors

    Does this mean my version of OpenGL does not support this? or am I missing something?

    Im using DevC++ with the OpenGL Headers that come with it.
    Those are definitely things to do with this, I believe:
    Code:
    #define GL_GLEXT_PROTOTYPES 1		/* include prototypes to save us some compiler warnings, etc */
    Which this could be platform and even driver specific. Thanks for letting me know, mebbe I will do some digging and do that update.

    The reason for those switches is because the VBO functions used to have _ARB suffixes, which means they were for testing by the "Architecture Review Board" and associated parties. But they have depreciated stuff at the same time as they have failed to provide support for what comes after what is now "legacy", methinks.

    Probably if you ask at the OGL forum and refer directly to that tutorial code someone will have an answer. In any case, post your OS and GL driver (nvidia or ATI). I'm guessing it's most likely a windows issue with the headers/define switches.

    My tutorial aside, VBOs are the way to go (google: there are other tutorials for different platforms around, windows to iphone -- openEL uses VBOs, there is no immediate mode -- but they are somewhat piecemeal. Start reading and combine them ). Once you have that, you can start using shaders/glsl (these are short precompiled programs you can keep in video memory, along with the vertex data, to complete all of the rendering within the GPU -- you issue parameters to shaders like functions or objects. Contemporary high performance 3D stuff, with both DX and OGL, is all shaders).

    Vis, learning curve, 3D graphics reminds me of web-dev in the sense that you are often dealing with different "technologies" on different levels that have different dimensions of cross-platform compatibility, but the end result is supposed to take place in someone's desktop environment. Many discrete pieces to fit together that are generally presented abstracted enough from one another to cover all cases in a relationship, but in real terms require intuitive leaps.
    Last edited by MK27; 04-23-2010 at 05:02 PM.
    C programming resources:
    GNU C Function and Macro Index -- glibc reference manual
    The C Book -- nice online learner guide
    Current ISO draft standard
    CCAN -- new CPAN like open source library repository
    3 (different) GNU debugger tutorials: #1 -- #2 -- #3
    cpwiki -- our wiki on sourceforge

  10. #10
    Master n00b Matty_Alan's Avatar
    Join Date
    Jun 2007
    Location
    Bloody Australia Mate!
    Posts
    96
    I done some googling and found out that i needed Glee to fill some gaps

  11. #11
    Registered User
    Join Date
    Apr 2010
    Posts
    6
    An alternative solution to VBOs for increasing your render speed is display lists. Display lists are less flexible than VBOs, but the amount of rewrite to go from immediate-mode rendering to Display List rendering is significantly reduced. As long as you stay within the constraints that a display list imposes (most notably that once the model is in the list its vertices cannot be re-generated... this does NOT mean that you can't still apply transforms to them! just that the model cannot be mutated), the rendering speed of a display list and VBO will be equivalent.

  12. #12
    Registered User
    Join Date
    Jun 2008
    Posts
    62
    Quote Originally Posted by Thinias View Post
    An alternative solution to VBOs for increasing your render speed is display lists. Display lists are less flexible than VBOs, but the amount of rewrite to go from immediate-mode rendering to Display List rendering is significantly reduced. As long as you stay within the constraints that a display list imposes (most notably that once the model is in the list its vertices cannot be re-generated... this does NOT mean that you can't still apply transforms to them! just that the model cannot be mutated), the rendering speed of a display list and VBO will be equivalent.
    Not so true. Display lists still have significant CPU->GPU data transfer going on with each draw. While display lists are faster then the begin/end pairs, they still slower then VOBs (well, ok, this does depend on the implementation, it is possible to make it about as fast, but that would require throwing away the client->server model of opengl).

    That being said, VBOs came standard in 2003, with most major video cards having the ABR extension available for quite a while before that. Any computer built within the last 7 years should support it.

  13. #13
    Master n00b Matty_Alan's Avatar
    Join Date
    Jun 2007
    Location
    Bloody Australia Mate!
    Posts
    96
    Iv'e tryed to add VBO into my program and the speed improovement is awesome to say the least, but im getting this massive problem and im not sure why, i'm not sure how to discribe it but it's doing this (see attchment).

    if you want to take a look iv'e uploaded the source codes Here

    Other feedback is welcome also.
    Attached Images Attached Images  
    Last edited by Matty_Alan; 04-25-2010 at 03:40 AM.

  14. #14
    spurious conceit MK27's Avatar
    Join Date
    Jul 2008
    Location
    segmentation fault
    Posts
    8,300
    looks to me like you just have some vertices backward somewhere.

    When this happens to me, I like to pretend I am actually doing 7D graphics instead of 3D. Nothing is wrong, it's your eyes are the problem.
    C programming resources:
    GNU C Function and Macro Index -- glibc reference manual
    The C Book -- nice online learner guide
    Current ISO draft standard
    CCAN -- new CPAN like open source library repository
    3 (different) GNU debugger tutorials: #1 -- #2 -- #3
    cpwiki -- our wiki on sourceforge

  15. #15
    Registered User
    Join Date
    Oct 2008
    Posts
    1,262
    I was planning on looking at your code. But it's horribly unreadable, mostly due to the indentation. If you want others to read your code, make sure you indent right, at least.

Page 1 of 2 12 LastLast
Popular pages Recent additions subscribe to a feed

Similar Threads

  1. how to use 'this' for different obj in class
    By effa in forum C++ Programming
    Replies: 2
    Last Post: 10-06-2009, 08:01 PM
  2. Checking array for string
    By Ayreon in forum C Programming
    Replies: 87
    Last Post: 03-09-2009, 03:25 PM
  3. OBJ TDS files .. what are they ?
    By moonwalker in forum C++ Programming
    Replies: 1
    Last Post: 07-22-2002, 02:21 PM
  4. ARG.... My Texture Loader is screwed... PLEASE HELP!
    By minime6696 in forum A Brief History of Cprogramming.com
    Replies: 6
    Last Post: 01-22-2002, 04:45 PM

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21