Fragment shader quick questions

[hyperion]

erm

ERROR: Failed to link program 'shaders/glsl/model_common.vs'+'shaders/glsl/model_common.fs':
error: fragment shader varying v_normal not written by vertex shader

... and both shaders have white space errors added

[DanW58]

26 minutes ago, hyperion said:

erm

ERROR: Failed to link program 'shaders/glsl/model_common.vs'+'shaders/glsl/model_common.fs':
error: fragment shader varying v_normal not written by vertex shader

... and both shaders have white space errors added

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

Edited February 6, 2021 by DanW58

[hyperion]

25 minutes ago, DanW58 said:

What are the "white space errors"?

Here, trailing spaces on empty lines, eg. line 59 and 171 in model_common.fs. Don't know what editor you use but should be configurable to at least highlight those. Also git will yell at you.

[hyperion]

You also need to take out "v_normal.xyz = normal;" of the conditional in the vertex shader for the program to link.

 

Well, tested on a few maps, still looks ok, can't say better or worse, but then again I'm not a graphics guy.

[DanW58]

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

Edited February 6, 2021 by DanW58

[wowgetoffyourcellphone]

I see the effect (applied the files and looked in Atlas) and I like it. I think it may be too 'strong' though, even if it's Correct™. I notice it reduces the visual effect of the AO maps a bit and adds a lot of contrast where there wasn't before, so I have to mess around with the ambient color some to reduce that contrasty look. I notice the it most with the Greco-Roman temples, where there is a bunch of columns in front of a covered area. The different effect applied to horizontal and vertical surfaces is very noticeable. Without true SSAO the effect doesn't look as "real" as it could (in truth, looks less real in the case of a colonnade or similar contrasty structure). Please take these as simple observations. 

Vertical and downward faces are darkened considerably. 

Again, I understand what is being attempted here. I just think it's too strong. 

[DanW58]

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.

[DanW58]

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

Edited February 6, 2021 by DanW58

[Stan`]

@vladislavbelov can you review this?

[DanW58]

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.

Edited February 6, 2021 by DanW58

[vladislavbelov]

17 minutes ago, Stan` said:

@vladislavbelov can you review this?

On phab - yes.

[hyperion]

2 hours ago, DanW58 said:

My biggest fear was people not noticing it

There was a clear difference, thou it neither looked real before or after. If I had to describe the difference it's moving an arcade landscape from Europe to Africa, less humidity and less distance for light to travel trough the atmosphere. Will test your latest changes later.

[DanW58]

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...

Edited February 7, 2021 by DanW58

[hyperion]

The latest shaders actually look like a slight improvement, however, just as you said, whitish textures need fixing now.

[DanW58]

14 minutes ago, hyperion said:

The latest shaders actually look like a slight improvement, however, just as you said, whitish textures need fixing now.

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.

[vladislavbelov]

14 minutes ago, DanW58 said:

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.

Interesting theme  In theory there are no colors at all, everything is a subjective perception. So there is no computer color/finite value that might represent any of real color.

18 minutes ago, DanW58 said:

I'm willing to put in the work.

I suppose he means that your formula gets an overflow as you get a color value more than 1.0 (255) for some components.

[DanW58]

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.

[vladislavbelov]

2 minutes ago, DanW58 said:

nfortunately, there was no elegant solution to the problem, as having a bias while preserving average luminosity implies going above and below 1.0;

On old hardware - yes, on modern we might render it into HDR render target and apply tone mapper afterwards, or just apply tone mapper directly.

5 minutes ago, DanW58 said:

since neither should the grounds be too close to white, nor should ambient light.

The problem appears not only for white but for any color that has a component near to 1.0 (255), like red, green or blue.

[DanW58]

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...

[hyperion]

2 hours ago, DanW58 said:

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.

If you have to touch a lot of the assets for this it might make sense to go further. Not saying you have to or that what I'm going to throw out is the way to go, just that I think it's worth discussing. Once more I'm not a graphics guy nor artist.

PBR came up earlier in this thread. Maybe it's worth considering adding a prefer spirv option analogue to the existing prefer glsl one. Sticking to glsl 4.6 for the time being is fine. The idea is to reuse this shaders for a future vulkan renderer. This set of "pseudo spirv" shaders can assume modern hardware and drivers supporting opengl 4.6, respectively vulkan, and the goal is PBR. Then while fixing the assets convert them to glTF which lends itself to PBR and has likely better support and for sure better interoperability than the discontinued collada.

If this results in some degradation in visuals for old hardware I think that's fine. If you already run on ultra ugly settings like no shadows and simple water some colour skew hardly matters any more.

The main question probably should be if there is someone/few capable and willing to do this and whether the artists are fine with PBR and glTF

[DanW58]

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.

Edited February 7, 2021 by DanW58