after some heated discussion came up in the "what are you working on thread" about how anal one should be about shaving those tris down, I guess its better to move the topic here.

this was a presented model, its fairly low already, and has beveled edges in a fashion that allows UV mirroring, and gives nice smooth normals (therefore is good for baking and runtime interpolation).



the proposed version, while taking less tris, will have some issues on interpolation side of things. (paintover!!)




now the major issue was "less = better", which is not always right. Basically the way driver/api works, we speak about batches being the limiting factor in a single frame. That is drawcalls. The less the better, the trianglecount per batch doesnt really matter, and once certain thresholds makes no difference at all. now a very good paper explaining the sideeffects and phenomena is this paper by nvidia
http://developer.nvidia.com/docs/IO/...BatchBatch.pdf
be aware that "high-end" card was a gf5 back then, and even the gf2 was saturated at 130 tris, ie makes no difference if less triangles per batch.a slightly newer version of that paper (wow radeon9600)
http://http.download.nvidia.com/develope...ptimization.pdf
shows how basically there is no difference at all if you send 10 or 200 triangles. And this "threshold" where it doesnt matter anymore, is constantly rising (those numbers are from 2004/2005). todays engines are all about crunching as much in as little drawcalls as possible, the triangle count of single objects becomes less an issue. there is certain types of objects that are rendered using "instancing" setups or "skinning", which are supposed to have less vertices, then other stuff. but even there technical variety is just too huge.

in short, make it look good, dont go insane about taking away tris, unless you do PSP/NDS or whatever mobile, or RTS instanced units. Any modern card can crunch so many triangles that this is not the real limiting factor.

if you run the crysis sandbox editor, you will see there is some more than million tris per frame, and it runs rather smooth still (editor is quite faster than game). In EnemyTerritory the whole 3d terrain is rendered fully... what matters is the total drawcall per frame, and not just meshes but postfx and so on are part of that, yes even gui elements. A lot of limiting comes from shading the pixels, and no matter how you lowres your box will be, if texture + size on screen remains the same, the costs thru shading will be identical. The few extra vertices that need to be calculated are negligable.

There are reasons it takes crytek, epic and other guys with tons of experience to get the most out of hardware, they do a lot of performance hunting, profile how cpu/gpu are stressed at a scene. I mean Rorshach wasnt telling you guys this for no reason, after all their studio works on the real "limits", and get more out of the hardware than most. Hence some "veterans" view will surprise you, simply as they are better informed work for the "top studios". I dont want to diss anyone's opinion, its not like people made them up themselves, its just times move on very quickly. Modern cards can crunch some insane workload, but its all about the feeding mechanism...

so yes you might do some mmo which runs on every crap hardware, but even there hardware principles stay the same and looking at steam's hardware survey, there is a lot of capable hardware around...

