DynDOLOD 3.00 Alpha 173

[mooit]

34 minutes ago, sheson said:

It looks like there have been plenty of other changes in the load between old and new output.
It seems you made further changes in the load order that rectified whatever caused seeing the LOD loading in late, too.

It was quite late when I was playing with this, but I could of sworn to make sure to keep the testing accurate, looking back, all I remember is changing the DynDOLOD DLL versions between the outputs.

But since I deleted my new outputs by mistake, all I recall next, I re created over the grass cache, xLODGen, TexGen, DynDOLOD. On my end, seeing the changes with only the DynDOLOD DLL versions seemed to be the issue. DLL 27, 29,30 always showed the enviroment popping in, the Test DLL didn't.

THANKS

Edited Saturday at 05:16 AM by mooit

[Chromatic]

On 6/26/2024 at 12:52 PM, sheson said:

That is unfortunate. If nothing else helps, I would try reinstalling driver only again as you did already or maybe try an older version, just to be sure.

To be honest, this isn't the first time I've been having these issues. I guess you have already noticed, but I had the same problem in November too and we couldn't find a conclusive answer back then either.

On 6/26/2024 at 12:52 PM, sheson said:

Interestingly in the last log it went past SIworld and had a problem one worldapace later in MerDesFantomes.

I already have high performance settings enabled on Windows each time I run xlodgen/texgen/dyndolod. The monitor does shut off by its own still due to the settings used, but I noticed the same issue happening even if I didn't let it shut off anyway.

On 6/26/2024 at 12:52 PM, sheson said:

There should be a related entry in the Windows Event log for Access violation at address 00007FFDF089C337 in module 'atio6axx.dll'. It probably won't help us much either, but it might indicate a driver/hardware problem. Typically problems when using the OpenGL API should be reported as OpenGL errors and not cause crashes in the driver.

I am looking for it, but haven't noticed such an entry in the Event Log.

However: After doing some research in this thread, I decided to install an older driver version like you also suggested. I went back all the way to 22.5.1 which was mentioned here in the past and surprisingly, everything worked fine and lod generation was successful even without a minimal driver install or shutting off AMD related processes. In fact, I ran DynDOLOD two different times with successful lod generation for each one (let me know if you still want me to post the logs anyway).

Does this mean that newer AMD drivers are a no-go?

Edited 4 hours ago by Chromatic

[sheson]

2 hours ago, Chromatic said:

To be honest, this isn't the first time I've been having these issues. I guess you have already noticed, but I had the same problem in November too and we couldn't find a conclusive answer back then either.

I already have high performance settings enabled on Windows each time I run xlodgen/texgen/dyndolod. The monitor does shut off by its own still due to the settings used, but I noticed the same issue happening even if I didn't let it shut off anyway.

I am looking for it, but haven't noticed such an entry in the Event Log.

However: After doing some research in this thread, I decided to install an older driver version like you also suggested. I went back all the way to 22.5.1 which was mentioned here in the past and surprisingly, everything worked fine and lod generation was successful even without a minimal driver install or shutting off AMD related processes. In fact, I ran DynDOLOD two different times with successful lod generation for each one (let me know if you still want me to post the logs anyway).

Does this mean that newer AMD drivers are a no-go?

Considering there are no other reports at the moment, the newest drivers seem OK.