DynDOLOD 3.00 Alpha 190

[sheson]

  On 9/5/2023 at 4:01 PM, Mousetick said:

I don't know what happened but the first post of this topic, authored by sheson and containing important README and BEFORE YOU POST type of information, has disappeared. Now there is an old 2019 post from user 'Caaros'.

Latest Wayback Machine capture: https://web.archive.org/web/20230530205331/https://stepmodifications.org/forum/topic/17510-dyndolod-300-alpha-128/

Expand  

That post got accidentally merged into this thread. I am hoping z929669 can fix it. I only know of a time consuming way.

[Mousetick]

  On 9/5/2023 at 3:37 PM, sheson said:

The covered area is the bounding box of cells with navmehes +- (uLargeRefLODGridSize/2)+1  or (uGridsToLoad/2)+1 

Expand  

Sorry, I don't understand. Would you mind clarifying what covered area is referring to?

Let's say I'm standing on a city wall or atop a building at the edge of the city and looking at the surroundings. If the dynamic reference copy is outside the active cells grid, I'm not going to see its full model, I'm going to see its dynamic LOD instead. Unless the reference is a large reference. So it seems like a waste of time to visually check these dynamic reference copies that are too far from the cells containing the city limits.

  On 9/5/2023 at 3:37 PM, sheson said:

Dynamic LOD is done for references with enable parent or initially disabled flag. Also for animated models based on mesh mask or reference rules or via dynamic LOD asset filename matching, in this case waterfalls.

Expand  

Ok. Animated models would be things like windmills I assume. I reran my filters to include initially disabled flag and that didn't change the results, in my case.

The reason I'm filtering to get the list of enable parent or initially disabled reference copies is so that I can identify which ones are dynamic, where they are, and how they are enabled. If I'm peaking over a city wall, and everything is looking fine because all the dynamic references are disabled and therefore not visible, it's not going to be a very good test, is it?  Like the Civil War stuff, it's always disabled except during sieges.

On second thought, the number of added dynamic reference copies is not a big deal in regards to performance, as most of them, at least in vanilla, are disabled most of the time.

Thanks for your input.

[sheson]

  On 9/5/2023 at 6:38 PM, Mousetick said:

Sorry, I don't understand. Would you mind clarifying what covered area is referring to?

Let's say I'm standing on a city wall or atop a building at the edge of the city and looking at the surroundings. If the dynamic reference copy is outside the active cells grid, I'm not going to see its full model, I'm going to see its dynamic LOD instead. Unless the reference is a large reference. So it seems like a waste of time to visually check these dynamic reference copies that are too far from the cells containing the city limits.

Ok. Animated models would be things like windmills I assume. I reran my filters to include initially disabled flag and that didn't change the results, in my case.

The reason I'm filtering to get the list of enable parent or initially disabled reference copies is so that I can identify which ones are dynamic, where they are, and how they are enabled. If I'm peaking over a city wall, and everything is looking fine because all the dynamic references are disabled and therefore not visible, it's not going to be a very good test, is it?  Like the Civil War stuff, it's always disabled except during sieges.

On second thought, the number of added dynamic reference copies is not a big deal in regards to performance, as most of them, at least in vanilla, are disabled most of the time.

Thanks for your input.

Expand  

I only explained how the size of the area around a city into which references are copied is determined. You seemed to wonder why things 3 or 4 cells away are being copied. Large references at 11 means 6 cells from the outer cells with navmeshes. This is unrelated to how you test.

Windmill fans happen to be an example of references that are not copied, because the dynamic LOD uses the full model and stays enabled also when active cells attach for continues animation.

[StrayHALO_MAN]

  On 9/5/2023 at 5:29 AM, sheson said:

Moved to the DynDOLOD 3 Alpha thread.

Read the first post and/or https://dyndolod.info/Official-DynDOLOD-Support-Forum#Post-Logs which DynDOLOD log and debug log to upload.

Lookup the reference form id in xEdit to find out its editor id which shows the source for which the reference was added as explained at https://dyndolod.info/Official-DynDOLOD-Support-Forum#In-Game-Screenshots.

The land and building should be two separate references and using two different LOD models. 

Expand  

Thank you for the help, here is my log and updated screenshots:
https://mega.nz/file/8kZjVLpI#RXZPI7s0bP139Nv8uZzLKoZQg0DkkUy5J4mCtGTWT6Y

