Jump to content

DynDOLOD 3.00 Alpha 182


sheson

Recommended Posts

1 hour ago, sheson said:

Both log from Alpha-128 and the bugreport.txt appear to be old ones from past months?

I assume you are using the latest Alpha-133 but somehow uploaded an old logs. Upload the log and also the debug from the generation that is used in the screenshot.

FormID 0005c854 is supposed to be "deleted" by a DynDOLOD plugin. Probably a bug with the manual patch file included in the latest alpha.

The mesh being replaced is most likely irrelevant for the duplication.

Sorry I assumed the logs updated during my las run but yes I am using Alpha 133. hopefully these are the correct logs for you

DynDOLOD_SSE_log.txt DynDOLOD_SSE_Debug_log.txt

Link to comment
Share on other sites

1 hour ago, DarkladyLexy said:

Sorry I assumed the logs updated during my las run but yes I am using Alpha 133. hopefully these are the correct logs for you

DynDOLOD_SSE_log.txt 2 MB · 0 downloads DynDOLOD_SSE_Debug_log.txt 1.08 MB · 0 downloads

Unfortunately the debug log got replaced already, but the log seems good enough.

Can you do a quick check with xEdit to see if anything overwrites 0005c854?

Link to comment
Share on other sites

30 minutes ago, DarkladyLexy said:

The log shows Alpha-133 on top. Old log again?

The error message from the log is:
Error: LOD billboard(s) not found. Check the log for the individual warning messages. Generate LOD billboards with TexGen first.

The log shows the list of missing billboards. They should have all been generated by TexGen and installed as a mod as usual.

As explained, use the Click on this link for additional explanations and help for this message to open https://dyndolod.info/Help/Tree-Grass-LOD-Billboards and scroll down to LOD Billboard(s) Not Found for some troubleshooting tips.

Link to comment
Share on other sites

17 minutes ago, sheson said:

The log shows Alpha-133 on top. Old log again?

The error message from the log is:
Error: LOD billboard(s) not found. Check the log for the individual warning messages. Generate LOD billboards with TexGen first.

The log shows the list of missing billboards. They should have all been generated by TexGen and installed as a mod as usual.

As explained, use the Click on this link for additional explanations and help for this message to open https://dyndolod.info/Help/Tree-Grass-LOD-Billboards and scroll down to LOD Billboard(s) Not Found for some troubleshooting tips.

Shouldn't i have deleted the old version, installed the new purged the logs and cache, and generated a fresh version of texgen with Alpha 134

Link to comment
Share on other sites

17 minutes ago, DarkladyLexy said:

Shouldn't i have deleted the old version, installed the new purged the logs and cache, and generated a fresh version of texgen with Alpha 134

Each new DynDOLOD release should be unpacked to a new empty folder.

https://dyndolod.info/Updating#New-DynDOLOD-Version
Always install DynDOLOD Standalone into a new or empty folder. Always replace old DynDOLOD Resources.

DynDOLOD 3 Alpha-134 has this as the first logline:
DynDOLOD 3.0 Alpha-134 x64 - Skyrim Special Edition (SSE) (B365340B) starting session YYYY-MM-DD HH:MM:SS

However, the missing billboard error is unrelated to which version is being used. It is about required LOD assets not being found in the data folder.

Link to comment
Share on other sites

I would like to know more about the new heighmap options added in the INI. I tried looking on the website and doing a search in this thread but couldn't find where they were explained.

; Set to 1 to create terrain heightmap textures
DoTerrainHeightMap=0

Does the heightmap in this context mean the heightmap used by things like the parallax shader, or something else?

Edited by Blackread
Link to comment
Share on other sites

1 hour ago, Blackread said:

I would like to know more about the new heighmap options added in the INI. I tried looking on the website and doing a search in this thread but couldn't find where they were explained.

; Set to 1 to create terrain heightmap textures
DoTerrainHeightMap=0

Does the heightmap in this context mean the heightmap used by things like the parallax shader, or something else?

I added export of the native terrain height data to a texture/image for doodlum for a test. It is also part of not yet released xLODGen terrain LOD beta.

The readme has a bit of information.

Terrain-Heightmap-Readme.txt

Link to comment
Share on other sites

