MAX PAYMENT
Member
I'm glad I can just enjoy the game and that things like this are an upgrade to me.
This seems like you're ruining your own fun.
-
Hey, guest user. Hope you're enjoying NeoGAF! Have you considered registering for an account? Come join us and add your take to the daily discourse.
[4K] The Witcher 3: PS4 Pro Analysis, PC Comparisons + Frame-Rate Tests!
- Thread starter adamsapple
- Start date
I'm glad I can just enjoy the game and that things like this are an upgrade to me.
This seems like you're ruining your own fun.
Yup, I'm glad I don't know much about the nitty gritty of it - all I know is that it looks good, how and why is beyond me.
HBAO isn't bandwidth-intensive, and he asked if the effect is "expensive as hell", which is not a label I would apply to a ~5% performance hit. Additionally, it does not have a particularly adverse impact performance on AMD cards (take Gamers Nexus' BF1 comparison article, for instance).
HBAO isn't the same thing as HBAO+, right?
Right, but apparently the improved AO is HBAO, and, to state the obvious, that HBAO+ is more accurate and has a slightly higher cost versus SSAO that still lands within the ballpark of negligible only supports the more general point that HBAO/+ is not a Hairworksesque destroyer of performance. Hell, Fallout 4 is an Nvidia-sponsored game and yet its HBAO+ implementation actually favours the Fury X over the 980 Ti.
TLW doesn't know either.
Brad Grenz
Member
Yes, they have exhibited a consistent, shallow understanding of CBR and frequently misrepresent it as a scaling technique.
Sawtooth artifacts are the product of motion errors. They only are more easily found on vertical edges because lateral camera motion is so much more common.
Nah. HBAO+ is actually among if not the cheapest Gameworks effect:
I find these kinds of graphs highly misleading. You can't really judge performance cost of an effect by impact framerate - as framerate isn't a linear scale.
If you use these numbers to calculate the time difference (assuiming 66fps for no AO and 58 for HBAO) then you end up with:
HBAO cost in milliseconds is:
(1000 / 58) - (1000 / 66)
Which comes out at 2.1ms. As a percentage of the frame cost, that's ~ 13% of a 60fps frame (16.6ms). This is *hugely* expensive for an AO effect.
FWIW most 30fps games will probably spend ~1ms on their AO, or around 3% of their frame time.
I borrowed Nvidia's framerate graph as the person I responded to asked about impact on performance. Yes, HBAO/+ may be not viable for all framerate budgets, but that wasn't the argument I was making and the reason the aforementioned question came up at all is that Digital Foundry believes the improved AO in Pro version of the game to be HBAO.
Finally got to try this out today. Picture looks very, very clean! The higher resolution doesn't do the foliage any favors but it doesn't look nearly as bad as some have described.
I understand why the sawtooth artifacts appear. It's the framebuffer setup I'm not certain of and would like to read up on. I know for temporal injection, half the pixels are processed at a time.
I also don't think you give DF enough credit here. I'm sure they've talked to far more devs than the vast majority here. So I would think they have a good understanding of the techniques used.
I understand why the sawtooth artifacts appear. It's the framebuffer setup I'm not certain of and would like to read up on. I know for temporal injection, half the pixels are processed at a time.
I also don't think you give DF enough credit here. I'm sure they've talked to far more devs than the vast majority here. So I would think they have a good understanding of the techniques used.
Yes it's strange to read the Mark Cerny direct quotes vs what DF got out of the quotes
like them saying it was a 1920x2160 buffer even though Cerny clearly says that the 4 million color samples is not arranged in a rectangular grid.
Also something that seems to be ignored when it come to the ID Buffer is that it's being used to complete the coloring of the frame even without using the previous frame so the resolution would be 3840 x 2160 from the start.
http://www.eurogamer.net/articles/d...tation-4-pro-how-sony-made-a-4k-games-machine
I always thought the biggest drawback of the console versions (after performance) was the draw distance, I think that's what makes the environments look quite rough and less.. cohesive.., so it's a shame although not really that surprising given the CPU requirements that it hasn't really been improved here.
The performance regressions are also a shame.
The performance regressions are also a shame.
It's late at night & this online sketch pad didn't work as planned lol but this is as simple as I can make things
say that it was only 4 pixels instead of 8294400 & there was a shader engine for each pixel , all 4 shader engines would be sampling the depth buffer while only SE1 & SE4 would be sampling the color buffer in frame 1 then it will alternate to SE2 & SE3 that will sample color in frame 2 but there is also the ID buffer that has information that can be used to track the exact location of objects & triangles that can be used to re-sample the depth & color buffer from the frame before ( it also has data that can be used to come up with color for the pixels even before re-sampling the previous frame).
at no time will the game only be 2 pixels
I don't need things simple, I just need them accurate. I understand how the color samples are stored.
Also if you're implying I think that only 2 pixels would be displayed on screen at a time, I never said nor insinuated that.
It's highly unlikely that they could have used max settings at 1440p. They could have done it at 1080p, but not 1440p. The system doesn't have the memory or bandwidth to run the game at max settings at 1440p. You're expectations were unrealistic, what they did here is impressive.
Yes it's strange to read the Mark Cerny direct quotes vs what DF got out of the quotes
like them saying it was a 1920x2160 buffer even though Cerny clearly says that the 4 million color samples is not arranged in a rectangular grid.
Also something that seems to be ignored when it come to the ID Buffer is that it's being used to complete the coloring of the frame even without using the previous frame so the resolution would be 3840 x 2160 from the start.
http://www.eurogamer.net/articles/d...tation-4-pro-how-sony-made-a-4k-games-machine
Nothing in that quote contradicts what DF has said, at least from what I recall. If it does, why not point out exactly what they got wrong?
You claimed to understand then turned around & showed that you really don't understand SMH. There is no reason for me to even talk to you because you have a real problem.
So you can't point out what they got wrong? What is it about Cerny's comment that proves they can't get a 1920x2160 count from the frame buffer before all the pixels are resolved into a 4K scene? I understand some things while still trying to learn others. You however act like you know everything but the moment you're pressed for details, you ignore posts or exit the conversation. I'm not the one with a problem here buddy.
I sold off my PS4 Pro a month ago and switched back to straight PC gaming mostly due to Witcher 3 patch taking forever. I picked up a SSD and replaced my 980 Ti with a 1080 Ti. Sailed directly to 4k greatness and couldn't be happier. I still use a controller to play the game though, heh.
Equanimity
Member
Understood.
Dictator93
Member
We honestly have no idea though if TW3 uses full resolution "helpers" : ID Buffer, Geometry Buffer, etc.
Horizon Zero Dawn does not at all, for example.
Yeah definitely, I just wanted to point out for the specific way it is done here producing those horizontal saw tooths. Like you mention, other reconstruction techniques, the many you mention, will have different error patterns or just look different in general. ^_^
I made an image btw of the image reconstruction available on PC for Call of Duty WWII, and that image reconstruction and the remedies against the error... produces vertical direction sawtooth pattern when at 1920X2160. While TW3 as we can see here has horizontal ones. Kinda neat.
Flying Toaster
Member
I am playing through the game on PC right now as well with a 1080ti. What they did with the pro patch is night and day different then what we got in 2015. I am glad it came out because this game deserves it.
Happy playing everyone.
It's the fact that they say " Technically rendering out 1920x2160 being checker boarded to a full 4K frame buffer" making it seem like the game is rendered at 1920x2160 then upscaled using checkerboard rendering when in fact parts of the rendering process is already 3840 x 2160 while parts of it is being done at a 1:2 rate rendering 2 pixels using 1 sample.
.
Dictator93
Member
We do not know this though. For example, Horizon Zero Dawn only renders out the HUD at 3840X2160, it does not use full resolution buffers on purpose. Everything else is internally 1920X2160 in Horizon Dawn and then checkerboarded up to 3840X2160.
Brad Grenz
Member
We do not know this though. For example, Horizon Zero Dawn only renders out the HUD at 3840X2160, it does not use full resolution buffers on purpose. Everything else is internally 1920X2160 in Horizon Dawn and then checkerboarded up to 3840X2160.
No where in that slide does it describe a 1920x2160 buffer. Here's a question: why don't you say 3840x1080? Both are wrong for the same reason, but neither is more accurate than the other.
The fact is CBR does not use an intermediate resolution. It renders a full resolution framebuffer where every other pixel is sampled from the scene's opaque geometry in a checkerboard pattern. Read this thread for a good overview of how it really works: http://m.neogaf.com/showthread.php?t=1330505
Dictator93
Member
Please take the time to read and think about what it means..
"Everything runs at 2160p checkerboard"
There is a reason that slide differentiates between native res (native res means 3840X2160) hinting and what is done in HZD.
Please feel free to download the slides yourself, but the notes are quite helpful in this:
There are different types of image reconstruction. I posted one from HZD that only ends up at 3840X2160 in a normal grid pattern as part of the final image sent out, after reconstruction via temporal means. Otherwise, every other buffer in a single frame other than the overlay from the ui is shaded at a checkerboarded 2160p, aka 50% of the pixels.
The 1920x2160 number comes from Mark Cerny describing the reference method for checkerboard rendering. It can be organized in different ways but that's one way of describing it. Obviously it's not typical upscaling and the gaps are filled in differently than typical upscaling but by giving that number and talking about the ordered grid it makes it easier for people to mentally picture how the process works.
Dictator93
Member
Exactly. Thank you for putting that into words I failed to find in the proper moment.
And in the case of HZD, it does not even do the normal even / odd alternating of "typical" CB along the ordered grid. But it is of course still shading and going through the normal GPU pipeline for 50% of a 3840X2160 frame.
Getting up in arms, and constantly saying "native but with a caveat" comes accross as trying to obfuscate checkerboarding for platform-warrior reasons. Not trying to clarify.
Please take the time to read and think about what it means..
"Everything runs at 2160p checkerboard"
There is a reason that slide differentiates between native res (native res means 3840X2160) hinting and what is done in HZD.
Please feel free to download the slides yourself, but the notes are quite helpful in this:
There are different types of image reconstruction. I posted one from HZD that only ends up at 3840X2160 in a normal grid pattern as part of the final image sent out, after reconstruction via temporal means. Otherwise, every other buffer in a single frame other than the overlay from the is shaded at a checkerboarded 2160p, aka 50% of the pixels.
It's because of these slides that I find the other comments confusing. I came across these when I was first trying to learn more about the technique. What GG is saying here doesn't really go along with what onQ has been saying, which is why I find this a bit confusing. Wish a dev would come in and set us straight on who's accurately describing it.
Also I'm guessing the final backbuffer is where the reconstruction takes place before being flipped to the front buffer for display. With the number of buffers in play on a typical rendering setup, I can see why there is confusion.
Dictator93
Member
Pottuvoi pointed out something great earlier that is basically at the core of all this talk.
There are many types of image reconstruction techniques, under the non-all-encompassing term "checkerboarding".
OnQ is purposefully trying to obfuscate when he comes into a thread like this by saying "but it is native*". Then he subsequently only attempts to explain the * when pressed whilst maintaining the political stance that using the term "native" is accurate. There is a half truth to the phrasing "native" in regards to checkerboarding of course. The final frame is indeed a native 3840X2160. There is also the fact that some image reconstruction techniques do indeed leverage pixel or otherwise information which is at 3840X2160.
The main reason why I at all brought in the GG presentation was to point out the simple fact that we do not know exactly how TW3 is doing its image reconstruction at all, that not all CB techniques are the same. To blindly come in saying it is 'native but', and saying 'DF is wrong' without knowing ourselves the internal way it is done is purely political.
Like how in the heck does he know this?
Are you running this game on PS4pro through Renderdoc?
demigod
Member
Lol, they're only doing this so they don't get backlash for doing it for the one x and not for the pro.
I have an issue with calling checkerboarding native just like I do with calling it upscaling, although part of the reason I like it is because the display/console output don't have to add any additional image scaling.
On top of that, almost every game that utilizes it does so in a slightly different way so there's no good catch all terminology for it. I expect more complex patterns and processes like Horizon's will become more common as devs experiment more with it on various platforms and into next gen.
BTW while we're getting into the nitty gritty is there any more detail on Insomniac's temporal injection technique? I find it really impressive and want to know the approach.
On top of that, almost every game that utilizes it does so in a slightly different way so there's no good catch all terminology for it. I expect more complex patterns and processes like Horizon's will become more common as devs experiment more with it on various platforms and into next gen.
BTW while we're getting into the nitty gritty is there any more detail on Insomniac's temporal injection technique? I find it really impressive and want to know the approach.
Yeah I saw Pottuvoi's post and thought it was well thought out. Also agree with the rest of your post. I understand there is no one way CBR is done, which is why I find it interesting.
I really wish onQ would just stop with the spin on what's a full 3840x2160 frame buffer but with caveats. The constant need to come into threads revolving around CBR and run into these claims is tiresome. It's like some take it as a form of bashing when we describe it as non-native. I can sort of understand that with some of the trolling that goes around, but I think it's clear many of us just want to be accurate with the terminology.
Appreciate the further explanation.
Yup, I completely agree on the native vs CBR vs upscale comment. Also agree there's no good catch all terminology. The range of quality of the reconstruction varies from game to game. HZD looks cleaner than Rise of the Tomb Raider even though both resolve to a full 3840x2160 resolution.
I'm hoping Insomniac does a panel discussion at GDC next year to cover their TI technique.
At what point in this thread did I say this game was native 4K? now you see why I said there was no point in me talking to you because you keep twisting words for whatever reason.
When did I say but it's native?
Ok full 3840x2160 frame buffers. I figure based on the conversation it was clear what I meant. I'll edit my post to better reflect my point. In the end you feel this need to make attempts at correcting people when half the time they aren't entirely wrong. It's tiring.
Brad Grenz
Member
It's a misleading number that came from people who spent months describing CBR as upscaling. The fact that so many in this thread are clearly confused by how CBR works makes it clear saying "1920x2160" does more harm than good. I don't think people wanting an easy shorthand is a good reason to choose a misleading expression.
I've never described CBR as upscaling, I actually think that's a horribly inaccurate way to describe it. I also don't want an easy shorthand description with intentions on misleading anyone. I think you're taking some of the discussion the wrong way. I simply want an accurate description to how the different implementations of CBR (and other reconstruction techniques) go from point A earlier in the pipeline to point B when it's all flipped to the front buffer and displayed on our screens. I don't see anything wrong with that.
Liabe Brave
Member
As BradGrenz has pointed out, it's equally "correct" to say that CBR uses a 3840x1080 buffer somewhere in the middle of the render process--at least, sparse pixels could be packed either way if so desired. But I feel promulgating either of these buffer sizes for all cases is misleading.
First and most simply because we're talking about intermediate render targets, and we just don't know what those are for most games. As Dictator93 has said, absent presentations most engines are black boxes. To put any specific number on a buffer that isn't the main backbuffer or frontbuffer is usually guessing. But both of those known buffers will be at least full-sized for CBR games (3840x2160 for 2160c, 3200x1800 for 1800c, etc.).
Second, the existence of actual anamorphic rendering, using standard upscale techniques to expand, is a potent possible source of confusion. Even if a game does use a packed 1920x2160 buffer to store intermediate values during CBR, the operations that will proceed on it are of a wholly different type than the familiar, established methods of "unsqueezing" images from similarly-measured buffers. Both the accuracy and efficiency of the CBR process are basically in a different class--one higher, one lower.
Finally, presenting anamorphic buffer sizes--on either axis--leads directly and immediately to assertions about directionally-biased error. Dictator93 is one of the most knowledgeable people on GAF about rendering methods, and in this thread he's pointed out specific games as having a tendency to produce artifacts in the horizontal or vertical. Yet for actual checkerboard rendering, this should be extremely unlikely. The whole point of CBR is that the image is treated uniformly and symmetrically; the checkered sparse pattern and the alternation of reprojection from frame-to-frame ensure this. (Asymmetric reconstruction is a possible method, but seems to have been dropped since Shadow Fall, for good reason.) If anything, CBR artifacting should be most prevalent along 45-degree angles, where the distance between samples is highest. This argument from principle is borne out in that you can usually (always?) find both vertical and horizontal artifacts in screenshots from actual CBR games.
(Extra special bonus point: depending how you measure, even a 1920x3840 CBR render target isn't necessarily the same size as a normal 1920x3840 render target, because CBR pixels aren't square [for some definitions].)
I think clarity and accuracy are best preserved by not taking descriptive shortcuts at all. We always know with high confidence the buffer size before any final scaling operation. Best just to say that number, and then make notes about observed errors and the techniques inferred from them. E.g. "The game resolves to 3200x1800, using a checkerboard technique that produces more artifacts than other CBR games. It then uses standard scaling up or down to the display resolution."
I actually think we should never call a CBR game "native". That's also potentially very confusing for people, since "native" has previously applied only to standard rendering. It therefore implies a false equivalency to use it for CBR. This is why I believe it's more accurate and precise to say "the final image is 3840x2160, half of which is rendered with lower accuracy (but more speed)". If shorthand is needed, I'm a big fan of Durante's "2160c" terminology. It conveys very efficiently that there is both similarity and difference from 2160p.
In general this is a good point, but for Horizon Zero Dawn in particular, I think we do have more information about the internal render targets. Guerrilla have explicitly said that they pack intermediate checkerboard targets into a "tangram" 2160x2160 buffer, which they unwrap after performing an error-correction step. EDIT: Rechecking my recall, it seems they may also use a 1920x2160 buffer earlier in the process. No processing is done on that buffer, however (besides the transform to the tangram version).
Nothing wrong at all, this is definitely the correct goal! I think his point is that flatly stating that "checkerboard uses a 1920x2160 buffer" is misleading, because it's overgeneralized. (I think everyone in the thread agrees there are multiple techniques under the heading "CBR".) But even saying a particular game uses a 1920x2160 buffer can be very misleading as well. This is most definitely not something you can tell for certain just by looking at the final output. Perhaps Digital Foundry was actually given this specific number regarding Battlefront II by someone at DICE, but personally I doubt it. DF have historically been imprecise with their language when talking about CBR, so this is more likely to be a generalization based on an ideal process--the Mark Cerny "reference method" RoboPlato discussed above--rather than a novel datum.
adamsapple
Or is it just one of Phil's balls in my throat?
I don't have any technical knowhow to contribute to this topic but I popped in the disc to run around Blood and Wine for a while with the patch. The increased resolution does wonders for how clean the IQ is and the low-quality vegetation really isn't noticeable outside of stills as it was never an eye-sore in my experience.
Blood and Wine was also better optimized otherwise so I didn't run into any kind of performance shortcomings either.
Blood and Wine was also better optimized otherwise so I didn't run into any kind of performance shortcomings either.
Dictator93
Member
Hey Liabe Bravo,
I have been incredibly busy the last 2 days and will only come to this tomorrow. But thanks for the long, respectful, well-written and well argued post.
I will write back tomorrow.