guide on how to get LOD glow windows for custom models?

[glarthirs_body]

I have designed a custom building model, and with it, I have a custom LOD model for my building. As my building has exterior windows with glow, I have additionally made LOD models for the windows. I want to use DYNDOLOD to thus enable my LOD building model to also use the LOD window model.

 

There are no guides for this in the manual, as the section dedicated to describing LOD glow is only written for skyrim models (e.g. enabling LOD glow for High Hrothgar), but there is nothing there for modmakers who want their custom buildings to have LOD glow.

 

So as I spend some time trying to figure out how for instance the High Hrothgar LOD glow windows work, I am assuming that there may be many hidden variables that I am completely missing that I would never be able to figure out myself. So for Shenson or anyone out there who have themselves successfully gotten LOD glow to work on models that previously have not had LOD glow, I would appreciate any guidance I can get.

[sheson]

Yes, the manual is thin on the details for that. Make sure to read the Glow LOD Windows section in the manual:
 
Checking the [x] Windows option adds glowing LOD windows to all vanilla LOD buildings. Glow LOD Windows are independent meshes that are added in addition to the LOD of the object they belong to. If the [_] High option is not checked the glowing windows are added as static object LOD. Check the [x] High option to add glowing windows as dynamic object LOD if applicable. As explained above, dynamic object LOD windows react to external lighting. However, windows on vanilla forts for example are not using external emittance and consequently will always be generated as static object LOD.
 
Most windows are automatically added to the FarGrid, some are added as neverfades that always show regardless of distance. This is determined by the *glow_lod_X.nif file name. If X equals _0 it is assigned to NearGrid (LOD4), _1 to FarGrid (LOD8) and _2 (LOD16) is a neverfade.
 

 

The glow LOD windows are done as a separate meshes. If required (and if High Windows has been checked) they can be added as dynamic LOD in order for them to react to the external emittance (window lighting changes based on weather/light conditions) settings defined on the reference. Otherwise they will be simply merged into the static object LOD BTO.

 

For example, if the LOD model has the file name house01_lod*, its glow LOD windows should have the file name house01glow_lod_*.nif.

 

If checking [x] Windows, the glow LOD mesh is then automatically found whenever a reference uses house01_lod_1.nif. There are no additional settings required.

 

Check the existing glow LOD meshes. They are also setting Decal, Dynamic_Decal on Shader Flag 1 and No_Fade on Shader Flag 2 as that will be help with the long distance visibility and z-fighting.

The windows themselves typically float a bit in front of the LOD mesh for the structures.

 

Now when you include the house01_lod* and its house01glow_lod* LOD meshes with your mod and then later users use DynDOLOD to generate LOD with the Windows and optional High settings checked, it should just work.

[glarthirs_body]

After following these directions, everything works beautifully!

 

I have only tried this for a single house, using the NIF naming conventions:

house01 (for the base highpoly model)

house01_lod (for the LOD model)

house01glow_lod_1 (for the LOD glow windows), with 1 meaning assigned to FarGrid. 

 

I am not using external emittance and am deciding on just using the glow windows as static LOD for now. Once I am more confident in how I can liberally use the various features within dyndolod, I will experiment. However, with static LOD only (only checking [x] Windows and leaving the rest of the stuff to the right of that unchecked), I can confirm that everything works beautifully, and now my building's LOD model has working LOD windows.

 

I should note that for the LOD window mesh, I also as you recommended for improved visibility at far distances, "also setting Decal, Dynamic_Decal on Shader Flag 1 and No_Fade on Shader Flag 2 as that will be help with the long distance visibility and z-fighting." I first did it without this, and decided I couldn't see the glow at all from a very far distance, so then I added these flags. Regardless if these flags are checked or not, for many weathers where there is even a very slight mist / fade at a distance, I am getting the window glow to not be visible, where the silohuette of the rest of the building is still visible. I'll play around with this more to see differences in visibility performance, but as things stand now I am very happy and content with the results. 

 

You sir are a pillar to this community. The credit will be yours when someday my mod finally gets out there.

[sheson]

One test I like to do, compare the full model with its glowing windows at the same distance as the LOD by using tfc in console. LOD has only limited shader support, but often it is just the way the engine works.

 

Check the mipmaps of the glow map texture_g.dds of the third texture slot. Test if removing the mipmaps yields better results. Consider manually creating the mipmaps or using another mipmap shrinking texture algorithm in the graphics program you use edit textures. If you check the mipmaps of hhwin02noalpha_g.dds you will see that they basically just become a white pixel in the end. The usual algorithm would make it dark grey/black.

 

You can also try increase to the Emissive Multipe value in the Shader of the glow LOD mesh a bit. 

 

ENB affects lighting, test without it for comparison.

 

Good luck with the mod.

[glarthirs_body]

Good to know these things, I'll try another mipmap gen tool at some point once I figure out what a mipmap is.

 

I used blender to bake my LOD glow windows from the original highpoly windows, and I note that if you do this, you will need to play with the emissive multiple, like you are saying. Where the original windows had an emissive multiple around 1-2, I am needing to bump up to between 9 and 12, otherwise they always start out too dim (blender doesn't bake the correct brightness). But this otherwise helps to ameliorate my previous problem of the dimness of the windows at a distance. 

 

Fixing the emissive multiple in combination with setting it to a neverfade is a good solution.