DanW58

@nani Any chance you could do me one more matlab favor? This is the angle of incidence after every diffuse bounce and internal reflection, as a function of refractive index: refractive cos of average index reflect angle ========== =========== 1.0 0.0000 1.5 0.4115 2.0 0.5023 2.5 0.5494 3.0 0.5786 3.5 0.5985 4.0 0.6132 4.5 0.6242 5.0 0.6329 Thanks in advance.

Alright, taking a break from the other shaders. Back to the world of Sanity! So as I finished my second-last post I was saying that the repeating cycle for diffuse reflections does NOT start with ray 'c' going towards the diffuse layer. This is because the angle matters, and it will be a constant dependent on index of refraction alone after internal reflections begin, but at the stage of ray 'c' it is dependent on the incident light's angle. So, our photon saga now looks like this (separating the repeating part): //where.. void RealFresnel( vec3 NdotL, vec3 IOR_RGB, out vec3 Frefl, inout vec3 sin_t, inout vec3 cos_t ) { vec3 Z2 = WHITE / IOR_RGB; // Assumes n1 = 1 thus Z1 = 1. vec3 cos_i = NdotL; // assignnment for name's sake vec3 sin_i = sqrt( WHITE - cos_i*cos_i ); sin_t = min(WHITE, sin_i * Z2); // Outputs sin(refraction angle). cos_t = sqrt( WHITE - sin_t*sin_t ); // Outputs cos(refraction angle). vec3 Rs = (Z2*cos_i-cos_t) / (Z2*cos_i+cos_t); vec3 Rp = (Z2*cos_t-cos_i) / (Z2*cos_t+cos_i); Frefl = mix( Rs*Rs, Rp*Rp, 0.5 ); // Outputs reflectivity. } //The saga, from the beginning (from sun-ray): void saga_of_a_photon( vec3 ray_A, vec3 normal, vec3 MatDiffuseRGB, vec3 RefractiveIndex, out vec3 specularFactorRGB, out vec3 diffuseFactorRGB ) { //Getting ready ... float NdotL = max( 0.0, dot( ray_A, normal ) ); vec3 ReflectivityRGB; vec3 sinRefrAngle; vec3 cosRefrAngle; RealFresnel( vec3(NdotL), RefractiveIndex, Reflectivity, sinRefrAngle, cosRefrAngle ); float EscapeFraction = getDiffuseEscapeFractionFromDielectric( RefractiveIndex ); float cosAvgReflAngle = getCosOfAvgReReflectionAngle( RefractiveIndex ); vec3 diffuseFactorRGBacc = vec3(0.0); //repeating cycle vars: vec3 ExplodingRGBlight vec3 LightEscapingRGB; vec3 LightIncomingRGB; //First reflection (ray_B): specularFactorRGB = Reflectivity; //First refraction (ray_C): LightIncomingRGB = vec3(1.0) - Reflectivity; //First diffuse bounce vec3 ExplodingRGBlight = LightIncoming * cosRefrAngle * MatDiffuseRGB; //<Sound of trumpets here.> //First iteration of our repeating cycle: LightEscapingRGB = ExplodingRGBlight * EscapeFraction; diffuseFactorRGBacc += LightEscapingRGB; LightIncomingRGB = ExplodingRGBlight - LightEscapingRGB; vec3 ExplodingRGBlight = LightIncoming * cosAvgReflAngle * MatDiffuseRGB; //Second iteration of our repeating cycle: LightEscapingRGB = ExplodingRGBlight * EscapeFraction; diffuseFactorRGBacc += LightEscapingRGB; LightIncomingRGB = ExplodingRGBlight - LightEscapingRGB; vec3 ExplodingRGBlight = LightIncoming * cosAvgReflAngle * MatDiffuseRGB; //.............................................. // repeat infinite times; then ... //.............................................. diffuseFactorRGB = diffuseFactorRGBacc; } The function getCosOfAvgReReflectionAngle( RefractiveIndex ) is the next problem to solve. What it represents is the cosine of the average angle to the normal for light reflecting back in. It is really a function of material refractivity alone, same as the escape cone. It is the cosine of half the complement of the cone of escape's radius. Time for some spreadsheet work... EDIT: Don't worry about the "repeat infinite times"; that's just rethorical. Once we get our per-cycle factor x, we have a case of f(x) = 1 + x + x^2 + x^3 + x^4 + ... which is a geometric series and solves as = 1/(1-x) for absolute values of x less than 1; or... f(x) = x + x^2 + x^3 + x^4 + ... = 1/(1-x) - 1;

