PDA

View Full Version : Games modeling - some rules of the trade. For the newbie and for the experienced...


spm
12-29-2003, 11:05 AM
MODELING FOR GAMES

introduction

the idea for this article came up after some time of browsing around the game art forum here at cgtalk. there were a huge ammount of threads that i wanted to comment in a similar way, basically explain the same issues in every single one of them, so i thought it might be a good idea to share these thoughts formally to everyone.

so please read this and think of the matters discussed here before you post you mesh and you will have a lot for free when it comes to serious games related feedback. but ofcourse this doesnt mean these "rules" should in any way intervene in your creative process of learning and making things just for the fun of it. quality comes with experience and experience comes with making as much stuff as possible in any way one might think of it. :)

this article is mainly aimed for the individual(s) looking for more information about how to get started modeling objects, levels and characters for games. i will discuss issues that are very basic. i will not get in to things like normal mapping and pixel shading etc. also, i will not talk about the technical aspects of the whole matter because it would be too much. i want to keep this very simple and artist friendly :). however, i will try to post links for those wanting to dig into the more technical issues (if i find any good links that is).

among the things i will discuss you will find these (sometimes embedded under the topics), more fundamental parts of how to create a better mesh fr games:

- triangle stripping
- intersecting mesh
- open/closed mesh
- Z-buffer issues
- unproportional polygons

i will also approach the subjects from a worst case scenario point of view. that means im going to say we are about to use the RENDERWARE (RW) engine and make a game for the PLAYSTATION 2 (PS2). why? because i think those two are (when working on them at a default level) the nastiest of worlds to work with if youre a graphic artist. why? because they have so much limitations...

ok, here we go.

spm
12-29-2003, 11:10 AM
PART 1 - TRIANGLE STRIPPING

what is triangle stripping?

triangle strips are rows of polygons (triangles) that are continuous.

as you can see in the image (taken from http://www.sgi.com/software/opengl/advanced98/notes/node16.html) the mesh is nice and clean.

http://susi.nu/jonni/Chili/tristrips.gif

although its a VERY simple mesh in this case, every prop, weapon, character or level etc. in a game should strive to have the same architecture for optimal tri-stripping.

this can be achieved by either setting up every triangle by hand or letting the exporter for the engine handle it. the pros and cons are that if you let the exporter do it for you, you will probably lose the intended shape of the object, that is if its not totally flat or built by totally flat surfaces.

the art of tri.stripping is one of the most complicated tasks you can take on as a games modeler. the hard core stripper ;) gets into the vertex numbers and all, but thats not really necessary for most models and not may do that.

how well you do this is mostly ependent of the platform youre aiming at. for example the PS2 and the RW engine are very sensitive to good and bad tri-strips, RW beeing the least sensitive of these two. but imagine if combined as in the racing game "burn out"?

its also a relative path between good looks and tech-wise optimization. some things may afford "bad" strips, while less important stuff in a game has to weigh this up by beeing perfect.

things that cut a tri-strip are:

- geometry structure (non-continuous mesh)
- surface smoothing (hard edges, non equal normals along a surface)
- UV mapping (UV borders)
- material assignment (shader borders)
- pre-lighting (similar reason as the surface smoothing)
- world sectoring (tri-strip is broken when a world sector cuts geometry)

today most platforms are getting better and better when it comes to shuffeling polygons and the necessity of really good tri-stripping gets less important. nonetheless we arent there all the way yet so we cant ignore the fact that its better done well. ESPECIALLY when modeling for the PS2 (and probably for the PS3 in the future as well).

to illustrate a classig issue...

imagine modeling that character of yours. the usual way is to model one half and have the other mirrored. then triangulate it and you get mirrored tris everywhere... and many fans in the junction between these two halfs.

if you on the other hand tri-strip everything nicely on the "wrong" side as well you will loose the shape of the polygons you wanted. and you have a problem to solve.

the exporter only triangulates quads (i say this because every game model with faces having more corners is not acceptable), so you could still keep the main shape and triangulate these parts manually and let the exporter do the rest for you. if you dont have access to an exporter you have to make sure everything is ok by yourself.

also it is sometimes better to add some polygons to your mesh if it helps creating better strips. in that case more polygons actually give you better performance than a bad few.

spm
12-29-2003, 11:12 AM
PART 2 - intersecting mesh

intersecting mesh causes a calculation for the engine to determine which face is in front and which is on the back.

in many games you see loads of mesh going through itself or the mesh of another object. the worst case is a level where you have objects like rocks beeing just pressed into the ground through the mesh thus creating huge ammounts of useless unseen polygons and a wide range of intersections allover the camera view to be calculated and sorted.

another option is to place the rocks VERY close to the plane, but not intersecting so that they seem to be stuck in it. the drawback with this is that you COULD get errors with the Z-buffer while rendering the game, and you also get a "jagged" seam due to the fact that they are not one single object. and, you have several objects to render instead of one.

the mesh will be optimal if everything is one single object, but its as always a matter of priority and what looks good. performance vs. aesthetics.

some developers are very strict about clean meshes, some are not. its all about what you can estimate having room with performance-wise.

the quake level editor has a very neat boolean function that makes everything to a one mesh model. in 3d-software this is more difficult.

in every level-editing tool ive seen there has been a strict method by which you work. everything is based on units and snapping to these. this way you will have very precise placing of objects etc. and youre guaranteed a non intersecting environment if you snap edges and vertices according to the grids. if you for example snap the legs of a chair on a floor you get a situation where the chair is not intersecting the floor, nor is it hovering above it. they are merely infinitely close to one and other.

furthermore, intersecting mesh in a character COULD create problems when youre about to animate it. you dont want to see, for example, a hand/lower arm sticking through a sleeve just because its a separate object. and remember geometry borders cut tri-strips :)

spm
12-29-2003, 11:14 AM
PART 3 - misc. issues, tips and comments

as i said before these "rules" are not a way for me of telling people how they should proceed doing their work. they are merely my point of view of the gathered experience i have of the work made in the industry. my way of sharing the experience and the issues ive faced.

an example: in a game where you face a few characters in a limited level the rules are easily bent. but in a game in which you have to pull through loads of characters in a spectacular environment these things lets you take it to the limit and maybe add those extra characters/level details you want to make it a little extra.

the optimal mesh:

- is continuous
- doesnt have open edges
- doesnt intersect in any way
- has one shader with one texture powered by 2 (2, 4, 8, 16, 32, 64 and so on)
- is completely smoothed all over
- is not pre-lighted
- has one single UV-map
- has one single world sector if beeing a level

as you can see many of these things are impossible to make, but its all about how OPTIMAL you can make it. we dont live in a perfect world :)

ive written all this with the RW engine and the PS2 platform in mind. if you have any experience with another engine/platform, please share.

feel free to add your own comments to all this. also, im not english speaking so there might be lot of typos and forgotten topics. please let me know if something is not clear enough :)

questions will be answered.

spm
12-29-2003, 11:24 AM
PART 4 - things forgotten :)

Z-buffer:

Z-buffer issues are manifested by flickering mesh and/or sharp borders/lines running through the mesh. this could happen if two separete objects are too close to eachother and/or are intersecting. it can also happen if the transparency sorting is not working properly, hence making objects to appear in a strange order in relation to one and other.

Unproportional polygons:

imagine a perfect grid with evenly sized polygons. then add a couple of looong and very thin polygons to it. this takes away performance when the game renders.

ADDITIONAL INFO:

here i will post links over time when i find good ones.

www.gamasutra.com - a huge resource for the games artist

http://www.sgi.com/software/opengl/advanced98/notes/node16.html

Bingo Little
12-29-2003, 11:40 AM
Hi and thanks for the excellent info!

I have a question re: one of the requirements you mentioned -- that is, the completely smoothed all over mesh.

Do you mean that the less smoothing groups you have the better? I suppose the reason is the fact that when you have an edge bordering two smooth groups, its vertices are split so that when you have only one vertex in your 3D soft, you actually have two vertices after exporting, because each one will be supporting a different Vertex Normal. Does this mean that potentially you will have border edge problem here (and, consequently, a non-convex geometry because even though the two vertices will share the same global coordinates they will still be two separate ones)?

Best regards,
Bingo Little

spm
12-29-2003, 11:49 AM
Originally posted by Bingo Little
Hi and thanks for the excellent info!

I have a question re: one of the requirements you mentioned -- that is, the completely smoothed all over mesh.

Do you mean that the less smoothing groups you have the better? I suppose the reason is the fact that when you have an edge bordering two smooth groups, its vertices are split so that when you have only one vertex in your 3D soft, you actually have two vertices after exporting, because each one will be supporting a different Vertex Normal. Does this mean that potentially you will have border edge problem here (and, consequently, a non-convex geometry because even though the two vertices will share the same global coordinates they will still be two separate ones)?

Best regards,
Bingo Little

i dont really know about if the ammount of smoothing groups affect anything when exporting.

the simplest answer i would have to your question is this:

imagine a sphere with all edges totally smooth. then select a few edges and make them hard (the method is a bit different from package to package). this cuts the "would be" tri-strips over those hard edges.

but sometimes its necessary to use hard edges to get the right look to the model.

Bingo Little
12-29-2003, 12:06 PM
I've always claimed a pretty high degree of stupidity, and never hesitate to demonstrate it in public :D

I'm really sorry, but can you explain again that sentence:

"this cuts the "would be" tri-strips over those hard edges."

I just did not get the idea behind it....

And, once again, thanks A LOT for your effort!

Best,
Bingo Little

spm
12-29-2003, 12:15 PM
Originally posted by Bingo Little
I've always claimed a pretty high degree of stupidity, and never hesitate to demonstrate it in public :D

I'm really sorry, but can you explain again that sentence:

"this cuts the "would be" tri-strips over those hard edges."

I just did not get the idea behind it....

And, once again, thanks A LOT for your effort!

Best,
Bingo Little

there are no stupid questions, only bad answers or explanations :)

take that pic above in the article as an example. the mesh is all smooth and the three strips run nicely over the surface. so far so good.

now make one of the edges crossing over one of the three strips non smooth/hard. this will cut the strip in two, making it a total of four strips instead of three.

Bingo Little
12-29-2003, 12:30 PM
Originally posted by spm
there are no stupid questions, only bad answers or explanations :)



Or, as one of my professors used to say, there are no stupid questions, only stupid people asking them :D

Thanks alot, this clears it up now. I thought that each individual row of polys is a separate strip, wasn't aware that actually the whole smoothing group of poly rows is one strip.

Do you have an idea why it is like that? Do the separate strips get loaded in separate batches, or are being processed in separate batchesn and sent for rasterising?

Also, to what degree is this thing detrimental to the performance? Of course, this is asking too much, but do you have an educated guess as to how much the presence of hard edges (and, subsequently, smoothing groups) reduces the performance? Something like, say, "Each solid edge increases the rendering time of the object X with 7,6%"?

