Jump to content
The Dark Mod Forums

My first map – questions & work in progress


peter_spy

Recommended Posts

That shouldn't be a problem. There's something wrong with that meshes, because the same material put on brushes looks fine:

 

do_2017-04-15_01.22.23.jpg

 

 

At first I thought the planes might be too big for proper specularity, so I might need to more subdivisions, but then this happened :D

 

do_2017-04-15_00.02.28.jpg

  • Like 2
Link to comment
Share on other sites

Alright, box mesh works well with this material, while the plane mesh does not. That doesn't make much sense to me, since I already made objects like columns with open edges and some of their polygons deleted, as they're never visible. They work okay and cast proper shadows.

Edited by Judith
Link to comment
Share on other sites

After several hours wasted, I finally found the source of the problem. Typically before exporting, you adjust mesh pivot for proper snapping, and you Align the pivot to the world (i.e. to current scene in 3smax), so the mesh isn't e.g. turned on one of the sides after importing it in game engine. YOU MUSN'T DO THIS IN DARKMOD. Looks like the initial rotation of the pivot is used by the idtech4 as a reference to calculate specularity and cubemaps for the polygons. When you align it to your scene in 3dsmax, you'll mess it up. You can still move the pivot, just don't rotate it. This is for ASE files btw., not sure how it works with LWO.

  • Like 1
Link to comment
Share on other sites

Thanks Biker, I already added it to my notes, this will be written huge block letters ;) To illustrate it better:

 

This is what you typically do before export. Notice the actual pivot (big arrows) aligned with the move gizmo in 3dsmax. This is what you should not be doing, even though you do that for all other game engines:

 

image.jpg

 

 

If you export your mesh and load your map, the lightning will look like this:

image.jpg

 

Don't mind the mesh distortion, I added it to see whether subdivisions help anything (they make it even worse). There are two lights here, btw. and it looks like there are many more. And see this weird stuff at the top?

 

 

Now, this is mesh with a pivot that didn't have any rotation/scene alignment. As you can see, axes are not aligned. And for idtech4 this is alright. In other game engines this piece would be imported horizontally.

image.jpg

 

 

And finally, everything is works as it should. The disaster has been averted ;)

image.jpg

Edited by Judith
  • Like 4
Link to comment
Share on other sites

  • 3 weeks later...

Slow but steady progress :)

 

I decided to iterate a bit on the roof section instead of rushing to texturing phase, and it paid off. It looks better and it should be more versatile to use (more on that later ;) ). I'm also pleased with the polygon budget (700 poly / 1400 tris). I managed to stay pretty low without compromising the silhouette too much. Althought that meant some tedious work and deleting faces player will never see. With proper smoothing and normalmaps, there will be a more complicated shape going along these edges and faces, so it will look more complex than it actually is. And, less polygons means easier unwrapping, so that's always a good thing.

 

Using symmetry helps a lot in controlling the texture space as well, so I can see whether I'll be using mirrored UVs or not. Roof, sure, but arches and wall sections could benefit from more unique space ;)

 

Clipboard02.png

Edited by Judith
Link to comment
Share on other sites

  • 4 weeks later...

I finally had some time to test a few things on my laptop, and while everything goes quite smoothly, I noticed a few things, performance-wise. First and most obvious is about lights: 3 overlapping and shadowcasting lights can bring down the framerate below 60 (it takes 4 nonshadows to do so). Also player going through two overlaping lights can cause the framerate to go down because of more complicated lightgem calculations? Just my guess.

 

But, my biggest surprise was that in some cases it's actually the ambient_world light that eats up considerable amount of performance. You can have no lights except the ambient_world, and the fps will go down, depending on your scene complexity. I turned off the vsync to see what numbers we're talking about, and it goes from 180 fps to 100 fps in a highly detailed, but also very static scene (basically a room full of meshes). So, when checking performance it might be useful to turn ambient_world on and off once in a while, to see whether it affects your map in any significant way.

Link to comment
Share on other sites

1) Is your ambient_world set to noshadows? Could be worth checking.

2) 60 FPS is not bad performance by any standard, even if you have a powerful PC. I'd take anything above 20 as good enough.

  • Like 1

Come the time of peril, did the ground gape, and did the dead rest unquiet 'gainst us. Our bands of iron and hammers of stone prevailed not, and some did doubt the Builder's plan. But the seals held strong, and the few did triumph, and the doubters were lain into the foundations of the new sanctum. -- Collected letters of the Smith-in-Exile, Civitas Approved