After all this should not imply that optimization is bad, or not needed, if you can get the work done with less, and not sacrifice quality, then do it. But there is a certain level were the work/effect payoff just isnt there anymore. (this will differ for older platforms (ps2, mobiles)


----

there is another caveat so, that is the problem with "micro / thin" triangles. If you have triangles that hardly ever occupy much pixels on screen, it kills parallism of the GPU. Which should be taken into account, ie do not go overboard with micro-bevelling.

-----

make sure to read Kevin Johnstone's posts
http://boards.polycount.net/showpost...12&postcount=5

nice writeup and info here crazybutcher, but i notice you're only referring to "runtime" performance of stuff.
what about loading things into memory, or collision calculations etc.
if you have 100 duplicates of an object and it's not instanced, that is going to add up quite quickly on the memory side of things if you have extra polygons.
any more info on stuff like that rather than just brute force rendering of tris would be cool [img]/images/graemlins/smile.gif[/img]

you also have to bear in mind stencil shadows, more silhouette polys lead to greater stress there. not every engine uses lightmaps.

good thread tho [img]/images/graemlins/laugh.gif[/img]

What this translates to is that even on ancient hardware you can actually ADD polies to that box and maintain the exact same performance rendering it... which in turn means that, yes, there IS such a thing as "insignificant optimization".

Now, Ror has the brains to guard his words, but I don't, so I'll say to you earlier optimization-worshippers: When a whole bloody torrent of highly experienced professionals tell you you're wrong, maybe you should stop being so bullheaded and actually try to research the validity of your claims.

yeah mop you are right, stencil shadows are definetely ugly case where more tris = more work. But I dont think stencilshadows will have much future, personal opinion so [img]/images/graemlins/wink.gif[/img]
or if moved to GPU to do silhouette extraction the tris count will not be soooo important anymore.

loading into memory, well vertexcounts and texture memory are the limiting factor. I remember having made as similar thread once, stating that vertex weigh signficantly less,too. A triangle in stripping weighs just 4 or 2 bytes, and in non strip case three times as much.

collision is software stuff and might use dedicated lowest lod, geometry. Its a whole different story I would not want to touch, but yes here also less is better. However often dynamic objects are approximated with primitives such as boxes, spheres... to keep costs down. And static environment stuff is also fairly optimized to cope with a few more tris.

about "instancing". Engines will instance stuff anyway, I mostly meant higher-techniques that do the rendering in less drawcalls. You will always load that box into memory only once, and have a low weight representation for every time you use it (pos,rot,scale in world + handle to actual geometry). Its just that non-instanced rendering means a drwacall every time you render the box at another position.

of course you might do total unique box variatns, like mesh deformed permanently, but that would be exactly like modelling two boxes.

After all we are talking about a very optimized model already, its not like the box is 1000 tris. Its just the question that the tradeoff of quality/speed for < 300 or so, simply isnt worth it, considering the rendering pipeline.

I spent a solid few months of optimizing polys, lightmap UV channels, collish meshs for everything in UT and the act of
stripping 2million polys out of a level generally improved the FPS by 2 or 3 frames.

Polycount is not the huge issue people were rightly sure it was previously. The bigger issue now is texture resolution because all assets carry 3 textures as standard, normal map, diffuse and spec and thats before you have additional mask light textures for emmisives and reflection or whatever other stuff you are supporting in the shader.

Shader complexity is also a bigger issue now because it requires longer rendering time.
Section counts are a bigger issue , meshs carrying 2 of each texture and thus requiring a 2nd rendering pass.

I can't explain things technically enough for people but the coders have explained to me a couple times that the problem with just beating everything down with optimization on things like polycount doesn't affect things as much because of different things being CPU or GPU bound.

Mesh count is a big issue now that everything is a static mesh rather than the majority being BSP. BSP is terribly inefficient compared to mesh rendering also.

A mesh is pretty much free for the 1st 600 polys, beyond that its cost can be reduced dramatically by using lightmaps for generating self shadowing and so on rather than vertex lighting.

The reason also I was saying I wouldnt take out the horizontal spans on this piece was also largely because as an environment artist you have to be thinking about
the crimes against scale the level designers will often make
with your work to make a scene work.

Just because I know its a box , doesn't mean it wont get used as something else much larger so I always try to make sure
it can hold up, whatever it is, when 4 times the scale!

Butcher mentioned instancing, this is another feature that we relied upon much more heavily to gain performance.
Due to textures / BSP being more expensive now and polycounts cheaper we made things modular, very very modular.

For instance, I made a square 384/384 straight wall using a BSP tiling texture and generated about 60 modular lego pieces that use the same texture and all fit with themselves and each other to replace BSP shelling out of levels.

This led to lots of optimizations in general and quick easy shelling of levels and it gave our levels a baseline for
addition of new forms to the base geometry level.

I doubt I'm changing anyone's opinion here, maybe making a normal map driven next gen game will convince you though.
And by next gen, i just mean the current new technology like ID's new engine, crysis engine, UE3 etc because they
are normal map driven and the press likes fancy names
for simple progression of technology.
r.

Heh, Rorshach, in our engine you can't scale static models so everything stays the same size unless someone explicitly exports a different version of the model file [img]/images/graemlins/smile.gif[/img]

And I would expect a good level designer would know not to madly scale up an object obviously designed to be used as a small prop :/

But yes good info on all fronts, cheers guys.

I should add that triangles are stored as "indexed" lists. that means you get a huge array of all vertices, and a triangle is made from either 3 or 1 index into that array.

say for a quad your have verts = [A,B,C,D]. And now you store triangle info (index starting at 1):
as list: [1,2,3, 2,3,4]
as strip: [1,2,3, 4]

each index normally weighs as much as a half uncompressed pixel. And thats it, triangles are really just adding some more indices to that index list. And their memory is sooo tiny compared to the rest... (unless for collision stuff, or stencils, there you need per face normals as well)

The mentioned texturememory used mentioned by ror, is the one thing to really optimized for, as you can just crunch x megs of texmemory into your graphics card a frame.

The other thing that may reside in memory are static meshes. Note that static here means we dont want to change vertices individually "by hand". But we change thru shaders (bones), or thru spatial placement in total. Which is nearly all vertices we normally see on a frame. The opposite is data that is generated/manipulated more fundamentally every frame, think particles.
Now a game vertex is like 32 or 64 bytes mostly. Which means a 512x512 compressed texture gives you about 8192 "small" vertices or 4096 "fat" vertices. Their weight depends on how accurate and how much extra data you need per vertex (second UVs, vertex color...), let it be a bit less than 4k if is even fatter vertex format.

Now the third texturememory eating thing are the special effects textures, which are uncompressed and can suck up quite some megs depending on window resolution.


Now the "other" memory costs are on the application side, in regular RAM, like the collision info, and "where object x is", relationships... that memory is mostly never a big problem on PC. Just on console you need to be more clever about not loading everything into RAM. As they are more limited.

So we have X memory of what fits into the graphics card which is "texturememory" "framebuffer memory + effect textures" "static meshes" and "shaders" (which are like ultra tiny compared to rest).

Now of course say we have a giant world and want to move around, it will be impossible to preload every texture/mesh into graphicsmemory. So we must cleverly unload/load some while we move around, so noone notices. The amount we can send over without hickups is not a lot (keep in mind that the rest of your scene is still rendered). So one must be very clever about swapping out textures. Hence the modularity and "reuse", rorschach mentioned, is even more important.
not only per-frame will it allow batching of "same state" objects. but even in the long run means less swapping occurs.

now what happens if I have more active textures in the scene than my graphics card can actually load per frame. then the driver will kickin and send a cached copy over (very ugly stalls). The driver also optimizes moments when to reload stuff, as most loading from RAM to Videoram is done asynchronously (ie you call the function doesnt mean it happens right now, but you let driver do it when he wants to). So now we got the driver in the memory equation as well. Now some clever strategies the driver optimizations gurus at AMD/NVidia do might create hiccups in "non common" situations. But what is "common"? If some new major game comes out and has a very specific new way to tackle a problem, we see new drivers magically appearing making smoother rides, of course they might optimize a lot more in those drivers, but anyway...

you get a brief idea of complexity of all this, and why the most common reply on this boards regarding polycounts and whatever is "it depends"

Mop: sure, but theres always cases where they need to fill in gaps and anything will do when you can scale things.

Clearly a box prop isnt the best example, i was trying to detail a general attitude toward environment asset creation
to substitute the 'everything must go' all purpose optimization attitude.

Also another reason for extra polys in UE3 is smoothing groups. We try to use one smoothing group because it renders a better normal map.

The optimization at all costs method led me to finding out that reducing polycount and controling the smoothing with more smoothing groups costs as much as using more polys to create a better single smoothing group because
the engine doesn't actually have smoothing groups, it just doubles the edge count where the smoothing group changes.

Which costs as much or more than adding additional chamfered edges to support a cleaner smoothing group.

I still go back and forth on this issue myself but generally
the consensus at Epic is that its better to use more polys and process out a normal map that will render well with light hitting it from any angle.

If you go the purist optimization route ( as I did at the beginning of the project) and optimize with smoothing groups to control things and have half the polycount, you
end up with normals that look good only when hit by light from certain angles and its still just as expensive.

Again, I doubt anyone who has a different view is going to be changed by this information. I didn't change my
opinions until I had it reproved to me dozens of times.

r.

Yep, I totally agree that for normalmapped stuff it's way better to have some extra polys and keep a single smoothing group, than to use separate smoothing angles or groups, since as you say they pretty much amount to the same vertex memory anyway, and the former gives a better normalmap.

One of our senior programmers told me that some graphics cards can have a harder time rendering long thin tris (such as those you'd get by having thin bevels instead of smoothing groups) at long range, but I don't know to what extent or how much this would impact performance, not much it seems.

Great to see this all written down with some proper technical backing to it - while there is no excuse whatsoever to piss away polygons for the sake of using them, and those verts do add up, its ALWAYS textures, textures, textures that are the main bottleneck.

As for collision information, in most cases there is little issue with optimising that mesh down. I know we don't use the full resolution mesh for collision. In many/most cases, the LOD is used for collision. For characters its pretty much a series of boxes, because let's be honest - we might have modelled fingers and the inside of the mouth, but when it comes to collision all you care about is the hand and the head.

This bit interested me:

[ QUOTE ]
A mesh is pretty much free for the 1st 600 polys, beyond that its cost can be reduced dramatically by using lightmaps for generating self shadowing and so on rather than vertex lighting.


[/ QUOTE ]

Is that because you don't have to store that data on a per vert basis?

Originally Posted by Kevin Johnstone

I spent a solid few months of optimizing polys, lightmap UV channels, collish meshs for everything in UT and the act of
stripping 2million polys out of a level generally improved the FPS by 2 or 3 frames.

Polycount is not the huge issue people were rightly sure it was previously. The bigger issue now is texture resolution because all assets carry 3 textures as standard, normal map, diffuse and spec and thats before you have additional mask light textures for emmisives and reflection or whatever other stuff you are supporting in the shader.

Shader complexity is also a bigger issue now because it requires longer rendering time.
Section counts are a bigger issue , meshs carrying 2 of each texture and thus requiring a 2nd rendering pass.

I can't explain things technically enough for people but the coders have explained to me a couple times that the problem with just beating everything down with optimization on things like polycount doesn't affect things as much because of different things being CPU or GPU bound.

Mesh count is a big issue now that everything is a static mesh rather than the majority being BSP. BSP is terribly inefficient compared to mesh rendering also.

A mesh is pretty much free for the 1st 600 polys, beyond that its cost can be reduced dramatically by using lightmaps for generating self shadowing and so on rather than vertex lighting.

The reason also I was saying I wouldnt take out the horizontal spans on this piece was also largely because as an environment artist you have to be thinking about
the crimes against scale the level designers will often make
with your work to make a scene work.

Just because I know its a box , doesn't mean it wont get used as something else much larger so I always try to make sure
it can hold up, whatever it is, when 4 times the scale!

Butcher mentioned instancing, this is another feature that we relied upon much more heavily to gain performance.
Due to textures / BSP being more expensive now and polycounts cheaper we made things modular, very very modular.

For instance, I made a square 384/384 straight wall using a BSP tiling texture and generated about 60 modular lego pieces that use the same texture and all fit with themselves and each other to replace BSP shelling out of levels.

This led to lots of optimizations in general and quick easy shelling of levels and it gave our levels a baseline for
addition of new forms to the base geometry level.

I doubt I'm changing anyone's opinion here, maybe making a normal map driven next gen game will convince you though.
And by next gen, i just mean the current new technology like ID's new engine, crysis engine, UE3 etc because they
are normal map driven and the press likes fancy names
for simple progression of technology.
r.

DID ANYONE READ ALL THIS?! that fucking blew my mind thats so insane. all that crazy dedication, no wonder i still think UT is one of the best looking of the "next-gen" era.

Even if i come from the lowspec game dev side(wii&ds), i just can underline kevin johnstone's post. Of course you shouldn't waste polys on senseless edge loops and details, but it's the shaders and sfx, who send your performance to stop motion. To get our games on wii running 60fps our bootleneck is the shaders, which need to be simplified here an there. The vertex count is just a base issue and something comperable easy to optimize.

yes thats true, but I think it was mentioned before (I put it into first post now). Thin triangles or triangles smaller than a pixel or just a few pixels will be bad for the reasons he mentioned.

That boxmesh example here, depends of course on the size of the box "on screen". Once it's just background, or always small on screen, the bevels would be overkill, and one can live with a few minor shading artefacts.
Ie its a question of LOD and "how the model is used". If you have a game with corridors and the box will always be exposed in reasonable size, there is no reason for LOD/lower res model, as the bevel tris will be okay (unless you talk about ultra fine bevels, which always would be too thin).

I've been wanting to actually do a side by side performance comparison test and see what the impact is when dealing with a whole environment, unfortunately it requires building the environment twice. If I get round to it I'll report back!

perfect example: CoD WaW uses MODELS for their grass. not alphas.

lol wut?

The start of this thread is pretty old and I haven't spent much time keeping up to date with the cutting edge of 3d engines. Are there any big changes in the way things are done worth knowing about that haven't been mentioned in this thread?

not much should have changed, basically this is more or less a hardware / priniciple rendering issue, instead of individual 3d engine's advancements.

We are pretty much fixed to "older" hardware anyway (especially with the consoles). Imo we wont see a "real change" until the all new consoles or all new gpu systems (larrabee or whatever advanced ati/nvi gpus in years to come) are mainstream, ie a few years to go still...

And it's hard to define "mainstream" with tons of wii, iphone, psp, ds or casual Pcs having "last-gen" hardware.

No, this was simply pointing out that technology is to a point where counting every last triangle isn't really a big deal any more. This is not an excuse to do sloppy work, or to not take appropriate optimization steps, but rather to say that it's better to leave in a few bevels to make the model look better.

Thanks for the reply CB, I'm also interested in how the new shadowing meathod works and how expensive it is. (compared to stencil shadows) if you dont mind explaining

You have to render the scene's depth from the lights frustum (classic shadow mapping). But as you only require depth, this is very fast (ie mostly vertex bound).

There is numerous tweaks to enhance quality, by rendering multiple (cascaded) shadowmaps for the sun, shearing... Which will just raise the number of how often a single object might be rendered to depth.

Once the shadowmaps are created, "normal" shaders can sample them (again different methods exist, for soft shadows, remove aliasing... or whatever).

The setup for stencil shadows as such was more complicated (requiring stencil buffer, requiring volumes/silhouettes...) However for less complex geometry this is still practical as it gives you pixel-perfect shadows, while the shadowmap approach has to do more tricks to hide aliasing. Then again its better suited for soft shadows.

Shadowmapping is more pipeline friendly, as you have a real "shadow texture" to sample and therefore can do more tricks. But it needs more tweaks and advanced methods to get really nice results.

So how expensive it is, depends on the quality you want to achieve, but you can get "more" out of it then stencil. And silhouette generation for stencil stuff requires CPU (slow) interaction on pre SM4 hardware (ie the majority of hardware out there).

I am given to understand that a lot of outside-the-box coders are seriously considering a revolution in rendering. Apparently a lot of them think that the advent of multi-core processors is going to make the traditional GPU obsolete, and that the standard rendering pipeline will also be phased out in a few more years. As I understand it, the ability to mutli-thread opens up new avenues for software-based rendering, avenues that will make software based rendering comparable to, and in some cases superior to, traditional GPU-supported rendering.

Older rendering techniques that were discarded years ago are now being looked at anew. I believe there are some who are attempting to resurrect voxel rendering. It could be that in the future polygonal modeling will be rendered obsolete.

Of course, this is pure conjecture at this point. It will be years before multi-core processors are common enough to make such development financially viable. And current polygon-based tools and engines are so prevalent that such a major shift in methodolgy is sure to be slow.

Still, its probably a good time to be a C programmer.

Thanks for the replies, interesting to read.

removed the link, it was an artificial benchmark test (48 to 48 000 sided circle) to prove the adversary effect of thin triangles on performance

NOT suggesting to use certain layouts for "caps" of low poly, with so little geometry at hands interpolation artifacts are much more dominant...

Originally Posted by CrazyButcher

added this link
http://www.humus.name/index.php?page=Comments&ID=228
to the first post

illustrates how triangulation strategies affect speed. Basically shows the micro thin triangles issue vs large area triangles. Bear in mind that the "number of sides" is really high in the stats, something you will not reach in regular modelling. Ie the low numbers you work with have same performance costs, so dont redo your cylinders ;)

That was a great little read.

I guess these are issues the engine programmer needs to deal with rather than the modeler, since the modeler will supply mostly quad based geometry.

However, if you're following the workflow of reimporting high poly geometry into a modeling app (3ds max/maya) and then optimizing it, then the optimizer should perform the recursive area subdivision which is, I think, the way 3ds max does it.