DynDOLOD 3.00 Alpha 196

[sheson]

23 minutes ago, Zenball said:

Debug log is here: https://ufile.io/75hwq32r

I have seen a couple of areas by the coast where the sun does appear to be casting rays through mountains and showing glare reflection on water surface through mountains so wanted to try to generate an underside to see if it would help, but it appears it's generating it but then not finding the file generated.

Can any other Enderal players share their underside nifs in the meantime? Will it still work if I place the nif in the correct filepath if the generation failed?

Thanks.

Put this test version of LODGenx64.exe into the Edit Script folder and run again DynDOLOD again.

It should hopefully generate the underside now.

[Zenball]

6 hours ago, sheson said:

Thanks.

Put this test version of LODGenx64.exe into the Edit Script folder and run again DynDOLOD again.

It should hopefully generate the underside now.

Sheson you are a gentleman, a paragon of dedication, cool repose, and wondrous achievement.

The underside nifs have generated. Thank you!

[DarkladyLexy]

hey question with alpha 43 how do we sleect the Ultra Trees option now the option is no longer avaible in DyDOLOD?

 

Ignore me i now see the the HD Trees check was renamed to Ultra.

[LucidAPs]

I got this error when running the tool, I am using the alpha 44
https://nekobin.com/cuguvuramu

[sheson]

50 minutes ago, LucidAPs said:

I got this error when running the tool, I am using the alpha 44
https://nekobin.com/cuguvuramu

Read the first post what log files and bugreport to upload when making posts.

[LucidAPs]

20 minutes ago, sheson said:

Read the first post what log files and bugreport to upload when making posts.

Thank you, let me know if more info is needed. Disabling near grid upgrade fixes it.
bugreport.txtDynDOLOD_SSE_Textures_Used_Tamriel.txtDynDOLOD_SSE_Dynamic_LOD.txtDynDOLOD_SSE_Debug_log.txt

[sheson]

19 minutes ago, LucidAPs said:

Thank you, let me know if more info is needed. Disabling near grid upgrade fixes it.
bugreport.txtDynDOLOD_SSE_Textures_Used_Tamriel.txtDynDOLOD_SSE_Dynamic_LOD.txtDynDOLOD_SSE_Debug_log.txt

Does the error happen consistently with the same record?

The debug log gets replaced with each start, so it does not contain the log from session with the error anymore.

If you can reproduce the error, upload that debug log and also the normal log as explained in the first post and teh new bugreport.txt

The Textures_Used and Dnamic_LOD files in the log folder are not needed.

Which version of JKs Skyrim.esp are you using?

Is any plugin overwriting 38009E5E?

[Arrocito]

Hey Sheson

 

I have no idea what would be blocking access to the folder for the texgen output and I'm more confused since it it happens mid process and not right away with the first textures. I'm seriously stumped and never had these issues before. It's getting pretty demoralizing. 

[sheson]

7 hours ago, Arrocito said:

Hey Sheson

 

I have no idea what would be blocking access to the folder for the texgen output and I'm more confused since it it happens mid process and not right away with the first textures. I'm seriously stumped and never had these issues before. It's getting pretty demoralizing. 

Programs use standard OS function to read and write files. If the OS function fails it returns an error message. The program can only relay that message.
It is either the UAC or some the tied-in antivir or something is already accessing by another program etc.

In the process it is the first time that a texture is being copied from that data folder / BSA to the output folder. AntVirs also check the contents of data being written. One file might be fine, while another isn't.

Start xEdit with entire load order. Start the Asset Browser with CTRL+F3. Put the source filename into the filter field. The first listed container is the winning BSA or teh data folder for loose files. Right click and select Save As (from the winning container). See what happens.

[Phlunder]

Hey sheson! Thanks for all the latest improvements to DynDOLOD 3.0. The renderer for custom object and tree LOD textures is really something else, perfect match now! Having trees with normal maps in object LOD helps a lot too, once they are matched in terms of brightness of the diffuse, they blend well in every situation! Good stuff!

I still have issues with blending the damn glaciers, even with custom made LOD textures to match, their horrible UVs make it hard to make them look good. For mountains/unique, I used a suggestion of yours from a while ago, creating a ruleset that pushes certain LOD stages farther out. The LOD4 step of mountain LOD almost always uses the full mountainslab texture, so pushing that step out to LOD8 helps a lot. Could a similar thing be done with glaciers as well? Their LOD4 model already uses custom textures though. Maybe pushing the full model (they are not very complex in terms of shape) out to LOD4 or LOD8? Would that be possible with rules? Performance impact is a given of course.

