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
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.
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.Thanks for clearing all this up for me perna
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.
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.