Dynamic Distant Objects LOD - DynDOLOD for Skyrim and Enderal 2.98

[MaysSson]

  On 6/7/2019 at 5:29 AM, sheson said:

Edit DynDOLOD_TES5.ini and set

 

TreeLODAverageColor=1

TreeLODDiffuseFormat=202

Thank You! Now it's perfect!

[frojo]

Heya, I must be doing something wrong or something, but I've been following the STEP guide and got to the page for using DynDOLOD. I got to the point where it's saying to run DynDOLOD.exe through MO, I click Run, and it comes back with "The file "DynDOLOD.exe" seems to be corrupt!" I tried seeing if there was anything in the log, but it seems as if it doesn't even run, as there isn't a log. I looked around and couldn't find a solution somewhere (I might just be overthinking/underthinking it), and I don't know what information to supply or anything, and I'm sorry to bother you, but if I could get some assistance, that'd be great.

Edited June 13, 2019 by frojo

[sheson]

  On 6/13/2019 at 9:26 AM, frojo said:

Heya, I must be doing something wrong or something, but I've been following the STEP guide and got to the page for using DynDOLOD. I got to the point where it's saying to run DynDOLOD.exe through MO, I click Run, and it comes back with "The file "DynDOLOD.exe" seems to be corrupt!" I tried seeing if there was anything in the log, but it seems as if it doesn't even run, as there isn't a log. I looked around and couldn't find a solution somewhere (I might just be overthinking/underthinking it), and I don't know what information to supply or anything, and I'm sorry to bother you, but if I could get some assistance, that'd be great.

Basic first troubleshooting steps would be to see if it starts when executed directly without MO.

Then download the latest archive again and unpack it with the latest version of 7zip to make sure the file is no corrupt.

[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]

  On 9/14/2019 at 3:05 PM, Astien said:

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]

  On 11/5/2019 at 12:52 AM, Phlunder said:

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]

  On 11/5/2019 at 12:39 PM, sheson said:

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]

  On 11/5/2019 at 6:42 PM, Phlunder said:

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]

  On 11/5/2019 at 7:46 PM, sheson said:

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]

  On 11/5/2019 at 9:17 PM, Phlunder said:

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]

  On 11/6/2019 at 9:23 AM, sheson said:

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]

  On 11/6/2019 at 7:37 PM, Phlunder said:

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