Some of NVIDIA's work filtering back into it probably helped. If it's open source it doesn't really make sense not to incorporate improvements for other hardware, not doing so will just piss off the developers who will proceed to do it themselves.
The Witcher 3: Wild Hunt revealed
- Thread starter Dresden
- Start date
-
- Tags
- tig:thewitcher3
Some of NVIDIA's work filtering back into it probably helped. If it's open source it doesn't really make sense not to incorporate improvements for other hardware, not doing so will just piss off the developers who will proceed to do it themselves.
Yep. That's approximately it (better get the the frame-time graph, though, it's the default one).
As we can see the real performance is much closer to "barely 49 fps", with a lot of stuttering (SLI? ok, noticed, SLI indeed).
Last edited:
On AMD cards it's possible to limit tessellation through the control panel to gain a decent boost with Hairworks
http://i.imgur.com/2wyxv90.jpg.
8x seems like a good compromise. This hack affects also water tessellation giving a small boost at high/ultra quality level.
Not related to tessellation, it seems that, on the nVidia front, the 7xx cards perform much worse in Witcher 3 than their 9xx counterparts with a 780 loosing also to a R280/285/290 in certain scenarios.
http://media.gamersnexus.net/images/media/2015/game-bench/witcher-bench-1080-u.jpg
Some people are suspecting that this is done on purpose to force people to upgrade. For sure, the 7xx series performance compared to other cards, both of nVidia and AMD, is quite different from what we've seen so far in most games
http://i.imgur.com/2wyxv90.jpg.
8x seems like a good compromise. This hack affects also water tessellation giving a small boost at high/ultra quality level.
Not related to tessellation, it seems that, on the nVidia front, the 7xx cards perform much worse in Witcher 3 than their 9xx counterparts with a 780 loosing also to a R280/285/290 in certain scenarios.
http://media.gamersnexus.net/images/media/2015/game-bench/witcher-bench-1080-u.jpg
Some people are suspecting that this is done on purpose to force people to upgrade. For sure, the 7xx series performance compared to other cards, both of nVidia and AMD, is quite different from what we've seen so far in most games
Can you elaborate?
If I read this correctly, the 49 frames are for 1% of the bench.
Isn't the average more important?
D
Deleted member 13524
Guest
I wish someone did a proper benchmark on this.
I've seen reports claiming that tesselation in Witcher 3's Hairworks goes all the way up to 64x, so even the 16x limit could bring a substantial performance boost to GCN cards.
Also, here's the .ini edit for HairWorks MSAA that's been giving huge performance boosts:
My guess is that combining these two hacks, getting a solid VSynced 30FPS with Hairworks in a 290X might be possible. to achieve.
Also, AMD is in dire need of releasing a Witcher 3 driver..
D
Deleted member 13524
Guest
Lots of comparative screenshots with FRAPS numbers from user "B!0HaZard" in this thread:
http://www.overclock.net/t/1556474/...orks-now-works-on-amd-cards-smoothly-cc-tweak
With an overclocked HD7950 in a certain scene, he gets ~23 FPS with vanilla Hairworks, 29 FPS with Hairworks and tesselation limited to x64, and 37 FPS with Hairworks off.
So by default, Hairworks is using more than x64 tesselation for hair strands.
Moreover, the visual difference between the default values and x64 seems to be minimal, with the performance boost hovering some 20-30% in a Tahiti.
In Tonga and Hawaii cards the difference could be smaller, as they have better geometry throughput.
Regardless, combining these with the MSAA .ini hack could bring huge improvements.
http://www.overclock.net/t/1556474/...orks-now-works-on-amd-cards-smoothly-cc-tweak
With an overclocked HD7950 in a certain scene, he gets ~23 FPS with vanilla Hairworks, 29 FPS with Hairworks and tesselation limited to x64, and 37 FPS with Hairworks off.
So by default, Hairworks is using more than x64 tesselation for hair strands.
Moreover, the visual difference between the default values and x64 seems to be minimal, with the performance boost hovering some 20-30% in a Tahiti.
In Tonga and Hawaii cards the difference could be smaller, as they have better geometry throughput.
Regardless, combining these with the MSAA .ini hack could bring huge improvements.
With vsync on and considering around 99% of the frames are being delivered in under 16.16ms I'd say this classifies as a clear 60fps with some minor dips. How obvious the stuttering is from those frames that are delivered in more than 16ms is open to question but I'm guessing they are barely noticeable.
In fact I'd love to sit down with the guys from DF one day and understanding exactly what they consider to be bad stuttering. I certainly have my own definition of it and know it's a real thing but I sometimes suspect that they will classify anything as stuttering if it doesn't deliver perfect frame pacing even if the end result is completely smooth.
If I hadn't seen the graph, I wouldn't have known there was any stuttering.
Need to say, the framerates smoothness things have gone a bit out of proportions on some sites,.sometimes i ask me if they really sit and play, or instead just look at the graphs. Let alone that Fraps is a bit useless, you need to read the output of the frames.
Last edited:
Agreed, also no stuttering on my sli setup and very smooth. I think if your average fps was in the 20 - 30 range it might become alittle more noticeable, begging for game quality settings to be relaxed.
if any of you only get stereo sound out of W3. Currently the only fix is by modifying directx audio libs.
No, it does not. Author can enable vsync and see how it looks. (spoiler: it looks even uglier, I tried).
That's a correct definition.
You can start almost any PS2 game and see what "perfect 60fps" looks like. I assure you you will look at everything people call "stable 60" today as a kind of joke.
It's not about how the graph looks, it's about how the game plays. FRAPS always shows frame times that are all over the place regardless of how smooth the game actually plays. This is Ori on my PC with vsync on. With vsync off it will consistently break 100fps so there are no performance issues here:
The graph is a mess but the game is buttery smooth (apart from the 30fps animations), every bit the match for 60fps games I've played on the likes of the PS2 and N64. The big spike btw is when I loaded the map screen which gave a small judder.
People describe many different things as a "stable 60fps". Tombraider DE on the PS4 has been described as 60fps despite it averaging in the 50's. What I would describe as a "stable 60 fps" though feels just the same as a 60fps game on the older consoles, regardless of what the frame time graph may look like. At least to me.
Yes, there are zones. It's like you get 4 large, open world games in one.
Realistically it wouldn't be possible to combine them into one super big map as it would have to be more than 200sq/km. Skyrim Solstheim add-on was the same. I'm quite happy with how it currently is as too much of something can be overwhelming!
Now back at home, I need to test Hairworks with tweaks from this thread!
Tested and got some pics:
http://i.imgur.com/GtfTzbK.jpg - No HW
http://i.imgur.com/AMHFLlF.jpg - HWFull Tess x6 AA x2
http://i.imgur.com/EFQoQGa.jpg - HWFull Tess x16 AA x2
http://i.imgur.com/e32GRPb.jpg - HWGeraltOnly Tess x16 AA x2
http://i.imgur.com/50j853J.jpg - HWFull Tess Default AA x2
http://i.imgur.com/COs5Ry6.jpg - HWFull Tess Default AA x8
Win7 x64 and R9 290X 1050/1325 Cat. 15.3beta
As you can see reducing tesselation factor have massive effect on performance of HairWorks but a bit surprisingly reducing AA levels for HW has almost no effect! This might be thanks to Hawaii massive memory bandwidth or the setting not kicking in ( but I think there is more aliasing when AA is lowered).
I'm now playing on AMD card with full HairWorks setting and locked 30FPS
Last edited:
If you're streaming in the data there is no reason it shouldn't be possible ... you might get stuff like aliasing ID's with 32 bit integers, but you can divide ranges of them according to location so you would never have two areas with aliases loaded at the same time.
It's either content gating, or some artifact of the development process (ie. they started running out of some per map resource they should have made per region and decided to just hack it like this).
It's either content gating, or some artifact of the development process (ie. they started running out of some per map resource they should have made per region and decided to just hack it like this).
People can believe in a variety of things, until there is a measurable repeatable experiment in place...
Never assume. Fat APIs like DX11 have a multitude of ways to make you look bad when saying "no performance issues", engineer who wrote code for the checkbox that says "vsync on" could do things differently than you expect.
To me it seems main problem was creating content for areas in-between locations described in books, not technical limitation. You would have to create a lot more land and sea to connect these locations in 'organic' way.
I suspect we will know for sure once map editor is released by CDPR.
Similar threads