And again, the same question re: Open edges. Sometimes I intentionally leave open edges in order to save as many polygons as possible. For example (I did this model as a doodle lastSaturday night coz I couldn't fall asleep -- I have not optimised it in any way).

http://www.drone3d.co.uk/doodles/Sigismund_03.jpg

The whole model is one mesh (except the helmet), but if you look at the elbow joints and the pelvis you'll see open edges. I intentionally cut them like that without joining them to the main mesh in order to save from the invisible faces. Will it be better to put the faces there and avoid open edges, or leave it like that and save the polys?

Thanks yet once again, and please do not hesitate to tell me if I've pushed your patience to the limit.

Best,
Bingo Little

Supervlieg
12-29-2003, 12:51 PM
Yeah, Ive been checking out the site and have it bookmarked now. Excellent read!

spm
12-29-2003, 12:51 PM
Originally posted by Bingo Little
Or, as one of my professors used to say, there are no stupid questions, only stupid people asking them :D

Thanks alot, this clears it up now. I thought that each individual row of polys is a separate strip, wasn't aware that actually the whole smoothing group of poly rows is one strip.

Do you have an idea why it is like that? Do the separate strips get loaded in separate batches, or are being processed in separate batchesn and sent for rasterising?

Also, to what degree is this thing detrimental to the performance? Of course, this is asking too much, but do you have an educated guess as to how much the presence of hard edges (and, subsequently, smoothing groups) reduces the performance? Something like, say, "Each solid edge increases the rendering time of the object X with 7,6%"?

And again, the same question re: Open edges. Sometimes I intentionally leave open edges in order to save as many polygons as possible. For example (I did this model as a doodle lastSaturday night coz I couldn't fall asleep -- I have not optimised it in any way).

http://www.drone3d.co.uk/doodles/Sigismund_03.jpg

The whole model is one mesh (except the helmet), but if you look at the elbow joints and the pelvis you'll see open edges. I intentionally cut them like that without joining them to the main mesh in order to save from the invisible faces. Will it be better to put the faces there and avoid open edges, or leave it like that and save the polys?

Thanks yet once again, and please do not hesitate to tell me if I've pushed your patience to the limit.

Best,
Bingo Little

hmm... lets get technical for a moment and get us some formulas found in the "game developer" magazine june 2003 issue. i dont know if any of this answers your questions, but anyway :)

scene complexity = vertex density * texture density * visibility spectrum

transform cost = vertex count * transform complexity

transform-bound likelihood = transform cost/fill cost

fill cost = pixel coverage * draw complexity *texture density

fill-bound likelihood = fill cost / transform cost

transform-bound likelihood = vertex density

these formulas sortof describe a game gfx-wise. i dont have the energy atm to get into each one of these and explain them in detail :P

in my mind open edges are never good because they cut a potential tri-strip. i would use faces even if they are not visible to get better performance tri-strip- and otherwise. also, you could get problems when animating the model if there are open mesh in cruicial parts like the joints. and dont forget backface culling... you never know if youre going to see those "hidden" polygons :)

a guess on how much in % performance is changed due to better/worse mesh/continuity is relative to the engine youre working with and the scenery itself. you should think of it as pushing it to the limit. when you do that it starts to make a difference... and most games developers want to push it. it can make the difference between 20 characters in a squad or 40 if the difference is obvious.

for more info, check out:

http://www.sgi.com/software/opengl/advanced98/notes/node16.html

Bingo Little
12-29-2003, 01:08 PM
These formulas actually do make sense and are VERY useful!

It is only since a few months back now that I got interested in Game Art (I'm working as a 3D Artist/Animator, but I'm using hi-res/in-package-rendered models) and I find it absolutely fascinating!

I'll keep to your advise and model everything as closed as possible.

BTW, when it comes to setting up the stripes, do you manually adjust the Vertex Numbers, or do you use a special modelling technique that allows you to keep track of/keep the correct order of the Vertex Numbers?

spm
12-29-2003, 01:13 PM
Originally posted by Bingo Little
These formulas actually do make sense and are VERY useful!

It is only since a few months back now that I got interested in Game Art (I'm working as a 3D Artist/Animator, but I'm using hi-res/in-package-rendered models) and I find it absolutely fascinating!

I'll keep to your advise and model everything as closed as possible.

BTW, when it comes to setting up the stripes, do you manually adjust the Vertex Numbers, or do you use a special modelling technique that allows you to keep track of/keep the correct order of the Vertex Numbers?

im glad you found them useful.

personally i dont care about the individual vertex numbers. it would drive me insane to pay attention to and keeping track of them.

i model everything as usual, keeping in mind that i model the overall shape of my model as it should be and leave the precise triangulation of the non-triangulated faces (that are not really needed to accentuate characteristic shape of the model) to the exporter. this could in cases be parts of a stommach, back, an arm of a character or where tri-fans often occur when combining two mirrored halves of a character.

note: i dont mean that i use polygons which do not give shape to my model. every polygon should count. no waste is acceptable. but there are sometimes more or less important polygons shape-wise.

spm
12-29-2003, 02:13 PM
further examples of things:

http://susi.nu/jonni/Chili/example.gif

1. IGNORE - error by me. i truly apologise for the missleading information.

2. example of a well tri-stripped cylinder when triangulated. 3 strips. front, back and around.

3. example of a cylinder with a fan. use this when you need a pointed tip of some kind. in other cases it is very unpredictable and i dont recommend having these fans at all if possible to avoid.

EricChadwick
12-29-2003, 03:15 PM
This is really great of you to share your knowledge. I'd like to add some of my observations...

Tristripping
I haven't used Renderware, but some other game engines automate tri-stripping for you, so the artists can concentrate on other matters. Knowing about the issues does help in some situations, like with limited hardware (PS2 etc.), or an engine that doesn't automate your workflow. But these auto-strippers will mostly solve problems like the fans created with mirrored meshes. Just be aware of the trade-off... the final topology will not be the one you originally fed it.

Interpenetrations
In my experience, most other game engines do not create extra faces where objects interpenetrate. The faces are simply rendered as-is, with depth-sorting handled in various ways. Some engine-hardware combinations will use object-based sorting, others will use per-pixel z-buffer sorting, others use multiple methods. But none of the ones I have used have created new polygons at intersections. The only time I've seen this is at the edges of the view frustum for clipping purposes, and sometimes also at the near clipping plane. Does the PS2 have a very low-res zbuffer, or none at all? If so, then I can understand why RW does this.

Smoothing
Adding a hard edge can interrupt tri-stripping, but other things can also interrupt it as well, depending on your engine-hardware mix... material/smoothing/UV seams.

Some vertex info (from an earlier thread)
The number of vertices currently in view in the game affects rendering performance. All information for the model is stored in the verts, the positions and orientations of the triangles, the materials applied to them, the UVs on them, the bones affecting them, the normals (smoothing) applied to them, 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.

Vertices are sent by the engine to your graphics hardware across the system 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. There are plenty more details, and things specific to each game, but that's basically it.

Some engines store each chunk of contiguous UVs as a separate set of verts, increasing the vert count, while others don't. Generally I prefer more contiguous chunks, even if it doesn't affect vert count, since it makes painting the textures easier. If you hand a model to someone else to skin it, they prefer less chunks too.

A great couple of articles
As you metnioned spm, there were a couple great articles recently in Game Developer magazine. June and July 2003 issues, "Beautiful, Yet Friendly" by Guillaume Provost. Worth ordering the back issues, only $8 US each.
https://www.gamasutra.com/php-bin/store.php?category=22&gdmag=10
A subscription is free for developers.
The author provides some great visual examples of how to make optimal-performing models. He also talks through the issues artists encounter via the rendering pipeline... the fill-rate vs. transform-rate tradeoff. Nicely written.

An Artist's Real-Time 3D Glossary
Finally, here's an older glossary that might help game artists...
http://www.ericchadwick.com/portfolio/glossary/glossary.html
... some of the info is out-dated, but it's mostly correct.

mikkot
12-29-2003, 03:27 PM
Hi

The reason why you should use "smooth" edges as much as possible is that as soon as you have a "hard" edge, in real what happens is polygons connected to other polygons get "separated" and do not share vertexes anymore.

More hard edges you use, more memory and GPU you use.
If you can, avoid using hard edges unless your design needs it.

Ofcourse I don't mean you stop using smoothing-groups, only beeing careful, and think before yousing them :)


/Mikko

spm
12-29-2003, 03:51 PM
posm: hey! great post! i hope this thread will get sticky with loads of information concerning all things posted so far and more related to it.

spm
12-29-2003, 04:54 PM
most embarassing. i think ive misunderstood the whole intersecting mesh thing :D

all my life ive believed its the way ive described in this article, but it seems ive got it all wrong.

the calculation is NOT based on "virtual new" polygons created as i believed. instead the calculation is about sorting... which face of the two will be rendered and so on to get the right appearance. its all about performance on the pixel-level.

if im way off even here, please correct me. also it would be nice if someone would like to fill out the blanks.

im away to commit suicide... im so ashamed and i humbely apologise for my errors.

EricChadwick
12-29-2003, 05:34 PM
LOL, we've all been there. This is one of the reasons I like to post on these boards... being proven wrong is a good way to learn.

Anyhow, sorting is done differently in different setups, but the basics as I understand it are...

1. Sort objects based on their boundingbox centers.
2. Sort faces within each object according to vertex order.
3. Sort on the per-pixel level with the zbuffer.

An interesting point is that soft transparency can cause sorting discontinuities within concave surfaces. This is mostly a hardware issue… most current graphics chipsets do not support proper sorting of semi-transparent surfaces. But relying on the CPU to sort these blended surfaces is too slow. So most games just use clipmaps for transparency (not soft at all, pixels are either on or off). Hardware that uses a tile-based sort, like Dreamcast, GigaPixel, PowerVR, all avoid the problem.

zworp
12-29-2003, 11:13 PM
The interesting question is; does interpenetrations take extra calculation time, and if, how much does it slow down the rendering.
This probably varies quite a bit between hardware and engine, but some numbers would be interesting to see.

AndersEgleus
12-30-2003, 07:43 AM
Excellent thread.

I don't have anything to add, just wanted to say thanks for sharing all this invaluable info! :)

spm
12-30-2003, 08:48 AM
Originally posted by zworp
The interesting question is; does interpenetrations take extra calculation time, and if, how much does it slow down the rendering.
This probably varies quite a bit between hardware and engine, but some numbers would be interesting to see.

the fact that a calculation takes place (atleast that much im sure of atm) means it takes away performance. but as you say, it would be nice to get somekind of numbers on the screen...

POSM: you know anything about this?

zworp
12-30-2003, 10:33 AM
Originally posted by spm
the fact that a calculation takes place (atleast that much im sure of atm) means it takes away performance.

Unless it's calculated paralell to the rest of the rendering process.
(like fill and transform/lightning.)

MFTituS
12-30-2003, 11:39 AM
i have add something to the tristripping thing.
as i know you dont have to pay attention adjusting the edges on the pc.
for console it is important (performance), but only there.
i dont know why, but we never had to care for it.
by the way we work with renderware.

spm
12-30-2003, 12:18 PM
Originally posted by MFTituS
i have add something to the tristripping thing.
as i know you dont have to pay attention adjusting the edges on the pc.
for console it is important (performance), but only there.
i dont know why, but we never had to care for it.
by the way we work with renderware.

do you mean the smoothing?

MFTituS
12-30-2003, 01:10 PM
not the smoothing, the triangle strippes :)
the thing with the long rows of polygons you explained so nice in your first part.
i know from our technical director that the time you spend with turning edges to get long rows is waste for the little performance you get on pc. so we dont care how they are lieing.

EricChadwick
12-30-2003, 01:13 PM
As far as I know, interpenetrations do not affect rendering "speed." They can affect rendering "quality," like creating some z-fighting. But since no new vertices/faces are created, there is no speed hit.

zworp
12-30-2003, 02:08 PM
I did a simple test here, in this case its rarther extreme but it do show that there is performance to be gained even on a pc by having decent tristrips.

(sys spec: p4 1.8ghz, ddr333, gf4-4200, winXPro)

http://w1.236.telia.com/~u23604841/temp1/test/smooth.jpg
fps around 400

http://w1.236.telia.com/~u23604841/temp1/test/unsmooth.jpg
fps around 250

and file sizes:
http://w1.236.telia.com/~u23604841/temp1/test/filedif.jpg

the performance differens should be higher with more lights, 1 ambient and 1 directional was used.

zworp
12-30-2003, 02:14 PM
ohh and the poly count is 38700 something.

the tristrips on the better version is done by the exporter(and not very good), and on the slow version all edges were hard.

ofcourse if the tristrip is as sucky as the last pic you would be better of by using trilists.

spm
12-30-2003, 02:15 PM
could you explain more about tri-lists?

EricChadwick
12-30-2003, 02:17 PM
It seems to me that the second model has a ton more duplicated vertices than the first, because the engine is basically sending multiple verts for each hard edge. So the performance hit is a combination of having to send all those extra verts and having no strips. Or maybe I'm missing something.