I've been testing the new parent/child copy feature, and so far looking great, thank you so much for adding this in. There were a couple things I wanted to ask about though.

In some places objects seem to be missing. The places I found where this is visible without console hacking are the Dragonborn Museum Safehouse balcony in Solitude and in front of the Honorhall Orphanage looking towards the Riften fishery in Riften. I assume this is because cells containing refs in the child world don't receive any refs from the parent world, or something along those lines?

K2Q1hpx.pngTyvEgT7.png

Another thing I noticed is that refs in the parent world that have had their base objects swapped with Base Object Swapper use their original base records in the child world. Here are two pictures from the Whiterun stables to demonstrate. The first one shows the fences as they appear in the parent world (Tamriel) having been swapped with BOS, the second shows them in the child world (WhiterunWorld) using the original base record. This is of course quite minor and barely noticeable, but just wanted to make sure whether it's because Base Object Swapper is not supported for this feature, or if there is a bug of some sort.

VTJLYFK.png7inrxID.png

Lastly, at least in MarkarthWorld there seem to be some issues with large references. The first picture is taken with uLargeRefLODGridSize=5, the second with uLargeRefLODGridSize=9. The bridge and some other large objects disappear when they enter the large ref grid. I have added the "Use LOD Data" flag to the Parent worldspace field of MarkarthWorld so that Markarth uses the Tamriel LOD instead of its own LOD.

sawKmXc.pngW2di8FT.png

Here's a link to the logs: https://mega.nz/file/RWFHgJ4C#3_wi91qevRJLXpEbAIXO57E_XrgJsTemNRkq1jOFxOo

 

Almost forgot, there were also these things:

5QdE4zF.pngXAuOazh.png

The first picture is from Evermore in Beyond Reach, the second is the entrance to Cidhna Mine in Markarth. To my eyes it looks like either LOD or the underside mesh, but I wasn't able to target it in console so I assume it's the former, unless things have changed.

Edit: Remembered the tll command. Using it made the low res objects disappear, so they indeed are LOD.

Edited by Blackread
Link to comment
Share on other sites

10 hours ago, Blackread said:

I've been testing the new parent/child copy feature, and so far looking great, thank you so much for adding this in. There were a couple things I wanted to ask about though.

In some places objects seem to be missing. The places I found where this is visible without console hacking are the Dragonborn Museum Safehouse balcony in Solitude and in front of the Honorhall Orphanage looking towards the Riften fishery in Riften. I assume this is because cells containing refs in the child world don't receive any refs from the parent world, or something along those lines?

K2Q1hpx.pngTyvEgT7.png

Another thing I noticed is that refs in the parent world that have had their base objects swapped with Base Object Swapper use their original base records in the child world. Here are two pictures from the Whiterun stables to demonstrate. The first one shows the fences as they appear in the parent world (Tamriel) having been swapped with BOS, the second shows them in the child world (WhiterunWorld) using the original base record. This is of course quite minor and barely noticeable, but just wanted to make sure whether it's because Base Object Swapper is not supported for this feature, or if there is a bug of some sort.

VTJLYFK.png7inrxID.png

Lastly, at least in MarkarthWorld there seem to be some issues with large references. The first picture is taken with uLargeRefLODGridSize=5, the second with uLargeRefLODGridSize=9. The bridge and some other large objects disappear when they enter the large ref grid. I have added the "Use LOD Data" flag to the Parent worldspace field of MarkarthWorld so that Markarth uses the Tamriel LOD instead of its own LOD.

sawKmXc.pngW2di8FT.png

Here's a link to the logs: https://mega.nz/file/RWFHgJ4C#3_wi91qevRJLXpEbAIXO57E_XrgJsTemNRkq1jOFxOo

 

Almost forgot, there were also these things:

5QdE4zF.pngXAuOazh.png

The first picture is from Evermore in Beyond Reach, the second is the entrance to Cidhna Mine in Markarth. To my eyes it looks like either LOD or the underside mesh, but I wasn't able to target it in console so I assume it's the former, unless things have changed.

Edit: Remembered the tll command. Using it made the low res objects disappear, so they indeed are LOD.

Cells with navmeshes are ignored by default for some child worldspaces atm.

