• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.
Sign in to follow this  
Followers 0
realh

OpenGL
Optimising 3D rendering order

6 posts in this topic

I've read that the order in which objects are rendered can make a big difference to performance, but there are two different strategies and I'd like to know if one is better than the other or "it depends" etc. They can be used together with major and minor sort orders, but which should be minor and which major? I'm most interested in OpenGL ES 2.0, but I think the same principles would apply to DirectX etc.

 

The first strategy is to aim to minimise the number of OpenGL state changes because they are allegedly expensive. I wouldn't have thought it would make much difference, but Mario Zechner (who wrote quite a good book about Android game development and libgdx, so I think he knows his stuff) says it can make a huge difference and advocates the use of sprite batchers for 2D rendering (where the alternative of depth sorting is irrelevant). So if you have a number of objects with the same mesh and material/ shader/ textures in different positions, you should only select their VBOs etc once per frame and render them all together before rendering objects of another type. You can go a step further and group all objects with the same shader but different mesh etc.

 

The other strategy (for 3D only) is depth sorting. Checking the Z-buffer and not overwriting a "nearer" pixel is supposedly much quicker than updating the framebuffer so, somewhat counter-intuitively you should render objects in near-to-far order. But are a few wasted writes to the framebuffer really slower than applying every object's MVP to its centre point and sorting? Can that be done on the GPU? I don't actually know whether GLSL variables can be uses as outputs to be read back by the CPU after running a shader, but I suspect not. And I presume that anything more complicated than sorting on centre points, ignoring whether objects overlap in XY camera space, only considerably increases pain for decreasing gain?

0

Share this post


Link to post
Share on other sites
Unfortunately, "it depends." Different hardware/drivers can have more bottlenecks in managing state changes and others can have more problems with fill rate. It also depends on your scene and how many overlapping complex surfaces you have and how many pieces of state you need to change for each draw.

In general, you should optimize for both. You can minimize buffer state changes by using fewer VBOs (you can stuff multiple objects in each VBO/IBO and then use index ranges to draw a single object out of each). You can minimize texture state changes via atlases and texture arrays. You can minimize shader state changes by using a unified shading model.

It's even quite feasible to just support both sort modes and then use the proper one for the given hardware profile. If you use the method described at http://realtimecollisiondetection.net/blog/?p=86 then you can change up how you generate your sort key based on various compile-time and run-time criteria.
0

Share this post


Link to post
Share on other sites

The first strategy is to aim to minimise the number of OpenGL state changes because they are allegedly expensive. I wouldn't have thought it would make much difference, but Mario Zechner (who wrote quite a good book about Android game development and libgdx, so I think he knows his stuff) says it can make a huge difference and advocates the use of sprite batchers for 2D rendering (where the alternative of depth sorting is irrelevant).

I am writing a book on iOS optimizations and he is quite correct in that respect.

 

The other strategy (for 3D only) is depth sorting.

This does not apply on tile-based deferred renderers such as those used in mobile devices. They already remove hidden surfaces before running the pixel shader, so sorting front-to-back literally does nothing but waste cycles (I have tested it).

 

But are a few wasted writes to the framebuffer really slower than applying every object's MVP to its center point and sorting?

Since there won’t be any wasted writes thanks to tile-based deferred rendering, you would have technically come to the correct conclusion, except that:
#1: You don’t determine the distance the object is from the camera by multiplying anything by its model-view-projection matrix, you get the distance from the camera via any of several methods involving the camera and the object’s bounding box or bounding sphere (squared distance from camera to bounding volume’s center, dot product between camera forward vector and bounding volume’s center, squared distance from the camera to the edge of the bounding sphere, etc.—take your pick).
#2: You always have to transform the bounding volume by the object’s world matrix anyway, so it’s virtually free, meaning that yes, it often makes up for overdraw, at least on systems that actually have overdraw on standard opaque renders.
 
 

And I presume that anything more complicated than sorting on center points, ignoring whether objects overlap in XY camera space, only considerably increases pain for decreasing gain?

You presume incorrectly.
Shader and texture swaps are significantly more expensive than a simple sort, especially if your sort takes advantage of frame-to-frame temporal coherency and swaps indices, not actual items.
Vertex-buffer changes are also typically offenders in performance.

And as mentioned, comparing items for the sort can be as simple as a u64 compare (or a float compare for translucent items).

Of note: You must sort translucent objects back-to-front for proper rendering. State changes be damned.  You will need to handle bounding volumes as I mentioned whether you want to or not.


L. Spiro
2

Share this post


Link to post
Share on other sites

You should combine both- and it costs nothing.

 

Order your objects by distance from observer (if observer does not move radicaly, it will involve a write free algorithm of the bubbe sort algorithm, that rarely reorders the ordered array), and even, you can stick those render objects pooled, to be neigbors in the very virtual memory for the algorithm so you will be cache lightning friendly sorter/reader/writer in a 0.5 ms.

 

Then, process this array naive way from beginning a few times over, based on shared gpu states, prior shader, then prior texture, then prior vertex buffer of them, to render "the likes" complete of scene on the shared state. Of course, examine each entity for frustum visibility while at it

