*Sub-Thread* Dithering in GTA4

Off topic, but Hahahha at the FUD detergent. I didn't notice that :)

Even more off-topic, but that prompted me that this game actually reminds me an aweful lot of the original Leisure Suit Larry. I think you could write an interesting article that compares these two games.
 
Good observation! That would appear to rule out it being due to texture corruption, and indicates some sort of post-processing effect gone awry.
I still don't agree with that. First of all, this doesn't look the same at all. You have little smearing of the neon along the electrical lines, not the stippled, garbled look of the affected textures. Secondly, there's no other evidence of any other geometry edges being affected other than alpha tested object (due to alpha-to-coverage, which actually looks better than simple alpha testing) or the illusion of geometry artifacts from a garbled texture and/or dithered shadow.

I did a face-on washing machine shot for you but am not sure I'm close enough for you.
Thanks. You're right, it is too far, but it does help a bit anyway. I see if I can get around to the test I was talking about.
 
As I thought of in the other thread, if you are right about alpha blending being possible in combination with HDR (FP16) on the PS3, but not with HDR on the 360, then are we seeing the same alpha differences as we have been seeing in Sega Rally for instance?
 
As I thought of in the other thread, if you are right about alpha blending being possible in combination with HDR (FP16) on the PS3, but not with HDR on the 360, then are we seeing the same alpha differences as we have been seeing in Sega Rally for instance?
No, the lack of alpha blending with 360 only applies to FP16. There's still FP10 (and even I16 if you want) on 360 that allow both AA and half speed alpha blending. (FYI, RSX has half-speed blending for all formats, and an additional factor of 1/2 for FP16.)

FP10 is sufficient for HDR unless you are really anal about being mathematically correct about the most extreme situations. Like I've mentioned before, cameras have only 8-9 stops of dynamic range, where as FP10 has 13. If you do HDR properly, that's plenty of extra room to get the rendering done.
 
Ok, fair enough. However, having said that, is it possible that for any sort of (silly?) reason they decided to do FP16 on both consoles? I've seen sillier things happen.

And since the game seems to use deferred rendering, I'm wondering how that fits into all this.

Though Eurogamer has promised that they have something more than the average comparison in the shortly upcoming comparison.
 
Ok, fair enough. However, having said that, is it possible that for any sort of (silly?) reason they decided to do FP16 on both consoles? I've seen sillier things happen.
I seriously doubt it. There are lots of alpha blended effects in GTA4, and I doubt you could emulate that on 360 and have a higher resolution too.

And since the game seems to use deferred rendering, I'm wondering how that fits into all this.
I don't think it does. It was just a guess based on a loose description of the engine's lighting abilities. DR is really important for many local shadowed lights, and even then it's possible to work around that with good dynamic branching. GTA4 doesn't have that, as only one light source is shadowed.
 
Mintmaster: regarding the alpha to coverage theory and the dithering getting worse when stuff is distant from the camera: what if the alpha channel in the mipmaps is someway screwed?
This might maybe explain those curious dithering artifacts..
 
I don't think it does. It was just a guess based on a loose description of the engine's lighting abilities. DR is really important for many local shadowed lights, and even then it's possible to work around that with good dynamic branching. GTA4 doesn't have that, as only one light source is shadowed.
I'm almost 100% sure it's a deferred renderer, based on a chat with a developer in the last few days.
 
On second thought, I also have doubts about GTA4 using a deferred renderer. There's just too much shader variety - characters, car paint, glass, wet roads, concrete, water etc. are all very obviously different. It's one of the things that gives the game a very unique look, particularly when playing it.
So, I think that it'd be far too much for the 360's EDRAM to manage such a complex G-buffer, complete with reflection and material mask passes and 2x AA on top of it all.
 
Mintmaster: regarding the alpha to coverage theory and the dithering getting worse when stuff is distant from the camera: what if the alpha channel in the mipmaps is someway screwed?
This might maybe explain those curious dithering artifacts..
I had a similar theory early in the thread, but it was before I knew that it was distant dependent and so I didn't have the mipmap aspect. Now my theory has mipmaps, but I tossed the alpha aspect.

The artifact happens in places where you just don't expect any alpha channel. When the "BurgerShot" was the only thing we were looking at, I thought maybe the artist was thinking about the geometry underneath glowing through the lettering like a real sign. However, with more screenshots, we're seeing it almost everywhere that there's a minified texture, and its clear that the color channels are being garbled as well.

