LOD system ala Ground Zero Mod?

[nbohr1more]

I have not seen this broached here before (lots of searching), it appears that another Doom 3 Mod has implemented an LOD system. I find this a bit confusing as there is already an LOD cvar in Doom 3 but perhaps that is just for texture LOD (verses mesh LOD)???

 

Anyway here is a link to a discussion of their techniques:

 

Ground Zero Mod

 

Have these ideas been broached by the TDM team?

 

I do not see any evidence in the modeling wikis that would instruct users to create LOD meshes...

 

(feel free to bring the beatdown if this is wiki'd elswhere)

 

What do you guys think?

 

 

Bonus: Perhaps to keep KRAZIES like me in line we should stickie a "Newbie TDM Technology Questions" thread?

 

(or a loony internet guys who faintly understand modding asking weird or incorrect questions thread)

[Fidcal]

We definitely need more thick vegetation. As well as looking good it helps to obscure harsh edges. In Alchemist I had to sink trees into the ground to simulate bushes.

 

But remind me what LOD means please. Is this like in Oblivion where vegetation is spawned based on distance? A quick search found so many defs for LOD I gave up. That forum link you gave also assumed prior knowledge. Were they generating something in game? Or written some external software that generates terrain models? Or a combination of both?

[aidakeeley]

Level Of Detail?

[rich_is_bored]

LOD - Level Of Detail where the geometric detail of models is reduced based on distance.

 

In the mod linked above a terrain mesh is dynamically reduced based on distance. In terms of general props, this can't be done dynamically. Instead you have to produce several versions of the same prop each with less detail and the engine swaps them out.

 

Two problems arise. First, nobody is making terrain meshes for their FMs. Second, all the props would need additional lower detail models.

[jdude]

Does anyone know how halflife 2 does it? I think it procedurally reduces the polycount of objects. However I do notice it a lot in that engine.

[STiFU]

Yeah, that's the general LOD approach. You also have sort of LOD on textures (Mipmapping), which is also designed for eliminating alias.

 

But I do think this could be applicable in TDM, when I look at NHAT for example. We would indeed need additional lowres props, but only for trees, gras and other bigger vegetation. Very small objects like stones or flowers could simply be eliminated based on the distance.

 

But couldn't "Render to texture" be used here to generate those lowres props? For example, a tree in the distance could be "rendered to texture", so that it could be used as a decal-texture on a simple plane.

[nbohr1more]

Well, even if only the Tree's had LOD applied, FMS authors that want to make their own take on NHAT's forest might have a chance of having decent performance without Mortem Desino's visportal wizardry... Or, could have even higher poly trees for the close-ups... (Or maybe a level like NHAT would run on my ole P4... )

 

I guess there might be some smoke 'n mirrors with Ground Zero's method though because I've heard of modders trying to use the AI system to manage LOD levels and that bogged down things more than it helped...

 

But if it worked, it would be a win!

[OrbWeaver]

But couldn't "Render to texture" be used here to generate those lowres props? For example, a tree in the distance could be "rendered to texture", so that it could be used as a decal-texture on a simple plane.

 

Insert standard response about the requirement for Doom 3 to be open-sourced here.

 

Unless you're just talking about how to create the low-details models in the first place, in which case rendering it as a billboarded decal would be one option.

[nbohr1more]

...actually, rather than using the AI SDK you could use the TRSGM's depth capture hack from my other crazy thread...

 

Depth Capture Hack

 

But there must be at least a few SDK interfaces that deal with distance from the player??? Maybe one of 'em has less CPU overhead than AI scripting?

 

I'm still kinda shocked that Doom 3 doesn't have a native Mesh LOD system...

[OrbWeaver]

I'm still kinda shocked that Doom 3 doesn't have a native Mesh LOD system...

 

It was never designed for that kind of scene. LOD is critical for expansive outdoor environments, while Doom 3 was optimised for dark shadowy corridors on a Mars base (which also happens to align with the goals of a Thief-like game).

[nbohr1more]

I know there are at least a few Image Quality perfectionists who "HATE" LOD levels, for these people NHAT 3/3 's forest is a Holy Grail of pristine geometry...

[Tels]

It was never designed for that kind of scene. LOD is critical for expansive outdoor environments, while Doom 3 was optimised for dark shadowy corridors on a Mars base (which also happens to align with the goals of a Thief-like game).

 

I think we have a distance-based portals? Don't we also have a hide/show-this-entity-based on distance? That all could be rolled into a home-grown LOD system. Might not be as fast as native, but if you absolutely want 10000 trees on a square kilometer, it would make it possible.

[OrbWeaver]

Oh yes, we have home-grown solutions; I was just answering nb-whats-his-face's question about why this sort of functionality wasn't already in the engine.

[nbohr1more]

Wow! Maybe I'll get off my duff and try to make some low-poly trees to expedite this!

[ungoliant]

I think we have a distance-based portals? Don't we also have a hide/show-this-entity-based on distance? That all could be rolled into a home-grown LOD system. Might not be as fast as native, but if you absolutely want 10000 trees on a square kilometer, it would make it possible.

 

yeah, I'm seeing how this could work. Put a billboarded tree decal/particle/whatever and a model tree on top of eachother, one set to hide at xxxxx distance, and the other set to show at xxxxx distance.

 

With a trick like that, either you could get more performance out of a mission like nhat 3/3, or you could set the portals further apart and/or set them to shut off at a farther distance.

[OrbWeaver]

Or, you may find that it makes absolutely no discernible difference to performance, if the complexity of your trees is not a bottleneck. All attempts to enhance performance that require a non-trivial amount of work to implement really need to be subjected to empirical testing first.

[nbohr1more]

Ungoliant's two-level LOD (mesh to billboard) looks pretty easy to test:

 

1) Find any decal billboard

