UberShader

For collaboration on developing the mod capabilities of VS; request new features, report bugs, or suggest improvements

Moderator: Mod Contributor

chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

UberShader

Post by chuck_starchaser »

Starting this thread as a development blog for the UberShader, which will be an incremental improvement upon the current HighEnd shader, and a stepping stone on the way to CineMut1 (See this post in the CineMut thread).
For the UberShader, I will try to keep needed changes to the existing art to a bare minimum, while improving its CineMut-like capabilities to a maximum:
  • It will use no PRT's or bent normals, or any new textures, for that matter.
  • It will only require the addition of alpha channels to existing textures, namely...
    • Shininess in specular alpha
    • Uniform Ambient Occlusion (UAO) in glow map alpha
    • Detail Control in damage map alpha
    ...but it will change the format for the normal-map to the encoding used by CineMut, which is far more accurate at the same texture size.
  • It will implement two detail textures: One used universally by all models and meshes globally, but very subtle, with various types of noise applied differently depending on the type of material (ripples for paints, shininess stains for metals, and "salt and pepper" noise for matte materials). The other will be user-supplied, and with controllable application. The alpha channel in the damage texture will control it in two possible modes, or none, or fades of the two modes, as follows: With alpha - 0.5, the detail texture will not be applied. With alpha below 0.5, all the way to 0.0, the diffuse mode will fade in to maximum. Diffuse mode means that the supplied detail texture is alpha-blended with the regular diffuse texture, to produce what would look like tiling painted patterns. In this mode, the detail texture's alpha channel will blend as gray with the specular texture, and with shininess, simultaneously. With damage alpha above 0.5, and towards 1.0, the supplied detail texture will be taken to mean normalmap modulation, where the red and blue channels will encode dU, the green channel will encode dV, and the alpha channel will multiply the ambient occlusion.
  • There will be no way to control the frequency of detail texture tiling, however. It will be fixed at 16x for the universal detail texture, and at a fixed 32x for the user-supplied one. If a higher tiling frequency is desired, the artist can tile the detail texture itself, such as dividing it in two, vertically and horizontally, and painting the same pattern four times.
  • There will be no switch to "albedo + specularity" as was planned for CineMut; the standard paradigm of separate diffuse and specular textures will be adhered to; and there will be no channel to specify dielectric constant or refractive index. Instead, the UberShader will deduce the artist's intent from the diffuse and specular colors. If the diffuse color is colorful (non-gray), but the specular color is a shade of gray, it will conclude that a paint is what the artist intended, and apply Fresnel speculartiy. Otherwise it will assume that the artist is representing a metal, and use metallic shading. One limitation of this guessing game is that it will be difficult, though not impossible, to represent gray paints. The way to represent gray paints will be to choose equal shades of gray for diffuse and specular. Metals are almost universally brighter in specular than they are in diffuse; so, using similar values will provide the shader the hint it needs to know that a gray paint is what is wanted.
  • In spite of the lack of PRT's or bent normals, I will attempt to implement very soft dynamic self-shadowing (by guessing a direction for a bent normal by taking differential samples of the AO).
  • Fresnel will be computed using the full Fresnel formula from physics books, like it's done in CineMut; NOT like it's done (for glass) in the current HighEnd shader, --a rough approximation which looks like crap.
  • Modulation of the AO by the bumpmap will be done in the shader, relieving artists from having to run a noodle to do it off-line.
  • Most importantly: Mirroring of UV maps will be permissible, for strictly symmetrical models, I believe; since a) Normalmapping can take it, since the introduction of tangents, and b) Even for the future purposes of CineMut, the PRT's were first replaced by a "bent normal", and later this bent normal was moved to tangent space, so it will handle like a normal normalmap normal. But I haven't ran this by Klauss yet...
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Re: UberShader

Post by chuck_starchaser »

Beginning with the texture packing

Size figures given are for a fighter-sized ship (smallest; 512 x 512).

