Jump to content


Photo

My first map questions & work in progress

newbiequestions duh

264 replies to this topic

#226 Judith

Judith

    Advanced Member

  • Member
  • PipPipPip
  • 755 posts

Posted 14 April 2017 - 06:16 PM

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


  • Bikerdude, Goldwell and Anderson like this

#227 Judith

Judith

    Advanced Member

  • Member
  • PipPipPip
  • 755 posts

Posted 15 April 2017 - 07:06 AM

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, 15 April 2017 - 07:18 AM.


#228 Judith

Judith

    Advanced Member

  • Member
  • PipPipPip
  • 755 posts

Posted 15 April 2017 - 03:51 PM

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.


  • SteveL likes this

#229 Bikerdude

Bikerdude

    Mod hero

  • Member
  • PipPipPipPipPip
  • 19011 posts

Posted 15 April 2017 - 04:37 PM

Your texture/model work is over most people heads, including mine - keep up the good work ^_^


  • Judith likes this

#230 Judith

Judith

    Advanced Member

  • Member
  • PipPipPip
  • 755 posts

Posted 15 April 2017 - 05:14 PM

*
POPULAR

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, 15 April 2017 - 05:15 PM.

  • Bikerdude, PsymH, Moonbo and 2 others like this

#231 Judith

Judith

    Advanced Member

  • Member
  • PipPipPip
  • 755 posts

Posted 07 May 2017 - 09:38 AM

*
POPULAR

^ My god this material was hideous. This is how it's supposed to look: https://skfb.ly/67xtM

 

Also, after some initial problems, I can say that the roof section is shaping up quite nicely:

Clipboard01.jpg


Edited by Judith, 07 May 2017 - 01:39 PM.

  • Bikerdude, PsymH, nbohr1more and 2 others like this

#232 Judith

Judith

    Advanced Member

  • Member
  • PipPipPip
  • 755 posts

Posted 13 May 2017 - 05:03 AM

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, 13 May 2017 - 05:05 AM.


#233 Judith

Judith

    Advanced Member

  • Member
  • PipPipPip
  • 755 posts

Posted 06 June 2017 - 07:52 AM

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.



#234 Melan

Melan

    Contest Winner, Wordsmith

  • Campaign Dev
  • PipPipPipPip
  • 4399 posts

Posted 06 June 2017 - 07:59 AM

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.


  • Springheel and Bikerdude like this
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

#235 Judith

Judith

    Advanced Member

  • Member
  • PipPipPip
  • 755 posts

Posted 06 June 2017 - 08:26 AM

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.



#236 Judith

Judith

    Advanced Member

  • Member
  • PipPipPip
  • 755 posts

Posted 06 June 2017 - 10:56 AM

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, 06 June 2017 - 10:57 AM.


#237 SteveL

SteveL

    Hero Coder

  • Active Developer
  • PipPipPipPip
  • 3669 posts

Posted 06 June 2017 - 11:06 AM

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.


  • Judith, Moonbo and Anderson like this

#238 Judith

Judith

    Advanced Member

  • Member
  • PipPipPip
  • 755 posts

Posted 07 June 2017 - 01:47 AM

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, 07 June 2017 - 01:49 AM.


#239 Obsttorte

Obsttorte

    Scripting guru, Mapper

  • Active Developer
  • PipPipPipPipPip
  • 5337 posts

Posted 07 June 2017 - 01:54 AM

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).


  • CarltonTroisi likes this
FM's: Builder Roads, Old Habits, Old Habits Rebuild
WIP's: Several. Although after playing Thief 4 I really wanna make a city mission.
Mapping and Scripting: Apples and Peaches
Sculptris Models and Tutorials: Obsttortes Models
My wiki articles: Obstipedia
Let's Map TDM YouTube playlist: ObstlerTube
Texture Blending in DR: DR ASE Blend Exporter

End of shameless self promotion.

#240 Judith

Judith

    Advanced Member

  • Member
  • PipPipPip
  • 755 posts

Posted 07 June 2017 - 02:14 AM

It's MSI GP60 2OD with Intel i5 2,5 GHz CPU and GF 740M 2 GB, 8 GB ram, running at native resolution of 1366 x768. I think it's enough for a 60 FPS target platform, although I'm not 100% sure yet.



#241 Judith

Judith

    Advanced Member

  • Member
  • PipPipPip
  • 755 posts

Posted 07 June 2017 - 08:29 AM

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.



#242 SteveL

SteveL

    Hero Coder

  • Active Developer
  • PipPipPipPip
  • 3669 posts

Posted 07 June 2017 - 10:50 AM

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!


  • Judith and Anderson like this

#243 SteveL

SteveL

    Hero Coder

  • Active Developer
  • PipPipPipPip
  • 3669 posts

Posted 07 June 2017 - 11:18 AM

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, 07 June 2017 - 11:38 AM.

  • Judith and Anderson like this

#244 SteveL

SteveL

    Hero Coder

  • Active Developer
  • PipPipPipPip
  • 3669 posts

Posted 07 June 2017 - 11:24 AM

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.


  • Springheel, Judith, RPGista and 1 other like this

#245 Judith

Judith

    Advanced Member

  • Member
  • PipPipPip
  • 755 posts

Posted 07 June 2017 - 12:22 PM

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 ;)


  • nbohr1more likes this

#246 Judith

Judith

    Advanced Member

  • Member
  • PipPipPip
  • 755 posts

Posted 07 June 2017 - 12:58 PM

By the way, is it possible to make r_showprimitives 1 command to be read from autoexec.cfg and not crash the game? I put as many useful debuging commands as I can in my cfg file to avoid typing it every time I start the map.



#247 nbohr1more

nbohr1more

    Darkmod PR, Wordsmith

  • Development Role
  • PipPipPipPipPip
  • 8170 posts

Posted 07 June 2017 - 01:18 PM

Try adding it to an autocommands.cfg instead. autocommands delays the action until the map starts as I recall.


  • Judith, Anderson and SteveL like this
Please visit TDM's IndieDB site and help promote the mod:

http://www.indiedb.c...ds/the-dark-mod

(Yeah, shameless promotion... but traffic is traffic folks...)

#248 Judith

Judith

    Advanced Member

  • Member
  • PipPipPip
  • 755 posts

Posted 07 June 2017 - 01:35 PM

Yes, it works! It's active right away in main menu screen.



#249 Judith

Judith

    Advanced Member

  • Member
  • PipPipPip
  • 755 posts

Posted 08 June 2017 - 04:34 AM

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, 08 June 2017 - 07:08 AM.


#250 Judith

Judith

    Advanced Member

  • Member
  • PipPipPip
  • 755 posts

Posted 08 June 2017 - 05:04 AM

Oh, and just for fun, I wondered how many of these lamps I'll be able to stack with SEED on, before dipping below 60 FPS. Over 1300 ;)

 

Clipboard03.png





Reply to this topic



  


0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users