How to revert to Full if Level0 (3D LOD) doesn't exist?

[tamrieltwo]

I have many tree mods. Some tree mods have 3D LOD resources. For these, I want LOD4=Level0. 

However, some tree mods don't have 3D LOD resources, and for these, I want LOD4=Full, because I don't like billboards for LOD4 nd I don't really have time to make 3D Tree LOD models, I'd prefer to just use Full. (I will downscale textures before doing this, and I have a lot of VRAM spare).

How can I create a tree mesh rule that automatically switches between LOD4=Level0 and LOD4=Full, depending on whether an appropriate 3D LOD model exists in the data folder? I would prefer not to create many manual mesh rules to achieve this.

NearLOD doesn't do what I want because it will revert to Billboard1 if Level0 isn't available.

Edited October 13, 2023 by tamrieltwo

[sheson]

https://dyndolod.info/Official-DynDOLOD-Support-Forum#Post-Logs#Generating
Depending on the mesh mask rules the LOD for such trees will use (hybrid) 3D tree LOD models (if available) or use tree LOD billboards directly or as fallback in case a 3D tree LOD is not found. The default fallback is defined by the TreeFullFallBack=1 setting in ..\DynDOLOD\Edit Scripts\DynDOLOD\DynDOLOD_[GAME MODE].ini. 1 = Billboard, 2 = Bilboard2 etc.

From the INI
; Do not change this setting
; 0 -> FullModel; 1 -> Billboard1, 2 -> Billboard2, 3 -> Billboard3 etc. 
; NOTE: This setting changed meaning in version 2.44
; RTFM before changing this setting
; set to 0 to use tree full model for static object LOD instead of billboard if a tree 3D LOD model is not found
; this can create HUGE static object LOD files and can potentially cause CTD because of invalid nif settings copied to *.bto
; identify the largest full models and create 3D LOD models, see https://dyndolod.info/Help/3D-Tree-LOD-Model
; Do not set this to 0
TreeFullFallBack=1

The resolution of textures is typically not an issue. The complexity of models is which will cause long object LOD generation times and GBs of LOD meshes.

https://dyndolod.info/Help/Dynamic-LOD
Dynamic LOD uses two distances, the so called NearGrid and FarGrid to control the visibility (enable state) of the dynamic LOD references.

[tamrieltwo]

1 hour ago, sheson said:

https://dyndolod.info/Official-DynDOLOD-Support-Forum#Post-Logs#Generating
Depending on the mesh mask rules the LOD for such trees will use (hybrid) 3D tree LOD models (if available) or use tree LOD billboards directly or as fallback in case a 3D tree LOD is not found. The default fallback is defined by the TreeFullFallBack=1 setting in ..\DynDOLOD\Edit Scripts\DynDOLOD\DynDOLOD_[GAME MODE].ini. 1 = Billboard, 2 = Bilboard2 etc.

From the INI
; Do not change this setting
; 0 -> FullModel; 1 -> Billboard1, 2 -> Billboard2, 3 -> Billboard3 etc. 
; NOTE: This setting changed meaning in version 2.44
; RTFM before changing this setting
; set to 0 to use tree full model for static object LOD instead of billboard if a tree 3D LOD model is not found
; this can create HUGE static object LOD files and can potentially cause CTD because of invalid nif settings copied to *.bto
; identify the largest full models and create 3D LOD models, see https://dyndolod.info/Help/3D-Tree-LOD-Model
; Do not set this to 0
TreeFullFallBack=1

The resolution of textures is typically not an issue. The complexity of models is which will cause long object LOD generation times and GBs of LOD meshes.

https://dyndolod.info/Help/Dynamic-LOD
Dynamic LOD uses two distances, the so called NearGrid and FarGrid to control the visibility (enable state) of the dynamic LOD references.

Excellent, it worked, thank you.

