hide_distance broken again?

[peter_spy]

42 minutes ago, Dragofer said:

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.

Yup, the above makes sense. If you have an ambient + foglight + one regular light hitting those objects, they are already drawn 4 times. So hiding a light has the least impact, because you just remove one light pass + shadows (vs hiding objects, which removes all light passes and shadows).

Perhaps one other thing to note is that the savings might look high, even with hiding just a light, because of the high material count and complexity stock TDM models can have (e.g. 5-8 materials per model). That much less of a gain with models typically optimized for games (using 1-2 materials max).

[duzenko]

3 hours ago, MirceaKitsune said:

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?

You're kinda answering your own question

If you want the AI to still have collisions then use a visportal closed by distance

[nbohr1more]

As long as you aren't hiding monster clip, path finding should work as expected.

[MirceaKitsune]

5 hours ago, nbohr1more said:

As long as you aren't hiding monster clip, path finding should work as expected.

Yes, but you also need to know the size of the AI, correct? And I believe it doesn't use a simple bounding box you can just store, but its own animated collision model... drawing this conclusion from how AI playing certain animations push the player away if they're standing right next to the AI.

[Dragofer]

Seems odd that a visual performance optimisation makes the entities become nonsolid. I've got an arrow stuck in some LOD-enabled wooden beams and when the player is over 1500 units away the arrow drops to the floor. The same could happen to i.e. a readable resting on a LOD-enabled crate, causing the readable to go unnoticed.

Surely we'd want LOD to use a hide method that doesn't switch off solidity?

[peter_spy]

58 minutes ago, Dragofer said:

Seems odd that a visual performance optimisation makes the entities become nonsolid.

Yeah, and I think there is this quirk with hide 0/1 as well. If you set an entity to hide 1, it will go invisible on map start, but it will be solid. Set it to 0 and change it to 1 during gameplay, e.g. via trigger, the result will be nonsolid. Is it because of how .cm or .proc files are calculated?

Edited August 3, 2021 by peter_spy

[kingsal]

On 8/3/2021 at 2:33 AM, Dragofer said:

Seems odd that a visual performance optimisation makes the entities become nonsolid. I've got an arrow stuck in some LOD-enabled wooden beams and when the player is over 1500 units away the arrow drops to the floor. 

That shouldn't be happening. Out of curiosity does the model or its LOD  have a collision mesh? This won't happen to moveables  AFIK since their collisions meshes are kept. 

[duzenko]

@stgatilovI'd like a second opinion on hide_distance CPU usage

Suppose we have 1000 entities in a large fairly optimized map that use LOD

All set to hide_distance 0.5

Is it a valid assumption that all these 1000 entities will calculate their LOD on the same game tick twice a second? Wouldn't it cause micro-stutter?

[Dragofer]

5 hours ago, kingsal said:

That shouldn't be happening. Out of curiosity does the model or its LOD  have a collision mesh? This won't happen to moveables  AFIK since their collisions meshes are kept. 

This was just some plain func_static wooden beams made out of patches, with a 'stuck' version of a broadhead arrow lodged in one of them. Only the beams had any kind of LOD, hide_distance, enabled.

Stuck arrows probably shouldn't be moveables anyway.

[stgatilov]

1 hour ago, duzenko said:

Suppose we have 1000 entities in a large fairly optimized map that use LOD

All set to hide_distance 0.5

Is it a valid assumption that all these 1000 entities will calculate their LOD on the same game tick twice a second? Wouldn't it cause micro-stutter?

First find a map with 1000 LOD entities, then bother

Indeed, if entities all think about LOD at the same time, it can cause a stutter. Although the code which checks LOD does not look as heavy, I'm not even sure 1000 entities will be enough. Moreover, they are actually spread randomly across frames:

	// add some phase diversity to the checks so that they don't all run in one frame
	// make sure they all run on the first frame though, by initializing m_TimeStamp to
	// be at least one interval early.
	// old code, only using half the interval:
	m_DistCheckTimeStamp = gameLocal.time - (int) (m_LOD->DistCheckInterval * (1.0f + gameLocal.random.RandomFloat()) );

 

[peter_spy]

1 hour ago, Dragofer said:

This was just some plain func_static wooden beams made out of patches, with a 'stuck' version of a broadhead arrow lodged in one of them. Only the beams had any kind of LOD, hide_distance, enabled.

Stuck arrows probably shouldn't be moveables anyway.

Have you tried making a beam with wood material, shooting a broadhead or rope arrow into it and then moving away beyond the hide distance? That seems like more practical example to me.

Edit: to answer my own question, they appear and disappear along with the wood beam, nice! It seems like you found a corner case @Dragofer.

Edited August 7, 2021 by peter_spy

[duzenko]

I just realized that hide_distance is actually nothing more than the last LOD distance

It was supposed to virtualize the logic so that the user does not need to remember which lod_X_distance was the last one

[Dragofer]

@peter_spy Nice, and yes I can confirm that an arrow shot ingame into a LOD object stays where it's meant to be. Looks like this is an issue that happens at map start on LOD objects that start hidden.

[peter_spy]

7 minutes ago, Dragofer said:

Looks like this is an issue that happens at map start on LOD objects that start hidden.

Yup. If you place IdMoveables on a model with LOD that is hidden at map start, they will fall on the floor. If the model is visible and you move away beyond the hide distance, they stay where they are.

[MirceaKitsune]

5 hours ago, duzenko said:

@stgatilovI'd like a second opinion on hide_distance CPU usage

Suppose we have 1000 entities in a large fairly optimized map that use LOD

All set to hide_distance 0.5