Link to comment
Share on other sites

1) No, actually. I never thought it might make a difference (will check it just in case).

 

2) It sure is. I use 60 FPS as a basic performance guide, i.e. if performance drops below 60, it's my fault, because I'm probably not using engine the way I should.

Link to comment
Share on other sites

Okay, checking don't cast shadows option didn't make any effect. I also took a closer look at fog light. While everything is fine so far in terms of performance, it increases triangle count quite a bit. In my corridor scene I use both ambient world and fog light. I checked all the lights so they're not overlapping, there are 4 of them.

Current readout: 144k tris.

 

When I delete the ambient world light: 75k tris.

When I delete both ambient world and fog light: 45k tris.

 

Performance with vsync off (old laptop, GF GT 740 M, 1360 x 768):

 

With amb_world & fog lights deleted: 120 FPS

With amb_world light only: 58 FPS (!)

With fog light only: 90 FPS

 

I always thought fog is resource consuming in games, but here it's kind of the other way around.

Edited by Judith
Link to comment
Share on other sites

I always thought fog is resource consuming in games, but here it's kind of the other way around.

 

Any light hitting a surface will cause its tris to be drawn again. Lights with multiple stages count as multiple lights, but we don't have many of those (if any).

 

Fog is only considered "expensive" because of the relatively small effect that it gives for the cost. It's cheaper than other light types because it uses a very cheap shader: it just adds some static colour to the tris that it hits, so it draws the tris again but it doesn't use the surface's diffuse, bump, or specular maps to do any complex shading which is what normal lights and ambient_world do.

  • Like 3
Link to comment
Share on other sites

Thanks for the clarification, it's always better to know how such things work to avoid surprises later.

 

I have one more question though. I built a simple room with one model lit by one omni light + one ambient light. The model is 500 tris, but the readout is roughly 6 times higher than that. Is it because of a light, or a complex shader? (diffuse+normal+specular+glow+cubemap reflections)

 

The_Dark_Mod_2017-06-07_08-10-50-20.png

 

But when I move the omni light away from the model, tris count is still quite high:

 

The_Dark_Mod_2017-06-07_08-14-44-73.png

 

When I delete the ambient light, it's still quite high:

 

Clipboard01.png

 

And when I put the omni light back (with ambient light still deleted):

 

Clipboard02.png

 

By the way, the omni light uses fallof_exp2, if that increases anything.

 

Now I commented out some image stages in the model shader, leaving only diffuse and normalmap:

Clipboard03.png

 

That's a big difference. Then I tried commenting out different stages, and it looks like the simple image shortcut stages have no impact at all, here's diffuse, normal, and specular active:

Clipboard04.png

 

 

Looks like the emissive (glow) map stage (blend add) and the cubemap stage added 1500 to the tris count for the model. Typically I just use _d, _n, and _s textures with no fancy things in shader, but this means you have to watch for more complex stuff.

 

Also, it seems like ambient world adds one more omni light calculation per object? When I deleted the ambient light, the tris count went down by 500, so the tris count for this model.

Edited by Judith
Link to comment
Share on other sites

The ambient light shader isn't very effective unfortunately. Switching to simple ambient already gives a good performance boost without any visual difference. I guess the shader needs reworking.

 

What are the specs of your laptop btw.? (Just to make your values comparable).

  • Like 1

FM's: Builder Roads, Old Habits, Old Habits Rebuild

Mapping and Scripting: Apples and Peaches

Sculptris Models and Tutorials: Obsttortes Models

My wiki articles: Obstipedia

Texture Blending in DR: DR ASE Blend Exporter

Link to comment
Share on other sites

Also, it looks like any stage in the material declaration that isn't image shortcut adds the equivalent of total triangles for the model to the count. "TDM Ambient Method Related" is an exception. Every other operation that needs to be between { } is basically a multiplier to the triangle count of your model.

Link to comment
Share on other sites

There's a certain base tri count that you will never get rid of. The HUD generates tris to be drawn. The biggest culprit is the console: every character shown on the console is 2 tris, and they do show up in the tri count. A console full of text is worth about 1500 tris if I remember right. Also the lightgem, and a few other things generate a handful of tris.

 

I always found that irritating in my renderer test maps. I used empty maps, no skybox, everything made of caulk except the one thing I wanted to test but the console tri counts varied by more than the thing I was trying to count!

  • Like 2
Link to comment
Share on other sites

