DynDOLOD 3.00 Alpha 190

[sheson]

  On 10/10/2021 at 9:44 PM, skinjack said:

To be honest I almost never read back further than what could possibly be causing the errors. Code makes my head hurt these days.  But I can see the "normal" errors and warning while DynDOLOD is running. I am talking about the final, stops the process, popup window you get.

I did just run it again with the same results. It stopped, without a final error or warning window. Just faded from my screen. There is no debug_log.txt or bugreport.txt for this run through, so I will keep running it until I get one. Sorry this is taking so long but sometimes I almost get through the entire run, and DynDOLOD can take a while, even on my computer. You don't necessarily need to respond today. It IS Sunday, and even programmers should get a break. 

 

EDIT: OK, this time it made it all the way through. No rhyme or reason. CPU usage was 0 to 96%. RAM was 0-52%. I didn't change any files, but had to run this at least 6 times until it finally ran all the way through. I couldn't even hazard a guess as to why it was closing beyond the memory issue, but like I said that should not be a problem for me. I have an I9-1098XE CPU, 64GB of RAM, and a 2080ti GPU. Could the drivers or something be interfering somehow? I'm pretty religious about keeping them updated.

Expand  

The log message are not code. They typically use plain English words. There is nothing normal about warning or errors. They indicate problems that need to be at least checked and often corrected. Unless you rather troubleshoot mysterious CTD or game issues later.

The reported issues could be because of hardware/driver issues, for example like overclocking, heat or bad memory timings etc.

If there is no debug log, check the windows event log.

[sheson]

  On 10/11/2021 at 2:26 AM, z929669 said:

Running latest alpha for the first time after upgrade from Alpha 44 (clean directory). TexGen runs fine, but DynDOLODx64 is failing without reson. LODGenx64 completes without issue long after DynDOLOD fails. No bugreport.txt, and no DynDOLOD log or debug log generated. Tree report is fine.

This is now acting like my xLODGenx64 unresolved issues.

I am running DynDOLOD in the same manner with same settings as I have been for months now. Alpha 44 ran without issue, and this is essentially a repeat using Alpha 47.

It seems the error occurred during logging of this file or immediately after: LODGen_SSE_DeepwoodRedoubtWorldTerrainUnderside_log.txt

App window closed.

Event:

Faulting application name: DynDOLODx64.exe, version: 3.0.0.0, time stamp: 0x615ec9a2
Faulting module name: KERNELBASE.dll, version: 10.0.19041.1202, time stamp: 0xc9db1934
Exception code: 0x0eedfade
Fault offset: 0x0000000000034f99
Faulting process id: 0x7c08
Faulting application start time: 0x01d7be43e42f7282
Faulting application path: C:\Modding\Tools\DynDOLOD\DynDOLODx64.exe
Faulting module path: C:\Windows\System32\KERNELBASE.dll
Report Id: dd705d9e-af4b-46e4-acd9-879a7c1b1261
Faulting package full name:

 

EDIT: Ran without issue the second try. No changes otherwise.

EDIT2: This is my first time experiencing this. Not a DynDOLOD issue but rather a model issue I am thinking. The aspen hybrids are very dark relative to full and other trees seem fine. Any idea offhand what might cause this? Using default TexGen settings, and only the aspens seem impacted. I'm thinking it is something with the crowns, but they are copied over from the full models as usual. Model examples follow if you care to have a look (tree mesh rule is Level0/Level1/Level2 with all else default):

 

Expand  

Nothing changed about TexGen generation or atlas creation.

Can't really check the crown without the full texture for the branches.

[Illana]

Can we remove this error checking on Dyndolod? It's out of scope for this program to be checking QUEST records surely?

[skinjack]

It may possibly be an issue with drivers. I'm not sure about that. I usually keep them updated with a program that does them for me. I don't overclock. Heat... eh, maybe, but I doubt it. I have the cpu water-cooled with 5-6 fans in there. Bad memory. Again, could be. Windows is recognizing 64GB, but you can never really tell with RAM. But I hope not. Those were expensive sticks. Probably more machine than I need but my wife did say this is the last one I'm getting in this lifetime.

And I didn't mean to trivialize the "normal" errors. I just meant they are errors I normally get before troubleshooting the game further. Same with code. My slang for "Damn, that's a lot of stuff in there-where do I start". But I am going to write that "check the Windows Event log" down in my book of notes. I don't normally look into that because I usually don't have issues with this computer. Outside of Skyrim, of course. 

