A compendium of tweaks and fixes for the PC version

+
Status
Not open for further replies.
[Rendering]
FakeMeshesNotReady=false <- Prevents to use of stupidly low quality meshes. Might have an fps hit in lower end systems.
For me FakeMeshesNotReady=false is exactly what the LOD system already does. I still get this:






If I set it to FakeMeshesNotReady=true, then **everything** becomes the super low quality version. This tells me the engine is already defaulting to false, because setting it to true completely breaks the game.

Above 1.0 the foliage doesn't go any further, it simply adds shadows.. which you'd think "FoliageShadowDistanceScale" is responsible for
It doesn't just add shadows. There are other shaders like the backlighting/vegetation shader. The trees definitely get higher poly too, but only slightly. Basically there are super "billboardy" trees and then slightly less "billboardy" trees. The really flat ones probably don't cast shadows because it wouldn't look good.

You can see here with the huge tree in the distance:

1.8 vs 2.4
https://i.imgur.com/RY6HBJe.jpg vs https://i.imgur.com/2GfTMrT.jpg

There is definitely more geometry there, because the tiny holes in the foliage go missing.
 
someone knows the difference between "MaxTextureAnisotropy=" and "MaxTextureAnizotropy=" below [Rendering] in user.ini?

Basically it's a spelling typo, that they forgot to clean / remove.

When they first "introduced" Anisotropic Filtering in a patch (I say introduced, but really it was just hidden, because it worked before that patch). They were writing TO the file as MaxTextureAnizotropy, but trying to read FROM the file as MaxTextureAnisotropy.

I made a thread pointing it out. It was corrected, but they apparently forgot about the old value.

tldr MaxTextureAnizotropy is old, and does nothing so far as I'm aware. MaxTextureAnisotropy is the corrected one, and that's the one that's read for the max aniso value.

#Edit: do yourself a favour and use the driver AF, instead. It's much higher quality.

- i play on pc - do i still add it ?

Well, of course it's for PC. You don't have access to these files on console. Whether or not, you add it, well that's totally up to you.

It has a bad impact if I set that to False, right?

Well, not sure if I'm understanding the question completely. Bad, as in making stuff worse?, or bad, as in lower fps?.

Basically disabling (setting to false) it should disallow the use of super low quality meshes.

False = higher quality
True = lower quality.

----
#edit @jonwd7 I'll have to double check. I don't think it's that simple. I think when it's set to true, it also force disables other mesh aspects..They've made a lot of variables codependent on eachother. i.e. changing one thing, linked in some way to another var also affects those linked.

It will also, of course depend on your settings.

The effects of some of these tweaks are annoying to accurately test, because of lack of consistency between areas

Especially distance/lod-related values. Their effects vary greatly depending on location.
 
Last edited:
For me FakeMeshesNotReady=false is exactly what the LOD system already does. I still get this:






If I set it to FakeMeshesNotReady=true, then **everything** becomes the super low quality version. This tells me the engine is already defaulting to false, because setting it to true completely breaks the game.


It doesn't just add shadows. There are other shaders like the backlighting/vegetation shader. The trees definitely get higher poly too, but only slightly. Basically there are super "billboardy" trees and then slightly less "billboardy" trees. The really flat ones probably don't cast shadows because it wouldn't look good.

You can see here with the huge tree in the distance:

1.8 vs 2.4
https://i.imgur.com/RY6HBJe.jpg vs https://i.imgur.com/2GfTMrT.jpg

There is definitely more geometry there, because the tiny holes in the foliage go missing.

I'd also like to point out that it affects how much animation detail you can see. I was able to test this in White Orchard, find a branchy tree in a very windy place. Walk away from it slowly and you can see the animation go from very windy branches to not moving so much when further away. Now increase the foilagedistance and you'll be able to see the complex animations further away. I think it's one of the main reasons why this setting has such a performance hit.
 
I'd also like to point out that it affects how much animation detail you can see. I was able to test this in White Orchard, find a branchy tree in a very windy place. Walk away from it slowly and you can see the animation go from very windy branches to not moving so much when further away. Now increase the foilagedistance and you'll be able to see the complex animations further away. I think it's one of the main reasons why this setting has such a performance hit.
Yes, you're right. I forgot about that. If you look in the bin/shaders/speedtree folder you can see that there are things like:

Billboard_vs.fx11obj
Branches_vs.fx11obj
facing_leaves_vs.fx11obj

and so forth.

These are the vertex shaders which cause the tree animation. You can see there is a vertex shader specifically for branches, so the more distant trees must lack these. The furthest trees must switch to Billboard_vs. Unless there are even more distant trees that have no animation at all (I forget).


@jonwd7 I'll have to double check. I don't think it's that simple. I think when it's set to true, it also force disables other mesh aspects..They've made a lot of variables codependent on eachother. i.e. changing one thing, linked in some way to another var also affects those linked.

