CineMut shader family - Opaque

[chuck_starchaser]

Thanks!
All the ships and bases will be remodeled. The most urgent ones are the ones needed for the demo release,
and they indeed include the broadsword and paradigm.
The full list is half way scroll down on this post:
PU Demo release To Do list (including ship remodeling list).

[Fendorin]

something i didn't understood (if you know the book called "cinemut for dummy" give it to me please)

well:

-do we need to throught all texture in the nodulizer "blender's noodle"?

-if i haven't AO cinemut will work?

- i need to "re"bake all texture i did with PS in blender?

[chuck_starchaser]

Fendorin, CineMut will use a different texture pack. Not just diffuse, specular and glow. A LOT of textures:

Texture 1:
Albedo (sum of diffuse and specular colors)

Texture 2:
Red represents the specular to diffuse balance
Green represents the dielectric coverage or blend ratio
Blue is the material's dielectric constant
Alpha is the shininess

Texture 3:
Red and Blue are damage dU/dV normalmap modifiers
Green is for sub-texel detail control
Alpha is damage obscurity

Texture 4:
RGB = Glow
Alpha = Cosine distribution ambient occlusion

Texture 5:
RGB = PRT (for now; it will be two textures later)
Alpha = Uniform distribution ambient occlusion

Texture 6:
RGB = Normalmap dU
Alpha = Normalmap dV

Texture 7:
To come; will have "self-bake" for radiosity and self-reflections.

So, CineMut will be incompatible with regular texture packs.
Something textured for CineMut will not show correctly on other shaders.

Having said that, I will have noodles to convert existing diffuse/specular to albedo+spec/diff balance; to
ease the work of converting; but cinemut needs a lot of information that was never present before, and
therefore needs to be generated.

The good news is that CoffeeBot is writing Blender python scripts to make the bakings easier to do.

[Sindwiller]

http://www.blender.org/development/curr ... materials/

Would it work with Blender as a testing environment? It'd be awesome.

[chuck_starchaser]

Doesn't look very cinemutish-compatiblish to me. I've been thinking, once cinemut is finished and the pipeline
starts moving, I might suggest to blender's devs to add custom shaders for the internal renderer, or even to
be able to use custom shaders for the "Shaded" mode. It would have to support special texture packings, quite
distinct from blender's way of specifying materials using Diffuse, Specular and Mirror colors and texture modes.

[Sindwiller]

Ah, I see.... well, no hurry with that

[pyramid]

@chuck,
Just wanted to check if there is a chance to get the issues with xNormal, that you have reported in another thread, resolved in the near future? Would be an ache in the heart if all that progress you did was lost in oblivion due to ao baking problems.

[chuck_starchaser]

@chuck,
Just wanted to check if there is a chance to get the issues with xNormal, that you have reported in another thread, resolved in the near future? Would be an ache in the heart if all that progress you did was lost in oblivion due to ao baking problems.

The issues remain, but the good news is that we're still working on them. Klauss got involved briefly in our emails (I always send him carbon copies) and
this morning I had a "flash of lightning on the road to Damascus" experience while I was in the washroom #2; I think I got a workable solution. I am sure,
positive I got it; only not sure 100% whether the idea is GPU CUDA compatible. Anyways, I sent Santiago (and Klauss) an email about it. Haven't heard
back yet.

Y finalmente tengo una solucion:

Lo que no se es si es compatible con metodos de gpu; pero probablemente si.

La solucion se basa a partir de la idea de interpolar la normal pero ignorar los rayos por debajo de la cara.

