Jump to content
The Dark Mod Forums

hide_distance broken again?


grayman

Recommended Posts

17 hours ago, MirceaKitsune said:

I'm seeing it with atdm:torch_gothic02_wall: Give it "dist_check_period 0.5" with "hide_distance 1000" and it will pop out together with its light source. Electric lights though, like atdm:streetlamp_round_lit, will not... it likely has to do with how their light source is defined or attached by comparison.

I'll have to learn some DR first for this it seems 😉

  

12 hours ago, geegee said:

I cant see using any kind of light pop-out/pop-in spawnarg.  Rather, I could see using a shadow/no_shadow hide_distance setting, which could be used more universally and quite unobtrusively. 

 

I think it's been mentioned a number of times in this thread now

Link to comment
Share on other sites

12 hours ago, geegee said:

I've been optimizing my map to boost fps from in a lot of cases 25-30 to 45-65, doing this systematically.  I have a newbie perspective, this being my first FM - so   ....  be kind.

First off, when building the .map I began by dropping in shadow/no_shadow lights with zero care - just looking to light the areas being worked on.  Same for entities, dropping them in with little care except for aesthetics and creating shadows for the player to hide in. That procedure made for a very unoptimized map. 

So, what's been the optimizing plan?  First, clean up the geometry.  Second, go thru' the map section by section, setting shadow/no_shadow on entities.   There's a tradeoff:  complexity of geometry multiplied by shadows gets out of hand, so a lot of care needed here.  With a first pass on that done, redo the lighting.  I eliminated all the small ambients I'd put in, whether shadowcasting or not, leaving just those lights attached to fixtures of some kind, which I wanted to be in general shadowcasting.  I reset these shadowcasters to not overlap so far as viable.  I was amazed to find that this made for a much much better looking map coupled with much more acceptable frame rates.  

I use hide_distance on entities sparingly as I don't like the pop-outs.  Not at all!   My map has a lot of transparent windows/doors.  I use func_portals with hide_distance set on every one of these.  Controlling pop-outs caused by func_portals is fairly simple.  The func_portal pop-outs tend to be marked by abrupt lighting changes.  These are very ugly and getting rid of them or making them unobtrusive is a priority.  

I cant see using any kind of light pop-out/pop-in spawnarg.  Rather, I could see using a shadow/no_shadow hide_distance setting, which could be used more universally and quite unobtrusively.  If that's possible now, please tell me how!  Also, I could see using a fade-to-black hide_distance on lights, so there'd be no lights a popping.

 

That plan is good; if possible, I'd probably move the lighting phase onto the first place. If you focus on placing shadow casters so they don't overlap, and using noshadows lights as often as possible, you should have fewer performance problems down the line while adding more objects and geometry (you should be less restricted in doing so).

That said, it's worth noting is that with stock TDM objects achieving good performance is an uphill battle, as they're not optimized like they typically are in games.

Link to comment
Share on other sites

4 hours ago, duzenko said:

I'll have to learn some DR first for this it seems 😉

No worries. If me providing some basics to test this is okay:

  • Open any working map in DR, in which the player can spawn and is large enough to test distance.
  • Right-click in any 2D viewport and choose "create entity". In the menu go to "The Dark Mod 2.0 (Standalone) - Lights - Model Lights, Static - Torches - atdm:torch_gothic02_wall" then click add.
  • Click-drag the entity around in the 2D viewports so it sits against a wall.
  • With it selected (Shift + Left-Click in 3D viewport if it got deselected) press the N key to open the entity inspector. In the two editable fields at the bottom, set the spawnarg at the top and its value at the bottom then press enter: You should see it get added in the list just above.
  • Save the map and open TDM. In the console use "dmap mapname" followed by "map mapname".
  • Like 1
Link to comment
Share on other sites

Completed: At revision: 9528  

Quote

Fixed the show/hide ambiguity in light entities behavior
Previously: hiding/showing light entities directly did not change the lit status, while hiding showing master entities did on/off the slave/team lights
After: both standalone and team lights on/off when they're shown/hidden

I hope it's not too breaking a change? @stgatilov @Springheel

  • Thanks 1
Link to comment
Share on other sites

11 minutes ago, duzenko said:

Completed: At revision: 9528  

I hope it's not too breaking a change? @stgatilov @Springheel

Wonderful! It's finally there at last. Thank you 😊

I think this is the best way in the end: Light hiding as a feature is good to have, especially when we already got it for meshes and all other entity types (it even seems to work on AI which is great). Then it's up to the mapper whether they feel this improves performance without being too visually disruptive, as it depends on how the map and lights are set up.

  • Haha 1
Link to comment
Share on other sites

Lol, performance has nothing to do with feelings, it's about hard data :D And since you've been so stubborn in pushing your agenda, you should at least show that it was worth the effort and make an example scene where this looks good.