1

Share this post


Link to post
Share on other sites

It's even quite feasible to just support both sort modes and then use the proper one for the given hardware profile. If you use the method described at http://realtimecollisiondetection.net/blog/?p=86 then you can change up how you generate your sort key based on various compile-time and run-time criteria.

 

Thanks. That's a useful technique. You can even put transparent and opaque objects all in the same list provided the transparency flag has the highest priority, negate the depth measurement, and change the priorities so the depth has the highest priority for transparents. But is it more optimal to have two shorter lists/"buckets" or one long one? FWIW I intend to use libgdx (which I don't think has a stock scene graph manager yet), so will most likely be using Java's Collections sort algorithm.

Edited by realh
0

Share this post


Link to post
Share on other sites

realh, on 07 Aug 2014 - 2:47 PM, said:
The other strategy (for 3D only) is depth sorting.
This does not apply on tile-based deferred renderers such as those used in mobile devices. They already remove hidden surfaces before running the pixel shader, so sorting front-to-back literally does nothing but waste cycles (I have tested it).

OK, I think it's easy enough to disable or enable that depending on whether I'm running on mobile or desktop.

 

 

 


#1: You don’t determine the distance the object is from the camera by multiplying anything by its model-view-projection matrix, you get the distance from the camera via any of several methods involving the camera and the object’s bounding box or bounding sphere (squared distance from camera to bounding volume’s center, dot product between camera forward vector and bounding volume’s center, squared distance from the camera to the edge of the bounding sphere, etc.—take your pick).
#2: You always have to transform the bounding volume by the object’s world matrix anyway, so it’s virtually free, meaning that yes, it often makes up for overdraw, at least on systems that actually have overdraw on standard opaque renders.

Good points, I'll take those into account.

 

 

 


realh, on 07 Aug 2014 - 2:47 PM, said:
And I presume that anything more complicated than sorting on center points, ignoring whether objects overlap in XY camera space, only considerably increases pain for decreasing gain?
You presume incorrectly.
Shader and texture swaps are significantly more expensive than a simple sort, especially if your sort takes advantage of frame-to-frame temporal coherency and swaps indices, not actual items.
Vertex-buffer changes are also typically offenders in performance.

I don't think I made myself clear. I wasn't ruling out sorting on state changes as well as depth sorting, but speculating as to whether it's worth using something more complicated than comparing the centres for the depth testing alone. I don't think having multiple lists depending on what objects actually overlap each other in the view would be a good idea, because some objects would be on more than one list and overcomplicate things. OTOH a simple center test may be "good enough" for opaques, but not transparents, because I've realised it's possible even for two simple triangles to overlap in the opposite order from what their centres and nearest vertex to the camera suggest. That raises another question, how do I deal with that? That probably belongs in a separate topic.