zworp
12-30-2003, 02:23 PM
urh.. tri-list, well buy using trisstrips you put the vertexes inte the file as a.. chain. and in trilist you put every triangle buy it self, using 3 vertexes per triangle. erhmm.. hope you undertand some of that, I'll se if I can find a better explenation

yes, the second model has LOTS of more vertexes, thats whats tristripping is all about, using as few vertexes as possible.

thats also why lightning will be veru slow of the model since theres so many vertexes...

(okay my english isnt very good)

spm
12-30-2003, 02:27 PM
so triangle stripping is still a good thing if done well even on a PC, although its more of a must on a console.

also, imagine these planes as the polygons showing on screen in a game. now, what if youre about to push things to the limit? the difference in performance is obvoius and even on PC its better to make things right if you want to get all the way to the edge.

zworp
12-30-2003, 02:58 PM
by the way, did a similar test with the same geometry testing intersection. and I got no performance differens.
soo I think we can conlude that intersecting polys doesnt take any (or very small) extra time to render.
atleast using d3d on a gf4 card.

mikkot
12-30-2003, 03:04 PM
Why cannot I post attachments ??
Others can, but not me....
is there a setting or ?... anybody know ?


/Mikko

MFTituS
12-30-2003, 04:22 PM
hm thats strange.
i will ask a programmer the next days and post why we dont care for tristripps and whats it all about with the performance on pc with or without using it.

sorry for my crappy english....

zworp
12-30-2003, 08:39 PM
Originally posted by MFTituS
hm thats strange.
i will ask a programmer the next days and post why we dont care for tristripps and whats it all about with the performance on pc with or without using it.

sorry for my crappy english....

If you model with quads the RW-exporter will tristrip for you, (unless you disable it).
The exporters tristripping is pretty okay, It might not be worth the time and effort to do it manually.

EricChadwick
12-30-2003, 08:52 PM
I wonder if you could test the difference between a model with edges in nice rows versus a model with edges turned oddly.

Something like...

/ / / / /
/ / / / /
/ / / / /

vs.

/ \ / \ /
\ / \ / \
/ \ / \ /

I guess RW will just find the best path it can through the second model's weird edges...?

spm
12-30-2003, 09:13 PM
probably yes, but the strips wouldnt be as good as they could be. also you would probably get a lot of strips containing 3 or fewer polygons.

perhaps after new years eve zworp and i can run a couple of new tests and post some new screens :)

spm
12-30-2003, 10:28 PM
Originally posted by zworp
If you model with quads the RW-exporter will tristrip for you, (unless you disable it).
The exporters tristripping is pretty okay, It might not be worth the time and effort to do it manually.

letting the exporter do the triangulation for you may also lead to loss of shape inte the model if not beeing very careful...

zworp
12-30-2003, 10:40 PM
Originally posted by posm

I guess RW will just find the best path it can through the second model's weird edges...?

yes, I can do another test for this in a couple of days. the 2nd jan. probably.

Originally posted by spm

letting the exporter do the triangulation for you may also lead to loss of shape inte the model if not beeing very careful...

yeah, you should always triangulate all the quads that effect the shape manually.

where for example a box you can let the exporter tristrip without losing the shape.

Count0
01-02-2004, 04:57 PM
Hello, I'm new to modelling and I recently started a game character, now having problems with the hair. I have some questions about this and could use some tips. The character is supposed to have quite long hair, and I want to use alphamaps to round off the edges. I've read that intersecting mesh should be avoided, but to make the mesh in one part would leave holes where the alpha map is transparent. I'm not really sure how to make this and get a nice result. I guess this isn't much information for anyone helping me, but I can't explain it better ;)

Anyway, some advice about making hair would be appreciated :)

spm
01-02-2004, 05:24 PM
Originally posted by Count0
Hello, I'm new to modelling and I recently started a game character, now having problems with the hair. I have some questions about this and could use some tips. The character is supposed to have quite long hair, and I want to use alphamaps to round off the edges. I've read that intersecting mesh should be avoided, but to make the mesh in one part would leave holes where the alpha map is transparent. I'm not really sure how to make this and get a nice result. I guess this isn't much information for anyone helping me, but I can't explain it better ;)

Anyway, some advice about making hair would be appreciated :)

start by searching the forum for tutorials. a good place to start is here:

http://www.cgtalk.com/forumdisplay.php?s=&forumid=46

and the thing about intersecting mesh turned out not beeing as dangerous as i believed earlier, so make some planes falling down the characters shoulders with alpha maps. shouldnt be any problem. be careful though to make it animation-friendly. i mean that it dont intersect other mesh or otherwise missbehave when the model is skinned later on. it looks bad :)

Nutter
01-03-2004, 08:50 AM
To clear up the question of tristrips on the PC..

While tristrips do have a (slight) advantage in the optimal case, depending on how your engine handles them, they can also be the cause of significant speed decreases.

There are 3 ways that an engine can handle a tristrip:
1) Treat each tri-strip as an individual strip/piece of geometry, which means that there is a separate render call per strip. I'll put it bluntly: This is the absolute worst performance that you will see.
2) Chain as many tristrips together as possible with degenerate tris. What this means is that between each strip is a single triangle with 0-area (ie 2 identical verts). This allows the engine to render multiple strips in a single render call (assuming everything else is the same: texture, shader, etc).
3) Do similar to (2), except explicitly specify a "stop" at the end of each strip before starting a new strip. While this is very slightly better than (2), it is only supported by NVidia GeForce FX cards under OpenGL, not ATI and not Direct3D. In other words, it isn't of much use to most people, and even if you are working with an OpenGL engine, it's quite likely that your engine doesn't take advantage of this extension anyway.

In those screenshots that were posted of good stripping vs bad stripping, I can nearly guarantee you that it was doing (1) above. If you change that mesh to a simple tri-list instead of tri-strip, you will most likely get far better speeds than even your optimally-stripped version.
Of course this does depend on the engine you're using, but from what I can see, and assuming your engine allows you to specify tri-lists, it's what is happening.

Why is (1) the way it is? It's actually a design issue/limitation of Direct3D, which causes each render call to be very, very expensive. MS are working to reduce this issue for Longhorn, but that's of no use to anyone anyway, at least until Win2k and XP are completely dropped from our 'must support' lists. Without going into too many technical details, I'll give you a simple formula that NVidia provides programmers with quite often in their technical documents (but stated a little simpler here):
To achieve 60FPS, there can be no more than 25,000 render calls per second per GHz of CPU dedicated to invoking the rendering of meshes.
What does this mean? It means that to get 60FPS on a 1GHz CPU, if you're able to use 100% of the CPU time for rendering (ie 1GHz), you will be able to render no more than 25,000 things. In reality though, of course you may have a minimum CPU spec of lower than 1GHz, you probably won't have more than 20% of the CPU time allowed, etc.
"Things" in the (1) case are individual tri-strips. "Things" in the (2) and (3) cases is the number of joined tri-strips. "Things" for tri-lists are the number of separate textures/shaders/etc used on a model (this should be the same as (2) and (3)).

So you see that in the optimally-stripped image, it is probably actually causing hundreds of render calls, when it would only be a single render call for a tri-list.

Please remember that what I've said is very engine, PC, and D3D specific. Check with your engine team before taking this as gospel, but it is a fact for the situations that I've described.

spm
01-03-2004, 03:23 PM
nice post. important.

do you have any links to the technical aspects of tri-listing or could you tell us more about that?

zworp
01-03-2004, 03:49 PM
Thanks Nutter, that was very interesting.

Im quite sertain the examples I posted was using method number 2, creating strip-tiangles binding the tristrips togheter.

Im gonna try exporting some stuff with trilists on monday to see what performance I get.

Bingo Little
01-04-2004, 01:28 PM
OK guys,

I can't figure out why the engine will make separate calls for each tri-strip. Is the fact that when you have an edge dividing two Smoothing Groups the vertices along it are broken down to 0-area pairs/trios/etc. -- because the bordering polys will require different Vertex Normals from the said vertices? But then still we are talking about one mesh -- shouldn't it be passed for rendering in one call/batch? With engines that use OpenGL the tri-strips are not a problem at all. I can't figure out a logical reason why D3D would break down the mesh along its Smoothing groups/Tri-strips edges. Not that I am questioning what Nutter said, not at all -- I am just trying to get as much info on the gamez-specific modelling techniques as possible :D

Best wishes,
Bingo Little

zworp
01-05-2004, 11:19 AM
I did a little test with tri-list today, with the old tristrip mesh:
http://w1.236.telia.com/~u23604841/temp1/test/smooth.jpg
(around 400fps)

and the framerate with trilist using the same mesh was alot lower, ending up at about 235-240fps.

so atlest with Renderware (and d3d on gf4) tristrips work alot better.

Staffan Norling
01-06-2004, 05:46 PM
hmm...looks like each quad is forming a tri-strip in your "bad tri-srtipping example". The performance would be even worse if you triangluated it and then unsmoothed the edges (one tristrip per triangle).

The interesting part here is that the result of the tri-list test is similar to the result of the 2-tris-per-strip test.
So, if RenderWare is being used, and the modeler can create meshes with more than 2 triangles per strip (creating such crappy mesh would be hard!), the game would probably benefit from using tri-stripping...


Each tristrip does probably not cause a new render call. If that was the case, the unsmoothed plane would cause about 40000 rendercalls (if the mentioned polygon count is the quad count, and each quad forms a tristrip). It seams like Zworp is rendering almost the whole plane @ 250 fps, wich acording to nvidias formula would reqiure a computer that is way faster that 1.8 ghz...

TheWriter
01-12-2004, 10:40 AM
Well this is interresting. I have been using RW since last year, and never did get the tri-stripping thing figured out to this day, despite trying to do some research on it. Everyone person I ran into who thought they knew about it, only knew the utter basics... tri stripping = good. But not any details.

I just let RW handle the stripping. Only out of curiousity have I sometimes taken a look at it. To be honest, I do not recall someone ever asking me, "Did you optimize the tri-stripping? I think our frame rates are too low".

Well to be honest I tend to get a lot of slow frame rates, but the problem often tends to be something a little more obviouse :P

MFTituS
01-12-2004, 12:31 PM
i have asked how it works in our project and we also trust in the automatic routines of renderware.
of cource you can get better results by doing it yourself. but the biggest factor in making games is time. vertices are more important than finetuning the tristripps for a bit better performance.
it will only make sense if you need every single fps otherwise the automatic tristripping does his job good.

spm
01-12-2004, 01:32 PM
the automatic stripping is not always reliable. especially on caps and round surfaces...

zworp
01-12-2004, 01:35 PM
most of the time you dont really have to bother about the tristripping, RW does it pretty good by itself.

However sometimes it can be important to think about it.
Try to have your mesh mostly build with quads.

two cylinders:
http://w1.236.telia.com/~u23604841/temp1/test/tristrip-cylinder.gif

spm
01-12-2004, 01:36 PM
good example. this applies to a lot of other places where tri-fans occur. also, if ppl working with renderware would bother reading the manuals they would know all this pretty fast :)

gandalf_the_red
01-13-2004, 05:57 AM
The RW manuals state that fans and T-Junctions are bad. But does not get into details as to why.

spm
01-13-2004, 08:09 AM
Originally posted by gandalf_the_red
The RW manuals state that fans and T-Junctions are bad. But does not get into details as to why.

the reason why they are bad is quite obvious i think... especially when you check your strips.

TheWriter
01-13-2004, 10:02 AM
As I understand it, tri-strips allow you to CHEAT on vertx counts at the fundamental level.

TheWriter
01-13-2004, 11:29 AM
Actualy I just realized something I could have asked. Not to side track off into RW, (but there really aren't any public forms for RW so i'm asking here), if I remember right you can not make a rotational keyframe from 0 to 360 Deg. The math in the engine gets screwed up because due to the full circle effect. You must add a 180 deg keyframe to help it along. It is possible this is related to max but, I think I am pretty certain it was a RW issue. Also if you wanted to make say, a 49303 degree rotational keyframe, you ended up needing to write a whole script for it or something.