Also, hide distance worked for AI for ages, but if you took more than a few seconds to examine how this works, it makes AI stop patrolling. If you use timing in your AI patrols to influence player pacing, and create interesting gameplay, this option is completely useless. It's only slightly above the feature that makes AI stop thinking when it's outside player view.

Link to comment
Share on other sites

7 minutes ago, peter_spy said:

Lol, performance has nothing to do with feelings, it's about hard data :D And since you've been so stubborn in pushing your agenda, you should at least show that it was worth the effort and make an example scene where this looks good.

Also, hide distance worked for AI for ages, but if you took more than a few seconds to examine how this works, it makes AI stop patrolling. If you use timing in your AI patrols to influence player pacing, and create interesting gameplay, this option is completely useless. It's only slightly above the feature that makes AI stop thinking when it's outside player view.

I'm not getting into this again. I understand you didn't want the feature and can respect that, albeit I don't see a reason: The only thing it does is complete an existing feature and give mappers proper control over their map's functionality and performance. Unless the default light entities are modified to use this (unlikely) nothing is going to change for existing maps, unless any added hide_distance on lights preemptively in the past in which case it was desired. You do NOT have to use it... if others get an improvement from it though, let them use it instead.

As for hiding putting AI into sleep, I noticed and can confirm that. I tested it on rats since they're a small detail, indeed they don't move while outside the player's hide_distance range. Technically this shouldn't happen if the spawnarg "neverdormant 1" is set... if that spawnarg is 0, AI should sleep while hidden then. The fix here would be to decide based on that setting.

Link to comment
Share on other sites

11 minutes ago, MirceaKitsune said:

albeit I don't see a reason: The only thing it does is complete an existing feature and give mappers proper control over their map's functionality and performance.

You don't see a reason because you lack experience and knowledge, you're so focused on "me me me, I want this, gimme!". I'm focused on the big picture, i.e. not being in a bubble, using the common knowledge and language, and working with what has already been established in gamedev, so the engine uses known workflows and isn't weird and insular for anyone coming here from outside.

21 minutes ago, duzenko said:

I did not know hiding AI makes them freeze? Sounds like a bug maybe?

Not sure, but if you use hide 1 on an AI, it stops patrolling. It is there e.g. playing random barks, although it does not appear on the showtris view ;) 

Edited by peter_spy
  • Sad 1
Link to comment
Share on other sites

I've got some lanterns near the top of a mountain in a large outdoor scene. When you look up at them from the foot of the mountain it's almost impossible to see what they light up, given their surroundings. With the way how the mountain path is made, you have to get quite close before you can properly see what these lanterns illuminate. For this scene an option to switch off those lights beyond x distance could be used.

Yeah, hide_distance for lights has strict limitations because in most cases the switch is glaringly obvious, but it's still a tool in the toolbox that has situations where it's suitable. Another such situation could be lights inside an apartment that has an open window to the streets, where you know it's not possible to get a clear view inside from further than x units.

@peter_spyWith modern workflows, you probably mean an alternative implementation of the LOD system compared to what TDM has?

  • Like 1
Link to comment
Share on other sites

20 minutes ago, Dragofer said:

With modern workflows, you probably mean an alternative implementation of the LOD system compared to what TDM has?

Not really alternative, more like "historically established" and widely known :) If you take a look at various descriptions and definitions from other engines, all LOD systems are about the same thing: https://forums.thedarkmod.com/index.php?/topic/17283-hide_distance-broken-again/page/4/&tab=comments#comment-463315

and TDM follows that. You can argue that it's a bit broken here and there, or it has some quirks (like with absolute distances from the model instead of relative ones, like everywhere else), but otherwise it's there :)

And in your example, you could simply hide stuff these lanterns light, because, as proven in the last screenshot in this post, the cost of your lights will be minimal: https://forums.thedarkmod.com/index.php?/topic/17283-hide_distance-broken-again/page/4/&tab=comments#comment-463272

20 minutes ago, Dragofer said:

Yeah, hide_distance for lights has strict limitations because in most cases the switch is glaringly obvious, but it's still a tool in the toolbox that has situations where it's suitable.

That's the thing, and I'm really curious to see this looking good and giving meaningful performance boost at the same time. Since other engines have been around for so many years, and none of them is doing that, I think it's pretty safe to assume that other developers already tried it and it wasn't worth it / looked awful.

As I said, it would be great to see a meaningful example, but so far we've got a lot of talking and examples that had nothing to do with the subject matter, despite explaining the thing several times over. Let's hope Kingsal comes up with something nice :)

Edited by peter_spy
Link to comment
Share on other sites

1 hour ago, peter_spy said:

And in your example, you could simply hide stuff these lanterns light