La diferencia es con la logica de los rayos por abajo de la cara: En lugar de simplemente ignorarlos, lo que habria que
hacer es invertir la direccion de la busqueda de colisiones. Si el dot de un rayo con la normal de cara es negativo, lo
que hacemos es buscar hits comenzando por la maxima distancia. El hit oficial seria el primero que encontramos; el
cual deberia ser el mas lejano.
Ahora hacemos una segunda pregunta acerca de ese hit:
Es un back-face hit o no?
Si es un front-face hit, el rayo esta ocluido sin lugar a duda.
Si es un back-face hit, podria ser un back-face hit con una cara colindante que deberia ignorarse, o podria ser un
hit con una cara lejana que no deberia ignorarse. Y la solucion hackish que creo que funcionaria en este caso es
usar una atenuacion invertida: Cuanto mas lejano el hit, mas se cuenta.

As for working on the Hammer, thing is, I've done and re-done the bakings so many times I'm burnt. The last AO took 3 and a half days, and it was not
good. I'd rather wait a little more until xNormal works. I think my time is better spent modeling, for now. We don't have cube-maps yet, anyhow; and
that may take a while, also.
Now, if the xNormal problems CAN'T be worked out, then I'll take another tack; but I'm still optimistic.

[Fendorin]

Did it finish? have you some news?

[chuck_starchaser]

Sorry, I took an unexpected vacation; I decided to have a game of MOO2 (Masters of Orion II), my old addiction, and had a resurgence of
the addiction. Spent like 9 days playing MOO2 night and day, hardly even sleeping. Just starting to get myself back into shape.

[chuck_starchaser]

A sober update. Klauss simply has no time to work on the engine, at all --he took a teaching job in addition to his full time job, which he says
was "a mistake"; but he's going to quit teaching at the end of the year and will then have some spare time to get back to coding for VS.
Until then, further cinemut work is rather pointless, as the cinemut-compatible vs executable I have only works for the test bike mission; but
not in PU (segfaults); and I can't use Unit Converter because the current mesher segfaults on me also; --and when it doesn't, the mesh it
exports segfaults my cinemut compatible vs executable. Plus, there's no cubemap support. Plus, some unresolved problems with XNormal AO
that presently Santiago doesn't have the time to address. Plus, there's a bug (in ALL the current shaders) with the lighting (the light direction
with one unit disagrees with the light direction of another unit), which comes from a shader routine called "imatmul()", which I didn't write
and have no idea how it is supposed to work, and Klauss was going to fix but can't get around to it.
So, I'm placing cinemut development officially in limbo (where it's been unofficially for a while) till next year. My time is better spent modeling,
right now, so as to have a bunch of models ready to texture once there IS a cinemut shader in vegastrike trunk, and an executable that doesn't
segfault. Here's some stuff I've been working on:
http://wcjunction.com/phpBB2/viewtopic. ... 5661#15661
http://wcjunction.com/phpBB2/viewtopic. ... 5733#15733

One good piece of news is that, as of late, vegastrike was segfaulting on Klauss, too; so it wasn't a problem with my machine, after all.
In the meantime, as I said in another thread, I've been making further improvements to the standard high shader in PU; you might want to
test it with VS. It allows you to distinguish between texture jobs that include or not a) shininess in specular alpha and/or b) ambient occlusion
in glow map's alpha channel, without having to specify different shaders or techniques. You signal the presence of information in the alpha
channels, to the shader, by putting the corresponding xmesh specular/emissive colors' alphas to zero.

[pyramid]

Sad to hear, but true. We've driven ourselves into a corner, where a release in the current state does not make much sense as there are too many graphical errors inherent. Guess, the only option is continue improving things that can be improved without CineMut and further engine development. Good work anyway and it's still a hope for future engine excellence.

I've put already the testing of your upgraded standard shader on my task list, but haven't come around to it and we also don't have models with shininess and ao in alpha channels, so I can only test it for proper functioning with current textures.

[chuck_starchaser]

Sad to hear, but true. We've driven ourselves into a corner, where a release in the current state does not make much sense as there are too many graphical errors inherent. Guess, the only option is continue improving things that can be improved without CineMut and further engine development. Good work anyway and it's still a hope for future engine excellence.