Edited September 21, 2021 by Phlunder

[sheson]

34 minutes ago, Phlunder said:

Hey sheson! Thanks for all the latest improvements to DynDOLOD 3.0. The renderer for custom object and tree LOD textures is really something else, perfect match now! Having trees with normal maps in object LOD helps a lot too, once they are matched in terms of brightness of the diffuse, they blend well in every situation! Good stuff!

I still have issues with blending the damn glaciers, even with custom made LOD textures to match, their horrible UVs make it hard to make them look good. For mountains/unique, I used a suggestion of yours from a while ago, creating a ruleset that pushes certain LOD stages farther out. The LOD4 step of mountain LOD almost always uses the full mountainslab texture, so pushing that step out to LOD8 helps a lot. Could a similar thing be done with glaciers as well? Their LOD4 model already uses custom textures though. Maybe pushing the full model (they are not very complex in terms of shape) out to LOD4 or LOD8? Would that be possible with rules? Performance impact is a given of course.

Of course, just create a mesh mask rule that targets part of the path/filename of the full model of whatever it is you want to target with custom rules.

However, keep in mind that LOD does not support parallax, so using such full models for object LOD is probably not going to look as expected.

[Phlunder]

4 hours ago, sheson said:

Of course, just create a mesh mask rule that targets part of the path/filename of the full model of whatever it is you want to target with custom rules.

However, keep in mind that LOD does not support parallax, so using such full models for object LOD is probably not going to look as expected.

Thanks for the quick response! Yes, I noticed, due to the missing capability I had to make changes to the LOD textures to take the visual impact of the parallax effect on full models into account. Now that I think of it, to give those full models as LOD a different texture, I would have to make them a different mesh with unique texture path assigned. I wonder if it would make sense to just replace the LOD models with the full ones, and assign a special texture to it. Not sure why they've gone through the trouble of making so many unique LOD meshes for those glaciers, they don't really have much shape complexity to begin with.

Thanks for the ideas! I'll try to figure something out. Best way would be to create new reduced LOD models for the glaciers of course... Just beyond my capabilities.

[sheson]

1 hour ago, Phlunder said:

Thanks for the quick response! Yes, I noticed, due to the missing capability I had to make changes to the LOD textures to take the visual impact of the parallax effect on full models into account. Now that I think of it, to give those full models as LOD a different texture, I would have to make them a different mesh with unique texture path assigned. I wonder if it would make sense to just replace the LOD models with the full ones, and assign a special texture to it. Not sure why they've gone through the trouble of making so many unique LOD meshes for those glaciers, they don't really have much shape complexity to begin with.

Thanks for the ideas! I'll try to figure something out. Best way would be to create new reduced LOD models for the glaciers of course... Just beyond my capabilities.

Consoles. Also, full modes and LOD models not having to closely matching 3D shapes helps to reduce texture z-fighting while both show for that brief second.

Sure, you can just take the 3D shape data (maybe do a slight decimation) from the full model and update shader + textures.

[DoubleYou]

I am making custom rules that load with a mod, but the following rules are always overridden as follows:

fxwaterfallbody,None,Level1,Level2,None,FarLOD,Unchanged,1,DynDOLOD_SSE_all_dynamic.ini
dlc2cliffbasalt,Level0,Level1,Level1,None,FarLOD,Unchanged,0,DynDOLOD_SSE_High.ini
dlc2dwecluttercolmlarge01,Full,None,None,None,FarLOD,Unchanged,0,DynDOLOD_SSE_High.ini
dlc2dwe,Level0,Level1,Level1,None,FarLOD,Unchanged,0,DynDOLOD_SSE_High.ini
redorantemple01,Level0,Level1,Level1,None,FarLOD,Unchanged,1,DynDOLOD_SSE_High.ini
windhelmbridge,Level0,Level1,Level2,None,None,Unchanged,5,DynDOLOD_SSE_High.ini

All the other rules load fine. I have attached my rules INI file.

DynDOLOD_SSE_maptweaksesp_high.ini

[z929669]

If I'm not mistaken, your rule additions have conflicting priority with the default preset. I believe that you could use a spreadsheet to interleave your custom rules with the default, merging and renumbering in the wanted priority. You will need to remove default rules matching your new ones also, I'd say. Seems faster than inputting via the gui anyway.

Oof ... I guess I didn't know that the preset INIs allowed 'append' of custom mesh rules via mod-included rules. Duh. I assumed that the line numbering like "LODGen 202" actually indicated priority ... but it seems like it's just a line counter that must update internally (without duplication) when eternal rules are appended/injected/interleaved.