Jump to content
  • Advertisement

Driv

Member
  • Content Count

    3
  • Joined

  • Last visited

Community Reputation

0 Neutral

About Driv

  • Rank
    Newbie

Personal Information

  • Interests
    Design
    Programming
  1. 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?
  2. 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?
  3. 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!
  • 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!