It really is that simple. Setting it to true breaks the game. True/false is binary, so the default must be false. Example:

 
@jonwd7 Yes, I'm quite aware that a bool is binary.. I've also never said that false wasn't the default value. Speaking of which - some of the cvar members are dynamic, and changed on the fly. Others have no hard coded values at all by default, and are left to the engine to handle. They just end with = and blank.

What I did say was, changing it to true, also force-changes other vars related to mesh lod. It's probably the reason it's hidden to begin with.

I've posted dozens of hidden cvar tweaks. Obviously first and foremost - to share them, but also because I'd like help testing them.

But, there's a difference between helping me test them, and simply being condescending..
 
Last edited:
But, there's a difference between helping me test them, and simply being condescending..
I'm aware that you know what you're doing. But it's unfair to tell others that something is improving the game when it probably isn't. So I'm sorry if it feels like I'm calling you out or being condescending, but I'm simply stating the obvious (to us) out loud for everyone else to hear. Because I would prefer that someone actually try to do the work of disproving me than just blindly put the setting in their INI because you said so.

You said:

Prevents to use of stupidly low quality meshes. Might have an fps hit in lower end systems.
And this is extremely misleading. If you were just positing this idea and hadn't tested it, then at least make that clear. If you did test it and did find a difference, you could at least have been more specific.

TL;DR - It's called being skeptical, not condescending.
 
I'm aware that you know what you're doing. But it's unfair to tell others that something is improving the game when it probably isn't. So I'm sorry if it feels like I'm calling you out or being condescending, but I'm simply stating the obvious (to us) out loud for everyone else to hear. Because I would prefer that someone actually try to do the work of disproving me than just blindly put the setting in their INI because you said so.

You said:

And this is extremely misleading. If you were just positing this idea and hadn't tested it, then at least make that clear. If you did test it and did find a difference, you could at least have been more specific.

TL;DR - It's called being skeptical, not condescending.

while i agree with you , you're reading a bit too much into it
 
It doesn't just add shadows. There are other shaders like the backlighting/vegetation shader. The trees definitely get higher poly too, but only slightly. Basically there are super "billboardy" trees and then slightly less "billboardy" trees. The really flat ones probably don't cast shadows because it wouldn't look good.

You can see here with the huge tree in the distance:

1.8 vs 2.4
https://i.imgur.com/RY6HBJe.jpg vs https://i.imgur.com/2GfTMrT.jpg

There is definitely more geometry there, because the tiny holes in the foliage go missing.

Indeed, it's something I noticed earlier but forgot about cause it's kinda hidden by the extra shadows you get from shadowdistancescaling

And it's not worth using, really, the performance impact is huge for that setting comparatively with shadows, grass, etc.

Basically it's a spelling typo, that they forgot to clean / remove.

When they first "introduced" Anisotropic Filtering in a patch (I say introduced, but really it was just hidden, because it worked before that patch). They were writing TO the file as MaxTextureAnizotropy, but trying to read FROM the file as MaxTextureAnisotropy.

I made a thread pointing it out. It was corrected, but they apparently forgot about the old value.

tldr MaxTextureAnizotropy is old, and does nothing so far as I'm aware. MaxTextureAnisotropy is the corrected one, and that's the one that's read for the max aniso value.

#Edit: do yourself a favour and use the driver AF, instead. It's much higher quality.

What is the correct way to force AF anyway, what should I set my rendering.xml AF to? 0/1? Leave it at 16?
 
@Asmodean778 Also, it seemed to me you were saying you were noticing that this setting (FakeMeshesNotReady) was new in 1.05, no? Well, it's in your post from 5/27 and it was one of the things I had already queued up to test.

So were you saying that something has changed to indicate that it's now being read by the executable in 1.05, or did you just not notice you'd already dumped it?

--

Also, regarding all the cv* settings that used to be in the INI, it's my understanding they could never have been read to begin with because they incorrectly left the cv* prepended onto them. I'm talking about:

cvMaxAllowedLightsShadowTime=1cvMaxAllowedApexDestroTickedTime=0.2
cvMaxAllowedGrass=30000
cvMaxAllowedDecalsDynamic=10
cvMaxAllowedDynMeshes=104857600
cvMaxAllowedChunksSkinnedTime=2.5
cvMaxAllowedTrianglesSkinned=100000
cvMaxAllowedDecalsSSTime=0.1
cvMaxAllowedLightsShadow=3
cvMaxAllowedApexTicked=60
cvMaxAllowedActiveEnvProbesTime=0.1
cvMaxAllowedStatTextures=314572800
cvMaxAllowedSpeedTree=5000
cvMaxAllowedLightsNonShadowsTime=0.2
cvMaxAllowedSpeedTreeTime=2.2
cvMaxAllowedChunksStatic=1500
cvMaxAllowedTrianglesStatic=500000
cvMaxAllowedHiresChunks=25
cvMaxAllowedDecalsDynamicTime=0.5
cvMaxAllowedLightsNonShadows=40
cvMaxAllowedChunksStaticTime=1.5
cvMaxAllowedChunksSkinned=400
cvMaxAllowedApexDestroTicked=20
cvMaxAllowedStatMeshes=209715200
cvMaxAllowedHiresChunksTime=0.2
cvMaxAllowedApexTickedTime=0.5
cvMaxAllowedCharTextures=209715200
cvMaxAllowedParticlesCountTime=0.2
cvMaxAllowedParticlesCount=1000
cvMaxAllowedGrassTime=1.5