I see z929669 was running into the same issues I was, or at least similar, although he was a little more informative than I was. Considering there aren't hundreds of comments with the same thing I'm going to go with drivers or some other program on our machines causing the issue as my tentative explanation for that.

Thank you for your patience and knowledge. I'm sure dealing with people like me can be exasperating and most likely annoying. At best. But so far everything seems to work, so again, I thank you kindly for your help.

[sheson]

  On 10/11/2021 at 12:01 PM, Illana said:

Can we remove this error checking on Dyndolod? It's out of scope for this program to be checking QUEST records surely?

Expand  

DynDOLOD does not process QUEST records, once the xEdit background loader completed without issues.

Finalize the load order and fix all errors before generating LOD.

If you believe the xEdit error check is making wrong reports about errors, I suggest to make a bug report on the xEdit discord.

If you believe DynDOLOD is making a wrong error report, see the first post what logfile to include when making posts.

If you need help fixing errors in plugins or the load order, see the first post what logfiles to include when making posts and ask qualified questions about it.

[sheson]

  On 10/11/2021 at 12:12 PM, skinjack said:

I see z929669 was running into the same issues I was, or at least similar, although he was a little more informative than I was. Considering there aren't hundreds of comments with the same thing I'm going to go with drivers or some other program on our machines causing the issue as my tentative explanation for that.

Thank you for your patience and knowledge. I'm sure dealing with people like me can be exasperating and most likely annoying. At best. But so far everything seems to work, so again, I thank you kindly for your help.

Expand  

It is the same issue based on what?

Have you looked at the event log? Post it.

If the same load order and setup runs through all of sudden without problem, then OS, driver settings, anti vir could be likely the problem.

What do you mean there are "hundreds of comments with the same thing"?

xLODGen/DynDOLOD not writing a log/bugreport is a very rare thing. 2 cases IIRC.

[Illana]

Can anyone tell me how to fix this error?

[sheson]

  On 10/11/2021 at 12:52 PM, Illana said:

Can anyone tell me how to fix this error?

"Load order FileID [02] can not be mapped to file FileID for file "Occlsuion.esp""

Expand  

Click the "Help for this message" link as explained in the first post.

If this does not help any further, upload the logfiles and bugreport as explained in the first post.

As explained on the first post, do not post screenshots of error messages. Use the "Copy message top clipboard" link instead and then paste the text.

[skinjack]

Sorry again. Similar issue. Of course he only had the issue once, it took me several times to get DynDOLOD to run through properly.

And no, I haven't looked at the Event Log yet. I just got up, answered your question, and then was looking at a reply in the SkyUI posts and watching a suggested video. I was looking up event logs per your request and they don't look anything like the above, so I'm not sure I'm even in the right place. I apologize for my lack of knowledge in this area. I upgraded this computer to Windows 10 when I had it built and nothing is where I remember it from Windows 7. And I really haven't explored the Windows 10 system very much on this machine. That's why I didn't do any of the successive upgrades. I was happy with 7 until they stopped supporting it, and then I was strong-armed into upgrading.

Antivirus could be the issue. I run Norton, and they are notorious for taking a lot of things out of your control and then burying how to undo them. I really need to sit down and look at anti-virus programs again before this subscription is up.

And by hundreds of comment, I simply meant that there were NOT a lot of people complaining about a similar issue that we were so it must be our setups that are the issue, not some new bug we discovered for this Alpha. I'm not blaming DynDOLOD in any way. Its most likely my machine or setup causing any issues I have.

As I said before, everything seems to be running fine now. Next time I run DynDOLOD I will try to remember to get an event log if I have issues so that I can pass it along with the debug_log and bugreport.

[sheson]

  On 10/11/2021 at 2:26 AM, z929669 said:

This is my first time experiencing this. Not a DynDOLOD issue but rather a model issue I am thinking. The aspen hybrids are very dark relative to full and other trees seem fine. Any idea offhand what might cause this? Using default TexGen settings, and only the aspens seem impacted. I'm thinking it is something with the crowns, but they are copied over from the full models as usual. Model examples follow if you care to have a look (tree mesh rule is Level0/Level1/Level2 with all else default):

 

Expand  

This happens because the UV of the branches has coordinates < 0.0.
After inserting new vertices and triangles in order to have untitled UV, LODGen runs the face normals and update tangents spell.
In this case this destroys the original normals. You can replicate the problem in NifSkope by running the face normal spell there.