I hide most of the stuff up there already, but I do still want the lanterns themselves to be visible from a distance, since their purpose is to eventually attract the player's attention to this part of the map, despite their small size, thanks to their surfaces' high luminosity and their swinging motion. (They're quite far away - and .jpg compression makes this worse - because of how huge the geography is, but that's a misjudged scale problem common in first missions). As you can see the illumination itself is almost invisible.

onesteptoofar_2021-08-01_17_36_01.thumb.jpg.2c25df59a68717aec0d1a01708204ec2.jpg

onesteptoofar_2021-08-01_17_36_22.thumb.jpg.37ab8aed1d0c2092633dbf721681d45e.jpg

The cost of the light is probably very small, but probably no less than that of the crates and packages on that platform. If, as duzenko's earlier post suggests, hide_distance for lights is pretty much implemented already, it can just as well be used.

  • Like 1
Link to comment
Share on other sites

It's a double-ended stick for sure

Arguably it makes more sense\more useful to hide the light entity while retaining the interactions for everyday mapping (with a special spawnarg to override)

With enough mapper votes I might revert that commit so that _all_ lights remain ON even when their entities are hidden

But at any rate the standalone and team lights should behave similarly

  • Like 1
Link to comment
Share on other sites

1 hour ago, Dragofer said:

The cost of the light is probably very small, but probably no less than that of the crates and packages on that platform.

That's a good practical example you can analyze. If it isn't too much to ask, you can try taking stats screnshots from the same spot and camera angle with:

1) both light and objects visible

2) light entity hidden and objects visible

3) light visible and objects hidden

4) all hidden

The biggest stat difference will be between 1 and 4 obviously, but you should observe much bigger performance gain between 1 and 3, than from 1 and 2 or 3 and 4.

Edited by peter_spy
Link to comment
Share on other sites

If a mapper sets hide_distance on a light, it's because they want that light to be hidden and feel that works best. If anyone doesn't like the functionality they just don't set the parameter: There's no reason to make it do nothing or remove a model without its light which is incomplete functionality (hiding a part of an entity without the rest). Now that we have the feature at last I think this side of the issue can be put to rest: Mappers have this added possibility if they consider it necessary, as is right IMO. Of course it will be interesting to see how much it improve FPS in different setups from here.

One thing I can add: Small lights popping in and out after a certain distance don't feel very different from medium-large meshes doing so (including the default setup in some prefabs). At least on the lowest LOD setting which is what I use, both are as visually disruptive or as acceptable to me. Lights should use a slightly higher hide_distance than meshes of the same size of course, their disappearance is more noticeable... nothing that can't be made to work out though.

Support for fadein / fadeout range on lights too would be nice for this reason. Of course I am NOT that greedy to suggest implementing that too right now: I'm happy with how things are as of today, even if there's no transition this is good.

Edited by MirceaKitsune
Link to comment
Share on other sites

19 minutes ago, MirceaKitsune said:

which is incomplete functionality

Please stop pushing this nonsense, LOD system in TDM is and was a complete functionality already; it does what all other engines in the world do in that department. Your refusal / inability to understand the concept, and the context this system works in (proven by the wrong test maps you provided, despite several people giving you instructions), is your problem. Let others provide examples or test maps.

Edited by peter_spy
Link to comment
Share on other sites

1 hour ago, peter_spy said:

Please stop pushing this nonsense, LOD system in TDM is and was a complete functionality already; it does what all other engines in the world do in that department. Your refusal / inability to understand the concept, and the context this system works in (proven by the wrong test maps you provided, despite several people giving you instructions), is your problem. Let others provide examples or test maps.

Now is a great time to disengage

  • Like 2
Link to comment
Share on other sites

1 hour ago, peter_spy said:

Please stop pushing this nonsense, LOD system in TDM is and was a complete functionality already; it does what all other engines in the world do in that department. Your refusal / inability to understand the concept, and the context this system works in (proven by the wrong test maps you provided, despite several people giving you instructions), is your problem. Let others provide examples or test maps.

Okay... let me try putting this in a different way. hide_distance was created with the idea that mappers should be able to set a distance limit on all entities that have a visual component, particularly ones that can affect performance. This can include meshes, particles, lights, AI, etc... anything except worldspawn for obvious reasons, or objects in the skybox. This is the normal and intended functionality for this feature, to hide whatever you set it on.

Right now you're essentially upset because a limitation was lifted and a bug was fixed. As this was never a desired limitation, no one at any point said "we mustn't allow the hide distance to work on lights"; It's just that no happened to add those few lines of code that preform the check on light sources as well. duzenko was awesome today and provided a bugfix closing the gap. Indeed I highly support the change... not because I have nothing better to do, but because now I know I finally have the ability to customize my map and optimize large spaces to the best extent possible as I see fit.

