TES Skyrim 0.241

[kaffeekranz]

Btw i was wrong my Video their shows the typical engine UGRID issue, not sure why the setting failed to be applied previously

uGridsToLoad=6

already fixes it on those 2 major parts though a 3rd testscase isn't even fixed with uGridsToLoad=7 i will look into this 3rd level part more carefully it's pretty tricky from the distance though still perceptual problematic in the Gameplay flow

Im very very surprised that Bethesda chose the default uGridsToLoad=5 for Ultra it is definitely not enough by any means for their own level Design setup that's pretty crazy it makes 0 sense it's much to obvious what happens (see my video of testcase1).

Though Z-fighting now becomes a more obvious problem even @ 6 maybe Bethesda tried to avoid it by the lower ugrid setup also @ ultra and making the decission Z-fighting is more evil then mesh lod fading in your face ?

How does the Witcher 2 compensates this ? Distant Lod vs Z-fighting ?

Cruncher, please get your basics right.
You're only supposed to use odd numbers for the ugrids.
It's been that way since Oblivion.

[ENBSeries]

Z-fighting is not a problem actually, it's just another shitty thing from bugthesda. If you look carefully then will find out that some distant objects (like flickering mountains) drawed as two meshes overlapping. At such conditions z-fighting happen even near camera.

[Maeldun]

CruNcher
The default uGridstoLoad=5 was set for stability and performance. You have to realize that Bethesda Game Studios' target audience was using 7 year old consoles with obsolete graphics hardware.

[kaffeekranz]

Knowing what Bethesda is now makes predicting that things won't change rather easy though.
We'll see the same flawed engine for years to come.

[ENBSeries]

Version updated, download again
Optimized shaders of water displacement, added parameter EnablePrecache to [WATER] category. If enabled, mod convert water textures to special format and use them only to increase performance of displacement. The downside of caching is in delay when water is first time seen on screen (texture size dependent), it almost not noticable when memory manager disabled. Another bad thing is extra video and system memory cost, i did buffer of 40 mb max, probably for existing water mods it will be about 16 mb mostly. Cache effective only when water textures uncompressed (not dxt1-5 formats), size of textures is big enough (see difference when 2048*2048, but don't have it with 512*512), videocard have slow video memory.

[CruNcher]

Z-fighting is not a problem actually, it's just another shitty thing from bugthesda. If you look carefully then will find out that some distant objects (like flickering mountains) drawed as two meshes overlapping. At such conditions z-fighting happen even near camera.

Yep Boris i saw this mostly the objects that overlay in the distance are starting to flicker

sometimes you see entire rock parts showing out of other geometry and exactly that small rock part starts to flicker on camera movement it's just 1 or 2 pixels but they become extremely annoying

@kaffekranz
What happens if i dont use odd numbers

i really fall in love with ugridstoload=8 in my testing so i guess i will continue working with that and see how that works out

also 8 is pow2 and most calculations that have todo with blocks (grids) tiles are pow2, so i dont see a math stability problem here for now, on the contrary odd numbers make rarely sense.
the only problem i see is how much of the distance actually becomes visible so that certain AI things could go wrong i heard that @ ugridstoload 11 for example NPC actions can be wrongly triggered and result in wrong logical flows as they where intended. Though i dunno where those parts in the Game are to test them with 8 and see if they go wrong with it as well.

[wolfgrimdark]

The 0.1 and 0.3 SamplingRange value is more of a recommendation for game play in first person. If you want the best/better looking AO+IL you need to increase that value a lot but that will also decrease performance.

Thanks JawZ (see I do use your guide *grin*, fact is I reference it pretty often). Going to be testing out some combinations tonight.

Will also test out latest version of 241 as the the same time and see how the water goes.

[kaffeekranz]

@kaffekranz
What happens if i dont use odd numbers

i really fall in love with ugridstoload=8 in my testing so i guess i will continue working with that and see how that works out

also 8 is pow2 and most calculations that have todo with blocks (grids) tiles are pow2, so i dont see a math stability problem here for now, on the contrary odd numbers make rarely sense.
the only problem i see is how much of the distance actually becomes visible so that certain AI things could go wrong i heard that @ ugridstoload 11 for example NPC actions can be wrongly triggered and result in wrong logical flows as they where intended. Though i dunno where those parts in the Game are to test them with 8 and see if they go wrong with it as well.

This isn't something I'm pulling out of my buttocks - it's relevant information to the engine that's been available for 10 years!
I'm going to quote cdcooley from the Nexus here just so you can read through that.
Seriously man. For once. Do it right. You're always having inexplicable problems so hopefully you can at least avoid this.

Actual information:

Back in Morrowind you could use the TG (ToggleGrid) console command to see the active cluster of loaded cells around the player. The player was always in the center cell of a group of nine cells. Then there was a one-cell boarder region for a full 5x5 cell buffer. The game would only process items and creatures in one of the inner nine cells but if I'm remembering correctly the others were partially loaded to allow seeing slightly into the distance. (Morrowind was a very foggy place because the graphics engine really don't show things at a very large distance.) The external buffer variable controlled how many cells could be stored in memory and the only reason to raise it above the default of 32 was so the game wouldn't have to reload everything from disk if you traveled back and forth between locations frequently. (With Recall and Intervention you could very easily jump back and forth between locations.) 32 was the default buffer value because it was the first power of two that was big enough to hold the cluster of 25 cells. It also had the benefit that by default if you were walking along a road and needed to walk backwards a few steps you wouldn't trigger a cell reload.