I did some quick benchmarking: with fBlock0 of ~35,000, my FPS went down from 96 to 82 (a 1.8ms increase in latency) and my VRAM consumption increased by 3GB (i can probably optimize with 256 textures). I don't get frame stutters and have spare VRAM overhead, so I think I am OK overall. But it's only be viable on a RTX 4080/4090 or 7900XTX.

 

Edited October 13, 2023 by tamrieltwo

[Mousetick]

The increase in VRAM usage doesn't make a lot of sense.

You don't need to downscale textures, that's what mipmaps are for. Mipmaps are progressively downscaled versions of the full texture, e.g. 4K by 2K > 2K by 1 K > 1K by 512 > 512 by 256 > 256 by 128, and so on, down to 1x1 pixel. The GPU automatically selects the appropriate mipmap resolution based on the displayed surface dimensions depending on viewing distance. Do your textures have mipmaps?

Mipmaps increase VRAM usage but improve performance since the GPU doesn't have to rescale the full texture all the time.

[Mousetick]

Never mind, please ignore the previous comment. We're talking about object LOD and I'm completely wrong.

To understand the sharp increase in VRAM usage, you could compare the before/after sizes of the LOD texture atlas. For example, textures/dyndolod/lod/dyndolod_tamriel.dds. +3GB seems overly high.

You still don't need to downscale the textures. They're already downscaled by DynDOLOD when added to the LOD atlas.

Edited October 13, 2023 by Mousetick

[tamrieltwo]

On 10/13/2023 at 7:59 AM, Mousetick said:

Never mind, please ignore the previous comment. We're talking about object LOD and I'm completely wrong.

To understand the sharp increase in VRAM usage, you could compare the before/after sizes of the LOD texture atlas. For example, textures/dyndolod/lod/dyndolod_tamriel.dds. +3GB seems overly high.

You still don't need to downscale the textures. They're already downscaled by DynDOLOD when added to the LOD atlas.

Should I use LOD4=Full, or should I upgrade trees to Large reference using an older version of DynDOLOD? I know that both approaches are considered bad as a generality, but if I have to choose between one, which is better?

[z929669]

34 minutes ago, tamrieltwo said:

Should I use LOD4=Full, or should I upgrade trees to Large reference using an older version of DynDOLOD? I know that both approaches are considered bad as a generality, but if I have to choose between one, which is better?

I'm skeptical of this increase in VRAM usage. It's incredibly difficult/spurious to really determine VRAM usage changes, and with 6+ Gb GPU RAM, it's just not important, IMO. Full trees in LOD (or inefficient LOD models) crush FPS, not VRAM.

I'd personally take the time to make the needed LOD models using copies of the crowns and hybrid.bat as usual, because it's just as fast as all the work you're doing trying to test what works. But if for some reason you still don't want to do this, then use LOD4=Full mesh rules for the corresponding trees. This means you would need to know the names of all tree NIFs that don't have corresponding LOD models and could take a while to figure out the most efficient mask names to cover these and only these (maybe one rule for each tree at worst). Likewise, you could copy these full trees and name them as the LOD models with CRC32 into the LOD path, but this is also bad practice and could result in CTD if they have invalid NIF settings.

Regardless, it will require time and testing, so best to just create the LOD models for the trees that need them that are large enough to be valid as LOD. Sniff helps with mass editing NIFs. What tree mods are you using? A custom mixup mash?

[tamrieltwo]

17 minutes ago, z929669 said:

I'm skeptical of this increase in VRAM usage. It's incredibly difficult/spurious to really determine VRAM usage changes, and with 6+ Gb GPU RAM, it's just not important, IMO. Full trees in LOD (or inefficient LOD models) crush FPS, not VRAM.

I'd personally take the time to make the needed LOD models using copies of the crowns and hybrid.bat as usual, because it's just as fast as all the work you're doing trying to test what works. But if for some reason you still don't want to do this, then use LOD4=Full mesh rules for the corresponding trees. This means you would need to know the names of all tree NIFs that don't have corresponding LOD models and could take a while to figure out the most efficient mask names to cover these and only these (maybe one rule for each tree at worst). Likewise, you could copy these full trees and name them as the LOD models with CRC32 into the LOD path, but this is also bad practice and could result in CTD if they have invalid NIF settings.