A Llama-sized (~50m range) ship would use 512 x 1024 (or 1024 x 512, horizontal rectangle)
A corvette or frigate (~100m long) would typically use 1024 x 1024.
A destroyer (~250m long) would typically use 1024 x 2048.
A cruiser (~500m long) would typically use 2048 x 2048.
A carrier (~1km long) would typically use 2048 x 4096.
A big station (kilometers) would typically use 4096 x 4096, or multiple meshes
or sub-units with smaller textures, but roughly adding up to 4k x 4k, or 16 megatexels

For all sizes, the normalmap is typically twice the size of the base textures.
Why? The normalmap's resolution is more critical to the eyes. Think of a typical
groove: You need two texels in the normal map for a v-shaped cross-section,
whereas the diffuse color of it can be represented with a single texel.

Diffuse (512 x 512)
* R = R
* G = G
* B = B
* A = A

Specular (512 x 512)
* R = R
* G = G
* B = B
* A = shininess

Glow (512 x 512)
* R = R
* G = G
* B = B
* A = Uniform AO

Damage (512 x 512)
* R = R
* G = G
* B = B
* A = Detail policy and intensity (0.5 for no detail; 0.0 for color detail; 1.0 for relief detail)

Normalmap (1024 x 1024)
* R = dU
* G = dU
* B = dU
* A = dV
There will be a little program to convert a standard normalmap to this format.

(Optional) Detail texture (256 x 256 or 128 x 128). It can be either color detail or relief.
a) Color detail option:
* R = R
* G = G
* B = B
* A = gray specularity AND shininess
b) Relief detail option:
* R = dU
* G = dV
* B = dU
* A = ambient occlusion modulation
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Re: UberShader

Post by chuck_starchaser »

Material AI done.

