Mathimatical techneque to work out polycounts?
polycounter lvl 18
hey guys
I rememeber on one of my intensive trainning courses in max last year being taught a mathimatical techneque which can be used to work out approximatily how many polygons i am able to use in a certain area of a model.
Only problem is I have lost my page of notes with that info on and really can't remmeber the method,any of you guys got any ideas or any methods and tips u use?
Went soemthing like:-
Resource:- 2500 polygons
model:- figure split into 3 - Head-body-legs
2500/3 = 833polys per section..... Then I remmeber using factors or equations to figue out how many polygons I can move from say the legs to the face to increase detail while still keeping the count very balanced.
unfortunatily its the eqations and factors bit im stuck at
. So anyone know how to enlighten me?
john
I rememeber on one of my intensive trainning courses in max last year being taught a mathimatical techneque which can be used to work out approximatily how many polygons i am able to use in a certain area of a model.
Only problem is I have lost my page of notes with that info on and really can't remmeber the method,any of you guys got any ideas or any methods and tips u use?
Went soemthing like:-
Resource:- 2500 polygons
model:- figure split into 3 - Head-body-legs
2500/3 = 833polys per section..... Then I remmeber using factors or equations to figue out how many polygons I can move from say the legs to the face to increase detail while still keeping the count very balanced.
unfortunatily its the eqations and factors bit im stuck at
. So anyone know how to enlighten me?john
Replies
Usually if I finish a model, and it equals the target polygon count, then I'll look at the mesh and see where detail could be removed/added to keep the distribution of polys and detail fairly consistent.
It is very arbitrary though, I don't think you can say there are hard and fast rules (like maths!) that can be applied - I reckon it's all about knowing what you're targets you're aiming for.
It works on the theory that an ingame camara for a FPS (for example) would be focused on the head and shoulders of a charcter most of the time (unless of course you have a foot fetish
but I see your point,the theory kind of goes out the window with a charcter that happens to be wearing a full bodied piece of clothing or dress or soemthing similar.
john
I guess it's tough to think in vertex terms. But the way I see it the vertex duplications affect the model's performance cost, not the number of triangles.
Though in the end it isn't that big of a deal, seems the render passes are the real bottleneck these days.
I vaguely recall a vertex counter script for max that also factored in UV splits. Hmmmm, need to search that one out.
AFAIK, a single vert can store a position, plus a single UVW coord, plus a single normal, plus a single material ID, plus a single vertex color, plus a single vertex alpha. Any attributes over that have to generate a new vert, though which attributes depends on the engine I would guess.
Also I think tri-strips may affect vertex count too, but I'm a little hazy on the details.
Would be cool to have a counter that listed the number of verts needed for each attribute and then also the total. But of course there can be a lot of sharing too, like if the UV edges are the same as the smoothing edges, etc.
An example from Provost's article...
Eric: I don't understand what you mean by, "number of verts needed for each attribute". Why would you need a certain number of verts? The way I understand it, you just try to get the lowest count possible.
I think I can also factor in triangle stripping the way I think it works. When I get some more free time I'll work on it some more.
Here's the script:
<font class="small">Code:</font><hr /><pre>obj = selection[1]
sgArr = #()
numFaces = getNumFaces obj
for i = 1 to numFaces do (
sg = getFaceSmoothGroup obj i
if findItem sgArr sg == 0 then append sgArr sg
)
totalSgVerts = 0
for i = 1 to sgArr.count do (
selFaces = #()
for ii = 1 to numFaces do (
if getFaceSmoothGroup obj ii == sgArr then append selFaces ii
)
vertArr = (meshop.getVertsUsingFace obj selFaces) as array
vertCount = vertArr.count
totalSgVerts = totalSgVerts + vertCount
)
pushPrompt ("Vert Counts - Geo:" + getNumVerts obj as string +
" UV:" + getNumtVerts obj as string +
" VC:" + getNumCpvVerts obj as string +
" SG:" + totalSgVerts as string)</pre><hr />
But your script doesn't yet provide the ultimate total, the number that's really needed, the total number of unique verts that the game has to make out of my model. Which I think would involve just what you said, figuring out which are shared.
Would it be tough to add MatID verts too?
This is really cool. Much appreciated!
One thing I was wondering, is that it seems like the article is saying that normal geometry verts really don't matter, that it's all about the verts that affect the look of the surface of the model. Whereas geometry verts just define the model itself. So should geometry verts not even be a part of this equation? I think in the end, with all the vert sharing factored in, it wouldn't make a difference, but I was just curious if game engines really "see" those verts, or just the uvs and stuff.
I'm no programmer, but from what I understand a geometry vertex (as called in 3ds max) is really just the xyz position for the uber-ingame-vertex that stores the unique data for that corner of the triangle.
So really you don't get any other data (UV, normal, etc.) without first having a position in space to stick it all in. Thus the number of geometry vertices is really the lowest uber-count you'll get.
The data in that geom vert gets duplicated only as much as is needed in order to store the multiple UV coordinates, and/or multiple normals, and/or etc. coming from that original geometry vertex. Since in-game, you only get room enough for one of each type of data in each ingame-vertex. Or at least that's the way I understand it.
It's funny, it seems any 3D app (max, maya, etc.) ultimately has to duplicate all that data too, in order to give you an accelerated real-time display. So the numbers in theory shouldn't be too hard to extract. I guess...
The numbers of each type of vert aren't hard to extract, like you said Eric. It's just figuring out which ones are shared. Max may do that internally, but I haven't seen a ready made maxScript command to get that info yet. I'm guessing I'll have to do some kind of comparison between each type of vert and see if they're associated with the same geometry vert. And if so, don't include it in the uber calculation of total verts.
Ok,so this is now kinda over my head, don't worry baout hi-jacking the thread,I take some pride in thinking ive started soemthing here
Ive never really taken into account the number of vertices I have in an object,its always been the face count ive gone by,infact ive never even been told taht vertices are acturally more important than polygons......having read this stuff I can now go to people "have ya checked ya vertex count"...."erm,polycount?"....and the *try* and exsplain and sound all big headed
But just see if I have this right,what your saying is all the mesh "information" is stored in the vertices which is acturally the thing that uses all that computer power?...polygons are just geometry(or visurals).....but if you have a triangle face,it would ahve 3 vertex points and basically for this reason people are led to belive its the "polycount" that matters over the vertex count.....right? I haven't exsplained it well...sorry guys...carry on
Just gonna try your script out fat.
john
A crude method I used to use was just to tear the model apart at the seams and extract the "actual" vertex count from there. Effective, but slow and with no finesse...getting the UV vertex count is just as effective, assuming you use no smoothing groups.
The main reason I think this might be the case is that I'm using various methods to count the total verts, and I keep coming up with the same number, which is always the largest number in the group using the original script.
But at the very least, the biggest number should give you a rough estimate of the in-game vert count, and let you know in which area to start optimizing.
I could even make it spit out a rough grade based on the ideal of a one to one relationship with the geometry verts. For example, you have a model with 1000 geometry verts, but because you were lazy and used Max's auto-unwrap feature, the uv vert count is 3000. I'd say that gets an "F". But if you were careful about uv seams and the uv vert count is only 1100, that gets an "A". (To be used for entertainment purposes only. The creator assumes no responsibilty for loss or injury caused by a failing grade.
Anyway, here's an updated version of the script which includes the Mat ID vert count.
<font class="small">Code:</font><hr /><pre>obj = selection[1]
numFaces = getNumFaces obj
-- get count for smoothing group verts
sgArr = #()
for i = 1 to numFaces do (
sg = getFaceSmoothGroup obj i
if findItem sgArr sg == 0 then append sgArr sg
)
totalSgVerts = 0
for i = 1 to sgArr.count do (
selFaces = #()
for ii = 1 to numFaces do (
if getFaceSmoothGroup obj ii == sgArr then append selFaces ii
)
vertArr = (meshop.getVertsUsingFace obj selFaces) as array
vertCount = vertArr.count
totalSgVerts = totalSgVerts + vertCount
)
-- get count for matID verts
matIdArr = #()
for i = 1 to numFaces do (
mi = getFaceMatId obj i
if findItem matIdArr mi == 0 then append matIdArr mi
)
totalmatIdVerts = 0
for i = 1 to matIdArr.count do (
selFaces = #()
for ii = 1 to numFaces do (
if getFaceMatId obj ii == matIdArr then append selFaces ii
)
vertArr = (meshop.getVertsUsingFace obj selFaces) as array
vertCount = vertArr.count
totalmatIdVerts = totalmatIdVerts + vertCount
)
-- display totals
pushPrompt ("Vert Counts - Geo:" + getNumVerts obj as string +
" UV:" + getNumtVerts obj as string +
" VC:" + getNumCpvVerts obj as string +
" SG:" + totalSgVerts as string +
" MatID:" + totalmatIdVerts as string)</pre><hr />
1. For n# UVs (b) that exist within GeomVert#1 (a), create n# uber-verts (c).
2. For n# MatIDs (d) that exist within GeomVert#1 (a), if (d) = # > (c) then create # more uber-verts. But if (d) < (c), don't create more uber-verts.
3. Repeat step 2 for each type of vertex data that's associated with (a).
4. Move on to GeomVert2 and repeat.
Does this make sense?
I don't know how programmers create usable code after working 12 hour days. I definitely can't think as well at 1:00 in the morning as I can after a good night's sleep.
Bronco: I'm glad you don't mind us going off on a tangent. And I think you've got a pretty good grasp of the basic concept of verts vs. polys.
Snowfly: If I ever get into a company that uses Maya I'll most likely start learning MelScript, and then transfer this one over. But I'm sure there are MelScripters out there that could takle this.
It's a macroscript now, so needs to be installed before using. It's called UberVertCount and can be found in the HaywoodTools category. It's been tested with versions 5, 6, and 7 and should work on editable meshes or polys.
Sample results...
Download the script
its looking pretty good!
however,Ive just been thinking about this,how exacly can this help a guy like me optermise my models as much as possible?
I ask simply becuase I have NO idea of the restrictions of game engines generally,apart from the normal "whats the polycount?" method.....Maybe im missing the point,but unless you have advanced knowledge,having worked for the company and been given direct instruction,helped to create the engine or the engine your working on is open source,I just don't see the point of knowing this stuff.
Oviously u could be aiming to help industry profesionals with this and I can see it being very very useful tool but, for the ameture,modders or guys trying to break into the industry(me) It seems pointless becuase that sort of info on the engines are generally kept as a company secret,at least until they are open source.
Though if I am wrong with the above maybe we should make a webpage that goes through the main engines and open source engines that lists its limits,I mean im sure with the artists we have on polycount finding this information out wouldn't be too difficult and im sure that would save many people a hellova lot of time and effort testing.
Keep up the good work.
john
It might help you to read these two articles. Many "secrets" are revealed, things you tend to learn on the job.
You'll find in general that there are no hard and fast numbers, usually one of the programmers or else your Lead Artist will come up with some basic polygon budgets for each model. But these are usually just guestimates, with a lot of "fudge" room tossed in. It's how the model performs in-game that really counts, and this can change from room to room, also depending on how many characters are visible at once in a gameplay situation.
Hope those articles help.
I acturally read those articles last night from your reply earlier in this thread,but it was 3am and I was damn tired so oviously did as you have suggested and missed the point
anyway having read it all again and understanding the concept and theory behind it...I still don't see how I could optermise my models any more than I am....A certain polylimit,normally pridicted by myself for most major objects anything between 2500-4000polygons with latest engines in mind....or "do as u feel best"...in the average modders language
Just curiously asking...I mean its all very well knowing the therory its wether you can put it into practice that counts
Thanks for the info anyway eric.
john
Nvidia provides a free tool for this, that can be integrated into a game engine, called ViewPerfHUD or something, don't have the link handy right now. But it's free, comes with full source code, and seems to have plenty of stats.
On the other hand, if you're at a game developer and the game is chugging, someone is going to have to go through the models and optimize them. If you're the guy that steps up and says, "I noticed these models aren't using smoothing groups effectively (for example), then you're going to be the hero. Becuase fixing smoothing groups is a lot easier than removing polys. This tool can help you see where the problem areas of a model are.
And to tell you the truth, I think most games are made without consideration to how the different properties of the model affect the vert count and how areas other than poly count can be optimized to save memory. The first reaction when the frame rate slips is to cut polys, and that's what most people do. At Treyarch, I created a tool to automatically map buildings so that they used uv strip meshing effectively. That saved a bunch of memory in game without changing the look of the models one bit. The main problem was that many of the artists didn't even know what strip meshing was and were basically face mapping the environment becuase it's faster, and that's the worst thing you can do for most engines.
By the way, has anyone tried the newest version of the script?
If possible, I'd love to have an "Update" button in the popup. This would let me make changes to the mesh then press it and get a fresh recalculation of the uber-count.
Thanks again. This is freakin' awesome!
You tried anyone from UT community,im sure UnrealED must have some way of showing these kind of counts,especially as almost verything taht goes into the engine needs to go through it.
john
I've used Unreal Ed in the past and don't remember seeing exact numbers for the various different kinds of vert counts. But then again, I wasn't looking for that exactly.
Except... when I'm forcing a surface to turn off backface-culling.
So if your script supported this (and it sure would be cool if it did!) it would actually have to query all the Standard mats' 2-sided checkboxes, then duplicate verts as needed to add to the grand total. This would be a nice thing to check in the models, to see if backfaces are killing the uber-count.
Once complication I can think of would be if two IDs are 2-sided, and they share verts along an edge, then those shared verts should only be duped once rather than double-duplicated.
But I understand this is a learning kind of project, so this might not make the cut.
Anyhow, I think you should at least put in an About rollout with contact info, and maybe a link to your site. You are looking for work after all, and scripts like this are a handy form of free publicity.
Here's some script code we've used for a url, in case you're interested. Works really well.
<font class="small">Code:</font><hr /><pre> hyperlink m_lnkWhatifInfo "http://www.whatif.info/" address:"http://www.whatif.info/" color:(color 0 0 63) hoverColor:(color 0 0 255) pos:[127,107]
</pre><hr />
Thanks again for the cool tool, very handy. BTW I liked your advice for Bronco about vert counts in actual practice. So true.
Another discrepancy that might happen is if you have unwelded uv verts that are right on top of each other. I know that can happen pretty easily in Max, but I think some game engines would be smart enough to optimize them into one vert. So you might think you have more uv verts than the engine would. But that's more engine specific, and it's better to think you're over and optimize more, than to think you're under and wonder why the framerate is dropping.
And about the About section, I always add one with contact info when I put a script on my site. And I'll be sure to do it with this one too.
Like if I used the same # of UV verts as the # of geometry verts, I would get a 100% score for my UV vert count. But the uber % score would probably be much less, because I might have used a bunch of smoothing groups or something.
So the results window might be laid out something like this...
While it's got some very good information, I can't quite grasp some things it discussed.
[ QUOTE ]
Richard Feynman, Nobel Prize winner, said the same thing about reading
scientific papers - you read it through once and get baybe 15% of the content
and skim the rest, then you go back and try again, this time getting, say, 25%.
Repeat until you understand the paper.
It happens to the best of us, and it's a side effect of researchers
brain-dumping three years worth of feeling lost and banging their head against
furniture into just the handful of pages that conference organisers allow you.
[/ QUOTE ]
So the point is, it may take a few readings to understand. It also takes some understanding of the terms that aren't explained... one thought I had was to hyperlink the terms to a glossary, kind of extend the article. We'll see if I ever get the time...
Vassago, feel free to ask.
Download the script
The URL is fine, although it's neither clickable nor copyable. To go there, I would have to search the script to copy/paste the url, or else re-type it by hand. Is there a way to make it clickable?
Great help contents, nicely thorough! I think the first bullet point might have a typo. It should read "...without affecting the overall count..."
When I try to Cancel the script, I get a "Really Cancel?" popup that won't go away, unless I press No, so it doesn't cancel. If I press Yes it keeps popping up.
Thanks again.
Download the script
HaywoodTools-UberVertCount
I tried running it recently and it seems really slow, I'll have to go back and to optimize it one of these days.
It's really the vertex count that matters. But I think we artists are just kind of stuck with a legacy triangle-count system.
I guess it's tough to think in vertex terms. But the way I see it the vertex duplications affect the model's performance cost, not the number of triangles.
[/ QUOTE ]
This is wrong. You can have many split vertices in a model and there is little performance change. The fps is affected by the number of triangles being rendered.
And the argument about number of triangles = number of vertices / 3, does not cut it. Especially when you have split seams to make sharp edges on smoothed models.
Frankly, transforming a few verts for an animated character is nothing compared to drawing the triangles for that characters and then also drawing the triangles for the whole environment.