DanW58

Nice! Why is it called "ao_as_emissive"? AO modulates reflected ambient. I hope you guys are not ADDING the ao... It should multiply the ambient component. It should darken, not brighten... Is this why I can't see it? (Going to bed now.)

Stan, I can't follow; too fast. Maybe tomorrow after coffee. I mean today. So, the ao looks perfect; I just don't see it in-game, for some mysterious reason. Yeah, now I remember it had to be normalized... EDIT: Speaking of cosines, which type of ao are you guys using? The ao by Blender is unmodulated, last time I looked into it. That means, all rays are counted equally. There's a type of ao where rays are multiplied by light dot normal before accumulating. That type of ao gives noticeably more realistic results.

Well, my Blender interface is now completely messed up; it became divided into four sub-screens, with the top left full of icons for folders; I don't even know what I touched; and can't seem to get out of it. Maybe you can look at the file and, yes, maybe apply the texture to it for me; I've had so much Blender frustration today I almost need medication. GLSL is much easier than it looks. First of all, it's much like C. But the main types of variables you use are float, vec3 and vec4 (3 and 4 floats, respectively). So, for a fragment shader example, uniform vec3 sunray; //uniform means that it's like a per-frame constant uniform vec3 suncolor; //ditto uniform sampler2D baseTex; //this is a data structure to read a texture varying vec2 v_tex; //texture coordinates, interpolated by vertex shader varying vec3 vnormal; //interpolated vertex normal, varying means from the vertex shader main() //this executes per pixel, or per pixel-fragment in antialiased mode { //calculate the diffuse component of final color: vec3 difftexture = texture2D(baseTex, v_tex.xy); //fetch diffuse color from texture float diffuse_intensity = dot(sunray, vnormal); //dot = cosine of angle; 1 for face-on vec3 diffuse = difftexture * suncolor * diffuse_intensity; //similar thing for ambient light with ao //similar thing for specular //add it all together and output. } //next pixel... What is that plug-in? For what? EDIT: File attached; no change since last attached. ptol_civic_centre.dae

Stan, I found the ao png, and it looks good; but I wanted to see it on the model, so I loaded it into Blender in the UV editor, and went back to the 3D view to look at it on the model, but the building appears very dark, with two small slivers of light. I'm used to the old Blender of XP days; I'm really struggling to get used to the new Blender interface. Anyways, I used to just load a texture in the UV screen and look at it in 3D in object mode, but it's not working for me. In-game, I strain my eyes trying to see AO and can't see any; even though all my graphics options are maxed out, including the Shader Effects. Could it be that my tweaking with the model removed the texture linkage somehow?

No, exactly, this is a software problem. We should make sure all models have AO, though; I'm not sure this does; if it does it's kind of weak. The space behind the columns should already be pretty dark from the AO, then even the flickering of the direct shadow wouldn't be so noticeable. Done. ptol_civic_centre.dae

Very true. I can't sleep, so I'll tackle it right now. Probably just a matter of moving the edge on the UV map. By the way, I just notice the same shadow flickering problem on the terraces of guard towers. The strange thing is that it changes as you rotate around the tower. Going back to thinking this is algorithmic.

Well, he already did; he said next release. But I'd be curious if perhaps he remembers there being a minimum shadow length setting somewhere.

I'm guessing in a month or two, but I don't know; I'm actually quite new around here. Anyways, the problem seems to be that there's a minimum shadow distance set somewhere, probably to avoid surfaces shadowing themselves, but that is not short enough for the existing art. I know I said this is probably a precision problem, but I'm changing my mind now... If it was a precision problem it would show at any distance from the shadow casters, not only at the shortest distances --the way it seems to occur. @Stan`Does this building have an ao? I'm not sure how to tell in Blender.

Okay, I don't see the flicker from the images, but I believe you. EDIT: Ah, I see it now; the shadow behind the column. Frankly, if there was a proper ao in this building, the wall behind the column should be dark enough from the ao you probably would not notice the direct light shadow missing... However, the problem is not the building itself; it is something about the shadow algorithm and/or the precision of the hardware; and there's a new algorithm coming soon, so there's not much to gain fixing the current one; --much less from changing the buildings. Have you played with the settings of the shadow quality? The more bits of depth the better, as long as your hardware can handle it. I see that your images are high rez, which suggests you have better hardware than mine. In the Menu, Settings, there's shadow quality options going from Very Low to Very High, and whether to have filtering or not. Try playing with those and see if the problem goes away.

It's totally correct. There's no balcony; it's a terrace. The inside is lower than the periphery. I think you're looking at it the wrong way. Try it in-game you'll see.

