DynDOLOD 3.00 Alpha 173

[sheson]

46 minutes ago, skinjack said:

I see z929669 was running into the same issues I was, or at least similar, although he was a little more informative than I was. Considering there aren't hundreds of comments with the same thing I'm going to go with drivers or some other program on our machines causing the issue as my tentative explanation for that.

Thank you for your patience and knowledge. I'm sure dealing with people like me can be exasperating and most likely annoying. At best. But so far everything seems to work, so again, I thank you kindly for your help.

It is the same issue based on what?

Have you looked at the event log? Post it.

If the same load order and setup runs through all of sudden without problem, then OS, driver settings, anti vir could be likely the problem.

What do you mean there are "hundreds of comments with the same thing"?

xLODGen/DynDOLOD not writing a log/bugreport is a very rare thing. 2 cases IIRC.

[Illana]

Can anyone tell me how to fix this error?

[sheson]

19 minutes ago, Illana said:

Can anyone tell me how to fix this error?

"Load order FileID [02] can not be mapped to file FileID for file "Occlsuion.esp""

Click the "Help for this message" link as explained in the first post.

If this does not help any further, upload the logfiles and bugreport as explained in the first post.

As explained on the first post, do not post screenshots of error messages. Use the "Copy message top clipboard" link instead and then paste the text.

[skinjack]

Sorry again. Similar issue. Of course he only had the issue once, it took me several times to get DynDOLOD to run through properly.

And no, I haven't looked at the Event Log yet. I just got up, answered your question, and then was looking at a reply in the SkyUI posts and watching a suggested video. I was looking up event logs per your request and they don't look anything like the above, so I'm not sure I'm even in the right place. I apologize for my lack of knowledge in this area. I upgraded this computer to Windows 10 when I had it built and nothing is where I remember it from Windows 7. And I really haven't explored the Windows 10 system very much on this machine. That's why I didn't do any of the successive upgrades. I was happy with 7 until they stopped supporting it, and then I was strong-armed into upgrading.

Antivirus could be the issue. I run Norton, and they are notorious for taking a lot of things out of your control and then burying how to undo them. I really need to sit down and look at anti-virus programs again before this subscription is up.

And by hundreds of comment, I simply meant that there were NOT a lot of people complaining about a similar issue that we were so it must be our setups that are the issue, not some new bug we discovered for this Alpha. I'm not blaming DynDOLOD in any way. Its most likely my machine or setup causing any issues I have.

As I said before, everything seems to be running fine now. Next time I run DynDOLOD I will try to remember to get an event log if I have issues so that I can pass it along with the debug_log and bugreport.

[AiElias]

What do I need to do to remove this void space between grass and grass LOD with uGridsToLoad = 7 ? I'm assuming there's an ini distance setting I'm missing but for all I know it may very well not be possible.

Edit: BTW, I'm using grass mode 1, and the cells without grass are not far grids, they are fully loaded by the game. So it looks like there's some terrain blending going on in the game.

Edited October 11, 2021 by AiElias

[sheson]

57 minutes ago, AiElias said:

What do I need to do to remove this void space between grass and grass LOD with uGridsToLoad = 7 ? I'm assuming there's an ini distance setting I'm missing but for all I know it may very well not be possible.

Edit: BTW, I'm using grass mode 1, and the cells without grass are not far grids, they are fully loaded by the game. So it looks like there's some terrain blending going on in the game.

Looks like grass LOD was generated for mode 2, but NGIO is currently running mode 1.

If grass LOD was generated with mode 1 and the gap goes away when using uGridsToLoad 5, then NGIO might be hardcoded to 5 cells for DynDOLODGrassMode = 1.

If that is the case set Set DynDOLODGrassMode = 2 and use mode 2 for grass LOD generation to use uLargeRefLODGridSize cells distance.
Or keep using sane uGridsToLoad 5.

Near/Far Grids are a concept of dynamic LOD and never have anything to do with terrain/object/tree LOD meshes/textures or other mods.

[AiElias]

39 minutes ago, sheson said:

If grass LOD was generated with mode 1 and the gap goes away when using uGridsToLoad 5, then NGIO might be hardcoded to 5 cells for DynDOLODGrassMode = 1.

If that is the case set Set DynDOLODGrassMode = 2 and use mode 2 for grass LOD generation so to use uLargeRefLODGridSize cells distance.

This is in fact the case, I've ensured both were set to 1. I will give this a go and see if it resolves the issue.

 

39 minutes ago, sheson said:

Or use sane uGridsToLoad 5.

Normally I would agree with you, unfortunately to get the ideal transition between LOD trees and loaded trees there needs to be a small amount of space in the loaded cells where shadows are not applied. Otherwise, when the full model gets loaded over the lod, there will be a sudden fade to dark when shadows are applied.

Given that uGrids update when the player is past the midpoint of the adjacent-to-center cells, a setting of uGrids 5 leaves a minimum distance of 6144 units between player and LOD. Given that the default fShadowDistance = 8000, this is unideal. Therefore, I see two possible solutions to this.

1) Reduce fShadowDistance to 4096 (2048 units seems to be enough distance under most circumstance to facilitate the transition from lod to full unshadowed model). Unfortunately, this is really ugly, and the unshadowed trees in the distance are really noticeable.

2) Increase fShadowDistance to the maximum distance the player can be away from LOD terrain, then manually blend LOD textures to the full lods with applied shadows. With uGrids 5, that distance is ~20275 units (diagonal measurement of cell x 3.5). Unfortunately fShadowDistance scales up the fShadowMapResolution and makes shadows look ugly. Not to mention issues like shadow acne and flickering.

