polygon count question

[Dageris]

Just curouis what would be considered nowadays as a low, meduim, and high poly count for games. While were at it what would that me in movies? Thanks in advance

[Ndigo]

The main characters in the PS3 game Uncharted were about 30,000 - 35,000 polygons. Uncharted is one of the best looking games out there so that should be a good indication of how far you can go with this generation of games.

Last generation, characters ranged from about 2,000 - 6,000 polygons. I guess that would be considered the absolute "low" range these days.

As far as movies go "it depends". The lead female character model in "Final Fantasy: Spirits Within" was around 420,000 polygons before adaptive rendering and about 100,000 on "extra" characters. Then again, the crocodile in "Primeval" was 4 million polygons if I'm not mistaken. Movies have more freedom with poly counts than games so I wouldn't even be to concerned with the poly count numbers as long as the mesh can be animated without problems.

[mocaw]

Once you throw displacement into the equation a lot goes out the window when it comes to movies depending esp. on which render engine type you use. Just look at the last few pirates movies with all their intense detail...

I think there are a lot more variables when dealing with film though due to the freedom- some people insist that the average "lead" characters can be as low as 30k with proper normal mapping etc. Then if you need a close up you can add displacement. That's all on a scene by scene basis too...

[mantom]

Just curouis what would be considered nowadays as a low, meduim, and high poly count for games. While were at it what would that me in movies? Thanks in advance


Depends on the game.

If the game is a two player boxing match, then the character polygon counts can be quite high because they're the only 2 characters on screen. 50,000 polygons not unreal.

If the game is an MMO, then polygon counts have to be drastically lower to account for the number of characters on screen in view. 5,000 polygons per main character may be considered high in such a case.

[iamamanami]

I have a question about polygons.

For example, triangle, tetragon, pentagon, hexagon..., each of them are regarded as one polygon, right?

My question is, if there are two characters (assume they are same in shape), one is made of 30000 triangles and the other one is made of 30000 hexagons. So, what are the differences between these two characters (e.g. in terms of storage size)?

[SebasProulx]

Jamamanami, I think the reason why it's confusing is that people are not using "polygon" correctly. Instead of "polygon", we should say "triangle". Example, a square is always made of two triangles and is even if it's only one polygon.

So, a square is twice heavier then a triangle.

[mocaw]

I'm not sure in the "normal sense" of polygon we are using it incorrectly, I'd argue that we're being too vague and are going on many assumptions. In the end it's the same problem- confusion!

Come render time, most render engines are going to slice and dice as need be to make everything a tri. When working in real-time it is my impression that you do this BEFORE sending it to render...cause you don't want to slow things down.

So yeah...I guess if you really wanted to know the "weight" of the model you'd triangulate it or look up the stats...I think this is a lot more crucial for games though than film modeling. I'm not saying that every triangle doesn't still count...just that the budget is more flexible in film and broadcast (non-realtime) rendering esp once displacement is involved.

[Bellsey]

some good points being made here.

In games, its the triangale count that's the number that most game artists will work to. Many artists, especially characters artists will work in tri's straight away, as it can be a real craft to produce a character and get the most from the budget you have to work with.

Many games tools will also have a kinda failsafe added into their data exporters that it trinagulates any polygons or 'quads' on export before being compiled and reaching the engine.

As previously mentioned, the type of game will impact the budget avaliable for models, but also the desired framerate also has to be considered. 60fps is often considered the 'gold' standard, but this has proved to be a tough ask even with the most recent consoles. The consoles are certainly capable of archieving the framerate, but like many things, there's always a cost. People expectation of the consoles being able to deliver more on screen will ultimately effect the engines ability to maintain a smooth and fast framerate to the player. Its all a question of balance.

Of course the practice of using normal maps, etc is now widely used, but even they have a budget. Using normal and AO maps will effect the texture budget with again numbers and resolutions having to be taken into consideration.

A typical budget for a racing game would be something like this:

Each car would have 5 LOD's (level of detail) models, the highest being 25-30,000 tris, the lowest would be as low as 500 tris. This would be for the exterior only with superficial bits for the interior, including a driver.
The interior would actually have its own model of 25-30,000 which would swapped in when the player switches to an interior cam.

There the would be a number of texture, normal, specular, AO maps, probably as much as 12 texture maps, with resolutions ranging from 2048x2048 to 512x512. Sometimes even as low as 256x256.

[ThE_JacO]