Oblivion technically made the size of the grid around the player a configurable setting (with the uGridsToLoad) and the buffer value no longer needed to be a power of two (the default was 36). But uGridsToLoad had to be an odd number to ensure there was still a center cell for the player. The default buffer value was set based on a 6x6 grid so that a player standing at the corner between a group of 4 cells wouldn't trigger excessive cell loads if moving around in that small area (while dodging around in the middle of combat for instance). People who used a teleportation mod for Oblivion found it valuable to double or triple the external buffer space allocated because it allowed the game to keep more cells in memory longer. Oblivion also introduced differing AI processing depending on NPC location. NPCs in the grid of active cells got full processing. Those in loaded cells that weren't in the active grid got some processing. Those in unloaded cells were virtually ignored unless they were marked as special.

The cell buffer value has to be large enough to hold all of the cells in the active grid of cells which is simply the uGridsToLoad value squared. Then you need a few more to avoid stuttering (so you can have both an old set and a new set in memory at the same time), uGridsToLoad+1 squared is always safe.

If nothing substantial has changed, the reason people can't reliably use more than a 5x5 grid is that for every cell loaded in that grid you have to load absolutely everything into memory and process it. A 32-bit application, high resolution texture pack, heavy AI and creature spawning mods, etc. all combine to make the idea of reliably loading more cells impractical in the long-term. People manage to hit the game's memory limit just with 25 cells loaded. Raising to uGridsToLoad to 7 effectively doubles the number of active cells. Since the basic game takes approximately 1GB it's easy to see how using a 7x7 grid is possible in a lightly modded game and even 9x9 would be possible. But as people explore more of the world (triggering more game overhead) and add more content with mods it's just too easy to get past the 3.2-3.6 memory limit for a 32-bit application. It's really not a matter of "if" 9 or 7 will cause you problems but "how soon" they will, unless you really want to run a game without mods.

[CruNcher]

8 or 9 then if 9 triggers these direct NPC AI activation problems their would only be 8 left no matter what he is saying about the center cell, and how soon is no reason really it doesn't fix anything it just puts it further away from you to happen so if it happens earlier that's no problem for me knowing it can't be fixed @ all.
And i have no problems these problems are in the Generic Game Design with the default ULTRA ugridstoload of 5 and they are to perceptible braking the Gameflow directly im not like someone who stands on the mountain looks down and sees the lod and starts to cry because he has such a powerful machine god dammit (i care about direct Gameflow brakes, stuff that happens in your direct view distance especially on huge objects some meters in front of you), but i didn't experienced them before because i only concentrated on 1 subsystem.

Though this still doesn't fix the stuck texture fading (close distance lod terrain texture fade in) which is also visually very problematic in the Gameflow, and which i till now could find no information about anywhere except what Boris has analyzed, and isn't related to the ugridstoload value.

[Phinix]

Just wanted to say thanks for v0.241. So far everything is working great. Had a minor issue with water ripples caused by the player being a bit choppy, but I see you updated the version with some new water tweaks so it may already have been resolved. Will test ASAP.

Also, I noticed you have coded it so new feature options are automatically added to custom weather files. Very smooth!

Happy holidays all.