DanW58

Ahhhh, darn. Well, what I did was take out v_normal from the conditional, as otherwise I had no normal to work with. I'll just make the vertex shader write it. What are the "white space errors"? EDIT: This third (vertex) shader should solve the first problem: model_common.vs model_common.fs terrain_common.fs

You notice the difference more in-game; elephants look more real; everything looks more real. The only problem is that it makes the lack of ambient shadowing more noticeable. But I guess every unit would have to include a prop for terrain shadowing, to do that... Here are the files with the loss of ambient brightness problem fixed: EDIT: Tried it with four different maps. The only map that has a bit of a problem with it is the Acropolis, in the sense that the ground is too white to begin with, and it gets even whiter with skyward bias. I point out this is an artistic problem, in the sense that no ground could be as white as that even if we tried to. The best telescope mirrors reflect only 92% of the light or so. Diffuse materials reflect less by their very nature. Just because it is possible to make a ground almost pure white doesn't mean it is correct. And I'm willing to bet that the diffuse and specular add to more than white... I'd be willing to fix that texture, rather than tweak the sky bias formula. For those wanting to try it, throw these files into your ~/0ad/binaries/data/mods/public/shaders/glsl folder. To change back, you can go to the folder and type svn revert <name of the file>. model_common.fs terrain_common.fs

Here it is: Old on top, new at bottom; notice the increased contrast between ground facing and upward facing surfaces. It is subtle, but this is how you get to high realism; one subtle improvement at a time. Some places to look at are the stairs, see how the vertical planes look a bit darker; and those spherical lingams left and right, showing more contrast between the down-facing and up-facing parts. Half way between the horse and the elephant, the wide edge of the curvey wall also shows more contrast. And you might say, "we can increase contrast with a filter"; yes, but this adds contrast where it matters more to 3D shape perception. The only flaw I now see is that I darkened ambient light slightly over-all, but I can fix that easily. Though I admit this is a hack that will work 99% of the time in open grounds; not for my space game; not for interiors; but for 2 lines of glsl code I think it is worth it in lieu of a more general approach to lighting. model_common_new.fs terrain_common_new.fs

Ouch! Intel GPU owners should be sent to labor camps on the moon, though. Well, when I was stuck with XP, Blender did not go out of their way to support me; they just said go back to 2.73 or whatever it was...

Hmmmm... How do you know the comment is snarky? I'd probably say the same thing without snarkiness. As an artist I used to hate to have to set thing I had no idea how to set properly, such as ambient light or specular power, and various others.

Don't worry, Stan, I've short fuse sensitivities, but I know you're a good guy. But seriously, "take artistic freedom away" just because I'd remove an absurd parameter? Most artists are not as unreasonable as to say "I want my model to ALWAYS be seen in this light, regardless of lighting conditions!"

Hahaha, older than 20 years? That's how long ago I achieved realism like you still don't see nowadays. And even then I didn't have the latest videocard... Just to give you an idea of what I was able to do: You know when car manufacturers mix metal and plastic parts, and they try to match the color and the specularity, but you can still tell the difference between the plastic and the paint? With my shaders I could represent that difference. Even exaggerate it, if I wanted to. Yes, the primitive normal is what I'm looking for. Both normal and v_normal are declared inside conditionals. Looking for the normal that always comes in.

Bah, sorry; I forgot here you use a separate mapping for AO. But that's even better, you can use diffuse alpha channel to distinguish between metals and dielectric materials. Of course, it would have to ship with simple tools to convert from existing stack, but that's writable in a day. EDIT, by "glossiness and roughness are the same thing" I mean the microbumpiness.. If by glossiness you mean the index of refraction, that could also be conveyed by the diffuse alpha channel. Above 75%, say, means metallic. 0~50% encodes dielectric constant. EDIT2: By now I have looked at all of the fragment shaders, and I'm still confused. It seems to me if particular effects such as bumpmapping are not on, then there is no normal to work with!! Isn't there an interpolated normal coming in, regardless of effects?