First, these are shots of the diffuse (top) and specular (bottom) textures:
(This is NOT the new Llama; it's the one in-game presently.)

Image

Below I'm showing the material AI analysis results:
  • red means metal
  • green means matte material
  • blue means dielectric (e.g.: paint, plastic, glass...)
Image

In a nutshell,
  • if diffuse is much brighter than specular, it decides it's a matte material
  • if the diffuse saturation is greater than specular saturation (more colorful), it decides it's a dielectric
  • if the normalized diffuse and specular chromas are similar, it decides it's a metal
  • but if the diffuse and specular are both gray and of similar brightness, it changes its mind from metal to a gray paint or plastic --i.e.: a dielectric.
This last exceptional rule was necessary to be able to represent gray paints or plastics,
and it rests on the safe assumption that metals with equally bright diffuse and specular
are just about impossible. Metals have much brighter specular than diffuse. And matte
materials have much brighter diffuse than specular. But there's no materials that have
equal diffuse and specular. So, it's pretty safe to test for this and call it a dielectric.
But the texturing for the Llama was done un-mindful of the rules of real materials, and
so there's many spots of blue above (dielectric), not because of the chroma rule; but
because the diffuse and specular come close to equal brightness in those places. I can
only do so much in a shader...

This was important to get working because, whether to apply fresnel or not, for example, rides on knowing if the material is a metal or a dielectric. Also, metals' diffuse albedo is approximately the square of their specular albedo; which is not the case with dielectrics; so, for metals, the shader will correct that on behalf of the artist, so that gold and bronze and copper really look like themselves.
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Re: UberShader

Post by chuck_starchaser »

Is it just me, or the UberShader is starting to look better than the HighEnd?

Image

Image

Image

Shininess blurring of the environment is not working yet; still waiting for Klauss' commit.
There's also no detail textures yet. And no shadows. And no specular occlusion. And I got
a lot of artifacts to work out still.
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Re: UberShader

Post by chuck_starchaser »

There's been quite a bit of progress while the forum was down.
By the way, I committed an update to MiningBase.bfxm, to give it nicer
glass domes; and also 5 small, generic textures for all things glass; so
be sure to svn-up data. Should look better even without shaders. In fact,
the way glass was implemented would have been incompatible with old
videocards. Now there's alpha in the front material AND in the texture,
so it should work on anything.
But with the UberShader they look best, of course :D

Image

Image

The normalmap is a lot less subtle than I intended it; but it can't be made
much more subtle due to limits of precision.
The solution will be to have a separate shader for glass, which will scale
down normalmap data to an almost imperceptible level.
Struggling with some strange lighting phenomena, now.
klauss
Elite
Elite
Posts: 7243
Joined: Mon Apr 18, 2005 2:40 pm
Location: LS87, Buenos Aires, República Argentina

Re: UberShader

Post by klauss »

chuck_starchaser wrote:The normalmap is a lot less subtle than I intended it; but it can't be made
much more subtle due to limits of precision.
The solution will be to have a separate shader for glass, which will scale
down normalmap data to an almost imperceptible level.
Struggling with some strange lighting phenomena, now.
Add a uniform to the shader for scaling the normalmap, and hardcode the value in the .technique file.

That way, if you ever want glass with exagerated normal maps (or solids with subtle normal maps), you only have to create a new .technique and bind the mesh to it, instead of a new shader.
Oíd mortales, el grito sagrado...
Call me "Menes, lord of Cats"
Wing Commander Universe
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Re: UberShader

Post by chuck_starchaser »

[quote="klauss"]By the way, Klauss, what would an xmesh file look like that specifies a technique? Something like...

Code: Select all

<Mesh scale="1.000000" reverse="0" forcetexture="0" sharevert="0" polygonoffset="0.000000" blend="ONE INVSRCALPHA" technique="sheet_glass" alphatest="0.000000"  texture="bubble_diff.png" texture1="bubble_spec.png" texture2="bubble_damg.png" texture3="bubble_glow.png" texture4="bubble_norm.png" >
<Material power="1000000.0" cullface="1" reflect="1" lighting="1" usenormals="1">
	<Ambient Red="0.000000" Green="0.000000" Blue="0.000000" Alpha="0.000000"/>
	<Diffuse Red="0.000000" Green="0.000000" Blue="0.000000" Alpha="0.100000"/>
	<Emissive Red="0.000000" Green="0.000000" Blue="0.000000" Alpha="0.000000"/>
	<Specular Red="1.000000" Green="1.000000" Blue="1.000000" Alpha="0.100000"/>
</Material>...
?

Exa-very-actly.

That will look for sheet_glass.technique
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Re: UberShader

Post by chuck_starchaser »

Hahaha, I think you hit Edit instead of Quote.
It's happened to me at wcjunction.
Glad to hear. That was easy! :)
Next one's a bit harder...
Trying to write a technique. This is what I got so far:

file: sheet_glass.technique

Code: Select all