Edited by realh
0

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  
Followers 0

  • Similar Content

    • By mapra99
      Hello

      I am working on a recent project and I have been learning how to code in C# using OpenGL libraries for some graphics. I have achieved some quite interesting things using TAO Framework writing in Console Applications, creating a GLUT Window. But my problem now is that I need to incorporate the Graphics in a Windows Form so I can relate the objects that I render with some .NET Controls.

      To deal with this problem, I have seen in some forums that it's better to use OpenTK instead of TAO Framework, so I can use the glControl that OpenTK libraries offer. However, I haven't found complete articles, tutorials or source codes that help using the glControl or that may insert me into de OpenTK functions. Would somebody please share in this forum some links or files where I can find good documentation about this topic? Or may I use another library different of OpenTK?

      Thanks!
    • By Solid_Spy
      Hello, I have been working on SH Irradiance map rendering, and I have been using a GLSL pixel shader to render SH irradiance to 2D irradiance maps for my static objects. I already have it working with 9 3D textures so far for the first 9 SH functions.
      In my GLSL shader, I have to send in 9 SH Coefficient 3D Texures that use RGBA8 as a pixel format. RGB being used for the coefficients for red, green, and blue, and the A for checking if the voxel is in use (for the 3D texture solidification shader to prevent bleeding).
      My problem is, I want to knock this number of textures down to something like 4 or 5. Getting even lower would be a godsend. This is because I eventually plan on adding more SH Coefficient 3D Textures for other parts of the game map (such as inside rooms, as opposed to the outside), to circumvent irradiance probe bleeding between rooms separated by walls. I don't want to reach the 32 texture limit too soon. Also, I figure that it would be a LOT faster.
      Is there a way I could, say, store 2 sets of SH Coefficients for 2 SH functions inside a texture with RGBA16 pixels? If so, how would I extract them from inside GLSL? Let me know if you have any suggestions ^^.
    • By KarimIO
      EDIT: I thought this was restricted to Attribute-Created GL contexts, but it isn't, so I rewrote the post.
      Hey guys, whenever I call SwapBuffers(hDC), I get a crash, and I get a "Too many posts were made to a semaphore." from Windows as I call SwapBuffers. What could be the cause of this?
      Update: No crash occurs if I don't draw, just clear and swap.
      static PIXELFORMATDESCRIPTOR pfd = // pfd Tells Windows How We Want Things To Be { sizeof(PIXELFORMATDESCRIPTOR), // Size Of This Pixel Format Descriptor 1, // Version Number PFD_DRAW_TO_WINDOW | // Format Must Support Window PFD_SUPPORT_OPENGL | // Format Must Support OpenGL PFD_DOUBLEBUFFER, // Must Support Double Buffering PFD_TYPE_RGBA, // Request An RGBA Format 32, // Select Our Color Depth 0, 0, 0, 0, 0, 0, // Color Bits Ignored 0, // No Alpha Buffer 0, // Shift Bit Ignored 0, // No Accumulation Buffer 0, 0, 0, 0, // Accumulation Bits Ignored 24, // 24Bit Z-Buffer (Depth Buffer) 0, // No Stencil Buffer 0, // No Auxiliary Buffer PFD_MAIN_PLANE, // Main Drawing Layer 0, // Reserved 0, 0, 0 // Layer Masks Ignored }; if (!(hDC = GetDC(windowHandle))) return false; unsigned int PixelFormat; if (!(PixelFormat = ChoosePixelFormat(hDC, &pfd))) return false; if (!SetPixelFormat(hDC, PixelFormat, &pfd)) return false; hRC = wglCreateContext(hDC); if (!hRC) { std::cout << "wglCreateContext Failed!\n"; return false; } if (wglMakeCurrent(hDC, hRC) == NULL) { std::cout << "Make Context Current Second Failed!\n"; return false; } ... // OGL Buffer Initialization glClear(GL_DEPTH_BUFFER_BIT | GL_COLOR_BUFFER_BIT); glBindVertexArray(vao); glUseProgram(myprogram); glDrawElements(GL_TRIANGLES, indexCount, GL_UNSIGNED_SHORT, (void *)indexStart); SwapBuffers(GetDC(window_handle));  
    • By Tchom
      Hey devs!
       
      I've been working on a OpenGL ES 2.0 android engine and I have begun implementing some simple (point) lighting. I had something fairly simple working, so I tried to get fancy and added color-tinting light. And it works great... with only one or two lights. Any more than that, the application drops about 15 frames per light added (my ideal is at least 4 or 5). I know implementing lighting is expensive, I just didn't think it was that expensive. I'm fairly new to the world of OpenGL and GLSL, so there is a good chance I've written some crappy shader code. If anyone had any feedback or tips on how I can optimize this code, please let me know.
       
      Vertex Shader
      uniform mat4 u_MVPMatrix; uniform mat4 u_MVMatrix; attribute vec4 a_Position; attribute vec3 a_Normal; attribute vec2 a_TexCoordinate; varying vec3 v_Position; varying vec3 v_Normal; varying vec2 v_TexCoordinate; void main() { v_Position = vec3(u_MVMatrix * a_Position); v_TexCoordinate = a_TexCoordinate; v_Normal = vec3(u_MVMatrix * vec4(a_Normal, 0.0)); gl_Position = u_MVPMatrix * a_Position; } Fragment Shader
      precision mediump float; uniform vec4 u_LightPos["+numLights+"]; uniform vec4 u_LightColours["+numLights+"]; uniform float u_LightPower["+numLights+"]; uniform sampler2D u_Texture; varying vec3 v_Position; varying vec3 v_Normal; varying vec2 v_TexCoordinate; void main() { gl_FragColor = (texture2D(u_Texture, v_TexCoordinate)); float diffuse = 0.0; vec4 colourSum = vec4(1.0); for (int i = 0; i < "+numLights+"; i++) { vec3 toPointLight = vec3(u_LightPos[i]); float distance = length(toPointLight - v_Position); vec3 lightVector = normalize(toPointLight - v_Position); float diffuseDiff = 0.0; // The diffuse difference contributed from current light diffuseDiff = max(dot(v_Normal, lightVector), 0.0); diffuseDiff = diffuseDiff * (1.0 / (1.0 + ((1.0-u_LightPower[i])* distance * distance))); //Determine attenuatio diffuse += diffuseDiff; gl_FragColor.rgb *= vec3(1.0) / ((vec3(1.0) + ((vec3(1.0) - vec3(u_LightColours[i]))*diffuseDiff))); //The expensive part } diffuse += 0.1; //Add ambient light gl_FragColor.rgb *= diffuse; } Am I making any rookie mistakes? Or am I just being unrealistic about what I can do? Thanks in advance
    • By yahiko00
      Hi,
      Not sure to post at the right place, if not, please forgive me...
      For a game project I am working on, I would like to implement a 2D starfield as a background.
      I do not want to deal with static tiles, since I plan to slowly animate the starfield. So, I am trying to figure out how to generate a random starfield for the entire map.
      I feel that using a uniform distribution for the stars will not do the trick. Instead I would like something similar to the screenshot below, taken from the game Star Wars: Empire At War (all credits to Lucasfilm, Disney, and so on...).

      Is there someone who could have an idea of a distribution which could result in such a starfield?
      Any insight would be appreciated
  • Popular Now