Someone prove me wrong?

spm
01-13-2004, 01:03 PM
still the power of good tri-stripping is there no matter if its "cheating" or what :)

anyhoo, yes ive got the same issue with rotations as you. i use maya so i think its a universal thing independent of software. our solution is to bake in more keys. it really doesnt do any real damage on the performance. it only takes up slightly more memory... or atleast thats what ive been told as a non-animator :)

EricChadwick
01-13-2004, 01:58 PM
Yeah, in my experience it's pretty universal, especially for real-time apps. We have to interpolate between two rotational values (keyframes) on the fly, and update the interpolation on each rendered frame. As far as I understand it, the problem occurs towards the middle of the rotation where the engine isn't sure which way to go to get to the other angle... so you see constant flipping as it tries to decide. This can be dampened down, but then you end up with some lag issues and other motion-compensation artifacts. Kind of like the effect you see with a video camera that has a filter for hand-held motion. You can really see the lag when you zoom in on something.

zworp
01-13-2004, 02:08 PM
Originally posted by TheWriter
Actualy I just realized something I could have asked. Not to side track off into RW, (but there really aren't any public forms for RW so i'm asking here), if I remember right you can not make a rotational keyframe from 0 to 360 Deg. The math in the engine gets screwed up because due to the full circle effect. You must add a 180 deg keyframe to help it along. It is possible this is related to max but, I think I am pretty certain it was a RW issue. Also if you wanted to make say, a 49303 degree rotational keyframe, you ended up needing to write a whole script for it or something.

Someone prove me wrong?

its a math issue;
0 to 360 is actually the same thing as 0 to 0 :)

instead you could animate 0 to 359...

Xaint
01-13-2004, 02:52 PM
http://picserver.student.utwente.nl/view_image.php/7BX2X23OQM/picserver.jpeg

I hope, I'm right with this one. If these two equals in render performance regarding to triangle strips, then why use hard edges (smoothing groups), when beveled edges look far better? Even with mechanics you don't have perfect sharpness, aside from blades. But you can do a miniman (even zero?) bevel, and have the edge of the blade anti-aliased this way.
Am I right?

Milotavich
01-13-2004, 07:31 PM
By request of spm, I am reposting my normal map discussion thread here. Being new, I haven't read this whole thread yet, so sorry if I'm repeating something.

>> NORMAL MAPS Hey guys, I was wondering if anyone's been working on environments with these?

I'm starting too but was wondering if anyone else really gave it much thought.

Either way Id like to talk Normals in any way. games that use it, techniques, plug ins, etc. I'm also interested in Normal vs Bumps and other hi end game environment creation techniques.

Thanks

gandalf_the_red
01-14-2004, 05:17 AM
Now I wonder. What are chances that there are enough RW users here to open up a RW forum? Last year I think maybe 1 in 500,000 of 3d modelers had even heard of it. TLately it's been picking up, and I think the ratio has drasticaly improved. Not to mention 3dsmax 6 is going to give it a lot of more pupularity this year..

zworp
01-14-2004, 08:05 AM
Originally posted by Xaint

I hope, I'm right with this one. If these two equals in render performance regarding to triangle strips,

I think the cube with more polys will take a little more time too render, eventhough it has better tristrips.

zworp
01-14-2004, 08:12 AM
A renderware forum would be really nice.

spm
01-14-2004, 08:21 AM
*double post deleted*

spm
01-14-2004, 08:21 AM
Originally posted by Milotavich
By request of spm, I am reposting my normal map discussion thread here. Being new, I haven't read this whole thread yet, so sorry if I'm repeating something.

>> NORMAL MAPS Hey guys, I was wondering if anyone's been working on environments with these?

I'm starting too but was wondering if anyone else really gave it much thought.

Either way Id like to talk Normals in any way. games that use it, techniques, plug ins, etc. I'm also interested in Normal vs Bumps and other hi end game environment creation techniques.

Thanks

perhaps this is a link to start with. i work with maya so i dont know any better atm.

http://www.drone.org/tutorials/normal_maps.html

and, for you ppl working with RENDERWARE you can now use normal maps in version 3.6... if you didnt know that.

Dargon
01-14-2004, 09:58 AM
Has anybody on here tried modeling geodesically?

(most triangles arranged in hex-shapes)

It gives much nicer rounded, organic surfaces, and for often less polies, but it throws tri-stripping out the window.

Have you tried it, what are your thoughts on it?

TheWriter
01-16-2004, 05:21 AM
As I recall T-Junctions are to be avoided at all costs. I don't think it is a speed related issue, but the fact that they result in artifacts.

Would be nice to see the mechanics behind the reason.

spm
01-16-2004, 07:53 AM
Originally posted by TheWriter
As I recall T-Junctions are to be avoided at all costs. I don't think it is a speed related issue, but the fact that they result in artifacts.

Would be nice to see the mechanics behind the reason.

the only reason i can come up with is that a t-junction will get triangulated non continuously when the mesh is exported, hence breaking tri-strips.

EricChadwick
01-16-2004, 04:09 PM
As I understand it, a T-junction is where an edge meets another edge, but one of them has a vertex in the middle, and the other edge doesn't have a corresponding vertex. This creates a crack or hole in the model.

spm
01-16-2004, 08:17 PM
Originally posted by posm
As I understand it, a T-junction is where an edge meets another edge, but one of them has a vertex in the middle, and the other edge doesn't have a corresponding vertex. This creates a crack or hole in the model.

this is one of the explanations that causes my stupid brain to evaporate :). is this a fact you can physically demonstrate, or is it a math thing? i mean, does this "hole" really occur? i know the deformation will be different from "normal" if you smooth the surface in a 3d-package... but when you export it to a game engine itll become triangulated and therefore fixed. or am i wrong?

EricChadwick
01-16-2004, 09:38 PM
Well, I'd post a pic, but my site is down right now.

Here's closest thing I could find online.
http://www.cg.tuwien.ac.at/~msh/vbspdocs/vt_trace.GIF
http://www.cg.tuwien.ac.at/~msh/vbspdocs/v_tech.html

The vertex labeled "E" is causing the t-junction. There is no corresponding vertex in face "1", so a crack can appear along the edge between C and B. To fix it, either create a new triangle BCE to fill in the crack, or remove vertex E.

Does that help? At all?

DreiGrasheir
01-16-2004, 09:58 PM
yes, that is what a t-junction is. You might not see problems in just the model alone, but if it is skinned, and vertex E has a different weight on the same bone as A, B, C, or D, a crack will most definitley form in animation. simple solution is (maya) split polygon ABC and merge the new vertex with E, or (3ds) divde Edge BC on face ABC and target weld the new vertex to E.

spm
01-17-2004, 12:53 PM
Originally posted by posm
Well, I'd post a pic, but my site is down right now.

Here's closest thing I could find online.
http://www.cg.tuwien.ac.at/~msh/vbspdocs/vt_trace.GIF
http://www.cg.tuwien.ac.at/~msh/vbspdocs/v_tech.html

The vertex labeled "E" is causing the t-junction. There is no corresponding vertex in face "1", so a crack can appear along the edge between C and B. To fix it, either create a new triangle BCE to fill in the crack, or remove vertex E.

Does that help? At all?

yep, very clear.

but doesnt an exporter create (when the model is triangulated) an edge going out from that single lone vertex to the top corner in this case?

Xaint
01-17-2004, 02:03 PM
zworp: "I think the cube with more polys will take a little more time too render, eventhough it has better tristrips."
-Could you or somebody explain this furter?

Staffan Norling
01-17-2004, 10:51 PM
Originally posted by spm
yep, very clear.

but doesnt an exporter create (when the model is triangulated) an edge going out from that single lone vertex to the top corner in this case?

Nope, there's a crack in the mesh. "1" is a triangle, not a quadrangle.

TheWriter
01-18-2004, 09:12 AM
How many RenderWare users create many different animation files for your characters/objects?

It is only common sense, to say make one dff for your object heirarchy, and maybe 4 anm files associated, one for ducking, running, jumping, etc.

I have noticed thought that RW forces you to do this by putting ALL your animations on the same timeline, and then splicing that up into different assets. Problem with this is it seems to cauase quite a few issues, with keyframes dropping out etc on me.

Another issue i've been having, is how would I turn on or off renderware's particle system, say from one asset to the next when sharing the same timeline?

spm
01-18-2004, 03:06 PM
Originally posted by Staffan Norling
Nope, there's a crack in the mesh. "1" is a triangle, not a quadrangle.

to make it clear, the exporter divides (1) into two. creating an edge connected to the lone vertex. or du you have examples of this not happening?

i have to run some tests on this tomorrow so i can get som empirics behind everything :). im not really sure about anything atm.

EricChadwick
01-19-2004, 02:32 AM
Like Staffan says, it's not a quad, so there isn't a vertex there in the triangle. Some exporters do not fix this. Only if the exporter is smart enough, then it may be able to detect an abnormality like this, and insert the needed vertex, dividing triangle 1 into two triangles. In the link, the author talks about how they fix cracks like these, by adding the needed vertex to the triangle.

Staffan Norling
01-19-2004, 08:08 AM
See example:
http://www.3dluvr.com/staffan/t-junction.mb

spm
01-19-2004, 09:09 AM
Originally posted by Staffan Norling
See example:
http://www.3dluvr.com/staffan/t-junction.mb

well, a maya file doest do the job. i can make a t-junction by my self :). you could post images of it before and after export.

Staffan Norling
01-19-2004, 10:30 AM
no, i cant. not with an outdated verision of the RW exporter that won't load....you really think that the exporter is smart enough to hande this error?

spm
01-19-2004, 12:05 PM
i ran a test on this. the result showed i had slightly misunderstood the concept of t-junctions :). i thought they only were edges ending in the middle of another... but that isnt the case.

anyway, i know the RW exporter has a fix t-junctions option. ive never tested this though because ive never encountered real t-junctions while modeling... thats probably the reason why i didnt really get the concept :P

STAFFAN: you were right. i should have checked your file :D

zworp
01-19-2004, 12:19 PM
Originally posted by Xaint
zworp: "I think the cube with more polys will take a little more time too render, eventhough it has better tristrips."
-Could you or somebody explain this furter?

okay, Ill try to explain more clearly.
normal box has 12tris
while the rounded box you posted has 20tris.

20tris probably takes longer time to render than the 12. eventhough is has better tristrips.

Im just guessing though.

Xaint
01-19-2004, 02:11 PM
Originally posted by zworp
okay, Ill try to explain more clearly.
normal box has 12tris
while the rounded box you posted has 20tris.

20tris probably takes longer time to render than the 12. eventhough is has better tristrips.

Im just guessing though.

:) You're funny! It's okay, I'll try to explain what I mean.

