LOD system ala Ground Zero Mod?

[Tels]

How does this compare to no LOD?

 

It doesn't make much difference, but I am still testing with more trees. Only 400 trees means most of them are visible anyway.

[stumpy]

hl2 uses sprites, of grass and bushes, that draw around the player and upto about 15 meters away depending on the darkness of the surrounding blend texture on terrain patches, the distance is restrictive due to the amount of sprites drawn at a time eats into the amount of objects you can have per level and in hl2 thats about 2048 max, I think detail props is restricted to 512 props drawn but not too sure.

 

Although in hl2, detail is restritive to where you place a blend texture, and how you paint it and the density values in the detail.vbsp file.

[Tels]

Ok, here is the verdict. Doing the LOD check once per second for 800 entities is basically free, compared to render about one tree or so

 

I doubled the number of trees to 800, and now there are 4 *moving* shadow casting torches in one giant room with no visportal:

 

 

* No LOD: 8..12 FPS

* LOD 1/s, distance 4000: about 8..12 FPS (same as no LOD as 4000 means about all trees are visible)

* LOD 1/s, distance 2000: about 15..20 FPS

* LOD 1/s, distance 1500: about 18..25 FPS

 

The number of entities used is still high, however, we could cheat and have a modeller combine f.i. one tree, one rock, a patch of flowers and a "tree-base-small-hill" into one model. Then we would use the same number of entities, but have a much more believable forest. Right now, each additional thing (rock, flower) would either be not LOD, or eat up one entity.

 

Edit:

 

More data this time with 1600 trees:

 

* no LOD: 4..5 FPS (killmonsters: 5..6 FPS)

* LOD distance 4000: 5 FPS (killmonsters 6 FPS)

* LOD distance 2000: 8..10 FPS (killmonsters 12..13 FPS)

* LOD distance 1500: 9..15 FPS (killmonsters 15 FPS) (fluctuating strongly)

 

So, LOD definitely helps.

 

Note that the map I test on is based on Fidcals startmap map, which means it already got about 30 AI (albeit in a closed off, different section),has an ambient_world etc.. "killmonsters" always causes a slight increase in FPS, so this is a real-world test (as long as the real world has a PC as I have

 

Anyway, I got another idea which I will explore tomorrow. More then

[Tels]

hl2 uses sprites, of grass and bushes, that draw around the player and upto about 15 meters away depending on the darkness of the surrounding blend texture on terrain patches, the distance is restrictive due to the amount of sprites drawn at a time eats into the amount of objects you can have per level and in hl2 thats about 2048 max, I think detail props is restricted to 512 props drawn but not too sure.

 

Although in hl2, detail is restritive to where you place a blend texture, and how you paint it and the density values in the detail.vbsp file.

 

That's all nice to know, but we use the D3 engine

[nbohr1more]

So the only question left is if LOD gradients like:

 

Full-Poly Mesh > Low Poly Mesh > Decal

 

or

 

Full-Poly Mesh > Lower Poly Mesh > Lowest Poly Mesh > Decal

 

...would have any benefit or... if each adding multiple distance-scale checks hurts things... ???

Edited June 17, 2010 by nbohr1more

[Fidcal]

Tels: tell us more about this def file. How can we make a new def with multiple models? This could have been used already to reduce entities. I never really thought of it before but I guess an AI is one entity but has a separate head mesh [edit: Plus maybe a sword plus a torch.] A candle or torch is one entity but might have a holder model, a candle model, and a flame. I'd really like to see your def for 50 trees whatever.

[Tels]

So the only question left is if LOD gradients like:

 

Full-Poly Mesh > Low Poly Mesh > Billboard

 

or

 

Full-Poly Mesh > Lower Poly Mesh > Lowest Poly Mesh > Billboard

 

...would have any benefit or... if each adding multiple distance-scale checks hurts things... ???

 

Since we do currently have no lower-poly-meshes and no billboard rendering (at least not in the 5-minute hack sense), I cannot test this. My test is mainly for areas where the player cannot look that far.

[Tels]

Tels: tell us more about this def file. How can we make a new def with multiple models? This could have been used already to reduce entities. I never really thought of it before but I guess an AI is one entity but has a separate head mesh [edit: Plus maybe a sword plus a torch.] A candle or torch is one entity but might have a holder model, a candle model, and a flame. I'd really like to see your def for 50 trees whatever.

 

As far as I know, having two models per entity is not supported - you need to attach a second entity to make that work, which defeats the purpose of saving one entity. But maybe we can hack that support into the general entity as "other models list" and just feed them of to the renderer? Probably needs D3 open source again *sigh*

 

Anyway, I just checked in a def file with the entities I used for testing, one tree model per entity, see tdm_lod.def

[nbohr1more]

Use a square table for the low-poly mesh? (I know it would look weird)

 

or a Barrel?

Edited June 17, 2010 by nbohr1more

[nbohr1more]

BTW, us lowly "Members" cant increase the Rep for "Team Members" can we?

 

Tels is the MAN!

 

(So is Ungoliant!!)

 

(nm, I found it!)

Edited June 17, 2010 by nbohr1more

[rich_is_bored]

How can we make a new def with multiple models?

 

Combine the models into a single file. Use a skin to set the materials of objects you want to hide to nodraw.

[nbohr1more]

If I understand the Skins tutorial correctly, this LOD method could also be used to:

 

1) Go from Texture with no Normals to a Texture with Normal Map depending on distance

 

