16 replies to this topic

[starstutter]

I am still deciding whether or not to switch to deferred shading, and I think I have finally found the deciding question.

It has come to my attention that all (maybe not all) UE3 games use deferred shading by default. Maybe it's a conincedence, but the games also have an unbelivable amount of visual depth to them. There's something about Unreal Engine that makes the scenery and characters blend so well together and just have a terrific use of lighting and shadows to create unmatched visual depth. This is comparing to things like the Source engine that, while they look good, look a bit flat and polygonal.

So my question is with this is, could deferred shading be responsible for the high depth in the visuals? I was thinking that maybe deferred shading would allow for more contrasts of light and dark, which I think is one way to increase depth. Even games like Crysis (that use forward rendering) look a bit flat in their visuals, even though realistic.

I personally just think that depth can actually provide more immersion than realism in a lot of cases, so that's what I am leaning towards.


Btw, sorry if this is posted too close together with my last one, but I felt that this was more of a different subject.

[Vilem Otte]

Well, I personaly don't use DS. It's overkill method, and until u don't need 100 lights in the scene affecting - use forward shading. Anyway DS biggest bottlenecks are fillrate-eating (lots of geometry buffers), no blending (uhh, not again), etc.
Anyway if you wan't more depth in the scene - use stereoscopic rendering (also nightmare for DS, for FS it's pretty not-so-hard) and I presonally like pictures from CryEngine 2 much more, than screens from UE3.

[starstutter]

Vilem Otte said:

use stereoscopic rendering

isn't that Voxels? To me those are just totally impractical (at least for todays hardware). Anyway, in my mind DS might provide more depth because it has the abilillity to blend lighting together better than FS.

[Reedbeta]

Stereoscopic rendering has nothing to do with voxels, where did you get that idea? It's just rendering two images, one for each eye, and you use a special display device (like an HMD) to show each image to the correct eye.

But Vilem, why would stereoscopic rendering be any more difficult with deferred shading? That doesn't make sense to me at all.

[starstutter]

Reedbeta said:

Stereoscopic rendering has nothing to do with voxels, where did you get that idea?

lol, oh I don't know... maybe it's because I typed it in on google and I saw the word Voxel appear about a hundered times.

That's an interesting thought though. I would highly doubt Unreal uses anything like that, but I'll look into it more. Or... actually, I guess you need some kind of special display device? I guess my main question still stands though: could deferred shading be influencing the amount of depth in the graphics?

[Reedbeta]

Let's be clear: by "depth", you're not talking about a sense of 3D distance into the screen, right? You mean it more like in the sense of profundity.

[starstutter]

Not entirley sure how profundity fits in to that. If by that you mean level of detail, then not exactly. Here's what I mean...

Just look at the difference between (Bioshock, MOH: Airborne) -

http://img.qj.net/up...qjpreviewth.jpg

http://problematisk....oh_thompson.jpg

http://steamreview.o..._fairground.jpg

and (half life, portal) -

http://www.whatisthe...al_Screen02.jpg

http://www.games32.c...es/md_20917.jpg

maybe it's a matter of opinion to an extent, but to me it just looks like the Unreal based games are going to jump right out at you. It's like there's little people inside your moniter lol.

With the Source games it just really looks drawn on the screen, fine detailing, but a weak sense of depth.

I mean honestly, it's tough to put it into words, but it's almost like the Unreal games give this feeling like you could actually reach inside your screen and there's a whole nother world in there. Another thing is that screenshots never realy do Unreal justice. It focuses on dynamics and screenshots can't really depict that.

lol, taken out of context, this sounds like I'm on some major drugs.


EDIT: Actually, here's a better example in video:

http://www.gametrail...ayer/24506.html (MOH)

http://www.gametrail...ayer/12966.html (ep2)

[Reedbeta]