<?xml version="1.0"?>
<technique fallback="sheet_glass_lobotomized">
    <!-- Full-blown shader technique for representing sheet glass, lucite, acrylic
         or plexiglass. (All look the same, really; almost exactly the same refractive
         constant (nD) of about 1.47 to 1.48.) Beware that this shader is not for
         solid glass objects or chrystals... It does NOT perturb the background
         refractively.
         What it does do is compute precise, physics-based Fresnel reflectivity, and
         with multiple internal reflections between the two sides of the glass sheet.

         Furthermore, it deals with a very old problem:
         
         Traditionally, in Vegastrike, sheet glass has been represented with blending
         mode of "ONE ONE" and cull mode of "none". The former, for performance; and
         the latter for correctness. The problem is that the former is incorrect, and
         the latter, in spite of being correct, it looks terrible. The reason it does
         is that the back-facing glass you see in a cockpit or glass dome would NOT
         reflect the sky; it would reflect the inside of the cockpit or whatever the
         dome covers. But due to lack of specular occlusion, what it does reflec is
         sky, as if the cockpit had no pilot and no floor.
         One solution I've found works better is to simply use cull="back"; i.e. only
         show the glass facing you (the camera), and ignore the other side.
         While better, this neglects the fact that the far side of the cockpit also
         blocks light coming through, as a function of angle, by Fresnel rules.
         
         The sheet_glass technique deals with these problems by,
         a) Using blending mode of "ONE ONEMINUSSRCALPHA".
         b) Doing a first rendering pass with cull="front", to render the far side;
         and applying fresnel to its apparent transparency; but it does NOT apply
         specular light reflections or environment mapping.
         c) Doing a second rendering pass with cull="back", to render the near side,
         with full specularity and with normal-mapping.
         
         More details:
         Five textures are supplied under the /textures game folder, and used for
         glass by default.
           * bubble_diff.png (4x4) is black, with alpha of 0.1 to play well with
           non-shader-capable gpu's. 10% blending for glass looks okay, when it
           isn't possible to compute angle-based reflectivity and transparency.
           * bubble_spec.png (4x4) is white, with alpha 1.0, for maximum gloss.
           * bubble_damg.png (4x4) is identical to bubble_diff.
           * bubble_glow.png (128x128) has a bit of yellow light, and a generic
           ambient occlusion (for a hemisphere on a plane) in the alpha channel.
           This AO allows a rough computation of specular occlusion on outer
           reflections. But you may want to supply your own "bubble_glow.png",
           with a custom-baked AO for more accurate specular occlusion.
           * bubble_norm.png (256x256) has generic, tileable bumpiness, which the
           shader scales down considerably before applying to the outside for
           perturbing the environmental reflections. (Glass is a high viscosity
           liquid, rather than a solid. Over the years, windows become wobbly as
           they "drip down".)
         Note that clean glass doesn't have much of diffuse reflectivity, ergo
         the default black diffuse texture. However, if you want to depict dirty
         or dusty glass, you might want to supply a local "bubble_diff.png" with
         a very dark, but not totally black color.
         
         Future work:
         The reason for having a glow texture, (besides the fact that its alpha
         channel carries the ambient occlusion); and a specular texture (beside
         the fact of its carrying shininess in alpha), is to, in the future, implement
         a couple of little hacks...
         First, if we assume a tiny bit of diffuse reflectivity for glass, we could do
         a radio bake of inner world light sources onto the glass. Thus, a glass dome
         over a citadel, like those on the mining base, could get light from indoor
         lights, with shadows projected by the buildings. This would be put straight
         into the RGB channels of bubble_glow.png.
         Second, the RGB channels of bubble_spec.png could contain some kind of
         rendering of the inside of the cockpit or whatever is housed by the glass
         dome. A special texture mapping algorithm used only for the first pass
         (far-side glass) only, would reflect view vectors in some quirky way onto
         the glow map, to make it appear that the far side of the cockpit or dome
         is reflecting what's inside.
         
         Number of lights:
         This is a two-pass algorithm, but NOT two passes over the same geometry,
         but rather two complementary passes: One with cull="front"; and the other
         with cull="back". Furthermore, the passes are nowhere nearly as complex
         as those of the UberShader, and therefore we might be able to allow four
         lights, instead of just two, which is important because reflections on
         something as glossy as glass would be hard not to miss 'em BAD, if absent.
         
         No Z pass necessary:
         The performance advantage of a Z pre-pass is proportional to overdraw
         resulting from self-coverage by a mesh. Glass domes and cockpits are
         very rarely too far from their convex hulls, giving a Z pass less value.
    -->

    <!-- First pass: Far side of glass cockpits and domes -->
    <pass type="shader" sequence="77" blend="alpha_blend" cull="front" >
        <vertex_program src="sheet_glass"/>
        <fragment_program src="sheet_glass"/>
        
        <texture_unit src="decal:0" default="file:bubble_diff.png" name="diffuseMap"/>
        <texture_unit src="environment" name="envMap"/>
        <texture_unit src="decal:1" default="file:bubble_spec.png" name="specMap"/>
        <texture_unit src="decal:3" default="file:bubble_glow.png" name="glowMap"/>
        <texture_unit src="decal:4" default="file:bubble_norm.png" name="normalMap"/>
        <texture_unit src="decal:2" default="file:bubble_damg.png" name="damageMap"/>
       
        <auto_param name="envColor" semantic="EnvColor" optional="true"/>
        <auto_param name="light_enabled" semantic="ActiveLightsArray" optional="true"/>
        <auto_param name="max_light_enabled" semantic="NumLights" optional="true"/>
        <auto_param name="cloaking" semantic="CloakingPhase" optional="true"/>
        <auto_param name="damage" semantic="Damage" optional="true"/>
        <auto_param name="gameTime" semantic="GameTime" optional="true"/>
        <auto_param name="pass_num" semantic="PassNum" default="0" optional="maybe"/>
    </pass>
    
    <!-- Second pass: Near side of glass cockpits and domes -->
    <pass type="shader" sequence="77" blend="alpha_blend" cull="back" >
        <vertex_program src="sheet_glass"/>
        <fragment_program src="sheet_glass"/>
        
        <texture_unit src="decal:0" default="file:bubble_diff.png" name="diffuseMap"/>
        <texture_unit src="environment" name="envMap"/>
        <texture_unit src="decal:1" default="file:bubble_spec.png" name="specMap"/>
        <texture_unit src="decal:3" default="file:bubble_glow.png" name="glowMap"/>
        <texture_unit src="decal:4" default="file:bubble_norm.png" name="normalMap"/>
        <texture_unit src="decal:2" default="file:bubble_damg.png" name="damageMap"/>
        
        <auto_param name="envColor" semantic="EnvColor" optional="true"/>
        <auto_param name="light_enabled" semantic="ActiveLightsArray" optional="true"/>
        <auto_param name="max_light_enabled" semantic="NumLights" optional="true"/>
        <auto_param name="cloaking" semantic="CloakingPhase" optional="true"/>
        <auto_param name="damage" semantic="Damage" optional="true"/>
        <auto_param name="gameTime" semantic="GameTime" optional="true"/>
        <auto_param name="pass_num" semantic="PassNum" default="1" optional="maybe"/>
        <auto_param name="wobbliness" semantic="WoblinesS" default="0.1" optional="maybe"/>
    </pass>
