Jump to content

A "psychic" shader mod; development begins...


Recommended Posts

First the low quality of the video hides all the qualities your shader is supposed to present, second you seem to overestimate how many follow progress enough to see an obscure post in a dev subforum.

Lastly, your stats are great, compared to many veteran 0ad casters so chillout XD

  • Like 1
  • Thanks 1
Link to comment
Share on other sites

Posted (edited)
35 minutes ago, wowgetoffyourcellphone said:

I hate what it does to the terrain textures though. I forget, but did you say that will be worked on later?

I had to refresh my memory.

What I did to terrains was three things:

  1.   I got rid of the specular channel;  I ignore it with full prejudice, since ground never has much specularity to speak of, unless it is man-made polished stone, or smooth ice;   but even in those cases the specularity is dielectric rather than metallic.
  2.   Even so, some grounds, particularly the Acropolis elevated ground, were so bright in diffuse they still saturated even after removing the specular channel.  So what I do is detect unsaturated (gray-scale) material that is too bright, and dim it down by using squaring, color*color, which dims while increasing contrast.  This did wonders for the Acropolis and the Badlands maps, both of which had very bright tiles around where you start the game.  Belgian Bog did not really need fixing but it got a little bit of darkening and contrast enhancing of the stone paths, and they looked beautiful;  I appreciated them for the first time.
  3.   The third thing I did, and which I'm thinking perhaps it's not entirely correct, is I multiplied ambient lighting for terrains by 0.5, to compensate for the fact that we don't have terrain AO bakes.  I'm thinking this is perhaps unwarranted because if we did have such AO bakes they would look about 80~90% white on average.

So, yeah, I think I'll get rid of that 0.5 and report back.  Thanks for the reminder.

EDIT:  And regarding specularity of grounds, now that I have Fresnel, I could bring the spec channel back with some arbitrary Fresnel and some arbitrary but very low spec power, to make it just a blurry shimmer.  I'll experiment with that.

Edited by DanW58
  • Like 1
Link to comment
Share on other sites

Posted (edited)

@Panther A *.pyromod is a renamed *.zip;  you can rename it back to *.zip if needed.

I'm having a hard time with bringing back specularity to terrains.  Initially I tried testing with my favorite terrain, the Belgian Bog, but nothing I was doing had any effect;  then discovered that Belgian Bog has specularity turned off via xml settings.  Maybe that's one of the reasons it's so nice :)

So then I turned to my pet-peeve map, which I knew had specularity, the Acropolis Bay.  So, first I wanted to know what exactly am I dealing with, so I made the shader output raw specular color to the screen, and this is what I found:

absurdspecular.thumb.jpg.403a4e6d032bad0b30583822b2ac9dd8.jpg

I have no idea why some patches have almost full specularity.  It seems totally random.  There's nothing particularly different about those areas to tell in the diffuse texture.  I mean, if the diffuse intensity went down as the specular intensity went up, those areas would turn metallic;  but the diffuse intensity is rather uniformely too high;  too close to white, in fact. 

absurddiffuse.thumb.jpg.3689a4a86863ae4bcc91d3be3b089bcd.jpg

And there is no material that could possibly be white in diffuse AND in specular;  this is complete trash.

But then, as I brought back specular code that I had erradicated from the terrain shader with full prejudice, I noticed something peculiar:  The alpha channel in the specular texture is used to alpha-blend specular color with diffuse color AFTER lighting, which I'm still trying to wrap my head around...  Why not just pre-multiply this alpha channel by the specular RGB, and use the alpha channel for a more valuable purpose?  I decided to try and see what this alpha channel contains, so I converted it to grayscale and put it on the screen:

absurdalpha.thumb.jpg.6449e1aad6db3a643da0cf172cf87db9.jpg

As you can see, we find no relief from specular absurdity in the alpha channel.  I was hoping that maybe those bright patches had low alpha to compensate, but the alpha channel is not only conceptually wasteful, it is wasted in actual fact by making it 255 all across.