https://dyndolod.info/Help/Child-Parent-Worldspace-Copies#Settings-for-Parent-gt-Child
NoCellsWithNAVM - set to 1 to not copy references from the parent worldspace if the child worldspace cell contains a nav mesh. Use to only copy reference that are really outside the walled cities.
Settin NoCellsWithNAVM=0 for Solitude, Riften should address the views. 

For copies, not all possible conditional features of BOS are supported yet. I assume the fences are using locational swaps. See https://dyndolod.info/Official-DynDOLOD-Support-Forum#In-Game-Screenshots how to make screenshots of objects showing usefull information with the More Informative Console mod. Provide a link to the mod adding the swaps.

Regarding Markarth, parent child worldspace copies are made after LOD is generated for a worldspace. By default Markarth does not use the Tamriel parent worldspace for LOD. When its own LOD is generated, there is no reference adding the bridge, hence it has no LOD. If you set ScanParent=1 for Markarth and you also want LOD to match, edit the Markarth worldspace record and set the flag to use the LOD of Tamriel.

Get the cell coordinates and terrain LOD filename from DynDOLOD SkyUI MCM - You are here to check the CELL and LAND records and the terrain LOD meshes. Make sure terrain LOD is generated for the load order in high enough quality. If necessary also check the object LOD meshes for culprits.

Link to comment
Share on other sites

Hi. Is it normal that every time I start the game and load last save the message appears `dyndolod initialized successfully`? Maybe not every time but quite often. It already initialized with success when I first start new game. But now Im lvl 10 and it still happens. Never had it with earlier versions like 128/129/130 etc. Im using version 133 now. Everything seems to work fine but thought I will ask here in case thats indication something is not right. Thanks. 

Link to comment
Share on other sites

10 hours ago, sheson said:

Cells with navmeshes are ignored by default for some child worldspaces atm.

https://dyndolod.info/Help/Child-Parent-Worldspace-Copies#Settings-for-Parent-gt-Child
NoCellsWithNAVM - set to 1 to not copy references from the parent worldspace if the child worldspace cell contains a nav mesh. Use to only copy reference that are really outside the walled cities.
Settin NoCellsWithNAVM=0 for Solitude, Riften should address the views. 

For copies, not all possible conditional features of BOS are supported yet. I assume the fences are using locational swaps. See https://dyndolod.info/Official-DynDOLOD-Support-Forum#In-Game-Screenshots how to make screenshots of objects showing usefull information with the More Informative Console mod. Provide a link to the mod adding the swaps.

Regarding Markarth, parent child worldspace copies are made after LOD is generated for a worldspace. By default Markarth does not use the Tamriel parent worldspace for LOD. When its own LOD is generated, there is no reference adding the bridge, hence it has no LOD. If you set ScanParent=1 for Markarth and you also want LOD to match, edit the Markarth worldspace record and set the flag to use the LOD of Tamriel.

Get the cell coordinates and terrain LOD filename from DynDOLOD SkyUI MCM - You are here to check the CELL and LAND records and the terrain LOD meshes. Make sure terrain LOD is generated for the load order in high enough quality. If necessary also check the object LOD meshes for culprits.

Alright I gathered up the information. Here are first the pics for the fences:

j8Ue3xi.pngDaIiRcu.png

The EDID for the copy is skyrimesm_0627B3_WhiterunWorld_DynDOLOD_PARENT_DynDOLOD_NOLOD. The mod swapping the fences is Fences of Skyrim and the fences are swapped by their reference IDs.

The Cidhna Mine entrance information:

Cell: -43,0, CELL: 20EED~Skyrim.esm, LAND: B2550~Skyrim.esm
Objects: Tamriel.4.-44.0.bto, Tamriel.8.-48.0.bto, Tamriel.16.-48.0.bto
Terrain: Tamriel.4.-44.0.btr, Tamriel.8.-48.0.btr, Tamriel.16.-48.0.btr, Tamriel.32.-64.0.btr

I looked at it a bit closer ingame and noticed there are three things happening. First is the underside mesh, which is visible when coming out of the mine (single-sided). ojS6vLA.png