</technique>
Notes:
  • sequence = 77 because I like the number. There were no examples for glass in the dtd.
  • Blend="alpha_blend" because I couldn't find "ONE ONEMINUSSRCALPHA"; unless that's what you meant.
  • First pass doesn't need detail textures, so I took them out. Second pass reuses the bubble_norm as a detail texture (yeah, at different scales; maybe rotated; and yes, it's tileable); so I guess we don't need to pass it a detail texture in addition to it. And I could do the same with the specular texture, reusing it as detail, so if someone would like to play with shininess to put scratchiness, then the scratchiness would become sort of fractal.
  • First pass doesn't use the normalmap at all, but I figured I should pass it anyways, to use the same shader?
  • All these auto-param things I just copied them; haven't the foggiest what they mean and/or do. I read the dtd 7 times already. I'm not sure what does 'semantic' mean, in practical terms. Comparing the name and semantic values, they only seem to change by capitalization, or camel case versus underscores. And what's the difference between 'param' and 'auto_param'?
  • I need to tell the shader whether this is the first pass or second pass. Did I do it right?
  • And "wobliness" is your normalmap scaling suggestion, or my attempt at it.
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Re: UberShader

Post by chuck_starchaser »

IT WORKS !!! :D

Got the glass domes rendered by their own shader.
Not working perfectly yet. The domes look dimmer than they did in the UberShader, not sure why.
Could be due to the "sequence" parameter in the technique, which I guessed at 25.

Well, I have the first pass and my auto-param lines commented out, and the stuff
about detail textures is back in. IOW, it's pretty much identical to the UberShader technique.
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Re: UberShader

Post by chuck_starchaser »

