LOD system

[Bikerdude]

Baddcog told me via an email about the LOD system and how it can be used to cut down on stuff thats rendered when out of view or far away from the player etc.

 

I have never heard of it before, is there a wiki entry on the howto..

 

[update] found the following wiki - http://wiki.thedarkmod.com/index.php?title=LOD

 

but I would still like to hear peoplea take on the best way to use it..

Edited August 7, 2010 by Bikerdude

[Baddcog]

Me again

 

The very basics (and moist useful IMO) is what I emailed you. Just completely hiding an object based on distance.

 

If you set the distance to 500 units, when you reach 500 units away the object completely blinks out of existance and is no longer rendered.

It can take a bit of tweaking. Sometimes an object will completely be hidden by geometry 4 units way, but then you can get a glimpse of it from 700 units away. If it's a mushroom no big deal (the player probably wouldn't notice it was gone at 700 units).

 

So it takes fine tuning obj to object. In your map almost everything is rendered from one corner to another, but most stuff can't be seen over 500 units away. (ground stuff anyway)

 

Then when you get back to 500 units and closer it reappears.

---------

 

I didn't tell you but there is also a shadow command which will turn off shadows at distance. So maybe the stairs you'd want to have their shadows on when you are close, but not along ways away.

 

---------

The actual LOD stuff is more complicated and while Tels has it working doesn't really work in TDM (yet?).

 

It means Level of Detail.

So you can have a barrel with 3000 polys and shadow up close, but when you get to 200 units away the model is swapped to 2000 polys, get 400 units away and it's swapped to 1000 polys and the shadow turns off... Tels made it work for up to 7 levels.

 

The issue is is that it's new and we only have one statue with LOD models. So the usefulness is just turning stuff off right now.

 

He's also adding function that spawn and combine many objects (so you place a brush and it'll randomly spawn a forest basically). I don't think that's ready to go yet.

[Bikerdude]

Yeah I started reading that the LOD system is being re-written for TDM 1.03.

 

My only question at this point is what LOD args can I use on my existing Func_Statics, models and light sources so I can try and eak out some more perfomance on my map.

[Baddcog]

lod_hide_probability - set to one so they always hide (at set distance)

 

hide_distance

 

I probably wouldn't even mess with the shadows one.

[aidakeeley]

I have never heard of it before...

 

I think nbohr has alluded to it once or twice in an offhand roundabout passing btw mof tangential glancing...

[nbohr1more]

@Aida

 

Yes, I've brought it up a few times...

 

These are the Spawn Arguments:

 

"hide_distance" "If set greater than zero, this entity will hide itself when it is greater than this distance from the player. WARNING: Performance can be impacted if too many entities in a map use this feature."

"dist_check_period" "If hide_distance is used, this sets the interval between distance checks, in seconds. Default is 0.5 (500 milliseconds)."

"dist_check_xy" "If true, the LOD distance check is only done orthogonal to gravity, i.e., vertical distances aren't counted in it. Useful for things like rain clouds turning off/on."

 

...that's for the system that's currently available in 1.02 (options = either visible or invisible).

 

Tels made an example entity definition and passed it along to Fidcal from what I recall.

It's also broken due to a typo in the distance check period? (causes FPS to fluctuate wildly...).

 

More details in this thread:

 

http://modetwo.net/d...round-zero-mod/

 

(Try to ignore some of my raving and ranting )

 

(edited to exclude redundant internal syntax)

Edited August 8, 2010 by nbohr1more

[Bikerdude]

well for me it means I can hide a buch of tree's/ vergitation decals and other FS that are out of vew..

[nbohr1more]

Those arguments should work for your requirements Biker... but the performance benefits may be (?) inconsistent due to the "typo bug" in 1.02 (they should also work in 1.03 AFAIK).

[Bikerdude]

Those arguments should work for your requirements Biker... but the performance benefits may be (?) inconsistent due to the "typo bug" in 1.02 (they should also work in 1.03 AFAIK).

 

well if by the bug you mean the on off nature, that fine at this time as i want to stop the engine from rendering stuff thats not in direct line of site of the player. In fact when im done with my compo map I will implement this in my cathedral map and see if it improves things.

 