Is it a valid assumption that all these 1000 entities will calculate their LOD on the same game tick twice a second? Wouldn't it cause micro-stutter?

The first question that comes to mind on that is how costly is the distance itself to calculate, especially at the default dist_check_period of 0.5. As far as I can tell without knowing the code, the check simply uses the origin of the entity and that of the player's view to compute a distance float, only deciding to do anything if that float is below or beyond a certain value. Should be a very easy mathematical operation on the CPU: I'd suspect even 1 million of them should be possible to calculate with ease, though that's purely an assumption not a fact and this should be tested before drawing a conclusion.

[kingsal]

11 hours ago, Dragofer said:

This was just some plain func_static wooden beams made out of patches, with a 'stuck' version of a broadhead arrow lodged in one of them. Only the beams had any kind of LOD, hide_distance, enabled.

Stuck arrows probably shouldn't be moveables anyway.

Interesting, stuck arrows are not moveables. They inherit a weapon_arrow_base which is its own special thing. I was referring to general moveables (crates and the like) will keep their collisions meshes even when their physical models are hidden. Although thats not to say there aren't bugs that could occur here. 

I could see an arrow appearing and disappearing, but dropping to the floor is pretty odd considering they are bound to the entity they are stuck to.  

[HMart]

7 hours ago, MirceaKitsune said:

The first question that comes to mind on that is how costly is the distance itself to calculate, especially at the default dist_check_period of 0.5. As far as I can tell without knowing the code, the check simply uses the origin of the entity and that of the player's view to compute a distance float, only deciding to do anything if that float is below or beyond a certain value. Should be a very easy mathematical operation on the CPU: I'd suspect even 1 million of them should be possible to calculate with ease, though that's purely an assumption not a fact and this should be tested before drawing a conclusion.

That is how my own simple LOD system works, it does a origin to origin float distance number and I have yet to see any major problem with it, but I will not claim that I have tested it that much, specially in a complex scene with hundreds of LOD entities.

I do make sure to do the check, only when the player is within the same area has the LOD object and the player is moving, no need to do it, if the player is stationary or the distance value didn't changed that much between frames. I also do the check in a larger interval, if the entity itself is totally hidden. 

Btw would love to do the LOD, based on size of object in pixel/screen space, (size of object on screen) like Unreal Engine does but currently I don't know how to do that, if someone has a hint...  

[peter_spy]

That was written in 2010: https://wiki.thedarkmod.com/index.php?title=LOD#Performance

Given how many CPU generations we've seen since, I'd hazard a guess that you'll have a hard time creating a substantial CPU load, even if you had 16k thinking entities (which is the current limit IIRC).

[MirceaKitsune]

Just updated to the new snapshot that was just made available (dev16342-9552) which contains all changes made to LOD and hide_distance recently, including the controversial light hiding but also fixing noshadows_lod_# and other fixes. Wanted to say my map's performance has improved ever so slightly but noticeably so! In a spot where I previously had some 1.300.000 tris reported I now get 1.000.000 and moving the mouse practically feels a bit smoother when looking around. New functionality is great and all the changes were worth it, cheers to duzenko and the others once more for those fantastic fixes

[peter_spy]

Still waiting for an example where hiding a light both makes a meaningful difference and doesn't change visuals.

Edited August 8, 2021 by peter_spy

[MirceaKitsune]

I do NOT wish to revive the discussion on how useful hide_distance for lights is if possible, not because I mind but due to how hot the issue remains. However I must bring up some issues I discovered in the current implementation, after trying the latest snapshot and finding some breakage on my map where the feature is now being used. As I'm among those who wanted this the most and am actively testing it, it more so feels my duty to report anything it might be breaking.

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

Essentially torches aren't hidden by default, their light source shows up until you enter the hide_distance then exit it. It also ignores lights that start or were turned off... a lamp disabled by a trigger will show up as lit when you get near it, instead of appearing as the unlit / extinguished model unless it gets triggered again while shown or hidden.

With this occasion I noted another problem which isn't light exclusive but affects even func_static ents: If you set "hide 1" on a mesh but also give it "hide_distance #", the LOD overrides the hide parameter causing the entity to become shown / hidden with distance exclusively. Ideally the two shouldn't conflict: A model with both spawnargs set should dhow up when both within hide_distance AND not hidden. Remember that hide can be toggled by triggers.

[peter_spy]

There is no point in investing time in a feature which is doubtful to begin with, just because one person on the forums refuses to acknowledge that LOD refers to models, as it stands for Level Of Detail, and not Lights Off, Dumbass.

[MirceaKitsune]

Please. I literally found a bug and wanted to make sure the team is aware so we don't have a release with broken functionality that would be brought up later. I was thinking of not reporting those issues because I knew you're going to see it. You don't need to respond if this doesn't interest you, but let us discuss bug reports at least.

Edited August 9, 2021 by MirceaKitsune

[peter_spy]

So, at least now you acknowledge that hiding lights is a new functionality. Last time it was a "limitation" and a "bug" to be fixed Although I have no doubt that you'll entertain us with another convenient explanation for that.

Edited August 9, 2021 by peter_spy

[MirceaKitsune]

Yes: A limitation in the hiding code was lifted, the bug was that it was ignoring light entities entirely, now it allows the functionality of hiding those too like literally all other entity types. You aren't even making sense any more... now you're nitpicking at words to find a reason why I must be stupid because I supported a change you don't like. How much longer do we have to keep doing this? Because I'm not interested in entertaining it whenever I try to have a discussion here. Again I ask that you please let us discuss the LOD system without trying to start drama each time this comes up in some form, before this thread is gonna need to be closed over it. Thank you.

Edited August 9, 2021 by MirceaKitsune