Exactly. Metallic reflection colors light; Fresnel reflection doesn't. In the case of "diffuse materials", the color also results from multiple colored bounces, just as in metals, but the difference is that we don't have a specular (single bounce) color to compare with; but it would be the square root or cubic root of the diffuse color if we could. Applying this rule to metals, I cannot describe in words what a huge difference it makes. I once made a model of an electric motor and used these rules for copper, bronze and gold parts in it, and people were going crazy like "That looks like a photograph! How did you do it?" It works THAT well, even though the difference is almost invisible. Quite a contradiction. If you look at the same rendering with diffuse = black it looks like "standard" representations of copper, bronze and gold; but you change the diffuse to a very dark, almost black, 2nd or 3rd power of the specular color, and you can't almost see the difference, but it looks photographic. Science delivers. Yes, the rule is per-channel, no more than 1.0, preferably no more than 0.9. In fact, I bet the problem with the Acropolis terrain is not only that it is close to white, but probably has some specular added to it. Best thing that could be done with terrain is to not support a specular texture at all. The only specularity from ground should be water (or polished granite), both of which are Fresnel reflections and therefore must be computed, and NOT come from a texture.

I had been out of this line of work for too long; this is the first time I hear of glTF and spirv; I'm reading about both right now. Not sure yet what the art impact would be. Generally, though, I think PBR should go with PBA, and it should not offend artists to receive some physics based guidelines. I posted a "mini-course", some very basic rules, such as not having diffuse and specular colors that add to more than white, and when to desaturate diffuse for specular, and when not to: And I didn't get any dislikes. When I was an artist at first (and I WAS clue-less back then) I wanted physics based direction; I hated anybody telling me "You are the artist; whatever you decide." As far as converting to new formats, it is a matter of obtaining or coding tools to convert existing assets. There was a time when Vegastrike did not have cube-maps. When I pushed for them I was getting resistance based on the amount of work it would take to convert from spheremaps. So one day my buddy Klauss took on the programming, and I took on the maps themselves. In two days I converted all the spheremaps to cubemaps, and Klauss had the code ready. As someone said, there comes a time in the history of every project when you have to shoot the engineers and start production. If swtiching to glTF is the way to go, I would advocate NOT discussing it too much... ;-) EDIT: One change I would propose, that would help separate what's art from what isn't, is to separate weather from maps. Just as you have choice of map and civilization, I'd have a choice of season, time of day (or night) and weather, of course defaulted to random. This would entirely remove the expectation that ambient light is an artist's choice or responsibility. And it would increase replay value 100-fold.

I don't like it either. It would be preferable to just pile on 50 kilo coffee bean bags along the walls... Did Greeks drink coffee? Close to Rome... Anyways, the edges that were spuriously sharp were mostly around the columns. I highlighted some edges yellow to give you a general idea; I don't remember which edges were sharp and which weren't. In Blender you have to be careful with selection by angle. It only works 95% of the time...

Indeed. Of course. But which, again, should not be happening. Anyways, I was writing a post and lost it. My 4-color shader project. Back in the day I was doing a lot of crazy stuff. Some metals, such as chromium, which get self-pasivating rust (transparent rust) exhibit rainbow color effects due to light refracting into the rust and reflecting internally several times before coming out, and since the angle of refraction depends on wavelenth, some colors get subtracting reflections, some get additive reflections, depending on the thickness of the oxide, and the view angle. I got that to work; I could control the thickness of the rust via a texture channel and could see rainbows as I turned. But it didn't look too realistic. So I started working on a 4-color band. I used the alpha channel for a color between blue and green, as the distance between blue and green is about twice that between green and red. Although we don't officially have cones tuned to blue-green, our rod cells actually have a low-Q preference for blue-green. I had two ad-hoc algorithms for producing the blue-green channel: one for materials, and one for light sources. I did all my processing in 4 colors, then at the end I moved some of the blue-green energy to the blue and green channels...

Yes, I was fully aware of the saturation risk; unfortunately, there was no elegant solution to the problem, as having a bias while preserving average luminosity implies going above and below 1.0; but in my mind this was no life or death issue, since neither should the grounds be too close to white, nor should ambient light. I was tempted to forgo the preservation of average illumination, as I find most maps in game have excessive ambient light; but then I figured I might become a political refugee after darkening ambient generally.

FIXED!!!! Well, it's a dishonorable fix; I just slanted the walls inwards to hide the part of the floor that gets leaked light. But I also fixed other problems with the model. There were many spurious edges tagged "sharp" around the columns, for example. I did a general clean-up of missing or unwarranted sharp edges. ptol_civic_centre.dae

The problem is that the moment it makes ONE bad choice of triangles to merge, from then on it propagates the badness. I frankly don't understand how the coder could be so dumb. If you had a cloud of triangles on a shapeless surface I would understand; but in a model that is aligned with the axes, it should be obvious which triangles to merge. Life in prison is not enough. Regarding the problem; brute force doesn't work. I placed a chunky sun shield inside the wall of the building around the top terrace, see pic, and it makes no difference whatsoever; light gets through anyways. Looks like we'll have to wait for release 25 and hope it fixes it.

I'm willing to put in the work. White is a color that should never be used for materials, really. It doesn't exist in the real world. Nor does black for that matter, though in some situations it may be useful.

