CineMut shader family - Opaque

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

Moderator: Mod Contributor

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

Re: CineMut shader family - Opaque

Post by chuck_starchaser »

FINALLY...

I think Klauss and I have a conditional agreement on the following packing:

Image

Many explanations are due. Starting from the top...
  • Some of you might notice ALPHA, back together with the main color, in an alpha channel, and
    without a sad face. Had a change of heart on Alpha: It's a meaningless term, from a point of view
    of optics and physics; but NOT having it would preclude rapid, automatic conversions of existing
    models to CineMut-compatible format; and would interfere with uses of alpha as per putting holes
    into things, via alpha-testing, which is a common technique. So alpha is back without regrets.
  • Mix-in color and Age Alpha... We were talking in some PU forum about whether it makes sense
    for a brand new ship you buy to show rust. Well, it doesn't; but if you see a ship of the same type
    that's been around a while, it makes more sense. Rust and scratches and to some extent dirt, are
    connected to a ship's age. Combat may result in "rapid aging" to some extent; but it won't put thick
    rust on your engines. I think that age should be a parameter passed to the shader, just like damage
    is. So, the idea here is to have the rust or scratch or dirt color in the mix-in color channels, and a
    sort of logarithmic encoding of rust clouds and scratch lines in the Age Alpha channel. The shader
    would apply age-dependent gamma to the alpha channel, then blend the RGBA with diffuse; and
    lower specularity and dielectric purity inversely with the gamma-ed Age Alpha.
  • Iridescence is something new in this packing. I'm not entirely sure what it IS, yet, but I know we
    need it for titanium rusts :D Probably a normalized dielectric thickness. I have to read up on it.
    Iridescence is what makes some materials show rainbow-like reflections that change with angle.
  • There's now a whopping 5 channels for detail control. This might seem excessive, but I believe
    it isn't. Thing is, we need to control,
    • the intensity of detail texture application
    • whether it puts bumps on the normal map and/or
    • whether it puts clouds in the shininess map and/or
    • whether it puts noise in the diffuse color, and if so,
      • whether it should look like sparse white dots or
      • black dots or
      • some perlin noise in-between
    • frequency of the detail map (big or small tiling)
    Plus, we may have a second detail texture for random direction scratchiness; and/or a custom detail
    map for representing evenly tiled surfaces.
    So... I'm not even sure how to control all that from 5 texture channels.
  • The bent normal is no longer in a separate, un-compressed texture; but that means we need to use
    special tricks to get some precision out of dxt5 compression. So, I'm repeating the U and V in 3 rgb
    channels each, and will encode it with offsets so that the steppings in the encoding are staggered,
    for a rough total precision of 7 bits. The Z is the most critical and so it goes in an alpha channel, which
    is 8-bit.
  • The UAO, CAO and bump height are in alpha channels also, for maximum precision.
  • Radiosity took a big hit, and only gets 6 RGB channels; but that's okay: self-radiosity is a subtle
    effect and doesn't need a lot of precision.
  • As explained before, for a fighter, all sub-textures are 512x512 except the normalmap is 1024.
  • So, each atlas is 1024x1024. Three atlases plus the 1024 normalmap = 4 million texels. And 4M
    texels is equivalent to having a single 2048 texture. I don't think this is bandwidth-excessive at all.
I called this a "conditional agreement" because Klauss is not sure about what effect doing four reads
per texture might have on performance. His concern is with texture cache: Four reads around the
same place are probably okay because of locality; but 4 reads spread around the texture might be
problematic. His contention is that this requires testing and that we shouldn't set the texture packing
in stone before we have more data. I, on the other hand, wanted to have a packing we can start
with, and modify later if necessary; just to push the project forward.
But so, what this all means is that instead of three 2x2 atlases we might have six 2x1 atlases (what
are currently labeled sub-atlases would become atlases); or that we might end up with a whopping
13 textures.
However, if any of that happens, the internal structures will probably stay as they are.
Crossing fingers...

On other news, I wrote a wiki "home" page for CineMut:
What is "CineMut"?

