CineMut shader family - Opaque

[chuck_starchaser]

I'm supposed to be at work already today; super-late, so quick update before I leave.
Tentative materials are assigned.

First the layout mask:



Diffuse:



Specular:



Shininess:



Dielectric constant:



Dielectric blend:



And I didn't need a real damage channel for the test; but I do need a damage texture, because some
of its channels are not related to damage but rather to materials; and I've been fancying a new methodology
to represent damage, and it actually involves the shader, so I said heck, might as well do it.
So here's the damage baking setup:



Here's the "damage_ao" bake:



And here's what it looks like when applied to the model as a texture:



Before packing the textures, the "damage_ao" has to be converted to an "ao_darkener" channel, which
involves dividing by the plain ao. This will be done by LaGrande; no time to get it done and shown now, but
at least here's the plain AO bake:



And the AO applied as a texture:



Notes:
AO means "Ambient Occlusion".
The fat colorings are because I have margin set at 32 (the maximum) in Blender; which means that from
the edges of islands, the edge color is extended outwards 32 pixels. Long story; gotta go. Cheers!

[chuck_starchaser]

Tonight I'll try and get a Blender noodle to pack those textures the way the shader wants them.
Probably won't be able to finish that tonight; gotta make it generate damage dU/dV modifiers, etc. Then...

• I have to come up with a generic detail texture.
• Then I have to use ATI's CubeMapGen to produce a cubemap. I did this already last week, but my computer crashed
  before I saved.
• Then have to get help from Klauss and Safemode to get a VS engine branch compiled with Techniques, Tangents AND
  cube map environment map support.