I may be wrong at some points, but:
1. The vertices will be calculated, so vertex number counts on speed, not polygons. I think posm said in another thread that drawing a polygon takes no more time than calculating its vertices. (I apologize if I misunderstood something or I don't remember right.)
2. Along hard edge the verices are broken, duplicated to store the different normals.
3. Since the vertices are duplicated along the hard edge, the two boxes has the same vertex count. This concludes to same render time.

I stated the question because I'm not sure about this, but this is what I've picked up. I may have misunderstood something.

zworp
01-19-2004, 04:52 PM
Okay, sorry now I see what you mean.. Interesting question

TheWriter
01-20-2004, 07:26 AM
Ok back to fans. I was going to texture a low poly soda can, and noticed my cylinder had two ends of fans. I did a simple test..

One model has the original cylinder whith fans at both ends.. and in the other I used an edit mesh modifier to remove the central verts, then used a cap modifier to cap the ends back on. If there is a flaw in that, or some kind of better method please let me know.

In anycase, here is the comparison, interrestingly the two versions have the same strip tris values, though the fanned version has 2 more polys at both ends, bring it up to a total of 4 extra polys. In any case, I think i'll dump the fanned version, not because of the extra 4 polys, but because fans tend to be too... SLOW calculating (whats a better word for this?).


P.S. I know there is another method for eliminating the fans, which involves adding a plane, with an alpha & texture map. But I would not be surprised if this even results in a slow down on some engines. Any technicians here know for sure?


http://www.highpoly3d.com/writer/screen1.png
http://www.highpoly3d.com/writer/screen2.png

spm
01-20-2004, 07:59 AM
you should cut a cylinder like nr.2 in this pic. if nothing else, its cleaner.

http://susi.nu/jonni/Chili/example.gif

EricChadwick
01-20-2004, 01:58 PM
Originally posted by Xaint
http://picserver.student.utwente.nl/view_image.php/7BX2X23OQM/picserver.jpeg

I hope, I'm right with this one. If these two equals in render performance regarding to triangle strips, then why use hard edges (smoothing groups), when beveled edges look far better?
Should be the same rendering cost, but if your engine/hardware combo is slow on fill rate, the 20-tri model may be worse. Other than that it should be the same.

Note the bad shading on the right side, from interpolated normals. If you bevel all 8 edges, it may fix this, and would still probably be the same rendering speed as if you gave the 12-triangle cube a different smoothing for each side.

Xaint
01-20-2004, 11:03 PM
Thanx posm, I was thinking the same about fill rates, it's good that you confirmed.

TheWriter: I use to work out the bottom of barrel type stuff like this. It looks better, don't know if it performs better or not. Maybe you could do a test.

http://picserver.student.utwente.nl/view_image.php/0MS357474N/picserver.jpeg

Staffan Norling
01-21-2004, 06:01 PM
Originally posted by Xaint
TheWriter: I use to work out the bottom of barrel type stuff like this. It looks better, don't know if it performs better or not. Maybe you could do a test.

http://picserver.student.utwente.nl/view_image.php/0MS357474N/picserver.jpeg

Yeah, that is probably the most optimal way of doing it.

TheWriter
01-22-2004, 07:01 AM
I think the best way to do this, is to draft up a set of models, then send them to the coders to run and clock the fps. While making sure that no media player is running in the background during those tests.

Bingo Little
01-22-2004, 09:50 AM
Hi Posm,

First off, you have a BIG thank you from me for all the info you are sharing here!

Next, I want to ask you about the Normal Interpolation you mention re: the shading above. Can you please put some more info in about this procedure? Does it involve Vertex Normals or Face Normals? is it illumination-dependent or Vertex Colour dependent?

Thanks a lot (as ever) in advance!

Best regards,
Bingo Little

EricChadwick
01-22-2004, 05:23 PM
Bingo Little, glad to help.

Vertex Normals or Face Normals? is it illumination-dependent or Vertex Colour dependent?

OK, I'll try to explain. Forgive me if this is common knowledge.

The darkening I mentioned is caused by Gouraud shading, which is often used to shade a polygonal surface in real-time, since it is usually very fast. Each triangle has three vertices, and each vertex has a normal. Each normal's brightness is varied according to how parallel it is with the light direction. The normal is "bright" when it points directly at the light, and the normal is "dark" when it points directly away from the light. The triangle is shaded simply by interpolating between the values of the three normals, in a linear gradient. When the difference in angle between the normals is great, the gradient becomes very obvious, and you get suddenly-dark areas on your model.

Bingo Little
01-22-2004, 06:02 PM
Thanks a lot again, Posm!

It is as I suspected -- the Gouraud averaged normals. I haven't seen "interpolation" used when it comes to the Vertex normal average calculation, so I got confused :) Now I can breathe more easily, initially I thought I've misunderstood the whole procedure :)

Best,
Bingo Little

TheWriter
01-23-2004, 10:45 AM
Uh oh, I wonder if we are going to switch into smoothing groups next..

Tabu_Nuf
01-26-2004, 10:40 PM
This is the best I have read for a loon loong time..
You guys rock..
Somone should take all the good stuff, put it together and put it on a site (or write a book ;) ).
Once again, thx to all of you... great reading, I have grown a bit older, and a lot smarter reading this :D

Lopoly
01-31-2004, 08:23 PM
Originally posted by zworp
A renderware forum would be really nice.

Maybe we should start Renderware forum here at cgtalk in Aplication Specific Forums!? Both, engine and its documentation are far from perfect and it would be nice to have a place to ask for help someone who is actually using a system.

TheWriter
01-31-2004, 10:35 PM
The only solution for RW issues I know of currently, is the ticket system at the criterion site.

JaMo
02-12-2004, 12:22 AM
Hi, ive been reading about tri-stripping and the other things in this post. What i dont under stand is t-junctions. I model hi-res characters and your suppose to use them to route your edge loops. When you model for games are you suppose to not use edge loops?

Also you say to not use hard edges. If im making say a hand going into a glove shouldnt you make the edge where the hand and glove meet hard so it looks to be seperate even though its the same mesh? Is there a better way?

EricChadwick
02-12-2004, 02:04 PM
What i dont under stand is t-junctions. I model hi-res characters and your suppose to use them to route your edge loops. When you model for games are you suppose to not use edge loops?T-junctions and edge-loop-terminations are not the same thing. Edge-loops are generally a good thing to preserve in a game model, since they help the deformation. The end of an edge-loop is a vertex that is shared with the next polygon (five-sided, made of three triangles). A t-junction however is when the vertex at the end of an edge doesn't connect with the next triangle... it overlays it without connecting to another vertex.

Also you say to not use hard edges. If im making say a hand going into a glove shouldnt you make the edge where the hand and glove meet hard so it looks to be seperate even though its the same mesh? Is there a better way? Hard edges are fine, but there are two common ways of accomplishing this effect... either use different normals on each side (hard smoothing)... or add another edge-loop close to the edge to make a thin set of faces along the edge, which will "harden" the normals there, but allows you to slightly soften the effect. Both methods end up being nearly the same cost in the game, since both use double the vertices of a non-hardened edge.

Does that make sense?

JaMo
02-12-2004, 05:32 PM
i think im still confused on what a t-junction is.

here is what i call an edge loop.

http://maxrovat.sns.hu/subdiv/tri_screen_2.jpg

i looked at my vert count when i did a hard edge it didnt seem to change. i use the method of putting edges real close for harder edges in highres modeling but its seems a waste of triangles for game modeling? i guess im still confused but i want to understand as i am looking for a job in the industry as a modeler.

EricChadwick
02-12-2004, 07:46 PM
Nope, that's an illustration of the termination of two edge loops (where the three quads meet in the upper right).

For t-junctions, it might help to re-examine my post at the bottom of page 5. Vertex E is the t-junction... in the image it isn't a vertex of triangle 1. E is a vertex shared by triangles 2 and 3. The triangle labeled 1 is a triangle, not a quad, it only has three vertices A, B, and C. There should be a fourth triangle using the vertices BCE, but there isn't, so this means E is a t-junction, and it can make a crack appear in-game.

Vertex count doesn't change in most modeling software when you add a hard edge... the software designers just don't show you what's going on under the hood. The vertices along the hard edge are actually duplicated to create the hard look. In a game, these duplications are typically stored as separate vertices, and the game reports it as so.

JaMo
02-12-2004, 08:15 PM
ok i understand the hard edge thing now.

what i dont under stand is how face 1 isnt considered a quad. if you run an edge to a new face doesnt the face get the vert as well? if you pull on the vert (e)of face 1 doesnt it alter it or does face 1 not move? i guess im asking is there an actuall hole in the mesh and thats the reason it has a crack? (border edge)

i hope im not bothering you with my ignorance but im always willing to learn.

EricChadwick
02-12-2004, 08:28 PM
No problem.

Yeah, there's a hole where the triangle BCE should be. Except one of the vertices (E) along the edge of the hole has been moved up against one of the triangles (1) bordering the hole. Some modeling software will let you create T-junctions, either by letting you delete triangles in the middle, or by letting you create triangles manually, or by using bad mesh optimizers, etc.

Hope that helps.

JaMo
02-12-2004, 08:35 PM
aaah! thanks for your help. i guess the reason i wasnt getting it was because id never think someone would leave a hole in their model. i learned alot from this post as id never heard of tri-stripping but now ill start to watch out for it and applying to my low res models.

thanks again.

AdamMechtley
02-13-2004, 04:48 PM
Thank you all for sharing your experiences. I understand that when you have a material, UV, or vertex normal separation, it actually generates independent vertices for the purposes of real-time. Does the same hold true for separation of vertex colours?

Example: Does the surface on the right have a higher cost than the one of the left (particularly if such separations are propagated several times, as in a pre-lighted environment).

http://cherem.org/adam_hw/vertex_colour.jpg

Thanks.

EricChadwick
02-13-2004, 09:09 PM
I don't use vertex colors, but I would imagine that's the case... I would guess that each vertex can only contain one RGB color, when it is being sent out to the graphics card for transformation. And that's where the bottleneck lies... in getting them out there.

TheWriter
02-14-2004, 02:14 AM
Vertex count doesn't change in most modeling software when you add a hard edge... the software designers just don't show you what's going on under the hood.

I just had an interresting thought. Wouldn't it be beneficial for RW to also give an EDGE count besides just polys & verts?

Vassago
02-21-2004, 04:17 PM
I'm a little bit late on catching this post, but I know EXACTLY what you mean. We are using Renderware 3.5 to develop Daredevil for PS2 and Xbox. We started out with 3.0 and continuously upgraded throughout the project. This caused the art team to get massive headaches, however. With each upgrade of Renderware, there we newer, more efficient tristrip algorithms to use. The best one (in 3.5) is TUNNEL. These continual tristrip updates made us re-build dozens of meshes, as they were now "inefficient" using the newer algorithms.
Renderware suggests that (using their viewer tools) you get a tristrip ratio of 1.5 or less for best efficiency. This ratio is calculated by dividing the number of total indicies by the number of real indicies. Here's an example shot from one of our levels:

http://digitalinfluence.net/temp/rw1.jpg

The ratio is circled in red. So according to Renderware, this level strips amazingly well. However, on export, it tells you what your quality of stripping is, via a percentage. This level in particular only has a quality of 67%. So as you can see, there is a lot of room for improvement. Overall though, it does depend on what your enviornment is and what you need to cram into it. As it was said before though, if you have a smaller enviornment (ie; a hotel lobby) you can be a lot less inefficient with stripping than if you were were making an entire city scape.
Great info, though spm - I'm sure this will help many game artists around here.

gandalf_the_red
03-14-2004, 06:14 PM
Such a good thread, yet it seems to be dying here. If I may, I have some light map issues I am delving into again lately and could get some feed back on that area.

Actually, I am quite familiar with render to texture functions, though I did try to use RenderWare to export my light maps and I guess I still don’t grasp things. I even tried to follow the RW doc on light mapping step by step but seems it just ends in disaster. For example, they claim that in 3ds Max, RW will add a Diffuse map to UV channel 1, and a duplicate to UV channel 2. But the light map should always be set for UV channel 2, so to remove the diffuse from that one or you get a duplicate?

Every time I remove the diffuse off channel 2 though from the shell material, my entire diffuse disappears in the view port and I get worse results in the visualizer. I don’t know, don’t you need two maps? One to control the lighting, and the other for the actual diffuse? I understand that. Should be a simple process.

imscifi
03-31-2004, 08:01 PM
GACK!

ok. Just as an fyi.... this thread title did post something for the "Newbie".... anything but newbie! Good greif guys. So, I'm now more confused than before. I'm looking to find out about gaming modeling and texturing. But after reading this, I'm almost afraid to ask!

So here are a few questions....

Why can't you have triangles and rectangles? or can you (from the posts, i got the feeling that you should only use triangles).

Do most games use models with subpatching on? or is it better to just model something without subpatching?

What's concidered a good # to stay under when modeling? Like for instance a head? a body and head? a tank? or are there any places on the net to find out this information? (I've been looking, but there's a lot of garbage and dead links)

Are there any refferences on how to model low poly objects?