Okay, that stack looks reasonable. It can still be optimized. Alpha, for example, is useless 99.999% of the time; worth having a separate shader for things like windows, as they require fresnel anyways. So, use the alpha channels of diffuse and specular for ao and roughness respectively. The system I co-authored 20 years ago had 3 textures, not 5: Diffuse (RGB) + ao (A) Specular color (RGB) + roughness (A) Glossiness and roughness are the same thing. The distinction between using metallic specularity (colored, unmodulated), and non-metallic specularity (white, Fresnel modulated) was deduced per fragment by the shader, based on the diffuse and specular textures. If diffuse and specular agreed more or less in hue and saturation, it applied metallic reflectivity; but if the saturation of the specular color was far less than that of the diffuse color, it went for a plastic to paint reflectivity. The third texture was for detail texturing.

Alright, gottcha. LOL, we are brothers in pain, then. What's PBR? Oh, physics based rendering. Well, if by that you mean that system that uses like nine texture layers to describe a material, none of that is necessary to have a pretty good looking rendering pipeline. Just a bit of common sense here and there adds up over time, such as not having separate ambients for units... (OMG!)...

Yes; it might also be INCORRECT.

Guys, I sense nothing but resistance to ANYTHING I want to help improve, no matter how obviously adventageous. Is there any point whatsoever for me sticking around here? I'm accused of trying to take away artistic freedom... Heck, I was an artist before I became a programmer, and as an artist being told I have to set a color for ambient light which I don't know what it should be might not be what I consider "freedom". And how does my proposition require "a lot of artist work"?!?!?! What? Where? I was merely suggesting that the engine compute ambien light color from the environment map, by averaging it. How does that increase the workload of artists? The resistance and hostility to any changes whatsoever around here are off the charts!

Thanks! That gives me something to chew on. Re... That might happen only case you have no directional light. But a usual scene has a sun (or something like that), which light is pretty well scattered and lightens different areas. I do take directional light into account. What I'm saying is this: Light from the Sun is scattered by the atmosphere, taking some of the blue end of the spectrum out of direct path, making the Sun look yellowish, but then reaching us from other directions in the sky as it re-scatters. However, there's no sky below our feet; there's a ground instead, which reflets some, but not all, of the sky-scattered blue light. So the bluish ambient light has a bias towards the sky. The green component could be represented better by a bias towards the mid vector between UP and the Sun, maybe squared. This is a very rough, almost contemptible, approximation, but orders of magnitude better than OGL's definition of ambient illumination. And I do think it would improve realism with any map; and it is super-simple. Regarding ambient light specifications, I once advocated (while working with another engine) that the ambient light specification be removed entirely, and that the engine compute it on the fly by averaging the cube-map. This was done and it improved realism considerably. There's no reason why the ambient color and the cubemap used for specular reflections should ever disagree, and therefore no need to burden artists with determining and writing down what ambient color should be. Ambient (diffuse) reflections have the same origin as specular reflections; same environment, just different light-bounce type.