I'm not sure in the "normal sense" of polygon we are using it incorrectly, I'd argue that we're being too vague and are going on many assumptions. In the end it's the same problem- confusion!
Well, you kind of are.
Asking for a "polygon count" when it comes to games means you're asking a question that can result in incorrect answers.
The triangle count is all that matters, whether the trinagulation is explicit or derived from "Npolys" at some stage is irrelevant.

Come render time, most render engines are going to slice and dice as need be to make everything a tri. When working in real-time it is my impression that you do this BEFORE sending it to render...cause you don't want to slow things down.Not really.
Come render time not every renderer will make everything a tri.
Adaptive subdivision surfaces (any renderman engine and the next mray, or in limited capacity even the current mray) will first build a splines network from the poly cage and then build subdivision surfaces from that network on a per-need basis, so the ratio cage to tri is anything except fixed or easily predictable, and it doesn't really matter much anyway.

When working in real time you are most likely to triangulate explicitly at some point, not really for the expenses (which are minimal anyway), but to have a guaranteed triangulation and, in some cases, to make sure you respect stripping rules if you have any.

So yeah...I guess if you really wanted to know the "weight" of the model you'd triangulate it or look up the stats...you would actually just activate the display info in xsi, shift+S, you can get a tri count there if I remember right. XSI already triangulates internally before the ogl pipe I think.
If your trinagulation scheme is particular though then you could need to run it, although it doesn't necessarily mean committing the mesh to it, at least not for characters. For environments/levels things can change a fair bit.

I think this is a lot more crucial for games though than film modeling. I'm not saying that every triangle doesn't still count...just that the budget is more flexible in film and broadcast (non-realtime) rendering esp once displacement is involved.Correct. In film the polycount is hardly ever, if ever, determined by rendering efficiency.
Between view dependant displacement, adaptive subdivision surfaces, archives etc (especially in film where renderman engines are most prominent) the polycount hardly counts.
Cage density and topological constraints are first and foremost supposed to support look and operators, saving a few triangles hardly ever does much outside of crowds/environment work.

[kim aldis]

Jamamanami, I think the reason why it's confusing is that people are not using "polygon" correctly. Instead of "polygon", we should say "triangle".

No. You should only say 'triangle' if the polygon you're referring to has 3 sides. A triangle is a polygon, a polygon may be a triangle but only if it has 3 sides.


Example, a square is always made of two triangles and is even if it's only one polygon.


For this one you get the 'most nonsensical statement in thread' award. It's not 'always made up of two triangles'. A square may be converted into 2 triangles but a square is a square, which in this context is a polygon and is made of points and edges.

The reason for the confusion in this thread is that people are getting their mathematical definitions messed up. And this would be why precision in mathematics is important.

[kim aldis]

For example, triangle, tetragon, pentagon, hexagon..., each of them are regarded as one polygon, right?

Yes. In fact, apart from - possibly - the triangle, they're regular polygons - tetragon is a regular or equilateral triangle. The strict mathematical definition of a polygon is ' A closed plane figure with http://mathworld.wolfram.com/images/equations/Polygon/Inline1.gif sides' (mathworld)

http://www.mathopenref.com/polygon.html



My question is, if there are two characters (assume they are same in shape), one is made of 30000 triangles and the other one is made of 30000 hexagons. So, what are the differences between these two characters (e.g. in terms of storage size)?

that would depend on a number of factors. Obviously there's how any given programme stores the information; most store a list of vertices and a list of polygons, each of which is an indices into the vertex list. The polygon list is pretty fixed but the number of vertices would depend on the number of shared edges in the poly list as well as the number of polygons. Polygon data usually consists of a point count followed by the index list so a triangle data set would be bigger. But not much.

[ThE_JacO]

tetragon is a regular or equilateral triangle.
A tetragon is a quadrilateral polygon Kim.
Equilateral triangles are particularly defined as regular, but not tetragons (which translates in "four angles")

[kim aldis]

I was testing you. You passed.

(oops)

[ThE_JacO]

I was testing you. You passed.

(oops)


50 quids and I'll delete my post and let you edit yours.

[yayas]

...any renderman engine and the next mray...

It's going to be a little off topic here (cos this brief question may not deserve a new topic), does it mean the next MRay will implement micropolygon? or reyes-like, given it's now under the same roof with Gelato..

[ThE_JacO]

It's going to be a little off topic here (cos this brief question may not deserve a new topic), does it mean the next MRay will implement micropolygon? or reyes-like, given it's now under the same roof with Gelato..