I'm currious also about the image mapping... I always see them on a single sheet...normally with a black background. What's that all about and where do I find out more info?

Hopefully you all can give me some good info.

Thanks ahead of time!

:)

EricChadwick
04-07-2004, 02:42 PM
I can take a stab at these...

Why can't you have triangles and rectangles?
Rectangles (usually called quads) are ok in your 3d content creation program, but the model is really all triangles "under the hood." Most game engines display only triangles, so your quads will be triangulated on export. Thus although it may be easier to model using quads, you should triangulate it yourself before export, to fix any of the triangle edges that may not be the way you want them.

Do most games use models with subpatching on?
Do you mean subdivision surfaces? Many game modelers use this method of modeling to quickly increase the resolution of a model (usually quadrupling the triangle count for each subdivision level) before exporting it to the game. However, some games will auto-subdivide using hardware acceleration, so the game takes the low-res mesh and increases triangle count to smooth the surface. Some hardware subdivides using patches instead of subdivision surfaces... similar results, different methods.

What's concidered a good # to stay under when modeling?
Totally depends on the engine, and also on how each model is used. Basically, model as low-res as possible. But each game is different. Do some searches, this question gets asked a lot here...
http://dynamic.gamespy.com/~polycount/ubb/forumdisplay.cgi?action=topics&forum=2D+and+3D+Discussion&number=8

Are there any refferences on how to model low poly objects?
I find these WIP forums a good source of info. Look at the wireframes posted by the more experienced modelers... the ones working in the industry already are good ones to study. Off the top of my head, I like Bobo the Seal's work.
http://www.bobotheseal.com/
Here are a couple other forums with good game modelers showing their work...
http://dynamic.gamespy.com/~polycount/ubb/forumdisplay.cgi?action=topics&forum=Pimping+and+Previews&number=2&DaysPrune=10&LastLogin=
http://www.cgchat.com/forum/forumdisplay.php?forumid=58

I'm currious also about the image mapping... I always see them on a single sheet
I call it texture packing. Nvidia had a recent talk about this at GDC, they call it a Texture Atlas. Look here for the paper titled "Optimization for DirectX 9 Graphics"...
http://developer.nvidia.com/object/gdc_2004_presentations.html
Basically, you want to stick as many textures as possible into one texture, by packing them in close together. The textures you choose to pack together should be for surfaces that will be seen together often in-game. This packing can greatly increase performance, since the video card doesn't have to keep loading and unloadin lots of little textures again and again as objects appear/disappear from view.

Using black backgrounds around the textures is NOT a good idea, typically a newbie method, I guess since the texture sheet is more visually appealing this way. But in-game, the texture is resized multiple times to make "mips," smaller versions of the texture that help reduce aliasing in-game as the surface gets farther away. When it is resized down, the black starts to bleed into the texture area, so you get black halos on your models as they recede. Not good. Best to fill the unused texture space with colors similar to the used areas, then when scaled it won't be so obvious.

That's about all I can type right now. Hope this helps. There's a lot to learn, isn't there? ;)

Tahl'eN
06-12-2004, 07:28 AM
Ok, this seems the propper forum to ask this question: I'm working on optomizing an older model of mine, and I have the opportunity to cut around 200 polygons, but the in-maya vertex counts will be virtually unchanged. All of the polygon removals will be along hard edges, so (in theory) I will actually be removing a large number of verts as far as RW would be concerned? Also, I would be breaking the mesh into smaller peices, but this wouldn't have any effect on tri-stripping as the edges that the mesh would be broken at are hard (and therefor breaking tr-stripping anyway). I can post pics if this is unclear (as I assume it is).

spm
06-12-2004, 09:00 AM
Originally posted by Tahl'eN
Ok, this seems the propper forum to ask this question: I'm working on optomizing an older model of mine, and I have the opportunity to cut around 200 polygons, but the in-maya vertex counts will be virtually unchanged. All of the polygon removals will be along hard edges, so (in theory) I will actually be removing a large number of verts as far as RW would be concerned? Also, I would be breaking the mesh into smaller peices, but this wouldn't have any effect on tri-stripping as the edges that the mesh would be broken at are hard (and therefor breaking tr-stripping anyway). I can post pics if this is unclear (as I assume it is).

yes, please do. and also explain more in detail how you think (with RW and all). could be valuable to all of us.

if youre talking about cutting a mesh into several pieces the ammount of verts would increase, right?

Tahl'eN
06-13-2004, 02:31 AM
Ok, here is what I am thinking:
http://www.tahlen.com/CGTPosts/polyQuestion/sLegs.gif
The leg on the left is the modified, broken version, and the leg on the right is the solid, uninterrupted mesh version. (I've removed everything above the model's thigs because all that wireframe was getting in the way of what I was trying to show.)

This one change removed 12 polygons. It did not change the vertex count according to Maya, and since the area that I removed the polygons from was a hard edge (and also a material boundry) I believe I actually reduced the vertex count by 9. I can do this same thing to 14-20 points throughout the model, and I'm not seeing a downside, except that I have to be very specific about how I bind my joints so that they don't separate (or interpenetrate, I suppose.)

Thoughts? Oppionions? Advice?

spm
06-13-2004, 11:19 AM
hmm... it will work. given that youre REALLY careful when you apply the joints and animation. theres always a risk that things will screw up when doing it like that. but if you know what youre doing there shouldnt be any problems.

also, youre right about the hard edges... it wont matter strip-wise.

the rookie
06-20-2004, 03:54 PM
I have to say thank you for this very informal topic, as I am what my name states and I'm trying to teaching myself game design, I have a couple questions, and before I jump the gun, I'll have to read the entire post, but one question to brush up on, I've learned to build models with low polys using tri's, but is it okay to use quads for a smoother setup, I know the tri's are industry standard issues for platforms and you mentioned about PS3, does anybody know where you can find models of CG characters like snake in metal gear solid 2 sons of liberty, which seems to be high rez, any wire frames for this maybe? I am at a very rookie, and I've found a couple of books explaining the difference in texture maps or mapping for video games and I have to drill and review it myself, I'm planning to toy around with a game engine, that's affordable, to produce a game demo, but I want to go for metal gear solid look (the first one on PS one) and low rez texturing, engines are very picky on how it wants the information exported in, I've seen game glitches even on some of the newer games , that seem to be edges or vertexs fliping or pinching, but I'm really trying to drill myself on this, I've had modeling and animation experience and it wasn't a problem converting to the rules of game design, any in depth suggestion besides the ones that are already posted?

spm
06-21-2004, 06:42 AM
i suggest you start modeling on something and then post your work in progress on the forum. that way ppl can comment on it as you proceed.

meshes in games are always made of tris. when you export a model to an engine it is converted from quads, if there are any. i suggest you triangulate your model before exporting so that you can see the final shape and perhaps tweak it if its not perfect.

the rookie
07-04-2004, 10:53 PM
Thanks, I will, sorry I'm slow in the head,but the rookie I am, I just read the first page of this topic and there was some nice stuff in there, I just go into game design myself , and I'm teaching myself game design ( alot of work but I'm movin') I understand now what your saying about the tri-striping part and creating things as on mesh, occasionally I see what they call game glitches of camera's catching open edges or intersecting items and how it's rendered, I'll be working on models soon, I'm working on tutorails on creating games mods for what best suits the comfortbility and speed for production,

I do appreaciate the explaination of the renderware game engine and the Z buffer, I wondered what they were actually using, I'm at the begining phase of learning modeling and scene setup for games, I still do animation stuff, but I have a idea for a game, and I was trying to formulate a demo, I found a game engine and have'nt found out all it's flaws yet, because I'm still in preproduction of the games design and effects,for what I'm looking for, I'm searching hard for it's flaws and evaluating what I can and can not do, or get away with, type of thing, I am well aware that these platforms are using diehard game engines, and the one I could afford and use was the Torgue engine (a hundred to 500 bucks), there are techniques that I want to incorperate, as far as look and design, and I hope to come up with something close to the references I'm going for, the engine is limited indeed, and I may explore others, I have looked at shots that the quake games has and what they come up with, I guess my issues are:
Creating clean geometry
scene and textures (sound I'm not worried about at this time, but the graphic setup)
I am a Maya user and I have incorperated techniques gained from Max tutorials as far as modeling and some scene layout
reviewing the Torque engine and the exporter and it's limitations (because you can go pretty far out using Maya but I have to be reasonable to terms of the engine

All this I have taught myself, modeling with polys and little knowledge of true texture mapping, I'm still in the developmental phases, of learning what I need, to complete this project, I'm moving along fine right now, there's just a few things I need to know and every little bit helps, trial and error, it's intensense and people think I'm crazy to teach myself game design, but I can do it, for some reason it's easy to me...don't know what to say, I am proud of you guys who do have jobs in the industry and it's a huge inspiration to me, my project was abandoned a long time ago, and a close friend of mine seen some of the work and asked me to pick it back up, so I did and demand is become higher, I hope this works, especially the way I need it to go, I'll finish reading thee other pages and studying and hope to have something for you guys to see, Thanks and sorry for the graphic novel writing

the rookie
07-04-2004, 11:09 PM
Thanks again on that, I understand now what you say about modeling (and maybe triangulating after the model is done, because I do, use quads, but I just now learned that th exporter converts them to tri's, remember you talking to someone that's teaching his self game design) for the exporting part I'm just learning about this, and one person on this topic talked about some exporters do the tri-striping for you I do remember reading that before, but learning how to do that manually I believe is better because you have more control of the geom, I've explored different modeling techniques and yet to master them, I've seen some really great low rez models that were done nice, but I didn't get to see the image you guys were talking about the open edges (I still unstand what your talking about thoe) does tri-striping cause and effect more geom or tris? I learn from playing video games and looking at how they approach modeling there models and what they got away with even using textures, this is a very formal topic and you broke down variations of what some studios may want as far as the look and design or the clean and stricted mesh for some studios, amazing, well back to work, Thanks again

EricChadwick
07-06-2004, 01:20 PM
It may help to leanr how tri-stripping works, but most game developer artists don't design their characters with tri-stripping in mind. Most studios have tools that post-process the models to make them strip-friendly. It is a pretty low-level kind of modeling task, there are other things that tend to cause a bigger performance hit than stripping does, like texture memory or # of bones or # of hard normals.

Anyhow, might help you to learn about it, but IMO I wouldn't advise you to spend a lot of time on it, time is better spent on improving your artistic skills, things that will get your foot in the door (or your game done). Let the coders handle tri-stripping, mesh storage, LOD, etc. (all the boring stuff!).

Dargon
07-06-2004, 01:31 PM
Totally agree with you, Eric, except for one point, I think it's well worth practicing LOD skills. Even though it is possible to have an engine that does this for you, most don't, and it's a good skill to have, as it's a really good design challenge to reduce something down, and keep it looking exactly the same, and deciding just how far away it has to be to not notice the difference.

But all the others, while they affect the performance, they do in a fairly negligable way, and so it's best not to really focus too much on them. :)

the rookie
08-05-2004, 09:36 PM
I just recently read some more of the information posted on here and there's alot of awesome information on here, I like to thank the person who posted that renderware test shot of the level for the daredevil game, that was really nice to see

Crazy enough that I am a rookie in this, I do actually do some coding stuff for the games I'm working on, that I thought myself, what's even more crazy, I lucked up on a PS2 Linux Kit to actually practise creating games for platforms, for me it doesn't seem hard, and maybe I'm just that crazy, and I can do some modeling game art stuff too, I was wondering (If this is the right section to post this, and I haven't seen this question any where else) What's the average poly count for models or a range if you can provide it for me, for modeling for platform games?

I've seem some of the models here reach at least 5000 to 6000 poly's on character models alone, (I know this will change, within probley a couple of months, due to the Xbox2 and PS3 coming out) but I was curious of the range of mods, Example:
What would be the range of models for PS one?
What is the range with PS2 and Xbox?
I have seen and have a general idea for PC games and there limitation based on the engine being used

I've also seen mods that were 500 poly's and worked out fine for PC games, I know this information would be based on what Game Engine is used, but I'm trying to get a general mind set of the models, I have looked at models playing specific games on how they went about it (like Metal Gear Solid one and in comparision to games like Omimusha 2 for the difference of design and what there working with) I may sound crazy, but I like PS one games better than PS2, it's something about the video feed thing I don't like with the PS2, while PS one was more straight cut right into it and not drawn out, I'm not to fimiliar with the real time thing, even thoe I've purchased the PS2 Development Kit, I just learned the basics to create my demo, please help me on this if possible, (also I'm working fast as possible and I'll be posting models soon, it's just getting the modeling thing down, the right way and mastering the techniques, I'll pull it together)

OttovonDrone
08-22-2004, 01:45 PM
Hi Eric,

Thank you again for all your contribution! Gotta another question for you re: the T-Junctions. In this case:

http://www.drone3d.co.uk/img/vt_trace_01.jpg

In this case, do we still have a T-Junction? I mean, shifting the E Vertex down the ED Edge?

Best wishes,
OvD

[edit to add] Isn't this problem with the T-Junctions a bit immaterial so to say, when prepared for export won't this face 1 be broken down into two tris anyway by the triangulation? CEA and EBA? Even though I'm not in the game industry, if i were doing such a thing on a model which will be animated, I'd do this triangulation even before the rigging so that I'll have a good edge there to make the deformations acceptable.

EricChadwick
08-22-2004, 02:46 PM
Legitimate question.

The diagram assumes all are triangles, no quads or polygons. Thus if you move E away from the line BC, you're just opening up the hole that is already there, because E is not connected to triangle ABC.

Without moving E, the surface may look solid, but in-game you'll probably get some artifacts because you typically have lower numerical precision in-game, which will not keep E's position exactly along the line BC.

It isn't just me contributing to this great thread though... my props to everyone who's added their insights.

OttovonDrone
08-22-2004, 02:56 PM
Legitimate question.

The diagram assumes all are triangles, no quads or polygons. Thus if you move E away from the line BC, you're just opening up the hole that is already there, because E is not connected to triangle ABC.
I have obviously missed the point where you describe the diagramme as tris only :) I see your point, it's pretty obvious now :)

Is the solution, then, adding another edge down the EA line (that is, removing the gap of CEB)? Is the addition of a new egde justifying the removal of the problem?

It isn't just me contributing to this great thread though... my props to everyone who's added their insights.
Ditto!

EricChadwick
08-22-2004, 03:00 PM
You got it. To fix I would add a vert between B and C, then weld it to E. Or else remove E entirely, leaving just two triangles ABC and BCD.

OttovonDrone
08-22-2004, 03:13 PM
Cheers Eric!



And yet another question:

When I have the free time (which is infrequent, unfortunately) I work on a few low-poly models just for the fun of it. Here's one:

http://www.drone3d.co.uk/img/Crossbowman_01_Wire_04.jpg

The question is:
Are the tri-fans circled in red problematic when it comes to tri-stripping? Is the shared vertex broken down in several vertices, or the tri-strippers have a way around this? Are tri-fans recommendable at all?

Best wishes,
OvD

gtl
08-22-2004, 05:45 PM
thanks for the excellent info! :bounce:

AlexMateo
09-29-2004, 05:12 PM
im now working for a games house , and this help me very much , thanks :)