• Then, with Klauss' help, put together a technique.
• Then get a modern version of mesher with techniques, and produce a bfxm of the bike model that calls the technique.
• Then make an entry for the bike in units.csv.
• Then setup a test mission for viewing the bike in space.
• Then start testing and debugging and make the CineMut Opaque shader work.
• Then copy the CineMut Opaque shader and modify to make a CineMut FireAndGlass shader (for exhaust plumes, lights
  and glass cockpits and stuff.
• Debug that one.
• Then play around with the materials for a few days, and come up with a first rudimentary materials library, while fine-
  -tuning the LaGrande noodle(s).
• Then, and this is going to take a bit of time, I have to come up with a couple of lobotomized versions of the shaders
  for medium and low shader settings, to support older videocards while still being able to use its texture packing format.
• Then write a wiki page on how to use the Blender materials library, LaGrande and the techniques.
• Get a bit of feedback from Vegastrike artists and do final fixes and adjustments.

[pyramid]

Wow, still a long list of tasks. I'm very curious to see it all working together and barely can wait for the climax to come.

I've just started to restructure the 3d models listing page to get things organized for the retexturing. And I'm really missing the spec for textures. It may be that the packing schema still gets a change, so I prefer to wait until the Noodle is complete and at least preliminary tests are done.

Keep it up!

[chuck_starchaser]

Thanks. I'll make LaGrande so that it takes input from diffuse and specular, to make it easy to convert texturings; but you will need a specular texture.
What I could make is another noodle with ad-hoc ways to come up with a specular texture from a diffuse, to make it easier to get things started for models that lack specular. Essentially, spec = (1,1,1) - diffuse for low saturation materials (metals assumed); and spec = diffuse * (1-diffuse_luma) for high saturation materials (paints), or something along the lines.
Hmmm... Never mind, this would never work.

[chuck_starchaser]

Thought I'd show this: Dividing the damage_ao by the plain ao, in a LaGrande sub-noodle, works like a charm;
it leves in the damage darkenings and pretty much nothing else.



Now I just have to use this resulting texture as if it were a height map and generate dU/dV normalmap-like
channels, that are blended with the standard normalmap at runtime, in the shader, in proportion to damage.

[chuck_starchaser]

True, but I kind of feel that way about alot of material types beyond even glass, plastic and paint. Organic stuff for instance, like animal and plant surfaces where the light is actually penetrating partially or entirely (example, sunlight going through banana leaves in Crysis trailers).

Organisms rarely show metalic surfaces, ergo all organic reflectivities are dielectric. Human skin's specular color is white, regardless of skin color. As for the rest of it, you're talking about a modern shader technique called "sub-surface scattering". I hope to have a member in the CineMut shader family with that capability, eventually. Unfortunately, a shader capable of *everything* would not fit in any gpu; a degree of specialization is necessary. So, for living things we'll eventually have a special shader with SSS capabilities.

Besides, having separate diffuse and specular colors lends itself to having incorrect and impossible materials.

Well, in some mods, intelligent use of 'incorrect' materials might mean more 'alien' looking materials that enhance the game's visuals. So maybe fresnel and material influenced specular color wouldn't be a terrible combination for a shield effect or the surface of an alien hull.

Might be a good idea to let the artist choose these things if they don't look absolutely buggy and terrible, instead of modern realworld physics as dangerous as that sounds. Though haven't tried anything like this yet myself.

Can't do. The shader is done; it is monstruous in size, and it does one thing and does it well: Realistic, opaque materials. There's no texture slots left to specify fantasy materials, and no instructions left either. Besides, a material that is red in diffuse and cyan in specular is not just not real but not even possible. And a material that is white in diffuse AND white in specular is also not possible; --and looks like crap. CineMut uses a lot of tricks to get all the necessary info it needs into 5 input textures plus detail plus environment; and this "compression" resulted in a beautiful consistency that precludes the definition of impossible materials.

So basically, diffuse and specular will get replaced by the albedo texture right?

Exactly. Albedo, plus a channel that expresses how much of that albedo is to be taken away from diffuse and given to specular.

As for the question of localized damage, that's been explored many times and it's a herculean task to program.

Really? Because its been implemented in alot of games, including open source games, albeit to the environment instead of the actors (like ships or characters). And none of those games have anything even close to what you are talking about here.

Precisely, the environment can be done because there's only one. But when you have 70 ships of the same kind in a scene, they all share the mesh and textures. To be able to manage damage per-chip, you'd have to load separate instances of them in the videocard, each with its own set of textures. But already we have problems with textures needing more video memory space than is available.

From which it will compute normalmap modifiers, --"damage dU/dV" channels that are also part of the texture package, and that will be blended with the standard normalmap normals at runtime, in the shader, in proportion to damage.

Wow, so then it will look like layers of your armor have been ripped off clean. I wonder if you could make the edges where there is alot of contrast render in the glow shader as bright orange for a while, so that they looked close to molten.

Yeah, that could be added. I'll think about it.
EDIT:
No, can't do; not without some engine code changes, as the heat of damaged areas should gradually cool down after battle, but shaders can't have static variables; so the shader can't do the cooling without a variable coming from the cpu; --a sort of leaky integrator of ((d-damage/dt)^2)*dt or something.

The good news is you won't have to look up dielectric constants of materials in chemistry books; there will be a library of materials you can pick from and apply to your model in Blender, including many metals, plastics, ceramics, high, medium and low gloss paints and whatnot; then you bake textures, and then LaGrande will take those input textures and spit out textures for packing with the mesh file. Somewhere along that line, you'll be able to take the intermediate textures and add your art to them, of course. The bakings are only a way to get the basic materials right.

Sounds like a smooth pipeline. When would you guess this will be available? It will be open source right?

Certainly Open Source; it will be done when it will be done Check the task list a couple of posts ago.

Finally, this is unrelated to global illumination and its two 'PRT-N' / 'PRT-P' maps mentioned on the wiki in the shader how to? I'm trying to get an idea for what the final list of maps for a 3D model will look like, if the GI is indeed a separate thing it will look like this:

Normal
Albedo
Glow
Shininess
Damage
PRTN
PRTP

True?

Not quite true yet... Currently, CineMut doesn't have GI; but I asked Klauss the other day if he'd like to add it and he appeared interested in doing so. Let's cross our fingers.

[chuck_starchaser]

Damage normals, created from the damage_ao bake divided by the ao:



The blender noodle so-far:

http://deeplayer.com/vs/shaders/testmodel/shot05.jpg

This noodle will be LaGrande's front-end.

[pyramid]

I see your renders are in blender. Though it's already on your roadmap/tasklist, it still might be already a good point in time to try put the moto into VS so that the techniques could be worked on in parallel.
The noodle looks complex. Too bad the top part is cut off (I'm missing the normal texture). And what is the top one input texture "k.png"?

Since I'm working on the requirements, you confirming the final INPUT textures requirements. My understanding is that the model requires 9 input textures:
* diffuse
* normal
* damage
* specular
* shininess
* dielectric
* detail
* glow
* ambient_occlusion

which then will be encoded into the 4 or 5 final textures.

Where some of the input textures might be generated automatically by an alternative noodle (e.g. detail, damage) or with a materials catalog even specular, shininess, dielectric.

I think the way to go is to define minimum requirements that an artist has to create by hand (diffuse + glow + normal) and imagining a perfect noodle+materials catalog+blender script combination we could come up with the rest automatically.
These requirements would start will all the input textures currently (as long as the automatism is not available) and be reduced as you (we) progress with the scripts.

Btw, currently I am not able to integrate the new models (Derivative, Xuanzong) into the data set correctly. They simply show as black shapes no matter how I tweak the xmesh. Strangely, some other existing models show up ok (Hawking), some others do not (Goddard). The reasons might vary (ATI drivers, techniques, shader, old win mesher, wings export....). Without cross-debugging from others I am unable to proceed. The same issues plague me on win & linux.

[chuck_starchaser]

I see your renders are in blender. Though it's already on your roadmap/tasklist, it still might
be already a good point in time to try put the moto into VS so that the techniques could be worked on in parallel.
The noodle looks complex. Too bad the top part is cut off (I'm missing the normal texture). And what is the top
one input texture "k.png"?

Been working like 12 to 14 hour days for the past week; that's why this has been going slowly.
Yeah, I intend to throw it in-game for tests as soon as I have the full texture packing noodle working.
The first input at the top is dielectric_blend.png; the second is dielectric_k.png.
Here's the file (minus the textures, or it would be a bid download):
http://deeplayer.com/vs/shaders/testmodel/noodle.blend

Since I'm working on the requirements, you confirming the final INPUT textures requirements.
My understanding is that the model requires 9 input textures:
* diffuse
* normal
* damage
* specular
* shininess
* dielectric
* detail
* glow
* ambient_occlusion

Actually, I lied; this noodle is not really the front end. Right now I have a lot of black and white textures at the input.
I produced those one by one in Blender by going through all 15 material indexes each time, and adjusting diffuse color.
So, for example, for dielectric constant (k): I started from the first material, BluePaint and said "this should be medium"
so I made it 50% gray; next, blue plastic, I said "this should be high", so I made it white; next, some metal, "should be
none", made it black; and so on.
Then baked dielectric_k.png.
Then I started again with dielectric blend in mind: Paint, made it white; plastic made it about 60% gray, and so on,
and baked that as dielectric_blend.png.
Etceteras.

I did this just for expedience, for now. Once we have a library of materials, it will work differently: You'll pick materials
from a library blend file and assign them to selected polygons on your model. Blender defines three colors per
material, and what I'm planning to do is use 2 of those 3 colors to encode all the material characterization channels
in a format somewhat similar to the final packing format. So, dielectric k will be in the blue channel of specular;
dielectric_blend will be in the green channel of specular, etceteras. The third color would be used for glow color,
like for lights.
In fact, what the real front-end noodle will do is *separate* some of those channels into gray-scale, independent
textures, so that the artist can more easily manipulate them.
So this noodle I'm working on now is actually the second noodle in the chain. Well, not really; this is actually
the Packer Noodle. See further down.
EDIT: Well, it's none of the final noodles, really; just a quick shortcut to get results in a hurry.

And so, the input requirements will be:

• 2 material-related textures from Blender: You could call them "albedo" and "blend". Albedo will have
  the r,g,b material color and probably shininess in alpha; then Blend will have spec-to-diff balance in red channel,
  dielectric blend in green channel, dielectric constant in blue channel, and detail modulation in alpha.
• Glow bake (from the third Blender material color, usually black, but some color for emissive items)
• AO (ambient occlusion) bake (AND/OR two bakes: PRT-P and PRT-N, if/when we end up adding
  Klauss' GI to the shader)
• DAO (damage ambient occlusion) bake (with random occluders around)
• Smoothing Normalmap bake (baked from Blender; encodes corrections from a high-poly version of the mesh
  onto the low-poly mesh)
• Static light map bake (using Blender's Radiosity Baking)
• Front-lighting bake (also using Blender's Radio Bake, but using a single light source in front of the ship.
  This bake is used to modulate frontal and front-to back effacts, such as high temperature rusting, and
  micrometeorite impact damage)
• Bumpmap (artist-supplied texture; not a bake)

I hope I'm not forgetting something, but what are the chances?

which then will be encoded into the 4 or 5 final textures.
Where some of the input textures
might be generated automatically by an alternative noodle (e.g. detail, damage) or with a materials catalog
even specular, shininess, dielectric.

I think the way to go is to define minimum requirements that an artist has to create by hand (diffuse + glow + normal)
and imagining a perfect noodle+materials catalog+blender script combination we could come up with the rest
automatically.
These requirements would start will all the input textures currently (as long as the automatism is not available) and
be reduced as you (we) progress with the scripts.

Well, the LaGrande process will go like this:

• You take all the above and put them through LaGrande's Separator Noodle, which separates many of those
  channels so that they are easier to work with. So, dielectric constant ends up having its own texture, for example,
  gray-scale.
• Now you can do what artists do: add details and greebles and whatnot. But on the initial texturing rounds,
  for a given ship, you'd skip this, to try and get just the materials; so that you can test-in game, and change
  the materials in Blender if they don't look right, and re-bake some of the texture; repeat until materials look
  exactly right; then you do the detail work. Detail work is a bit of work, in that if you want to show teflon-insulated
  wires on a metal surface, you need to draw them in all the material channels at the same time, as they have
  not only a different color, but different specularity, shininess, dielectric constant, etceteras. I will probably,
  eventually, write a small program to help with this stage, so that you can provide per-material masks, and the
  program will modify all the textures for you.
• Now you feed ambient occlusion, front bake, bumpmap, and a few other textures to the LaGrande's Streaker Noodle,
  which will generate dirt-streaks that start at bumpmap features and fade towards the back of the ship.
  It will also generate scratches.
• Another noodle, the Ruster Noodle, will generate various types of rust; but it will need some extra masks from
  the artist to select rust type. High temperature, titanium-like rust will need no masks, as it is modulated by the
  front light bake.
• Perhaps I'll have a Bleacher Noodle to modulate paints so that they lose a bit of blue channel brightness in the
  most exposed (sun-scorched) areas.
• Now you feed all the modulated textures to the LaGrande Packer Noodle, which will generate game-model-ready
  textures. They will be PNG's, as Blender doesn't have a DDS encoder. You'd try them in-game as PNG's until the
  textures are final, then use nvcompress to turn them into DDS's.

Btw, currently I am not able to integrate the new models (Derivative, Xuanzong) into the data set correctly.
They simply show as black shapes no matter how I tweak the xmesh. Strangely, some other existing models
show up ok (Hawking), some others do not (Goddard). The reasons might vary (ATI drivers, techniques, shader,
old win mesher, wings export....). Without cross-debugging from others I am unable to proceed. The same issues
plague me on win & linux.

Hmmm... I've no idea. On the other hand, I've always used a very old but very stable version of mesher, from
back in the days of PR, as I always had problems with any meshers that came after that. If you want to try it, it's
the one I have in the wcjunction SVN utilities folder:
https://svn.wcjunction.com/utils/mesher
Username is 'username'.
Password is 'password'.
EDIT:
I once had an invisibility problem, and I emailed Hellcat, and he suggested I try changing the order in which I was
loading the submeshes; so I did, and it worked like a charm.

[pyramid]

I see there will be some processing steps required, where the artistic texture contribution will be actually put somewhere in the middle, in the sense that:
1) Artist will import model into blender
2) Will assign materials to mesh
3) A preprocessor will generate the intermediate textures
4) Texture artist will add specialties (diffuse color changes, dirt, rust, glow color, greebles, ....) e.g. in GIMP
5) Packaging noodle will use this reworked input textures and spit out the final masters
6) The rest then is data integration work (mesher, DDs compression, ...)