Mray already has micropolygons for displacement etc.
It also already has a reyes like mode, or rather a rasterizer, which is pretty much its own engine altogether inside the main application.
It also has an implementation of adaptive subdivision surfaces, but they have severe (topological) limitations and aren't too performing.


What's coming in the next version if I remember well is catmull clark subdivision surface primitives, and I don't think gelato has much to do with it, although more contamination might very well be possible in the near future, but I expect more of it to be on the GPU front considering nVIDIA's vested interests.

[yayas]

Thanks.
((Enough for now, before I'm ruining this thread too far))

[SebasProulx]

Correct me if I'm wrong, but when I said that we should use "triangle" instead of "polygon" to know how a model is heavy, it wasn't so stupid or nonsensical ;) .

I mean, If I want to know how heavy is my mesh, i'll just turn on the "selection info" in the visibility options and i'll check how many triangles it as. I did not invent that, it's the information XSI gives me. And yes , if I have a square, XSI always tells me it has two triangles so I assume it's a little heavier then a triangle. I also assume that if XSI tells me that my mesh as 100 000 triangles, it is probably more heavy then my other mesh that as 50 000 triangles no matter how many polygons they have.

If that's not the right way to know how heavy a mesh is then, tell me what you guys do?

We don't always have to go into complicated mathematical stuff for simple questions.

[ThE_JacO]

If that's not the right way to know how heavy a mesh is then, tell me what you guys do?
Hold the mesh in one hand and a stone that I know to weight a Kilo in the other.
I like to keep it simple :)
Triangle count is fine, you're looking at it the right way.

We don't always have to go into complicated mathematical stuff for simple questions.That is an entirely different discussion.
Personally I'm in favour of not being lax with language when it comes to technicalities; lack of details and assumptions did make a lot of damage in the CG scene in general, and I believe it's in the community's best interest to make sure information is correct and detailed without exceptions (even if it becomes a time consuming and long process to post and all).
Maybe not everybody should do it, or not do it all the time, but personally I appreciate the time some people put into splitting hairs (when they know what they're saying that is).

In this particular case I got into the debate already started and just grabbed the chance to address a bunch of things all at once. As for Kim, he's old and grumpy, what did you expect? :p

[SebasProulx]

Personally I'm in favour of not being lax with language

So am I. This thread as become very interesting. But if someone gives a simple aswer, it doesn't mean it's wrong, and people can had precision if they know more about the subject.

[mocaw]

Thank you for the informative posts ThE_JacO (http://community.softimage.com/member.php?u=593), and Kim! I'm more than happy to be corrected and learn from the splitting hairs method of discussion and argumentation when it comes to "3D". Please keep it coming!

So I get that rasterizer is more reyes like in a sense...but why in the hell is it so slow on average in comparison? I know that's a generalization...but after playing with 3Delight I was left scratching my head on it. It's easier to find out info on how reyes engines work in general than mr...so any enlightenment would be cool/great/neat-O even if it slightly derails this thread.

I've read a lot of jibber jabber on message boards comparing the two...but no seemingly informed info...

And I know it isn't a motion picture production like render engine etc. but is there any part of how Zbrush renders that is reyes like? Lighting and shading a pixel vs. a polygon?!?

[ThE_JacO]

So I get that rasterizer is more reyes like in a sense...but why in the hell is it so slow on average in comparison? I know that's a generalization...but after playing with 3Delight I was left scratching my head on it. It's easier to find out info on how reyes engines work in general than mr...so any enlightenment would be cool/great/neat-O even if it slightly derails this thread.
reyes is based on a rasterizer, the rasterizer in mray isn't a reyes renderer.
As for comparing anything to 3delight that's pretty unfair. As far as reyes renderers go 3delight is by far the fastest, several orders of magnitude faster than the ever so overrated and quickly aging PRMan.

And I know it isn't a motion picture production like render engine etc. but is there any part of how Zbrush renders that is reyes like? Lighting and shading a pixel vs. a polygon?!?No not really.
There's a big difference in primitives as well. 3Delight/PRman are blazing fast and all when it comes to subdivision surfaces, and particularly excel at some things. Mray is a different beast, even the rasterizer part of it, and the way data is presented to and handled by mray doesn't exactly make the best of rasterization.
It would be a pretty long discussion to have to be honest, but I'm surprised you say you can't find much online, plenty good documentation about reyes all over the place. I'll look if I can find something to point you to.

As for zbrush, no, reyes has got nothing to do with the way zbrush renders. It would be pretty funny trying to see zbrush rendering scheme to do motion blur :)

Edit:
Ops, misread your post, you could find stuff about reyes and not MRay...
Well MRay is pretty tightly shut, reyes is public knowledge, as is the renderman standard and a number of OSS projects (like pixie) that are reyes based.
It boils down to reyes being a type of rasterization, but mray having a rasterizer based on different foundations than reyes.

I'm waiting for the next mray though before judging anything. New sds primitives and the new acceleration structures might change things on several fronts.

[mocaw]

OK, so for zbrush to even consider motion blur, each stored "pixol" would have to include translation data and another set of data/values to relate it back to it's part of the mesh it was derived from right? I know this is theoretical since, zbrush doesn't really do any animation beyond turntables and the like, I'm just wanting to understand a little more how it handles things. Kind of like that "Z born Toy" plugin for fusion and AE I take it (which I don't understand its practical function)?