Given these two options, increasing uGrids to 7 seems to be the better approach. Unless of course there's something I'm missing.

Edited October 11, 2021 by AiElias

[sheson]

19 minutes ago, AiElias said:

This is in fact the case, I've ensured both were set to 1. I will give this a go and see if it resolves the issue.

 

Normally I would agree with you, unfortunately to get the ideal transition between LOD trees and loaded trees there needs to be a small amount of space in the loaded cells where shadows are not applied. Otherwise, when the full model gets loaded over the lod, there will be a sudden fade to dark when shadows are applied.

Given that uGrids update when the player is past the midpoint of the adjacent-to-center cells, a setting of uGrids 5 leaves a minimum distance of 6144 units between player and LOD. Given that the default fShadowDistance = 8000, this is unideal. Therefore, I see two possible solutions to this.

1) Reduce fShadowDistance to 4096 (2048 units seems to be enough distance under most circumstance to facilitate the transition from lod to full unshadowed model). Unfortunately, this is really ugly, and the unshadowed trees in the distance are really noticeable.

2) Increase fShadowDistance to the maximum distance the player can be away from LOD terrain, then manually blend LOD textures to the full lods with applied shadows. With uGrids 5, that distance is ~20275 units. Unfortunately fShadowDistance scales up the fShadowMapResolution and makes shadows look ugly. Not to mention issues like shadow acne and flickering.

Given these two options, increasing uGrids to 7 seems to be the better approach. Unless of course there's something I'm missing.

Use ENB with distance shadows as alternative.

[AiElias]

33 minutes ago, sheson said:

Use ENB with distance shadows as alternative.

I've been testing with with this setting active. The shadows appear to be different enough to where the buffer zone between ENB shadows and game shadows is still necessary for seamless transition. At least with Manty's 3d trees. I can't speak for the card pines most people use.

[z929669]

34 minutes ago, AiElias said:

I've been testing with with this setting active. The shadows appear to be different enough to where the buffer zone between ENB shadows and game shadows is still necessary for seamless transition. At least with Manty's 3d trees. I can't speak for the card pines most people use.

I just want to point out that I believe the doc states (or sheson stated somewhere) that transition changes should be tested with collision and without speedmult ≥ 500. I do all of my LOD testing without collision and at high speed in sneak mode, but not for transitions (which are fairly stark when flying around like this).

[AiElias]

24 minutes ago, z929669 said:

I just want to point out that I believe the doc states (or sheson stated somewhere) that transition changes should be tested with collision and without speedmult ≥ 500. I do all of my LOD testing without collision and at high speed in sneak mode, but not for transitions (which are fairly stark when flying around like this).

Good to know the specifics of Sheson's methodology. I've been testing all sorts of different ways. I've found that at ground level with collision enabled (as the lighting is different compared to when you're flying around) with a speedmult of 400 seems to be the sweet spot between efficiency and accurate gameplay representation. Sounds like I've been on the ball.

[sheson]

49 minutes ago, z929669 said:

I just want to point out that I believe the doc states (or sheson stated somewhere) that transition changes should be tested with collision and without speedmult ≥ 500. I do all of my LOD testing without collision and at high speed in sneak mode, but not for transitions (which are fairly stark when flying around like this).

That's in the DynDOLOD-README.txt. This only affect dynamic LOD. It stops updating the player position until speed is lower again. it won't affect other LOD types.

Yes the distance shadow is a very rough and quick estimate for performance reasons.

[sheson]

15 hours ago, z929669 said:

This is my first time experiencing this. Not a DynDOLOD issue but rather a model issue I am thinking. The aspen hybrids are very dark relative to full and other trees seem fine. Any idea offhand what might cause this? Using default TexGen settings, and only the aspens seem impacted. I'm thinking it is something with the crowns, but they are copied over from the full models as usual. Model examples follow if you care to have a look (tree mesh rule is Level0/Level1/Level2 with all else default):

 

This happens because the UV of the branches has coordinates < 0.0.
After inserting new vertices and triangles in order to have untitled UV, LODGen runs the face normals and update tangents spell.
In this case this destroys the original normals. You can replicate the problem in NifSkope by running the face normal spell there.

In case you do not want want to fix the UV to be inside 0.0 and 1.0, you could try to add spherenormals to the shape name to test if that helps.
Also next LODGen included in the next alpha will properly respect the "Texture Clamp Mode" on on the BSShaderProperty. So you can just set CLAMP_S_CLAMP_T to "fix" the UV to be inside 0.0 and 1.0 without having to edit the UV itself.

[z929669]

23 minutes ago, sheson said:

This happens because the UV of the branches has coordinates < 0.0.
After inserting new vertices and triangles in order to have untitled UV, LODGen runs the face normals and update tangents spell.
In this case this destroys the original normals. You can replicate the problem in NifSkope by running the face normal spell there.

In case you do not want want to fix the UV to be inside 0.0 and 1.0, you could try to add spherenormals to the shape name to test if that helps.
Also next LODGen included in the next alpha will properly respect the "Texture Clamp Mode" on on the BSShaderProperty. So you can just set CLAMP_S_CLAMP_T to "fix" the UV to be inside 0.0 and 1.0 without having to edit the UV itself.

Thanks so much for the analysis. Very helpful.

[mattski123]

Hey, this mod called Skyrim Platform just released and it also has an easier way to convert .psc files to .ts files. Can you please update this to speed up the scripting processes?

Let me know!