How is a poor shader supposed to deal with garbage at the input?  One map can be beautifully well done;  another can be totally absurd.  But I'm not sure who exactly I'm pointing a finger to, though I certainly am.  Is this the map-maker's fault?, or is it the materials?, or the engine?  One thing I know is that I looked at the textures in the materials library a week ago or so, and I found the texture that makes up the tiles (that we barely see in the second picture above, so bright they are).  That texture, as I said to Stan, is way too white, and on top of that has content in the specular channel.  What my so hated terrain shader has done is inject beauty into this acropolis bay absurdity by toning down those whites, removing specularity altogether, and increasing contrast at the high end, thus making the tiles noticeable AND good looking  *** for the first time *** ...

beautyacropolis.thumb.jpg.c64746a30871eceb9b6671573c140eda.jpg

  ... but what do I get for it if not hate?   How is it even possible?  Or is this just the case of one little tyrant's opinion that everybody else is afraid to confront?

@wowgetoffyourcellphone Can you please tell me which map is so badly affected by my terrain shader, so that I know what is it exactly that I need to fix?

 

Edited by DanW58
  • Thanks 1
Link to comment
Share on other sites

1 hour ago, DanW58 said:

... but what do I get for it if not hate?   How is it even possible?  Or is this just the case of one little tyrant's opinion that everybody else is afraid to confront?

Did I say anything? Tiles look nice

Link to comment
Share on other sites

Posted (edited)

I wasn't talking to you, Stan.  I know my friends from my enemies.

What I did say to you earlier stands, though;  the tiles texture is too bright.  A shader should not be expected to fix this kind of problem.

EDIT:  Consider this:  If floor tiles deserve 255,255,255,  what color do you use for Greek houses, which are traditionally painted with the whitest paint known to man?  In fact, if Greek houses were full white in diffuse, I would NOT complain to you.   But floor tiles *full white* ?!?!?!

And it's inconsistent with the other textures.  Try scrolling through the textures in the folder with a picture browser, the moment you hit the tiles texture your eyes begin to tear from the brightness.

It instantly ruins any map that uses it.

Edited by DanW58
Link to comment
Share on other sites

3 hours ago, DanW58 said:

@wowgetoffyourcellphone Can you please tell me which map is so badly affected by my terrain shader, so that I know what is it exactly that I need to fix?

Sorry, I am currently in the middle of revamping all of the terrains, so the cases you are trying to fix with your shader aren't present in my current terrain set (for instance, those white tiles on Acropolis Bay no longer exist for me). The new terrains do include specular maps, but they are much more subtle than the old ones, so likely require less adjustment than what you are coding for. Perhaps I can port my terrain work over to a new separate github repo sooner rather than later so you can take a look at them in-game. I'm just in the middle of trying to get my main mod ready for publishing while fighting off an illness.

Edited by wowgetoffyourcellphone
Link to comment
Share on other sites

Ok, fine. Thanks.

 I'll wait for your new maps then, as I see nothing in the current set that breaks with the terrain shader as is.

 Just so you know, though, my brightness correction is not a dimming of the whole thing, it is a curve that only begins to kick in when the ground material goes above 75% white;  so if you have nothing so bright, my terrain shader should be doing nothing to it,  EXCEPT getting rid of the specular, which I'm working on to trying to bring back, but is made so difficult by the data in specular for Acropolis Bay being complete nonsense.

Another problem is that the terrain_common.fs shader gets neither an eye vector nor a sky-box from the engine.

All I can do, in terms of specularity, is reflect the sun.  That's it.  I don't know why are shaders denied so much info.

 

Link to comment
Share on other sites

5 minutes ago, DanW58 said:

but is made so difficult by the data in specular for Acropolis Bay being complete nonsense

Oh, I completely agree that many of the brighter terrains are completely blown out. That's part of the fix for the terrains I'm working on, in addition to bringing normal/bump maps to all terrains and increasing resolution and overall quality. Terrains are, IMHO, the most important thing to get right visually, as they take up a huge percentage of screen space. 

Here is Acropolis Bay with some of the new terrains (high res image):

Spoiler

ksK91Ot.jpg

 

  • Like 1
Link to comment
Share on other sites

But if you want specularities in the stones, you might want to consider making them darker, though;  I'm just saying.  Because you mention you'll have normal maps.  Normal maps look best with specularities.  If these stones are anything like cobble-stones, they'd be much darker in diffuse.  But if they are some kind of matte white stones, then they are fine.

