Chris_F

I guess I'd just like a really good engineering solution, something that you can say "ok, this works for everything everywhere all the time" and you don't need X to back it up.

I think path tracing meets that criteria.

It is sort of like Heisenberg's uncertainty principle in a way. You can't have a general solution that works well for all scenarios and is computationally cheap at the same time.

Unless you mean adding a new MIP level with higher resolution

That is indeed what I meant. You don't need a 4K screen to get benefit from having 4K textures over 2K textures. When was the last time you saw a game in which texel size never exceeded pixel size on a 1080p screen? Not even Rage with its megatextures can manage to do that. Sure, things look good at a distance or at 60mph, but if you get close up and inspect things you'll see the large texels and compression artifacts.

I'm not sure you got the idea where sampling textures might be slow from - this is something that 3D accelerators have been doing since before 1996 (and we're talking D3D11 so we're talking reasonably modern hardware here, which makes the whole notion even odder).  The whole question smells heavily of pre-emptive optimization to me.

 

Stop assuming, I asked a very simple question, I didnt get any ideas from anywhere

 

"The whole question smells heavily of preemptive optimization to me"

Really? explain please, cause your post smells as wanabe all over it..cant I ask a simple question on a subject I dont know about without someone using the opportunity to say "premature ..root of evil"

 

Your post is so contradictory in every sense. If its so obvious ("since 1996..blablabla") how can this be premature optimization? If its obvious and I didnt know about,  I should have asked much sooner since I should know the obvious information. Katie pretty much posted everything I wanted to know and more, and than theres your useless followup there just for the sake of promoting yourself over my lack of knowledge on the subject..seriously.. its unbelievable

You're not being persecuted by mhagain. Were you really that offended by his post?

Taking a simple, low level operation (ordinary texture sampling) and looking for a way to speed it up despite not having found it to be an actual bottleneck in a specific instance is pretty much the definition of premature optimization. I should know, I've been guilty of it far more times than I can count.

Just do the math.

A single 8K uncompressed 8-bit RGBA texture is 256 MB. Heaven forbid you need 16-bit or even 32-bit float for something.

You could never have enough graphics memory. Double the amount of memory and artists will want to add an extra MIP level to the textures for higher quality, which then quadruples the amount of memory you would need.

Well yeah...was just not sure if it would be this strong of a blue tone since gold would be kind of yellowish I guess (the specular itself is more so, so I guess its okay...)

I removed the multiplication, I realized it was wrong since I was multiplying it two times in a row with the fresnel term.

 

About the GGX, do you have a sample code / paper on how to implement that ?

float NdotH_2 = NdotH * NdotH;

float a_2 = a * a;

float D = a_2 / pow(NdotH_2 * (a_2 - 1.0) + 1.0, 2.0);

You shouldn't be multiplying your environment map with Fresnel_spec, which uses the half vector.

I would not recommend Gaussian distribution function, or Beckmann, or texture look-ups. GGX is about as cheap as Blinn-Phong to compute, and supports very rough surfaces like Beckmann. Out of all of them I think it looks the best too.

As for your gold looking "blueish", of course it does. It's in a blue environment. If everything around it is blue, then what else is there to reflect but blue?

If this is C++, then you can potentially do a lot better than the C library's rand function.

http://www.cplusplus.com/reference/random/

Is Direct x portable to mac??

Yes, with OpenGL.

Create your own simple format that can be easily loaded into a vertex buffer. It's a video game, not a 3d modeling suite. There is no reason for it to support a bunch of formats and there is certainly no reason for it to be parsing textual mesh formats at runtime.

It should probably be clear why shadow maps are necessary based solely off the observation that light occluders are often off screen.

OK, here I did a test with a little C++ and the FreeImage library. I rendered a test cube in Blender with low lighting and no textures, then exported it as a 16-bit EXR. I quantized the image to 8-bits:

Top left you see the results if you output floor(pixelColor * 255f + 0.5f), and then on the right you see floor(pixelColor * 255f + rand), where rand is between 0 and 1. At the bottom I adjusted the contrast to show it off better. The random bias is added after gamma correction but before quantization, so I don't think there is any way to utilize a sRGB backbuffer for this technique.

http://www.gamedev.net/topic/552315-glsl-area-light-implementation/