http://www.taron.de/zborn/index.html

I understand that the rasterizer in mr isn't a reyes renderer. I guess to go deeper on differences for those I'll have to slowly do more of my own research and pray I can find more information on the mr side. I wish there was a chart like this for mr's rasterizer so that I could compare them in at least a rudimentary way:

http://en.wikipedia.org/wiki/Image:Reyes-pipeline.gif

But I guess that's wishful thinking, since mr is a "closed" platform and not a standard.

Thank you for entertaining my bone headed questions!

[yayas]

Out of curiosity Raff, do you see MRay is going to expand its 'rasterizer' performance in displacement and DOF to match reyes renderer? is it 'technically' possible (to get the best of both worlds)?

[ThE_JacO]

OK, so for zbrush to even consider motion blur, each stored "pixol" would have to include translation data and another set of data/values to relate it back to it's part of the mesh it was derived from right?
ZBrush does what it does because of the reduced set of data and operations it's based on.
Location on the original mesh isn't something really pertinent to the dataset, which is why things like subdivisions etc are tools (in the general sense, not as zbrush's tools) and not operators. The data that's there already used to sort and draw the canvas is already all that's needed to add moblur, but because of the way it's stored and looked up it would be interesting to see if it could render time without the memory footprint needed literally doubling or more.
[/URL]
I understand that the rasterizer in mr isn't a reyes renderer. I guess to go deeper on differences for those I'll have to slowly do more of my own research and pray I can find more information on the mr side. I wish there was a chart like this for mr's rasterizer so that I could compare them in at least a rudimentary way:

[URL]http://en.wikipedia.org/wiki/Image:Reyes-pipeline.gif (http://www.taron.de/zborn/index.html)
It would be interesting to get Halfy to post on this since he has a pretty good idea of how MRay's rasterizer works. The pipeline itself wouldn't be terribly different (if at all), a large part of why mray fails at performing like even the slowest renderman engine is still largely a matter of primitives and data-sets. If you tried to run the same scene xsi handles to mray (polys and not sds) through prman or 3delight you'd notice a considerable drop in performance in those engines too.
There's also the fact that MRay needs to be able, on demand, to run as a hybrid engine running full on raytracing calls and all on the same datasets which probably makes for the rasterizer to compromise on several levels.
Renderman engines suffer of the opposite problem when some raytracing calls are needed. Just look at how painful raytracing used to be in PRMan (up to the point where it was downright impossible unless ran as a server in not so long gone times).

If you want to play around try to get a mesh with a relatively simple cage, turn geometry approximation up (so that 3delight or affogato consider it a subdivision surface) and render it.
Then hard subdivide it a couple times but keep geo approx off and make it render as polygons.
Do that with and without raytracing a dome that's much larger than the mesh (just to make it fun for the engine to deal with the bsp or whatever acceleration structure they use).
You might be surprised by the results.
PRMan will kneel and beg you to stop when you do something like that.

Out of curiosity Raff, do you see MRay is going to expand its 'rasterizer' performance in displacement and DOF to match reyes renderer? is it 'technically' possible (to get the best of both worlds)?
It's tricky but it's not impossible.
3delight does a very good job of it (prman fails quite hard still), but it remains a fairly complex problem.
Rasterization is what it is because of the basic principles applied, the same principles make raytracing (assuming the same data structure) pretty much impossible in the same pass so a lot of trickery is needed.
A raytracer to be efficient needs an acceleration structure and is aware at all times of the whole scene, a rasterizer deals strictly with what's needed in camera for that bucket, the two things simply don't go hand in hand.
That's why a rasterizer, the moment raytracing calls are needed to shade something, needs to run additional operations that add a lot of overhead. You can be smart about it, which is what 3delight does, but you still have a fundamental discrepancy between datasets to fight with.

