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
[img]/images/graemlins/frown.gif[/img]. So anyone know how to enlighten me?

john

Hmm. Can't say I've ever done that. I just look at the model as I'm going and add/remove detail depending on the target polycount, the type of game setting (cutscenes? closeups? if so, which body parts?) it will be seen in.
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.

But the formula falls apart when you do characters with funky costume designs or non-bipeds, etc.! But it's a good idea to break down your polygon budget before modeling. Keeping the geom distribution balances is something you develop an intuition for. No maths for me...

thanks for the replies im damned if I can rember the techneque anyway,though i do know it works on a triangle system...snowfly I do belive its a aimed at charcters mainly,as other objects like guns,most objects,veicles etc would be seen all sides at the same level as the camara so the poly levels would need to be balanced anyway to keep detail consistant.

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 [img]/images/graemlins/smile.gif[/img])..and therefore thats where most detail is needed..where as the legs don't need such detail.
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

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.

EricChadwick: You're right. In 3d hardware a triangle is merely 3 indices into a list of vertices. All rotations and transforms happen on the vertex-level. A vertex can only hold one UV-pair, which means your uv-seams also contribute to the total amount of vertices processed. Same thing with normals, which means smoothing groups also increase the vertex count. I know some studios actually count vertices.

But they probably count them from within the game (or the editor), not within the modeling app I would guess. I find it kind of tough to gauge the in-game vert count from within 3ds max, for example. Sure I have a rough idea... but combining the normal splits, material splits, UV splits, etc. can change the vert count dramatically. I find I have to examine it in-game to get the true stats. Depending on the model (and # of UV sets) it can increase the count 50% to 400% or so.

Though in the end it isn't that big of a deal, seems the render passes are the real bottleneck these days.

EricChadwick: File -> Summary Info will give you the vertex counts of all objects in your scene... although it would be cool if someone scriped an addition to the Polycounter utility tool, which added a vertex-count bar...

Mop: most game engines count verts differently than Max. Smoothing group edges and uv seams will add to the vert count in a game engine, but not in Max. That's what he's having a problem with. Although, you're thinking along the right lines with scripting. It might be possible to create a script that would give the vert count that includes smoothing groups and uv's.

Ah yeah, I see. I forgot about that!

I was thinking last night about that cool display mode in Max 7 where you can see the UV edges in red in the main viewport. I think it'd be helpful to also show smoothing seams and material seams too, in different colors.

I vaguely recall a vertex counter script for max that also factored in UV splits. Hmmmm, need to search that one out.

Hmm, the one I found was written by Borislav Petrov (aka Bobo). You select UV verts and the script tells you the corresponding mesh vert #s. Not a counter really.

I should be able to whip up a script to do this. The question is, are uv verts and vertex color verts (for smoothing groups calculation) counted completely seperate from geometry verts? For example, if one geo vert is on the seam of a texture and also on the seam of a smoothing group, does it count as 5 verts or something else? If anyone know the answer, or can ask one of your programmers, that would be helpful. And also, is there any other factors in determining vertex count in a game engine?

That would be great!

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...

Here's something I did pretty quick. There's no user interface or error checking. Just make sure you have a collapsed editable mesh object selected and then run the script. Look down at the prompt area of the screen to see the results. "VC" stands for vertex color, "SG" stands for smoothing group. I can make it more user friendly if it seems useful. The next logical step would be to figure out which verts are sharing uv, color, and smoothing group seams and factor those into the count.

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[i] 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 />

Ah. Poorly phrased on my part. Your script does it already, shows the totals for each attribute.

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!

Adding MatID verts is no problem. But coming up with the grand total is going to take some time. But then again, it might be easier than I think, we'll see.

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.

FatAssasin for president! Good work on this, once you get it finished (if it's possible), I'm sure it will be a very useful script for a great many people.

Yeah, I'll second that MoP.

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. [img]/images/graemlins/wink.gif[/img]

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...

I think we officially highjacked Broncos thread. Sorry about that. [img]/images/graemlins/smile.gif[/img]

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.

LOL...as MoP said Fat-A for president.....

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 [img]/images/graemlins/smile.gif[/img].intresting reading though been following this.great learning oppotunity and all.

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 [img]/images/graemlins/wink.gif[/img].

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 [img]/images/graemlins/smile.gif[/img].

Just gonna try your script out fat.

john

FatA, great script, definitely has potential! Wish someone would write a tool like this for Maya.

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.

I've spent a couple hours creating some fairly complex functions to determine which vertices are being shared among the different vertex types, but I think I might be making this more complicated that it really is. So I need someone to either varify or disprove the following theory... the magic number we're looking for is whichever is the largest number in the various vert counts provided by the script. If that's the case, then I'm done (barring some tidying up to make it ready for the world), but if it's not the case I need to continue in the direction I was going, plus I might need to brush up more on exactly how a game engine breaks apart and then optimizes a model.

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. [img]/images/graemlins/smile.gif[/img] )

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[i] 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[i] 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 />

I think the formula needs to be something along these lines...

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) = # &gt; (c) then create # more uber-verts. But if (d) &lt; (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?

Yep, that's exactly what I'm doing. Just going from vert to vert and seeing how many alternate verts it would be split into for each different type, and then taking the largest number. And it so happens that the final number I got was the same as the largest number from the script I just posted (in this case MatID). But it might just be the particular model I was using. Now that I'm more awake I can see that different configurations of seams could produce a different final number.

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. [img]/images/graemlins/smile.gif[/img]

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.