Home Technical Talk

In-Game Vertex Counts - useful to know?

Bek
interpolator
Offline / Send Message
Bek interpolator
Greetings,

I'm wondering how useful it would be to know the final, in game vertex count of a model - after UV and smoothing splits are calculated. From the polycount wiki I remember reading that there were apparently plugins for Max/Maya that used to calculate this thing, but they were discontinued or not distributed to the community.

So, would the ingame vertex count be useful information when optimising a mesh? While working you can certainly consider where to bevel, where to place seams etc for the lowest count, but it would be silly to try and manually calculate the final ingame count by 'hand'.

Ideally you would be able to see this count in real-time, so you could see your two vertex counts (in software and ingame) both at once. This would be a non-essential but handy tool, imo.

The reason I'm asking is because for Legend of Grimrock (the editor was released today), you have to use a custom model format. This lead to a user writing a program that imports .obj and exports to the custom .model format. However, the program is also a model viewer, and lists the real vertex count, which I found quite interesting. If you want to check it out, here's a link.

If this is a useful piece of information, why doesn't Marmoset have this info, rather than just Tri count?

tl:dr: Ingame vertex counts, useful information or insignificant?

Replies

  • Bek
    Offline / Send Message
    Bek interpolator
    Correct me if this is wrong/inaccurate, but:

    As a model gets more complex, the ingame vertex count would increase exponentially (not exactly, but you know what I mean, not in a linear way), because more verts will lie on the UV seams and so on. So, because poly/tri counts are just rough estimates anyway, doesn't this mean that the higher the polycount your budget is, the more inaccurate this estimate is? Since two meshes with high polygon counts could each have quite different performance costs, are polygon/tri counts 'unfair' or impractical on complex meshes?

    This is mostly just 'technically speaking' - practically, you're going to be making wise choices with your UV seams / smoothing groups regardless. I just find it interesting that poly/tri counts are held to such strict limits sometimes, although the difficulty of getting the real vert count mostly explains this.
  • Bek
    Offline / Send Message
    Bek interpolator
    perna wrote: »
    However, in real world cases the estimates are calculated from existing assets, not from pure mathematics, so it doesn't work out like you suggest.
    Excellent point. Interesting that a model of a lower polycount can actually be more expensive than a higher polycount model. Maybe in a more pedantic world we would not be having this discussion on the vertexcount forums :shifty:

    That thread pretty much sums up when to worry about optimisation too. What I took from it, in bullet form:

    • It's generally a bad idea to sacrifice model quality for optimisations that are probably insignificant in the big picture
    • Optimising texture memory / shader complexity is an important step
    • Keep vertex splits in mind when modelling, but don't waste time on tiny gains
    I don't know anything about tri-stripping yet, but as the thread points out I shouldn't get too caught up on the optimisation stuff, especially on relatively low poly models.
  • Bek
    Offline / Send Message
    Bek interpolator
    As a bonus question, would anyone consider listing the vertex counts (in software and in game) of models on their portfolio? If anything that would demonstrate your models efficiency more than a poly/tri count. Since no one really does though, I would assume that studios aren't too worried about this sort of thing. Looking at UV's would probably be a quicker/easier way to judge a models efficiency anyway, so it shouldn't be surprising that real vert counts aren't really used.

    Thanks for clearing all this up for me perna :D
  • Bek
    Offline / Send Message
    Bek interpolator
    Hm, that's really interesting. I did a quick calc on some simple models I have, one which I thought would be quite bad had an efficiency of 1.14, which isn't too terrible I suppose. Another which I deliberately kept reasonably optimised had an efficiency of 0.82.

    Interestingly enough a highly optimised cube (no top/bottom, 3 edges with a bevel + smoothing, the unbeveled edge with no smoothing (split normals and lies on UV seam) has a real count of 16 and a tri count of 14, giving an efficiency of ~1.143. (16/14). Although a worst case cube (24 verts 12 tris) is only a 2, because splits on smoothing and UV's don't 'stack'. As you say, to get a 3, the model would have to be single triangles.

    So a 2 is still quite a bad practical efficiency, as it's unlikely you'd even get anything > 2. It's quite interesting that efficiency can be measured in this way, It'd also be interesting to extract meshes from various games and test their efficiency. Just for curiosity's sake.
  • passerby
    Offline / Send Message
    passerby polycounter lvl 12
    optimization is like sex, if your over think it you jsut fuck it all up, do what seems right in each case, eventually you get a feel for it.

    on a serious note, just don't be wasteful with how you use your verts and tris, and wait till you actually know, what is slowing down your scene/game before doing anything too hardcore. Like why waste a ton of time on the mesh, when it is really textures or a shader dragging performance down, or vice versa.
Sign In or Register to comment.