BUAHAHAHAHA :mrgreen: :lol: :mrgreen: :lol: :mrgreen: :mrgreen: :lol: :mrgreen: :lol: :mrgreen:
... "But hey said it couldn't be done!" :twisted:

Same mesh as before, for the dome; but now looking MUCH smoother, thanks to two hacks.

Image

The first hack trims the sharp corners around the outline, so that the geometry is less apparent.
Just a little trim, that's all; --merely blunting the sharpness of the corners.

Image

The second hack corrects for the distortions caused to normals by standard normal interpolation. It does this by NOT normalizing the vnormal right away. Instead, it measures its length, subtracts that from one, and divides the result by the dot product of the interpolated normal and the face normal. This quantity is then multiplied by the face normal, and the resulting vector is added to the interpolated normal. Should be length one, after that, but just in case I normalize it anyways.

Image

But ... but ... but ... How can a shader know what the face normal is?
Well, mine just figures it out, out of the vacuum :D
Here's HARD proof:

Image

BUAHAHAHAHA :mrgreen: :lol: :mrgreen: :lol: :mrgreen:


EDIT:
Not sure everyone will get the full implications...
This means that now I can write a "flat_shader" for greebles.
Many greebles often need flat shading; but flat shading is extremely expensive, because it splits every
vertex into as many vertices as the number of faces that meet at that point.
When you flat-shade geometry, the vertex count goes through the roof.
With the "flat_shader", you can put all your greebles in a separate mesh, select all, remove doubles,
and set smooth. They will look like crap in blender with smooth shading, but bear with me...
Export to obj, mesher to bfxm, mesher again to xmesh, specify technique="flat_shader", and mesher
back to bfxm. Voila! Flat-shading and FAST!
charlieg
Elite Mercenary
Elite Mercenary
Posts: 1328
Joined: Thu Mar 27, 2003 11:51 pm
Location: Manchester, UK
Contact:

Re: UberShader

Post by charlieg »

That looks brilliant chuck.
Free Gamer - free software games compendium and commentary!
FreeGameDev forum - open source game development community
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Re: UberShader

Post by chuck_starchaser »

Thanks!
And I have good news from another quarter... Klauss has committed the cubemaps code!
And I'm testing it now; it works like a charm.

Now the pressure is on me and Jason.

On Jason, because if we can't compile for windows soon, we're just going to have to leave
that platform behind, as we move forward.