cvMaxAllowedDecalsSS=160

I had already tried testing them in 1.04 without the "cv" and didn't notice any changes. Of course, after 1.05 came out, it wiped the cv* values out of the INI because they never worked to begin with, but I'm wondering if you noticed any changes which may indicate that they are finally being read (without the 'cv' part)? Because I also tested them without the 'cv' part in 1.05 and still didn't notice any changes. My guess is that these options were just never fully implemented because they ran out of time for the day-one patch deadline. (The day-one patch is supposedly what introduced all the INI options according to some developer interview I read.)

If there is some indication that things you previously dumped like FakeMeshesNotReady are still being messed with in new patches, I guess I'll remain hopeful that they'll make improvements to INI configuration in the future.

Of course, I'm guessing that all those Budget options are modifiable in memory and it's just the INI->engine connection that was never completed, so I'm hopeful an industrious hacker will come along and get all these options working. :)
 
Not added, but 'active'. I can only spend so much time testing each var at a time, when I found them. I would like to actually play the game as well ofc ;p When I initially found FakeMeshesNotReady, it appeared to do nothing. When I tested it in the current patch. It was clearly being read.

edit: I also mentioned when I posted that batch of cvars, I had not tested all of them.

Regarding the prefix cv values. Yeah, that batch was probably, either not intended to be added to the file yet, to begin with. Or have that cv identifier in front of it, when it was added to it.

I had speculated that they were being written to the file, but not being read from the file at all. So changing them did nothing.

They are definitely in there with the cv values - there are no occurrences of them without the cv prefix in the binary file. They are still present btw, even in the 1.05 binary.

I'd imagine the most simple way to test, would be to find the most apparent looking ones(eg: cvMaxAllowedGrass, or MaxAllowedGrass), and set them to 0. If there's still grass, then I presume it's currently not being read by the GetConfig scripts.
 
Last edited:
When finally evry graphics hax are found i will achieve this ò.Ó
atm it looks vanilla like this... Q___Q
I think the vanilla picture looks much closer to an actual photograph. It looks much closer to the real world. And I very much prefer the look of the vanilla picture. That first picture looks severely oversharpened. Just looking at this picture is not very easy, it actually makes my head hurt a bit. Now imagine if this actually moves, the amount of shimmering and aliasing would be extraordinarily high. It would really make my head almost explode. Also, it looks severely desaturized. It doesn't look like the real world at all. It's almost as if there is some sepia filter or something like that going on.
 
I think the vanilla picture looks much closer to an actual photograph. It looks much closer to the real world. And I very much prefer the look of the vanilla picture. That first picture looks severely oversharpened. Just looking at this picture is not very easy, it actually makes my head hurt a bit. Now imagine if this actually moves, the amount of shimmering and aliasing would be extraordinarily high. It would really make my head almost explode. Also, it looks severely desaturized. It doesn't look like the real world at all. It's almost as if there is some sepia filter or something like that going on.
In the actual trailer there wasn't noticeable sharpening but the things you should take away from that comparison is the detail and not the cinematic filtering that's going on. Everything was bigger and better and then you can move onto other things that were reduced in parts of Novigrad. There are lots of comparison images out there.
 
please stop, it hurts knowing we'll never get that graphics :(:(:(

---------- Updated at 11:41 PM ----------

I think the vanilla picture looks much closer to an actual photograph. It looks much closer to the real world. And I very much prefer the look of the vanilla picture. That first picture looks severely oversharpened. Just looking at this picture is not very easy, it actually makes my head hurt a bit. Now imagine if this actually moves, the amount of shimmering and aliasing would be extraordinarily high. It would really make my head almost explode. Also, it looks severely desaturized. It doesn't look like the real world at all. It's almost as if there is some sepia filter or something like that going on.
nah, it looks to caartonish vanilla..the upper picture is like a film, much much better
 
I personally don't like either of those screenshots. I'll take the e3 2014 incarnation of the renderer any day. It was beautiful then, imo.

Go rewatch the uncompressed 35 min gameplay demo and cry inside lol.

On a small secondary note: I found out how to make the UI scale (smaller / or larger) than the defaults allow. Also to adjust the uiOpacity. It's in the hud_settings.csv, though, and you need to use quick bms to repack it.

Made the UI tiny as a test, see below;

witcher3 2015-06-08 00-33-20-06
 
Last edited:
Go rewatch the uncompressed 35 min gameplay demo and cry inside lol.
It really hurts :(

I hope it is possible one day to auto hide the compass. It makes no sense that they didn't keep that feature from the last game, didn't they finally patch it in after it was requested for like a year?

I made a bind to hide the hud but it doesn't work if I have free camera active.
 
Status
Not open for further replies.
Top Bottom