And on the subject of implementation, why wasnt it used on NHAT - I imagine it would have been immensely beneficial for the forest section..

[Baddcog]

Actually, I didn't know there was a bug in the code. So you probably want to test it in a different save. Sounds like it might make thing worse until 1.03... some kindof memory leak type thing.

 

NHAT was probably finished before the LOD system was even in place though I'm not sure of the timeline. I do know the LOD system is quite new though and Tels has been improving it quickly.

It's possible it could help in that section. As is hiding things might or might not have had bad effects in that one. Since it was a straight line through the forest you might've been able to see things in the distance appearing/disappearing. Hard to say without doing the work and looking. Probably at least the very farthest objects could have been hid.

 

But the model swapping would probably help it more, if we had lowpoly versions of trees as swapping distance models is less noticable than just making them vanish.

[Bikerdude]

lod_hide_probability - 1

hide_distance - 750

Ok tried this on my light entites on and nada

 

so gonna try -

 

editor_float hide_distance - 1

editor_float dist_check_period - 0.5

editor_bool dist_check_xy - true

 

in addition to the other args

 

again no effect.

Edited August 8, 2010 by Bikerdude

[Baddcog]

Actually not sure if it works on lights.

 

An easy test is to give them a distance of 100, then you can be close enough to watch things 'turn off' and disappear. If they do they work with the system.

 

And if you used a light entity for that lamp model it might be tough to hide the model itself. Settings on that entity adjust the light, not the model.

(so noshadows on a light entity make the LIGHT (not the model) cast noshadows. Then you get light bleed through walls, etc..)

 

I've never tried lights though obviously that would be a good way to save performance. A bit tougher though as you have to account for not only the light source but where it's light and shadows can be seen.

[nbohr1more]

There may be trade-offs with that approach Biker because as soon as you turn around to look at the objects that were out of view the engine will have to recompute silhouettes for anything that casts shadows and the engine will get hit with a bunch of draw calls. But I suppose for far away stuff that is behind you it should yield some benefit (meaning it will probably take some tweaking to find the optimal "make me invisible" distances). I would caution that this type of LOD use should not be used as a crutch for folks who are bad at working with visportals (for any newbs reading this... ) but it may help bulldozer some geometry away when you want it gone.

 

Actually NHAT was what inspired me to investigate Object LOD in Doom 3.

 

I always figured that Doom 3 had an Object LOD system like every other engine so I went running around Doom3world to see if there were any tricks to help it run better. I found out the Doom 3 does not have object LOD at all and there were serious questions about whether it could be made to work because you'd have to build it with what's available in the external SDK (instead of the Renderer). (When I posted the thread here I still couldn't believe that Doom 3 doesn't have a native LOD solution...)

 

I'm not sure Mortem Desino was aware that you could specify distance checks to make entities disappear when he worked on NHAT 3. (Given that it's kinda broken I don't think that it's a widely used feature...).

 

Edit (Late redundant post )

Edited August 8, 2010 by nbohr1more

[nbohr1more]

Oh yeah, lights cannot currently be culled via LOD. Not sure if that is just a lot of extra work or impossible (requires Source Code?). Probably just very difficult because of all the other custom SDK stuff Tels put into the lighting system. You'd have to treat every LOD light like an extinguishable candle?

Edited August 8, 2010 by nbohr1more

[Bikerdude]

Oh yeah, lights cannot currently be culled via LOD.

Arse, oh well, Ill just have to try it on some FS instead.....

[nbohr1more]

I don't think that:

 

lod_hide_probability - 1

hide_distance - 750

 

will work in 1.02...

 

XXXXXXXXXXXXXXXXXXXX

 

You will need to use:

 

editor_float hide_distance - 750

 

(OK... the "editor_float", etc... part is probably redundant to what happens in TDM and Dark Radiant internally... So editor_float hide_distance = hide_distance... if hide probability is not in 1.02 then it probably ignores it...)

Edited August 8, 2010 by nbohr1more

[Baddcog]