juliany
10-06-2004, 02:34 AM
Very interesting and well composed! - I've let my 3d team know about this! Handy stuff!

JeePee
10-09-2004, 12:31 PM
i've got a question about the tri strip thing

when i have to choose between a good tri strip or less polygones what is the better choise?
i've also got some places where i can save about 3-4 faces

http://www.jeepee.demon.nl/tristrip.jpg

Lopoly
10-09-2004, 01:19 PM
- Basically tristrip oriented hardware (like PS2) and engines(renderware) doesn't care much how many polygons Your's object have, they work on tristrips and tristrips they count/display. This means that lessen number tristrips is always better choice even if this means adding new polygons - however before You start changing geometry (especially on small objects) it's good to check how object strip-tease - sometime changing anything is just waste of time, auto-strip could do this good enough.

Edited: About Your's model: You are removing quite a loot faces there and it is possible that You will reduce tristrip count - what is good.

Important thing is that all optimalization decisions should be done after You seen initially tristripped model - model viewers usually have tristrip preview - only then You can see what part of geometry You could remove (because eg. its stand alone tristrip) and where You need to add or fix polygons.

JeePee
10-09-2004, 01:59 PM
so if i understand right i only have to care about tri strips on tristrip oriented hardware or engines?

i'm making this model for half-life 2

Lopoly
10-09-2004, 06:14 PM
so if i understand right i only have to care about tri strips on tristrip oriented hardware or engines?
i'm making this model for half-life 2

I see I mislead You a little, sorry about that.

- From my knowledge tristriping is quite popular routine. I belive that (at least) nvidia cards have hardware accelerated tristriping. It is highly possible that most commercial engines are using tristripping. You should find some half-life fan development forum and ask there. They could also have some extra stripping tools or at least a strip-viewer.

Nosalis
12-09-2004, 07:28 AM
really great and useful thread.

I also worked with RW and PS2 and it`s really a horror to have everything smooth (tristrips, smoothgroups, UV`s ...)

thank you for the sharing the experience

mustra
12-22-2004, 09:57 PM
nice stuff this thread is great ive never heard of tri strips or list before, so this is really important in a construction of an engine.

i have some doubts, like if i model something for a pc game, where the amount of tri strips arent that important concerning to render sweepts, if the game is to be converted to a console , do i have to remodel the model because of tristripes optimization ?

and about that stuff from nvidia about the limitation of the number of rendering stuff i can have concerning the 60 fps constant, i can only have 25000 tristrips rendering at a time, but a model is composed by many tristrips, even if chained, wich leads me to conclud, if correctly, that with corrent tecknolgy i cant have more then about 2500 models on screen at the same time, with an average rate of 1000 tripolys per model, but then, if i have a really big mesh with 2000 millions of vertexes , wouldnt that exceed the 25000 tristrips available at the same time ? and consequently, run lower then 60 fps ? right ?

but that is something that i found hard to believe, because ive seen pretty intensive meshes in 3dsmax with thousands of hundreds of vertexes, does 3dsmax uses chained tristrips or trilists ??

hmmm...sorry if i sound confusing and sorry for the bad english :sad:

ps: if to creat an engine (wich i wont), where can i find infromation on coding tristriped or trilist buffers ?

ps2: what is renderware ? a game engine ?

Triarii
12-26-2004, 12:13 AM
i have some doubts, like if i model something for a pc game, where the amount of tri strips arent that important concerning to render sweepts, if the game is to be converted to a console , do i have to remodel the model because of tristripes optimization ?

To be honest, if you know you going to be making it for Consoles aswell as the PC, common sense would tell you to model it for the console as opposed to a PC, and then there isn't any faffing around trying to remove polygons to allow tristiping to occur, instead of having an alreasy stripped model, that needs no converting at all.

If your gonna be modelling anything, use strips, then nothing can go wrong can it?

Great thread btw, i learned alot from it.

Dodgeas3d
05-04-2005, 07:14 AM
I just wonder why most game models are modeled in quads not in tris? maybe they add tris later? accross quad surface? http://www.cgtalk.com/attachment.php?attachmentid=70075

Btw great thread!

coCoKNIght
05-04-2005, 09:25 AM
Well I guess that's because a quad consists of two tris. If it wouldn't it couldn't be displayed assuming the four vertices are not planar. Quads are just way more easy to edit/model.

But right now I'm a bit confused, so that might be wrong.
I'm thinking about joining the unoficial game art challenge but then I see the small models of the people participating and they say their model has 600, or 800 tris. But the model doesn't look like it has 300, or 400 polys?! :argh:

And what's with that tri-export-thing. Can't the standard 3d packages do that?
Are there any of those free to download?

Sorry if some of the above has already been said. Can't read the whole thread...

EricChadwick
05-04-2005, 02:22 PM
It's generally easier to see the form and shape of the model if you work in quads, and it also allows "edge loop" modeling shortcuts (search (http://www.cgtalk.com/search.php?) for it).

But in the end, nearly all modeling programs export to triangles. It is a good habit to check your triangles before export, to make sure those edges running across the insides of the quads are going the direction you want.

An example...

http://www.ericchadwick.com/portfolio/glossary/examples/ridge_valley.gif (http://www.ericchadwick.com/portfolio/glossary/examples/polygons.html)

lostdoll
05-05-2005, 07:33 PM
o.that's right

Zorlin Crux
07-02-2005, 05:52 PM
There are no differences between modeling for PC and for consoles. The essentials of how PC and console 3d hardware work are the same. The main difference is that you cannot tell a console owner to go and buy a faster graphics card, so you have stricter quota.

About effectiveness of triangle striping

Practically all modern 3d hardware has a primitive modes: triangle strips, triangle fans, and triangle lists. Some OpenGL cards do quad lists as well. In any case, the lowest level, rasterizer, only draws triangles. All modern PC hardware and some consoles have vertex indexing, where all vertices are in an array and strips/fans/lists just refer to the array.

Let's first take the case where you have no indexing and strip cutting is free, such as PS2.

Tristrip cost: vertex cost * (2 + number of triangles in a strip) * number of strips
Trifan cost: same as triangle strip, but fans are usually much shorter, since max fan length = number of triangles sharing a vertex.
Trilist cost: vertex cost * 3 * number of triangles.

Here, even if all you have is one triangle strips, you still get as fast as triangle list. And since strips are generally longer, triangle strips win. From now on, triangle fans are left out, as they are only useful for some special cases.

Now let's have a look at a PC graphics card with linked tri-strips and indexing:

Tristrip cost: (vertex cost * ( 2 + number of triangles in a strip - cache factor ) + 4*cost of degenerate triangle )) * number of strips
Trilist cost: vertex cost * ( 3 - cache factor ) * number of triangles

So what is this cache factor? Modern T&L graphics cards have a post-transform cache which is a small memory of recently used vertices. Cache efficiency depends on a number of factors too complex to discuss here; however, it cannot be more than about 1.5 - 1.7, which is in the case that - surprise - the triangles were pretty much in strip order.
Degenerate triangle cost is very small compared to vertex cost since all their vertices are in the cache already or will be used for the next strip.

Here we have a break-even ratio of 2 or 3 triangles per strip on average, which is quite poor, vs 'optimal' trilist. However in the case where tristrips work so poorly, trilists work even worse due to bad cache factor. Again, in a general case, triangle strips win.

In short, efficiency is almost never a reason to avoid triangle strips. A much more common reason is a different technicality, such as depth sorting for transparent triangles, in which case strips and list are equally poor but lists use less memory.

About modeling for good triangle strips

The discussion above has a good list of advice already. Basically it boils down to a few things:


Avoid discontinuous edges. Each discontinuous edge adds two vertices to the model at hardware level.
Try to get a multiple-of-three triangles for each vertex. Otherwise it breaks a strip, since each vertex is used by three consecutive triangles in a strip. (Except for first two and last two vertices, obviously.)
If you have a vertex with two discontinuous edges, try to get three (or a multiple of three) triangles between them. Otherwise it breaks a strip, like above.
When capping cylinders, put the edges to a zigzag pattern, just like the sides. That gives the best striping.
About engine-efficient models

Besides making models with good stripping, the point is to avoid multiple batches. A 'batch' is a bunch of triangles that can be rendered as one linked strip, and in effect one (usually expensive) call to the rendering system. Among things that break a model into multiple batches are:


Different shaders/materials for different parts of a model. Shader change always breaks a batch and is usually a very expensive operation - even so that many 3d engines rather render parts of different objects with the same shader rather than one object completely at a time!
Different textures/texture combinations. Typically textures are bundled with shaders, so a character with one map for head and another for body counts as two batches. A fighter plane model with four maps for decals becomes four or five batches!
Too many bones. 3d engines can only use a limited number of bones, 25-30 typically. If there's more they either don't work at all or split the model.
Different bone influences. Some 3d engines use a faster shader for single-bone vertices and a slower one for 'blended' vertices. It is a different shader so the first item applies.
Mixing transparent and opaque materials. It's a different material, so it's a different shader.
This thread clearly needed a 3d engine programmer advice. :)