Glad you understand. I felt "out of steam" with regards to cinemut, and I didn't know why, until the news that klauss was NOT going to make any code changes in the near future; then it all came to me at once: just too many stumbling blocks outside of my domain.

I've put already the testing of your upgraded standard shader on my task list, but haven't come around to it and we also don't have models with shininess and ao in alpha channels, so I can only test it for proper functioning with current textures.

No need to rush testing that, either, as there are more improvements yet to come. The current high shader lacks PRT's, and without a bent tormal one can't have shadows, BUT, I have an idea that might enable shadows using standard AO, and that is to sample the AO differentially. I was doing differential sampling in cinemut to fake specular reflections of statically baked lights: assuming that the direction in which light brightens, on the texture, is where the light is coming from. So I'm planning to move that part of cinemut code to the standard shader. Ironically, the glow map, which I was sampling differentially (5 samples in a cross pattern) is also the texture where the AO is (in alpha), so I can compute ad-hoc light source vectors for red, green and blue static lights (for static light specularities), PLUS a general ambient light direction (bent normal) for ambient, all in one shot.
We'll see soon how well it works; it will probably be very noisy, though; and will have to be toned down in a compromise between shadow visibility and artifact density; but it should be an improvement, nontheless.

What you could do in the meantime, Pyramid, and you're best positioned for, is to insist on non-overlapping UV unwraps for all future models. You can't even bake a proper AO with overlapping islands.

[pyramid]

... insist on non-overlapping UV unwraps for all future models.

OK. I'll keep that in mind (and wiki).

[chuck_starchaser]

I hope Fendorin doesn't mind. Tell him I'll do his AO's for him, to sweeten the deal

[Deus Siddis]

I hope Fendorin doesn't mind. Tell him I'll do his AO's for him, to sweeten the deal

I thought you might have convinced him to make the switch already in a previous thread, or at least come close to it.

Anyway the progress you've made with cinemut and displayed on this thread over the past months has had me sold since a while ago that everything I contribute from now to eternity will use non-overlapping UV patches in support of cinemut's future implementation. I will try and spread the word on this as well.

[chuck_starchaser]

Thanks! Yeah, it's a bit of a hard sell for people who are used to squeezing maximum usefulness from the texture and are proud of it. Hopefully some day the engine will support dual UV mappings, and we'll be able to have maximum efficiency for material definition textures and a non-overlapping unwrap for all situational textures, such as lightbake, AO's and PRT's. When that day comes, however, our non-overlapping UV unwraps will be good already, and we'll just add an extra, highly efficient unwrap for those ships that can use it, with mirroring and other symmetries and repeating things all overlapping, as well as having greeble clusters on which to throw many islands at random. That will be the day...
But until then, just having an AO beats all efficiency gains from overlapping islands many to one.

[Fendorin]

I hope Fendorin doesn't mind. Tell him I'll do his AO's for him, to sweeten the deal

For the next ship/models i will create i will do that = one texel for one pixel. i will keep it in my head.
-oriented front/up. bottom/down
-repetitive mesh with a same texel just if the color is totally black .
-all set map.( what is it exactly PRT map and what is the purpose/handle of this map?)
-Normal map instead of bump map.
- model around 10 000 vertices
- Multi mesh/map for big unit ( like the Clydesdale( i will rework the Midwiffe with this task list)

& optional ( if i'm inspirred) a 2d "inside view screens"


thank

[chuck_starchaser]

Good to hear, Fendorin!

The purpose of the PRT's is to tell the shader not just how much ambient light is reaching a texel, but where is it coming from.
Ambient Occlusion alone only tells the shader that, say, 30 % of the ambient light reaches a given texel.
PRT's can tell the shader "there's 30% of ambient light reaching this texel, AND this 30% is composed of 15% coming from above the ship,
10% from the front side, and 5% coming from the left side".

This is good for three things:
1) Instead using a generic color for ambient light, the shader can actually look at the sky (cube map) in the direction that light actually
comes from and use that color and brightness for the final ambient light contribution.
2) If the direction the PRT's say most light comes from is too far out of alignment with a light source, the shader can assume that point is in
shadow. This yields pretty realistic, dynamic shadows.
3) If the direction the PRT's say most light comes from is too far out of alignment with the reflection vector (view vector reflected around
the surface normal), the shader can assume that environmental reflections are occluded. This yields pretty realistic specular occlusion.