On me because what the dds cubemaps really shine at is shininess modulation. Well, the
high end shader does have shininess modulation, so I guess I'll upgrade that one a bit as
we make cubemaps official. And I can release the sheet_glass shader already. It's not
perfect yet, but its bugs may not even be noticed ((psst.. real lights don't reflect on it
any more, don't know why; only the environment does)).

We need someone who knows svn to make a windows tag or branch. I don't want to
risk the repositories by trying to do it myself.
Specifically, I have new shaders and techniques to commit to data, but I can't, because
if I do I will break windows users.
snow_Cat
Confed Special Operative
Confed Special Operative
Posts: 349
Joined: Thu Jan 05, 2006 12:43 am
Location: /stray/
Contact:

Re: UberShader

Post by snow_Cat »

^ . . ^ (awed)
Deus Siddis
Elite
Elite
Posts: 1363
Joined: Sat Aug 04, 2007 3:42 pm

Re: UberShader

Post by Deus Siddis »

Looking very sharp. VS has needed this kind of visual clarity for a long time.
klauss
Elite
Elite
Posts: 7243
Joined: Mon Apr 18, 2005 2:40 pm
Location: LS87, Buenos Aires, República Argentina

Re: UberShader

Post by klauss »

First, sorry about editing your post - I didn't even notice :-(
chuck_starchaser wrote:EDIT:
Not sure everyone will get the full implications...
This means that now I can write a "flat_shader" for greebles.
Many greebles often need flat shading; but flat shading is extremely expensive, because it splits every
vertex into as many vertices as the number of faces that meet at that point.
When you flat-shade geometry, the vertex count goes through the roof.
With the "flat_shader", you can put all your greebles in a separate mesh, select all, remove doubles,
and set smooth. They will look like crap in blender with smooth shading, but bear with me...
Export to obj, mesher to bfxm, mesher again to xmesh, specify technique="flat_shader", and mesher
back to bfxm. Voila! Flat-shading and FAST!
Beware, I noticed flatness with simpler shaders. I believe there's some form of flatness on the mesh itself, not sure where it would come from.
Oíd mortales, el grito sagrado...
Call me "Menes, lord of Cats"
Wing Commander Universe
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Re: UberShader

Post by chuck_starchaser »

Thanks all. Nice to see you back Deus.
Klauss, what I'm doing is passing vertex position from the vp to the fp, in gl_TexCoord7. Since interpolation is linear, we get a position on the triangle's plane for every fragment on it. Right?
Now, in the fp, I take screen-space differentials of this interpolated position. So I get two tiny little vectors on the plane of the triangle that are projections of screen-space pixel pitch. Talking about dFdx() and dFdy().
What matters is that the two little vectors are both on the plane of the face. So the face-normal is simply the normalized cross-product of the two. Voila!
klauss
Elite
Elite
Posts: 7243
Joined: Mon Apr 18, 2005 2:40 pm
Location: LS87, Buenos Aires, República Argentina

Re: UberShader

Post by klauss »

chuck_starchaser wrote:Thanks all. Nice to see you back Deus.
Klauss, what I'm doing is passing vertex position from the vp to the fp, in gl_TexCoord7. Since interpolation is linear, we get a position on the triangle's plane for every fragment on it. Right?
Now, in the fp, I take screen-space differentials of this interpolated position. So I get two tiny little vectors on the plane of the triangle that are projections of screen-space pixel pitch. Talking about dFdx() and dFdy().
What matters is that the two little vectors are both on the plane of the face. So the face-normal is simply the normalized cross-product of the two. Voila!
LOL
So simple and so elegant... congrats...

(still, I did see flatness, I'll check the meshes).
Oíd mortales, el grito sagrado...
Call me "Menes, lord of Cats"
Wing Commander Universe
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Re: UberShader

Post by chuck_starchaser »

Hehehe, thanks. Yeah, the consequences of being able to do this are staggering.
It's like finding the lost continent of Atlantis and a couple of vimanas in your
basement and wondering who to call first. And it takes so little code it could be
put into all our shaders right now.

I'm thinking of using a texture channel to control shading:
  • With a value of 1.0, you get an ultra-smooth mesh without needing to bake a normalmap from a fine mesh.
  • With a value of 0.0 you get flat-shading without the high vertex count cost.
  • With a value of 0.5 you'd get a "beveled" look without having to put extra cuts.
Almost too good to be true.

Question is, which texture channel? They are all used up.

OTOH, this should perhaps be a new bloodline of shaders, because a mesh that
is optimized to work with shader control of normal smoothing would probably
look totally wrong in a shader without that capability. So, we're talking about
a new family of high, medium and low shaders sharing this feature, so we
might as well plan for a new texture: with one channel for smoothing and
the other three maybe for detail control.

Or, maybe we should say "to hell with a new bloodline", add the feature to all our shaders,
but just make the texture optional. The defult texture would probably have a value of 0.77
for smoothing, and and all detail control options at OFF.

EDIT:
Question:
If the technique specifies a default "foo.texture", does the engine first check in the unit's
folder for foo.texture, and if it's not there then looks under /textures?
Because, if so, then rather than specify "white.png" and "black.png", it would be smarter
to specify "diffuse.texture" and "specular.texture", etceteras.
This way, to change textures from default one wouldn't need to edit the mesh, but rather
just throw a texture in the unit's folder and name it what it's named in the technique.
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Re: UberShader

Post by chuck_starchaser »

Progress shots... Agri base done; flat shader kind of done; glass shader updated, but
with a new bug.

Image

Image

4:30 am; time to go to bed.
snow_Cat
Confed Special Operative
Confed Special Operative
Posts: 349
Joined: Thu Jan 05, 2006 12:43 am
Location: /stray/
Contact:

Re: UberShader

Post by snow_Cat »

^ - -^ Reminds me of the astrodome.
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Re: UberShader

Post by chuck_starchaser »

There's a few bugs still, in the glass shader I'm using with the domes (the glass part working okay, but the diffuse mix-in part not), so it should improve; but if I can't make the chicken wire look less trashy I'll just get rid of it.
charlieg
Elite Mercenary
Elite Mercenary
Posts: 1328
Joined: Thu Mar 27, 2003 11:51 pm
Location: Manchester, UK
Contact:

Re: UberShader

Post by charlieg »

I don't see that wire mesh ever looking good. The problem it suffers from, other than looking totally flat, is that it connects inconsistently with the main hull, which makes it look totally out of place / unnatural.

You'd be better off with a texture or shader that made every seam between the flat surfaces of the dome look like a metal joint. Then it would all come out the hull in the same manner and look nice and uniform.
Free Gamer - free software games compendium and commentary!
FreeGameDev forum - open source game development community
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Re: UberShader

Post by chuck_starchaser »

charlieg wrote:I don't see that wire mesh ever looking good. The problem it suffers from, other than looking totally flat, is that it connects inconsistently with the main hull, which makes it look totally out of place / unnatural.

You'd be better off with a texture or shader that made every seam between the flat surfaces of the dome look like a metal joint. Then it would all come out the hull in the same manner and look nice and uniform.
I think you're absolutely right. The best thing to do with the damned mesh, really, is to get rid of it. Sorry to whoever's the artist, but the only way to apply a mesh to a sphere uniformly would be by using an icosphere, unwrapping hexagons and pentagons individually, and putting metal seams around them, or something along the lines. Flat-mapping a sphere to a circle and then putting a pattern on it is simply unacceptable, aesthetically.
So this wire-mesh texture goes to the recycling bin, and the domes become pure glass, for now anyways.
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Re: UberShader

Post by chuck_starchaser »

Done.

Image

And with this goes the bug I mentioned in the glass shader. I had removed all diffuse and metallic specularity code from it, which was good; but then I put it back for the sake of the chicken wire, and that had a bug; but now I took out that code again, --I hope for good. Not to say the glass shader looks perfect, but good enough for now. This glass shader is in the same complexity/quality level as the (updated) highshader; not in the highshaderplus bin, much less in the uber bin, much much less in the CineMut realm; just high-shader, so it's supposed to look a bit crappy :)
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Re: UberShader

Post by chuck_starchaser »

Have only just started with the diplomatic station; been mostly debugging and
hegemonizing the shaders, and testing with the agri station.

Image

Image

Image

Sorry it's a crappy job I did on the agri base; just a half-assed normalmap, and a crummy ao, and
a plain shininess. Thing is, to do anything better I'd have to trash the existing unwrap, as
it's full of ovelapping islands. Unfortunately, nothing in Vegastrike is properly unwrapped.
By the way, notice the star reflected in the lake:

Image

I don't want to commit anything yet; too buggy an not much art using the better shaders.
For those wanting to live on the bleeding edge, though, what you need to do is compile
the engine with cubemaps, first of all:

Code: Select all

make clean
./bootstrap-sh
./configure --enable-cubemap
make
Then you need to replace your shaders with cubemap-enabled variants; just unzip this file
in your /programs folder:
http://wcjunction.com/ftp/programs.tar.gz
Then you need techniques that call the updated shders. Just unzip the next file in the
/techniques folder:
http://wcjunction.com/ftp/techniques.tar.gz
And then you need a model that uses the techniques. Here's the Agricultural base; just
unzip it in /units/installations/Agricultural-station:
http://wcjunction.com/ftp/Agricultural_Station.tar.gz
Post Reply