Link to comment
Share on other sites

3 minutes ago, DanW58 said:

But if you want specularities in the stones, you might want to consider making them darker, though;  I'm just saying.  Because you mention you'll have normal maps.  Normal maps look best with specularities.  If these stones are anything like cobble-stones, they'd be much darker in diffuse.  But if they are some kind of matte white stones, then they are fine.

I'll do what I can with the source files I'm working with. They are very high quality files found here:

https://cc0textures.com/

https://texturehaven.com/

With this terrain update we're committed to using high quality CC0 or CC-BY-SA sources. We are lucky that in this day and age we have access to these sources. Currently the game has many many terrains, spanning over the course of a decade and a half, all of different quality and from uncertain provenance. Can't really fault some of the original artists as 10+ years ago high quality material was difficult or impossible to find, and also the rendering engine was much more primitive, so a simple 512x512 diffuse texture was all that was deemed necessary.

As the process continues I am committed to working with you and whoever else wants to work on rendering the game world better. To facilitate that cooperation, I want to get a terrains git repo up and running in the soonish timeframe. I'll work with @Stan` on that.

Link to comment
Share on other sites

Can't wait.

My only concern is what you guys use as a reference shader to know what the final work looks like.

My shader set, I called it "PROHIBITED" in the video because it is supposedly NOT to be used as a reference shader for artists to use, precisely because of my metal and skin detections, and corrections of overbrightness.

On the other hand, the current shaders aren't really much better, and in many ways worse than mine, in terms of lighting correctness.

Case in point, I just discovered that terrains had no Light dot Normal modulation for sunlight.  You can tell  how high or low the Sun is by how the shadows project, but not by the brightness.  The brightness is the same no matter if the sun is high above or near the horizon.

So, now, what happens when I fix the problem and introduce modulation of brightness of ground by Sun angle?

What happens is the grounds in maps not at noon will look darker.  And everybody will blame my shaders for it.

Right now there is no reference shader.  NONE whatsoever.  That's what I'm worried about.

  • Like 1
Link to comment
Share on other sites

Until the git repo is up and running I can provide you with screenshots or videos of anything you need for your critique or adjustment. 

Are you using the SVN version of the game or Alpha 24? You may be able to download and run my gameplay mod "Delenda Est" which includes all the new terrains I have created so far. 

Edited by wowgetoffyourcellphone
  • Like 1
Link to comment
Share on other sites

Posted (edited)

Yes, I'm on SVN.  I'll check out Delenda Est, thanks.  Where do I find it?

I just found another error in the current, official terrain_comon.fs:  The normalmap only affects diffuse lighting;  not specular.  It's funny because normalmap is best shown in specular;  that's where it really shines;  but in this shader it is invisible to specularities.  I'll fix that, of course;  but this is generally how my shader set keeps getting closer to becoming a reference.  All I'd have to do is remove metal detection, etc, and they would be far more of a reference than the official shaders.

You might not think much of this bumpmapping gottcha, but chances are that you, as an artist, using the current shaders, might think your normal-mapping looks too subtle and strive to increase it.  Once you see it through a shader that uses the normalmap in both diffuse and specular, however, it may look transdimensional.

I also don't understand why is there parallax in so many of the shaders, but not in the terrain shader.

And why there's no skybox.

EDIT:  Sorry, it was in your signature.

Edited by DanW58
  • Like 1
Link to comment
Share on other sites

42 minutes ago, DanW58 said:

Can't wait.

My only concern is what you guys use as a reference shader to know what the final work looks like.

My shader set, I called it "PROHIBITED" in the video because it is supposedly NOT to be used as a reference shader for artists to use, precisely because of my metal and skin detections, and corrections of overbrightness.

On the other hand, the current shaders aren't really much better, and in many ways worse than mine, in terms of lighting correctness.

Case in point, I just discovered that terrains had no Light dot Normal modulation for sunlight.  You can tell  how high or low the Sun is by how the shadows project, but not by the brightness.  The brightness is the same no matter if the sun is high above or near the horizon.