Nosalis
07-03-2005, 11:33 AM
thanks @ll for great info :)

spm
07-03-2005, 06:44 PM
Zorlin Crux: tnx for the summary. i think it was needed :)





.

membreno-david
07-04-2005, 11:48 PM
Thanks for this, just graded from Game Art & Design program, good pointers.
-Tito

Ristintin
08-10-2005, 01:08 PM
hello,
thank you for posting this, it was really really helpfull. i want to be a charecter designer in the future, but i cant find that much information, so what you posted really help me alot. angain thank you very much:bounce: :)

makkE
10-17-2005, 07:04 PM
Thanks everyone who put their knowledge in this thread, the information gathered here is really valuable :D

Now that Zorlin Crux gave this really nice summary, there´s a thing that´s giving me a little headache.
The modelling program I have used for all my models so far (ms3d) does cylinders like you can see on the left of the attached image.
Some other apps I´ve tried do them all like the one on the right.

Do I have to go through all my models now, turning edges on cylinders?
Or is there a reason behind the app creating cylinders just like that?

EricChadwick
10-17-2005, 07:11 PM
The cylinder on the right is better for tri-stripping. But IMO changing your models only matters if your game engine shows a significant framerate improvement. Personally, I would contrast the two methods in an actual runtime situation before changing a bunch of assets.

makkE
10-17-2005, 11:00 PM
Thanks Eric, you were right.
Just did a runtime test, infact there was no dramatic change in performance, in fact the version that was not continiusly stripped ran like 0.2 fps better. It seems to depend on the engine.

dudethedreamer
01-20-2006, 08:17 PM
Any other advice on game modeling besides 'triangle stripping'? I thought this thread was going to go into more interesting topics such as... Well... What else is there to game modeling beside triangle stripping? Is this? Realy it? Triangle stripping?

I still dont fully understand triangle stripping. Im assuming its the flow of a mesh that flows in one constant direction which seems to help the game engine run better. And then the hard edges that you guys talked about seems to be the pologon 'smoothing groups' which also helps the game engine run better, but what else is there to game modeling?

Thnaks

EricChadwick
01-20-2006, 10:24 PM
dudethedreamer, did you read past the first post? A ton more techniques and tips have been covered that just stripping. I think we covered exactly what it is further in the thread. If you read those pages and still have questions, I'll be glad to help.

monkeynutz
02-02-2006, 09:05 AM
Well my instructors at school had been urging us to visit this site and now I have and I read through this entire thread just now. Firstly, thank you all for contributing your knowledge and experience. I have been taught that it is best to model in quads, though explanations outside of deformation related issues had not really been covered. I now see that in game models quads lend themselves to better tristripping as it is quite normal to model in quads but a stray triangle will typically terminate a strip. The information on how a game engine interprets hard/soft edge changes is quite useful as well. In my game content and scene design class we were actually required to have some hard edges on the model; their reasoning was that not everything is smooth. While I can see that sometimes it may be necessary to get the right look, it is nice to know and consider what this actually does in a game engine.

Also, from the brief discussion on interpenetrating geometry confusing the Z-buffer in some game engines I'm no longer angry with the requirements for my current school project. In creating a game environment we're absolutely not allowed to have any intersecting geometry. Having any surfaces intersect simply results in no credit for the project. At first it confused me as I am certain I have seen interpenetrating geometry in games before and in some scenarios it's just very difficult to avoid without compromising the density of the mesh. There was also the fact that one of our instructors months ago encouraged us to use interpenetrating geometry as opposed to a more complex model, though perhaps I'm misunderstanding some of this.

I suppose after all this rambling I should at the very least pose a question. Though the XBox 360 has not been out long and it is unlikely that anyone here has a very good idea of what the PS3 is/will be capable of I may as well ask, not that it is necessarily completely specific to those platforms. In any case, I'm planning on using a couple of game environments and characters for my demo reel and I intend to use normal mapping to the best of my ability as all signs indicate it will become the standard for adding lots of extra detail in games over the next few years. My question is how badly will normal mapping bog down a system? Naturally the playable character should be normal mapped as you want the character to look it's absolute best, but how do things work for the environment? I know normal mapping can be very beneficial for cracks, divets, and other imperfections in hard surface models, but suppose every model that composes an environment is normal mapped. Is this too excessive and unnecessary and will this have serious consequences on the performance in game?

Thanks in advance for any input and sorry for posting such a question when I did read at the beginning of the thread that such things as normal mapping wouldn't be touched upon in this thread, but that was a couple years back and by now normal mapping is something everyone in the game industry needs to be familiar with, lol.

EricChadwick
02-02-2006, 02:16 PM
... how do things work for the environment? ... Is this too excessive and unnecessary and will this have serious consequences on the performance in game?
Good post.

Not too excessive. The realistic-themed first-person shooters are using normal-mapped environments and props, across the board. Height maps are also coming into vogue, with the (re-)introduction of relief and parallax mapping. Do a search, some good threads on CGTalk about these in the past. Also here (http://boards.polycount.net/showflat.php?Cat=0&Board=1&Number=59490&page=4&fpart=all) on polycount.

Rendering performance is usually kept in check by your Art Director working alongside the Technical Director, so they'll be the ones to set your limits. They should be telling you how big your textures should be, what file formats to use, how many you get per load area, which kinds of passes are allowed (color, specular, normal, parallax, etc.). Then you work within those limits and try to make your assets look as awesome as possible.

Often you'll get a list of game-supported shaders, each with a set number of passes. So one shader will be used for light sources, with just an emissive texture. Another will have color + normal + specular, for props. Etc. Half-Life 2 had something on the order of 1000+ unique shaders, each having supporting slightly different options and incurring different amts of passes. The artists then pick and choose which to use on which asset, using the least-heavy performance shader the asset can get away with.

Texture memory is a big still a limitation though on these new platforms, so environments need to use tileable and reusable textures to stay efficient and maintain detail. Great thread here (http://boards.polycount.net/showflat.php?Cat=0&Number=91531&page=0&fpart=all&vc=1) on polycount from a couple artists working on Unreal2007, detailing how they model/map their environment props.

btw, in the future this really belongs in the normal-mapping thread (http://forums.cgsociety.org/showthread.php?t=129627).

HellBoy
02-17-2006, 04:59 PM
Hi guys

I have a question about Level designing, lets say you finished a city level, sort of GTA type, you obviously modelled building blocks seperatly from the ground pavement, after you finish and are ready to export it to a game engine, does the whole work need to be one mesh, so everything, from building blocks to trees need to be 1 object, everything is attached to each other? I personally think its not, but its kinda confusing

thanks

EricChadwick
02-17-2006, 05:10 PM
does the whole work need to be one mesh, so everything, from building blocks to trees need to be 1 object, everything is attached to each other?

Usually no, though the game exporter ultimately dictates how you setup a level. You want multiple entities so that meshes behind the camera or out of the view can be culled, which tends to improve performance. If it was all one object, every vertex would have to be transformed, etc., for every frame. Even though a lot of it wasn't actually being seen.

abyjoe
02-20-2006, 08:26 PM
Usually no, though the game exporter ultimately dictates how you setup a level. You want multiple entities so that meshes behind the camera or out of the view can be culled, which tends to improve performance. If it was all one object, every vertex would have to be transformed, etc., for every frame. Even though a lot of it wasn't actually being seen.

hi eric,

i have been checking this thread for quite a while now and admire your knowledge. i have a question regarding blend mapping. thought you would be the best person to answer this.

i have modeled my level and kind of finished texturing it. now i am using some blend maps to give it a decent look...

i have to blend 3 sides of a poly with 3 different maps, like on two sides ther is grass, then on other pavement and another one side there is dry land. with using blend maps i can specify 2 maps and 1 mask only. can you tell me how to get over with this. i have heard about painting RGB colors for the map but i dont know how to do it... iwhat is the way to get this done most economically... what will happen if i use a blend material in blend, and will the engine recognise it...

is there any good learning resource you can direct me towards for advanced texturing of game environments.

EricChadwick
02-27-2006, 02:24 PM
[oops, duplicate post]

EricChadwick
02-27-2006, 02:25 PM
Thanks for the compliments.

UDN has some good resources, if a bit dated (Unreal2 era). Here's one about using vertex color...
http://udn.epicgames.com/Two/VertexBlendingTutorial

RealityEngine was bought by Epic last year, so this site may go away. But it shows a more modern method of blending textures...
http://reality.artificialstudios.com/twiki/bin/view/Main/MixMapTutorial
Though most engines AFAIK still rely on vertex color for blending.

Don't rely on material setups in your 3d app to match what an exporter allows... they usually have very strict guidelines for what's supported, and very different from game to game. Usually they just export the mesh, and have you set up materials in their own custom app.

Authentic-Dave
04-20-2006, 01:21 AM
Games modeling - some rules of the trade.

This thread has really cleared some thing up for me about how Tri's are best handled, really appreciate it, keep up the good work.

twistkill
07-04-2006, 02:53 AM
i know models for games should be real lowpoly..i am trying to optimize this model for a glock (hand gun)...it has a sliding barrel on top..do i delete the inner polygons of the barrel (marked by red in the render below)???..as they will be coverd by the lower part of the gun even when reloading

same for the magazine compartment...do i delete the inner walls of the compartment in the gun handle..leaving just a hole on the lower region of the handle? wont it leave any open edges?

http://img346.imageshack.us/img346/8097/slidebarrel1sh.jpg

i made a seperate thread for this silly question in some other forum!..sorry!

ArchangelTalon
07-04-2006, 04:42 AM
If it's for a first person view model (the model you see in your viewport in-game) you remove all the polygons that are never seen anyway. So you can model them in if you like, but more than likely you'd be removing them later on.

twistkill
07-04-2006, 09:41 AM
kewl..thanx..

yeah..its for a first person game..so i delete all the inner polygons..that would leave open edges...is that fine to have models with open edges in games?..just curious!

DaFuture
07-08-2006, 04:27 AM
Hi,

My name is Jorge Velez and I'm fairly new to 3D modeling. I have gotten pretty good with a few 3D apps and now I want to take my journey into game development. I have a few questions since you seem to have knowledge on this subject. 1) I'm souly focused on sports (basketball 1st) and need a few suggestions on programs that would best work primarily for human character design (athletes). 2) What would be good for smooth animations (for dunks & moves). 3) Something that'll work good for arenas. I'm more concerned about gameplay so my goal is to have great looking characters and smooth animations while still maintaining a low poly count which of course helps towards smooth gameplay right? Does this have something to do with which software I use or are there tips to keeping the poly count low? For the engine to run it on I've been adviced on Blitz3D and Torque. Hash Animation Master was also suggested. 4) What do you suggest? It's hard to choose because most types of software don't work well with others so I'm kinda searching for a good package wether I put it together piece by piece or buy it as a whole. My goal is to evetually reach the xbox and ps2 consoles. I already know of 3DStudioMax, Maya and XSI so are ther any that are just as good but cheaper? Thank you for taking the time to read this and I hope to recieve good advice.

DaFuture

nibbuls
07-08-2006, 04:42 PM
Blender's free, and once you get accustomed to it, some people prefer it over Max and Maya.

www.blender3d.org (http://www.blender3d.org)

All 3d programs can model humans--just a matter of your skill.

FreakyDude
01-21-2007, 03:06 PM
Blender's free, and once you get accustomed to it, some people prefer it over Max and Maya.

www.blender3d.org (http://www.blender3d.org)

people like me. :)

if you need instant humans which will deform well, you could try makehuman, it's open source, and you can create a LOT of different type of humans with it that you can export to whatever app you like and rig/animate etc.

CGTalk Moderation
01-21-2007, 03:06 PM
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.