DynDOLOD 3.00 Alpha 182

[z929669]

16 hours ago, zhuabaobao said:

hi. I want to ask how to solve this, 
    DynDOLOD  
Warning: Initially disabled large reference in RealisticWaterTwo - Resources.esm [REFR:0700AE48] (places RockPileL02Wet [STAT:00039393] in GRUP Cell Temporary Children of [CELL:000095D7] (in Tamriel "天际" [WRLD:0000003C] at 10,-1))

If you are using the latest version of RWT (5.x), there is nothing to fix. This is just a warning to verify you don't see artifacts of the large-reference bug in SSE and that it has been accounted for properly by this plugin (which it is). All such warnings are just that. Most other mod authors haven't made the changes as RWT has made in it's most recent version though.

PS: I rarely see an issue in game for most of these situations, even if they are valid. Sometimes, there are visible issues in game, so having the warnings is a good thing.

[Phlunder]

Hey sheson! I noticed that the Windhelm bridge LOD model (both windhelmbridge_lod.nif and windhelmbridge_lod_1.nif) has a black spot in the latest DynDOLOD Resources 3.00 Alpha 15. The windhelmbridge_lod_2.nif is not affected. A picture of the issue with comparison to the full model:

 

I did notice that this part of the model uses a different texture than the rest of the outer wall, though the issue isn't apparent on the full model or the vanilla LOD model.

Edited December 24, 2021 by Phlunder

[sheson]

7 hours ago, Phlunder said:

Hey sheson! I noticed that the Windhelm bridge LOD model (both windhelmbridge_lod.nif and windhelmbridge_lod_1.nif) has a black spot in the latest DynDOLOD Resources 3.00 Alpha 15. The windhelmbridge_lod_2.nif is not affected. A picture of the issue with comparison to the full model:

 

I did notice that this part of the model uses a different texture than the rest of the outer wall, though the issue isn't apparent on the full model or the vanilla LOD model.

The part in question uses a different texture compared to the main part. The LOD model included in DynDOLOD Resources defines the same textures as the vanilla full model like this since 2017.

In the vanilla full model the part is a decal with an alpha-property (which is not supported by LOD) so it is made to look like the full with the decal applied. It seems the vanilla texture textures\architecture\windhelm\WHruinstonedark.dds for that part is changed with one that has a different alpha channel that makes it so that the decal is barely or not visible in the full model.

Use a different replacement texture with a similar alpha channel to the vanilla texture. Alternatively create a custom LOD model that uses the same texture as the main part. Rename the BSTriShape to Windhelmbridge:2 when doing so. Better yet merge the separate shape with the main part in the custom LOD model.

[Phlunder]

2 hours ago, sheson said:

The part in question uses a different texture compared to the main part. The LOD model included in DynDOLOD Resources defines the same textures as the vanilla full model like this since 2017.

In the vanilla full model the part is a decal with an alpha-property (which is not supported by LOD) so it is made to look like the full with the decal applied. It seems the vanilla texture textures\architecture\windhelm\WHruinstonedark.dds for that part is changed with one that has a different alpha channel that makes it so that the decal is barely or not visible in the full model.

Use a different replacement texture with a similar alpha channel to the vanilla texture. Alternatively create a custom LOD model that uses the same texture as the main part. Rename the BSTriShape to Windhelmbridge:2 when doing so. Better yet merge the separate shape with the main part in the custom LOD model.

Ahh, so it was Noble Skyrim which caused it. Thank you for explaining the issue (that was my own doing) in detail. I already tried to assign the same whoutwall texture to that part, but it was still darker than the adjacent parts. Turns out I had to match the Vertex Colors too! I also renamed the NiTriShape to Windhelmbridge:2 as you suggested. Looks perfect now. Thanks again, and happy holidays to you!

Edited December 24, 2021 by Phlunder

[redleviathan]

20 hours ago, sheson said:

cgid files were "invented" by NGIO. There is no other tool that generates them at the moment.

Ah well, hopefully the mod author found a way to upgrade NGIO.