2) Same as above but for Specular Map / Gloss Map

 

3) Change Shader complexity for LOD levels by associating shaders with textures in each LOD skin

 

 

????

 

(ALOT of asset creation required though... )

 

(rich_is_bored is also the MAN!!)

 

 

...obviously these LOD methods would need to be used sparingly...

Edited June 18, 2010 by nbohr1more

[Serpentine]

"LOD" for textures is not really required, while we do use quite a few (and will continue to put in more) high res textures, internally all textures that are well formed will have mipmaps, mipmapping reduces memory load substantially at distance as you drop pixel count by 3/4ths for each level, the resulting map is loads lighter. Added to that the user may opt to use lower resolution textures by default by selecting a lower setting. A mixed high/low detail texture approach is rather ugly too.

 

So all in all, I wouldn't bother looking into this. You could however download a copy of the last Ground Zero pre-release (since the project did die and I dont think assets/source was ever released) and look for interesting stuff in its files, the videos seem interesting however they use extremely low res textures and I have a feeling the buildings are just solid brushes with some extras bolted on to look 'dynamic'

[nbohr1more]

I've always speculated about doing things like having shorter shaders (SM 1.4) far away then using longer shaders close-up (SM 3.0) so that is my line of thinking

[Serpentine]

I've always speculated about doing things like having shorter shaders (SM 1.4) far away then using longer shaders close-up (SM 3.0) so that is my line of thinking

 

That might be a good idea for window glass etc, I wonder if it would work with the fragment shaders...

[Tels]

Combine the models into a single file. Use a skin to set the materials of objects you want to hide to nodraw.

 

That's what I said. If it is an ASE, maybe we can just copy&paste them together and modify the material in a text-editor? No luck with LWO, we need someone with a modelling program then.

 

However, it is totally unclear if a lower-poly model helps. Most of our models (esp the trees) are relatively low-poly to begin with, so one would not gain much. Note that in my test I *hid* the models after 2000 units and my system still struggled. If you'd replace them with lower-poly at 1500, and hide them at 2500, you'd still run slow and not have that a big forest to begin with.

 