I'm not sure if there's a genuine difference in the quality of the engine's lighting and shading there. It seems like with the Unreal engine you've picked examples where the lighting is very dramatic - nightime, with lots of contrasting light/dark areas and volumetric effects, while in the examples from the Source engine, things are pretty evenly lit; they're either outdoors or in a well-lit interior.

So I think from the examples you've posted that what you're seeing is more a difference in the art direction of those games rather than a difference in the technical capabilities of the engine.

However, it might be that the reason the Unreal ones have more dramatic lighting is because deferred shading makes that engine better able to handle darkish scenes with lots of small lights, and less well able to handle outdoor or well-lit scenes. So it might come back to the technology, but it's hard to say.

Part of this might also be that the Unreal engine is maybe doing a better job of HDR than the Source engine. But I can't really be sure of that either.

[JarkkoL]

UE3 doesn't use deferred shading. It uses standard forward lighting and relies largely on pre-computed lighting to vertices and lightmaps, with sparing use of real dynamic lights. Not saying you couldn't modify the engine to use deferred shading, but I'm talking about the off-the-shelf UE3. The visual depth in UE3 games is because they just got great artists and nice tools, not because of the technological choice of rendering algorithm ;)

[starstutter]

JarkkoL said:

UE3 doesn't use deferred shading. It uses standard forward lighting and relies largely on pre-computed lighting to vertices and lightmaps, with sparing use of real dynamic lights. Not saying you couldn't modify the engine to use deferred shading, but I'm talking about the off-the-shelf UE3. The visual depth in UE3 games is because they just got great artists and nice tools, not because of the technological choice of rendering algorithm ;)

man.... that whole paragraph just has me skeptical. Then maybe you could answer -

- Why is it I havent seen a UE3 game yet with AA?
- How is it that every company that buys UE3 has the exact same artists with the exact same talents?
- When you go on to Unreal Technology, Anti-alias is not supported or mentioned whatsoever?
I'm not asking these sarcasticly, but sincerley... that just seems like a bit too much of a coincedence.


EDIT: In fact, I'm really not sure which part of that to correct first:

"UE3 doesn't use deferred shading." - I just learned that according to them, that is the default system.
" relies largely on pre-computed lighting to vertices and lightmaps" - the entire basis of Unreal is fully dynamic lighting environments
"I'm talking about the off-the-shelf UE3" - I seriously hope you don't litterally mean "off the shelf"... as in you buy it at a store
"they just got great artists" - in fact, it looks as though epic just lends every company their artists during production ;)

[Vilem Otte]

#Reedbeta - Stereoscopic rendering needs with deferred shading ALL geometry buffers for left eye and for right eye - for both of them! ALL of them, so that's pretty hard to code if you want realtime rendering! Anyway trying to code it "brute force" is the same hard as for forward shading... But it'd me much more slower. Lets calculate some values - F.e. you've got resolution of 1024x768 pixels, and some effects (like some kind of bump mapping (F.e. normal mapping), some post process (let's calculate with 64bit HDR), etc.) ... so:

Forward rendering:
Left eye buffer - 1024*768*64 = 50331648 bits
Right eye buffer - 1024*768*64 = 50331648 bits
Final LDR Backbuffer - 1024*768*32 = 25165824 bits

Memory usage - 125829120 bits = cca 15 MB

Deferred rendering:
(Well, you don't have to create everything in HDR buffers, but u can use LDR ... but you'd lose some quality)
Diffuse geometry buffer - 1024*768*64 = 50331648 bits
Specular + shininess geometry buffer - 1024*768*64 = 50331648 bits
Normal + depth geometry buffer - 1024*768*64 = 50331648 bits
and everything twice times! plus
Final LDR Backbuffer - 1024*768*32 = 25165824 bits

Memory usage - 327155712 bits = cca 39 MB

