Sign in to follow this  
goowik

OpenGL Rendering possibilities

Recommended Posts

goowik    129
Hi,

I've started learning OpenGL a few days back and love it [img]http://public.gamedev.net//public/style_emoticons/default/smile.png[/img]
It's been a few months to almost a year I've been creating games in 2D, time to change!

As of now I always created my primitive objects with an immediate rendering coding
For example:
[CODE]
glBegin(GL_TRIANGLES);
glColor3f(1, 0, 0);
glVertex2f(-0.5f, -0.5f);
glColor3f(0, 1, 0);
glVertex2f(0.5f, -0.5f);
glColor3f(0, 0, 1);
glVertex2f(0.5f, 0.5f);
glEnd();
[/CODE]

After reading some articles on performances I found out there are several more rendering "patterns". There is:[list]
[*]Display lists
[*]Vertex arrays
[*]Vertex buffer object
[*]and Immediate
[/list]
Does it come to personal preferences when choosing one of them? Or is there a major difference?

Also let's say you have a cube. How can you cull 3 of the invisible sides and make it change each time you move around it.
Is this coding different per rendering pattern?

Kind regards
Peter Edited by goowik

Share this post


Link to post
Share on other sites
larspensjo    1561
You are using legacy OpenGL. It is fine for testing small simple things, but not good enough for "real" applications. And it is usually not feasible to start with legacy, and then upgrade, because it is done differently.

Have a look at [url="http://www.arcsynthesis.org/gltut/"]Learning Modern 3D Graphics Programming[/url], and you will quickly learn the modern way of doing it.

Unfortunately, most of the tutorials "out there" are done in the old way.

Share this post


Link to post
Share on other sites
goowik    129
@lardpensjo:
Just so I understand better: By Legacy OpenGL you mean the way of writing code? Not the library I'm using?
Thanks a bunch for the link! Guess I have some work to do testing out :)

@mark ds:
okay, I guess I forgot to mention that I'm using [url="http://www.lwjgl.org/index.php"]LWJGL [/url](The Lightweight Java Game Library). But I guess the OpenGL code isn't much different from c++.

Share this post


Link to post
Share on other sites
mhagain    13430
Specific differences between the 4 items you mentioned.

Immediate mode is fine for rapid prototyping and experimental work. It [i]can[/i] be fine for learning, provided you recognise and accept that it's a suboptimal path that can lead you into bad habits, and that you plan to move away from it as quickly as possible. It's suboptimal for a number of reasons - more calls into the driver means significantly higher function call overhead, and modern drivers are likely to emulate it via a dynamic VBO behind the scenes - not a good idea if the data is not dynamic. It also involves transfer of a lot of data from system memory to the GPU, which again is not good for data that is not dynamic in nature. It's been deprecated from recent GL versions so you need to be aware that you're learning something of very limited future utility.

Display lists provide a mechanism for caching GL commands and data on the driver for subsequent future use. The driver may cache them in GPU memory or in system memory (you have no control over this) and there are a set of highly complex rules for what state gets cached and in what circumstances it happens. In the right cases and with the right hardware it can be the fastest method available, but not all drivers or hardware are equal. Once created you can't modify a display list - you can only execute it or destroy it. If state or data needs to change you're SoL. Display lists are also deprecated so clean interaction with current and future GL functionality may not be guaranteed in all cases - approach with extreme caution in other words.