Sorry, it's been 20 years since I used to work with glsl, and my shaders were top of the world in realism, but monolithic in structure; I was heavily criticized for my style while highly praised for the results... Anyways, I was trying to introduce one little mod in model_common.fs, just to get my feet wet... See near the bottom: #version 120 #include "common/fog.h" #include "common/los_fragment.h" #include "common/shadows_fragment.h" uniform sampler2D baseTex; uniform sampler2D aoTex; uniform sampler2D normTex; uniform sampler2D specTex; #if USE_OBJECTCOLOR uniform vec3 objectColor; #else #if USE_PLAYERCOLOR uniform vec3 playerColor; #endif #endif uniform vec3 shadingColor; uniform vec3 ambient; uniform vec3 sunColor; uniform vec3 sunDir; varying vec4 v_lighting; varying vec2 v_tex; #if (USE_INSTANCING || USE_GPU_SKINNING) && USE_AO varying vec2 v_tex2; #endif #if USE_SPECULAR uniform float specularPower; uniform vec3 specularColor; #endif #if USE_NORMAL_MAP || USE_SPECULAR_MAP || USE_PARALLAX || USE_AO uniform vec4 effectSettings; #endif #if USE_SPECULAR || USE_NORMAL_MAP || USE_SPECULAR_MAP || USE_PARALLAX varying vec4 v_normal; #if (USE_INSTANCING || USE_GPU_SKINNING) && (USE_NORMAL_MAP || USE_PARALLAX) varying vec4 v_tangent; //varying vec3 v_bitangent; #endif #if USE_SPECULAR || USE_SPECULAR_MAP varying vec3 v_half; #endif #if (USE_INSTANCING || USE_GPU_SKINNING) && USE_PARALLAX varying vec3 v_eyeVec; #endif #endif void main() { vec2 coord = v_tex; #if (USE_INSTANCING || USE_GPU_SKINNING) && (USE_PARALLAX || USE_NORMAL_MAP) vec3 bitangent = vec3(v_normal.w, v_tangent.w, v_lighting.w); mat3 tbn = mat3(v_tangent.xyz, bitangent, v_normal.xyz); #endif #if (USE_INSTANCING || USE_GPU_SKINNING) && USE_PARALLAX { float h = texture2D(normTex, coord).a; vec3 eyeDir = normalize(v_eyeVec * tbn); float dist = length(v_eyeVec); vec2 move; float height = 1.0; float scale = effectSettings.z; int iter = int(min(20.0, 25.0 - dist/10.0)); if (iter > 0) { float s = 1.0/float(iter); float t = s; move = vec2(-eyeDir.x, eyeDir.y) * scale / (eyeDir.z * float(iter)); vec2 nil = vec2(0.0); for (int i = 0; i < iter; ++i) { height -= t; t = (h < height) ? s : 0.0; vec2 temp = (h < height) ? move : nil; coord += temp; h = texture2D(normTex, coord).a; } // Move back to where we collided with the surface. // This assumes the surface is linear between the sample point before we // intersect the surface and after we intersect the surface float hp = texture2D(normTex, coord - move).a; coord -= move * ((h - height) / (s + h - hp)); } } #endif vec4 tex = texture2D(baseTex, coord); // Alpha-test as early as possible #ifdef REQUIRE_ALPHA_GEQUAL if (tex.a < REQUIRE_ALPHA_GEQUAL) discard; #endif #if USE_TRANSPARENT gl_FragColor.a = tex.a; #else gl_FragColor.a = 1.0; #endif vec3 texdiffuse = tex.rgb; // Apply-coloring based on texture alpha #if USE_OBJECTCOLOR texdiffuse *= mix(objectColor, vec3(1.0, 1.0, 1.0), tex.a); #else #if USE_PLAYERCOLOR texdiffuse *= mix(playerColor, vec3(1.0, 1.0, 1.0), tex.a); #endif #endif #if USE_SPECULAR || USE_SPECULAR_MAP || USE_NORMAL_MAP vec3 normal = v_normal.xyz; #endif #if (USE_INSTANCING || USE_GPU_SKINNING) && USE_NORMAL_MAP vec3 ntex = texture2D(normTex, coord).rgb * 2.0 - 1.0; ntex.y = -ntex.y; normal = normalize(tbn * ntex); vec3 bumplight = max(dot(-sunDir, normal), 0.0) * sunColor; vec3 sundiffuse = (bumplight - v_lighting.rgb) * effectSettings.x + v_lighting.rgb; #else vec3 sundiffuse = v_lighting.rgb; #endif vec4 specular = vec4(0.0); #if USE_SPECULAR || USE_SPECULAR_MAP vec3 specCol; float specPow; #if USE_SPECULAR_MAP vec4 s = texture2D(specTex, coord); specCol = s.rgb; specular.a = s.a; specPow = effectSettings.y; #else specCol = specularColor; specPow = specularPower; #endif specular.rgb = sunColor * specCol * pow(max(0.0, dot(normalize(normal), v_half)), specPow); #endif vec3 color = (texdiffuse * sundiffuse + specular.rgb) * getShadow(); vec3 ambColor = texdiffuse * ambient; #if (USE_INSTANCING || USE_GPU_SKINNING) && USE_AO vec3 ao = texture2D(aoTex, v_tex2).rrr; ao = mix(vec3(1.0), ao * 2.0, effectSettings.w); ambColor *= ao; #endif /******************************************************************/ float up_bias; #if USE_SPECULAR || USE_SPECULAR_MAP || USE_NORMAL_MAP up_bias = 0.4 * (1.5 + normal.z); #else up_bias = 0.4 * (1.5 + v_normal.z); #endif ambColor.rgb *= up_bias; /******************************************************************/ color += ambColor; #if USE_SPECULAR_MAP && USE_SELF_LIGHT color = mix(texdiffuse, color, specular.a); #endif color = applyFog(color); color *= getLOS(); color *= shadingColor; gl_FragColor.rgb = color; } Description: "Ambient Light", the way OpenGL defines it, (light coming from all directions equally) is not even a first approximation of real ambient light. A second approximation, if you call that a first, is where light comes from all directions, but with a "sky-bias" or "up-bias"; i.e. more light coming from above than from below. I calculated it as 0.4 * (1.5 + normal.z), where normal.z wishes to be the UP component of the normal vector, like "normal dot UP"; I don't know that it is; it was a wild guess; I'm very rusty on all this. Consider that 0.5 * (1.0+("norm dot UP")) would produce a bit too much bias, as it would make light from below equal zero. With 0.4 and 1.5 I get a range of 0.2 from below to 1.0 from top. But subject to experimentation, of course. The problem is it doesn't even compile. Initially I tried using 'normal' and it told me "undefined variable 'normal'". So I added the #if and v_normal, and now it tells me "undefined variable 'v_normal'". But I see the declarations, albeit in wild nests of conditionals... Which by the way I don't understand why there's so many conditions. In the settings there are no choices for whether to have or not to use specularity or normal maps, and my "shaders" setting, whatever it means, is maxed out. EDIT: And if you could tell me how to get the UP dot normal quantity, if z is not it, I'd appreciate. EDIT2: Another question I have is in regards to what shaders are used for what, as I notice that when this shader fails to compile the trees disappear, but other things stay.