Well, that's not so much, when comparing - but today it's modern to use big monitors (F.e. 1920 x 1080) and very high precision HDR (128 bits) ... so geometry buffers are growing. And between us - generating 40 MB of data isn't so easy at 75 fps on todays hardware (well, as long as you have something in scene). Anyway I hope my calculations were OK and I didn't make some big mistake ... if am I wrong, please let me know, and I'll correct that.

[Blaxill]

JarkkoL said:

UE3 doesn't use deferred shading.

Yes it does.(Official unreal engine wiki)

From the link said:

Engine Details
Rendering Technologies
Deferred rendering and deferred shading

Vilem Otte:
Its unfair to say DS is an overkill, it has its strengths and weaknesses. DS does eat up your fillrate but sending geometry once to the GPU allows more unique vertices to be sent (higher detail models.)
Stereoscopic rendering is a special case and does not represent normal circumstances. In both cases of using DS and standard forward rendering stereoscopic rendering will half frame rate (i.e. 60 fps for both eyes becomes 30 fps to each eye.) I see no reason why the memory requirements for stereoscopic DS have to double as buffers can be reused. The only case where the same buffers would not be able to be used for both frames (one for each eye) would be where the frames were rendered simultaneously. However, rendering the two frames simultaneously would not gain any benefit as GPU's are stream processors, not threaded.

[Reedbeta]

Vilem, I don't think it's necessary for the fat buffers (geometry buffers as you call them) to be quite so big as you have them! Remember that even when using HDR, the diffuse and specular values stored in the buffer are simply *reflectances*, not intensities or luminosities, so there's really no call to store them in HDR - you don't need more than 8 bits/component, so those would be only 32 bits/pixel. And it's the same for the normals, you can totally get away with storing normals at 8 bits/component. Finally if you're willing to restrict your shading model just a little bit you don't really need a full RGB color for specularity, just a specular intensity. So that halves the size of your buffers:

Diffuse + specular: 1024*768*32
Normal + extra 8-bit channel: 1024*768*32
Depth + stencil: 1024*768*32

As you see with this layout there is an extra 8-bit channel available in the second buffer which you can use for an additional parameter to your shading model, which gets you back some of the flexibility you lost from getting rid of the three-component specular (e.g. you could blend the specular color between white and the material color, which is the range that most specular colors fall in anyways).

Also you forgot to count the depth/stencil buffers when you tallied up for forward shading but you put it in for deferred shading. But you also forgot to count the HDR accumulation buffers for deferred shading.

Anyways, I don't think it's necessary to tally up the numbers again, as it's clear deferred shading consumes a bunch more memory than forward shading. I think the point you were trying to make is that it's hard enough to generate one image at a reasonable framerate with deferred shading due to its memory bandwidth requirements, so it's really hard to generate two. I'll buy that.

[JarkkoL]

starstutter said:

- Why is it I havent seen a UE3 game yet with AA?

IIRC UT3 supports anti-aliasing. Lack of anti-aliasing on many PC platforms is due to HDR lighting though and HW limitations of not supporting anti-aliased HDR render targets. On consoles there are other limiting factors.

starstutter said:

- How is it that every company that buys UE3 has the exact same artists with the exact same talents?

And not every company, ragardless of licensing UE3, produces good quality games. UE3 has good tools though which helps in making good games.

starstutter said:

"UE3 doesn't use deferred shading." - I just learned that according to them, that is the default system.

UE3 doesn't support deferred shading in the sense we are talking about it here at least. If you consider SSAO deferred shading, then yes it supports deferred shading, but the actual dynamic lighting part uses standard forward lighting. Also, the deferred rendering they talk about might refer to the fact that renderer runs in its own thread thus the render commands are deferred.

starstutter said:

"relies largely on pre-computed lighting to vertices and lightmaps" - the entire basis of Unreal is fully dynamic lighting environments

I don't know what's the basis for your claim, but that's really not the case, unless if you rewrite the renderer for UE3 like we did. For example Bioshock you mentioned earlier doesn't use UE3 but heavily modified UE2.5 with their own rendering backend.