Vertex arrays allow you to specify a vertex layout and data in system memory in a handful of calls, and transfer it to the GPU very quickly in a single call. This retains the immediate mode overhead of needing to transfer data that may not change every time, but removes the function call overhead. For older code or code that needs to be compatible with older drivers (and note that we're talking [i]much[/i] older here - in the order of 10 years or so) this should be the preferred option. These are also deprecated, but - since VBOs are built on top of vertex arrays - are more likely to work well with modern OpenGL (e.g. instancing works perfectly fine with vertex arrays).

VBOs are the modern OpenGL way of doing everything. They're built on top of vertex arrays so they share the advantage of needing very few calls to specify and draw geometry, and have the added advantage that the data [i]may[/i] be stored in memory that is more optimal for the driver. This suits static data perfectly, but does mean that you need to be slightly more careful about how you operate with VBOs if you're using dynamic data (although do note that using shaders as well means that much data which formerly needed to be dynamic does not necessarily need to be so any more). As a general rule VBOs should be fastest of all on the widest range of hardware, but do note that it's [i]incredibly[/i] easy to write code using VBOs that runs slower than anything else if you're sloppy or careless.

With all that in mind my recommendation is to use vertex arrays for learning, but keep an eye on moving to VBOs. The reason why is that vertex arrays can share a lot of the same coding style as VBOs so you're primed for an easier move, but avoid traps for the unwary that can cause pipeline stalls throughout your program. Vertex arrays have also been available since OpenGL 1.1 so you can be very confident that driver support is ubiquitous. The same applies to VBOs, of course (although it's 1.5 rather than 1.1). So vertex arrays first and - when you get comfortable with them and build up more understanding of how things work in general - switch to VBOs.

Share this post


Link to post
Share on other sites
goowik    129
@mhagain:
Thanks for the detailed explanation. But after searching OpenGL's wiki I found the [url="http://www.opengl.org/wiki/Vertex_Buffer_Object"]Vertex Buffer Object page[/url].


Unfortunatly the following is written:
[quote]Legacy Note: Versions of OpenGL prior to 3.0 allowed the use of client-side data for vertex rendering, but GL 3.0 deprecated this. Core GL 3.1 and greater forbid client-side vertex data, so VBOs are the only means for rendering.[/quote]

And they state offcourse that it is recommended that we do not use any of these functionality in our programs.

So I have a two questions about this:[list=1]
[*]What is the meaning of Legacy? as 'lardpensjo' stated.
[*]What do they mean by client-side data? Isn't everything client sided?
[/list]

Share this post


Link to post
Share on other sites
Brother Bob    10344
[quote name='goowik' timestamp='1341341075' post='4955397']
So I have a two questions about this:[list=1]
[*]What is the meaning of Legacy? as 'lardpensjo' stated.
[*]What do they mean by client-side data? Isn't everything client sided?
[/list]
[/quote]
Legacy refers to the old OpenGL API up to version 2.1. Much of OpenGL 2.1 was removed from the API when 3.0 was introduced (there was a combatibility mode for some versions, but that compatiblity mode has been removed as well in 3.3), incluiding things such as display lists and client-side vertex arrays. Legacy refers to the now-deprecated API of version 2.1 and earlier.

Client-side and server-side in this context refers to the application (the client) and the OpenGL implementation/driver (the server). These are typically on the same computer (you run the application on the same computer you have your graphics card on), but that does not have to be the case. Especially on unix-platforms and their windowing systems, you can basically have the application run on one computer and have the display on another computer.

Client-side data in this context means the data is stored in memory managed by the application. For example, when you allocate the memory with malloc or new, or store the data in an std::vector). Server-side data means that the data is stored in memory managed by OpenGL. For example, texture data stored in a texture object with glTexImage or vertex arrays stored in a VBO are both stored in memory managed by OpenGL. They don't have to be physically stored on the graphics card, only that the memory is managed by OpenGL.

Server-side data is the only way to store any data in modern OpenGL. You may have to load your vertex arrays into your own memory before uploading them to your buffer objects of course, but you cannot use the vexrtex arrays to draw something until it has been uploaded into VBOs. Server-side is mandatory for everything involving user data at the moment, not just vertex arrays.

Share this post


Link to post
Share on other sites
jay2    317
If you have the choice, consider the API that is geared for the future of OpenGL. On mobile devices that would be OpenGL ES 2.0. Even if OpenGL 4.2 still supports the legacy api, you should try to avoid it if you can...
That being said, using immediate mode is still ok for quick testing and learning. But for the long run, and production code, avoid legacy API.
This page has some info about OpenGL Core profile: http://www.opengl.org/wiki/Core_And_Compatibility_in_Contexts