So, now, what happens when I fix the problem and introduce modulation of brightness of ground by Sun angle?

What happens is the grounds in maps not at noon will look darker.  And everybody will blame my shaders for it.

Right now there is no reference shader.  NONE whatsoever.  That's what I'm worried about.

That's what the global ambient light trick is for, in 0ad it works very well as maps are all open scenery you can combine it with the sun angle intensity.

Link to comment
Share on other sites

1 minute ago, nani said:

That's what the global ambient light trick is for, in 0ad it works very well as maps are all open scenery you can combine it with the sun angle intensity.

Hmmmm...  I don't understand.  Ambient light is just an (arbitrary) RGB color coming in, representing omnidirectional light. So, for a point on an object or terrain you compute,
 

light = suncolor * dot(sundirection,normal) * getShadow();
light += ambient;
light_reflecting_diffusely = diffuse_color * light;

It doesn't affect sunlight.

Link to comment
Share on other sites

9 minutes ago, DanW58 said:

Yes, I'm on SVN.  I'll check out Delenda Est, thanks.  Where do I find it?

Okay, so DE is currently incompatible with SVN (I am currently working on bundling the mod for A24), but this won't be a problem for you if you are willing to revert your local copy to r24938 (this shouldn't affect your shader work as far as I know). If you do that, then you can clone the mod from here:

https://github.com/JustusAvramenko/delenda_est

Edited by wowgetoffyourcellphone
Link to comment
Share on other sites

Posted (edited)

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

Edited by DanW58
Link to comment
Share on other sites

Posted (edited)

I'm exhausted working with this terrain_common.fs shader.  I can't deal with the profusion of compile switches everywhere;  this is insanity.  You try to do one thing, this variable doesn't exist;  try to do that, another variable doesn't exist.

The normalmap, as I said, was only modulating diffuse;  not specular.  But it gets worse:  The light on the bumps is computed separately, and added to the picture later.  I did not want the light on the bumps;  I wanted the normal to be modulated by the normal map, so then I can do my NdotL, EyedotN, HalfvecdotN, and use the modulated normal for all my calculations;  but the code in this shader doesn't modulate the normal.  So I tried to copy the code from the model_common.fs for modulating normal by normalmap;  but the first part goes,

    vec3 bitangent = vec3(v_normal.w, v_tangent.w, v_lighting.w);
    float sign = v_tangent.w;
    mat3 tbn = mat3(v_tangent.xyz, bitangent * -sign, v_normal.xyz);

but the v_normal and v_lighting uniforms in this shader are declared as a vec3's;  there is no w part.

And that's after commenting out pounds of bloody conditional compilation leg-traps.

I hate to give up, but I'm at that point;  this is impossible to work with.

I would understand a couple of switches having to do with graphics settings;  but why should there be a switch for whether to use specular, another for whether to use specular map, another for whether to use normal map ...  Why would you NOT want to use these things?

And then, if they only affected values, like

#IF USE_NORMALMAP
    normal = modulate_normal(v_normal, normalmap);
#ELSE
    normal = v_normal;
#ENDIF

Right?

But let me have the variable normal;  don't tell me I have to use v_normal in the code whenever normalmap is not being used.  Well this is NOT the case with normal, but it is the case with tons of other variables that exist or not based on the bloody switches.  It is insane!

And why are are the shaders so different from each other?

Why are v_normal and v_lighting vec4's in one shader but vec3's in another?

And why don't all the shaders get all of the information?  Why some shaders have access to the skybox, while other shaders are denied it?  What is the value of hiding those datas?  Is it such a big hit on performance to pass that information, that it necesitates being miserly with variables everywhere?  This is unbearable to work with.

Happens a lot in open source that people secretly feel ambivalent about openness, so they follow open source rules superficially, but write code in a "protective" way, anyways.  There was a lot of that in Vegastrike, I remember very well...  Of course, they do want help;  but then they have to set up a culture of initiation, where they are going to "teach" people how to be as protective as them, the style, the secrets of what means what.  So the whole thing becomes a private club or religion.  Not saying categorically that's what's happening here, but I'm starting to suspect it.  Slightly more than just starting...

Edited by DanW58
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

 Share

×
×
  • Create New...