Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 17 Dec 2009
Offline Last Active Today, 11:20 AM

Posts I've Made

In Topic: How could I use bent normal map

17 April 2016 - 04:41 PM

Calculating bent normals is just an extension of AO calculation where the direction of each sample is also averaged along with the occlusion amount.






The bent normals from substance painter seem correct. In any region that there is no AO, your normal won't be bent in any direction, therefore in tangent space it's pointing straight up along the surface normal. This is why you only see details in the ears.


I have no idea how Unity handles the bent normals but the usual way is to, instead of applying AO as a standard multiplier onto the lighting result (which gives this weird muddy look), use the dot product of the bent normal and the light instead. This is how we handle SSDO in CryENGINE for example.


I've only ever used a texture-based version of this technique once, however in this version the bent normals also contained information from the original tangent space normal map, and was used directly during lighting in place of the original.

In Topic: resolution scaling

02 April 2016 - 10:15 AM

Keep in mind that a lot of games don't do full 1080p rendering for everything. Post FX, Particles, SSAO, to name a few, are all done at lower resolutions and then merged with the full resolution image.


So if you're looking for a 100% natively rendered 1080p game, you probably won't find one today.


The important point to focus on is that, as long as the geometry is rendered at 1080p, people will consider it a 1080p game. If it's scaled down in one dimension (1280x1080) then you won't be considered "full 1080p", but you also won't be considered "not 1080p". People are kinda weird, they don't even notice that this is what they're doing. In the end, all they notice is "clarity", so if it looks even a little blurry they'll start pointing fingers at your resolution. It's pretty clear that they don't really understand how graphics work... hence talking about Textures being sharp and crisp when the image looks nice, since it's the only graphics term they really know.


An example of how this logic can easily be confused is when Guerilla did interlacing for the multiplayer of Killzone: Shadow Fall. They rendered at 1/2 width and alternated between even and odd pixels every frame while blending it with a reprojected previous frame. It caused a pretty big divide between players, some siding with "reprojection doesn't count! it's not true 1080p!" and some siding with "the final output is a 1080p image, it's 1080p".


They even almost got sued over it. ┐( ̄∀ ̄)┌

In Topic: Doing SubSurfaceScattering / backlight

14 March 2016 - 05:52 AM

Why not try Pre-integrated skin shading? It was used in The Order 1886. You can check this blog post for a bit more info, maybe it's what you're looking for.

In Topic: HLSL SM3 Loop into a 1280x720 sampler texture

26 February 2016 - 04:22 AM

What kind of indirect lighting algorithm requires you to sample every pixel on the framebuffer?


If it wasn't for the fact that they were trying to use a 1280x720 image I'd guess that they're trying to use the average to fake diffuse irradiance for an environment probe, since they mentioned "prebaked probes"...


If that were the case then I'd say just do hardware mip-map generation... way less room for error. It wouldn't be at all correct though, for that kind of thing they'd probably want a proper diffuse convolution.

In Topic: DoF - near field bleeding

22 February 2016 - 10:44 AM

You don't need to premul the sharp image by 1-cocNear. :) You just need to premul far and near.


What you want is to blend from back to front, something like this:

float4 sharp = tex2D(sharpTex, coord);
float4 near = tex2D(nearTex, coord);
float4 far = tex2D(farTex, coord);

// undo premultiplication
far.rgb /= far.a > 0 ? far.a : 1.0; // catching division by 0
far.a = saturate(far.a);

near.rgb /= near.a > 0 ? near.a : 1.0; // catching division by 0
near.a = saturate(near.a); // you can multiply by some value to avoid the "soft focus" effect at low CoC values

// compute sharp far CoC at full res (in case farTex is half res)
float depth...
float farCoC...

// composite, starting from back to front
float4 final = lerp(sharp, far, farCoC); // SHARP far CoC, not blurred, can be stored in sharp or far alpha if those are full res
final = lerp(final, near, near.a); // near.a is BLURRED near CoC