I also did disable+enable on the lod to show that it's still the same mesh and not landscape.
That large slab of LOD is actually sitting just under the landscape LOD.
I don't have any mods messing with Windhelm's geometry so if I could disable the child LOD being generated in the parent world that would be fine with me... Though it I guess that's only a band-aid fix.

Looking at this second image, the inn's LOD looks to be backwards, the long slab of LOD being the front area of Ulfric's castle.

Edited September 5, 2023 by StrayHALO_MAN

[Mousetick]

  On 9/5/2023 at 3:37 PM, sheson said:

Dynamic LOD is done for references with enable parent or initially disabled flag.

Expand  

About initially disabled references: I'm assuming those that can have LOD receive dynamic LOD in case they might be enabled later by a Papyrus script. Is this correct?

As I mentioned, I don't seem to have any copies of such references in my DynDOLOD plugins, so I need to ask for confirmation: Is their child copy a clone of the parent reference, with the initially disabled flag carried over?

If this is correct, we have a problem, Houston

The Papyrus script which toggles the parent reference is oblivious to the existence of the child copy, so the child copy is going to remain perpetually disabled.

Possible solution: don't carry the initially disabled flag over to the child copy, add the parent reference as enable parent of the child copy. So the child copy automatically remains synchronized with the parent reference.

[sheson]

  On 9/5/2023 at 11:32 PM, StrayHALO_MAN said:

Thank you for the help, here is my log and updated screenshots:
https://mega.nz/file/8kZjVLpI#RXZPI7s0bP139Nv8uZzLKoZQg0DkkUy5J4mCtGTWT6Y

I also did disable+enable on the lod to show that it's still the same mesh and not landscape.
That large slab of LOD is actually sitting just under the landscape LOD.
I don't have any mods messing with Windhelm's geometry so if I could disable the child LOD being generated in the parent world that would be fine with me... Though it I guess that's only a band-aid fix.

Looking at this second image, the inn's LOD looks to be backwards, the long slab of LOD being the front area of Ulfric's castle.

Expand  

Do not check "Prefer base record LOD assignments over rules" for now.

[Mousetick]

I've compiled a list of enable parent switches grouped by city and affected cells. Toggling a switch may enable or disable objects depending on opposite state. The list was based on Parent > Child copies generated with NoCellsWithNAVM=1 so is probably incomplete. Only vanilla references were considered.

I'm putting it here in case it might be of some use to you:

  Reveal hidden contents

Markarth -37,4
- dunReachcliffExitMarker [REFR:000DE164]

Markarth -39,6
- DragonMoundReach01_Disable [REFR:000FDB1F]

Markarth -40,1
- CaravanMarkarthCampEnable [REFR:001030E2]

Markarth -39,0
- [REFR:00094BF4] (no Editor ID, CW Siege Imperial Camp)

Riften 35,-20
- DragonMoundFallForest02_Disable [REFR:000FDB31]

Riften 36,-24
Riften 36,-25
Riften 37,-23
Riften 37,-24
- TG02GoldenglowGuardsEnabler [REFR:000B6311]

Riften 39,-24
- TG07WreckEnabler [REFR:000C04C6]

Riften 42,-20
- CWRiftenImpCampEnabler [REFR:0008FA4B]

Riften 42,-21
Riften 42,-22
- CWRiftenAttDefEnabler [REFR:0008F99A]

Riften 41,-22
Riften 42,-22
- CaravanRiftenCampEnable [REFR:0010311B]

Riften 42,-29
- DragonMoundFallForest01_Disable [REFR:000FDAD8]

Riften 42,-31
- DragonLair07ClutterEnableMarker [REFR:0005EFC3]

