SSE @ 60FPS On Midrange-PCs - My Guide

[Guest]

UPDATE 2019-12-18: Replaced "Noticeboard"-recommendation with "Missives"-mod, which is basically an improved version of the Noticeboard-mod.

 

---

 

Who this guide is for: People with neither lowend nor highend computers, but midrange (mine is a Ryzen5, GTX 1660, 6GB VRAM, 16GB RAM). People who cannot stand sub-60fps gameplay, and who will happily sacrifice 5-10% in quality, for a constant 60 FPS at 1920p. People who're over the "install every mod under the sun"-phase, and understand you can't have a smooth gameplay-experience with 200+ mods.

 

Whom this is not for: Screenarchers who want perfect stills to show-off. High-end rigs that don't need to care about inefficiencies. People who think "30fps is fine", so long as they can run 300 mods, opencities, 200 added NPCs with complex AI, and most importantly: Fully reflective hi-poly teaspoons with 4K textures.

 

In other words: My target-audience is people with affordable yet decent hardware, that just want to play the game instead of taking screenshots, and who look for "most bang for the buck"-approaches, instead of installing everything and the kitchen-sink.

 

For this you don't need a long list of mods (such as the "skyrim SE for beginners"-sticky, which has nothing to do with "beginners", but is simply a list of every halfway popular mod under the sun). No, all you need is keeping a few general principles in mind when moddying SSE - plus a few hints about stuff that absolutely kills performance. But enough preamble - let's dive right into it.

 

 

THE THREE MAIN BOTTLENECKS:
----------------------------------
CPU, VRAM, GPU-speed - those are the 3 ressources to always keep in mind, whenever you think about changing something about skyrim. And each is a premise for the next one - in that order. So: If your CPU can't keep up, your graphics-card doesn't matter. And if the VRAM is constantly swapping textures, it doesn't matter how fast your GPU is. Why? Read on.

 

OPTIMIZING CPU-TIME:
--------------------------

Spoiler

Skyrim treats CPU-tasks as mandatory, which means if the CPU hasn't finished its work in time, the frame simply isn't drawn. This is a simplification of course, but in practice the behavior is just that: If the used CPU-cores are at their limit, frames are simply skipped.

 

The single biggest performance-gain you can get in SSE is, to get the engine to multithread properly. This alone gets you from 30fps to 90fps in most areas. The problem is: SSE-multithreading is basically black magic. Nobody really understands, why the engine sometimes does the stuff it does. On some systems, it automatically uses 4 cores. On other systems, one core will be at 100% and another one at 40%, and the game lags like hell. And the later case happens no matter your ini-settings.

 

Here's a fix i found for my sixcore system, where SSE suffered from the "1,4 cores"-syndrome: I launch SSE, alt-tab, open my taskmanager, and in the skyrimse-process set core-affinity to #1 only. This forces SSE to put it's main-thread (and all others) on core #1. After a few seconds, i then change affinity to #1-5 (leaving #6 for the OS and other programs). And magic: Suddenly SSE+ENB uses 5 cores, and framerates shoot through the roof. I've also red that if your CPU has hyperthreading enabled, you should change iHWThreads to double the cores you want it to use (i cannot confirm this myself, since i have hyperthreading disabled on my rig).

 

So with your cores properly utilized, what else is there to consider? AI and script-heavy mods - in that order. SSE's AI has abysmal performance. If you want smooth gameplay in cities, do not install those mods, that add dozens of people to cities. No birds either, since those are just AIs like any NPC. In short: Every "actor" in the game is an AI - keep that in mind when choosing mods.

 

Most bang for the buck option, to make skyrim less empty? "Adventures and Travellers" plus "Immersive Encounters". Both are light on scripting. The former roam not just the lands, but also visit cities and taverns, so that's 3 birds with a single stone. And the later add encounters - basically a lightweight 3DNPC. Both are fully configurable via MCM, in how much load to add to the game.

 

Also instead of adding two dozen questmods, that potentially conflict with each other, consider using a handful of lightweight radiant-quest generators instead, such as "Missives" (An improved version of the "Noticeboard"-mod).

 

OPTIMIZING VRAM:
----------------------

Spoiler

If your VRAM is at its limit and constantly swapping textures, it does not matter how fast your GPU is, because it's just waiting for textures. If at gameload you're already at 80% VRAM-load, you've done something wrong, because it means there will be no room to cache frequently used textures. Target 60-70% at gameload instead.

 

So which texture-mods to install? Wrong question: Most of them are replacers - they don't add textures but replace existing ones. The right question is: What resolution for which textures, and do they use compression?

 

Why is resolution so important? Because every doubling of resolution, QUADRUPLES memory-consumption. So 1K is 1MB (plus mipmaps), 2K is 4MB, and 4K is 16MB per texture. Multiply by specular-maps and stuff, and textures for a single object in 4K might approach 100MB. That's just ONE OBJECT ON SCREEN, and there will anywhere from 50-100 objects on screen, plus landscape and architure. You do the maths.

 

So with that in mind:

 

- Do you actually need those tiny jewelry-rings to be in 4K, even though no screen can even display that unless fully zoomed in? No? Then why did you choose that option in SMIM?

 

- Do you need falling leafs in 4K? Are you gonna zoom in on those in normal gameplay?

 

- How often anyways do you closely look at small clutter in normal gameplay, as opposed to screenarchery?

 

- Conversely, what do you actually look at most of the time? Which things are most prone to "texture-stretching", and hence actually benefit from 2K or 4K?

 

It's the last question that provides the answer: Terrain, sky, architecture, skin and dress. Everything else (including grass) can do with 1K or less. Heck, for the sky even clouds are fine in 1K - it's not like a puff of smoke has a lot of detail. And why anyone needs distant-LOD at 1K is a mystery to me - i mean, those are small bits in the distance - it's not like your screen even has 1000 pixels on that scale. Heck, even 256p for distant-LOD looks fine here.

 