The reason is that all these tricks require a full entity, while manually planting 1600 model-trees might be a bit faster (not tested it), but single models cannot be modified with LOD tricks. (or at least I don't know that we have access to the renderer for models).

[Tels]

That might be a good idea for window glass etc, I wonder if it would work with the fragment shaders...

 

Hm, one could simply swap the skin so that instead of the "glass-warp" shader, from a distance it uses a plain shader. OTOH, the shader engines are the most beefy ones on modern cards, and if the texture is far away, it also is small, meaning the shader does not have much to do to render the few pixels...

 

I think the most promising idea is to this in a series:

 

* use low-poly models

* turn off shadows

* hide the model and replace it with a billboard - If we had a one-size billboard model, the code could use the rotation hack to scale and orient it to make it face the player. Alternatively, one could hide the model and spawn a single-particle in place. In both cases one would need to texture it properly, tho.

* hide the entity completely

 

In any event, "hiding" the models shows that you can gain a lot, but even with these gains, giant forest are not something you can do unless everyone has the latest greatest PC.

[nbohr1more]

(my wife kicked me off promptly at 10pm so... I didn't get to create a coherent reply... )

 

After I left I realized that I had gotten carried away and those other LOD ideas are barking up the wrong tree (we don't really need to help the GPU, as Tels mentioned above...). But I remembered why I was thinking along those lines in the first place. Subsurface Scattering... That is a very expensive shader effect that is very subtle but looks great up-close. I remember folks pining for the effect when nVidia first put out their Fairy demo and then ATI put out another more advanced version for Marble materials for the X800 series I believe...

 

(Yup I was correct...)

 

ATI X800 Demos

 

 

I kept thinking that since you only really notice the effect up-close it would be a perfect candidate for something like LOD. Then I read that other subtle up-close material effects can be achieved by manipulating the specular map and gloss map so I figured the same could apply (I forgot that editing the gloss map and specular map is virtually free unlike Subsurface Scattering).

 

(edit)

HA! JC Denton's work already includes a good approximate Sub-Surface Scattering method! That HDR upgrade cant come soon enough

Edited June 25, 2010 by nbohr1more

[nbohr1more]

Well well well... looks like a great deal of this has been discussed before

 

Black Dog quoted by Orbweaver

 

(Sorry for the redundancy)

[nbohr1more]

Maybe Ground Zero's LOD wasn't all smoke and mirrors:

 

At a basic level the tool simply allows you to group entities (meshes, lights speakers, spawn locations, etc), and move or rotate them on a common origin. These groups are entities as well (we call them Multi-Constructors), so you can easily create groups of groups. These would allow you to break maps into layers of entities, and create "prefab" groups to re-use in different maps. Constructors can also pass arbitrary properties to child entities for script and game code functions.

 

...but performance (especially with all that nesting)???

 

Maybe some custom gamex86.dll hacks... Bah! It still looks like a scam, reminds me of kits to build a "Flying Car" in the back of Popular Science magazine...

[nbohr1more]

Okay! Now we've got some meat!!!!!!!!!

 

Details of Vertex Modification

 

With the exception of my TGA file parser, I do not use any outside libraries to combine models or create terrain(the TGA parser still uses the idFile system). As for where to find model information. All doom3 Entities have a renderEntity_t structure. This structure has a pointer called hModel that is of type idRenderModel (src\renderder\model.h). Every renderModel has a number of surfaces represented by a structure called srfTriangles_t. Within srfTriangles_t you can find (finally) the individual vertexes (and indexes...) that make up a mesh. The vertexes are of type idDrawVert, a class which we are given full access to (look in idLib\geometry). All you need to do to edit a mesh is play with the xyz vector. Well, it's actually a little trickier than that, as you have to first allocate a new surface for the renderModel to use, and once you've filled in the information for that surface, add it to the renderModel.

 

If anyone has a specific questions please ask away, and if you like I can post the code for the model combiner or the terrain generator(and you can all laugh at my horrid O(n^2) performance ).

 

 

... I'm sure there are a great number who would like the details he alluded to ...

 

Does the above mean anything to anyone (echo, echo, echo... and crickets... )

[Baddcog]

Honestly, why bother?

 

The issue with polys is shadow casting. All models have a low poly shadow mesh, takes care of that issue.

 

TF2 uses multiple LOD's, because things up close are very high poly, things medium distance are low poly... Because there is ALOT on screen (24 high poly players at once).

It looks terrible when the objects 'pop' to low poly, but it's fast intense gameplay so you rarely notice.

 

By the distance you'd need to change to low poly and not get a pop it should be vis-portalled around a corner anyway.

[Mortem Desino]

It's not entirely shadowcasting. Go to NHAT 3/3, and turn off r_shadows. Little difference.

 

Now, try turning off r_skipParticles (this will trim off a lot of polygonal particle emitters). Polys do make a significant difference, but usually so in outdoors, where polys show up galore.

[nbohr1more]

I brought up this topic in response to the possibility that FM authors will try to emulate the forest portion of "No Honor Among Thieves". Tels appears to have shown, through experiment, that for this specific example (forest) there is a tangible benefit for LOD.

 

...and there is a further, untested (AFAIK), issue of "entity" related performance. The authors of Ground Zero actually claimed that "entity" usage was a bigger performance factor than polygons. I believe that this is what may have prompted Tels to continue this line of investigation as the "entity" limit is of concern to any FM author that wants to create large missions.

 

The performance impact of coming close to or hitting the entity limit has not been broached as most FM's are not designed with massive numbers of entities in mind (the exact scenario that a forest invokes...).

 

I understand that LOD transitions are not pretty and I respect the artistic stance that this method is undesirable but I think Tels has given the TDM community the choice to utilize this tool or not. I also would understand that if you are a die-hard against Object LOD for aesthetic reasons that you fear that FMS authors will create missions that can only be playable on mainstream hardware with the use of LOD. I presume that most authors will be using this tool to allow low-end systems to play expansive missions rather than using LOD to push the technical limits on the high-end...This is indeed a valid concern but I suspect that our community will use good judgment. However, should an FMS author decide to try the latter and push technical boundaries at the expensive of LOD artifacts I think that is a better worse case scenario than having no LOD at all, wouldn't you?

[Tels]

Badcogg wrote:

 

Honestly, why bother?

 

The issue with polys is shadow casting. All models have a low poly shadow mesh, takes care of that issue.

 

It's not entirely shadowcasting. Go to NHAT 3/3, and turn off r_shadows. Little difference.

 

Now, try turning off r_skipParticles (this will trim off a lot of polygonal particle emitters). Polys do make a significant difference, but usually so in outdoors, where polys show up galore.

 

To chip in with that, it also helps for models that *don't* have low-poly shadow messages. For instance, our pine model has 2000 tris (and still looks like crap, sorry to say that, but a real pine tree looks different). But is also has 2000 shadow tris...

 

So a LOD system that can reduce the polys, turn off shadowcasting, and/or reduce the particle count is still valuable

 

Edit: The other reason to have it that you no longer need to get away with a one-size-fits-all approach. Without LOD, you design entities so that they look good *AND* have good performance, even if a few dozend are on screen. With a LOD system, you can have an entity that looks *gorgeous* from close-up (think: 5000 polys plus texture + normal map) and still allows you at the same time have *thousands* of them around (but they have only 500 polys when far away and are only a billboard from 500m). The "keep a short line-of-sight" approach badcogg mentions works only so far as that you have a short line of sight. Massive outdoor scenes are simply not possible with it at all, unless you count on it being an empty desert