Uncharted 2 lighting?

E

Ether_Snake

Newcomer
Hi all. I was looking at Uncharted 2, moving around with the free camera, and I'm wondering if anyone knows if they used a middleware like Beast or is it all deferred rendering?

Basically, the lighting is incredible, and I'm wondering if it is baked textures, all dynamic lights, or a bit of both? Of course there are some dynamic lights, but I'm wondering if all that pretty lighting in the environment is from baked lightmaps or what.

Thanks!
 
Last edited by a moderator:
SSAO yeah, it's nice but I'm talking about all that radiosity in the environments, the fact that the lighting isn't vertex-baked, flat, etc.

The game I'm working on uses a lot of baked vertex lighting, it looks like a PS2 game IMO. I'm sick of vertex lighting. I'm wondering if ND used some sort of Beast-like middleware to bake the lighting into lightmaps or what, I want to go that route. I never want to work on another game with vertex-baked lighting.
 
I assume they used FP16 HDR at least and tone mapping for the excellent contrast in the game. Awhile back the guys from Digital Foundry has made indication of GI usage though still not confirmed yet. I don't think they used deferred rendering though as I don't see that many light sources in the level. The good use DOF also contribute to the look and feel I believe since it's making everything smoother. Just my guess.
 
Ether_Snake said:
SSAO yeah, it's nice but I'm talking about all that radiosity in the environments, the fact that the lighting isn't vertex-baked, flat, etc.

The game I'm working on uses a lot of baked vertex lighting, it looks like a PS2 game IMO. I'm sick of vertex lighting. I'm wondering if ND used some sort of Beast-like middleware to bake the lighting into lightmaps or what, I want to go that route. I never want to work on another game with vertex-baked lighting.
Click to expand...
Vertex lighting can look good if you store lighting from several angles to the vertex. (Basically PRT and spherical harmonics with samples located on vertex positions.)
Thisway you can use normalmaps and perpixel lighting when you render the surface.

They did use PRT in first Uncharted so I doubt that they would change it too much.
ultragpu said:
I don't think they used deferred rendering though as I don't see that many light sources in the level.
Click to expand...
They did use their own take on Deferred Rendering/lighting on first Uncharted, so I would expect them to continue forward from that.
 
They used the LUV 32bpp format conversion for the colour/HDR. A few other buffers were FP16 though. (Uncharted 1)

It's not unreasonable to assume they're using a more advanced GI solution compared to the first. :) The lighting is much more accurate from what little I have seen.
 
AlStrong said:
They used the LUV 32bpp format conversion for the colour/HDR. A few other buffers were FP16 though. (Uncharted 1)

It's not unreasonable to assume they're using a more advanced GI solution compared to the first. :) The lighting is much more accurate from what little I have seen.
Click to expand...
Cool, is LUV 32bpp similar to the logluv method applied for Heavenly Sword? Can't wait for a full DF analysis in the future.
 
jlippo said:
Vertex lighting can look good if you store lighting from several angles to the vertex. (Basically PRT and spherical harmonics with samples located on vertex positions.)
Thisway you can use normalmaps and perpixel lighting when you render the surface.

They did use PRT in first Uncharted so I doubt that they would change it too much.

They did use their own take on Deferred Rendering/lighting on first Uncharted, so I would expect them to continue forward from that.
Click to expand...


We do this actually, but I've noticed that we don't really see the normal maps. If I display only the lighting, I can see it is affecting the normal maps, but when I switch to Final view mode it's all flat. Maybe because the light source being an omni, rather than a direct light, it makes it too soft? It looks like PS2 to me.

And what is "LUV 32bpp format conversion for the colour/HDR"?

Thanks a lot
 
Ether_Snake said:
We do this actually, but I've noticed that we don't really see the normal maps. If I display only the lighting, I can see it is affecting the normal maps, but when I switch to Final view mode it's all flat. Maybe because the light source being an omni, rather than a direct light, it makes it too soft? It looks like PS2 to me.

And what is "LUV 32bpp format conversion for the colour/HDR"?

Thanks a lot
Click to expand...

They convert from linear RGB to LUV color space, and then store the log of the L component (luminance) across 2 components of an RGBA8 surface. So you end up with 16 bits for luminance (15 if you store a sign bit), which gives you enough precision for a high dynamic range in your luminance values. However you maintain a 32bpp footprint for each pixel, so you don't have the storage and bandwidth requirements of FP16. See this. You can also check this out.
 
Something I found interesting on the last video here - on the last part about their lighting they say they're using a 'filmic filter' for the HDR to be able to play more with the lighting values. They also mention it solves a lot of the shadowing problems they had and that it was hard to do but the benifits were huge.

Not a lot else on it. I'm wondering exactly what they meant by solving shadow problems - maybe it's used to just cover up far away shadows so they aren't as jaggy looking?
 
Last edited by a moderator:
PhilB said:
Something I found interesting on the last video here - on the last part about their lighting they say they're using a 'filmic filter' for the HDR to be able to play more with the lighting values. They also mention it solves a lot of the shadowing problems they had and that it was hard to do but the benifits were huge.

Not a lot else on it. I'm wondering exactly what they meant by solving shadow problems - maybe it's used to just cover up far away shadows so they aren't as jaggy looking?
Click to expand...

Nice, and very interesting, thanks.
 
1.2 million triangles per scene doesn't necessarily mean that's the total to be rendered... there may be multiple passes for the framebuffer, there may be many shadow buffers, so the actual numbers may be higher.

Also, that 250M is only true if only one additional vertex is needed to draw a new polygon. In reality though, this may be broken by changes in UV continuity, smoothing groups and so on, requiring more vertices by triangle. This is something artists can optimize for but only to limited extent...
 
You must log in or register to reply here.

Similar threads

S
Discussion about lighting (usage of lighting techniques).
2
Replies
21
Views
1K
Frenetic Pony
F
I
The first Evil Within still has remarkably sophisticated lighting
Replies
2
Views
458
Phantom88
P
I
"Material/shader-space lighting" and softness in modern rendering
Replies
9
Views
1K
JoeJ
J
G
Tech Differences between Switch and 7th Gen (PS3/360) Games
2
Replies
21
Views
6K
GuardHei
G
N
Hellslave (Saturn Homebrew)
Replies
6
Views
3K
Nesh
N
Back
Top