Jump to content

DanW58

Community Members
  • Content Count

    417
  • Joined

  • Last visited

  • Days Won

    5

DanW58 last won the day on March 2

DanW58 had the most liked content!

Community Reputation

182 Excellent

2 Followers

About DanW58

  • Rank
    Triplicarius

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. float getDiffuseEscapeFractionFromDielectric( float RI ) { float temp = (2.207 * RI) + (RI * RI) - 1.585; return 0.6217 / temp; } float getCosOfAvgReReflectionAngle( float RI ) { return (0.7012 * RI - 0.6062) / (RI - 0.4146); } // getLODbiasFromIR() will be used in ambient lighting. float getLODbiasFromIR( float IR ) //add 5 for 512; add 6 for 1024 cubes { float denominator = IR - 0.3472; float numerator = 0.1342 + (1.293*IR) - (0.123*IR*IR); return numerator / denominator; } void RealFresnel ( vec3 NdotL, vec3 IOR_RGB, out vec3 Frefl, inout vec3 sin_t, inout vec3 c
  2. Wait! What would be so wrong if we used the same diffuse correction factor for specularity? If we can't see some part of the terrain due to bump over-shadowing, it's no different whether the bounce is diffuse or specular. Let's try it and see what happens: We were talking about subtracting the sine of the mean roughness angle from NdotL. We'd want to do that when the sun is away from us, like on the other side of the object. When the sun is on our side of the object, such as behind us, we'd probably want to add the roughness angle to NdotL. Thus, NdotL += sqrt(1-0.5^(2/n))*(
  3. Let's see: NdotL is the cosine of the sun's angle to the normal. It is also the sine of the sun's angle to the un-roughened surface. If the sun's angle to the surface is small, the sine is roughly same value as the angle. If the sine of the sun's angle to the surface is comparable to the sine of mean surface angularity, the effect is the same as if the sun had an angle to surface that much lower. So we could just subtract the sine of the surface mean angle from the sun's NdotL, and that would have a similar effect to rotating the sun by the same angle. Right? We don't ev
  4. This is what I'm talking about: The effect of the sun's shading on an angular surface is the same as if the surface was flat but the sun was angled away from us by an angle equal to the very surface angularity. The normal here is irrelevant, I think... I now have to figure out how to implement this light vector rotation.
  5. Holly cow! I just remembered that 20 years ago I resolved this very problem, and it's just starting to come back how I did it ... It was in the context of planet rendering. Just a very vague memory ... I ended up scaling the angle of the sun as a function of roughness. A very angular surface caused the light source to move towards its horizon, or even fall behind it. Of course I wasn't moving the Sun itself; --not even the virtual one--; I mean for that pixel I was rendering, surface's mean angularity got added to the light vector's angle to the eye vector, I think it was, -
  6. Okay, I'm starting to see the light at the end of the tunnel... Okay, we are looking at a sphere. Our eyes are fixated on a point near the left horizon on the sphere. Now let's play with the Sun's position: If it is right behind us, it makes the bumpiness near the horizon of the sphere light up like phosphoro-cheese-cake. If it is right on the other side, or barely to the left of the sphere's horizon, it makes the far-side of the bumps light up, but our side of them is in darkness; so the net result is darkening. However, the effect is not symmetrical. Or, is it? I thi
  7. Could it simply be that this should be a function of the light vector, and NOT the eye vector? EDIT: Nope.
  8. No; that's not correct. I was only considering in the case of the light being on the other side, litting the back-faces. Should the light direction figure into this? Well, if the light is behind us, roughness at shallow angles will make the surface look MORE bright, not less; so yes, the light direction is important. In fact, this is why the full moon shades like a flat disk of cheese: It's the fact that it's not terribly smooth. Think, think, think ...
  9. Indeed. SpotRadius = arccos( 0.5^(1/n) ) In other words, cos(radius) = 0.5^(1/specpower); sin(x) = sqrt(1-cos(x)^2), so sin(x) = sqrt(1-0.5^(2/n)) Our dimming factor could be computed as PhongDF = clamp( dot(eyeVec, normal) / sqrt(1.0-pow(0.5, 2.0/specpower)); Thus, our full Pong function could look like this: float getPhongFactor(vec3 eyedotnormal, vec3 halfdotnormal, float SpecPower) { float FunnyNumber = pow(0.5, (1.0 / SpecPower)); float PhongDispersionFactor = 0.5 / ( 1.0 - FunnyNumber ); float PhongSelfOccludFactor = clamp(eye
  10. Phong sucks! Yes, I've said it. The way it is traditionally used in shaders is particularly retarded. People forget that the lower the spec power, and the wider the reflection spots, the more dispersed the reflection is, and therefore the less bright each pixel looks. The total light is invariant with spec power, but the per-pixel light needs to be adjusted for spread. But article after article on Phong shading fails to mention this. That's why I have a PhongDispersionFactor variable in the code of the last post. But there's more to the crappiness of Phong; and no; it's no
  11. Revised code to include Phong: float getDiffuseEscapeFractionFromDielectric( float RI ) { float temp = (2.207 * RI) + (RI * RI) - 1.585; return 0.6217 / temp; } float getCosOfAvgReReflectionAngle( float RI ) { return (0.7012 * RI - 0.6062) / (RI - 0.4146); } // getLODbiasFromIR() will be used in ambient lighting. float getLODbiasFromIR( float IR ) //add 5 for 512; add 6 for 1024 cubes { float denominator = IR - 0.3472; float numerator = 0.1342 + (1.293*IR) - (0.123*IR*IR); return numerator / denominator; } void RealFresnel ( vec3 NdotL, vec3 IOR_RGB, out vec3 Frefl,
  12. So, as I was saying, "...next stage in the pipeline would be the eyeVector Fresnel refraction modulation and Fresnel reflection modulated environment mapping, plus ambient. This next stage would also compute Phong." Oh, no! Another HUGE mistake ... Phong has to be computed per-light. So, our previous routine HAS to include Phong. Well, better to discover mistakes at this stage than to discover them at revision 42...
  13. I've just decided against testing this by itself. It is too difficult, given that nothing like this function exists in any of the current shaders, and therefore the interfaces are not there to plug this in. To plug this in I need to modify the existing code to conform to this model. But what is easier to do? Modify old code?, or write new code? Definitely the latter; so might as well complete the pipeline here, and test the whole thing. This function gives us reflectivity per light, excluding emerging fresnel modulation. The next stage in the pipeline would be the eyeVector Fre
  14. Coffee is having its desired effect. I just realized that indeed, the diffuse light coming out of a dielectric absolutely HAS to be modulated by Fresnel refractivity computed on the view vector. However: The emerging light figure that our unified formula yields is for total light going out. There are two ways we could proceed with this modulation: Compute a modulation that goes above and below 1.0 as to be neutral on a spherical average. Compute a standard refractive modulation, but have our universal formula scale the light back up so that it represents the maximum light c
  15. I knew this was a tough one; I tried hard to get anything to work; infinite thanks. And it works perfectly. float getLODbiasFromIR( float IR ) //add 5 for 512; add 6 for 1024 cubes { float denominator = IR - 0.3472; float numerator = 0.1342 + (1.293*IR) - (0.123*IR*IR); return numerator / denominator; } One subject not dealt with yet is rougness/smoothness, improving the Phong model, and how spec power and Fresnel combine. But I'm just waking up for now. EDIT: Spreadsheet updated: EDIT2: LOL, when someone complains "it's too dark", "it's too bri
×
×
  • Create New...