Jump to content
  • Advertisement
Driv

3D Optimizing pipeline rendering (and draw ordering / sorting)

Recommended Posts

Hi,

I am pretty new to gamedev and am toying around with my first game.

I have my own crude 3D engine I've built using Monogame. I am trying to optimize my rendering pipeline. Here's my scenario:

I have a number of 3D playing cards I want to render. The models have  front, back and side (single model made up of different mesh parts). The back is the same for a number of models being rendered. So are the sides. The front is mostly different. For my deck, I can see the front of the cards (and not the back), and for the enemy deck, I can only see only the back of his / her cards.

The card model is made up of a single set of vertices and indexes with a different start index for the different mesh parts (front, back and sides). The textures are not atlased, which allows me to easily set the front and back textures accordingly. 

To optimize rendering, I could do the following:

1. Render each card separately (which would be made of of 3 draw calls per card viz. front, back and side). Since they all share the same vertex buffer, only the textures would differ. This reduces the vertex and index buffer switches.

2. Sort by texture and render the different mesh parts separately viz. all card backs get rendered sequentially, followed by card fronts, sides etc. This will optimize texture switches, but the vertex and index buffers will keep switching since a single card has a single vertex buffer shared by 3 mesh parts viz. front, back and side.

 

I am a bit confused about which is most optimal. I would think that rendering the card in one go would be best since the vertex and index buffers are shared, but all the reading I've done thus far indicates that you should avoid texture switches, so sorting the mesh parts by texture sounds like it's the way to go, but would result in more vertex and index buffer switching.

Any advice would be appreciated!

 

 

Share this post


Link to post
Share on other sites
Advertisement

Out of Joker cards, only single two cards share a mark, do you have a diffrenet pre-set for how you texture them, what cards is it?

-do the cards overlap each other?

In such a case, you should sort by the their z depth to save rasterizer stage, secondary sort by tetxture the draw calls if even so.

Share this post


Link to post
Share on other sites

They are not traditional cards, but custom cards for a trading card game I am working on.

Yes, cards do overlap on screen. 

I am currently also sorting by Z, but it's not the highest priority at the moment (in the sort key). 

If I sort by Z first, then I am essentially rendering each card (front, back and sides) sequentially and maximizing texture switching... Isn't that supposed to be a bad thing?

Share this post


Link to post
Share on other sites

If you keep yourself under 10 switches, you are perfect, under 30 switches, you are good. Do not waste rasterizer stage by prioiring texture ordering drawing calls unless you need to chase mentioned numbers.

Share this post


Link to post
Share on other sites

Thanks for the pointers..... along these lines, I have seen in some other engines (e.g. Unity and others) that they merge / batch static meshes into one large mesh. Since these meshes would typically be at different Z's, isn't that going to impact the rasterizer stage? I considered doing that.

The other option I played around with is instancing the meshes e.g. back of the card and using texture atlasing for the instances (and setting different world coords for each instance). Is this worth the effort? 

Share this post


Link to post
Share on other sites
On 5/14/2019 at 8:53 PM, Driv said:

that they merge / batch static meshes into one large mesh. Since these meshes would typically be at different Z's, isn't that going to impact the rasterizer stage?

No, the verticies batching contains as much as it can and without vertex inputs switchings they are able to emit individual indexed draw calls to conform Z rejects.

 

On 5/14/2019 at 8:53 PM, Driv said:

The other option I played around with is instancing the meshes e.g. back of the card and using texture atlasing for the instances

If you cannot zoom-camera/scale scene, that is to force different mip-map levels to be sampled, it would be very effective to use atlased texture with minal margings. 

But the heviest operation is sampling the actual texture in rasterizer pixel shader stage, not its memory upload during switch. I have used 128x128 individual mipmapped textures with 150 swtichings on intel HD card without botllenecking actual screen framerate.

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

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!