Regarding my "productivity", that is a circular definition you're using. I come up with good work in the engine and you don't accept it. Does that constitute low productivity on my part? I come up with great shader mods, and they are not adopted for whatever reasons. Is that low productivity on my part? What I will take from your personal attack post is about hundreds of people working on this. I didn't know. But I've been trying to make things better, but I get no encouragement from ... the powers that be, and not much help, except from Stan. You guys would know how to give me the uniforms I need, but nobody offers to help; I'm left all alone to struggle with this. EDIT: Reminds me of one boss I had that kept asking me how long the software was going to take, and I kept telling him "I don't know; stop asking." One day, when I was almost finished, half way through testing, I told him "3 more weeks, pessimistically", and the next day he cancelled my development and put a new guy (who said he could do it in a week) to work on the project, from the beginning again. Then, 6 months later, when the project failed and he got sued by the client, he fired ME; not the new guy; and not himself... Circular definitions of productivity, or of success or failure. EDIT2: As far as your criticism that I ask for feedback and when I get it I react in some inappropriate way, I don't think feedback such as "I don't like get() and set()" functions is really "feedback", though you have a right to have preferences; and I don't think saying "I hate what your shader does to terrains" without any specifics can really be considered "feedback"; and even "your video is of terrible quality" (when in fact it looks exactly like my in-game screen" can seriously be considered "feedback". I have, AS A MATTER OF FACT, been "persecuted by a shadowy cabal".

EACH PATCH OF TERRAIN can customize its own shader?!?!?! OMG... That's it, I give up. This project is only open source in name. I mean, you can have a long chain of little decisions each of which can be justified; but if the end result is an incomprehensible mess, then the end result is an incomprehensible mess no matter how right all the intermediate arguments may be.

I can't find "actors" for terrains or maps anywhere in there. If I want to turn features on for Acropolis Bay, such as specular and normalmap, where would I go?

I thought actors were things like John Wayne. I'll have a look; thanks; but I'm afraid knowing this won't help terribly much trying to deal with all these #IF's, and won't bring me the uniforms I need.

And I can't understand, given I have my shader effects slider maxed out, I cannot understand why some variables declared inside #IF USE_SPECULAR are not getting defined, and such. I spend hours puzzling over each of these leg-traps; and if I succeed at solving them it is usually without understanding what I did to solve it. I'm falling into a bear-trap at every step, and the work takes forever like this.

I specially cannot work with such discrepancies between shaders as v_normal and v_lighting being vec4's in some shaders but vec3's in others. And I cannot work with them if I have to do engine work just to get a uniform in one shader that is available in another, such as a skybox.

Alright, I rest my case; but I just can't work with so many #IF's in the code.

I find this hard to believe to put it mildly. It was 20 years ago I was working full time on shaders, and people had texture lookup solutions for everything from Fresnel to Phong and whatnot, BECAUSE IT WAS CHEAPER than computing them, but every effort was put on trying to minimize the shaders, and minimize context switches. This would imply that we have regressed in terms of texture units... But you are using past tense... Are you talking BEFORE 20 years ago? Or did something really bad happen 10 years ago?

Gottcha. At fist I was assuming this was a slider for artists to use in Atlas or something. I still don't understand your earlier statement, though, namely, Does the slider setting really affect some materials differently from other materials, yes or no? Straight dope, please; this is the crucial thing. If some materials can dictate some parts of the shader to compile or not, differently from other materials, then we are back to Square Zero.

Wait: look at what you said. You implied that different materials produce different shaders.

Alright, then I'm not understanding anything. What slider is this?

Materials SHOULD NOT affect shaders. They SHOULD NOT cause different compilations of the same shader. It is a performance disaster to have shaders proliferate to each meet exactly a material's needs and nomore. The change from one shader to another, the "context switch", is a very expensive operation; equivalent to tens of thousands of polygons worth of rendering. It is insane to do that. There should be switches associated with graphics quality settings, but NOMORE. This business of having materials customize shaders is INSANE, both in terms of performance, in terms of complexity added to the art pipeline having to specify so many stupid things via xml files, in terms of code complexity ... and what is the advantage of it? Is there ANY? Is there any advantage in starving the shaders of input, so that trying to add a feature implies not only glsl work but engine work, to try to get the uniforms it should be getting but isn't? Ridiculous.

I'm exhausted working with this terrain_common.fs shader. I can't deal with the profusion of compile switches everywhere; this is insanity. You try to do one thing, this variable doesn't exist; try to do that, another variable doesn't exist. The normalmap, as I said, was only modulating diffuse; not specular. But it gets worse: The light on the bumps is computed separately, and added to the picture later. I did not want the light on the bumps; I wanted the normal to be modulated by the normal map, so then I can do my NdotL, EyedotN, HalfvecdotN, and use the modulated normal for all my calculations; but the code in this shader doesn't modulate the normal. So I tried to copy the code from the model_common.fs for modulating normal by normalmap; but the first part goes, vec3 bitangent = vec3(v_normal.w, v_tangent.w, v_lighting.w); float sign = v_tangent.w; mat3 tbn = mat3(v_tangent.xyz, bitangent * -sign, v_normal.xyz); but the v_normal and v_lighting uniforms in this shader are declared as a vec3's; there is no w part. And that's after commenting out pounds of bloody conditional compilation leg-traps. I hate to give up, but I'm at that point; this is impossible to work with. I would understand a couple of switches having to do with graphics settings; but why should there be a switch for whether to use specular, another for whether to use specular map, another for whether to use normal map ... Why would you NOT want to use these things? And then, if they only affected values, like #IF USE_NORMALMAP normal = modulate_normal(v_normal, normalmap); #ELSE normal = v_normal; #ENDIF Right? But let me have the variable normal; don't tell me I have to use v_normal in the code whenever normalmap is not being used. Well this is NOT the case with normal, but it is the case with tons of other variables that exist or not based on the bloody switches. It is insane! And why are are the shaders so different from each other? Why are v_normal and v_lighting vec4's in one shader but vec3's in another? And why don't all the shaders get all of the information? Why some shaders have access to the skybox, while other shaders are denied it? What is the value of hiding those datas? Is it such a big hit on performance to pass that information, that it necesitates being miserly with variables everywhere? This is unbearable to work with. Happens a lot in open source that people secretly feel ambivalent about openness, so they follow open source rules superficially, but write code in a "protective" way, anyways. There was a lot of that in Vegastrike, I remember very well... Of course, they do want help; but then they have to set up a culture of initiation, where they are going to "teach" people how to be as protective as them, the style, the secrets of what means what. So the whole thing becomes a private club or religion. Not saying categorically that's what's happening here, but I'm starting to suspect it. Slightly more than just starting...

SpaceX's own video is up already.

SUCCESS!!! IT DID IT! LANDED ON THE PAD AFTER FLYING UP 10KM. STANDING ON THE PAD, DOH!!! It blew up on the pad as I was typing this message... But anyways, HUUGE progress. The sky-diving + belly flop concept is proven to work now.

7 minutes ...

Live coverage here:

Me too. People ask me if I would go to Mars, myself. I say I'd buy a ONE WAY ticket any day.

I just had an idea for how to solve the problem of only having one channel for refractive index but needing separate RGB refractive indexes for many materials. The idea is to organize all materials from the available databases online into a big spreadsheet. Where two materials have the exact same refractive index, use the more commonly found in nature. Sort the spreadsheet by refractive index on the green channel. Then make a texture where the green channel increases linearly across and the red and blue channels represent deviation from the green x16, for better resolution. So, start by putting the red and blue channels all at zero, then for each known material along the green line write the red and blue to encode its deviation from green. And there will be many empty spaces in the end, as there are, for example, no known materials with refractive index of 1.1, or 1.2; they jump from. 1.05 to 1.25. Similarly, there's not too many materials of refractivity around 2, except boron nitride. So, for the empty spaces, might as well interpolate values between the nearest actual materials. The way this works is, the standard texture set specifies an exact refractive index. If it is 1.4603, we compute an offset into this texture and read the value, and it comes back (after scaling) as (1.4591,1.4603,1.4672). If instead the main texture specifies 1.5464, a lookup in this texture returns (1.545,1.5464,1.5544). The first is for fused quartz; the second is for natural quartz. A read of 1.77 will return (1.77,1.77,1.78), aluminium oxide. A read of 2.15 returns (2.05,2.15,2.3), the wildly steep refractive indices of chromium's most common oxide. And I know I was just ranting against the use of textures as lookup tables, but that is because I don't feel that a lookup is justified for functions that can be computed. But in the case of materials there's a lot to be said for having a lookup table for them ... Materials are as computable as phone-books.

Oh, I'm no SVN expert to do such things as reverting and cloning. First of all, reverting is out of the question for me because before I started hacking shaders I was doing a huge cleanup of the C++ sources, which got no appreciation from the powers that be, so it will be for myself; but in any case, it was not compiling at the time I put it in hiatus, and I intend to continue that work when I can. I keep resolving conflicts now and then as I svn up. But I would have to download a separate repo to be able to revert. What makes the mod incompatible with svn? Can't we fix the problem instead?

Hmmmm... I don't understand. Ambient light is just an (arbitrary) RGB color coming in, representing omnidirectional light. So, for a point on an object or terrain you compute, light = suncolor * dot(sundirection,normal) * getShadow(); light += ambient; light_reflecting_diffusely = diffuse_color * light; It doesn't affect sunlight.

Yes, I'm on SVN. I'll check out Delenda Est, thanks. Where do I find it? I just found another error in the current, official terrain_comon.fs: The normalmap only affects diffuse lighting; not specular. It's funny because normalmap is best shown in specular; that's where it really shines; but in this shader it is invisible to specularities. I'll fix that, of course; but this is generally how my shader set keeps getting closer to becoming a reference. All I'd have to do is remove metal detection, etc, and they would be far more of a reference than the official shaders. You might not think much of this bumpmapping gottcha, but chances are that you, as an artist, using the current shaders, might think your normal-mapping looks too subtle and strive to increase it. Once you see it through a shader that uses the normalmap in both diffuse and specular, however, it may look transdimensional. I also don't understand why is there parallax in so many of the shaders, but not in the terrain shader. And why there's no skybox. EDIT: Sorry, it was in your signature.

Can't wait. My only concern is what you guys use as a reference shader to know what the final work looks like. My shader set, I called it "PROHIBITED" in the video because it is supposedly NOT to be used as a reference shader for artists to use, precisely because of my metal and skin detections, and corrections of overbrightness. On the other hand, the current shaders aren't really much better, and in many ways worse than mine, in terms of lighting correctness. Case in point, I just discovered that terrains had no Light dot Normal modulation for sunlight. You can tell how high or low the Sun is by how the shadows project, but not by the brightness. The brightness is the same no matter if the sun is high above or near the horizon. So, now, what happens when I fix the problem and introduce modulation of brightness of ground by Sun angle? What happens is the grounds in maps not at noon will look darker. And everybody will blame my shaders for it. Right now there is no reference shader. NONE whatsoever. That's what I'm worried about.