DanW58

INTRO: To recap, the "psychic" shader is abandoned; it will never happen. During discussions in that thread, it was agreed that the way to go is to complete the eye-candy "metal detecting" shader (which now detects human skin, as well, and applies dielectric shimmer to it) and keep it as a better shader for existing art assets. This shader is now complete and ready for review and adoption. I include here how I described it in the D3555 update: The Next Shader last mentioned is the subject of this forum topic. New art assets will NOT need re-interpretation by the shader; no need for "detections" of materials; and it will embrace a more comprehensive texture stack capable of specifying all the important parameters needed to describe a material, such as metal/non-metal, metallic specularity in the case of a metal; index of refraction and surface purity in the case of a non-metal. We should also make sure that each channel has appropriate bit depth as per the criticality of its value accuracy or resolution. For example, specular power, in my experience, is a parameter well worth of its own texture channel, and it needs good resolution, as our eyes are quite sensitive to subtle changes in specular power across a surface. Other channels are less critical, such as rgb diffuse color. Another goal I'm setting for myself, with the new shader(s) is to reduce their number by making them capable of serving all the needs provided by a multitude of shaders presently. Another goal of mine is to get rid of as many conditional compilation switches from the shaders, with the following criteria: Conditional compilation is okay to have when it pertains to user settings in graphics options, which are settings affecting all materials generally. Conditional compilation is NOT okay to change compilation per-object or per-draw call, based on object parameters. Why? For one thing, the confusing rats' nest of switches in the shader becomes intractable. For another, it is effectively changing the shader from one call to the next, causing shader reloads, which are expensive in terms of performance. My tentative ambition is to produce two shaders: one for solids, and one for transparencies (excluding water; the current water shader is beautiful; I mean "glass" literally). SHADER CAPABILITIES (FOR ARTISTS): Without getting too technical, the "Next Shader" we call it for now, will be able to depict a wide range of materials realistically. If you want a vase made of terracotta, there will be a way to produce a terracotta look. If you want a simple paint, or a high gloss paint, or a painted surface with a clear varnish on top, you will be able to specify that exactly. The look of glossy plant leaves, the natural sheen of human skin in the sun, all of these will be distinctly representable. Cotton clothes, silk clothes, leather, granite... And there will be a huge library of materials that all artists can draw from, so that all artists are working on an equal footing vis a vis, for example, the albedo of the the assets produced. For an example of where albedo is not consistent, at present, Ptolemaic women have a good skin tone, but Greek and Roman women's skins are so white they saturate when they are in the sun, even as other assets look too dark. This kind of inconsistency will be avoided. You may notice I have not mentioned metals. The reason for that is that metals CAN be represented correctly by the current shaders using diffuse and specular colors, but hardly a soul on this planet knows how to do it right. So metallic representation will not be a "new" capability, per se; but inclusion of most metals in the materials library will be. And the most important feature of this shader is that it will be physics- and optics-based; not a bunch of manually adjusted steampunk data pipes and hacks. However, it is important to state what it will NOT be capable of: Although it will try to have some clever tricks to achieve things like specular occlusion (reflections of objects blocking the environment), it is not intended to be a ray-tracing shader. It will NOT use auto-updating environment boxes with moving ground reflections or anything of the sort. There's better things to spend GPU cycles on. The ground reflection will just be a flat color. It will NOT feature sub-surface scattering. Too expensive, and there are some cheap hacks that can be made to look almost like SSS. It will NOT feature second light bounces. Too expensive for what it's worth. It will NOT include things like hair or other complex material-specific shading. It will NOT support anisotropic filtering. Vynil records had not been invented yet, in the first century, anyways Possible new features: Not only shadows (as the present shader does) but also environmental shadowing (this may need props). Detail textures: These are textures that typically contain tile-able noise, and which are mapped to repeat over large surfaces, such as a map, modulating the diffuse texture, or the normalmap, or the AO, at a very low gain, almost unnoticeable, but make it seem like the textures used are of much greater resolution than they are. That's why they are called "detail textures; they would seem to "add detail". Very effective trick, but they need to have their gain modulated from the main texture via a texture channel, otherwise their monotony can make them noticeable. Long story. Possible test version of the shader, for artists, that detects impossible or unlikely material representations and shows them red or purple on the screen. Possibly have HDR... One thing this shader will NOT indulge on: Screen-space ambient occlusion. These are algorithms that produce a fake hint of ambient occlusion by iterative screen-space blurs of Z depth -tricks. They are HACKS. In my next post I will discuss texture packing, and give a few random examples for how materials will be represented. OTHER... I paste below a couple of posts from the "psychic" shader as a way of not losing them, as they are relevant here: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Problem Number 1: One issue that I seem to be the only guy in the world to ever have pondered, is the fact that the Sun is NOT a point-source; it has a size. I don't mean the real size, but the apparent size: its diameter, in degrees. If we were on Mercury, it would be 1.4 degrees. From Venus, (if you could see through the darned clouds), it would be 0.8 deg. From Mars it looks a tiny 0.4 degrees diameter. From Earth: 0.53 degrees. This should be taken into account in Phong specular shading. The Phong light spot distribution (which is a hack; it is NOT physics-based) is (R dot V)^n, where R is the reflection vector, V is the view vector, the dot operation yields the cosine of the angle between them, and n is the specular power of the surface, where 5 is very rough, 50 is kind of egg-shell, and 500 is pretty smooth. Given an angle between between our eye vector and the ray of light reflecting from the spot we are looking at, if the alignment is perfect, the cosine of 0 degrees is 1, and so we see maximal reflection. If the angle is not zero, but it is small, say 1 degree, the cosine of 1 degree is 0.9998477, a very small decrement from 1.0, but if the specular power of the material finish is 1000 (very polished), the reflection at 1 degree will fall by 14% from the 0 degree spot-on. But with a perfect mirror, --a spec-power of infinity--, a 1 degree deviation (or any deviation at all) causes the reflected light to fall to zero. But that is assuming a point-source light... If what is reflecting off a surface is not a point source, however, the minimum specular highlight spot size is the size of our light source. This can be modeled by limiting our specular power to the power that would produce that same spot size from a point source. But this limiting should be smooth; not sharp... Problem Number 2: This is horrendous graphical mistake I keep seeing again and again: As the specular power of a surface finish varies, specular spotlights change in size, and that is correct; but the intensity of the light should vary with the inverse of the spotlight's size in terms of solid angle. If the reflected light is not so modulated, it means that a rough surface reflects more light (more Watts or Candelas) than a smooth surface, all other things being the same, which is absurd. As the specular spots get bigger, they should get dimmer; as they get smaller, they should get brighter. But the question will immediately come up: "Won't that cause saturation for small spot-lights?" The answer is yes, of course it may. So what? That's not the problem of the optics algorithm; it is a hardware limitation, and there are many ways to deal with it... You can take a saturated, super-bright reflection of the sun off a sword, and spread it around the screen like a lens-flare; you can dim the whole screen to simulate your own temporary blindness... Whatever we do, it is an after-processing; it is not the business of the rendering pipeline to take care of hardware limitations. Our light model is linear, as it should be, and as physics-based as we can get away with. If a light value is 100 times greater than the screen can display, so be it! Looking at the reflection of the sun off a chromed, smooth surface is not much less bright than looking at the sun directly. Of course it cannot be represented. Again, so what?! So the question is, how much should we set the brightness multiplier as specular power goes up? And also, at what specular power should the brightness multiplier be 1? Research: The two problems have a common underlying problem, namely, finding formulas that relate specular powers to spot sizes, where the latter need to be expressed in terms of conical half-angle and solid angle. If we define the "size" of a specular highlight as the angle at which the reflection's intensity falls by 50%, then for spec power = 1, using Phong shading, (R dot V)^n, the angle is where R dot V falls to 0.5. R dot V is the cosine of the angle, so the angle is, SpotlightRadius(power=1) = arccos( 0.5 ) = 60 degrees. Note that the distribution is equivalent to diffuse shading, except that diffuse shading falls to half intensity at 60 degrees from the spot where the surface normal and the light vector align, whereas a specular power of 1 spotlight falls to half intensity at 60 degrees from the mid vector between the light and view vectors, to the surface normal. But the overall distributions are equivalent. We can right away answer one of our questions above, and say that, Specular power of 1.0 should have a light adjustment multiplier of 1.0 How this multiplier should increase with specular power is yet to be found... But so, to continue, what should be our formula for spotlight radius as a function of specular power? For a perfectly reflective material, Ispec/Iincident = (R dot V)^n If we care about the 50% fall-off point, we can write, 0.5 = (R dot V)^n (R dot V) = 0.5^(1/n) So our spot size, in radians radius terms SpotRadius = arccos( 0.5^(1/n) ) We are making progress! Now, specular power to solid angle: Measured in steradians, the formula for solid angle from cone half-angle (radial angle) is, omega = 2pi * (1 - cos(tetha)) But there are 2pi steradians in a hemisphere, so, measured in hemispheres, the formula becomes, omega = 1 - cos(tetha) If we substitute our spot radius formula above, we get omega = 1 - cos( arccos( 0.5^(1/n) ) ) which simplifies to, SpotSizeInHemispheres = 1 - 0.5^(1/n) where n is the specular power. Now we are REALLY making progress... Our adjustment factor for specular spotlights should be inversely proportional to the solid angle of the spots, so, AdjFactor = k * 1 / ( 1 - 0.5^(1/n) ) with a k to be determined such that AdjFactor is 1 when spec power is 1. What does our right-hand side yield at power 1? 1/1 = 1. 0.5^1 = 0.5. 1 - 0.5 = 0.5. 1/0.5 = 2. So k needs to be 0.5 So, our final formula is, BrightnessAdjustmentFactor = 0.5 / ( 1 - 0.5^(1/n) ) where n is specular power. Almost done. One final magic ring we need to find is what is the shininess equivalent for the Sun's apparent size. We know that its apparent diameter is 0.53 degrees. So, its apparent radius is 0.265 degrees. Multiply by pi/180 and... SunApparentRadius = 0.004625 radians Good to know, but we need a formula to translate that into a shininess equivalent. Well, we just need to flip our second formula around. We said, SpotRadius(radians) = arccos( 0.5^(1/n) ) so, cos( SpotRadius ) = 0.5^(1/n) ln( cos(SpotRadius) ) = ln( 0.5^(1/n) ) ln( cos(SpotRadius) ) = (1/n) * ln( 0.5 ) n = ln( 0.5 ) / ln( cos(SpotRadius) ) Plugging in our value, ln( 0.5 ) = -0.69314718 cos( 0.004625 radians ) = 0.99998930471 ln( cos( 0.004625 radians ) ) = -1.0695347 E-5 Finally, SunSizeSpecPwrEquiv = 64808 ... (make that 65k ) So, we really don't need to be concerned, except for ridiculously high spec power surfaces; but it's good to know, finally. EDIT: Just so you know, when I worked on this, decades ago, I obviously made a huge math error somewhere, and I ended up with a Sun size derived specular power limitation to about 70 I think it was. I smooth-limited incoming specular power by computing n = n*70/(n+70). I knew it was wrong; the spotlights on flat surfaces were huge. What was cool about it was the perfect circular shape of those highlights. It was like looking at a reflection of the Sun, literally; except that it was so big it looked like I was looking at this reflection through a telescope. EDIT2: One thing to notice here is the absurd non-linearity of the relevance of spec power; maybe we should consider encoding the inverse of the square root of spec power, instead. This way we have a way to express infinite (perfect surface; what's wrong with that?) by writing 0. We can express the maximum shimmery surface as 1, to get power 1. At 0.5 we get 4. At 0.1 we get 100. We could even encode fourth root of 1/n. Edited Sunday at 09:39 by DanW58 @hyperion Another way to go about it, that you might care to consider, is to incorporate this shader now (if it works with all existing assets), but to also include a new shader with NO metal detection, and encourage artists to target the new shader. Different texture stack, channels for spec power, index of refraction and detail texture modulation, etc. So this shader and the new one would be totally incompatible, textures-wise, and even uniforms-wise. This path removes the concern about people getting unexpected results with new models. New models would NOT target the metal detection shader. It would be against the law. I could come up with the new shader in a couple of days; I got most of the code already. So, even if there are no assets using them, people can start targetting it before version 25. In this case, I'd cancel the "psychic" shader project. Channels needed for a Good shader: Specular texture: rgba with 8-bit alpha specular red specular green specular blue specular_power (1 to infinity, encoded as fourth root of 1/spec_power)is_metal Diffuse texture: rgba with 1-bit alpha (rgb encoding <metals> / <non-metals>) diffuse red / purity_of_surface ((0.9 means 10% of surface is diffuse particles exposed, for plastics)) diffuse green / index_of_refraction (0~4 range) ((1~4, really, but reserve 0 for metals)) diffuse blue / detail_texture_modulator is_metal Normalmap: rgb(a) u v w optional height, for parallax Getting Blender to produce them should be no issue. Note that I've inverted the first and second textures, specular first, with the diffuse becoming optional... For metals, the first texture alone would suffice, as diffuse can be calculated from specular color in the shader. Artists who want to depict dirt or rust on the metal, they can provide the diffuse texture, of course; but in the absence of diffuse the shader would treat specular as metal color and auto the diffuse. Also, when providing diffuse texture for a metal, it could be understood to blend with autogenerated metallic diffuse; so you only need to paint a bit of rust here, a bit of green mold there, on a black background, and the shader will replace black with metal diffuse color.

The patch has arrived. Roof brilliance artifact is about 90% removed. Patch diffed from the /binaries folder. I call it "prohibited" because the intent of this patch is to make the best of existing art assets, but is to be discouraged as a target shader for new art. EDIT: Rather than submitting a new patch to Phabricator, I updated my previous patch, D3555. https://code.wildfiregames.com/D3555

I have good news, I was able to improve skin detection to exclude roofs. In the pic below, white means is_skin(), black means it is not. Just when I thought the shader was finished... Tonight's patch will fix the roofs.

Thanks. Just to be pedantic, the specular effect on the roofs is the opposite of metallic; it is the addition of Fresnel specularity that results from detecting skin for Fresnel purposes, so what the roofs suffer from is more like a varnish, or clear epoxy coat. But I don't like it either ;-) But OTOH I love to see gloss on human skins; and can't distinguish roofs from skins. Actually, I haven't looked at specular; maybe there's a way... By the way, sorry for the delay coming up with a patch; I wanted to do an svn up first, and I got a nasty conflict I'm trying to resolve. It will be in by tonight, though.

Cool project; I many times asked for something of the sort from the Vegastrike devs. Should take no time at all to come up with a patch... I'll be back...

Gone. Took me about 20 seconds It was hard to notice, anyways. model_common.fs model_common.vs terrain_common.fs

Gentlemen, I declare this shader finished. I wanted to put the skybox fetch, but I don't know how to pass the info to the shader. I copied the code from the water shader, and so it should work, but it is not getting the skybox and the rotation; and my C++ sources are nowhere near compiling state; I interrupted the engine work I was doing to work on shaders; and I no longer remember where I was at. In any case, the sky box was not going to help much, unless it has LOD's to bias into, to control blurriness of reflections. Then there is the green-detection hack, which should have worked but this common_model shader does not seem to have jurisdiction over too much foliage, apparently. I don't know what shader does the trees and stuff. So I removed the green hack, and the skybox; all I have is metals blue dresses human skin And that's it. It works. It does have a few bugs I cannot resolve, like the fact that roofs often acquire glossy varnish as the skin detection hack gets confused by the similar color to skin. Overall, though, it's darned good. What makes it so good is the correctness. Even down to the detail that specular highlights look brighter the smaller they are; this is something I have NEVER seen anybody else take into account. The Fresnel calculation is based on Schlick's approximation, which is a science level approximation; not some cheap graphics hack. The lack of skybox is not an issue at all, in my opinion. The reflective items are small and curvy; you don't have big mirrors here; it's not like the water, where you need to see clouds reflected. This is small objects like pots or helmets reflecting; a sky-biased ambient light is plenty good for that, specially WITH self-occlusion and ground occlusion hacks. And we got variations in dielectric constant and in shininess, albeit all ad-hoc values, like 1.5 index of refraction for skin, versus 1.0 for everything else. Specular power I take over a lot of the time, increasing it for metals, decreasing it for non-metals, setting it to 17.0 for skin, and to 2.0 for blue dresses. That's nowhere nearly as good as being able to specify these things via texture channels, of course; but that's the next shader. So I invite you all to try it, discuss it, give me feedback, so we can finalize this and move to the the big one. You need to apply a patch first, then replace the shaders attached below. The patch is attached to this post here: And you may also have to add a line to your config for gpu_skinning for the ao to work, I'm not sure because according to Stan it should make no difference, but if that's not what made the difference for me seeing the ao's in game, I don't know what did. model_common.fs model_common.vs terrain_common.fs

@Stan` This is the brightest I can go while still seeing sunshine glow on the women's arms. It is actually quite a bit brighter than before the gamma fiasco. If that's not bright enough for you, here's the deal: make human skin a bit darker, so that it doesn't saturate in the sunshine, and I'll give you more light. Deal? I'm trying to get the skybox to work...

Now I've removed all of the gamma stuff; put back the detection hacks to what they were before, and I still can't get rid of saturating white arms. Why can't I get back to how it was before? This is too frustrating. Anyways, detecting metals was trivial compared to detecting human skin here; there is just no way of telling skin from roof, wall or piece of wood, or a rock. If I give skin a sheen, everything gets a sheen. It looks like I'm hitting the limit of what this shader can do. I mean, I could add a green detector for plants; that would be a lot easier. And I could use the sky box as environment map; but it is probably not an LOD texture that I can bias the fetch to get blurry reflections; and without control of blurriness of reflections, environment mapping is a joke. Could try it anyways...

@Stan` No; this is not working. I think the problem is that human skin is painted too light; almost white. Obviously, if I don't want to see saturation with an item that's too light, I have to darken everything too much. It's a hard choice. See the trees too dark?, or see the women's arms saturatingly white? I'd rather make the trees dark. Human skin should be darker in diffuse. It is lightened up by the sheen of our epidermis index of refraction, and my shader will give you that; but the diffuse tone needs to be darker, otherwise I'm adding white sheen to white base. But actually, some of the people models have proper skin colors; I think the Romans are one of the few that don't. I'll put this bad example belolw, then go looking for which are the civs with good skins, see how this gamma thing works with them.

This is better. Still too bright for my taste, but at least I can see gradients of color on skin; not just saturated white. And of course I don't fail to notice the tiled roof of the house saturating, but that's due to unwanted gloss added to the tiles due to the skin detection hack which can't avoid detecting buildings as skin; --almost the same color in diffuse.

Actually no; it is way too bright. Now I can't see the sheen on arms of the women like I did before. The arms are already so close to white that sheen saturates. There's a golden rule about brightness: No part of a scene should saturate unless it is a sharp metallic sun reflection. I'm going to tone down this gamma thing until I can see the sun's reflections on skin again.

And as a result of making it more correct, not less. So, no argument here. For my taste, I'd lower ambient quite a bit, though. But I'm happy in general, particularly with having got metal AND non-metallic specularities to work. The rest is a mop-up operation. EDIT: Almost forgot. Here's the current shaders: model_common.fs model_common.vs terrain_common.fs

So, here's a bunch of screenshots of the gamma-aware correction that brightened everything ... Using the squares of the colors from the textures broke both my metal detection and skin detection hacks. I had to adjust all my coefficients to get them to work again. In the last picture, Romans, the metallic looking ornaments on the columns, I don't think they are metal detection, but rather fresnel put on them, sort of like varnish... "skin detection".

LOL @Stan` I think you'll be happier than me about this: I just implemented gamma awareness, and it got brighter.

It's just right. If you want more light, make the sun brighter, or increase ambient. I don't have any hacks to alter the physics or the optics; it is what it is, according to the lights and the materials; no more; no less. It just follows physics and optics. Users have brightness AND contrast controls on their monitors; so do I; so do you. How do we know that our controls are all adjusted exactly the same? This is a subject we should explore, like how bright or dark should it be shipped, so that it doesn't fall out of the range of users' adjustments. One thing I would hate, though, is in-game brightness controls, before anybody asks; because then you run into the trouble of "should I increase the game's brightness?, or my monitors?, or my videocard's? Too many adjustments in a long chain. It's like if you are a musician, and you got 5 effects pedals, each having a gain pot, followed by the amplifier's gain; and you also have a volume pot on your guitar or bass; you end up with like 10 volume pots, and you don't know which needs adjustment. Let me ask you another thing, though: In the real world, would you go about complaining it is too dark or too bright? I mean, today we would, because we have electric lighting we can control. But in the real world it happens often you're near a building at dusk, and the building looks super bright with golden radiance; and the rest of the place looks rather dark. No? Why should it be different in-game? Obviously I'm not alone feeling like this way, as someone created an Acropolis at Night map, designed to be dark; --even challengingly dark. I played that map several times. As a gamer I enjoy realism far more than I do unrequested catering to my incorrectly presumed preferences. If you want to know how it all got darker than before, well, part of that is that a lot of the stuff has bright specular textures, most of which I'm suppressing. The ambient occlusions were not being used in many cases, and where they were used, their gain was turned down to as low as 0.6 for no reason whatsoever (in those xml files); and then the shader was multiplying the ao's by 2.0, also for no reason whatsoever. Last but not least, some of the grounds had bright specular textures, causing the color of the ground to go to saturation. Once I turned off specular in the terrain shader, the diffuse textures, specially the Acropolis map, were still too bright, so I worked at detecting grayscale color (in the terrain shader) and dimming it while increasing contrast, and lo and behold, I discovered for the first time that the ground in the Acropolis map had nice square tiles. I had never known that before. The same goes for some of the stone paths, like in the Badlands, and Belgian Bog; now they can really be appreciated in their full beauty; before they were just whitish blurs. So yes, if you try to go brighter than monitors can display, you lose a lot of detail :-) You might care to sue Samsung rather than blame me. So right now everything is right, by physics and optics. The way to increase light is by cranking up the light, if that's what you want; but it looks good to my eyes. I want to see contrasts. I want to see bright sun reflections contrasting with darker surrounding objects. If you make everything be as bright as to be in the goldilocks of visual perception, you lose realism and beauty overall; it all becomes a cheap arcade. You might as well ask Goya why his paintings were so dark. Well, he was showing realities that other painters were ignoring. The question is, does it look real? Forget about passing judgement on how bright or dark it should be; does it look real? Having said all that, I do enjoy direct sunlight, in the VERY FEW maps that feature it. In the pictures I just posted, only the first one shows some hint of nice rays; the rest are all ambient light based, which is boring as hell. More maps should be like Belgian Bog and Oceanside. Beautiful suns... Ambient light should be reduced in most maps; it is so bright it doesn't let you appreciate the sunlight; and it reduces the visibility of shadows, which are important for 3D perception. EDIT: Speaking of brighness and contrast, I just remembered an issue we worked on at Vegastrike, namely "gamma awareness", which is a rather obscure subject... Monitors, for the longest time, have been very non-linear devices, and it's been customary to this day to compensate for the nonlinearity in the color values of assets and textures. The theory is long to explain, but in practical terms, what it boils down to is that when a shader reads any textures, it should immediately square the value, to convert from standard texture gamma to linear space. Once all the light computations are done, and the shader is about to output the final color for the pixel, it should take the square root first, then output, so as to go back to display device gamma space. I'm going to try this tomorrow. I mean today... 4 AM !!!

Here's more screenshots. Keep looking at specular highlights on metals and skin. Opposite ends of the spectrum. The potted plants in the Persian CC, I believe they got a bit of Fresnel by accident. They will give you an idea of how I want plant leaves to look like, shiny; though I did not intend it yet. Tiled roofs and cobblestone grounds are getting Fresnel also, leaking from my skin detection hack, so they look like varnished... This will not happen with the final shader, where a texture channel clearly says "this is a metal", and if it says it is a non-metal, another channel says "this has Index of Refraction such and so". Right now it is very difficult to have the shader isolate items on the basis of their color alone. Heck, even the palm trees behind the Persian cc have Fresnel gloss...

Thanks; I'm just putting together a few more screenshots. Tomorrow I'll tackle using the skybox as enviromap. This is HUGE, though. Even though as wraitii pointed out, there aren't a lot of metallic objects, the whole point is that the few there are really look like metal. And then with Fresnel for non-metals we can show the natural shine of human skin and plant leafs. Even if it is a few tiny places in a given scene, it is soooo refreshing to see them well represented, instead of everything looking like plastic dolls and toys. This also goes with the water. The water in this game is exquisitely well portrayed; and terrains too; but then it makes a stark contrast to see most materials look like cheap plastic. Getting masonry to look like masonry, metal look like metal, paint look like paint, and human skin that glows in the sun; these are tremendous contributions to realism and immersion.

Is that something I should remember or try to believe? Well, I've been forced to move dozens and dozens of things out of conditionals, or else it won't work. One asset denies me having a normal; another denies me the half-vector, another denies me the view vector... I can't see the USE of denying information to the shader. If the shader doesn't use it, nobody hurts; but trying to get something done and having problem after problem after problem, THAT hurts. Anyways, I'm making some progress now. Look at this picture, and look at those women's arms... See the whitish specularities? That is natural skin Fresnel sheen, my friend. The opposite end of the spectrum, vis a vis metals. Now we got the full range of materials. Too many hacks, though; I wrote a skin detection hack, but it detects parts of the building as being human skin, so the sheen is applied to some of the trim... I also wrote a blue dress detection hack that makes their dresses a bit shinier.

There's WAAAY too many options and conditionals in the shaders; it is an incomprehensible rats' nest. I mean, if something does not need a normalmap, just give it one texel normalmap. If something doesn't need a specular texture, just give it a single black texel specular. What is the need to have compiler switches everywhere, gazillions of different shaders...?

I need help. I don't understand what's going on. I have simple code to detect whether the reflected view vector hits the ground. float vector_hits_the_ground( vec3 vector, float specpwr ) { float blur = 0.5/(specpwr+1.0); return smoothstep( -blur, +blur, -vector.y ); } .................................................................. vec3 refl_view = -reflect( eyeVec, normal ); float reflecting_ground = vector_hits_the_ground(refl_view, 10.0*specPow); ................................................................. #define TEST //#define A_COLOR #ifndef TEST gl_FragColor.rgb = color; #else #ifndef A_COLOR //float temp = is_metal; //float temp = 1.0-normal_hits_the_ground; float temp = 1.0-reflecting_ground; /// <<<<<<<<<<<<<<<<<<<<<<<<<----- gl_FragColor.rgb = vec3(temp,temp,temp); #else //vec3 temp = specCol; vec3 temp = texdiffuse; gl_FragColor.rgb = temp; #endif #endif You don't need to understand the code though... My question is: How in the world could it be working just fine for the building and the trees, BUT NOT for the obelisks, or the people, or the camel? My first reaction would be, some of the items lack normals... But I have another test for whether normals hit the ground, and that test works fine for the entire scene! I'm dumbfounded... EDIT: Adding a screenshot of displaying normal orientations (Y projections) from black (pointing down) to white (pointing up); thus, the terraces are white. As you can see, the normals are perfectly normal. So why in the world reflecting the view vector should work differently for different assets? Do some assets mess with, or disable, the view vector through compilation switches? One thing I notice is that the parts of the civic center that don't work are the obelisks and the lions, both of which I noticed were packed inside the civic center, in the mesh. Are they being moved from inside the building to outside without regard for the normals moving or rotating or scaling with them? And what's with the women? But the thing is, the second picture shows that the normals are fine. I don't understand... EDIT2: Another screenshot: sky-biased ambient multiplied by ambient occlusion. The obelisks seem to have no ao bake; but otherwise this looks fine. EDIT3: Another screenshot: This is the Y projection of my reflected view vector; obviously not working for the people, lions, camels or obelisks, but working fine for the building... Why?!!! EDIT4: Okay, here's a hint: See the last pic with a green building? What I'm displaying is the view vector: vec3 temp = vec3(0.5)*(vec3(1)+eyeVec); gl_FragColor.rgb = temp; The bit of math is to fit the range, as the view vector spans -1 to +1, while colors span 0 to 1. Anyways, I would expect the view vector to change slowly across the screen in x and y, and to display for all assets. However the problematic assets show black. I can't imagine how... But that's it, if there is no view vector, how could I get the reflection of the view vector? My worst fears are confirmed; some of the assets are able to destroy view vector info through evil options! EDIT5: View problem fixed. The very creation of the v_eyeView vector in the vertex shader was buried in bloody conditionals; I took it out of the conditional morass, and it worked. Can anyone explain to me why the use of parallax is a necessary condition for there being a view vector? EDIT6: Much better... EDIT7: ReflectingGND() now works as it should.

You are right; specular reflectors are few and far between; but that is precisely what makes them catch the eye. A metallic little pot here, a helmet there and a shield is all you need, and it adds a TON of realism and depth to the entire scene. EDIT: And you probably have never seen what a bit of Fresnel can do for paints, skin and plant leaves. EDIT2: And you've definitely not seen what spec power modulation PLUS fresnel can do for wood representation.

Yes, I just realized how dumb I am. Yes; I will. I will do this soon; I want to finish this shader first, and then I will start removing all the hacks, settle on a new texture stack with hyperion or whoever, and partner with an artist to demo the new capabilities.

Okay, if they are modifications done on top of model.fs, that's even more evidence for my argument that they can be (and should be) incorporated into model_common.fs. I don't understand the question. EDIT: Do you meant there IS a skybox? EDIT2: darn! Of course there is; how would the water work otherwise?

@wowgetoffyourcellphone In that screenshot I see no specularity whatsoever. But that is not surprising, because the only specularity present in the official shaders right now is sun reflections. And the sun cannot reflect off building walls if we are looking down on them. If you were to turn the camera so that the sun is on the other side of those roofs, however, I bet you'd see a ton of reflected light. But to get back to the problem, you will soon, even if I were to leave, you will soon have environment mapping. It is mandatory; no game can NOT have enviromap for very long. Environment mapping is when you have a "sky box" or "environment box" or "environment spheremap" and the shader computes the reflection off of every point on the surface of objects, fetching what point in the sky-box they are reflecting, and show that as the specular part of the color. Once you do that, you will see clouds and whatnot reflecting off everything as if everything was wrapped in heat-shrink clear plastic. And it WILL look ridiculous. Right now, the lack of environment mapping is shielding you from seeing the problem. In my experimental shader, I don't have environment mapping yet, as there are no environment maps yet in the game, that I know of; but I implemented a little hack: I used the AmbientColor, as the sky to reflect, and I compute a rough specular occlusion to limit the reflection boundaries, and I implement a ground intercept, to reflect ground color when the reflection goes downwards. And with this simple hack I already see problems on building walls reflecting the ground, which they shouldn't. In other words, there is no specularity to speak of in the game yet; that's why the problem of excessive specularity doesn't become apparent. The worst part is that when a shader tries to implement environment mapping, everybody is going to jump and blame the shader for looking like crap... EDIT: Which brings me again to the same conclusion that this shader I'm working on will have to become the legacy shader, and future art will have to target a new shader without hacks, so that the art, the materials, will be tested on the right shader, and be right. So what I'm doing now with this shader is to either detect metallic specularity and improve it, or else turn it off completely. It is the best I can do to enable pseudo-environment-mapping eye-candy without running into problems with excessive specularity everywhere. It is the best way to support existing assets. The next shader, though, should not support existing assets as they are, but as they should be. Walls should be black in specular; not gray; and the same goes for women's dresses; unless they are Hollywood star dresses full of metallic stuff... But if they are they should indicate a specular power of like 2.0... super low! Otherwise they will all look like the "liquid metal" terminator from the movie, once environment mapping is enabled.