With this, I'd expect that with the first pre- and post-processor noodles the artist will be probably spared a lot of work at least on the material input textures spec, shininess, dielectric_k & _blend, which is good news.

[chuck_starchaser]

The news is actually a bit better than that:

Dirt streaks and scratches will require NO artistic input. They will be generated completely automatically
by the Streaker Noodle. There will just be parametric input nodes you can use to regulate the opacity and length.
http://wcjunction.com/phpBB2/viewtopic.php?p=8038#8038

Rust will be almost completely automated. High temperature rust will be fully automatic, whith just an intensity
control; and other kinds of rust will merely require a mask input, for the artist to indicate where he/she
wants rust, or how much.
http://wcjunction.com/phpBB2/viewtopic.php?p=8293#8293
Rust will automatically produce paint peeling, BTW.

I forgot to mention the Static Bump-Lighting noodle. You'll feed it the ambient occlusion and radiosity bakes
together with the bumpmap, and it will produce bump-modulated versions of ambient occlusion and radio bakes.
http://wcjunction.com/phpBB2/viewtopic.php?p=8133#8133
And that's a very early version; my latest was working much better but I accidentally deleted the folder...
Rather than arbitrarily shade, it computed a surface normal, an ad-hoc "light direction" (by differentiating the
light baking) and then used N dot L to modulate brightness.