Right now my theory is that Rockstar is are doing manual mipmap generation but didn't quite interpret the data tiling right on 360. Each 2x2 block of texels is in the wrong order except for the top level mipmap (which would be copied straight from the disc). As you can imagine, depending on the texture data, this can manifest itself as a subtle change or a drastic garbling. I'm going to try recreating a texture and see what happens when I apply it to a 3D polygon.
 
Can someone from B3D interview Rockstar on this, to find out if it's intentional or a mistake, and if they plan to fix it through some patching?
 
Right now my theory is that Rockstar is are doing manual mipmap generation but didn't quite interpret the data tiling right on 360.

Does this mean it's possible to fix with a patch of some sort (assuming the theory is correct)?
 
On second thought, I also have doubts about GTA4 using a deferred renderer. There's just too much shader variety - characters, car paint, glass, wet roads, concrete, water etc. are all very obviously different. It's one of the things that gives the game a very unique look, particularly when playing it.
So, I think that it'd be far too much for the 360's EDRAM to manage such a complex G-buffer, complete with reflection and material mask passes and 2x AA on top of it all.

Yeah I don't really see how a full-blown deferred renderer would make much sense on the 360 either, but who knows. I've also seen Wolfgang (R* lead graphics programmer) voice some pretty severe criticisms of DR over at gamedev.net, but of course that doesn't necessarily mean GTA isn't using one (in fact having to work with the limitations of DR would probably be a good reason for being so fed up with it! :smile:).

He did also mention that they're planning articles that will go over some of game's techniques, I'm looking forward to seeing those whenever they're available.
 
Well, on the other hand there's one thing that DR could help with - that city must have a hideous amount of overload. But they can easily do a Z-only prepass as well...
 
Does this mean it's possible to fix with a patch of some sort (assuming the theory is correct)?
Even if I'm wrong I'm sure it can be fixed with a patch, assuming Rockstar bothers to do so.

MS is claiming 1000 games for the 360 this summer, and as far as anyone knows none of them have the same bug, nor does the PS3 version of this game. It must be a software problem.
 
Right now my theory is that Rockstar is are doing manual mipmap generation but didn't quite interpret the data tiling right on 360. Each 2x2 block of texels is in the wrong order except for the top level mipmap (which would be copied straight from the disc).

I missed alot of this thread so you may have already answered this, but do you think Rockstar is generating the mipmaps on the fly (stream the main texture from disc and generate the mip on the spot via cpu), or do you think they save textures already mipped on disc, and hence their offline mipmap generation tool has a flaw? The reason I ask is because if they are creating mips on the fly, maybe the 'error' we see is more of a cpu optimization that they were willing to live with? In other words, they traded cpu use for some visual error?
 
I missed alot of this thread so you may have already answered this, but do you think Rockstar is generating the mipmaps on the fly (stream the main texture from disc and generate the mip on the spot via cpu), or do you think they save textures already mipped on disc, and hence their offline mipmap generation tool has a flaw? The reason I ask is because if they are creating mips on the fly, maybe the 'error' we see is more of a cpu optimization that they were willing to live with? In other words, they traded cpu use for some visual error?

When I first saw the images I thought of undersampling aliasing, like mipmaps are poorly generated or some of them are not available at all.
 
I missed alot of this thread so you may have already answered this, but do you think Rockstar is generating the mipmaps on the fly (stream the main texture from disc and generate the mip on the spot via cpu), or do you think they save textures already mipped on disc, and hence their offline mipmap generation tool has a flaw? The reason I ask is because if they are creating mips on the fly, maybe the 'error' we see is more of a cpu optimization that they were willing to live with? In other words, they traded cpu use for some visual error?
Mipmap generation is so damn easy, though. You could probably generate the mipmap 100 times in the time it takes to transfer the texture from disc. You do it once and can use the results until the texture gets booted from the cache. On the fly generation makes sense to me.

It could be an error in a custom offline tool, but I would expect them to use MS tools in they were storing them that way. Maybe streaming precludes them from doing so.

Either way, it's still shocking to see an error like this make the final build.
 
Food for thought: the first GTA4 images from about a year ago.

I can't see the same dithering effect on these, so I still wouldn't rule out that it's intentional.

Theory: the trees seem to have some artifacting though, maybe that's what they couldn't get rid of and decided to cover it up?
 
Back
Top