I think someone may have extended this technique for use in Blender Game Engine:

OK, I'm bumping this thread because I'm revisiting the Fresnel equation, this time using complex IOR values. I'm having a hard time converting this to complex numbers.

float Fresnel(float CosThetaI, float n)
{
    float CosThetaT = sqrt(max(0, 1 - (1 - CosThetaI * CosThetaI) / (n * n)));
    float NCosThetaT = n * CosThetaT;
    float NCosThetaI = n * CosThetaI;
    float Rs = pow(abs((CosThetaI - NCosThetaT) / (CosThetaI + NCosThetaT)), 2);
    float Rp = pow(abs((CosThetaT - NCosThetaI) / (CosThetaT + NCosThetaI)), 2);
    return (Rs + Rp) / 2;
}

This is the basic formula, but I need to re-write it so that it looks like:

float Fresnel(float CosThetaI, vec3 n, vec3 k)
{
    ...
}

Where n and k make up the complex IOR (n + ki). I've taken a few stabs at it, but it's gotten me nowhere. Here is my train wreck of an attempt:

vec3 Fresnel(float CosThetaI, vec3 n, vec3 k)
{
    float temp = 1 - CosThetaI * CosThetaI;

    vec3 NKSqr_real = n * n - k * k;
    vec3 NKSqr_imag = n * k * 2;

    vec3 temp2_real = (temp * NKSqr_real) / (NKSqr_real * NKSqr_real + NKSqr_imag * NKSqr_imag);
    vec3 temp2_imag = -(temp * NKSqr_imag) / (NKSqr_real * NKSqr_real + NKSqr_imag * NKSqr_imag);

    temp2_real = 1 - temp2_real;
    temp2_imag = -temp2_imag;

    vec3 CosThetaT_real = sqrt((temp2_real + sqrt(temp2_real * temp2_real + temp2_imag * temp2_imag)) / 2);
    vec3 CosThetaT_imag = sign(temp2_imag) * sqrt((-temp2_real + sqrt(temp2_real * temp2_real + temp2_imag * temp2_imag)) / 2);

    vec3 NCosThetaT_real = n * CosThetaT_real - k * CosThetaT_imag;
    vec3 NCosThetaT_imag = k * CosThetaT_real + n * CosThetaT_imag;

    vec3 NCosThetaI_real = n * CosThetaI;
    vec3 NCosThetaI_imag = k * CosThetaI;

    vec3 CosThetaI_minus_NCosThetaT_real = CosThetaI - NCosThetaT_real;
    vec3 CosThetaI_minus_NCosThetaT_imag = -NCosThetaT_imag;

    vec3 CosThetaI_plus_NCosThetaT_real = CosThetaI + NCosThetaT_real;
    vec3 CosThetaI_plus_NCosThetaT_imag = NCosThetaT_imag;

    vec3 a, b, c, d;

    a = CosThetaI_minus_NCosThetaT_real;
    b = CosThetaI_minus_NCosThetaT_imag;
    c = CosThetaI_plus_NCosThetaT_real;
    d = CosThetaI_plus_NCosThetaT_imag;

    vec3 Rs_real = (a * c + b * d) / (c * c + d * d);
    vec3 Rs_imag = (b * c + a * d) / (c * c + d * d);

    vec3 Rs = sqrt(Rs_real * Rs_real + Rs_imag * Rs_imag);
    Rs = Rs * Rs;

    vec3 CosThetaT_minus_NCosThetaI_real = CosThetaT_real - NCosThetaI_real;
    vec3 CosThetaT_minus_NCosThetaI_imag = CosThetaT_imag - NCosThetaI_imag;

    vec3 CosThetaT_plus_NCosThetaI_real = CosThetaT_real + NCosThetaI_real;
    vec3 CosThetaT_plus_NCosThetaI_imag = CosThetaT_imag + NCosThetaI_imag;

    a = CosThetaT_minus_NCosThetaI_real;
    b = CosThetaT_minus_NCosThetaI_imag;
    c = CosThetaT_plus_NCosThetaI_real;
    d = CosThetaT_plus_NCosThetaI_imag;

    vec3 Rp_real = (a * c + b * d) / (c * c + d * d);
    vec3 Rp_imag = (b * c + a * d) / (c * c + d * d);

    vec3 Rp = sqrt(Rp_real * Rp_real + Rp_imag * Rp_imag);
    Rp = Rp * Rp;

    return (Rs + Rp) / 2;
}