The EDID for the underside is Tamriel_Underside_DynDOLOD_NOLOD. The second is a single-sided LOD object which is visible from the outside, this is what can be seen in the first image I posted. I suspect this is the terrain LOD. The third one is a double-sided LOD object sitting behind the single-sided one, which I suspect to be a mountain from the object LOD. I suppose at least the underside is a side effect of making Markarth use the Tamriel LOD. I also looked at the terrain and object LOD files, but I'm not really sure what I should be looking for, or how to compare them to the loaded cell.

Edit: I checked the LOD files again and in the object LOD files there isn't anything in that spot in any of them, so the double-sided LOD object can't be a mountain object after all (or at least not from one of these). In the terrain LOD there obviously is the slope up the mountain, though I'm not sure how to relate it to the loaded cell.

GcdEn5p.png

/endEdit

Edit2: Setting Markarth to not use LOD data eliminated all the LOD objects. However, the underside is still there. But since I had the flag enabled while generating LOD maybe I just need to regenerate without the flag?

Evermore information:

Cell: 14,-4, CELL: DF8ED~arnima.esm, LAND: n/a
Objects: arnimaEvermore.4.12.-4.bto, arnimaEvermore.8.8.-8.bto, arnimaEvermore.16.0.-16.bto
Terrain: arnimaEvermore.4.12.-4.btr, arnimaEvermore.8.8.-8.btr, arnimaEvermore.16.0.-16.btr, arnimaEvermore.32.0.-32.btr

With this one I also noticed the LOD object is double sided. There are no terrain LOD files under those names in my mod list, and there are no object LOD files generated by DynDOLOD for this worldspace either. However, there are these bundled with the original mod:

sqQbVED.png

But the file names don't match the ones shown by the DynDOLOD MCM. Edit: I checked the meshes but none of them seemed to match what was seen ingame. Moreover, none of the objects in those meshes are double-sided, so it doesn't look like it could be any of them seen there. Edit2: Looks like setting Evermore not to use the parent worldspace LOD also got rid of the LOD object inside the city. Of course this means that the city now just floats in the skybox, but that's not a huge issue, since the walls are tall and you can't really see over them.

Edit: Just checked the map and it looks like despite setting the AllHDLOD32 to 1 in the ini, the objects that previously had non-HD (bright) snow on them still do.

ZlpYt0k.png

I checked the mesh in nifskope and it looks like the names of the objects are changed to HD but the shader flags aren't.

9x3LoIV.png

At least in the tests I conducted last time it looked like simply changing the names of the objects was not enough, the shader flags needed to be changed too to swap the snow to HD. I changed the shader flags on High Hrothgar to HD and then the snow matched the other HD snow as intended.

idlbUOj.pnglGzOmIA.png

One more odd thing I noticed is that when first going to an exterior the DynDOLOD Successfully Initialized notification isn't printed, no matter how long one waits. It's printed only after first making a save in an exterior and loading it. Don't know if this is indicative of a problem or anything, just different than what it used to be. I attached the Papyrus log here just in case: https://mega.nz/file/tTdFHKTD#909i7u0t8DLNl0Go0A4T-I6Ks8jGr19UOuqBuf9JL0U

Another edit:

Found one more problem when poking around Markarth testing things. There's this rectangular water object floating a bit above the normal water and clipping with things.

DoijUeb.pngbkdYqQ3.pngPm7hbDb.png

The editor ID is skyrimesm_0F6F5F_Tamriel_DynDOLOD_OBJECT

Edited by Blackread
Link to comment
Share on other sites

1 hour ago, xbk123 said:

Hi. Is it normal that every time I start the game and load last save the message appears `dyndolod initialized successfully`? Maybe not every time but quite often. It already initialized with success when I first start new game. But now Im lvl 10 and it still happens. Never had it with earlier versions like 128/129/130 etc. Im using version 133 now. Everything seems to work fine but thought I will ask here in case thats indication something is not right. Thanks. 

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

As explained, this is in ALPHA test to find and report bugs. If you using the experimental large reference bugs workarounds DynDOLOD DLL NG and Scripts, also an ALPHA test, then the message is expected to show after loading a save as well. Also see https://dyndolod.info/Help/Large-Reference-Bugs-Workarounds#Testing

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...

Important Information

By using this site, you agree to our Guidelines, Privacy Policy, and Terms of Use.