Regardless, it will require time and testing, so best to just create the LOD models for the trees that need them that are large enough to be valid as LOD. Sniff helps with mass editing NIFs. What tree mods are you using? A custom mixup mash?

One solution (from sheson) is to have LOD4=Level0, then define TreeFullFallBack=0 in config, so that if 3D LOD doesn't exist, it will automatically fallback to LOD4=Full. So it's "easy", but my 32GB of RAM is struggling to run DynDOLOD with these settings, I keep getting C0000005 error during the lodgen step, probably due to running out of RAM.

So, now what I want to try is ticking the "Large" box in DynDOLOD to upgrade trees to large references. However, my DynDOLOD 3.0 Alpha (newest version) lacks the "Large" box. Was it removed in a current version?

This is odd, because in DynDOLOD_SSE.ini (from the newest release of DynDOLOD 3.0 Alpha), there is a setting that refers to the Large checkbox:

Quote

; minimum size for a tree to be considered large in case large reference workarounds are used and ultra tree LOD with the large option is checked
TreeLargeRefSize=400

 

Edited October 15, 2023 by tamrieltwo

[sheson]

4 hours ago, tamrieltwo said:

Should I use LOD4=Full, or should I upgrade trees to Large reference using an older version of DynDOLOD? I know that both approaches are considered bad as a generality, but if I have to choose between one, which is better?

Do not use full models for LOD, especially if they are used hundreds or even thousands of times. Create optimized 3D tree LOD models instead. https://dyndolod.info/Help/3D-Tree-LOD-Model

Why do you believe making trees large references is bad? it is obviously the better choice.

3 hours ago, tamrieltwo said:

So, now what I want to try is ticking the "Large" box in DynDOLOD to upgrade trees to large references. However, my DynDOLOD 3.0 Alpha (newest version) lacks the "Large" box. Was it removed in a current version?

Read https://dyndolod.info/Changelog to know what changed between versions.

The option to make trees large reference was obviously not removed.
https://dyndolod.info/Help/Large-Reference-Bugs-Workarounds and https://dyndolod.info/Help/Large-Reference-Bugs-Workarounds#Settings in particular.

[tamrieltwo]

18 minutes ago, sheson said:

Do not use full models for LOD, especially if they are used hundreds or even thousands of times. Create optimized 3D tree LOD models instead. https://dyndolod.info/Help/3D-Tree-LOD-Model

Why do you believe making trees large references is bad? it is obviously the better choice.

Read https://dyndolod.info/Changelog to know what changed between versions.

The option to make trees large reference was obviously not removed.
https://dyndolod.info/Help/Large-Reference-Bugs-Workarounds and https://dyndolod.info/Help/Large-Reference-Bugs-Workarounds#Settings in particular.

Thanks for the corrections.

I can't find the "Large" checkbox anywhere in the DynDOLOD 3.0 Alpha gui?

Reading https://dyndolod.info/Help/Large-Reference-Bugs-Workarounds#Settings, the image there has the "Large" box, but my DynDOLOD doesn't.

[sheson]

17 minutes ago, tamrieltwo said:

Thanks for the corrections.

I can't find the "Large" checkbox anywhere in the DynDOLOD 3.0 Alpha gui?

Reading https://dyndolod.info/Help/Large-Reference-Bugs-Workarounds#Settings, the image there has the "Large" box, but my DynDOLOD doesn't.

https://dyndolod.info/Official-DynDOLOD-Support-Forum#Post-Logs

https://dyndolod.info/Help/Large-Reference-Bugs-Workarounds
When DynDOLOD is started, a log message will notify if the large reference bugs workarounds are enabled, for example:
Large reference bugs workarounds: enabled (DynDOLOD.DLL: NG, Scripts: NG, Deleted references: no)