Yes, that may be true at run-time; but if I load the model I just saved and it's all triangulated it is impossible to work with; and Blender does a terrible job of converting triangles to quads; whoever coded that should get life in prison. Anyways, I found the culprit: A stupid flag for triangulate on export, hidden in a second tab in the Collada exports options, absurdly defaults to checked ON. Another candidate for life in prison... Yeah, about the problem, I remember dealing with something similar, a very long time ago. I tried adding a thin outer trim to the terrace floor, but it made no difference. Now I'm trying a brute force approach, adding a hidden light-blocking frame. Of course, doing so is not ideal, as it causes the very problem I was talking about regarding graphics performance: overdraw... Which is a misnomer; should be called "over-visit", as the problem is revisiting the same fragment, whether it results in something drawn or not, z-buffer notwithstanding.

That's strange! I never saw anything like it. Light is leaking under... Hmmm... Let me look into this. Gameboy, I've looked at it, and nothing indicates to me this should be happening. And in my computer it does not happen. The floor in those roofs is not attached to the walls; i mean not welded; but the edge of the wall and the edge of the floor coincide seamlessly. Now, I do remember, many years ago, decades ago, there were graphics cards that exhibited such a light leakage problem say under walls that sat on a floor plane but did not connect to the floor, with certain shadowing algorithms. I'm tempted to just weld the terrace floors to the walls, but I fear this would break the existing UV-mapping of the model. I'm going to have to let someone with a better idea what may be going on weight in. EDIT: Another thing I notice is that Blender somehow triangulated all the quads on this model for me without even asking. I imported and exported a lot of .obj and .stl with Blender, but this is my first time touching Collada things; it may be some setting... I have good news. I was able to reproduce the problem in my computer. This is only a matter of time now...

LOL, well, the only place I've heard people say you see light coming equally from all directions is inside the Sun... Europe won't cut the mustard. Not even London in the sunniest, foggiest day. Wait! Was OGL designed by Sun Microsystems? I guess that's what you get from graphics hackers when they spend too much time in the sun...

I tweaked it a little more; found it way too subtle. Also it was still a bit darker than the legacy ambient light. So, try these files attached instead, which have overall gain of 1 and give less bias to red than to blue, but not zero. In case explanation is needed, the code is as follows: #if USE_SPECULAR || USE_SPECULAR_MAP || USE_NORMAL_MAP up = normal.y; #else up = v_normal.y; #endif up_bias = vec3(up,up,up); up_bias += vec3(4.5,3.0,1.9); up_bias *= vec3(0.2,0.3,0.5); ..................................... ambColor.rgb *= up_bias; model_common.fs model_common.vs terrain_common.fs Variable 'up' has the upward component of the surface normal. This component can go from -1 (pointing down) to +1 (pointing up). In the standard OGL pipeline, ambient light is simplified to "light that comes from all directions". In the real world, whether indoors or outdoors, more light comes from above than from below. Light from below is typically light from above that bounced off the floor and has lost some energy. Moreover, in open air settings on planet Earth, the sky is blue, and so the blue component has more biased than green and red. So, for the blue component, I'm adding this -1 to +1 value to 1.9, which yields a range of 0.9 to 2.9, the average being 1.9, and I multiply it by 0.5. Thus, the average is now 0.95, but increasing to 1.45 for polygons facing up, and as low as 0.45 for polygons facing down. For the green component, I add 3 and multiply by 0.3, giving a range of from 1.33 for polygons facing up to 0.6 for polygons facing down. For the red component I add 4.5 and multiply by 0.2, yielding a range of intensities from 1.1 to 0.7.

Okay, here we go. I separated the channels. Red gets no bias at all: omnidirectional. Blue gets as much bias as before. Green has half the bias. I think this is a more natural approach. I tried other things, even tried giving red a negative bias, towards the ground. It looked interesting, but not necessarily more realistic. I hope I haven't reduced the strength too much... Let me know what you think. The two fragment shaders changed. The vertex shader is not changed, but I'm including it for people who may have missed earlier posts. model_common.fs terrain_common.fs model_common.vs

Thanks for the feedback. I can reduce the strength of skyward bias easily. My biggest fear was people not noticing it. I will reduce the bias to about half, and re-post the files. In fact, I think I'm going to treat the channels separately, keep the blue channel as is, reduce the strength of the green channel by half, and remove bias in the red channel. This, I think, will look much more realistic.

Okay, thanks; I fixed those white spaces in model_common.fs; attached. As for "v_normal.xyz = normal;", I found it, but that was there before I touched the file; I'm shy about removing code that isn't mine and that I don't understand. I wrote fragment shaders for a couple of years, but I have zero experience with vertex shaders. I think it's better that whoever wrote deal with that. The only change I made was to swap lines 29 and 30, making the writing of the normal unconditional. EDIT: Ah, now I get you. My making v_normal's writing unconditional has to be paired to that norma.xyz = v_normal becoming unconditional also. Done! Attached. Might as well re-attach the terrain shader also; no change. P.S. If you don't notice a difference, look at an elephant up close; they look a lot more solid. model_common.fs model_common.vs terrain_common.fs