Look for glCullFace to find out how you can cull the invisible faces of your cube. glCullFace will always work no matter the rendering API you use.

Share this post


Link to post
Share on other sites
goowik    129
@Brother Bob:
Okay now I get it! So most of the code is backwards compatible till OpenGL 3.0.
Just out of curiosity, client/server side is this applicable to most graphic libraries (such as directX)?

@CodedVentures:
K so that clears most of it. To recap you simply have 2 "packages" (if I may call it this way):[list]
[*]The Core package
[*]The Compatibility (which was introduced in 3.2)
[/list]
Will the core always be the same? As all deprecated methods were removed?


EDIT:
I also was looking for a decent book to buy/rent and came across the "[i][b]OpenGL Superbible[/b][/i]"
But on [url="http://www.amazon.com/OpenGL-SuperBible-Comprehensive-Tutorial-Reference/dp/0321712617"]Amazon[/url] it does seem to have a low score (3.5/5) and the reviews are very various. Edited by goowik

Share this post


Link to post
Share on other sites
Brother Bob    10344
[quote name='goowik' timestamp='1341384981' post='4955542']
@Brother Bob:
Okay now I get it! So most of the code is backwards compatible till OpenGL 3.0.
[/quote]
That is correct. The compatibility mode of the modern API lets you extent the backward compatibility of the legacy API to version 3.1 even.

The modern API is mostly backward compatible as well, although there are some changes that makes it not. For example, vertex array objects (VAO) are not required in version 3, but are in version 4. That means that you cannot run a version 3 compatible program on a version 4 context. But that change is trivial; just use VAO in version 3 as well and you will have no problems with version 4.

[quote name='goowik' timestamp='1341384981' post='4955542']
Just out of curiosity, client/server side is this applicable to most graphic libraries (such as directX)?
[/quote]
I have no idea whether Direct3D makes the difference explicit in some way or not. I would, however, guess that pretty much the same requirements on memory management applies to both Direct3D and OpenGL: manual memory management is not possible, you have to let the API handle your resources.

[quote name='goowik' timestamp='1341384981' post='4955542']
@CodedVentures:
K so that clears most of it. To recap you simply have 2 "packages" (if I may call it this way):[list]
[*]The Core package
[*]The Compatibility (which was introduced in 3.2)
[/list]
Will the core always be the same? As all deprecated methods were removed?
[/quote]
The core changes, but (with few exceptions, see for example my comment above on VAO in version 3 and 4) new stuff are only added. What works on an earlier version typically works on a later version as well. Only exception of course is the major change from the legacy API to the modern API.

The compatibility mode was introduced in 3.0 though. From version 3.2 and onwards, compatibility mode is not available. Thus, it is only available for the modern API for versions 3.0 and 3.1.

Share this post


Link to post
Share on other sites
larspensjo    1561
[quote name='goowik' timestamp='1341384981' post='4955542']
I also was looking for a decent book to buy/rent and came across the "OpenGL Superbible"
But on Amazon it does seem to have a low score (3.5/5) and the reviews are very various.
[/quote]
I have that book, and I think the weakness is that it is that the examples are based on a home made support library. The disadvantage of that is for beginners, that do want simple examples where you can see the whole solution on the same page. The advantage is for the intermediate or advanced reader, that no longer cares about the basics but want to learn and understand advanced concepts.

If you have understood the basics, then the book is excellent.