Thanks!

[Omniguous]

hello. i hope this is the correct place to put this and i searched the other comments for the term `itm` and it came up with no results:

i ran FO4EditQAC on `FO4LODGen-HighTrees.esp` and it resulted in one (1) ITM.

`Removing: TreeMapleForest1 "Maple Tree" [STAT:0004A073]` was the log entry for that ITM.

"dirty" CRC: 0xDC282BF2

"clean" CRC: 0x7203CE8C

FO4Edit version: FO4Edit v4.0.4b

i am wondering if this was intentional, an oversight, etc. (bringing it to your attention, in other words).

 

thank you.

-omni.

[sheson]

7 hours ago, Omniguous said:

hello. i hope this is the correct place to put this and i searched the other comments for the term `itm` and it came up with no results:

i ran FO4EditQAC on `FO4LODGen-HighTrees.esp` and it resulted in one (1) ITM.

`Removing: TreeMapleForest1 "Maple Tree" [STAT:0004A073]` was the log entry for that ITM.

"dirty" CRC: 0xDC282BF2

"clean" CRC: 0x7203CE8C

FO4Edit version: FO4Edit v4.0.4b

i am wondering if this was intentional, an oversight, etc. (bringing it to your attention, in other words).

 

thank you.

-omni.

Looks like the vanilla ESM got updated between 2017 when the FO4LODGen-HighTrees.esp was created and now.

Like any other ITM that should be removed. I will go through the plugins and records to check if there for more changes to the game files happening in the past years.

[Tubb]

Running into an error upon opening Texgen for VR.

 Error: OpenGL: invalid enumerant.

^{TexGen_TES5VR_log.txt}

TexGen_TES5VR_Debug_log.txt

bugreport.txt

[Tubb]

Nevermind, had my iGPU disabled in device manager as I was experimenting with some Oculus stuff and forgot to re-enable.

[Quick]

Is there an ETA for Grass LOD?

[z929669]

11 minutes ago, Quick said:

Is there an ETA for Grass LOD?

It's here!

For SSE 1.5.97

No Grass In Objects is required with grass cache, which depends upon .NET Scrip Framework, which is not yet updated to SSE 1.6.xxx

DynDOLOD is not limiting grass LOD for SSE 1.6.xxx, NGIO is.

[Quick]

11 minutes ago, z929669 said:

It's here!

For SSE 1.5.97

No Grass In Objects is required with grass cache, which depends upon .NET Scrip Framework, which is not yet updated to SSE 1.6.xxx

DynDOLOD is not limiting grass LOD for SSE 1.6.xxx, NGIO is.

I should have been more specific, sorry.

I meant for Skyrim AE. I'm on SSE 1.6.xxx.

I know Net Framework doesn't work for this version yet. If there's a way to do grass LOD I haven't come across it yet.

[z929669]

1 hour ago, Quick said:

I should have been more specific, sorry.

I meant for Skyrim AE. I'm on SSE 1.6.xxx.

I know Net Framework doesn't work for this version yet. If there's a way to do grass LOD I haven't come across it yet.

You will need to generate your grass cache with your mods under 1.5.97 and then use that to gen LOD under 1.6.xxx against (nearly) same mod list. Otherwise, you must wait for .Net FW for NGIO under 1.6.xxx

[Quick]

2 hours ago, z929669 said:

You will need to generate your grass cache with your mods under 1.5.97 and then use that to gen LOD under 1.6.xxx against (nearly) same mod list. Otherwise, you must wait for .Net FW for NGIO under 1.6.xxx

I figured. Thanks.

[sheson]

4 hours ago, Quick said:

I should have been more specific, sorry.

I meant for Skyrim AE. I'm on SSE 1.6.xxx.

I know Net Framework doesn't work for this version yet. If there's a way to do grass LOD I haven't come across it yet.

DynDOLOD does not require a specific runtime version to generate  grass LOD in object LOD.

https://stepmodifications.org/forum/topic/15606-dyndolod-300-alpha-58/?do=findComment&comment=254861