The net advantage rasterizers have always had in film is largely related to the fact that what they are good at has always been more important than what raytracers are good at, and when raytracing was needed it could be added as an additional (and expensive) process only toward the end or by a secondary engine or dso in a more memory efficient way.

Renderman engines also have had a longer time and narrow focus to deal with such things, MI is still relatively fresh at it, and I wouldn't be surprised if the rasterizer wasn't exactly a master-piece with a lot of space for improvement.

In theory the next version will feature a much better acceleration structure than the aging BSP present now, new primitives (which might be very rasterizer friendly) and it might already have had some contamination from the gelato team (people who know their stuff when it comes to rasterization, Larry Gritz has been an important figure for reyes renderers for the longest time). I want to see how that turns out before chalking off MRay as useless.

[yayas]

I visit Gelato site sometimes, and I get a firm impression that this is a reyes like renderer (or with my very limited knowledge about them, can I harshly say this is a renderman in disguise?). I still have no chance to try this, as XSI interface hasn't been developed yet (I heard Daniel Rind is developing it).
It's a shame that this renderer is yet to attract people. The forum is kinda dead now, though Larry Gritz himself is pretty active in the forum, and some of the developers would kindly answer questions.

With your experience, can you see it is mature enough and has a future to be a production renderer, as it has an edge over renderman, which is GPU acceleration for some tasks?

I got this link ( http://people.csail.mit.edu/jrk/lightspeed/lightspeed_preprint.pdf ) from a forum while ago, is it more or less like Gelato?

[ThE_JacO]

I visit Gelato site sometimes, and I get a firm impression that this is a reyes like renderer (or with my very limited knowledge about them, can I harshly say this is a renderman in disguise?).
It is. The main figure behind gelato is Larry Gritz, the guy who wrote BMRT, ex pixar and one of the founders of ex-luna and writers of entropy.
Doesn't get any more renderman than Larry.
Should also be noted that renderman is just a standard. Pixar's engine is called Pixar's Photorealstic Renderman.

I still have no chance to try this, as XSI interface hasn't been developed yet (I heard Daniel Rind is developing it).
Last I checked gelato could render RIB files, which you can output through affogato.

It's a shame that this renderer is yet to attract people. The forum is kinda dead now, though Larry Gritz himself is pretty active in the forum, and some of the developers would kindly answer questions.
Larry is a phenomenal person, and as down to earth as possible.
Just a couple days ago though nvidia announced gelato would become free and (although it was somewhat obscure so I might have mis-understood) support discontinued. That might mean development could stop too.
Chances are nVIDIA now wants to focus on MRay since they own MI.

With your experience, can you see it is mature enough and has a future to be a production renderer, as it has an edge over renderman, which is GPU acceleration for some tasks?
GPU acceleration kind of failed to be a benefit.
nVIDIA's idea that by 2007 everybody would have quadro cards in their renderfarm nodes was laughable, and it proved to be.
Gelato is a good product, and it's been used here and there, but I probably wouldn't risk investing time in it, especially after thursday's announcement.

I got this link ( http://people.csail.mit.edu/jrk/lightspeed/lightspeed_preprint.pdf ) from a forum while ago, is it more or less like Gelato?
Not really. Gelato is a full fledged reyes renderer that can offset part of the workload by using the GPU for certain calculations.
That paper refers to a relighting tool, which means you actually render several sets of data per frame and then you can run a limited number of operations to re-light interactively that frame.
The use of the GPU to accelerate some calculations is the only thing in common between gelato and that relighting tool suite.

[yayas]

Oops.. it's a bad news, as I start to set my sight to this renderer.
I didn't notice the news has been there in announcement. it states they will be focusing on Mental Ray, and as you said, maybe there will be some 'contamination' from Gelato team to push MR further in production.

Now it all makes sense to me to anticipate the next MR, and see how far MR can benefit from gelato's (people) technology.

[yayas]

I read Houdini rendering specs stated
"..With a strong shading language behind it and the ability to choose between micropolygon (some say it's REYES), raytracing or physically-based rendering.." ;
and Modo which also uses REYES algorithm.

I don't know how their performance (in areas like displacement, DOF, MBlur, SubD, Hair) compared to, say 3Delight or PRMan, but doesn't it mean there's a room for MR to be versatile like those renderers?

Raytracing and micropolygon things at some stage may not "go hand-in-hand", but if MR can have a strong micropolygon algorithm, would it be final puzzle to be ready in heavy production works?

Thx.

[Dageris]

Thanks guys for the responses!