Example:

With the current shaders, if you have a space station with a pipe on the surface, like the mining base, if the pipe is on the shadow side,
even with ambient occlusion, the side of the pipe facing the asteroid looks illuminated, even though it should be in the shadow of the
asteroid. This looks very weird.

With PRT's this doesn't happen, because the PRT's tell the shader that light arriving to the underside of the pipe comes almost horizontally,
from above the asteroid's surface; so the shader takes that into consideration and concludes that there's no way it could be receiving
light from the light source, even if it's facing towards it.

[Fendorin]

-how i should make a PRT map?
-How she look like?
-is it baked with blender or made with "GIMP & brothers".
-is it black and white?
-i thought the AO is not handle by the motor but is for put over your other map and give a right shaddow, had i right?

thank

[chuck_starchaser]

You're asking good questions; so forgive me for the long answers

-how i should make a PRT map?

-is it baked with blender or made with "GIMP & brothers".

You need to,
1) download and install xNormal.
2) export a "low poly mesh" .obj, which is the high poly mesh (top LOD) for game export, but will be "low poly" from the baking perspective.
3) save a "high poly mesh" .obj which you produce by first copying your mesh to another layer and then applying sub-surf modifier. Now, if you try this with any mesh you'll find that sub-surf deforms the edges of meshes. First you need to prepare the mesh by "creasing" all sharp edges. Generally, all edges marked sharp should be creased; but in addition to sharp edges, you'll need to crease all mesh edges (borders); plus, even then some corners will get pulled inwards, and then the solution is to crease ALL edges meeting at that corner. This is a bit of a black art, and merits a tutorial I've been meaning to write but never got around yet. Basically, the safest way to proceed is set the sub-surf level to 1, and tab between edit and object modes, to see how subsurf is behaving, and crease edges as necessary. To crease an edge, or bunch of edges, select all edges you want to crease, hit Shift-E, then press 2, and Enter. Maximum creasing is 1.0, so entering 2 is a safe way to set it at maximum. To UN-crease an edge, select, Shift-E, type "-1" (minus one), Enter. For more advanced stuff, you can try creasing an edge at 0.5, or 0.25, or 0.75; but forget about that for now. Once you're 100% happy with the results, you can hit Apply on the sub-surf modifier, then export the high mesh .obj, then immediately Ctrl-Z to undo the Apply, just in case you change your mind about something in the future.
4) Fire up xNormal, give it the high and low meshes, select baking of PRTP and bake it; then select baking of PRTN and bake it. Many settings I need to cover in a tutorial, though.
5) In Blender, you bake an AO
6) Then you'll need a noodle I have made that takes the two PRT's and the AO and a) Makes corrections to the PRT's so that their normalized sum matches the AO for every texel, and b) combines the two prt's (PRTP and PRTN) into a single texture, and puts the AO in the alpha channel.

Sorry about the incompleteness of the answer. I'm going to get started on this tutorial right now.

-How she look like?

Gorgeous

-is it black and white?

Nope; quite colorful.
Imagine you have your model painted white, but in a dark room. Looks black.
Now put a red light in the direction of the positive X axis. You'll get the left side (port side) of the ship looking red.
Now put a green light in the direction of the positive Y axis. Your ship's left side still looks red, and now the top side looks green; and
some parts in-between look yellowish.
Now add a third light, blue, in the direction of the positive z-axis. Now the front of the ship looks blue.
If you now bake that to a texture, that's your PRTP.
The reverse of that, --red light in the negative x axis, green light below; blue light behind your ship--, that's your PRTN.
It's more complicated than this, because point-like light sources wouldn't be very useful. The distribution of the light sources vary as the
cosine-squared of the angle to the axis. So they are sort of "semi-diffuse" light sources. Long story.