2) Combine it with a Tree entity

3) Plunk a bazillion of 'em onto a blank map

4) change the hide/unhide distances and look at the FPS

 

...

 

you could even have a 2-mesh lod test with tree-mesh and ANY lower poly mesh in the inventory

 

(yeah I'm probably over-simplifying something)... (nobody uses Mr Sunglasses?)

Edited June 17, 2010 by nbohr1more

[Tels]

Hm, yeah, please make a testmap

 

Which reminds me, we probably need to increase the entity limit, 8192 won't reach that far if each tree eats two entities.

 

Edit:

 

However, if it really works, we can easily add something in the C++ code that not just hides the entity, but spawns in it's place a (spawnarg based) particle. That way we save half the entities.

 

Relevant spawnargs:

 

       "editor_float 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."
       "editor_float dist_check_period" "If hide_distance is used, this sets the interval between distance checks, in seconds.  Default is 0.5 (500 milliseconds)."
       "editor_bool 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."

[STiFU]

If such a testmap was created, shadowcasting lights and AI should also be added to simulate actual ingame scenarios.

[nbohr1more]

Oh I've done it now... I was hoping to wait 'till my wife's visit to California in August to go through the tutorials and make a simple FMS... Now it looks like I gave myself a crash-course deadline to create something ...

 

(foot in mouth indeed)

[Tels]

Currently building a testmap, stand by

[nbohr1more]

:):):):):):):) (I love Science!!!!!!!!!)

[Tels]

:):):):):):):) (I love Science!!!!!!!!!)

 

 

Preliminary test results:

 

My system always alternates between FPS numbers, counting down and up in about 2s. Not sure why.

 

* 150 trees + 2 shadow casting lights - 22..33 FPS with every 1s distance check. Reducing the time to 0.1s makes a very small drop in FPS (25..30), decreasing it 0.05s drops them to about 19..25. So the distance check doesn't use that much time. However, once per second is enough, the player doesn't run that fast.

 

* distance: 500 way too small, 1000 usable, at 1500 you seldem see the trees pop, at 2000 you see it only if you watch closely and have a light underground so you can see a trunk pop. 2000 most practical value, for performance reasons maybe choose 1800.

 

* 400 trees plus the same 2 lights: 18..25 FPS with 1s and distance 2000.

 

Next I am gonna try to double the forest in each dimension (should need 1600 trees then), then we can see how the system fares then.

 

The downside of the distance check is that each tree uses up one entity. (So I made a new def file with them, will be in v1.03 I'd say Anyway, you cannot have more than say 7000 trees, ever, because you need to leave room for other items etc. I am having some ideas how one could make an "unlimited forest" but it clearly needs code support and whether it is worth it, I don't know.

 

* low priority (because it is fast enough already): Idea for faster distance check: see if we can optimize it (does it run only for visible entities etc)

 

[nbohr1more]

Thanks so much for this test!!! My OCD has finally quieted! I look forward to v1.03!!!

[Springheel]

* 150 trees + 2 shadow casting lights - 22..33 FPS with every 1s distance check.

 

How does this compare to no LOD?