So, texture-resolutions are actually fairly easy to pick. Except for one problem: The "dress"-part. 4K skins are workable - it's not like there's that many races, and textures are heavily reused between races (creatures is a different story - i'd keep the big ones at 2K, and small ones at 1K). But clothing and armor? There's hundreds of 'em, and you're constantly looking at this stuff.

 

And with those words being said, you already know the painful conclusion, right? 4K armorpacks are not a thing - at least not if you want 60FPS performance. The maths just don't work out.

 

Most bang for the buck options:

 

1. https://www.nexusmods.com/skyrimspecialedition/mods/21166
   1GB VRAM FOR FREE! Replacement Vanilla Texture-BSAs. Original resolution,
   fully mipmapped, yet lower memory consumption, thanks to texture-compression.

 

2. https://www.nexusmods.com/skyrimspecialedition/mods/23316?tab=files

   Choose your own texture-resolution for any mod, thanks CAO Beta now including
   a batch-downscaler, that automatically generates mipmaps and reduces memory
   via texture-compression - all with the single press of a button.

 

How to use CAO-beta: First, download your mod and install using the most fitting
options. Then browse the mod's texture-folder: Look at what things the textures
are for, and what resolution they use. If you find a subfolder with excessive
textures, fire up CAO (outside of modman!). Select the SSE-preset and click the
"choose folder"-button. Select the matching folder. Then click the textures-tab
and tick the checkboxes. There are two options: Downscaling by ratio or max.
resolution.

 

The ratio-option is easy to understand: "2" for example means "divide by two"

so all textures in the folder would be halved in resolution. This sometimes makes sense,

but usually you want the "by resolution"-option instead: There you define the

maximum horizontal and vertical resolution for textures in that folder.

So if i.e. you enter 2048, 2048, any texture wider or taller than 2K will be

downscaled to 2K, but smaller-resolution textures won't be rescaled.
This keeps aspect-ratio, so you don't need to worry about rectangular textures.

 

OPTIMIZING GPU-PERFORMANCE:
-------------------------------------

Spoiler

There's two parts to this: Polycount and efffects.

 

Polycount is simply a matter being careful with mesh-replacers. Does anyone not
obsessed with screenarchery actually need full 3D-chains? (yes, i'm looking at
you again, SMIM). What, you never even noticed those are 2D? See, so you don't
need polys where nobody's looking.

 

Basically the same question as with textures applies: What are you actually
looking at most of the time? There's a difference though: With textures, having
the things you care about many times on screen is a good thing, because reusing
the same texture doesn't cost extra VRAM. With meshes instead, it's the other
way around: The more objects you care about appear on screen, the worse.

why? Because rendering the same mesh multiple times does multiply the cost.
Take landscape, architecture and trees for example: You see those all the time,
and that's precisely why increasing their polycount will have the biggest
performance-impact on your game.

 

On the upside: Stuff you don't care about appearing often on the screen is
actually a good thing. All that clutter lying around? Fuck polycount and keep
that vanilla. (Sorry SMIM, i don't care about HD tablespoons).

 

There's two odd cases however, where the IMO most satisfying solution is

counterintuitive: Grass and trees.

 

Grass:

Everyone cries about grass render-distance, right? Everyone wants more grass.

But somehow nobody asks for higher-poly grass, even though this stuff is

right in your face and ideally everyhwere. Why wouldn't you want more polys,

on something like that?

 

Answer: Because cost is exactly the problem. Vanilla grass is too expensive,

to render at far distances, so the solution is lower the cost, not increase is.

 

Check this out: https://www.nexusmods.com/skyrimspecialedition/mods/21954

 

"These models consist of only 3 triangles. For perspective, your typical shrub
consists of 1500. Most grasses in vanilla or mods consist of 12 to 200 triangles."

 

Yes, the installer has a "grass-only" option, and no: Cathedral Weathers is NOT

a requirement - they just say that, because both LOOKS well together.

It's an aesthetic recommendation, not an actual technical requirement.

I run Cathedral Grass together with CoT, and it looks fine.

 

So now you can have all the grass you want. Crank it up to the horizon,

with minimal performance-impact. Personally, i have my fade-distance set

to 20000, which is far enough to usually blend in with distant-LOD.

 

Trees:

Once again, the solution for midrange-rigs IMO is to reduce polycounts

instead of increasing them, in exchange for quantity and no dreaded "pop-in".

 

How? Disable skinned trees, but keep animation enabled. This gets rid of all pop-in

at midrange, and the saved performance you can then invest in rendering trees up

to horizon: Get DynDOLOD and the requirements, indistinguishable vanilla tree

billboards, and compile for either 256p or 512p distant-LOD (Again: 256p looks

perfectly fine here - theses are tiny things in the distance, after all - nothing close-up).

Then with DynDLOD ready, crank up the tree load-distance up to the horizon.

Billboards are cheap, so you can have a green Skyrim full of forests, at 1920p @ 60fps.

Did i mention no more pop-in already?

 

So to conclude meshes: You want high-poly on characters, and if you can

afford it landscape. The solution to having lots of grass and trees without pop-in

is not to upgrade quality, but downgrade in exchange for sheer quantity.

Be conservative with any other mesh-replacements, and choose carefully

- especially about clutter. You'll find the reason why raising clutter-polycount

is a bad idea, further down in the section about occlusion-culling.

Moving on to effects: Skyrim and even SSE has been around for a long time, and

 

there's a downside to that - obsolete information. Many things people worried
about years ago - such as ambient occlusion - i found to have almost zero performance
impact on my current midrange hardware and up-to-date ENB. At the same time,
i found things to be a big performance-drain, that i haven't seen mentioned
anywhere before.

 

Let's start with the stuff that was true, and still is true:

- Godrays suck performance - be it vanilla or ENB.
- Shadows suck performance - be it vanilla or ENB.

 

Not all shadows (and light) are made equal though:

- Standard vanilla shadows and the resolution issue: Nothing has changed.
  Choosing vanilla resolution vs distance is still the biggest performance
  decision about shadows, yet also makes the biggest quality difference.

 

- Enabling landshadows: Minor but noticable performance hit.

  It makes a big difference in appearance, so is well-worth the 2-4fps cost.

 

- ENB "Detailed Shadows"-setting: Medium performance hit. This was a surprise
  to me, since i haven't seen this mentioned anywhere else. The effect is very subtle

  but noticable. IMO not worth the 5-10fps cost.

 

- ENB "Complex Firelights" with "Big Range" enabled: High performance hit.
  Also not mentioned anywhere. It's a bummer, because "big range" does make
  a big visual difference (just try toggling it). Interestingly enough,
  enabling or disabling shadows for complex firelights has no noticable impact
  on performance.

 

- ENB "Complex Particlelights" with "Big Range" enabled: Same as with firelights,
  but medium impact on performance. You might want to keep this one enabled.
  As with firelights, shadowcasting seems to be free for this one.

 

Things people worried about in the past, but which made no big difference to me:

 

- Reflections in general. At low resolution like 512 (reflections are blurred
  anyways, so you barely notice it), the difference was about 1 FPS on my rig.

 

- HDR. Seems to be essentially free on my midrange GPU and current ENB-binaries.

 

- Every other ENB-effect not mentioned above: On current midrange GPUs, you can
  basically enable everything except godrays, detailshadows, and bigrange for
  complex lights - there's almost no performance hit, even for ambient-occlusion.
  HOWEVER: This holds true if you set "quality" to "low" (2) for every effect.
  How much a visual difference does that make? Frankly, on my 2k display the
  answer is "0% difference in normal gameplay". Only when i pause the game,
  look closely at individual objects, and keep flicking quality-settings,
  only then can i notice "a few pixels look different". Frankly, i see no reason
  for anyone but screenarchers, to run ENB with anything else than "low" quality,
  because there is no noticable difference in normal gameplay.

 

Things that do make a substancial difference, at no noticable performance cost,
that i haven't seen mentioned before:

 

- In skyrim.ini, display-section, set "bActorSelfShadowing=0". This will prevent
  actors from casting shadows on themselves (like holding an arm in front of your
  body). Yes, it's nice in theory, but it is also where skyrim's ugly pixelated
  and striped shadows look the worst. This in combination with the next setting
  will get rid of most of the weird lighting-artifacts on your character's skin.

 

- ENB SSAO_SSIL: Make sure "complex filter" is enabled, to get rid of another
  source of shadow-artifacts on your character's skin. The blur-filter won't do
  that (in fact it makes no visual difference here, so i have it disabled).
  Complex filter is what you want enabled - no noticable performance-hit here.

 

EDIT: Bonus round! Working around SSE's broken occlusion-culling:

 

Occlusion-culling means not rendering stuff you can't see. In interiors and cities,

that's actually the majority of objects nearby - yet SSE renders them, because

it's automatic occlusion-culling implementation is broken. You might stand

in front of a door, FPS drops like crazy, and you wonder what's so hard to

render about this door. Well: It's the hundreds of clutter-objects behind that

door, which a modder with no sense of performance has placed in your home.

 

Same thing can happen in cities, when standing in front of a building - even

on the outskirts of Whiterun, at the stables: You wonder what's so complex

about those stables - is it the horsies? No: It's all the other farms and objects

behind the stables, that you can't even see!

 

In theory modders can fix this, by manually placing so called "occlusion-planes"

(basically for every wall in skyrim, they would need to manually tell beth's

stupid engine: "This is a wall, okay?! Don't render past that, stupid!".

 

You get the idea: Nobody bothers to do it, so you're left with an engine

that spends more than half of its render-calls, on stuff you can't see.

And there's no fix - only damage-control.

 

How? Render-distances for items and objects!

(the two sliders in the ingame-settings).

 

Why is this an effective workaround? Because the stuff adding the

most triangles in those scenarios are SMALL THINGS. Small things

become tiny past a certain distance, and hence can be faded out

with you barely noticing.

 

Now what's the difference between items and objects? Items are

movable things affected by havok - swords, armor, bottles,

plates, food-items - you get the idea: All of those are very small.

 

Objects are unmovable things that are still interactive, such as

harvestables like flowers, planted cabbages or hay. Objects tend to

be larger than items, so they can be seen further. But they're still,

small compared to trees and buildings - in other words, they don't

need distant LOD, which is why most objects have no DOLOD.

 

So how do you best find out, what's a good distance to fade-out

items and objects? I use the following to methods:

 

For items, i go to the Whiterun market at day, and look at the

veggies and meat on the stands. Then i move backwards

on the street until i'm next to Breezehome. At that point,

the items on the market are just 2-3 pixels in size.

This is about the distance where items can start fading

without you noticing. Set the item-fade slider accordingly.

 

For objects, i go outside Whiterun past the stables,

and look at the green cabbages on the farms.

Moving backwards enough for them to be just

2-3 pixels in size, usually results in excessive distance,

but 3-4 pixels can be "good enough", which is where

i usually set my object-fade distance.

 

UPDATE: Real occlusion culling for indoor-spaces!

Turns out at least one modder actually did the work,

of manually placing "occlusion planes" in walls.

 

It's calleed Project Optimization:

https://www.nexusmods.com/skyrimspecialedition/mods/14084/

 

The catch? According to the mod description, it only fixes

interriors - which don't have bad performance to begin with,

except for modded playerhomes, but Project Optimization is

incompatible with those, which is why it offers a "no-homes"-version.

So, it's kind of a solution to a non-problem. But hey, every

bit helps, so you might want to give it a try.

 

 

HAVOKFAIL AND VSYNCFAIL:
--------------------------------

Spoiler

Last things last: Havok for unexplainable reasons actually is very much related
to running SSE at a constant 60 FPS. For also unexplainable reasons, FPS-limiters
are relevant to running SSE with VSync enabled.

 

Let's tackle havok first: In bethesda's infinite wisdom, they designed the physics
engine like an arcade-game - that is, it expects to run at 60FPS, not a frame more
and not a frame less. And then they tied havok to the render, which results in
actors and objects blinking in and out of existance, and in general everything
going full monty python, if havok doesn't get its 60FPS - and not a frame more.

This is bad news for a couple of reasons: Variable or higher-refreshrate monitors
are the obvious, but there's also other things this sucks for: Frame-buffering
for example. Forget letting your GPU render 2 frames ahead, so smooth out the
occassional slow frame. In fact, forget pretty much any framebuffer-related
performance optimizations.

 

There's a tool called "havokfix", that supposedly "fixes" this, by dynamically
adjusting havok's clock in realtime. At least on my rig, havokfix did not fix
havok: It reduced the amount of weirdness going on, but objects and chars still
flickered every few seconds. Ironically enough, this is even visible on youtube
videos, where people proudly proclaim "SSE at 100hz without glitches", all while
precisely those glitches are happening live for all to see.

 

From my observation, the problem is that havokfix simply isn't fast or precise
enough. It does adjust havok's clock in realtime, but not at the precise timing
beth's fooked engine needs for not glitching out.

 

So unless it magically works on your system, forget the whole idea and just
accept running SSE at 60FPS fixed, with VSYNC-enabled. Easier said than done:
It turns out SSE skips frames even when vsync is on. It's like it's own renderer
wants to go faster than havok (and the GPU allows this even with vsync on,
because at least on NVidia-cards the minimum number of prerendered frames is 1),
then havok cries "not so fast! wait for me!", and the renderer just stops until
havok catched up, resulting in a constant +1, -1, +1, -1 pattern, and with vsync
not allowing intermediate updates, that averages to.... 30 FPS.

 

Long story short: The only way i got SSE to run at constant smooth 60 FPS,
was to enable VSync, AND enable the ENB-limiter at the same time, which forces
the renderer/GPU to not "run ahead".

 

---

 

That's it from me. Hope some of this stuff was useful.

 

[McAztec]

This looks very useful. Now I'm technically in the category of highrange PCs, but my setup's not that much different from yours tbh (Ryzen 5 1600 OC@3.7Ghz, GTX 1080 and 16GBRAM, sorry for the flex, had to) and I find this interesting to say the least, there's really good info here. I'm gonna check out some of those smoothing tips you mention and also the core affinity since in some areas, like in the modded Lakeview manor, I see the frames drop to like 40-ish in a noticeable way at times and I suspect it's related to SSE dumping all it's stuff on a few unlucky cores. Either way, good stuff?!

[tweetbotter]

Quote

The single biggest performance-gain you can get in SSE is, to get the engine to multithread properly. This alone gets you from 30fps to 90fps in most areas. The problem is: SSE-multithreading is basically black magic. Nobody really understands, why the engine sometimes does the stuff it does. On some systems, it automatically uses 4 cores. On other systems, one core will be at 100% and another one at 40%, and the game lags like hell. And the later case happens no matter your ini-settings.

 

Here's a fix i found for my sixcore system, where SSE suffered from the "1,4 cores"-syndrome: I launch SSE, alt-tab, open my taskmanager, and in the skyrimse-process set core-affinity to #1 only. This forces SSE to put it's main-thread (and all others) on core #1. After a few seconds, i then change affinity to #1-5 (leaving #6 for the OS and other programs). And magic: Suddenly SSE+ENB uses 5 cores, and framerates shoot through the roof.

 

You do this every time you start playing? Or do you have a script/macro that executes automatically? 

I'm surprised to read that SSE uses multiple cores-coming from LE there were always strategies to try to get LE to run on multiple cores, but it never worked out (which is why I always check single core performance in new CPUS, lol) 

 

[nemocdt]

14 hours ago, lynak said:

Who this guide is for: People with neither lowend nor highend computers, but midrange (mine is a Ryzen5, GTX 1660, 6GB VRAM, 16GB RAM). People who cannot stand sub-60fps gameplay, and who will happily sacrifice 5-10% in quality, for a constant 60 FPS at 1920p. People who're over the "install every mod under the sun"-phase, and understand you can't have a smooth gameplay-experience with 200+ mods.

 

Whom this is not for: Screenarchers who want perfect stills to show-off. High-end rigs that don't need to care about inefficiencies. People who think "30fps is fine", so long as they can run 300 mods, opencities, 200 added NPCs with complex AI, and most importantly: Fully reflective hi-poly teaspoons with 4K textures.

 

In other words: My target-audience is people with affordable yet decent hardware, that just want to play the game instead of taking screenshots, and who look for "most bang for the buck"-approaches, instead of installing everything and the kitchen-sink.

 

For this you don't need a long list of mods (such as the "skyrim SE for beginners"-sticky, which has nothing to do with "beginners", but is simply a list of every halfway popular mod under the sun). No, what you need for a smooth-running "most bang for the buck"-setup is, just keeping a few general principles in mind - plus a few hints about stuff that absolutely kills performance. But enough preamble - let's dive right into it.

 

 

THE THREE MAIN BOTTLENECKS:
----------------------------------
CPU, VRAM, GPU-speed - those are the 3 ressources to always keep in mind, whenever you think about changing something about skyrim. And each is a premise for the next one - in that order. So: If your CPU can't keep up, your graphics-card doesn't matter. And if the VRAM is constantly swapping textures, it doesn't matter how fast your GPU is. Why? Read on.

 

OPTIMIZING CPU-TIME:
--------------------------

  Hide contents

Skyrim treats CPU-tasks as mandatory, which means if the CPU hasn't finished its work in time, the frame simply isn't drawn. This is a simplification of course, but in practice the behavior is just that: If the used CPU-cores are at their limit, frames are simply skipped.

 

The single biggest performance-gain you can get in SSE is, to get the engine to multithread properly. This alone gets you from 30fps to 90fps in most areas. The problem is: SSE-multithreading is basically black magic. Nobody really understands, why the engine sometimes does the stuff it does. On some systems, it automatically uses 4 cores. On other systems, one core will be at 100% and another one at 40%, and the game lags like hell. And the later case happens no matter your ini-settings.

 

Here's a fix i found for my sixcore system, where SSE suffered from the "1,4 cores"-syndrome: I launch SSE, alt-tab, open my taskmanager, and in the skyrimse-process set core-affinity to #1 only. This forces SSE to put it's main-thread (and all others) on core #1. After a few seconds, i then change affinity to #1-5 (leaving #6 for the OS and other programs). And magic: Suddenly SSE+ENB uses 5 cores, and framerates shoot through the roof. I've also red that if your CPU has hyperthreading enabled, you should change iHWThreads to double the cores you want it to use (i cannot confirm this myself, since i have hyperthreading disabled on my rig).

 

So with your cores properly utilized, what else is there to consider? AI and script-heavy mods - in that order. SSE's AI has abysmal performance. If you want smooth gameplay in cities, do not install those mods, that add dozens of people to cities. No birds either, since those are just AIs like any NPC. In short: Every "actor" in the game is an AI - keep that in mind when choosing mods.

 

Most bang for the buck option, to make skyrim less empty? "Adventures and Travellers" plus "Immersive Encounters". Both are light on scripting. The former roam not just the lands, but also visit cities and taverns, so that's 3 birds with a single stone. And the later add encounters - basically a lightweight 3DNPC. Both are fully configurable via MCM, in how much load to add to the game.

 

Also instead of adding two dozen questmods, that potentially conflict with each other, consider using a handful of lightweight radiant-quest generators instead, such as "Noticeboard".

 

OPTIMIZING VRAM:
----------------------

  Hide contents

If your VRAM is at its limit and constantly swapping textures, it does not matter how fast your GPU is, because it's just waiting for textures. If at gameload you're already at 80% VRAM-load, you've done something wrong, because it means there will be no room to cache frequently used textures. Target 60-70% at gameload instead.

 

So which texture-mods to install? Wrong question: Most of them are replacers - they don't add textures but replace existing ones. The right question is: What resolution for which textures, and do they use compression?

 

Why is resolution so important? Because every doubling of resolution, QUADRUPLES memory-consumption. So 1K is 1MB (plus mipmaps), 2K is 4MB, and 4K is 16MB per texture. Multiply by specular-maps and stuff, and textures for a single object in 4K might approach 100MB. That's just ONE OBJECT ON SCREEN, and there will anywhere from 50-100 objects on screen, plus landscape and architure. You do the maths.

 

So with that in mind:

 

- Do you actually need those tiny jewelry-rings to be in 4K, even though no screen can even display that unless fully zoomed in? No? Then why did you choose that option in SMIM?

 

- Do you need falling leafs in 4K? Are you gonna zoom in on those in normal gameplay?

 

- How often anyways do you closely look at small clutter in normal gameplay, as opposed to screenarchery?

 

- Conversely, what do you actually look at most of the time? Which things are most prone to "texture-stretching", and hence actually benefit from 2K or 4K?

 

It's the last question that provides the answer: Terrain, sky, architecture, skin and dress. Everything else (including grass) can do with 1K or less. Heck, for the sky even clouds are fine in 1K - it's not like a puff of smoke has a lot of detail. And why anyone needs distant-LOD at 1K is a mystery to me - i mean, those are small bits in the distance - it's not like your screen even has 1000 pixels on that scale. Heck, even 256p for distant-LOD looks fine here.

 

So, texture-resolutions are actually fairly easy to pick. Except for one problem: The "dress"-part. 4K skins are workable - it's not like there's that many races, and textures are heavily reused between races (creatures is a different story - i'd keep the big ones at 2K, and small ones at 1K). But clothing and armor? There's hundreds of 'em, and you're constantly looking at this stuff.

 

And with those words being said, you already know the painful conclusion, right? 4K armorpacks are not a thing - at least not if you want 60FPS performance. The maths just don't work out.

 

Most bang for the buck options:

 

1. https://www.nexusmods.com/skyrimspecialedition/mods/21166
   1GB VRAM FOR FREE! Replacement Vanilla Texture-BSAs. Original resolution,
   fully mipmapped, yet lower memory consumption, thanks to texture-compression.

 

2. https://www.nexusmods.com/skyrimspecialedition/mods/23316?tab=files

   Choose your own texture-resolution for any mod, thanks CAO Beta now including
   a batch-downscaler, that automatically generates mipmaps and reduces memory
   via texture-compression - all with the single press of a button.

 

How to use CAO-beta: First, download your mod and install using the most fitting
options. Then browse the mod's texture-folder: Look at what things the textures
are for, and what resolution they use. If you find a subfolder with excessive
textures, fire up CAO (outside of modman!). Select the SSE-preset and click the
"choose folder"-button. Select the matching folder. Then click the textures-tab
and tick the checkboxes. There are two options: Downscaling by ratio or max.
resolution.

 

The ratio-option is easy to understand: "2" for example means "divide by two"

so all textures in the folder would be halved in resolution. This sometimes makes sense,

but usually you want the "by resolution"-option instead: There you define the

maximum horizontal and vertical resolution for textures in that folder.

So if i.e. you enter 2048, 2048, any texture wider or taller than 2K will be

downscaled to 2K, but smaller-resolution textures won't be rescaled.
This keeps aspect-ratio, so you don't need to worry about rectangular textures.

 

WARNING: CAO Beta3 at this time has a bug, where the drag-n-drop feature doesn't
work correctly. Do not drag-n-drop folders into CAO - use the button to select
folders instead.

 

OPTIMIZING GPU-PERFORMANCE:
-------------------------------------

  Hide contents

There's two parts to this: Polycount and efffects.

 

Polycount is simply a matter being careful with mesh-replacers. Does anyone not
obsessed with screenarchery actually need full 3D-chains? (yes, i'm looking at
you again, SMIM). What, you never even noticed those are 2D? See, so you don't
need polys where nobody's looking.

 

Basically the same question as with textures applies: What are you actually
looking at most of the time? There's a difference though: With textures, having
the things you care about many times on screen is a good thing, because reusing
the same texture doesn't cost extra VRAM. With meshes instead, it's the other
way around: The more objects you care about appear on screen, the worse.

why? Because rendering the same mesh multiple times does multiply the cost.
Take landscape, architecture and trees for example: You see those all the time,
and that's precisely why increasing their polycount will have the biggest
performance-impact on your game.

 

On the upside: Stuff you don't care about appearing often on the screen is
actually a good thing. All that clutter lying around? Fuck polycount and keep
that vanilla. (Sorry SMIM, i don't care about HD tablespoons). Or take grass
for example: Everyone cries about grass-render distance, right? Everyone wants
more grass, but somehow nobody asks for higher-poly grass. Why might that be?

 

https://www.nexusmods.com/skyrimspecialedition/mods/21954

 

"These models consist of only 3 triangles. For perspective, your typical shrub
consists of 1500. Most grasses in vanilla or mods consist of 12 to 200 triangles."

 

Yes, the installer has a "grass-only" option. Now you can have all the grass you
want. Crank it up to the horizon, with minimal performance-impact. Personally
i have my fade-distance set to 20000, which is far enough to usually blend in
with distant-LOD.

 

So to summarize meshes: You want high-poly on characters, and if you can afford it
landscape. Be very conservative with anything else, and consider not upgrading trees
but downgrading them instead to unskinned (but animated) trees. This will also
eliminate the whole tree-popin nonsense, since there will be no transition.
Billboards are cheap, so with DynDOLOD you can then crank up the tree-loaddistance,
and have trees up to the horizon with no pop-in whatsoever, at 60 FPS.

 

Moving on to effects: Skyrim and even SSE has been around for a long time, and
there's a downside to that - obsolete information. Many things people worried
about years ago - such as ambient occlusion - i found to have almost zero performance
impact on my current midrange hardware and up-to-date ENB. At the same time,
i found things to be a big performance-drain, that i haven't seen mentioned
anywhere before.

 

Let's start with the stuff that was true, and still is true:

- Godrays suck performance - be it vanilla or ENB.
- Shadows suck performance - be it vanilla or ENB.

 

Not all shadows (and light) are made equal though:

- Standard vanilla shadows and the resolution issue: Nothing has changed.
  Choosing vanilla resolution vs distance is still the biggest performance
  decision about shadows, yet also makes the biggest quality difference.

 

- Enabling landshadows: Minor but noticable performance hit. Again,
  unfortunatelly it also makes a big difference in appearance.

 

- ENB "Detailed Shadows"-setting: Medium performance hit. This was a surprise
  to me, since i haven't seen this mentioned anywhere else. Fortunally the effect
  is subtle (but noticable), so it can be disabled without missing too much.

 

- ENB "Complex Firelights" with "Big Range" enabled: High performance hit.
  Also not mentioned anywhere. It's a bummer, because "big range" does make
  a big visual difference (just try toggling it). Interestingly enough,
  enabling or disabling shadows for complex firelights has no noticable impact
  on performance.

 

- ENB "Complex Particlelights" with "Big Range" enabled: Same as with firelights,
  but medium impact on performance. You might want to keep this one enabled.
  As with firelights, shadowcasting seems to be free for this one.

 

Things people worried about in the past, but which made no big difference to me:

 

- Reflections in general. At low resolution like 512 (reflections are blurred
  anyways, so you barely notice it), the difference was about 1 FPS on my rig.

 

- HDR. Seems to be essentially free on my midrange GPU and current ENB-binaries.

 

- Every other ENB-effect not mentioned above: On current midrange GPUs, you can
  basically enable everything except godrays, detailshadows, and bigrange for
  complex lights - there's almost no performance hit, even for ambient-occlusion.
  HOWEVER: This holds true if you set "quality" to "low" (2) for every effect.
  How much a visual difference does that make? Frankly, on my 2k display the
  answer is "0% difference in normal gameplay". Only when i pause the game,
  look closely at individual objects, and keep flicking quality-settings,
  only then can i notice "a few pixels look different". Frankly, i see no reason
  for anyone but screenarchers, to run ENB with anything else than "low" quality,
  because there is no noticable difference in normal gameplay.

 

Things that do make a substancial difference, at no noticable performance cost,
that i haven't seen mentioned before:

 

- In skyrim.ini, display-section, set "bActorSelfShadowing=0". This will prevent
  actors from casting shadows on themselves (like holding an arm in front of your
  body). Yes, it's nice in theory, but it is also where skyrim's ugly pixelated
  and striped shadows look the worst. This in combination with the next setting
  will get rid of most of the weird lighting-artifacts on your character's skin.

 

- ENB SSAO_SSIL: Make sure "complex filter" is enabled, to get rid of another
  source of shadow-artifacts on your character's skin. The blur-filter won't do
  that (in fact it makes no visual difference here, so i have it disabled).
  Complex filter is what you want enabled - no noticable performance-hit here.

 

HAVOKFAIL AND VSYNCFAIL:
--------------------------------

  Hide contents

Last things last: Havok for unexplainable reasons actually is very much related
to running SSE at a constant 60 FPS. For also unexplainable reasons, FPS-limiters
are relevant to running SSE with VSync enabled.

 

Let's tackle havok first: In bethesda's infinite wisdom, they designed the physics
engine like an arcade-game - that is, it expects to run at 60FPS, not a frame more
and not a frame less. And then they tied havok to the render, which results in
actors and objects blinking in and out of existance, and in general everything
going full monty python, if havok doesn't get its 60FPS - and not a frame more.

This is bad news for a couple of reasons: Variable or higher-refreshrate monitors
are the obvious, but there's also other things this sucks for: Frame-buffering
for example. Forget letting your GPU render 2 frames ahead, so smooth out the
occassional slow frame. In fact, forget pretty much any framebuffer-related
performance optimizations.

 

There's a tool called "havokfix", that supposedly "fixes" this, by dynamically
adjusting havok's clock in realtime. At least on my rig, havokfix did not fix
havok: It reduced the amount of weirdness going on, but objects and chars still
flickered every few seconds. Ironically enough, this is even visible on youtube
videos, where people proudly proclaim "SSE at 100hz without glitches", all while
precisely those glitches are happening live for all to see.

 

From my observation, the problem is that havokfix simply isn't fast or precise
enough. It does adjust havok's clock in realtime, but not at the precise timing
beth's fooked engine needs for not glitching out.

 

So unless it magically works on your system, forget the whole idea and just
accept running SSE at 60FPS fixed, with VSYNC-enabled. Easier said than done:
It turns out SSE skips frames even when vsync is on. It's like it's own renderer
wants to go faster than havok (and the GPU allows this even with vsync on,
because at least on NVidia-cards the minimum number of prerendered frames is 1),
then havok cries "not so fast! wait for me!", and the renderer just stops until
havok catched up, resulting in a constant +1, -1, +1, -1 pattern, and with vsync
not allowing intermediate updates, that averages to.... 30 FPS.

 

Long story short: The only way i got SSE to run at constant smooth 60 FPS,
was to enable VSync, AND enable the ENB-limiter at the same time, which forces
the renderer/GPU to not "run ahead".

 

---

 

That's it from me. Hope some of this stuff was useful.

 

Thankyou, we basically have the same system i will be all up in everything you posted.

[Guest]

6 hours ago, twitterbutter said:

 

You do this every time you start playing? Or do you have a script/macro that executes automatically? 

I'm surprised to read that SSE uses multiple cores-coming from LE there were always strategies to try to get LE to run on multiple cores, but it never worked out (which is why I always check single core performance in new CPUS, lol) 

 

Originally i did it every time, then i got bored by the process, but couldn't be bothered to fully automate it. So now i launch the SKSE-loader (via modman) with a script, that starts skyrim in singlecore-mode. After loading to the main-menu, i then alt-tab once and set affinity to 1-5. It's not perfect but saves a few clicks.

 

To fully automate it, what you would need to do is:

1. START /affinity 1 "path-to-skse-loader-exe"

2. PING localhost -n 90 > NUL   (this simulates a 90sec pause on any windows machine)

3. Set affinity to all cores again, or whatever you want. The problem is, the above START command only works for launching apps, but now skyrim is already running, so we need a way to change affinity of a running process. I know powershell can do this via the GET-PROCESS and PROCESSORAFFINITY commands, but the syntax involves bitmasks, and at that point i got lazy and thought "Bah, i'll just do it via taskman" ?

 

Anyways, the actual "magic" at least on my win8.1 system seems to be, that SSE refuses to multithread properly, unless its main-thread is on core1. But windows is unlikely to do that by default - it will just pick whatever core has the lowest load at the time, and #1 is unlikely to be that. The set-affinity trick fixes that, by manually forcing all SSE threads to core1 (including main), and then giving it more cores again, at which point it somehow knows how to use extra cores. Again, this is on win8.1 with a 2nd-gen Ryzen5 and SMT disabled - your milleage may vary.

[chevalierx]

SSAO and skylighting + press effect ( skin + godray) = kill fps

[Guest]

2 hours ago, chevalierx said:

SSAO and skylighting + press effect ( skin + godray) = kill fps

Interesting - never used the press effect, so didn't notice that. Thanks for the hint!

 

Added item/object-fade hints, to deal with SSE's broken implementation of occlusion-culling. You can find it at the bottom of the "Optimizing GPU-performace" section.

[chevalierx]

11 hours ago, lynak said:

Interesting - never used the press effect, so didn't notice that. Thanks for the hint!

 

Added item/object-fade hints, to deal with SSE's broken implementation of occlusion-culling. You can find it at the bottom of the "Optimizing GPU-performace" section.

just disable game sao ( it look bad ) and godray + snow +flare , the sse is demanding more then LE , it look better with weather , no need enb ( sharp with reshed)

and less high poly or oc you gpu

[chevalierx]

19 hours ago, twitterbutter said:

 

You do this every time you start playing? Or do you have a script/macro that executes automatically? 

I'm surprised to read that SSE uses multiple cores-coming from LE there were always strategies to try to get LE to run on multiple cores, but it never worked out (which is why I always check single core performance in new CPUS, lol) 

 

it false in windows 10 it use theme all maybe i tweak windows but he use with all threads and core

[Guest]

Why you need CAO-Beta and a brain:

 

\

 

What is this? A single-color texture - 2048x2048 pixels worth of it - PLUS MIPAMPS! We can't have distance degrade the details of our precious.... single-color texture.

 

WTF is this for? It's the texture for water in a tankard.

 

WTF is this from? Animated Eating Redux V3 (not using V4 since it's buggy here).

 

...

 

Speaking of CAO: Beta4 fixed the drag'n drop bug, so you can now just drag'n drop folders like this one into CAO, and smash downscale.

 

 

[Texmarker]

I have a question: You say AI is performance heavy. Does that mean "Immersive Citizens" is bad for performance? Or does only the number of actors count, not how they are coded?

[Guest]

13 hours ago, Texmarker said:

I have a question: You say AI is performance heavy. Does that mean "Immersive Citizens" is bad for performance? Or does only the number of actors count, not how they are coded?

Technically speaking, modders don't "code AIs" - instead the game has a number of predefined "AI-packages" (such as "loiter around this point", "find a nearby sleep-spot", "go to waypoint X", etc). It's those packages - bethesda's code, not the modders' - that are performance-heavy on their own. Without a package, an AI would just stand frozen on a spot, which isn't very useful, interesting or believable. So as a reasult, every "loaded" actor is a performance-drain, even if just idling around a spot. And mechanics like visibility-checks or physics run for all of them.

 

So what is a "loaded actor"? Someone correct me if i'm wrong, but AFAIK it's simply everyone within your range loaded cells (uGridsToLoad), and for large actors such as giants it's even further.

 

Seperate from this is... you might call it "high-level AI", which is the logic that decides which packages to picks. This level of AI is pure scripting done by modders, and it can be executed even for actors not actively loaded (which obviously is far more people, than just those within load-distance). For example, a script can decide to kill an actor on the other end of Skyrim, if you fail a quest.

 

You'd expect this highlevel scripting to be more performance-heavy - after all, those scripts can be run for any actor in skyrim, anytime - and that's far more people, than just those nearby. And yet it's the other way around: It's those "loaded actors", that are most performance-heavy. Why?

 

Because highlevel scripting is optional, and it can cheat. Modders don't need to simulate every single actor in skyrim all the time. Even for things like travelling merchants, a modder doesn't need to simulate the entire journey (in fact, that's pretty much impossible) - he can just pick a source-town and destination-town, estimate travel time by plain distance, and then if the merchant comes within your load-distance place him where he should be. You can't do the same for loaded actors - those need to be fully simulated, or the player might notice. And that means: Running packages, physics, pathfinding, visibility-checks - the whole shebang.

 

Of course it is absolutely possible, for a modder code the highlevel part badly - or to bombard the engine with status-checks for a follower, to make that follower behave in ways, for which there are no premade packages. But this is rare. Typically, it's the mere existance of loaded actors running AI-packages, that drags down performance.

 

TL/DR: Every actor within your loaded cells - even a stupid chicken - will consume an unreasonable amount of CPU-ressources. And remember if CPU-threads are bottlenecked, your VRAM or GPU won't matter. Of course Skyrim without actors would be boring - in fact, you play the game for those very same actors. But since they're expensive, it's not a good idea to waste ressources on trivial ones (such as with Birds of Skyrim). Basically my recommendation is: Make the most out of extra-actors, because there's only so many you can have nearby, before your game becomes CPU-limited.

 

[phillout]

> And the later add encounters - basically a lightweight 3DNPC.

 

Now I'm wondering if you ever played "Interesting NPCs". Interesting NPCs adds interesting NPCs - with stories and lots of quests, voiced dialog lines, some of them are followers. Now what this mod adds is just encounters.

 

edit: I've tried the affinity tweak and I didn't notice any difference. My cores were loaded equally anyway before tinkering with this setting.

 

> Seperate from this is... you might call it "high-level AI", which is the logic that decides which packages to picks. This level of AI is pure scripting done by modders

 

Err... no. If an actor has a package that sets him on a travel between two cities, and then encounters a wolf, for example, combat AI will be triggered w/o any scripts. Also you can code packages based on conditions (like time of the day) w/o writing a single script.

[Bluegunk]

Interesting discussion and ideas. Thank you. 

I being a general idiot, perhaps you can please advise me. I use an i7 processor. 4 Cores, 8 Logical Processors. So it's hyperthreading.

I don't put any threading commands in the Skyrim SE INIs because apparently they are no longer needed.

 

In my Affinity screen I have a tick boxes for all cores, and then tick boxes for the separate 0-7 'cores'.

 

What would be my best choice with your Affinity strategy? Leave 0 and tick 1-7?

I've tinkered with a few varieties, and all seem to work OK, but I can't see the results are any better or worse than just leaving the game to play.

[blase_hase]

iHwNumThreads is placebo anyways: https://forums.nexusmods.com/index.php?/topic/7269936-optimized-skyrimcustomini/page-42

 

what i'm more interested in is how to reduce draw call count - this is the limiting factor for me currently. i take mesh complexity isn't affecting draw call count but instead the amount of separate objects in the viewing frustum does? so reducing render distance and removal of small objects is the way to go? or would reducing mesh vertex count also benefit draw call counts?

 

also a PSA - get an nvidia gpu for skyrim. the amd driver has insanely bad draw call overhead: a 5700XT is a whopping 44% slower than a 1070 when not gpu-limited: 59 FPS on 5700XT vs 85 FPS on 1070, both at a worst-case 14000 draw calls, drawing some 21kk vertices. when gpu-limited however, the 5700XT is (only) about 15% faster, whereas it is 30-40% faster in recent games and synthetics.

 

tl;dr: amd driver bad, nvidia driver good =P

[Bluegunk]

12 hours ago, blase_hase said:

 

tl;dr: amd driver bad, nvidia driver good =P

I totally agree. I used to use AMD. Never again. Intel CPU and Nvidia have been a far better experience in every sense. 

Just wish I could afford to buy a small nuclear-powered CPU...  ?

[Guest]

On 11/3/2019 at 2:20 PM, Bluegunk said:

Interesting discussion and ideas. Thank you. 

I being a general idiot, perhaps you can please advise me. I use an i7 processor. 4 Cores, 8 Logical Processors. So it's hyperthreading.

I don't put any threading commands in the Skyrim SE INIs because apparently they are no longer needed.

 

In my Affinity screen I have a tick boxes for all cores, and then tick boxes for the separate 0-7 'cores'.

 

What would be my best choice with your Affinity strategy? Leave 0 and tick 1-7?

I've tinkered with a few varieties, and all seem to work OK, but I can't see the results are any better or worse than just leaving the game to play.

Sorry for the late reply: Took a bit of a pause from skyrim.  The first thing to do is: Find out what's actually going on, instead of relying on gut-feeling and ingame-FPS (which is just a symptom). There's a whole range of freeware-apps out there to plot graphs for your cores and gpu. The most popular one is Afterburner, which isn't just an overclocking-tool, but also great for looking at statistics (in fact, i personally use it mainly for stats). It let's you plot graphs like this:

 

(Top row is for GPU-stats, bottom row is core-utilization)

 

After all: Based on what people reported in this and other threads, the "1.4 core syndrome" doesn't seem to happen on win10, so maybe it's just win7 or win8 related, or maybe it's specific to Ryzen, or only happens with hyperthreading disabled. I don't know. Like i said: SSE multithreading is black magic. The only way to know is: Find out what's actually happens on your system. And the way to do that is: Take measurements.

 

If core usage is the problem: Open your taskman and go to the skyrim-process. Now there's two different ways of counting: Programmers like to count from zero, but sane people count from one. Bollocks, so how do you know which one's true for a given app? Easy: You know how many cores you have. If a program says 0-7, it counts from zero so core-0 is the 1st. If instead it says 1-8, then core-1 is the 1st core. WTF is this bullshit? Well, i could post a philosophical article here, on why programmers (counting 0-7) are doing it wrong, but that's not what you're here for: You just want to get stuff working. So: For the SSE process disable affinity for all cores except the lowest one. Wait a few secs, then set affinity for SSE to all cores. Or if you prefer stability over peak performance: Give SSE all cores except for the last. This way windows can assign background apps (like a browser or audioplayer) to the last core, so those background tasks don't disrupt skyrim-performance.

 

EDIT: As for temps: AMD-CPU's tended to run hot, until Ryzen came along, which actually runs cooler than intel. For GPUs instead: Basically forget AMD, unless you want to bake cookies in your PC.

 

[Guest]

On 11/4/2019 at 11:49 PM, blase_hase said:

what i'm more interested in is how to reduce draw call count - this is the limiting factor for me currently. i take mesh complexity isn't affecting draw call count but instead the amount of separate objects in the viewing frustum does? so reducing render distance and removal of small objects is the way to go? or would reducing mesh vertex count also benefit draw call counts?

Correct. The problem is: Skyrim wastes the majority of drawcalls on stuff you can't see, and there's no real way to fix that, since automatic occlusion-culling is broken, and manual occlusion-planes missing. So the only thing you can do is: Draw less stuff. But you don't want to cut corners on stuff like bodies, and you can't really draw less landscape and architecture (all you could do is, not install stuff that raises landscape polycounts). So the obvious place to save drawcalls is items and objects, especially since those can't be seen far.  And the way to do that is: Fadeout-distances and not installing mods that raise clutter polycounts.

 

 

On 11/4/2019 at 11:49 PM, blase_hase said:

 

also a PSA - get an nvidia gpu for skyrim. the amd driver has insanely bad draw call overhead: a 5700XT is a whopping 44% slower than a 1070 when not gpu-limited: 59 FPS on 5700XT vs 85 FPS on 1070, both at a worst-case 14000 draw calls, drawing some 21kk vertices. when gpu-limited however, the 5700XT is (only) about 15% faster, whereas it is 30-40% faster in recent games and synthetics.

 

tl;dr: amd driver bad, nvidia driver good =P

AMD-CPUs and GPUs are practically entirely different brands at this point. Their CPUs get all the funding and attention, since that's what is AMD's bread and butter. I'd buy a Ryzen anytime now over an intel. Meanwhile, AMD-GPUs are still just ATI-rebranded: A pathetic performance-per-watt proposal, and bloatware-drivers that are the shittiest of all shit. Yes, NVidia drivers aren't what they used to be, in terms of efficiency and cleanliness, but at least they still work and perform.

 

Man, i miss 3DFX/Herculess and Matrox. That stuff was efficiency and innovation, but NVidia killed 'em with plain raw minituarization and resistorcounts.

 

 

 

[Kristus Kringle]

15 hours ago, lynak said:

Man, i miss 3DFX/Herculess and Matrox. That stuff was efficiency and innovation, but NVidia killed 'em with plain raw minituarization and resistorcounts.

 

I bought a Voodoo 3 2000 when they came out and for a few months had the fastest video card made, until the Voodoo 3000 came out, lol. Gaming mags beat up 3dfx mercilessly because it was only 16 bit, destroying its sales and market share; nevermind that Nividia's 32 bit card couldn't play any game over about 15 fps in 32bit, everybody was about the bits, not fps. Nvidia won that battle through marketing. Matrox was built on uncompromising video quality but Nvidia closed that gap and Matrox became irrelevant. But lesson learned, never bet against Nvidia. 

[Guest]

On 12/8/2019 at 11:05 PM, Duncan Idaho said:

 

I bought a Voodoo 3 2000 when they came out and for a few months had the fastest video card made, until the Voodoo 3000 came out, lol. Gaming mags beat up 3dfx mercilessly because it was only 16 bit, destroying its sales and market share; nevermind that Nividia's 32 bit card couldn't play any game over about 15 fps in 32bit, everybody was about the bits, not fps. Nvidia won that battle through marketing. Matrox was built on uncompromising video quality but Nvidia closed that gap and Matrox became irrelevant. But lesson learned, never bet against Nvidia. 

Oh right, now i remember. Yeah, at first NVidia wasn't really competitive, so they marketed themselves as better quality than 3DFX, because 32bit. Also, they shilled Direct3D without abaddon, which meant microsoft-backing - as opposed to 3DFX, which had inferior performance on Direct3D, but blew all D3D-cards (incl NVidia) outta the water in GLide-mode. And by "blew outta the water", i mean "nuking D3D from orbit", as in GLide having almost twice the framerate.

 

But GLide was a proprietary single-vendor API, while D3D was an industry-standard backed by microsoft, so ever more games came out for D3D. And once NVidia got the capital, they just kept raising resistorcounts: Efficiency-wise their chips were inferior to 3DFX, but NVidia just kept raising clockrates and adding more render-cores, until 3DFX could no longer keep up and went under. Their engineers went to Hercules, who put out a card stockfull of innovative features, like.... guess what? Automatic occlusion-culling! But the media kept saying: "That herculess card is actually slower than NVidia. It's just cheating scores with this occlusion-culling magic." Yeah right: Not rendering stuff you can't see is "cheating", and NVidia rendering stuff just like Skyrim does today, is "the right way."

 

Turns out the gaming press was already rotten to the core, back when they still reported on gaming, as opposed to politics.

 

[phillout]

On 12/9/2019 at 1:05 AM, Duncan Idaho said:

 

Nvidia won that battle through marketing. Matrox was built on uncompromising video quality but Nvidia closed that gap and Matrox became irrelevant. But lesson learned, never bet against Nvidia. 

 

It wasn't just marketing. A dedicated game-only device that worked only in full-screen mode was an evolutionary dead-end. These days GPUs participate in everything, from video games and hardware accelerated MP4 playback to drawing canvases in web browsers, OS graphics compositing and cryptocurrency mining. I never owned Voodoo card for this very reason - I wanted windowed h/w accelerated 3D, that's why I bought a Rendition card back then. But then NVidia started moving ahead way too fast for many others to catch up (S3, anyone?).

[Santr]

Thanks for the guide, helped me quite a bit.

 

Two things to note, though:

- Instead of "Notice Board" as a quest mod, I'd recommend "Missives" - it's the same concept but much improved.

- On a weak CPU, object distance and object detail are a serious drain. Reducing both with BethINI from max to min shot my FPS from 30 to 50. Even keeping the object distance at max and only setting object detail to min raised the FPS to 42 without changing much visually.

[Guest]

On 12/17/2019 at 8:30 AM, Santr said:

Thanks for the guide, helped me quite a bit.

 

Two things to note, though:

- Instead of "Notice Board" as a quest mod, I'd recommend "Missives" - it's the same concept but much improved.

- On a weak CPU, object distance and object detail are a serious drain. Reducing both with BethINI from max to min shot my FPS from 30 to 50. Even keeping the object distance at max and only setting object detail to min raised the FPS to 42 without changing much visually.

Thanks a lot for telling me about "Missives". I didn't know this exists, and have updated the OP recommending it instead of "Noticeboard".