Suggested test for your 500 tri model if you still have questions for it:

  • Put it in a simple caulk box room so there is nothing to be drawn but the model. No visportals or walls obstructing the view.
  • Add an ambient_world light covering the map (if you try to use no ambient_world, the game will go ahead and generate one for you so you might as well place it yourself so you know for sure where and what it is).
  • Add a simple light covering everything and a trigger to turn it on and off every second. (EDIT: or not, see below)
  • launch the map, kick off r_showprimitives 1 and con_noprint 0 then close the console
  • You should now have a constant amount of console text on screen. The difference in tris as the light turns on and off should be the tris of your model.

I'm not sure off hand whether model tris facing away from the light will be counted. There are so many optimisations in the engine that there's often a long explanation for the exact tri count. The engine has various ways to exclude parts of your model from being drawn, some of them in the engine itself (which means the tris won't be counted by r_showprimitives) and some in the GPU (which means the tris still get counted as "drawn", but they won't use up much GPU power as they don't get coloured in).

 

EDIT: You probably don't need a trigger come to think of it. Simply facing away from the model will be enough to stop it being drawn as long as you are a little distance away (so not in its bounding box).

Edited by SteveL
  • Like 2
Link to comment
Share on other sites

Also, it looks like any stage in the material declaration that isn't image shortcut adds the equivalent of total triangles for the model to the count. "TDM Ambient Method Related" is an exception. Every other operation that needs to be between { } is basically a multiplier to the triangle count of your model.

 

That's right. 2 stages are the same as 2 materials. In theory it's slightly faster to draw a model twice in a row than to draw 2 models. But I doubt anyone will ever notice. I tried to "break" the renderer by multiplying these things up enormously in test maps without ever making much difference. General scene complexity and shadow complexity is much more important than optimising any one feature like tri counts or draw calls on a model. My best advice is to be aware of what makes for good performance and work with it but not worry about it otherwise. Everything else that happens in a real map will completely drown out the effect of trimming a few thousand tris here and there.

  • Like 4
Link to comment
Share on other sites

Thanks for all the info. Yup, I've seen that rise of triangle count with console open, but I've been using r_showprimitives 1 and con_noprint 0 to avoid this. My map is basically 99% meshes surrounded with caulk, so I wanted to know where this high tris count comes from, as I'm pretty anal about keeping polycount as low as possible. So far it's not what brings framerate down (overlapping lights are more important to watch for).

 

As for optimizing draws, I found the SEED system and watch entity function to be very effective. In my corridor scene, the number of draws went from 650 to 400 just like that. I don't post any screens yet, because I want to show you the final "eye-candy" version, and that will take another few weeks. But I'm getting there ;)

  • Like 1
Link to comment
Share on other sites

Ok, so another experiment, testing limits on my desktop PC, i7 3,5 Ghz, GTX 1060 6 GB, running at 2560 x 1440. Ambient light, omni light (shadow-casting); 500 tris per object, duplicated 688 times before the framerate started to go below 60 FPS.

 

Clipboard01.png

 

So, to round it down just in case, it's 3000 draws / 1,6M tris / 230K shadows. This is without SEED and watch entity. Results with SEED on:

 

Clipboard02.png

 

Kind of pointing out the obvious, but if you work with loads of meshes, you have to use SEED.

I encountered one peculiar bug though. Maybe it has something to do with shaderparms 3 and 4, because this lamp uses table to animate the glow texture in the material, and I have a similar light material to sync the pulse with actual light. When I don't use SEED everything works ok, but when I include the model in the SEED, the light pulse increases its speed.

 

This is the table:

table cor_light01_pulsetable1 { {1, .75, 1, .65, .85, .75, 1, .8} }

 

And this is the animated glow in the material:

 

{
blend add
map textures/do/mesh/cor_lamp01_em_blu
rgb ((1 * cor_light01_pulsetable1[(time * (.1 + parm3) + parm4)]) + 0) // max value, speed, min value
// parm3 - speed, parm 4 - offset
// define shaderparms in light and model!
}

 

Both the light and the models have shaderparms 3 & 4 set to 0 for the slowest pulse. The light works as intended, the animated glow on the model is several times faster.

 

Anyway, next step would be to check performance limits on my laptop.

Edited by Judith
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

    • 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.
      · 1 reply
    • 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
    • OrbWeaver

      I like the new frob highlight but it would nice if it was less "flickery" while moving over objects (especially barred metal doors).
      · 4 replies
    • nbohr1more

      Please vote in the 15th Anniversary Contest Theme Poll
       
      · 0 replies
×
×
  • Create New...