There's a new solution in the works; I would not expect a patch if I were you. Ok, he just told you. Ahhh, gottcha. Is that due to using fixed point?

There's probably not going to be a patch, gameboy. We'd need to know what the problem is before we try to fix it. That's what I'm trying to find out; just working on a theory for now. And there's little incentive to patch a problem with a piece of code that's going away anyways; there's a new shadows implementation coming soon. Just try this civic center I just attached to my previous post. It works ingame for me now. Consider it THE patch.

I didn't touch the Noba granary. Where is this "load units" thing? NM, found it! Alright, here it is, attached. The flickering is still on, but less; at least the shadows don't disappear altogether. I think this proves it's a precision problem; perhaps a depth rounding error; might be solved with a bit of bias tweaking; but I could be wrong. That's actually a pretty good idea, to separate texture from AO. Not a bad idea at all! R.e. polygons, they are grossly overrated. We're not in the days of software rendering anymore. What is REALLY the killer of GPU's, old and new, is overdraw. Painting or trying to paint the same pixel multiple times, letting the z-buffer to decide whether or not. That's the big killer. I could double the polygons on this civ center and have it render faster simply by getting rid of all the invisible surfaces inside the building. Fun hedge trimming work. ptol_civic_centre.dae

gameboy, try the mesh attached. Backup binaries/data/mods/public/art/meshes/structural/ptol_civic_centre.dae then put my modified mesh in the same folder, see if that fixes the problem. I found no duplicate polygon; all I did was increase the depth of the terrace floors. EDIT: Nevermind; the building became invisible, except for statues floating in the air... Probably some export setting in Blender that I don't know about. EDIT2: There are overlapping polygons in the mesh, elsewhere, there's a bunch of square windows that are co-planar with the walls without there being square holes on the walls for them; just overlapping. The UV unwrap is all overlapping islands; there'd be no way to bake an AO on this thing, not sure if you guys ever plan to have ao textures... They can do magic for the lighting, but you'd need non-overlapping UV unwraps to bake them. ptol_civic_centre.dae