In case you do not want want to fix the UV to be inside 0.0 and 1.0, you could try to add spherenormals to the shape name to test if that helps.
Also next LODGen included in the next alpha will properly respect the "Texture Clamp Mode" on on the BSShaderProperty. So you can just set CLAMP_S_CLAMP_T to "fix" the UV to be inside 0.0 and 1.0 without having to edit the UV itself.

[z929669]

  On 10/11/2021 at 5:42 PM, sheson said:

This happens because the UV of the branches has coordinates < 0.0.
After inserting new vertices and triangles in order to have untitled UV, LODGen runs the face normals and update tangents spell.
In this case this destroys the original normals. You can replicate the problem in NifSkope by running the face normal spell there.

In case you do not want want to fix the UV to be inside 0.0 and 1.0, you could try to add spherenormals to the shape name to test if that helps.
Also next LODGen included in the next alpha will properly respect the "Texture Clamp Mode" on on the BSShaderProperty. So you can just set CLAMP_S_CLAMP_T to "fix" the UV to be inside 0.0 and 1.0 without having to edit the UV itself.

Expand  

Thanks so much for the analysis. Very helpful.

[mattski123]

Hey, this mod called Skyrim Platform just released and it also has an easier way to convert .psc files to .ts files. Can you please update this to speed up the scripting processes?

Let me know!

[z929669]

  On 10/11/2021 at 2:26 AM, z929669 said:

Running latest alpha for the first time after upgrade from Alpha 44 (clean directory). TexGen runs fine, but DynDOLODx64 is failing without reson. LODGenx64 completes without issue long after DynDOLOD fails. No bugreport.txt, and no DynDOLOD log or debug log generated. Tree report is fine.

This is now acting like my xLODGenx64 unresolved issues.

I am running DynDOLOD in the same manner with same settings as I have been for months now. Alpha 44 ran without issue, and this is essentially a repeat using Alpha 47.

It seems the error occurred during logging of this file or immediately after:

App window closed.

Event:

Faulting application name: DynDOLODx64.exe, version: 3.0.0.0, time stamp: 0x615ec9a2
Faulting module name: KERNELBASE.dll, version: 10.0.19041.1202, time stamp: 0xc9db1934
Exception code: 0x0eedfade
Fault offset: 0x0000000000034f99
Faulting process id: 0x7c08
Faulting application start time: 0x01d7be43e42f7282
Faulting application path: C:\Modding\Tools\DynDOLOD\DynDOLODx64.exe
Faulting module path: C:\Windows\System32\KERNELBASE.dll
Report Id: dd705d9e-af4b-46e4-acd9-879a7c1b1261
Faulting package full name:

 

EDIT: Ran without issue the second try. No changes otherwise.

EDIT2: This is my first time experiencing this. Not a DynDOLOD issue but rather a model issue I am thinking. The aspen hybrids are very dark relative to full and other trees seem fine. Any idea offhand what might cause this? Using default TexGen settings, and only the aspens seem impacted. I'm thinking it is something with the crowns, but they are copied over from the full models as usual. Model examples follow if you care to have a look (tree mesh rule is Level0/Level1/Level2 with all else default):

 

Expand  

@sheson Setting string to SphereNormals at BsTriShape node resolved!

[AiElias]

  On 10/11/2021 at 3:25 PM, z929669 said:

I just want to point out that I believe the doc states (or sheson stated somewhere) that transition changes should be tested with collision and without speedmult ≥ 500. I do all of my LOD testing without collision and at high speed in sneak mode, but not for transitions (which are fairly stark when flying around like this).

Expand  

I still think this is important for LOD testing regardless. Player speed is much slower than this and depending on the load on a system, it can result in the player being closer to the transition that would normally be possible. Furthermore, because of the distant shadows in ENB, trees appear different from above than below and thus should be assessed from the perspective they're seen most, below.

[AiElias]

  On 10/11/2021 at 2:14 PM, sheson said:

If grass LOD was generated with mode 1 and the gap goes away when using uGridsToLoad 5, then NGIO might be hardcoded to 5 cells for DynDOLODGrassMode = 1.

If that is the case set Set DynDOLODGrassMode = 2 and use mode 2 for grass LOD generation to use uLargeRefLODGridSize cells distance.
Or keep using sane uGridsToLoad 5.

Expand  

Setting GrassMode to 2 seems to be working much better though I'm still not convinced it's working correctly with both full grass and lod grass sometimes being loaded at the same time. I have opened up a bug report on the NGIO page, hopefully meh321 will get back to me. If not, I might bug him on Discord. XD Thanks!