Jump to content
The Dark Mod Forums

Object/Mesh conventions


Baddcog

Recommended Posts

I guess I'll start this thread, was talked about in (I'll come back with link)

 

--EDIT--I'm not having much luck finding the post this was discussed in.

------------------

Basically it has been brought up that there are really no conventions set-up being used on objects as far as polycount/shader usage.

 

New info has been coming to light so we might as well have somewhere to discuss it.

 

I wouldn't say this is about redoing old models as much as establishing good guidelines for new models.

------------------

Things that need discussed (I'm leaving this first post fairly wide open here as I don't know the best conventions to use).

 

Polycount: Generally basic objects should be somewhere around 250 polys for objects that will be used alot (goblets and whatnot that have a possiblity of showing up in large numbers in one scene)

 

Doom can handle polys quite well but 10 goblets add up polys real quick, add that to plates, silverware, tables, lights, ect... polys balloon out of control. Also it seems that it's not the polycount that matters as much on performance visually as much as polycount performance wise for pathfinding/shadowcasting,ect...

 

AI generally range in the 2500 to 5000 poly range. So one Ai in a dining room scene could easily be 10,000+ polys plus terrain.

-edit- It seems that animated polys such as Ai weigh more heavily on the system as the need to be calcutaed more often than static polys

 

I'd say that special items. A fancy piece of loot, something that will be in a scene once could push 500 to 1500 polys. This is my personal opinion and this is not meant as a guidline so much as a discussion point.

 

Then we have terrain objects like Pink Dot's Galleon. This is about 12,000 polys p-lus 2500 for the rigging. This seems to be before shadow mesh and collision mesh were added.

 

Shadowmesh: This is probably one of the more important aspects, even moreso than polycount as we are working with real-time lighting. Probably any object over 250 polys (?) needs a shadow mesh that is as low poly as possible while still giving a decent looking shadow.

This can improve rendering performance greatly.

 

