Jump to content

Recommended Posts

Posted

My framerate has suddenly nosedived after a recent re-generation. Went from getting a good 50-90 fps to a consistent .7 fps, not even exagerating. I'm finding that DynDOLOD is generating all Grass LODs as it should, but the game is rendering every single Grass LOD in the entire game all at once, causing the frame rate to start at about 50 when first loaded, then quickly tank to an unreasonably low amount as LODs continue loading.

This link is a screenshot using TFC to show grass loaded all the way at Markarth (my character was just outside the Whiterun gates).  The screenshot was taken with a LOD generated with DynDOLOD 3.0 Alpha 159. But updating to DynDOLOD 3.0 Alpha 170 (current version) produced the same result. All LODs were created correctly (troubleshooting through the Grass LOD DynDOLOD page) with no errors and I used density setting 40 in Mode 1 because I'm using a pre-warmed Vedogolt Grass Cache from the Nexus on current patch AE.

I was hoping that it was some weird setting I changed in DynDOLOD for grass to render this far, but it doesn't seem to be the case. When I updated to Alpha 170, I deleted all DynDOLOD files except for the empty TexGen and DynDOLOD Output folders.

This is my Drive folder with my plugins.txt as well as a LazyListExporter file.

Posted
  On 5/28/2024 at 4:31 AM, gerg90 said:

My framerate has suddenly nosedived after a recent re-generation. Went from getting a good 50-90 fps to a consistent .7 fps, not even exagerating. I'm finding that DynDOLOD is generating all Grass LODs as it should, but the game is rendering every single Grass LOD in the entire game all at once, causing the frame rate to start at about 50 when first loaded, then quickly tank to an unreasonably low amount as LODs continue loading.

This link is a screenshot using TFC to show grass loaded all the way at Markarth (my character was just outside the Whiterun gates).  The screenshot was taken with a LOD generated with DynDOLOD 3.0 Alpha 159. But updating to DynDOLOD 3.0 Alpha 170 (current version) produced the same result. All LODs were created correctly (troubleshooting through the Grass LOD DynDOLOD page) with no errors and I used density setting 40 in Mode 1 because I'm using a pre-warmed Vedogolt Grass Cache from the Nexus on current patch AE.

I was hoping that it was some weird setting I changed in DynDOLOD for grass to render this far, but it doesn't seem to be the case. When I updated to Alpha 170, I deleted all DynDOLOD files except for the empty TexGen and DynDOLOD Output folders.

This is my Drive folder with my plugins.txt as well as a LazyListExporter file.

Expand  

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 when making posts.

https://dyndolod.info/Help/Grass-LOD
Grass LOD is generated for LOD level 4 only.

If you do not see LOD meshes rapidly cycling through their LOD levels and still see LOD Level 4 meshes with grass LOD further away when using tfc, it probably means you have set the object LOD distance INI settings to insanely high values.

See https://dyndolod.info/Help/Object-LOD#Settings and https://dyndolod.info/Help/Mod-Configuration-Menu#Settings to check/change the settings.
You can also use the game launcher or BethINIs to set sane defaults.

Posted

I'll upload the logs and INIs as soon as I get back home from work, but I can say that I've already used BethINI to set INI settings and have double checked the grass mod INI as well. I tried going though every INI file in the Data page of MO2 to make sure there was nothing else overwriting the LOD level 4 draw distance, grass density, etc.

Posted
  On 5/28/2024 at 6:10 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 when making posts.

https://dyndolod.info/Help/Grass-LOD
Grass LOD is generated for LOD level 4 only.

If you do not see LOD meshes rapidly cycling through their LOD levels and still see LOD Level 4 meshes with grass LOD further away when using tfc, it probably means you have set the object LOD distance INI settings to insanely high values.

See https://dyndolod.info/Help/Object-LOD#Settings and https://dyndolod.info/Help/Mod-Configuration-Menu#Settings to check/change the settings.
You can also use the game launcher or BethINIs to set sane defaults.

Expand  

I have got the necessary DynDOLOD and TexGen logs uploaded as well as Skyrim.ini, SkyrimPrefs.ini, and Veydogolt - Regions.ini. My fBlockLevel0Distance is just over 16000 (around where BethINI Low puts it).

Posted
  On 5/28/2024 at 10:50 PM, gerg90 said:

I have got the necessary DynDOLOD and TexGen logs uploaded as well as Skyrim.ini, SkyrimPrefs.ini, and Veydogolt - Regions.ini. My fBlockLevel0Distance is just over 16000 (around where BethINI Low puts it).

Expand  

I have become the very thing I swore to destroy, the person who overlooks one thing and bothers the mod maker about a user error. I have found the issue. DynDOLOD's own MCM did indeed have values WAY too high and that's all it was. I'm sorry to bother you and thank you for pointing out my stupidity, haha.

Posted

Idea/request for a possible future update: Billboard 2 looks more convincingly like full models from a distance to me, but when it is backlit by the sun (morning or evening, using the billboard model's soft-lighting shader) the illusion is broken because the bits that are supposed to be dark or opaque (shadows and the trunk) light up as much as the leaves/needles that should actually have some subsurface scattering.  This is especially noticeable with snowy pines, because all the white snow on the branches starts to basically glow and look translucent. 

This is because the billboard model reuses the diffuse texture in slot3, and the diffuse image seems to be captured by Texgen using frontal lighting (looks like bright daytime).  My suggestion is to use a new 3rd texture in the 3rd slot of the billboard models, which would also generated by Texgen (so texture.dds in slot 1, texture_n.dds in slot 2 and texture_sk.dds in slot 3).  That new *_sk.dds texture would be captured using lighting that more closely simulates backlighting - so trunks and shadows are darker and thus less illuminated by the soft lighting shader when backlit.  See below screenshots for the Nifskope lighting settings I found most closely resembled backlighting (backlit subsurface scattering version on left, daytime normal lighting for diffuse on right):

 

image.thumb.png.7fd8acd78c3cd836eb7d210e6132928e.pngimage.thumb.png.79fd12ffc7aadb0aa30eee0fe4de5504.pngimage.thumb.png.f03cbe32a5c51bd06b33d98560919089.png

Thanks for considering and for all your work on Dyndolod!

Posted

I have some questions...

Do dynamic window lights on Whiterun castle work if I select upper right Medium rules for Candles and FX Glow, but keep Glow Window and High checked in the lower section? Or do I have to use High rules at the top right for dynamic lights to function?

The grass precache and grass LOD's seemed to be working, except there is a color mismatch between the LOD grass being green and the loaded cell grass being more brown/yellow. What is the best way to fix this?

I also had a warning about ELFX missing a mesh called "Warning: File not found Meshes\effects\elfx\candlelanternwithcandle02.nif. Used by EnhancedLightsandFX.esp". I'm not sure how to fix this or if it needs fixing at all.

Is it better to use the Alpha 3 or Beta version at this time?

Posted
  On 5/31/2024 at 2:33 AM, drift123 said:

I have some questions...

Do dynamic window lights on Whiterun castle work if I select upper right Medium rules for Candles and FX Glow, but keep Glow Window and High checked in the lower section? Or do I have to use High rules at the top right for dynamic lights to function?

The grass precache and grass LOD's seemed to be working, except there is a color mismatch between the LOD grass being green and the loaded cell grass being more brown/yellow. What is the best way to fix this?

I also had a warning about ELFX missing a mesh called "Warning: File not found Meshes\effects\elfx\candlelanternwithcandle02.nif. Used by EnhancedLightsandFX.esp". I'm not sure how to fix this or if it needs fixing at all.

Is it better to use the Alpha 3 or Beta version at this time?

Expand  

The Glow windows and the High checkboxes are their own discrete options that have nothing to do with mesh rules, loading mesh rule candles or rules for FX glow. Look at the advanced mode interface how these options are separated, hover the mouse to see hints and read the explanations that open when clicking the Help button: https://dyndolod.info/Help/Advanced-Mode

Since Glow LOD windows are not the same as candles or FX glow, they all have their own checkboxes (hover for hints) and explanations. Click the Help button to open https://dyndolod.info/Help/Advanced-Mode and click also see https://dyndolod.info/Help/Glow-LOD.

https://dyndolod.info/Help/Grass-LOD#Settings
In case the grass LOD brightness or color seems off (it might depend on weathers or ENB settings), try different Direct/Ambient settings for grass LOD billboards in TexGen. In addition or alternatively change the GrassBrightnessTop*/ComplexGrassBrightnessTop* and GrassBrightnessBottom*/ComplexGrassBrightnessBottom* settings in ..\DynDOLOD\Edit Scripts\DynDOLOD\DynDOLOD_SSE.ini - those settings help if the color tone is off. Especially the image based lighting effect from ENB has a big impact on the brightness and color tone of the grass LOD. Additional complex grass lighting and time of day settings will obviously not apply to object LOD, as they are separate meshes and shaders. Do not use them so full grass and grass LOD match better for all weathers/times.

Read the first post and/or https://dyndolod.info/Official-DynDOLOD-Support-Forum#Post-Logs which entire DynDOLOD log and debug log to upload instead of posting only parts of the logs or pieces of a single log line or messages.

See https://dyndolod.info/Messages/File-Not-Found-Meshes. It also explains how to check if a mesh is required or not and gives hints how to fix the file not found error.

Typically it is "better" to use the latest DynDOLOD 3 Alpha version, for current game and mod support and to help to improve and develop it quicker. The answer also depends on the user goals and what is installed.

Posted (edited)
  On 3/24/2024 at 9:14 PM, sheson said:

The debug log is saved and replaces the old debug log when the tool is shutting down. Let the tool close on its own, do not terminate it via X for example. Delete the log folder for a new session, so there are no write protected files or files in use preventing overwriting them.

In order to properly troubleshot the issue, provide updated log, debug log, object report all for the same LOD generation session.
Provide links to the mods where I can download them. send links to private mods/uploads via PM if needed.

Also upload ..\DynDOLOD\Edit Scripts\Export\LODGen_SSE_Export_Tamriel.txt and LODGen_SSE_Export_Tamriel_WIN.txt

Expand  

Hi, I have finally been able to produce a valid debug log (took me two attempts, and I didn't have the patience to rerun it when DynDOLOD again failed to produce a debug log, hence the wait). To recap, the issue was a badly mismatched LOD model during winter, likely due to something breaking after applying mesh mask rules. The issue still persists. You are probably able to get the details by backtracking the conversation. The log files and other requested files can be found here: https://www.dropbox.com/scl/fi/ef90b9t3zloufid6620xn/Logs.7z?rlkey=nnt7uh9ohtanmkzlqktnsttdx&dl=0

I also reported that a certain building was not showing up on the map, despite having proper LOD models and the level 4 and level 8 LODs being successfully generated. That issue remains too. I have a bit more information on the issue, though, having found no less than six objects which suffer from the same issue (the list is likely not exhaustive). See the list below (with examples of references in parenthesis):

RTKeep01.nif (e.g. 00080C57)
RTFarmhouse01.nif (e.g. 167A~RiftenExtension.esp)
RTFarmhouse02.nif (e.g. 16A7~RiftenExtension.esp)
RTStables01.nif (e.g. 000BB7B4)
CWTower01.nif (e.g. 7EDC~Bells of Skyrim - OCS Patch.esp)
SHouseForSale.nif (e.g. 0008E2CA)

All of these meshes have specific form swaps for winter. Interestingly, three of them, RTFarmHouse02WIN.nif, RTStables01Snow.nif, and CWTower01Snow.nif do have level 16 LOD, despite using the same LOD meshes as the base objects (or copies thereof). I don't know whether it is related to the issue.

Edited by Jonado
Posted
  On 5/31/2024 at 11:04 PM, Jonado said:

Hi, I have finally been able to produce a valid debug log (took me two attempts, and I didn't have the patience to rerun it when DynDOLOD again failed to produce a debug log, hence the wait). To recap, the issue was a badly mismatched LOD model during winter, likely due to something breaking after applying mesh mask rules. The issue still persists. You are probably able to get the details by backtracking the conversation. The log files and other requested files can be found here: https://www.dropbox.com/scl/fi/ef90b9t3zloufid6620xn/Logs.7z?rlkey=nnt7uh9ohtanmkzlqktnsttdx&dl=0

I also reported that a certain building was not showing up on the map, despite having proper LOD models and the level 4 and level 8 LODs being successfully generated. That issue remains too. I have a bit more information on the issue, though, having found no less than six objects which suffer from the same issue (the list is likely not exhaustive). See the list below (with examples of references in parenthesis):

RTKeep01.nif (e.g. 00080C57)
RTFarmhouse01.nif (e.g. 167A~RiftenExtension.esp)
RTFarmhouse02.nif (e.g. 16A7~RiftenExtension.esp)
RTStables01.nif (e.g. 000BB7B4)
CWTower01.nif (e.g. 7EDC~Bells of Skyrim - OCS Patch.esp)
SHouseForSale.nif (e.g. 0008E2CA)

All of these meshes have specific form swaps for winter. Interestingly, three of them, RTFarmHouse02WIN.nif, RTStables01Snow.nif, and CWTower01Snow.nif do have level 16 LOD, despite using the same LOD meshes as the base objects (or copies thereof). I don't know whether it is related to the issue.

Expand  

DynDOLOD saves the debug log right after the normal log. Simply let it close/shut down normally. It can take a while.

No mods or links to mods were provided.
No useful screenshots were provided. https://dyndolod.info/Official-DynDOLOD-Support-Forum#In-Game-Screenshots
No base record form IDs were provided.

Read https://dyndolod.info/Installation-Instructions and https://dyndolod.info/Updating#New-DynDOLOD-Version. Do not install newer versions over older versions.

I assume for all listed references, the issue is both, the winter LOD does not match and no LOD on the map when the season is winter?

00080C57
swapped to base record to 844~SoS_Seasonspatch_Riften.esp from Simplicity of Seasons? CRC32 of plugin does not match Simplicity of Seasons 1.4.1?
Full model rtkeep01snow.nif CRC32 dos not match Simplicity of Seasons 1.4.1?
LOD uses vanilla LOD model and should have snow cover via the snow LOD shader in winter LOD.
With the current default rules there is no LOD model defined for LOD level 16 for default or winter seasons. so it expected the it does not show in the map. Create a custom rule that sets Level1 to LOD Level 16 to show it on the map.

167A~RiftenExtension.esp
swapped to base record to 83A~SoS_Seasonspatch_Riften.esp from Simplicity of Seasons? CRC32 of plugin does not match Simplicity of Seasons 1.4.1?
Full model rtfarmhouse01snow.nif CRC32 dos not match Simplicity of Seasons 1.4.1?
LOD uses vanilla LOD model and should have snow cover via the snow LOD shader in winter LOD.
With the current default rules there is no LOD model defined for LOD level 16, so it expected the it does not show in the map. Create a custom rule that sets Level1 to LOD Level 16 to show it on the map.

167A~RiftenExtension.esp
swapped to base record to BBD~Seasonal Landscapes - SoS_Seasons patch.esp, unclear what mod the plugin is from.
Full model rtfarmhouse02win.nif, unclear what mod it is from.
LOD uses vanilla LOD model and should have snow cover via the snow LOD shader in winter LOD.
With the current default rules there is no LOD model defined for LOD level 16, so it expected the it does not show in the map.  Create a custom rule that sets Level1 to LOD Level 16 to show it on the map.

000BB7B4
swapped to base record to 86C~SoS_Seasonspatch_Riften.esp from Simplicity of Seasons? CRC32 of plugin does not match Simplicity of Seasons 1.4.1?
Full model rtstables01snow.nif CRC32 dos not match Simplicity of Seasons 1.4.1?
LOD uses rtstables01snow_lod.nif, unclear what mod it comes from.
LOD has snow cover via the snow LOD shader.  LOD model defined for Level 16, so It should show on the winter map.

7EDC~Bells of Skyrim - OCS Patch.esp
Reference form id not found in any logs

0008E2CA
swapped to base record to 889~SoS_Seasonspatch_Solitude.esp from Simplicity of Seasons? CRC32 of plugin does not match Simplicity of Seasons 1.4.1?
Full model shouseforsalesnow.nif CRC32 dos not match Simplicity of Seasons 1.4.1?
LOD uses "vanilla" LOD model from DynDOLOD Resources and should have snow cover via the snow LOD shader in winter LOD.
With the current default rules there is no LOD model defined for LOD level 16, so it expected the it does not show in the map.  Create a custom rule that sets Level1 to LOD Level 16 to show it on the map.

All the swapped full models (minus the rtfarmhouse02win.nif) I have here from Simplicity of Seasons, do not contain 3D snow covers. The snow cover for the full model always seems to be realized via using a snow shader. So in that regard the default LOD models using the snow LOD shader should match?

Posted (edited)

I have a question about the Preset rules Low, Medium and High. If I check Candles and FXGlow and then click High preset, I presume it loads all mesh rules for High preset, including the Candles and FXGlow.

If I click first Medium preset, and then check Candles and FXGlow, and then click High preset. Will it override the Medium Preset changes and make them all high? Or will it only change the Candles and FXGlow rules to high?

Or for example, if I select the High preset, and then check Candles and FX Glow, and then click Medium preset, will it change all rules to medium, including the Candles and FX Glow rules? Or will I get a combination of High rules for Candles/FX Glow and Medium rules for other meshes?

The other thing is, what is the difference between Vanilla window glow and the Dyndolod with Glow Window + High checked (lower section)? When I disabled Dyndolod Output I could still see the Whiterun castle glow and it would turn off in the daytime on a new save. I'm not sure if that is because of the ELFX mod or if Vanilla has dynamic window glow on Whiterun castle by default.

Edited by drift123
Posted
  On 6/1/2024 at 2:01 PM, drift123 said:

I have a question about the Preset rules Low, Medium and High. If I check Candles and FXGlow and then click High preset, I presume it loads all mesh rules for High preset, including the Candles and FXGlow.

If I click first Medium preset, and then check Candles and FXGlow, and then click High preset. Will it override the Medium Preset changes and make them all high? Or will it only change the Candles and FXGlow rules to high?

Or for example, if I select the High preset, and then check Candles and FX Glow, and then click Medium preset, will it change all rules to medium, including the Candles and FX Glow rules? Or will I get a combination of High rules for Candles/FX Glow and Medium rules for other meshes?

Expand  

https://dyndolod.info/Help/Advanced-Mode#Low-Medium-or-High-Preset-Buttons
All existing rules will be replaced.

https://dyndolod.info/Help/Advanced-Mode#Candles-FXGlow
The check boxes activate rules for Candles and FXGlow.
These rules will be loaded when clicking any of the low, medium or high preset buttons.

As explained, clicking Low, Medium or High will always replace all existing rules. It will then load the rule files that match the selected preset and any files without any preset identifier or _all in the filename.

Posted (edited)
  On 6/1/2024 at 7:10 AM, sheson said:

No mods or links to mods were provided.
No useful screenshots were provided. https://dyndolod.info/Official-DynDOLOD-Support-Forum#In-Game-Screenshots
No base record form IDs were provided.

Expand  

I did provide detailed information further up in the thread. Let me dig it up for you:

  On 3/18/2024 at 11:08 PM, Jonado said:

I found some other LOD issues from the same generation. For some reason, I am getting a total mismatch for the LOD model for sbluepalacegate.nif during winter (but during the other seasons it looks fine). I am using a custom form swap for this object during winter, but the replacement is using the same mesh. I tried using mesh mask rules to get LOD for this building, perhaps I screwed something up? The generated object LOD mesh can be found here, please tell me if you need anything else: https://www.dropbox.com/scl/fi/yui7f3dhiqo5y62eylu30/Tamriel.4.-16.24.WIN.bto?rlkey=fohj4dpjul471rmn3e4i13afh&dl=0

Expand  
  On 3/24/2024 at 12:25 AM, Jonado said:

All the logs are here, just as they were before: https://www.dropbox.com/scl/fi/ef90b9t3zloufid6620xn/Logs.7z?rlkey=nnt7uh9ohtanmkzlqktnsttdx&dl=0. I have added the object report log to the zip file too now. I can see if I can upload some screenshots later, but it at least affects the reference 0xC938~Open Cities Skyrim.esp and all objects with FormID 000801ED.

Expand  

This should also help:

  On 3/24/2024 at 8:01 AM, sheson said:

What mod are  SoS_Seasonspatch_Solitude.esp and SoS_Seasons - Vigilant.esp from?

The debug log shows a couple duplicate EditorIDs which should be unique in the load order and can screw with swapping based on EditorIDs
Duplicate editor ID SBluePalaceGateWinter in SoS_Seasons - Vigilant.esp SBluePalaceGateWinter [STAT:FE2A4802] and SoS_Seasonspatch_Solitude.esp SBluePalaceGateWinter [STAT:FE0F2812]>

The object report shows that SBluePalaceGateWinter from SoS_Seasonspatch_Solitude.esp xxyyy812 uses the full model meshes\architecture\solitude\sbluepalacegate.nif for LOD which is most likely not what you want.

Expand  
  On 3/24/2024 at 8:18 PM, Jonado said:

I think this requires some explanation from my side. SoS_Seasonspatch_Solitude.esp is from the mod Simplicity of Seasons, which is an IMO broken mod which I have spent a lot of time in the last months to try to patch up. While working with that I decided to incorporate some of its features (with fixes) into a seasons mod for Vigilant, which I have published on Nexus with the mod name Seasons for Vigilant. As a workaround to avoid my mod to depend on Simplicity of Seasons, and while waiting for my bug fixes to get finished, I simply copied the relevant objects from Simplicity of Seasons to my mod (it should be fine according to the mod's permissions). That is the reason for the duplicate. But I am using FormIDs and not EditorIDs for seasonal swapping, so should it matter?

The full-model swap is likely from the mesh mask rules (the object in Simplicity of Seasons is using the same flags as the base object). I simply copied the rule from a similar line from RedBag's Solitude's custom rules (which I think are incorrectly configured, because that mod does not include any file called SBluePalaceGate.nif). But that should be same as for the non-formswapped object. The mesh mask rules only depend on the mesh, which is the same.

Expand  

That said, the Simplicity of Seasons meshes have been quite heavily modified by me, and for good reason. rtstables01snow_lod.nif was provided by me, and is a copy of rtstables01_lod.nif from the DynDOLOD resources. rtfarmhouse02win.nif is shipped with the mod Seasons for Vigilant for the time being (but will be published elsewhere later). Anyway, I think this fully explains the issue I am facing:

  On 6/1/2024 at 7:10 AM, sheson said:

With the current default rules there is no LOD model defined for LOD level 16 for default or winter seasons. so it expected the it does not show in the map. Create a custom rule that sets Level1 to LOD Level 16 to show it on the map.

Expand  

I don't understand why those rules are not set by default, though. Those buildings are big enough that it is noticeable that they do not show up on the map. I am not saying I cannot fix it myself, just that I think it should be a main part of DynDOLOD. If you want, I can add it as a request to the mesh mask rule thread we started a while ago. I also think that it is weird that some of the winter models get different rules than the base models, despite using exactly the same LOD mesh, and having the same LOD rules attached to the object.

Edited by Jonado
Posted
  On 6/1/2024 at 2:49 PM, Jonado said:

I did provide detailed information further up in the thread. Let me dig it up for you:

This should also help:

That said, the Simplicity of Seasons meshes have been quite heavily modified by me, and for good reason. rtstables01snow_lod.nif was provided by me, and is a copy of rtstables01_lod.nif from the DynDOLOD resources. rtfarmhouse02win.nif is shipped with the mod Seasons for Vigilant for the time being (but will be published elsewhere later). Anyway, I think this fully explains the issue I am facing:

I don't understand why those rules are not set by default, though. Those buildings are big enough that it is noticeable that they do not show up on the map. I am not saying I cannot fix it myself, just that I think it should be a main part of DynDOLOD. If you want, I can add it as a request to the mesh mask rule thread we started a while ago. I also think that it is weird that some of the winter models get different rules than the base models, despite using exactly the same LOD mesh, and having the same LOD rules attached to the object.

Expand  

If you want to report a mismatch between full models and LOD, then provide screenshots of the full model (with more informative console) and the LOD. The reference and base record form ID are required to look things up in the logs.

The "highest" available LOD models in these cases end in *1.nif, which means Level1. The last / rule automatically assigns those to LOD8 max. *2.nif = Level2 is assigned to LOD16 automatically as explained in the documentation. But no such LOD models exist in these cases.

So in this case add mesh rules for these models and set Level1 to LOD16 - choose the partial mesh mask right, a couple rules might be enough to cover all cases and seasons. There are no such rules yet, because nobody reported a problem so far. I will most likely address this in future updates.

Posted

Here you go. The gate has been replaced by a wall of some kind in the object LOD mesh.

As for Level2 LOD models, would it work to simply copy the Level1 models and rename them as *2.nif? That would be easier for me than to mess with the mesh mask rules again. Otherwise I can just wait until you fix it, I am not going to actually play the game in quite a while anyway.

20240601212920_1.jpg

20240601213055_1.jpg

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.