Jump to content

  • Log In with Google      Sign In   
  • Create Account

Optimising 3D rendering order


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
6 replies to this topic

#1 realh   Members   -  Reputation: 185

Like
0Likes
Like

Posted 07 August 2014 - 07:47 AM

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?



Sponsor:

#2 SeanMiddleditch   Members   -  Reputation: 6059

Like
0Likes
Like

Posted 07 August 2014 - 11:30 AM

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.

#3 cozzie   Members   -  Reputation: 1615

Like
0Likes
Like

Posted 07 August 2014 - 11:37 AM

Personally I'd first go for one and dig deeper if your performance needs it.

#4 L. Spiro   Crossbones+   -  Reputation: 13617

Like
2Likes
Like

Posted 07 August 2014 - 04:32 PM

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
It is amazing how often people try to be unique, and yet they are always trying to make others be like them. - L. Spiro 2011
I spent most of my life learning the courage it takes to go out and get what I want. Now that I have it, I am not sure exactly what it is that I want. - L. Spiro 2013
I went to my local Subway once to find some guy yelling at the staff. When someone finally came to take my order and asked, “May I help you?”, I replied, “Yeah, I’ll have one asshole to go.”
L. Spiro Engine: http://lspiroengine.com
L. Spiro Engine Forums: http://lspiroengine.com/forums

#5 JohnnyCode   Members   -  Reputation: 230

Like
1Likes
Like

Posted 08 August 2014 - 08:43 AM

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



#6 realh   Members   -  Reputation: 185

Like
0Likes
Like

Posted 08 August 2014 - 09:21 AM

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, 08 August 2014 - 09:49 AM.


#7 realh   Members   -  Reputation: 185

Like
0Likes
Like

Posted 08 August 2014 - 09:46 AM


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, 08 August 2014 - 09:47 AM.





Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS