Dynamic Distant Objects LOD - DynDOLOD for Skyrim and Enderal 2.98

[frojo]

Tried without MO, still comes up with the same message. 

Re-extracted, when I run it in the initial folder I extract it to -without MO- it opens, gets to the point where it says

"Error: Can not find DynDOLOD Resources core folder... (ect)"

Set the executable in MO to the exe in the initial extraction folder and run it, it seems like it's gone through and works.

The issue I'm guessing was that there was some kind of issue with me moving the folder after I had extracted it, or something along those lines.

Thank you for your assistance.

[Astien]

Hi, I'm having an error on this new version. Here are the log files:

 

https://gofile.io/?c=GrlOuA

[sheson]

Hi, I'm having an error on this new version. Here are the log files:

 

https://gofile.io/?c=GrlOuA

Exception in unit process line 87: Can not copy [REFR:02013CD0] (places PlaneMarker [sTAT:00000017] in GRUP Cell Temporary Children of DLC1VampireCastleExterior06 [CELL:000018DE] (in Tamriel "Skyrim" [WRLD:0000003C] at -43,37)) from Dawnguard.esm into DynDOLOD.esp Assertion failure (C:\Delphi\projects\DynDOLOD\wbImplementation.pas, line 13947)

Check log lines above the exception for additional hints. Check the FAQ and search official forum for those errors.

 

FAQ: DynDOLOD.exe: Can not copy xxxx from xxxx.esp into xxx.esp

A: Often caused by a broken bashed patch. Use a newer Wrye Bash version to create the patch or do not use the merge patches option. 

A: There is a plugin in the load order with errors. Check the load order for errors with xEdit.exe before generating LOD. Fix all errors. See this video for help. 

 

https://forum.step-project.com/topic/14114-error-can-not-copy-refr000b7365-places-planemarker-stat00000017-in-grup-cell-temporary-children-of-solitudeorigin-cell00037ee9-in-solitude

https://forum.step-project.com/topic/14205-can-not-copy-refr000a1ff7-places-farmlumbermill01waterwheel02/

https://forum.step-project.com/topic/14136-can-not-copy-refr0b0259dc-places-farmlumbermill01waterwheel02/

https://forum.step-project.com/topic/14127-can-not-copy-refr0c16904c-places-spatiowall01-stat00057a17-in-grup-cell-persistent-children-of-cell00000d74

[Astien]

Thanks, I was able to get it figured out

[Phlunder]

Hey sheson, first thank you for your continued work on DynDOLOD and xLODGen!

 

Maybe you can help me with a minor problem I've ran into. I created new tree billboards for the Soul Cairn and Forgotten Vale, which don't have any billboards at all by default. The billboards work and show up fine, but some trees in the Forgotten Vale are for whatever reason statics, not tree records. An example would be DLC1TreeWinterAspenSnow01 [sTAT:0200CE13]. I also created billboards for those statics plus the appropriate text files, but they won't be recognized by DynDOLOD. If I give those statics the flag "Has Tree LOD" DynDOLOD picks up on them and adds them to the texture atlas (with alpha) but the billboards still don't show up. Is there a way to give those statics billboards without replacing them with actual trees?

[sheson]

Hey sheson, first thank you for your continued work on DynDOLOD and xLODGen!

 

Maybe you can help me with a minor problem I've ran into. I created new tree billboards for the Soul Cairn and Forgotten Vale, which don't have any billboards at all by default. The billboards work and show up fine, but some trees in the Forgotten Vale are for whatever reason statics, not tree records. An example would be DLC1TreeWinterAspenSnow01 [sTAT:0200CE13]. I also created billboards for those statics plus the appropriate text files, but they won't be recognized by DynDOLOD. If I give those statics the flag "Has Tree LOD" DynDOLOD picks up on them and adds them to the texture atlas (with alpha) but the billboards still don't show up. Is there a way to give those statics billboards without replacing them with actual trees?

 

DynDOLOD uses the tree LOD generation from xEdit/xLODGen.

 

Setting the Has Tree LOD flag on a static base record is how CK does it and consequently xEdit/xLODGen do it as well. It is how vanilla does it for a couple Dragonborn trees.

 

If the tree LOD generation reports that it found a billboard, then the reason for a tree not to have LOD is that it is too tilted, dynamic or - which is likely in this case - the tree with the STAT base record is also a large reference. Tree LOD does not support large references.

 

For too tilted or dynamic trees DynDOLOD automatically substitutes them in object LOD.

Next version of DynDOLOD will also do large references with Has Tree LOD flag properly in object LOD. This combination just never came up so far.

 

If traditional tree LOD is disabled and all tree LOD is done in object LOD (e.g. ultra trees) then it already worked.

Edited November 5, 2019 by sheson

[Phlunder]

DynDOLOD uses the tree LOD generation from xEdit/xLODGen.

 

Setting the Has Tree LOD flag on a static base record is how CK does it and consequently xEdit/xLODGen do it as well. It is how vanilla does it for a couple Dragonborn trees.

 

If the tree LOD generation reports that it found a billboard, then the reason for a tree not to have LOD is that it is too tilted, dynamic or - which is likely in this case - the tree with the STAT base record is also a large reference. Tree LOD does not support large references.

 

For too tilted or dynamic trees DynDOLOD automatically substitutes them in object LOD.

Next version of DynDOLOD will also do large references with Has Tree LOD flag properly in object LOD. This combination just never came up so far.

 

If traditional tree LOD is disabled and all tree LOD is done in object LOD (e.g. ultra trees) then it already worked.

Thanks for the fast reply! I probably should have mentioned that I'm on LE, not SE. Or are large references also a thing in LE? I currently don't use ultra trees. Not sure what could be the problem then, the trees/statics in question are positioned perfectly upright, not sure how to tell if they are dynamic though. Its not a big deal, I just thought I was overlooking some limitation or rules to assign billboards to them.

[sheson]

Thanks for the fast reply! I probably should have mentioned that I'm on LE, not SE. Or are large references also a thing in LE? I currently don't use ultra trees. Not sure what could be the problem then, the trees/statics in question are positioned perfectly upright, not sure how to tell if they are dynamic though. Its not a big deal, I just thought I was overlooking some limitation or rules to assign billboards to them.

In that case, if a billboard texture has been listed as found and put onto the atlas, there is at least one reference with its tree LOD in the worldspace.

It only adds billboard textures to the tree LOD atlas when placement data has been written to a *.btt file.

[Phlunder]

In that case, if a billboard texture has been listed as found and put onto the atlas, there is at least one reference with its tree LOD in the worldspace.

It only adds billboard textures to the tree LOD atlas when placement data has been written to a *.btt file.

That makes sense. Really not sure whats going on then. I just tested it with ultra trees, and its the same issue. I believe not all of those DLC1TreeWinterAspenSnow trees have 3D LOD models included in DynDOLOD, but the "01" variant has for sure. For all the other trees this works flawlessly, and the 3D LOD models look great by the way. But all the DLC1TreeWinterAspenSnow01/03/05 are missing their full 3D LOD model (in case of 01) and their fallback billboard as well. A screenshot of one of those places where the missing 3D LODs/billboards are noticable (also notice the 2 WinterAspen04 billboards working):

 

https://i.imgur.com/lf7oL4L.png

 

https://i.imgur.com/JhTzJX4.png

[sheson]

That makes sense. Really not sure whats going on then. I just tested it with ultra trees, and its the same issue. I believe not all of those DLC1TreeWinterAspenSnow trees have 3D LOD models included in DynDOLOD, but the "01" variant has for sure. For all the other trees this works flawlessly, and the 3D LOD models look great by the way. But all the DLC1TreeWinterAspenSnow01/03/05 are missing their full 3D LOD model (in case of 01) and their fallback billboard as well. A screenshot of one of those places where the missing 3D LODs/billboards are noticable (also notice the 2 WinterAspen04 billboards working):

 

https://i.imgur.com/lf7oL4L.png

 

https://i.imgur.com/JhTzJX4.png

The DynDOLOD Resources contain 3D LOD models for all 3 DLC1TreeWinterAspenSnow01, 03 and 05, however for 03 and 05 I messed up the files names really badly.

I have them correct in DynDOLOD Resources SE.

 

just rename

dlc1treewinteraspensnow03.nifpassthru_lod.nif.nif to dlc1treewinteraspensnow03nifpassthru_lod.nif

dlc1treewinteraspensnow05.nifpassthru_lod.nif.nif to dlc1treewinteraspensnow05nifpassthru_lod.nif

 

Will be fixed next version of course.

 

It also seems that traditional tree LOD generation might not always pick up the updated HasTreeLOD flag, that will be fixed as well.

Edited November 6, 2019 by sheson

[Phlunder]

The DynDOLOD Resources contain 3D LOD models for all 3 DLC1TreeWinterAspenSnow01, 03 and 05, however for 03 and 05 I messed up the files names really badly.

I have them correct in DynDOLOD Resources SE.

 

just rename

dlc1treewinteraspensnow03.nifpassthru_lod.nif.nif to dlc1treewinteraspensnow03nifpassthru_lod.nif

dlc1treewinteraspensnow05.nifpassthru_lod.nif.nif to dlc1treewinteraspensnow05nifpassthru_lod.nif

 

Will be fixed next version of course.

 

It also seems that traditional tree LOD generation might not always pick up the updated HasTreeLOD flag, that will be fixed as well.

That did indeed work! The 3D LODs now all show up fine. Thanks a lot for looking into this. I didn't check out the mesh folders for the 3D trees before, but the naming mismatch issue immediately jumped at me when I did. I had to rename them differently though, without the additional "nif" in between the record name and passthru. So dlc1treewinteraspensnow03passthru_lod.nif instead of dlc1treewinteraspensnow03nifpassthru_lod.nif for example, just like the 01 variant is named.

 

Does that mean the regular billboard system will work for this specific case too with the next update?

[sheson]

That did indeed work! The 3D LODs now all show up fine. Thanks a lot for looking into this. I didn't check out the mesh folders for the 3D trees before, but the naming mismatch issue immediately jumped at me when I did. I had to rename them differently though, without the additional "nif" in between the record name and passthru. So dlc1treewinteraspensnow03passthru_lod.nif instead of dlc1treewinteraspensnow03nifpassthru_lod.nif for example, just like the 01 variant is named.

 

Does that mean the regular billboard system will work for this specific case too with the next update?

Yes you are right, I can't even copy and paste the correct filename :)

 

If either the tree vanilla LOD generation or the 3D tree LOD lists its using the billboards, then all should be fine.

If the vanilla tree LOD generation lists the billboards as not found, then there is a naming problem.

If the vanilla tree LOD generation does not list the trees at all despite having an overwrite with the HasTreeLOD flag, wait for the update or try actually setting the flag in Dawnguard.esm itself.

Edited November 6, 2019 by sheson

[Phlunder]

Yes you are right, I can't even copy and paste the correct filename :)

 

If either the tree vanilla LOD generation or the 3D tree LOD lists its using the billboards, then all should be fine.

If the vanilla tree LOD generation lists the billboards as not found, then there is a naming problem.

If the vanilla tree LOD generation does not list the trees at all despite having an overwrite with the HasTreeLOD flag, wait for the update or try actually setting the flag in Dawnguard.esm itself.

Setting the Has Tree LOD flag directly in the Dawnguard.esm worked! So its really not picking up on it in overwrite records. This time, DynDOLOD also immediately listed it at the start together with the other available billboards. Before it just mentioned it because its missing a normal map. Still added it to the atlas but I guess the placement data was never written into the BTT file?

 

Again, thank you for looking into this. I know it was kind of an edge-case.

[sheson]

Setting the Has Tree LOD flag directly in the Dawnguard.esm worked! So its really not picking up on it in overwrite records. This time, DynDOLOD also immediately listed it at the start together with the other available billboards. Before it just mentioned it because its missing a normal map. Still added it to the atlas but I guess the placement data was never written into the BTT file?

 

Again, thank you for looking into this. I know it was kind of an edge-case.

Great. So that will be fixed next version - so you don't have to patch a vanilla file. It's good that you looked into that part, as it helped fixing a couple issues there.

Edited November 7, 2019 by sheson

[Nuttertools]

Hello! I am using Skyrim SE, dyndolod with vanilla trees, vanilla weather and lighting, Indistinguishable Billboards for Skyrim SE (medium brightness) and with TreeLOD=0 option (3d trees). About 2 versions ago (2.79, if i remember correctly, it was version with default TreeLOD=0 option) i didn't notice that, but with 2.81 (and 2.81 resources) my tree lods, especially trunks, are too bright. With old version they had same brightness like closer trees. I never changed lod brightness setting in dyndolod wizard, it always is 0, and earlier it works perfect. I was trying to change TreeFullFallBack option from 1 to 0 but it didn't change anything. Seems like they doesn't have shadows anymore, or something like that. I am also tried Enhanced Vanilla Trees, but it has same issue. I never change other options in ini files. Can anyone help?

Edited February 2, 2020 by Nuttertools