So, the only artistic input needed will be the basic materials, and then greebles and construction details like seams and rivets.

[chuck_starchaser]

I started writing down a detailed organization and use guide for the upcoming La Grande texture tools, while
waiting for Blender to radiosity bake the motorcycle; but then I got carried away with the writing and finished it.

I split it into two parts:

Texturing with Blender (for CineMut Opaque shader and La Grande noodle)

and

Understanding and using the La Grande Noodle

This is good, because so far I've created about 3 or 4 dozen noodles, all intended originally to be bits and
pieces of LaGrande, but all having quirks specific to a given model, that I wasn't even aware were specific,
at the time. Plus, I never had a sharp, detailed image of how all the pieces fit together.

There's a lot of wisdom to the idea of writing the User Manual before you write the code...

[loki1950]

There's a lot of wisdom to the idea of writing the User Manual before you write the code... Wink

then you really have to watch out for feature creep then

Enjoy the Choice

[pyramid]

Great bedtime reading. I wasn't aware of the extension of processing that might be involved but it's well anchored in my mind now. Thanks!

Regarding the comment "A Gimp script is provided to convert texture0.png through texture4.png to texture0.dds through texture4.dds" in "Understanding and using the La Grande Noodle", safemode has been explaining this in one of his threads, as far as I can reconstruct Gimp dds conversion is not recommended since the Gimp dds converter uses hardware compression which may vary the quality of the results depending on the GPU and driver version used. The preferred conversion would be using nVidia's nvcompress.