And another for LaGrande:
What is "LaGrande"?
charlieg
Elite Mercenary
Elite Mercenary
Posts: 1329
Joined: Thu Mar 27, 2003 11:51 pm
Location: Manchester, UK
Contact:

Re: CineMut shader family - Opaque

Post by charlieg »

Don't forget to post this packing table in the CineMut wiki page (or another page linked from there).
Free Gamer - free software games compendium and commentary!
FreeGameDev forum - open source game development community
Sindwiller
Merchant
Merchant
Posts: 32
Joined: Sun Aug 10, 2008 10:31 pm
Location: Zürich, Switzerland

Re: CineMut shader family - Opaque

Post by Sindwiller »

Ace stuff, as everyone said - How is the development going along though? :)
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Re: CineMut shader family - Opaque

Post by chuck_starchaser »

Hey, Sindwiller!
It's been going slow but semi-steady; just not at this forum. Here:
http://wcjunction.com/phpBB2/viewtopic.php?t=1353
But right now my plan is to come up with an interim shader; --a quick solution that won't
require tons of bakes and other textures, but will have some of the CineMut features.
It will only require shininess (in specular's alpha channel) and Ambient Occlusion (in the
alpha channel of the glow map).
It will not need dielectric constant or refractive index. The way it will work is it will
guess the intent of the texturer by looking at the diffuse and specular colors. If the
diffuse color is un-saturated (gray scale) and/or the diffuse and specular are similar
in color (hue and saturation), it will know it is a metal, and apply metal shading
rules. But if the diffuse channel has color (is non-gray) and the specular color is a
shade of gray, then it will know that this is a dielectric material (paint or plastic),
and will apply fresnel reflectivity, instead. In fact, specular value, in the latter case,
is meaningless, because the fresnel formula dictates the amount of specularity; --it's
not for us to choose; it depends only on view angle and refractive index. So, when
the diffuse color is colorful, and the specular color is gray, the value of the specular
color will be used to control refractive index, instead.
The limitation will be that there will be no way to represent gray paints or plastics,
as gray in diffuse will immediately lead to a "metal" assumption.
Other than that, I have an idea for how to implement rough shadows without PRT's or
bent normals; though I doubt it will work very well; but I'll try.
Not sure when it will happen; but probably very soon. Jsnmtth is trying to get the
engine to compile with cubemaps, and I'm working on a simple model, a rework of
the llama, that I will test the shader with.
Sindwiller
Merchant
Merchant
Posts: 32
Joined: Sun Aug 10, 2008 10:31 pm
Location: Zürich, Switzerland

Re: CineMut shader family - Opaque

Post by Sindwiller »

*gawps at chuck*

That is truly terrific! :D
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Re: CineMut shader family - Opaque

Post by chuck_starchaser »

By the way, I've decided to cut back on the capabilities of CineMut and to simplify it
a great deal; otherwise it will never be finished.
The way this is all going to proceed is in three stages:
  • UberShader: An upgrade from the current HighEnd shader which will impose the minimum possible changes in the current art; namely adding alpha channels to existing textures. I'll start a separate thread for it shortly.
  • CineMut1: Will collect 4 textures as they are into an atlas (unified, 4-quadrant texture), and add a second atlas. That implies, among other things, that I'm moving away from having "albedo" plus a single channel "specularity", and going back to the industry standard of having separate diffuse and specular textures. This is because filtering and antialiasing are not compatible with blending operations like multiplication; so I was going to be forced to provide rusts and scratches and dirt marks as a separate "mix-in" or "age" texture; which was an appealing proposition in the sense of having parameterized ship age; but too much complication... Also getting rid of support for radiosity, self-specularity, occlusion ellipticity, surface curvature channels and metallized paints; but I will keep the more important things such as being able to distinctly represent metals from paints from plastics, shininess control, dynamic shadows, specular self-occlusion, detail textures, soft penumbras, etceteras.
  • CineMut2: The full version, if Humanity still exists then.
Post Reply