Riften 44,-29
Riften 45,-28
- dunForelhostSonsEnable [REFR:00090F0A
- dunForelhostDisableMarker [REFR:0010F8D5]

Riften 46,-21
- DA06ExtClutterEnableMarker [REFR:000C216C]

Riften 46,-31
- dunPOIFallForestBurningHouseEnableParent [REFR:000CF36F]

Solitude -12,31
- SlighthouseFireOff [REFR:00062832]

Solitude -8,26
Solitude -9,26
- MS07IcerunnerEnableMarker [REFR:0004B55D]

Solitude -12,26
Solitude -13,26
- KatariahEnableMarker [REFR:0007265C]

Solitude -12,21
Solitude -13,21
Solitude -13,22
- dunFolgunthur_ExteriorResetEnableMarker [REFR:000860C2]

Solitude -17,24
Solitude -18,24
- CaravanSolitudeCampEnable [REFR:00104AD6]

Solitude -20,22
Solitude -20,23
Solitude -21,22
Solitude -21,23
- SolitudeSonsCampEnabler [REFR:00034899]

Solitude -23,21
- CWGarrisonEnableMarkerSonsCampHaafingar [REFR:00095777]

Solitude -20,19
- DragonMoundTundraMarsh02_Disable [REFR:000FDAD6]

Whiterun 12,-4
Whiterun 12,-5
- CWGarrisonEnableMarkerSonsCampWhiterun [REFR:00095872]

Whiterun 0,-4
- mq104FXDragonAttackEnablerRef [REFR:000D3FB3]

Whiteurn 5,-5
Whiterun 5,-6
Whiterun 6,-5
- CWSiegeAttackCampEnableMarkerSonsWhiterun [REFR:0008680C]

Whiterun 3,-3
- CaravanWhiterunCampEnable [REFR:0010372F]

Whiterun 4,-4
- CWWhiterunAttackSiegeEnabler [REFR:00045855]

Whiterun 4,-1
- CWWhiterunExtDisableOnly [REFR:000FC87D]

Whiterun 11,3
- DragonMoundTundra02_Disable [REFR:000FDB13]

Windhelm 26,12
Windhelm 27,12
Windhelm 27,13
- CWGarrisonEnableMarkerMonsterFortKastav [REFR:0005E8AC]

Windhelm 30,14
- dunStillbornBackEnableMarker [REFR:000D2001]

Windhelm 33,6
- CaravanWindhelmCampEnable [REFR:00103774]

Windhelm 35,13
- CWGarrisonEnableMarkerSonsCampWinterhold [REFR:00052948]
- dunPOICampWinterholdAltEnableMarker [REFR:0007F892]

Windhelm 35,16
- TG05CampEnableMarker [REFR:000644D8]

Windhelm 35,5
Windhelm 35,6
Windhelm 36,5
Windhelm 36,6
- dunWindhelmAttackStartPOIEnableMarker [REFR:0006AF52]
- [REFR:000BE270] (no Editor ID,  CW Siege Imperial Camp)

Now that the prep work is done, time to finally check things out in-game

[sheson]

  On 9/6/2023 at 6:12 AM, Mousetick said:

About initially disabled references: I'm assuming those that can have LOD receive dynamic LOD in case they might be enabled later by a Papyrus script. Is this correct?

As I mentioned, I don't seem to have any copies of such references in my DynDOLOD plugins, so I need to ask for confirmation: Is their child copy a clone of the parent reference, with the initially disabled flag carried over?

If this is correct, we have a problem, Houston

The Papyrus script which toggles the parent reference is oblivious to the existence of the child copy, so the child copy is going to remain perpetually disabled.

Possible solution: don't carry the initially disabled flag over to the child copy, add the parent reference as enable parent of the child copy. So the child copy automatically remains synchronized with the parent reference.

Expand  

The references are not exact copies, scripts are removed for example. If the source reference has an enable parent, then the copy should already have it set.

An initially disabled reference without an enable parent that is copied would be 00062832. (Also 0005227F but it is ignored since it triggers large reference bugs. The harbor can typically not be seen from inside Windhelm anyways)

Enable parents need to be persistent. So one can not just blindly add the source references as enable parent without overwriting them and making them persistent - something to avoid at all cost This test version will set an enable parent to the source reference if it is initially disabled, persistent and does not have an enable parent.
https://mega.nz/file/IMowTbJK#30H0goSCiowS1jMqJYs_HaSe4rUu7lyG4m5GzEY8OtU

There are potentially more things (changing position, scale for example) that can happen to source references that are not covered. Those would be addressed if they actually happen / are reported.

[Mousetick]

  On 9/6/2023 at 10:04 AM, sheson said:

Enable parents need to be persistent. So one can not just blindly add the source references as enable parent without overwriting them and making them persistent - something to avoid at all cost

Expand  

Yes, agreed. But I think it works out perfectly. A non-persistent reference used by a separate script is an anachronism. It's not safe. I believe CK enforces persistence of references used as script properties. If a mod uses a non-persistent reference in a script, that mod is already bugged, with or without DynDOLOD.

If there are non-persistent initially disabled references, it's probably because the mod author doesn't care or know about properly UDR'ing them, but they're actually never used/enabled by a script. In such a case, xEdit shows that the temporary reference is not referenced by anything else. In which case, they don't really need dynamic LOD.

--

I noticed I had some dynamic Parent > Child copies in Whiterunworld cell 4,-1 even though it is navmeshed. Then I noticed that NoCellsWithNAVM=0 in DynDOLOD_SSE_childworld_WhiterunWorld.ini. It's completely fine, I just want to confirm this is intended, as all other cities have NoCellsWithNAVM=1.

Thanks.

[sheson]

  On 9/6/2023 at 12:12 PM, Mousetick said:

Yes, agreed. But I think it works out perfectly. A non-persistent reference used by a separate script is an anachronism. It's not safe. I believe CK enforces persistence of references used as script properties. If a mod uses a non-persistent reference in a script, that mod is already bugged, with or without DynDOLOD.

If there are non-persistent initially disabled references, it's probably because the mod author doesn't care or know about properly UDR'ing them, but they're actually never used/enabled by a script. In such a case, xEdit shows that the temporary reference is not referenced by anything else. In which case, they don't really need dynamic LOD.

--

I noticed I had some dynamic Parent > Child copies in Whiterunworld cell 4,-1 even though it is navmeshed. Then I noticed that NoCellsWithNAVM=0 in DynDOLOD_SSE_childworld_WhiterunWorld.ini. It's completely fine, I just want to confirm this is intended, as all other cities have NoCellsWithNAVM=1.

Thanks.

Expand  

It is intended because the cell/area right outside the maingate would otherwise not have copies for the drawbridge etc.

[redshift87]

Hey there! I got the exact same Invalid Argument error on an Immersive College of Winterhold cell that JakoJako had a few pages back. I'm on the most recent alpha and resources version, have tried a few times now and always get the error. Attaching my log and debug file (did not see a bug report file):

https://www.dropbox.com/scl/fi/0ntgiat8csv9y09tqxwto/logs.7z?rlkey=yd7uxsi3rmb0x49whd9mjixcc&dl=0

[ccaacc]

[sheson]

  On 9/6/2023 at 1:18 PM, redshift87 said:

Hey there! I got the exact same Invalid Argument error on an Immersive College of Winterhold cell that JakoJako had a few pages back. I'm on the most recent alpha and resources version, have tried a few times now and always get the error. Attaching my log and debug file (did not see a bug report file):

https://www.dropbox.com/scl/fi/0ntgiat8csv9y09tqxwto/logs.7z?rlkey=yd7uxsi3rmb0x49whd9mjixcc&dl=0

Expand  

Your DynDOLOD log show two generations. The first one worked. Can you tell what changed? They seem to have the same exact same plugin list and order.

Does it work with this test version? https://mega.nz/file/VYhQ3SqQ#wLIhiHVcYxN_m8Rw0xmBAAidLG0TlIJXLKl4fV4-pFQ
If not upload new log and debug please

[sheson]

  On 9/6/2023 at 1:54 PM, ccaacc said:

Expand  

Moved from the xLODGen thread to the DynDOLOD 3 Alpha thread, assuming that you are using it.

Read the first post and/or https://dyndolod.info/Official-DynDOLOD-Support-Forum#Post-Logs which DynDOLOD log and debug log to upload when making posts.

Also see https://dyndolod.info/Mods/Open-Exterior-Cities

[redshift87]

  On 9/6/2023 at 2:38 PM, sheson said:

Your DynDOLOD log show two generations. The first one worked. Can you tell what changed? They seem to have the same exact same plugin list and order.

Does it work with this test version? https://mega.nz/file/VYhQ3SqQ#wLIhiHVcYxN_m8Rw0xmBAAidLG0TlIJXLKl4fV4-pFQ
If not upload new log and debug please

Expand  

After the very first run, I added my personal custom rules (mostly for mods that don't have LOD objects like Eli's Skaal Village and to remove LOD for a few plants I don't care to see). I'll include my preset file that has those custom rules just in case it's helpful. I have been using those same rules for quite awhile now.

Tried again with the new .exe you provided and got a range check error this time. Oddly, my log file did not update but debug file did:

https://www.dropbox.com/scl/fi/xq3q5yjfop0ms7shsb5ob/logs2.7z?rlkey=o3rrmoxduds0z3tmc9nv2g9vg&dl=0