Actually, a member of the forum, [url="http://www.gamedev.net/user/158805-japro/"]japro[/url], recently created basic minimal examples, perfect for beginners to start with. See [url="https://github.com/progschj/OpenGL-Examples"]https://github.com/progschj/OpenGL-Examples[/url].

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this  

  • Similar Content

    • By pseudomarvin
      I assumed that if a shader is computationally expensive then the execution is just slower. But running the following GLSL FS instead just crashes
      void main() { float x = 0; float y = 0; int sum = 0; for (float x = 0; x < 10; x += 0.00005) { for (float y = 0; y < 10; y += 0.00005) { sum++; } } fragColor = vec4(1, 1, 1 , 1.0); } with unhandled exception in nvoglv32.dll. Are there any hard limits on the number of steps/time that a shader can take before it is shut down? I was thinking about implementing some time intensive computation in shaders where it would take on the order of seconds to compute a frame, is that possible? Thanks.
    • By Arulbabu Donbosco
      There are studios selling applications which is just copying any 3Dgraphic content and regenerating into another new window. especially for CAVE Virtual reality experience. so that the user opens REvite or CAD or any other 3D applications and opens a model. then when the user selects the rendered window the VR application copies the 3D model information from the OpenGL window. 
      I got the clue that the VR application replaces the windows opengl32.dll file. how this is possible ... how can we copy the 3d content from the current OpenGL window.
      anyone, please help me .. how to go further... to create an application like VR CAVE. 
       
      Thanks
    • By cebugdev
      hi all,

      i am trying to build an OpenGL 2D GUI system, (yeah yeah, i know i should not be re inventing the wheel, but this is for educational and some other purpose only),
      i have built GUI system before using 2D systems such as that of HTML/JS canvas, but in 2D system, i can directly match a mouse coordinates to the actual graphic coordinates with additional computation for screen size/ratio/scale ofcourse.
      now i want to port it to OpenGL, i know that to render a 2D object in OpenGL we specify coordiantes in Clip space or use the orthographic projection, now heres what i need help about.
      1. what is the right way of rendering the GUI? is it thru drawing in clip space or switching to ortho projection?
      2. from screen coordinates (top left is 0,0 nd bottom right is width height), how can i map the mouse coordinates to OpenGL 2D so that mouse events such as button click works? In consideration ofcourse to the current screen/size dimension.
      3. when let say if the screen size/dimension is different, how to handle this? in my previous javascript 2D engine using canvas, i just have my working coordinates and then just perform the bitblk or copying my working canvas to screen canvas and scale the mouse coordinates from there, in OpenGL how to work on a multiple screen sizes (more like an OpenGL ES question).
      lastly, if you guys know any books, resources, links or tutorials that handle or discuss this, i found one with marekknows opengl game engine website but its not free,
      Just let me know. Did not have any luck finding resource in google for writing our own OpenGL GUI framework.
      IF there are no any available online, just let me know, what things do i need to look into for OpenGL and i will study them one by one to make it work.
      thank you, and looking forward to positive replies.
    • By fllwr0491
      I have a few beginner questions about tesselation that I really have no clue.
      The opengl wiki doesn't seem to talk anything about the details.
       
      What is the relationship between TCS layout out and TES layout in?
      How does the tesselator know how control points are organized?
          e.g. If TES input requests triangles, but TCS can output N vertices.
             What happens in this case?
      In this article,
      http://www.informit.com/articles/article.aspx?p=2120983
      the isoline example TCS out=4, but TES in=isoline.
      And gl_TessCoord is only a single one.
      So which ones are the control points?
      How are tesselator building primitives?
    • By Orella
      I've been developing a 2D Engine using SFML + ImGui.
      Here you can see an image
      The editor is rendered using ImGui and the scene window is a sf::RenderTexture where I draw the GameObjects and then is converted to ImGui::Image to render it in the editor.
      Now I need to create a 3D Engine during this year in my Bachelor Degree but using SDL2 + ImGui and I want to recreate what I did with the 2D Engine. 
      I've managed to render the editor like I did in the 2D Engine using this example that comes with ImGui. 
      3D Editor preview
      But I don't know how to create an equivalent of sf::RenderTexture in SDL2, so I can draw the 3D scene there and convert it to ImGui::Image to show it in the editor.
      If you can provide code will be better. And if you want me to provide any specific code tell me.
      Thanks!
  • Popular Now