PDA

View Full Version : Polygon counts in MAX


Ramza24
12-06-2004, 09:18 PM
Ok, I've been confused about this for some time now, so hopefully someone can help clear this up. A polycount and a tri count are different, correct? I've been told that to get a polycount, you can either A)use the polygon counter, or B)go to File -> File Properties -> Contents and look under Faces. To get a true tri count, you convert the model to Editable Mesh, and then select it in the polygon counter. Have I been doing it right? Are there other ways to do these things? (in MAX)

Short_Fuse
12-06-2004, 09:36 PM
When working in editable mesh (tri's) and you use the inbuilt max poly counter (Shortcut 7) it will give you an accurate result. But if your working in editable poly (quads) and you use the poly counter it'll give you an inacurate result, because it is counting the quads not tri's.

Because two tri's make up a quad, double the poly count on an editable poly objects and it will give you a rough estimate of the tri count. Or convert it to editable mesh, check the poly count, then convert it back to editable poly.

Confusing yes :)

Ramza24
12-06-2004, 09:43 PM
So if someone asked you to do a model with a whatever polycount, do you tell them the tri
count or the quad count?

xno
12-06-2004, 09:51 PM
For a game model, the tri count.

Schwinnz
12-07-2004, 12:37 AM
In max 7 I believe it now displays tris AND faces in the utilities polygon counter.

Short_Fuse
12-07-2004, 03:55 AM
Just checked it out your right. In max 7 if you use the poly counter under utilities theres an option to count Triangles or Polygons, only taken 7 versions to implement too :P

Matt
12-07-2004, 09:36 AM
If you're working in Max, then the best thing to do would be to work with polys and make sure you don't have anything higher than a four sided polygon. This way, your final count will never be more than double what it says if you press '7' and use the viewport polygon counter. You should never have more than 4 sided polys anyways.

Say your model is 401 polys, 1 of which is a triangle. That means the final count will be 801 triangles, 1 less than 802, which would be your doubled figure.

If you have a poly limit on something, don't worry about counting to the final, just divide in half and work in editable polygon mode. If the model has a limit of 2000 tris, then just remember you have to stop at 1000 polygons. If you're lucky, in the end you'll have a few more to play with. If you're really lucky, you'll reach the desired look before you get to 1000.

Whoot
12-07-2004, 01:09 PM
http://www.juantwo.com/scripts/Macro_PolyCounter.zip

Counts tri count and displays is directly in your viewport.

EricChadwick
12-07-2004, 02:59 PM
Triangle counts don't matter. Vertex counts do (http://boards.polycount.net/showflat.php?Cat=0&Board=3&Number=9246&page=0&fpart=all).

MFTituS
12-07-2004, 04:49 PM
you are right, but the triangle count is a more visual value. everyone knows how a 700, 1500, model looks like, but it wouldnt be with vertices cause it depends on your uv sets, smoothing groups and some other stuff.
so itīs better to talk in triangles.....even though it isnt right :)

Matt
12-08-2004, 03:43 PM
Triangle counts don't matter. Vertex counts do (http://boards.polycount.net/showflat.php?Cat=0&Board=3&Number=9246&page=0&fpart=all).

1 triangle = 3 verts maximum.

Those verts could be shared if connected with another triangle.

A quick weld job at .01 takes care of any stray vertices, if there are any. If people have vertices not connected, then that's another problem all together.

It's like comparing the 0-60 and how many miles per gallon a car gets on the highway. Most people want to know the miles per gallon, ie, the polycount.

Telling someone it has a million vertices doesn't give them roughly anywhere near the right idea of polygons, as it could be a screwed up model with 999,900 stray verts. Unlikely, but the example fits.

EricChadwick
12-08-2004, 04:13 PM
When I talk about vertices, I'm not talking about the count you see in your modeling package. That's quite inaccurate. The vertex count in-game is what matters.

The way I understand it, 1 triangle does not always equal 3 vertices, sharing aside. In a game that's hardware-rendered (most are these days), each vertex can only hold one of each type of data... a UV coordinate, a normal, a material assignment, a vertex color, etc.

The model is typically broken up by your exporter and/or game engine into chunks. Each chunk is a set of vertices sharing the same kind of surface data. Each time you introduce a different kind of data to neighboring faces of your model, this creates a different chunk in the game. Along the edges of the chunks, the vertices are duplicated, so that each chunk has their own set of vertices for storing the chunk data. You won't see any seams along these breaks, but the model is divided just the same. The more chunks you have, the lower performance you get. This is where the in-game vertex count comes in.

Vertices are sent by the engine to your graphics hardware across the graphics bus. This is a relatively thin pipeline to move data through. The more vertices there are, the longer it takes to render each new frame in the game, since each chunk must be sent through this thin pipeline before the surface can be rendered.

There are plenty more details, and things specific to each game, but that's basically it.

I thought I might be stirring up a righteous response, since I think we're all used to dealing with triangle counts, me included. But in the end it's the in-game vertex count that affects performance, not the triangle count. I think we're just stuck with a legacy method for analyzing meshes, one that doesn't reflect the reality of how the model performs in real-time.

Most game developers still use triangle counts, so it's good to be aware of those. But the vertex count is much more important, and accurate, measurement of a model's impact.

Those two articles (http://www.cgtalk.com/showthread.php?t=187076) I posted before are well worth the read, if you're interested in how certain artistic choices can cause massive slowdowns in a game.

Waugh
12-09-2004, 01:51 PM
Good reply, :wise: EricChadwick, you summed up a lot of things in a few right words.
Thanks for that ! :)

___________________________
I believe in Stripping
___________________________

Waugh.

(ps : I'm printing out your articles. Feel like a brand new student hit by the though that maybe what he though he knew was just the emerging part of the Stuff... thanks again, this will help a lot)

EricChadwick
12-09-2004, 03:20 PM
It took me a long time to learn, hopefully I can help others by describing how it works.

Besides Guillaume Provost's two articles, I really haven't found any artist-friendly descriptions of how real-time models are rendered, so this kind of knowledge is hard to come by. Mostly I've learned it from pestering graphics programmers to explain things, or talking with technical artists.

BTW, got a response from the Art Lead at Pseudo Interactive, saying that they use those articles as part of their artist preparation workflow, and not just because Guillaume works there.

CGTalk Moderation
01-20-2006, 03:00 AM
This thread has been automatically closed as it remained inactive for 12 months. If you wish to continue the discussion, please create a new thread in the appropriate forum.