Other than a bug I'm not aware of making it decrease performance (as someone said above)

 

The hide system I posted DOES work (in 1.02), I'm using it in my city mission for various func_statics and objects.

[nbohr1more]

Cool!

[Bikerdude]

The hide system I posted DOES work (in 1.02), I'm using it in my city mission for various func_statics and objects.

 

BC can you do me a screenshot of the DR arg's window..?

[Baddcog]

BC can you do me a screenshot of the DR arg's window..?

 

 

 

That's for barrels that are in deep shadow and up a hill... So from the full view length I can't see them in the dark (or notice them missing anyway)

 

Guess I didn't even add a time, It probably defaults at 1 second interval (keep in mind that can almost be almost 2 seconds if the timer starts a new second right before you hit the threshhold. Doesn't matter too much for 1 second, but say you add 4, that can almost turn into 8. (I have a visportal that gets forced closed at distance set to 3, so I timed it by running at it and seeing if I ever saw it open).

[Bikerdude]

so the 'hide distance' was the only arg that was required, not like the 5 or so I have in my screenshot..

[Baddcog]

yep

[Bikerdude]

Other than a bug I'm not aware of making it decrease performance (as someone said above)

well applied the arg to various models and FS and it had a negative effect, I lost 5-10fps in certain places, bah - either I am doing something wrong or it wont work with my map..

Edited August 8, 2010 by Bikerdude

[nbohr1more]

Yeah... It makes the entities "think" about their "distance to you" so it will only be beneficial if that thinking takes less processor than the geometry that is being hidden. (works better when there is more "stuff" to hide.). The dist_check_period is where the bug is, it doesn't work well with fractions of a second. I think the default is one second so the bug may not be a problem there?

 

(damn Bold-ing can't un-bold...)

[Tels]

Yeah... It makes the entities "think" about their "distance to you" so it will only be beneficial if that thinking takes less processor than the geometry that is being hidden. (works better when there is more "stuff" to hide.). The dist_check_period is where the bug is, it doesn't work well with fractions of a second. I think the default is one second so the bug may not be a problem there?

 

(damn Bold-ing can't un-bold...)

 

Bold is fun!

 

Anyway:

 

in TDM 1.02:

 

* hide_distance does work when set to some Doom units (like 500, 1500 etc).

* dist_check_xy should only be used for things that are far over or under the head of the player and should still be visible in this case. E.g. rainclouds, or player on high tower but streetlamp below him should be visible.

* lod_hide_probability does not work (until TDM v1.03). Generally, any spawnarg named "lod_" or "lode_" will not work until v1.03

* dist_check_period means the entities "think" every frame, but only twice per second they consider checking their distance. That doesn't help performance that much (compared say to 0.0001). But it has mainly the benefit that if the player is very close/on top of the hide boundary, that objects don't blink in and out very rapidly. Due to floating point inaccuracies and what not it can be that in frame the engine thinks the player is 500.0001 units away, and the next frame 499.99998 units, meaning if the time is X frames, the object will blink every X*2 frames, in the worst case every other frame it is visible and then invisible again

* the bug alluded here to is that if you set the "dist_check_period" to 0.5 seconds, all the distchecks are done in the first half of a second, instead of the entire second. That means during 0.5 seconds the system does more work then the last half of the second, leading to slightly jumpy FPS, but ONLY if you have way more than 100 entities thinking and/or a lot of them hiding/unhiding. For most practical situations, it will not be visible.

 

For performance:

 

* 3000 entities using the LOD system use about 7% of CPU just for the checks (on my system), so if you have 10 or even 100 of them, the thinking itself will not use up any measurable CPU performance

* however, the actual hiding/unhiding will cause a brief loss of performance. But if you are standing still, it should have the (nearly) same performance as if you had not used the LOD system at all, see the point above

* generally, only hide entities if they have at least 100 tris or maybe even more OR you have hundreds of small entities. If you hide a 10 tris entity away, it might well be that the constant hiding/unhiding of entities when the player moves around makes the framerate jerky, but doesn't really help when the entities are hidden due to even 100 tris and one or two more drawcalls not making any FPS difference.