Indeed, a duplicate face could be the culprit. Does anybody know the filename/path of that mesh? I'd like to look at it in Blender.

You're right, v is not being used here. Now I'm starting to see... I thought all this stuff was in the denominator. I'm terrible at counting parenthesis... I'd be the worst LISP programmer. Now I understand. The last problem I was having was with my UnitVector class not having Multiply(), and was going "where does it need to multiply?" That last closing parenthesis before Multiply is giving me a rotated unit vector... BINGO! Thanks, gentlemen; this file compiles now.

/binaries/data/mods/public/shaders/glsl ? Ah, yes... Good job with the shaders... Looking at water_high.fs and so far I find nothing to fix. Except Fresnel, maybe; I once implemented real Fresnell, the whole equation, no simplifications, and it looked a lot better than any approximation. That was after 2 weeks of trying to find a good simplification, using DataFit, and finding nothing that approximated real Fresnel well enough, and finally biting the bullet and doing it by the book. Anyways, getting off topic here; can't say I understand how bias would not help, not that I insist it would. Anyhow, if a better solution is in the works, I rest my case.

Stan, thanks, but I can't seem to find any glsl files. I looked under graphics, under rendering... all I find is .h and .cpp files. Then again, I don't remember what the extension was for glsl files; it was 15 years ago...

Okay, it seems to me the distinction is semantic; to me a position (in a map) IS a point. In any case, my point classes are called 'point' as in CFixedPoint3D<WORLD>. Two vectors can be added to describe the translation of a position. I didn't deny that vectors can be added; I was talking about a position (in my lexicon, meaning a point) having a vector added to it, to specify a new ... point. Multiplying a vector with a scalar is still a vector. EXACTLY. I was contrasting that to the idea of multiplying or dividing ... a point. Anyways... "pos is a vector", I think you are right. My current theory is that all of this function is happening in spawning building space, such that spawning positions around the building are points relative to the center of the building, and would therefore be (what I call) vectors, in the real world (the real virtual world). "as is u", I think u and v are in fact unit-vectors, and are so in my revised code, namely CFixedUnitVector2D<WORLD>. "Rotate is a matrix multiplication...", well, there is no matrix multiplication going on in that line of code I showed, though I agree 100% that rotation of a vector can be achieved by matrix multiplication. It can also be achieved by quaternion multiplication, but that takes more code. "Multiply is a scalar multiplication denoting...", 100% agreed, but it's not what I see in the code. "pos += u is the translation of pos..", EXACTLY. I think that pos is initially initialized to initialPos which my current theory says is the center of the spawning building, and that this line of code takes us from there to the exact place in the periphery where the next spawn will happen. If all of this is correct, my confusion could be due to the comment on the line of code being about a rotation of a vector about to be added TO the center of the building, not a rotation of the center of the building itself... Okay, I think I'm now on the way to figuring this out. Thanks! Nescio, I almost missed your post. Yes, I guess I do confuse a position with a point. Point taken ;-) Sad to hear the inital coders have left.

Ah, really glad to hear you guys are working out a better solution. In the meantime, perhaps all this needs is a little bit of offset. I was looking through the shadow parts of the code and could not find a single offset tweak parameter anywhere. I think a tiny bit of tweaking is needed to make sure shadows are not killed by rounding errors. But perhaps there is tweaking in the shader; haven't looked at your shaders yet; not even sure what language they are in; I used to do a lot of glsl hacking in the good old days.

Gottcha. But I never said that competitive gaming ruined 0ad; I was merely pointing out a trend. But I get your point; maybe there is a point. If so, could perhaps such stats displays and whatnot be a settings option?