Collision Model: Probably second in importance, after shadow and more important than polycount. Like shadows it has a large effect on computations. Seems to be precompiled on mission load (I'm uncertain of this - someone else probably knows better than I).

Again, keeping them as low poly as possible increases performance with pathfinding.

 

Shaders: I'm not sure how this effects performance at all. There could be alot of factors and I'm interested to know exactly what the best options are. I guess I've been working so far under the assumption that it would be best to reuse existing shaders and or materials as much as possible to keep mod bloat down.

But recent posts have left me a little confused. From what I'm gathering more than one shader per object can start to bog down the engine???

So say we have 3 objects on screen. Each has 2 shaders. all three share one common shader. So in all there are 4 shaders on screen. Does doom manage these as four shaders total, or 2 shaders per object resulting in 6 shaders used?

Do we want to steer towards mod bloat by giving each objects one shader if possible? Or is it better overall to try and reuse shaders even if it means several shaders per object? Do shaders load at mission start or are they loaded when object is in view?

Dark is the sway that mows like a harvest

Link to comment
Share on other sites

Also it seems that it's not the polycount that matters as much on performance visually as much as polycount performance wise for pathfinding/shadowcasting,ect...

 

Yes, it would be nice to figure this out. Does an extra 2-3000 polys really have a huge impact on a scene? What if they're non-shadowcasting? What if they have a simplified collision mesh?

 

I guess it would be easy enough to do a few tests. From the ones I did with a static (nonanimated) AI model of around 3100 polys, with 40 AI in a room (say 125 000 polys, approx), I noticed the following:

 

When the model cast a shadow, fps went from 55 to 10. When the model did not cast a shadow, the fps went from 55 to 30.

 

That suggests that it is shadowcasting polys that cause a hardship for the engine, not just polys themselves.

 

Which also suggests that maybe 250 for props is unnecessarily low, as long as they have a simplified shadowmesh, or are non-shadowcasting to begin with (like many lights). Can any mappers comment on whether 125K polys sounds reasonable for any given scene?

 

But recent posts have left me a little confused. From what I'm gathering more than one shader per object can start to bog down the engine???

 

My test above was actually to primarily test whether one model using lots of submeshes (with different materials for each mesh) affected performance. In my test with 40 models, one batch with 10 submeshes/materials each, and the other with 1, I saw no difference in fps whatsoever.

Link to comment
Share on other sites

@Baddcog: the thread where discussion started: http://forums.thedarkmod.com/index.php?s=&am...st&p=135335

 

I'm not on my TDM system at the moment, but I do have one performance thing I can mention. When I was doing the recent AI tests, I noted the difference between D3 AI and TDM AI. The setup used 40 D3 imps, and later, 40 TDM city watch (same map, same environment). After trying all of those AI performance testing cvars (several of which shut the AI down completely, so we can figure any TDM AI complexities are not factoring in), I found that the room full of imps gave me, ~20-40 FPS. That's a lot of polys running quite well on my slower system. The 40 citywatch (not animating, not aware) brought the framerate to the low teens (12-14). I believe the citywatch and typical TDM AI have close to 5K polys. The D3 AI have half that. They're quite blocky actually, but it's hidden well by really incredible materials.

 

So anyway, that at least would indicate that yes, while Doom3 can render a truckload of polygons really well, it does add up. In this case, double the polys nearly halved the framerate.

 

I believe 125k polys is a pretty packed scene. It can definitely be done, but it's pushing it, especially with all of our advanced systems in place.

Link to comment
Share on other sites

So anyway, that at least would indicate that yes, while Doom3 can render a truckload of polygons really well, it does add up. In this case, double the polys nearly halved the framerate.

 

Note that animated polys != static polys. A static mesh can be shoved into a display list/vertex buffer and rendered very quickly whenever it is needed, whereas an animated mesh needs to be recalculated and sent to the graphics card every frame. This is one of the reasons why adding large numbers of AI can tank the framerate even if the equivalent number of static mesh polygons would render just fine.

Link to comment
Share on other sites

http://www.iddevnet.com/quake4/LevelEditor_Performance

 

This link is not new on this forums (Gildoran posted it some time ago). You can find there some info on Draw calls and Batch sizes. Basically draw is a batch of polygons of the same shader and for one light only sent to graphics card. So 10 AI with 10 shaders each lit by 3 lights mean 300 draw calls. It's plenty, because 1000 is recomended maximum number of draw calls per frame. And where's the rest of rendered map?

Springheel - I believe 10 meshes AI are a performance killers. Did you check them in empty room or in full map, with plenty other models and geometry with various textures? If anybody has time to do some test (sorry, I can't for a while) just check how many draw calls each AI adds to scene. There's a commnad r_showprimitive which shows draw calls number.

Link to comment
Share on other sites

Springheel - I believe 10 meshes AI are a performance killers. Did you check them in empty room or in full map, with plenty other models and geometry with various textures?

 

I tested them in an empty room. The goal was to test the effect of a number of meshes, so I wanted to eliminate any other considerations. The test showed quite clearly that multiple meshes had *no effect whatsoever* on framerate--at least on static meshes. It's possible it added to the overall load time for the map however, I didn't really pay much attention to that.

 

Here's the original thread:

http://forums.thedarkmod.com/index.php?showt...&hl=submesh

 

edit: the original test, using 5000 poly objects, showed only a drop of 2 fps when going from 1 mesh to 4, even with *135* models on screen. So while there does seem to be a marginal decrease, the effect is so low as to be not worth considering, IMO.

Link to comment
Share on other sites

Note that animated polys != static polys. A static mesh can be shoved into a display list/vertex buffer and rendered very quickly whenever it is needed, whereas an animated mesh needs to be recalculated and sent to the graphics card every frame. This is one of the reasons why adding large numbers of AI can tank the framerate even if the equivalent number of static mesh polygons would render just fine.

Yep, but, I was using the cluster of new AI debug cvars we had, including ones that caused them to stop animating completely (causing framerate to shoot way up). That said, the Doom3 AI, frozen/disabled (and whatever) else the cvars do, still had better performance by about a factor of 2, than TDM AI, frozen/disabled. And incidentally, half the polygons. There could be more behind it of course (and probably is), but it at least suggests our polycounts could be having some effect.

Link to comment
Share on other sites

--major edit-- sorry if anyone is answering that..

Shadowmesh -

//base/textures/common/shadow will cast a shadow on terrain, func_statics, AND objects which have a shadow mesh.

 

//base/textures/common/shadow2 (which I have been using for some reason) will not cast shadows on objects with shadow meshes.

 

I can't seem to find the material decls for common mtrs. Anyone know what file these are in?

 

----

Collision Mesh - collision.mtr contains PinkDot's collision materials for many different material types. These can be combined, for example I used tdm_collision_metal for metal parts on a chest (to deflect arrows and have a metal coll sound) and tdm_collision_wood so arrows would stick to wood areas on the same chest.

Dark is the sway that mows like a harvest

Link to comment
Share on other sites

Anyone know what file these are in?

somewhere in pk4s, in base folder.

 

I believe that diffrence between shadow2 and shadow is that shadow2 has also noselfshadow keyword. I used it for cuttlery to avoid weird selfshadowing, caused by shadow mesh sticking out of the visible mesh.

Link to comment
Share on other sites

Yeah, sorry. I think somone pointed out the difference of shadow and shadow2 to me quite awhile back. That was one of the first obj probs I had but forgot about it.

 

Trying to be very careful now on which shadow I use and if using shadow that the shadow mesh is contained within the objects mesh.

Dark is the sway that mows like a harvest

Link to comment
Share on other sites

I've searched for nearly an hour... How do I display the polycount?

 

I would love for something like Dromed where you can see a running polycount in the corner of the screen.

 

I found "r_showTris" but haven't tried it yet...

shadowdark50.gif keep50.gif
Link to comment
Share on other sites

r_showtris 1 shows rendered visible tris (?)

2 shows tris in view(?)

3 all tris in scene

I'm not sure I'm 100% on those, esp #2

 

R_ShowPrimitives gives you polys in view and also shadow polys in view. I've only used it a bit the last few days. It continually updates but the console has to be open, so I'm not sure how you can run around and see it at the same time.

Dark is the sway that mows like a harvest

Link to comment
Share on other sites

There could be more behind it of course (and probably is), but it at least suggests our polycounts could be having some effect.

 

Indeed, that was my point -- in contrast to static meshes, polycounts are expensive for animated models.

Link to comment
Share on other sites

Something that's bugged me for a while...what is the difference between a "poly" and a "tris"? Is it just that a poly can have any number of sides, so a 'tris' is used to specify a 3-sided poly?

Link to comment
Share on other sites

That really depends on the 3d program. In 3dsMax a poly can have inumerable tris in it. Some 3d progs count every tri as a poly.

 

I think ALL game engines count a tri as a poly, certianly Doom3 does. So in max I could have 1 poly, in Doom3 it would be 5.

Dark is the sway that mows like a harvest

Link to comment
Share on other sites

Yeah, strictly a poly (short for "polygon") could have any number of sides, but in modelling it will most often have 3 or 4 sides. Doom 3 (along with OpenGL and most renderers) only renders triangles, so in this case "poly" == "tri".

Link to comment
Share on other sites

Wow, I fired up mansion_alpha and noclipped to an area that showed over 2.5 million tris! When I went down into the skylight (the staircase room) the count dropped to 250k, still way high, but much better!

shadowdark50.gif keep50.gif
Link to comment
Share on other sites

Technically a tris is simply a special case of a poly having just three vertices. A poly can have many vertices, including 3. Don't know if a line could also be counted as a poly with just two vertices then. :P I guess polies have to have at least three vertices to make it a poly and in the case of three vertices you can call it a tris. A poly with four vertices could be called a qad, and some even do it, but a quad can have different properties than a tris. For example a tris can always be counted on to be on some plane, while a quad may not need to.

Gerhard

Link to comment
Share on other sites

In game engines (not in 3d app) polygons have many sides but are always cooplanar. Tris = faces and have always only 3 sides. Everything which is displayed is triangulated anyway, so polycount is usually diffrent than number of tris but people tend to mix up these words ("polycount" as a word just sounds good, doesn't it?). But sometimes it's good to be aware about that diffrence - f.e. collision meshes have limit of 16 polygons, not tris. This make big diffrence, cause you can have CM in shape of 14 sided cylinder, which would have actually 52 tris (faces) as a regular model....

Link to comment
Share on other sites

collision meshes have limit of 16 polygons, not tris. This make big diffrence, cause you can have CM in shape of 14 sided cylinder, which would have actually 52 tris (faces) as a regular model....

 

Doesn't D3 cut it into tris anyway?

Link to comment
Share on other sites

But if you have a square, the engine slices it into two tris. So everything is tris with Doom 3

 

Not sure if this is 100% true. In OpenGL you can use Quads as well, but they have to be planar, otherwise I think they will not work. I don't know if D3 makes use of this, or if it converts everything into triangles.

Gerhard

Link to comment
Share on other sites

Yeah! <_< I know that this is usually the case, but I'm pretty sure that I read in the SDK somewhere that there are special cases where Quads are indeed used. I'm not talkign about the average brush or model, because those are AFAIK always broken into tris, to avoid the problem of having to determine wether it is usable or not.

Gerhard

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Recent Status Updates

    • Ansome

      Finally got my PC back from the shop after my SSD got corrupted a week ago and damaged my motherboard. Scary stuff, but thank goodness it happened right after two months of FM development instead of wiping all my work before I could release it. New SSD, repaired Motherboard and BIOS, and we're ready to start working on my second FM with some added version control in the cloud just to be safe!
      · 1 reply
    • Petike the Taffer  »  DeTeEff

      I've updated the articles for your FMs and your author category at the wiki. Your newer nickname (DeTeEff) now comes first, and the one in parentheses is your older nickname (Fieldmedic). Just to avoid confusing people who played your FMs years ago and remember your older nickname. I've added a wiki article for your latest FM, Who Watches the Watcher?, as part of my current updating efforts. Unless I overlooked something, you have five different FMs so far.
      · 0 replies
    • Petike the Taffer

      I've finally managed to log in to The Dark Mod Wiki. I'm back in the saddle and before the holidays start in full, I'll be adding a few new FM articles and doing other updates. Written in Stone is already done.
      · 4 replies
    • nbohr1more

      TDM 15th Anniversary Contest is now active! Please declare your participation: https://forums.thedarkmod.com/index.php?/topic/22413-the-dark-mod-15th-anniversary-contest-entry-thread/
       
      · 0 replies
    • JackFarmer

      @TheUnbeholden
      You cannot receive PMs. Could you please be so kind and check your mailbox if it is full (or maybe you switched off the function)?
      · 1 reply
×
×
  • Create New...