It would be so much easier if HLSL/GLSL had first class support for complex values.

EDIT:

Never mind. I managed to come up with this.

vec2 CADD(vec2 a, vec2 b) {    return a + b; }
vec2 CSUB(vec2 a, vec2 b) {    return a - b; }
vec2 CMUL(vec2 a, vec2 b) {    return vec2(a.x * b.x - a.y * b.y, a.y * b.x + a.x * b.y); }
vec2 CDIV(vec2 a, vec2 b) {    return vec2((a.x * b.x + a.y * b.y) / (b.x * b.x + b.y * b.y), (a.y * b.x - a.x * b.y) / (b.x * b.x + b.y * b.y)); }
float CABS(vec2 a) { return sqrt(a.x * a.x + a.y * a.y); }
vec2 CSQRT(vec2 a) { return vec2(sqrt((a.x + sqrt(a.x * a.x + a.y * a.y)) / 2), sign(a.y) * sqrt((-a.x + sqrt(a.x * a.x + a.y * a.y)) / 2)); }

float _Fresnel(float _CosThetaI, vec2 n)
{
    vec2 CosThetaI = vec2(_CosThetaI, 0);
    vec2 CosThetaT = CSQRT(CSUB(vec2(1.0, 0), CDIV(CSUB(vec2(1.0, 0), CMUL(CosThetaI, CosThetaI)), CMUL(n, n))));
    vec2 NCosThetaI = CMUL(n, CosThetaI);
    vec2 NCosThetaT = CMUL(n, CosThetaT);
    float Rs = pow(CABS(CDIV(CSUB(CosThetaI, NCosThetaT), CADD(CosThetaI, NCosThetaT))), 2);
    float Rp = pow(CABS(CDIV(CSUB(CosThetaT, NCosThetaI), CADD(CosThetaT, NCosThetaI))), 2);
    return (Rs + Rp) / 2;
}
 
vec3 Fresnel(float CosThetaI, vec3 n, vec3 k)
{
    return vec3(
            _Fresnel(CosThetaI, vec2(n.r, k.r)),
            _Fresnel(CosThetaI, vec2(n.g, k.g)),
            _Fresnel(CosThetaI, vec2(n.b, k.b))
        );
}

If you keep the ambient occlusion separate from other things (e.g. diffuse) and only use it in the ambient portion of your lighting calculation, then it will look just fine.

I've been having an issue with different Cook-Torrance geometry terms though - most of these BRDF's are modulated by NdotV in some way, with the assumption that this can't be negative, else the fragment wouldn't be visible. However, in actual game scenes, this assumption doesn't hold! Simply picture a cube that's had normals generated without hard-edges / with every face in the same smoothing group (or alternatively, picture a sphere that's been LOD'ed super-aggressively into a cube - same thing). In this case there's a huge number of fragments where NdotV will be negative, but simply cutting off the lighting for these fragments looks really unnatural.
To get around these unnatural cut-offs in my game scenes, I've simply scaled/biased NdotV (and NdotL to maintain reciprocity) into the 0-1 range right before doing the specular calculations, which produces a "wrapped geometry term", instead of one that becomes zero at the horizon...
Has anyone else dealt with this issue?

Kelemen Szirmay-Kalos! Kelemen Szirmay-Kalos! Kelemen Szirmay-Kalos!

 

Okay, okay, I'll try and add some useful content later on. But seriously, it's designed to be a Cook-Torrance geometry term that doesn't suck. It succeeds.

The Kelemen Szirmay-Kalos visibility approximation is indeed very handy. My minimalistic Cook-Torrance uses it because it's dirt cheap and gives good results, but it suffers from the same shortcoming as the original Cook-Torrance geometry term, and that is that it does not take the roughness of the surface into account at all.

I'm still not sure about the way retroreflection is being handled. It seems to me that most natural materials display very little in the way of retroreflection, and mostly at grazing angles. This is captured by Oren-Nayar and GGX. Objects with very high levels of retroreflection are synthetic and consist of macroscopic corner reflectors, or similar. It would be nice if these could be modeled more accurately.

Path tracing of a flat surface made up of corner reflectors. L = V = ~45°