Reedbeta said:

Remember that even when using HDR, the diffuse and specular values stored in the buffer are simply *reflectances*, not intensities or luminosities, so there's really no call to store them in HDR

This is not exactly true. When your textures are LDR, lighting them with HDR light sources results in banding artifacts. Surely normalmapping, etc. can hide these artifacts and I believe developers rarely use HDR diffuse textures, but I just wanted to point that out.

edit: fixed quote bug :)

[Vilem Otte]

Quote

Vilem, I don't think it's necessary for the fat buffers (geometry buffers as you call them) to be quite so big as you have them! Remember that even when using HDR, the diffuse and specular values stored in the buffer are simply *reflectances*, not intensities or luminosities, so there's really no call to store them in HDR - you don't need more than 8 bits/component, so those would be only 32 bits/pixel. And it's the same for the normals, you can totally get away with storing normals at 8 bits/component. Finally if you're willing to restrict your shading model just a little bit you don't really need a full RGB color for specularity, just a specular intensity. So that halves the size of your buffers:

Well, as JarkkoL mentioned, diffuse textures will result in artefacts on the screen (and they can be masked though ;-)). Anyway I'm personally using HDR diffuse maps, and I want no artefacts on the screen -> so I have to use HDR diffuse geometry buffer (well, I can try masking 'em). To specular and normal buffers - I agree, it's wasting of fillrate (but I tried just several times on Radeon HD 2900 XT, so there wasn't problem with fillrate ;-)) - I'm much more interested in realtime-raytracing topic (and combined rendering).

Quote

Also you forgot to count the depth/stencil buffers when you tallied up for forward shading but you put it in for deferred shading. But you also forgot to count the HDR accumulation buffers for deferred shading.

I'm not using stencil buffer in my demos, but I forgot depth buffer (sorry about that mistake, I'm really sclerosal sometimes :-().

Quote

Anyways, I don't think it's necessary to tally up the numbers again, as it's clear deferred shading consumes a bunch more memory than forward shading. I think the point you were trying to make is that it's hard enough to generate one image at a reasonable framerate with deferred shading due to its memory bandwidth requirements, so it's really hard to generate two. I'll buy that.

Well, that was the point (I hope that most of you got it ... I'm not so good for explaining :-(, I have to work on myself) - deferred shading eats more bandwidth with lower cost of light computation and forward shading eats less bandwidth with bigger cost of light computation.

Quote

Its unfair to say DS is an overkill, it has its strengths and weaknesses. DS does eat up your fillrate but sending geometry once to the GPU allows more unique vertices to be sent (higher detail models.)
Stereoscopic rendering is a special case and does not represent normal circumstances. In both cases of using DS and standard forward rendering stereoscopic rendering will half frame rate (i.e. 60 fps for both eyes becomes 30 fps to each eye.) I see no reason why the memory requirements for stereoscopic DS have to double as buffers can be reused. The only case where the same buffers would not be able to be used for both frames (one for each eye) would be where the frames were rendered simultaneously. However, rendering the two frames simultaneously would not gain any benefit as GPU's are stream processors, not threaded.

Yeah, it's maybe unfair, but it WAS overkill several years ago. Today it isn't anymore, because new graphics cards are faster, better, etc. Stereoscopic rendering is special case, and I'm using it in most demos (posting images without stereo, because not-everyone has stereo glasses).

[starstutter]

@JarkkoL

GamePro said:

Are you using the Unreal 3 engine for Bioshock?

Ken Levine said:

Yes, it's a modified, heavily modified, engine. It's kind of a hybrid.

http://www.gamepro.c...ticle_id=121329

[JarkkoL]

Right, they upgraded from 2.5 to 3.0. Anyway, doesn't change the fact that Unreal Engine 3 uses forward shading and there's also good chance Bioshock still uses their own renderer due to dynamic lighting limitations.