[chuck_starchaser]

Yes, I'm aware of the problem, but nvcompress never worked for me for textures with alpha channel. Then again, maybe the problem has been resolved and I just need to upgrade...

[pyramid]

I think for DXT1 you need to explicitly specify an option to produce the alpha channel (though that's probably out of question anyway due to its 1bit alpha encoding), while with DXT3 ad DXT5 it would be standard, not sure though as I've reinstalled my system and don't have nvcompress at hand and it's bed time now.

[chuck_starchaser]

I was talking about DXT5. Nvcompress would produce DDS textures with weird colors when I gave it a texture with alpha channel and specified DXT5.
I'll see if there's a newer version.

[chuck_starchaser]

Just reposting the texture packing. No changes except the change of names. Since texture channels are
mixed all over the packing, it no longer makes sense to refer to textures by descriptive names. Instead,
might as well follow the names of the variables in xmesh, make it easier to edit that file without having to
look up info on what texture5 is supposed to be.
Heck, not even diffuse is really diffuse anymore; rather "albedo", so to hell with it. And by having standardized
texture names, we can make them the default in the the upcoming Visual Mesher tool; and LaGrande can be
hardwired to save files by those names. So, here they are:

tex0.texture (was "diffuse")

Code: Select all

(basic mat albedo; sent to diffuse/specular in (1-SPEC.r)/SPC.r ratios, respectively.)
 R (5) = red
 G (5) = green
 B (5) = blue
 A (1) = alpha (just a 1-bit alpha, for alpha-testing only; transparent materials use another shader)

tex1.texture (was "specular")

Code: Select all

(This texture controls metallic and dielectric specular properties and gloss.)
 R (5) = spec_to_diff_balance (0 for matte materials; high for metals, 1 for mirrors)
 G (6) = damage AO darkener (dark for smoke marks, black for holes)
 B (5) = dielectric_constant (spans 1.0 - 21.7; controls fresnel --spec as f(view angle))
 A (8) = shininess (spans 1.0 thru 100 to 30,000; applied to dominant specularity type)

tex2.texture (was "damage")

Code: Select all

(Damage darkens the ambient occlusion and perturbs normals, applied per % damage.)
 R (5) = damage normal dU modifier
 G (6) = detail_blend (NOT part of damage; controls detail texture use; see detail texture note below.)
 B (5) = damage normal dV modifier
 A (8) = dielectric_blend (0 = clean metals or pure matte paints, 0.7 = plastic, 1.0 = glossy paint)

tex3.texture (was "glow")

Code: Select all

(baked lighting in rgb; ambient occlusion in alpha)
 R (5) = red baked ligth (encoded with gamma = 0.5)
 G (6) = green baked ligth (encoded with gamma = 0.5)
 B (5) = blue baked ligth (encoded with gamma = 0.5)
 A (8) = ambient_occlusion (AO)

tex4.texture (was "normal" (and still kind of is))

Code: Select all

(normalmap)
 R (5) = 0.5*tan(0.5*U) + 1/127
 G (6) = 0.5*tan(0.5*U)
 B (5) = 0.5*tan(0.5*U) - 1/127
 A (8) = 0.5*tan(0.5*V)

The detail texture for CineMut will be universal, specified by the technique file as found in the /textures folder:

detail.texture

Code: Select all

(detail texture; perlin noises tiled multiple times across regular texture)
 R (5) = detail normal dU modifier perlin (low frequency)
 G (6) = detail wildcard modifier perlin (high frequency)
 B (5) = detail normal dV modifier perlin (low frequency)
 A ([size=12]8[/size]) = detail shininess modifier perlin (medium frequency)

[chuck_starchaser]

The look of tex_1 on the model:



What the hell's that?!

Well, alpha encodes shininess, so the tires and stuff look transparent because rubber has low shininess.
Red encodes specular to diffuse balance, so red stuff has a lot of metallic specularity.
Blue encodes dielectric constant. Plastic parts have a very high k so they look blue.
And green encodes dielectric balance, so the fuel tank and fenders, which are painted high gloss, look kind
of green because the dielectric balance is 100% (full coverage).

But why do the fuel tank and fenders look so yellowish green?
That's because green is maxed out, and red is medium, because the opaque material under the
dielectric laquer is partly diffuse, partly specular.

And why the occasional green streak?
Artifacts resulting from using (dumb) automatic unwrap.

So, it looks weird; but the important thing is that it works out

Proceeding with finalizer noodles for textures 2 through 4...
Actually, proceeding with laundry first; then dinner; then noodles.

EDIT:
Klauss, I'll probably be done with the textures tonight; I'll need your help soon with techniques.

[chuck_starchaser]

Another weird one: Texture 2



What's with the color purple?
Well, this is the sort-of "damage" texture. The alpha channel is the "ambient occlusion darkening channel", so
where you see faded holes of transparancy, those are damage areas.

Purple... Well, the red and blue channels have damage normal modifiers. Normals can go positive or negative,
which, with the unsigned nature of colors in a texture, have to be encoded as deviations from 50%. So, on average,
the red and blue channels are 50% bright, and occasionally they swing brighter or darker; but the typical
color, barring a green presence, is dark purple.

And what's green?
Green is detail blend. Notice the plastic parts are gray in this texture. That's because green is 50% there;
--same as red and blue. 50% means NO detail blend. Plastic is featureless and boring, so it gets NO detail texture.

The parts you see green is where green hovers at around 100%, which means "wavy" (normalmap jitter)
detail. The parts that look purple is where detail blend is around zero, indicating color-type detail, or "speckling".

[chuck_starchaser]

Texture 3 is a lot less weird, but it "looks" weirder than it is:



Starting with the alpha channel: Alpha here encodes the ambient occlusion (AO), so the parts that are more
exposed look more opaque; the parts that are in (ambient) shadow are more transparent.

The RGB colors are glow (emissive) color; and they come from the radiosity baking of the headlights and
positional lights.

But, doesn't it look almost like a "negative"? The more exposed areas look dark, and the more shadowed areas
look bright... What's going on?

Well, thing is, the ambient occlusion is going to the alpha channel ONLY.
The actual color, which shows more
the more opaque, is black. Why? Because RGB is the radiosity bake, and most parts of the bike didn't get
much light from the headlights.
So, most of the bike is as if it were painted black, and so the gray background is lighter than the bike.
The more shadowed an area is, the more transparent, and so the more you see the brighter background.
Conversely, the more exposed areas are more opaque, and so their blackness occludes the brighter
background.

[loki1950]

Waiting on a complete render chuck looking good so far.

Enjoy the Choice

[chuck_starchaser]

That's bad news; it's not supposed to look good...

No renders at all, this time. Engine or nothing. Actually, I could try and come up with a render of
what it's supposed to look like in-game, but... No, I can't. There's no such thing as fresnel in Blender's
internal renderer, AFAIK; so this *needs* the VS engine and CineMut and techniques...

Klauss! Where are ya? Textures are ready.

Well, I guess I can get started on exporting obj and all that jazz.

By the way, Texture 4 is not showable. No point in showing an invisible motorbike, is there? Reason
it's invisible is that the background is 50% grey, and so is the bike, and the alpha channel is 0.5 also.
Everything is 0.5. Why? Because texture 4 is the normalmap, and dU is going to red, green AND blue,
and dV is going to the alpha channel, and they are always 0.5 because I simply don't have a bumpmap,
and I never baked corrective normals.
So, instead I will show texture 0, which is the Albedo, and I never bothered to show it before:



Why's the engine so bright? Cast aluminium. Bright in specular. Remember tha albedo = diffuse + specular.
It will be tarnished by a bit of oxide (yeah, there's a bit of dielectric blend on it, and some dielectric k); and
it will be darkened by the ambient occlusion; plus, low shininess. Should look okay, but we'll see when we
start testing.

OBJ...

[chuck_starchaser]

Alright; here's the obj and mtl files. There's two of them: test_bike and test_lights. Test_bike is the bike .
Test lights is the lights and the glass covers. They will use the CineMut Fire and Glass shader, so they got no
textures yet. The mtl files have multiple materials in them; may need manual editing. Just posting the
stuff here in case klauss or anyone else wants to start playing with techniques and whatnot when I'm
at work or something.
http://deeplayer.com/vs/shaders/testmod ... t_bike.zip

One thing I found out but forgot to mention. Format for the glow texture: For a long time I thought the right
thing to do with the glow texture was to write it with gamma (i.e. square root) then square it at run-time in the
shader. Why? Because there's only a few lights requiring full brightness. Everything else (radiosity baked
from the lights) is a lot darker, and could use a bit of brightening if only to reduce dds compression quantization.

Recently I found that the whole concept was terminally flawed, as mipmaps would be generated off the
already gammafied image, and...
(a+b+c+d)/4 != ((sqrt(a)+sqrt(b)+sqrt(c)+sqrt(d))/4)^2
where, "!=" means "NOT equal".
This last point stands. No gamma.

But what I just realized today (or was it yesterday? (too much wine)) is that the bright emitters; --i.e., the
REALLY bright emitters; the lights-- should not be part of the main mesh, anyways. Why? Because every
ship has glass and has fire (engine exhaust trails), and that's stuff for the shader that is meant to do bright
things, CineMut FireGlass, so if we'll need this shader for every ship already, then might as well move
the lights to the object that has the windows and stuff; so the lights go in a separate object together with
the glassworks.
All of which means that our main mesh's glow ONLY has radiosity bakings, so we can use the full brightness
range; so the CineMut Opaque shader will change slightly: it will divide the glow texture's RGB channels by 2.

And so, speaking of the devil, I'll start working on the CineMut FireGlass shader.

[chuck_starchaser]

Then...

• I have to come up with a generic detail texture.
• Then I have to use ATI's CubeMapGen to produce a cubemap. I did this already last week, but my computer crashed
  before I saved.
• Then have to get help from Klauss and Safemode to get a VS engine branch compiled with Techniques, Tangents AND
  cube map environment map support.
• Then, with Klauss' help, put together a technique.
• Then get a modern version of mesher with techniques, and produce a bfxm of the bike model that calls the technique.
• Then make an entry for the bike in units.csv.
• Then setup a test mission for viewing the bike in space.
• Then start testing and debugging and make the CineMut Opaque shader work.
• Then copy the CineMut Opaque shader and modify to make a CineMut FireAndGlass shader (for exhaust plumes, lights
  and glass cockpits and stuff.
• Debug that one.
• Then play around with the materials for a few days, and come up with a first rudimentary materials library, while fine-
  -tuning the LaGrande noodle(s).
• Then, and this is going to take a bit of time, I have to come up with a couple of lobotomized versions of the shaders
  for medium and low shader settings, to support older videocards while still being able to use its texture packing format.
• Then write a wiki page on how to use the Blender materials library, LaGrande and the techniques.
• Get a bit of feedback from Vegastrike artists and do final fixes and adjustments.

Just reminding myself. Damn! I was proud of my accomplishments this weekend and though I'd have several items
to cross off the list by now; but ... NONE?!?!... I'm going to bed.