I believe this is a good thing and we should move past it. With light hiding now working and out of the way, we should see if LOD remains broken for any other entities. The hide distance seems to be working almost perfectly right now with only tiny side issues, I'll further investigate those that I find and share them.

  • Haha 1
Link to comment
Share on other sites

Moving on: I did in fact find another glitch with the spawnargs, which I reported a few days ago but forgot to share here as well. noshadows_lod_1 will not work unless you also set hide_distance, despite the two being separate LOD functions. This seems to affect every func_static model, it won't stop casting shadows unless you also give it a hide distance.

Edit for clarification: This refers to lod noshadows on model entities, it has nothing to do with those lights! I was setting lod parameters on func_static models and noticed the noshadows property wouldn't work on a window mesh until I also set the extra parameter, the window was still a shadow caster after the given range.

https://bugs.thedarkmod.com/view.php?id=5691

Edited by MirceaKitsune
Clarification
  • Haha 1
Link to comment
Share on other sites

Ok, that's quite enough now. I don't want to hear another word on light entities and LOD unless someone has an actual showcase demonstrating the usefulness or absurdity of the feature. This "discussion" is getting nobody nowhere fast. What's done is done.

  • Like 3
Link to comment
Share on other sites

15 hours ago, duzenko said:

Completed: At revision: 9528
I hope it's not too breaking a change? @stgatilov @Springheel

Looks like restoring the original intent to me.

The potential for breaking something... exists indeed 😌

14 hours ago, duzenko said:

I did not know hiding AI makes them freeze? Sounds like a bug maybe?

This code is here since the very beginning.

And it seems that all "hide" methods remove clip contents, so they don't just change visual representation.

  • Like 1
  • Thanks 1
Link to comment
Share on other sites

20 hours ago, peter_spy said:

That's a good practical example you can analyze. If it isn't too much to ask, you can try taking stats screnshots from the same spot and camera angle with:

1) both light and objects visible

2) light entity hidden and objects visible

3) light visible and objects hidden

4) all hidden

The biggest stat difference will be between 1 and 4 obviously, but you should observe much bigger performance gain between 1 and 3, than from 1 and 2 or 3 and 4.

My results are as follows, with "objects" being 2 packages, 1 crate, 1 tub, all set to noshadows at this distance. The light itself is shadowcasting, since as far as I'm aware there's no noshadows_lod for lights:

[drawcalls, tris, shadowtris, VBO]
1) objects + light
	1346 	252195	28600	223559
2) objects
	1329	249083	28398	220649
3) light
	1321	248285	28600	219649
4) -
	1309	245915	28398	217481

Fps: always 60 (didn't uncap)

So the single light causes 12-17 drawcalls, while the group of 4 objects causes 20-25 drawcalls, depending on the extent of light interactions. A small difference in any case when it comes to LOD, but every bit counts, and this almost invisible light is ca. 1% of the drawcalls in that scene.

  • Like 1
  • Thanks 1
Link to comment
Share on other sites

Just a reminder: I don't have TDM properly set up to run from SVN, I'm waiting on the next dev snapshot to test the latest changes in my practical FM. If I see anything significant I may mention... kind of afraid to pursue the issue further :P

8 hours ago, stgatilov said:

This code is here since the very beginning.

And it seems that all "hide" methods remove clip contents, so they don't just change visual representation.

Didn't think of that, it makes sense in this case. If collisions also get disabled when an entity is hidden AI obviously can't navigate. If that's the case this is one that can't be resolved, and I'm fine with that if it's too problematic to attempt. hide_distance should work on AI too, but in this case mappers should be made aware it will put the AI into sleep.

Which reminds me: The dist_check_period and hide_distance parameters don't appear to be documented on AI entities in DarkRadiant, they work but DR treats them as custom undocumented values. I'd fix that if possible, while including the added spawnarg description that AI stop walking and reacting past the hiding distance.

Gotta ask though: If this is the case, how do AI still navigate in a room closed to the player by portals? Does that use a special type of hiding by comparison, so AI entities still have collisions while being derendered? What if we used the same system for hide_distance in the case of AI entities?

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.

  • Recent Status Updates

    • 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
    • Ansome

      Well then, it's been about a week since I released my first FM and I must say that I was very pleasantly surprised by its reception. I had expected half as much interest in my short little FM as I received and even less when it came to positive feedback, but I am glad that the aspects of my mission that I put the most heart into were often the most appreciated. It was also delightful to read plenty of honest criticism and helpful feedback, as I've already been given plenty of useful pointers on improving my brushwork, level design, and gameplay difficulty.
      I've gotten back into the groove of chipping away at my reading and game list, as well as the endless FM catalogue here, but I may very well try my hand at the 15th anniversary contest should it materialize. That is assuming my eyes are ready for a few more months of Dark Radiant's bright interface while burning the midnight oil, of course!
      · 4 replies
×
×
  • Create New...