-i thought the AO is not handle by the motor but is for put over your other map and give a right shaddow, had i right?

This is the best question of all, and it has a 3-part answer:
1) With the current shaders, what you're saying is true: You have to apply the ao to the textures off-line, as part of the texturing process.
2) I have a modification of the current shaders, the high shader used currently in PU, which allows you to put the AO in the alpha channel of the
glow-map, and the shader itself applies it to all the textures at run-time. You have to let the shader know that you've put the AO in the alpha
channel of the glow-map, though; and the way to signal this is by putting 0.0 in the xmesh file as the alpha value for "Emissive" color.
3) Cinemut definitely doesn't expect AO to be applied to the textures. CineMut, in fact, currently needs two AO bakes: One of them is baked
from Blender (uniform AO) and goes into the PRT's alpha channel. It is used together with the PRT's for ray occlusion computations, for direct
shadows and specular occlusion. The other is baked with xNormal, with the "Cosine" distribution setting, and goes into the glow map's alpha
channel. This one is used for ambient lighting modulation.

Time for Aspirin...

EDIT:
The important thing is the masters, really. Bake the AO and/or PRT's and keep them safe. You can either apply the AO to the textures to
produce export textures that cater to the current shaders, and later, from the same masters you can produce export textures that cater
to the new (PU) version of the high shader, with AO in glow's alpha; and later for CineMut. Just as long as you keep your masters safe.
Working on the tutorial:
http://wcpedia.com/dw/doku.php/wc_info/ ... _prt_bakes

[chuck_starchaser]

Almost done.
All the information is in; all it needs now is illustrations for the high poly mesh export chapter.

http://wcpedia.com/dw/doku.php/wc_info/ ... _prt_bakes

[chuck_starchaser]

If anyone downloaded the PRT_normalize.blend noodle linked to from the tutorial,
please re-download it; there was a minor bug of major consequence in it; it is now fixed.

[Fendorin]

Thank a lot for had a time to entrance in explanation mode.

i will try to "study" it (turn around is maybe a better word)

[chuck_starchaser]

Thank a lot for had a time to entrance in explanation mode.

[English correction mode]
I think what you're trying to say is,
"Thanks for making the time to explain the subject at an introductory level."
(It's either "thank you" or "thanks [a lot}", but not "thank a lot"; --unless you are commanding someone to thank a lot.)
("Had a time" means something like "it was a fun party")
("To entrance" is incorrect, as 'entrance' is a noun, not a verb. "To enter" would be correct. But in this case I think
you meant "to introduce".)
[/English correction mode]

i will try to "study" it (turn around is maybe a better word)

[English correction mode]
I don't think "turn around" is a better expression. (Certainly not a better word, since it consists of two words .) Well,
"turn around" IS an expression, but it means to "face back", --either literally, like turn on your feet and face the opposite
direction; or metaphorically, as if a person who is a fanatical surrealist might "turn around and..." become an objectivist.
I'm not sure exactly what you meant. Perhaps "turn it around" like when you study an object? That's not an expression
commonly applied to studying a document; not to imply that you couldn't be the first and "coin a new use of an expression"...
If it was a printed document, you could "flip through it". Maybe "peruse it"? "Fool around with" it? (as in "experimenting"?)
[/English correction mode]

Great! Hope it's not too hard to understand.
Phlogios was just telling me he understood how to sub-surf a mesh for the
first time after reading it. Hope it helps you too.

By the way, Santiago Orgaz had a read of it and approved it.

And there are great news, but it's a secret... just between you and I...
[whispering]
xNormal is getting ported to other OS's... (*nix, Mac, Solaris...)
[/whispering]
Shhh!