FNVLODGen

Post by **zilav** » Sat Mar 21, 2015 8:23 am

I need help understanding some aspects of lod in FalloutNV. It mostly works the same as Skyrim, except one issue.

Objects lod files are located in meshes\landscape\lod\wastelandnv\blocks\ folder for vanilla worldspace, however there are several files that have "high" word in name. For example

meshes\landscape\lod\wastelandnv\blocks\wastelandnv.level4.high.x-20.y-28.nif

meshes\landscape\lod\wastelandnv\blocks\wastelandnv.level4.x-20.y-28.nif

Those have the same grid coordinates, "high" version contains handshaking statue if you open it in NifScope

http://i.imgur.com/LdCmfb2.png

Ordinary file has the statue too and additional objects from surrounding cells. The question is - when, how and under what conditions those "high" lod files are generated and used by the game?

Post by **RoyBatty** » Sat Mar 21, 2015 10:06 am

hrm doesn't Fallout have 2 different LOD levels, one for very distant, one for mid. Maybe checking the flags for "visible when distant" ?

Under the terrain manager settings in FalloutPrefs.ini there is these settings which control the LOD

fLowBlockLoadDistanceLow

fHighBlockLoadDistanceLow

fLowTreeLoadDistance

fHighTreeLoadDistance

Perhaps they are related, if some of them are set too high mid distance LOD changes from lower poly to higher poly at the wrong time or even it disappears totally.

Post by **zilav** » Sat Mar 21, 2015 10:59 am

Probably, but how to differentiate between low and high lod models? Is there anything in GECK for static records?

Post by **sesom** » Sat Mar 21, 2015 11:20 am

NVMojOutpostStatue01 has the "Visible when Distant" set. I hope it is the differentiation that you are looking for.

Post by **RoyBatty** » Sat Mar 21, 2015 12:10 pm

From what I understand to properly generate LOD, both high and low tri count models are needed. The low ones are needed for LOD generation and aren't shipped with the game from what I've seen, where as the high ones are. When dealing with the Tree LOD issues that TTW was having, some stuff was changed about the "visible when distant" flags and GECK complains that there is no LOD low model for them.

It's a kludge to fix the very low tri LOD models from showing up as duplicates over the high ones. It became obvious that New Vegas did not have proper LOD generated for the plants and tree's because Obsidian did not understand the system completely, or perhaps the engine was changed to generate it as object LOD instead. It's a puzzle, and there is a discussion thread in the mod author sub on the nexus about it. Several contributors to the thread were going to update the wiki with better more complete info about LOD generation, and perhaps they have done so as this discussion was only last month.

Other team members know a lot about it too, Chuck, Tricky and sesom can probably answer some of the questions.

The Truancy Factory blog has a lot of info too, and perhaps contacting the owner would be helpful.

Post by **TrickyVein** » Sat Mar 21, 2015 2:55 pm

There's an option when generating LOD to tick 'high priority' for models that are also visible when distant. This makes sure that their LOD blocks are visible from the furthest distance away, which is the only difference I've seen between 'high' and 'normal' priority LOD blocks.

Probably, but how to differentiate between low and high lod models? Is there anything in GECK for static records?

All LOD models are treated the same. There are no 'high-poly' and 'low-poly' LOD models for static objects that I'm aware of. Every LOD model that was used in NV was shipped with the game. Only the textures in the source folder for those models were not.

Yes, the GECK can view static objects but NOT LOD objects for those static objects, unless they too are imported as new static objects into the GECK. But then you might as well just view them in NifSkope.

Post by **zilav** » Sat Mar 21, 2015 8:19 pm

Thank you all!

Seems that High Priority is what I need. Does it apply only to statics or that flag is available for static collections too? Unfortunately FNVEdit source code has the same flags for all records, so I can't check that myself without GECK.

Post by **sesom** » Sat Mar 21, 2015 8:50 pm

The "High Priority LOD" is set on the reference. So it can apply to SCOLs too (not sure if it is used in game).

Post by **RoyBatty** » Sat Mar 21, 2015 10:52 pm

F3/FNV LOD gen must be different then, or maybe it's different for tree's.

Post by **zilav** » Thu Mar 26, 2015 6:31 am

Regarding Trees LOD in fallouts. First please read TES5LODGen description page on how LOD works in Skyrim since it inherited Fallout's LOD and they are very similar.

Trees LOD in fallout has slightly different naming for files

meshes\landscape\lod\<worldspace>\trees\<worldspace>.*.*.*.dtl those files have the same format as *.btt in Skyrim

meshes\landscape\lod\<worldspace>\trees\treetypes.lst, also the same format as in Skyrim.

But the last difference is a nail in the coffin, atlas file holding flat images for trees lod in a worldspace

textures\landscape\trees\treedeadlod.dds

Yes, there is no worldspace name at all, it is a hardcoded LOD texture for all worldspaces in the game. The only "difference" is if worldspace editorid starts with "DLC4" game will use textures\landscape\trees\treeswamplod.dds, and this is hardcoded too (hello Point Lookout).

LODGen for trees builds atlas itself from separate LOD images of trees used in a worldspace. Since the atlas is common in fallout, trees LOD must be built for all worldspace at the same time. I just don't want to do that honestly, this will make running FNVLODGen a mandatory when any tree is changed in any worldspace in the game.

Unless you have contacts with people who can reverse engineer engine and create NVSE plugin to override used atlas texture name for worldspace similar to Skyrim one, like textures\landscape\lod\<worldspace>\trees\<worldspace>treelod.dds and fall back to default procedure of atlas naming if this texture doesn't exist for the current worldspace, I don't see any point in doing trees lod for fallouts at all. Only objects LOD will be generated by FNVLODGen for now.