CineMut shader family - Opaque

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:

Re: CineMut shader family - Opaque

Post by chuck_starchaser »

Update:
Klauss was still videocard-less last time I asked; and busy with the sound system; so CineMut
development remains on hold.
One idea came up in another thread, and I discussed it with Klauss by email, and it resulted in
a very beneficial change of plans, as follows:
Four of the textures in the CineMut pack will be assembled into one larger texture. They include,
  • 1 - PRTp in RGB + uniform AO in alpha channel
  • 2 - PRTn in RGB + cosine AO in alpha channel
  • 3 - Glowmap (light bake) + incident self-illumination angle in alpha
  • 4 - Damage normalmap dU in r & b; dV in g, + damage darkening in alpha
To access these 4 sub-textures, the shader will do some math with the texture coordinates.

This change will have two benefits: It will reduce the number of texture units used, which was
a pressing concern; and it will reduce the texture setup latency overall.
The rest of the textures will remain single, probably.
JsnMtth
Bounty Hunter
Bounty Hunter
Posts: 174
Joined: Wed May 27, 2009 6:38 am
Location: Fresno, California - United States of America
Contact:

Re: CineMut shader family - Opaque

Post by JsnMtth »

Hey guys, I'm afraid I'm asking stupid question but....

What is CineMut?
When is it planned on being used?
How does one go about texturing with it?
Why is it better than the current method (of which I'm not familiar with either :oops: )
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 »

Your questions are not stupid; they are too good. Well, what IS CineMut is answered throughout this thread; just go to the first page and start reading.
In short, it's a set of shaders. The name "CineMut" came up after a few pages; and the name of the thread was changed retroactively. The shaders
had no name when work began.
When is it planned on being used?
As soon as it works! :D
For now the project is in suspended animation. Been waiting for Klauss to upgrade the engine with a number of features
that CineMut needs. I haven't been able to help due to a broken compiler; but as of today I'm in Ubuntu; so maybe this
thing will start moving again soon.
How does one go about texturing with it?
The short answer is you don't. Until the shaders are finalized,
trying to texture for them would be a waste of time, as the shaders are a moving target, right now. There will be a set
of Blender Node Networks to go with the shaders, called "La Grande". These "Blender noodles" will simplify and speed
up a lot of the texturing process.
Why is it better than the current method
In a gazillion ways:
  • Self-shadowing
  • Specular self-occlusion
  • Control of shininess (gloss) via the texture
  • "Physically correct" representation; --e.g.: red diffuse with green specular is NOT representable, as it can't exist
  • Distinction between metallic and dielectric specularities
  • Two-layer materials, such as car paints (diffuse color base + glossy, transparent coating) correctly represented
  • Effects of multiple light bounces within paints' dielectric layer modeled
  • Control of dielectric constant via the texture, --plastic is NOT glass is NOT diamond
  • Non-point-lights, for smoother penumbras
  • Control of dielectric coverage (blue plastic and blue paint look different)
  • Specular reflections of statically baked lights
and many other features I forget now
[*]Detail textures built-in, applied to albedo, shininess or bumpmap under texture control ;-)
JsnMtth
Bounty Hunter
Bounty Hunter
Posts: 174
Joined: Wed May 27, 2009 6:38 am
Location: Fresno, California - United States of America
Contact:

Re: CineMut shader family - Opaque

Post by JsnMtth »

Are the CineMut shaders dependant on the OGRE implementation?
I did read the first page and a half but tired of the argument over details that are over my head.

Thanks for the detailed answers. Funny you mention ubuntu as I'm anxiously expecting the Fedora 11 release (to ditch ubuntu). Not that ubuntu isn't a good system, I just don't care for doing things "the ubuntu way".

My childhood dream was making video games, although I've been fortunate in getting to do creative graphics and programming at the same time with web sites. I'd like to do game development, and I'd like to contribute to open source. I had this great idea for a Massivly Multiplayer space combat game and went looking for a GNU space flight engine, and checked out vegastrike. I'd never played Wing Commander, only Descent Freespace and X-Wing/TIE Fighter. After being VERY impressed with the engine I'm finding that VS's feature list is what I imagined plus lots extra coolness.
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 »

JsnMtth wrote:Are the CineMut shaders dependant on the OGRE implementation?
Originally they (and all shaders) were going to be dependent on Ogre; but the Ogre porting was taking too long, and so, one day
Hellcat V decided to bypass the Ogre porting process and introduce shaders sans Ogre; and the shader infrastructure has
been evolving: Klauss implemented a system he called "Techniques" which allows mesh files to specify the shader family
and version to use, and some extra things like multi-pass specifications. So, the answer is that Ogre porting is in the pipes,
but current and future shaders are not counting on Ogre-ness.
I did read the first page and a half but tired of the argument over details that are over my head.

Thanks for the detailed answers. Funny you mention ubuntu as I'm anxiously expecting the Fedora 11 release (to ditch ubuntu). Not that ubuntu isn't a good system, I just don't care for doing things "the ubuntu way".

My childhood dream was making video games, although I've been fortunate in getting to do creative graphics and programming at the same time with web sites. I'd like to do game development, and I'd like to contribute to open source. I had this great idea for a Massivly Multiplayer space combat game and went looking for a GNU space flight engine, and checked out vegastrike. I'd never played Wing Commander, only Descent Freespace and X-Wing/TIE Fighter. After being VERY impressed with the engine I'm finding that VS's feature list is what I imagined plus lots extra coolness.
Cool.
Are you a C++ programmer? We could use some help.
JsnMtth
Bounty Hunter
Bounty Hunter
Posts: 174
Joined: Wed May 27, 2009 6:38 am
Location: Fresno, California - United States of America
Contact:

Re: CineMut shader family - Opaque

Post by JsnMtth »

I've been a hobbiest programmer for 15 years. In the early years it was dos basic. I have a little C experience, a little perl experience, and 8 years of professional php experience(procedural and OOP). I also understand the challenges that come from writing in a language that access memory directly. I also have experience in performance tuning. I designed wrote, implemented and maintain the shopping cart and site for the company I work for. I've studied C++ for a year or so as a hobby,am familiar with compiling in linux (our server stack I call a parasite because it's a modified Linux from Scratch system that runs on top of a comlete distro). I've played with blender, I'm familiar with graphic design (I'm not at art but can use a computer to fake it eventually). I've been collecting documentation on 3d programming and would love to get involved in this project. I've never contributed to an open source project, but has always intended to, the idea of making games is what got me interested in programming way back in the day. I have some FPS level design experience too (just enough to be dangerous)
I'll work my way through this whole topic shortly, but frankly ... I'm lost, I don't have the terminology. Could someone recommend a resource to help me get up to speed?
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 »

You don't really need to understand this (CineMut) thread, as most of what's discussed in it is shader
programming, in the GLSL language. I can handle the GLSL side. What I've been less than useless at
is the engine, C++ side of things. Part of the reason is my lack of familiarity with the engine; part of it
was my inability to compile in Windows. The last engine contribution I made was the computing of
tangent vectors on mesh-load, but I wrote all the code blindly, without compiling/debugging; and then
passed the code to Klauss to finalize and merge. Hopefully, now that I've taken the leap to Linux, I'll
soon be able to help more with C++. Problem is there's a total of about 2.5 C++ developers working
on this project, and they are overloaded with many priorities. Klauss, for example, has been working
on the sound system for the past few months, and postponing the graphics side of things that CineMut
depends on.
I'll point him to this thread, see if he might find a few minutes to at least delegate some graphics work
that you and I could try and look into.

EDIT:
BTW, here's a screen-shot of the last CineMut version that worked. Click on the image for full rez.
http://vegastrike.sourceforge.net/forum ... 61#p103561
Note that the gas tank is blue paint, while the utility box under the seat is blue plastic. This is one
thing CineMut can do that NO other shader in the world does.
JsnMtth
Bounty Hunter
Bounty Hunter
Posts: 174
Joined: Wed May 27, 2009 6:38 am
Location: Fresno, California - United States of America
Contact:

Re: CineMut shader family - Opaque

Post by JsnMtth »

I'd be interested in working on various sides of the project. I'm interesting in achieving an understanding of the engine. I'm working on my C++, I understand programming concepts and working on large projects. If something is badly needing to be worked on let me know.
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 »

I sent Klauss an email, pointing him to this thread; I hope we'll hear from him soon.
In the meantime, last time we discussed the work to be done, he asked me for a rough list
of what I considered is needed, and I came up with this (quoting my old email):
I wrote:Let me try to itemize it more finely; just a suggestion list to simplify your planning:
  • Combining latest Vegastrike engine with techniques/tangents branches.
  • Testing executable with current PU data. (There's a potential problem here: the newer
    versions of the engine need textures to change names, but in PU they haven't yet. On the
    other hand, Wolphin left a script for us to run to change the texture names, but I've been
    too afraid to touch it; he was hacking into the svn files, in that script, to avoid redownloading
    of all the image data.
  • Fixing problem of light direction wrong when normalmapping is enabled.
  • Introducing support for DDS cubemaps in the engine.
  • Implementing cubemap support.
  • Changing shaders to use cubemaps (I can do this)
  • Finalize tangents, if not already finalized.
  • Finalize techniques, if not already finalized.
  • Making a Windows executable that works in all OS versions.
  • Will other files need changing in tandem? Python or dll? Sources and instructions for *nix.
In the meantime I'd finish the Toad/Hammer texturing, to be ready to test CineMut in the new
engine.
  • Shader work: Debugging CineMut (me or both of us)
  • Parallax
  • Tentative deployment in PU and announcement and getting feedback.
  • Remaining fixes
  • Transfer to Vegastrike, together with Toad/Hammer
Then I can take it from there, a cycle of:
  • Texturing refinements, material library updates
  • LaGrande improvements
  • Shader improvements
Wash and repeat until perfect. Then finish documentation

EXTRAS:
  • Object to object shadows (if very soft, they could use the collision/shield mesh, which could
    be standardized to be a closed manifold).
  • Planet and atmosphere shaders.
  • CineMut FireGlass (moi).
  • New asteroid field project, with hardware fog and other tricks. The idea would be to make the
    asteroids be generated procedurally, so we could have rings that when you fly close to them
    are composed of gazillions of ice chunks and a haze of space-snow.
But in a later email I said to him,
I wrote:But actually, if I were you, the first thing I'd work on is cubemaps; finding code
to read DDS cubemaps. It would be an instant win, improving the graphics in
Vegastrike AND PU. Remember I've already produced DDS cubemaps for all
backgrounds; as soon as the engine supports them, it's all done. And CineMut
absolutely NEEDS cubemaps; all testing of CineMut is inconclusive without
cubemaps in place.
A closely related bug to fix is that environment reflections are wrong. If I'm looking
at a surface almost grazing and there's a green nebula above it in the background
I should see its reflection; but I don't. Something in the math between background
display and env.mapping disagrees.
And then the problem of the illuminated side of models facing in diferent direction
from where the light comes from.

Cubemaps and solving those two problems would be huge AND tangible progress
to warm people up before techniques and new shaders.
And he agreed to the plan of starting with cubemaps; and last I heard he had been
collecting documentation on dds format, getting ready for the dash.

Well, just to give you a bird's eye view of where things stand.
JsnMtth
Bounty Hunter
Bounty Hunter
Posts: 174
Joined: Wed May 27, 2009 6:38 am
Location: Fresno, California - United States of America
Contact:

Re: CineMut shader family - Opaque

Post by JsnMtth »

Great! :D
I'll get familiar with the technical details, look for communication from Klauss, and see when I can make progress.

I think I attempted to use the svn/trunk with PU data and vegatrek. They crashed because of no techniques, no knowing what techniques are I didn't look into them further.
I might not have tried PU though, it might have been one of the derivatives (I didn't discover VS until last week). I'll dig around.

I'm willing to look into that file??? renaming script that was hacked into svn. We used svn here for 2 years before moving to git.
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 »

JsnMtth wrote:I'm willing to look into that file??? renaming script that was hacked into svn.
That would be fantastic. I think the script is in the main folder of PU in svn.
Like, I think the idea was something along the lines of "everybody run the script now", and a branch would appear on
the server, or something like that. I never understood it.
But the right thing to do would be to test that the switch to the latest VS engine works in windows and linux before
making a public announcement of it.
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 »

CineMut's coming back to life after hybernation...
Klauss is slowly getting back into the graphics side of things.
Re-posting this from the wcjunction forum:


CineMut texture packing format

The CineMut texture packing has been changing faster than the shader since day 1. There's just so many
considerations in coming up with a good packing, it seems it's never done. Lately it has evolved by leaps
and bounds over many days of discussions with Klauss. It may still change but probably not by much.
(Fingers crossed.)

Part of the reason I'm committing the current state to labor-intensive PNG's is so I can frown at Klauss if
he tries to change anything :D

There are now 13 textures arranged into two texture atlases, plus a detail texture.

The Materials and Light atlas will be DXT5-compressed. The Geometry and Shadows atlas will be un-
-compressed (in videocard memory, that is; it will probably be PNG-compressed on disk).

Size numbers are for a fighter size ship. Basic texture size is 512, with a 1024 normalmap.
Scale numbers up for larger ships. To recap standard texture sizes,
  • Fighter -- 512 x 512
  • Corvette -- 1k x 1k
  • Carrier -- 2k x 2k
  • Space station -- 4k x 4k
But here we use fighter figures for a base reference.

The "Materials and Light" texture atlas will contain eight 512 x 512 sub-textures or "pages",
as follows:

Image

Where,
  • Albedo means "the color of the pure material on a polished surface under diffuse lighting conditions"
  • Metallic spec is a ratio of specularity to diffuseness excluding dielectric layer specularities
  • Dielectric K is the dielectric constant for the material. Metals' dK are zero, but metallic rusts are dielectrics
  • Dielectric purity means the % coverage of dielectric layer, minus diffuse material at the surface
  • Gloss is the sharpness of reflections; low gloss == blurry reflections
  • Gloss purity is the % coverage of high gloss versus % of low gloss "scratchiness"
  • Aniso U vec and V vec define a rotation and biasing of gloss anisotropy (CD surfaces are anisotropic)
  • Damage dU and dV are normalmap modifiers that are blended in in proportion to ship damage
  • Damage AO is a damage obscuration factor (smoke marks)
  • Alpha is alpha :-(
  • Detail CTRL 1 & 2 are channels for control of the application of a "detail texture" (adds sub-texel graininess)
  • Self-radio color is the light arriving to points on the surface from ambient light reflected diffusely by other ship parts.
  • Self-radio dU and dV are the rate of change of self-radio luma as we move in the U or V texture directions
  • Static light color is the light arriving from static light emitter around the model
  • Static light dU & dV are rate of change of static light across U & V. Repeated in R & B channels for precision
  • Self-spec (monochrome) is the light arriving to points on the surface from ambient light reflected speculary by other ship parts.
  • Self-spec dU & dV are rates of change of the above across U & V.
  • Angle hack is some quantity TBD to help improve the specularities from static lights hack.
Notes:
* The self-radio stuff is to compute radiosity (two (diffuse) bounce light) and self-spec (diffuse-spec bounces).
* Self-spec is for two bounce (spec-spec) highlights, and two bounce (spec-diffuse) "caustics".
* Self-radio and self-spec won't be implemented initally, as they require a special baking process
* Static-bake differentials are to compute specular reflections of statically baked lights.

The "Shapes and Shadows" texture atlas will contain four 512 x 512 pages, and one 1024 x 1024 page.
Its contents are as follows:

Image

Where,
  • Bent normal UVZ define the bent normal computed by subtractin prtN from prtP, and rotation to tangent space.
  • UAO is the "Uniform Ambient Occlusion" (equally weighted rays)
  • CAO is the "Cosine Ambient Occlusion" (rays weighted by cos of angle between ray and surface normal
  • ERU and ERV define a vector on the tangent plane that indicates the rotation and ellipticity of the unoccluded light cone
  • Curvature axis rotation is a 0-180 degree of orientation of main surface curvature axis
  • Curvature along axis is a "concavity" measure of surface curvature along the above orientation
  • Curvature across axis is concavity in the transversal direction
  • Wavelet 1 through 6 are stuff I know nothing much about, but Klauss does; supposed to improve shadows & stuff.
  • Normal UVZ are standard normalmap encoding
  • Height is bump height (depth), for paralax queries and texture offset
Notes:
* The ERU and ERV will encode stuff that the last version of CineMut calculated in the shader, to reduce instructions
* Curvature data are for anisotropic filtering of env map reflections to avoid artifacts in small radiius glossy bevels
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 »

Make sure this post also has a counterpart in the VS/PU wikis! Posterity and ease of access!
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: CineMut shader family - Opaque

Post by chuck_starchaser »

Yeah, I have to confess to a little bit of exaggeration about it's finality; as Klauss wrote
this morning,
Cool.

But I bet it will change after coding the shader, where we can see
where the packing fails or performs poorly and how to improve it. I
wouldn't think it's "almost done", on the contrary.
And, in fact, I don't know yet what to even name the "angle hack" channel,
or the two detail control channels; and Klauss doesn't know exaclty yet what the six
wavelet channels will contain. So, it's not ready for wiki-fy-ing just yet; but it will be
once it settles.
The documentation for CineMut and LaGrande will be a huge project we'll have to
tackle at once and get it all done; but before we get to that we'll probably have
finished the PU demo with all models CineMut-ized, as we'll need the experience
of USING CineMut and LaGrande somewhat extensively to be sure of its being
stable enough to document. Documenting prematurely would multiply the amount
of work, if one has to change the documentation on a weekly basis.

So, I posted PNG's of the packing just because I do feel we reached a milestone
in finding the way to organize all these channels into two neat atlases; -one using
compression and one not; one devoted to material parameterizations, and the
other devoted to geometry and self-shadowing. It's a moral milestone. A bragging
point :D

What I haven't bragged about because it gets really technical is the huge, HUGE
improvements to the detail of the channels. Storing differentials in U and V texture
coordinates, for example: LaGrande Blender noodles can compute these at 32-bit
floating point precision, off-line, amplify the signals, and store them to those
channels optimizing the use of the bits; whereas before the shader had to sample
the texture 5 times and spend a lot of instructions to compute the differentials in
real-time, only to get poor results. This will allow far better and smoother static
light specular reflections, radiosity, self-specularity and caustics.
Having all these textures in two atlases reduces the need for texture units from
about 10 before, to now 4 (2 atlases, 1 detail texture, and cube-map).
There are now 13 samplings for the shader to do, plus 5 of the env map, plus one
of the detail texture... That's 19 so far; and a few more for paralax. May sound like
a lot; but the last version of CM was doing 18 texture samplings for about half as
many features.
In terms of memory requirements, we've gone up a bit, but not by very much.
We've also added anisotropics...
Anisotropic filtering is what allows such things as CD or vynil record surfaces
reflections, which show a sort of high shininess in one direction but low in the
transversal direction. Some degree of anisotropy is commonly seen in sheet-metal,
particularly stainless steel, where the manufacturing method often leaves parallel
scratches on the metal surface.
But another use of anisotropic filtering that's much more needed is for filtering
reflections of the environment on small radius curvature surfaces. Bevels, for
example, desperately need anisotropic filtering, for specular reflections of the
env map to look right.

As I was saying to Klauss a while ago, CM will perhaps not shine at any one
particular feature...
* there are better shadows out there than we can achieve
* there are gpu raytracing shaders that can do self reflections better
* there are shaders that can do fairly accurate radiosity
* there are shaders that use like 10 textures for full material BRDF modeling
* there are shaders that use multiple textures for spherical harmonics
* there are shaders that can do incredible bump-mapping paralax
But we got tricks, some already implemented, some still "on paper" that
will get about 90% results in all of these areas at a fraction of the cost in
terms of instruction count.
So CM will be THE shader that "has it all", --and does it all single-pass.
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 »

Another wonderful thing about this packing I forgot to mention is that it
separates mutable from immutable channels.
As long as the geometry and bump-map of a model don't change, the
Shapes and Shadows atlas needs not change.
Changes in colors and materials affect only the Materials and Lights atlas.
Thus, all factions of a ship can be defined by different M&L atlases, but
share a common S&S atlas.
Zebedee
Trader
Trader
Posts: 17
Joined: Thu Jul 30, 2009 8:58 pm

Re: CineMut shader family - Opaque

Post by Zebedee »

Stunning work. Excellent documentation. Good luck with bringing things to completion :)
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 »

Thanks. Yeah, I'm working on it like 5 horses and 11 dogs; but haven't got much
to show for it all yet.
The texture packing has changed about 5 times since I posted those pictures;
and it is going to change yet again; Klauss is very worried we are going to have
a bandwidth problem with so many textures. So, I'm working on
PU's new Centurion model,
to try and have it ready for shader testing, while fixing things and
refining the LaGrande set of Blender noodles, while trying to figure out what
texture channels we can dispense with.
Fendorin
Elite Venturer
Elite Venturer
Posts: 725
Joined: Mon Feb 26, 2007 6:01 pm
Location: France, Paris

Re: CineMut shader family - Opaque

Post by Fendorin »

Hi I doesn't understand all

But could it possible with Cinemut to use tiling texture mixed with uv mapped
exemple 2 meshs :
a station : the hull is tiling texture and the point of detail : dock ,bridge,habitat .....etc is uv mapped?

The render in game should be mice no? and very detailled?
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 »

Fendorin wrote:Hi I doesn't understand all

But could it possible with Cinemut to use tiling texture mixed with uv mapped
exemple 2 meshs :
a station : the hull is tiling texture and the point of detail : dock ,bridge,habitat .....etc is uv mapped?

The render in game should be mice no? and very detailled?
Hey, Fendorin!
I've got good news for you. Indeed, you will be able to mix tiling and UV-mapped textures.
And not only use one or the other, but actually blend them.
In fact, this is how CineMut works by default. The tiling texture is called the "detail texture",
because the standard use of it is simply to add sub-texel detail; but nothing prevents you
from giving your mesh a flat color and using the detail texture as your main texture.

And let me tell you, this is what you want: because even if you use the detail texture as your
main texture for a part of a ship or station, you still want an overlapping UV-mapped texture
to add global gradients of light and shadow, things like AO and lighting; as well as to paint
over a tile somewhere so that it looks like it fell off..
Otherwise the tiles would look too uniform.

Moreover, there are two texture channels in the main texture that, by changing the color,
you control the way the detail texture is applied. You can use one of those channels to
specify if you want to use the detail texture as a color modulator, or as a shininess (gloss)
modulator, or as a bump-map. And you can use the other channel to control its frequency
and intensity.

By frequency I mean that you can make the tiles bigger or smaller, by powers of two; or
even some blend in-between two powers of two.

There will be a default detail texture packed with CineMut, which has 4 channels (RGBA),
one of which (red) has noise; another (green) has "clouds", and the last two (blue and
alpha) have dU/dV normals to add to the normalmap, to look like a bumpy, ripply surface.
Remember the gas tank on the motorcycle?

But you *can*, through the techniques file, specify a detail texture of your own. However,
you'll have to use the channels the same way (red channel for brightness modulation,
green channel for shininess modulation, and blue and alpha for normalmapping). Which
is okay; you probably don't need multiple colors for the tiles, would you? You can use a
beige color for the main texture, for example; put like a thatch pattern in the normalmap
channels of the detail texture, inside a square border, say; and a bit of noise in the green
channel to represent wear of the surface, and you'd have awesome looking tiles without
using any color patterns.

I'm sorry this project has been dormant for so long. Now that Klauss is going to have some
time for working on graphics, hopefully it will be finished "soon".

EDIT:
Another day, another texture packing scheme...

Image

Sent it to Klauss for comments.
Fendorin
Elite Venturer
Elite Venturer
Posts: 725
Joined: Mon Feb 26, 2007 6:01 pm
Location: France, Paris

Re: CineMut shader family - Opaque

Post by Fendorin »

Hi Chuck
It's looks interressant.
i wanted know: what should be the std requirement after all for mesh? it will be the same than now ?
Cinemut will work with Ogre3D ?(i have no idea where is the developpment stage about Ogre3D mooving for VS)
What will be the future standard pack for texture?
the goal you try to reach is put the more information you can in the less texture you can ?
i m wonder if it's to complicate it will be difficult to have a good contribution
if you need more than 4 texture map for one mesh you multiplie the complexity for new contributor no
or maybe cinemut is just for PU/WC

I will try to follow the cinemut related thread.
but currently i have less and less time for contribute, but if i contribute i want be usefull :|

Thanks
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 »

Fendorin wrote:i wanted know: what should be the std requirement after all for mesh? it will be the same than now ?
Same as I've been mentioning for a while
  • No UV overlaps, except black material parts can all be piled up on top of each other and scaled down to a point.
  • Every UV island should be oriented such that UP in the texture is Forward in the ship. (In the case of
    stations, where there is no "forward" direction, it doesn't matter.) UV islands that represent vertical planes,
    forward- or back-facing, those should be all along the top of the texture, separated from the rest. This is not
    really a CineMut requirement; rather a LaGrande requirement. Some LaGrande noodles add dirt streaks and
    scratches that should fade back; and they do so by fading down in the texture; so this is very important if you
    want streaks and scratches. Have a look at this little unwrap tutorial/post about a good unwrap layout philosophy.
As long as you stick to these principles, your meshes will be CineMut-ready.
Cinemut will work with Ogre3D ?(i have no idea where is the developpment stage about Ogre3D mooving for VS)
The situation with Ogre is this:
Klauss has NO time to work on it. Development on Ogre porting is officially frozen --for the foreseeable future.
But it may not matter after all. Ace123 and Hellcat are working with a new engine, which they think might
replace the VS engine eventually. I heard this directly from Ace, by email; this is no rumor-mill stuff. So, it
explains to me why this place seemed so dead. This is rather the calm before the storm. I don't know whether
the new engine is Ogre-based or not. I know nothing about it, except that its main strength is about distributed
content; it can have virtually limitless worlds, as contents are spread through many servers.
But anyhow, none of this has anything to do with CineMut. CineMut is a shader (or, will be a family of shaders),
and any engine that allows shaders potentially allows CineMut.
So, the short answer is Yes. :)
What will be the future standard pack for texture?
the goal you try to reach is put the more information you can in the less texture you can ?
Exactly.
I just gave up on a lot of planned goodies to try and reduce the size of the texture pack.
i m wonder if it's to complicate it will be difficult to have a good contribution
if you need more than 4 texture map for one mesh you multiplie the complexity for new contributor no
or maybe cinemut is just for PU/WC
You're damn right about that; and this is a point I'm constantly
struggling with: How to make the art pipeline easy; and it's not easy.
CineMut requires, first of all, a lot of bakes:
Using xNormal we bake,
  • UAO (Uniform Ambient Occlusion)
  • CAO (Cosine Ambient Occlusion)
  • PRTP (Pre-computed Radial Transfer --Positive axes)
  • PRTN (Pre-computed Radial Transfer --Negative axes)
  • NOR (Corrective Normalmap)
And from Blender we need to bake,
  • Normal
  • Tangent
  • Binormal
And with Gimp we bake a normalmap from the bumpmap.

Needless to say, there will be detailed instructions how to do all these bakes; but
still, it's a lot of work. And then comes LaGrande. So far I got the noodles that, from all
the above bakes, compute a finale "bent normal in tangent space". This "bent normal"
texture is the heart of what produces dynamic shadows and specular self-occlusion.

Here's the current list of blender noodles in LaGrande to do just that, from
the current README.txt:

Code: Select all

The following is NOT instructions, or a how-to. Those will be found in
the wcpedia.com modeling and texturing wiki, when they are done. What's
below is simply a list of LaGrande noodles in order of usage, each with
an indented list of input and output filenames. This list is highly
mutable, and may be obsolete even if you happen to be reading the latest
version of this document.

/////////////////// START ////////////////////////////

//// RUN ONCE ////
AO_PRT_exports_for_touchup.blend (***DO NOT RUN*** except the first time,
unless you have new bakes and really want to over-write your touch-up's!!!!)
  inputs:
    /bakes/UAO.exr
    /bakes/prtP.exr
    /bakes/prtN.exr
    /bakes/CAO.exr
  outputs:
    /touchup/UAO_tu0001.png
    /touchup/prtP_tu0001.png
    /touchup/prtN_tu0001.png
    /touchup/CAO_tu0001.png
//// RUN ONCE ////

//// After running the above noodles you'd typically spend some time touching
up the bakes, such as selecting black blotches by color and blurring, to get
rid of too dark texels showing next to interpenetrating geometries. Gimp work.
That's why we exported .png's. Note that the import noodles below will try to
keep the full, 32-bit precision of the original OpenEXR files, except for the
areas you touched up in the png's. How do the input noodles know? They just
use a difference threshold to tell if a texel's been deliberately modified. ////


//// UPON INPUT UPDATES, YOU CAN RE-RUN NODES STARTING AS EARLY AS HERE ////

UAO_import_from_touchup.blend
  inputs:
    /bakes/UAO.exr
    /touchup/UAO_tu0001.png
  outputs:
    /bakes/UAO_fixed0001.exr

prtP_import_from_touchup.blend
  inputs:
    /bakes/prtP.exr
    /touchup/prtP_tu0001.png
  output:
    /bakes/prtP_fixed0001.exr

prtN_import_from_touchup.blend
  inputs:
    /bakes/prtN.exr
    /touchup/prtN_tu0001.png
  output:
    /bakes/prtN_fixed0001.exr

CAO_import_from_touchup.blend
  inputs:
    /bakes/CAO.exr
    /touchup/CAO_tu0001.png
  output:
    /bakes/CAO_fixed0001.exr


//// Compute inverse matrix to convert tangent space vectors to model space ////

UVN_to_XYZ_vec.blend
  inputs:
    /bakes/U_vec.exr
    /bakes/V_vec.exr
    /bakes/N_vec.exr
  outputs:
    /temp/X_vec.exr
    /temp/Y_vec.exr
    /temp/Z_vec.exr


//// Generate a first bent normal in tangent space to help later with bump modulation ////

prt_normalizer_1.blend
  inputs:
    /bakes/UAO_fixed0001.exr
    /bakes/prtP_fixed0001.exr
    /bakes/prtN_fixed0001.exr
  outputs:
    /temp/renormalized_prtP0001.exr
    /temp/renormalized_prtN0001.exr

PRT_to_bent_normal_1.blend
  inputs:
    /temp/renormalized_prtP0001.exr
    /temp/renormalized_prtN0001.exr
  output:
    /temp/bent_normal_model_space0001.exr

bent_normal_to_tan_sp_1R.blend
  inputs:
    /bakes/U_vec.exr
    /temp/bent_normal_model_space0001.exr
  output:
    /temp/bent_normal_tangent_spaceR0001.exr

bent_normal_to_tan_sp_1G.blend
  inputs:
    /bakes/V_vec.exr
    /temp/bent_normal_model_space0001.exr
  output:
    /temp/bent_normal_tangent_spaceG0001.exr

bent_normal_to_tan_sp_1B.blend
  inputs:
    /bakes/N_vec.exr
    /temp/bent_normal_model_space0001.exr
  output:
    /temp/bent_normal_tangent_spaceB0001.exr

bent_normal_to_tan_sp_1.blend
  inputs:
    /temp/bent_normal_tangent_spaceR0001.exr
    /temp/bent_normal_tangent_spaceG0001.exr
    /temp/bent_normal_tangent_spaceB0001.exr
  output:
    /temp/bent_normal_tangent_space0001.exr


//// Generate "PRT-light directions" in tangent spece, lerped with bent normal, also to help with bump modulation ////
    
bent_prtPNX.blend
  inputs:
    /temp/X_vec.exr
    /temp/bent_normal_tangent_space0001.exr
  output:
    /temp/bent_prtPX0001.exr
    /temp/bent_prtNX0001.exr

bent_prtPNY.blend
  inputs:
    /temp/Y_vec.exr
    /temp/bent_normal_tangent_space0001.exr
  output:
    /temp/bent_prtPY0001.exr
    /temp/bent_prtNY0001.exr

bent_prtPNZ.blend
  inputs:
    /temp/Z_vec.exr
    /temp/bent_normal_tangent_space0001.exr    /bump/normalGimp.png

  output:
    /temp/bent_prtPZ0001.exr
    /temp/bent_prtNZ0001.exr


//// bumpmap work and normalmap generation (use Gimp for now) ////

bump_expander_thinner.blend (not implemented yet; do it with Gimp)


//// Modulate the ambient occlusions to add tilt-based bump lighting and bump shadows ////

UAO_bump_splitter.blend
  input:
    /bump/bump.png
  output:
    /temp/bump_top_level0001.png
    /temp/bump_bot_level0001.png

UAO_top_shadows.blend
  input:
    /temp/bump_top_level0001.png
  output:
    /temp/UAO_top_shadows0001.exr

UAO_bot_shadows.blend
  input:
    /temp/bump_bot_level0001.png
  output:
    /temp/UAO_bot_shadows0001.exr

UAO_bump_shadows.blend
  input:
    /temp/UAO_top_shadows0001.exr
    /temp/UAO_bot_shadows0001.exr
  output:
    /bump/UAO_bump_shadows0001.exr

CAO_bump_shadows.blend
  input:
    /bump/bump.png
  output:
    /bump/CAO_bump_shadows0001.exr

CAO_bump_tilt_mod.blend
  input:
    /temp/bent_normal_tangent_space0001.exr
    /bump/normalGimp.png
  output:
    /bump/CAO_bump_tilt0001.exr

CAO_final_bumper.blend
  input:
    /bakes/CAO_fixed0001.exr
    /bump/CAO_bump_tilt0001.exr
    /bump/CAO_bump_shadows0001.exr
  output:
    /bump/CAO_bumped0001.exr

UAO_final_bumper.blend
  input:
    /bakes/UAO_fixed0001.exr
    /bump/CAO_bump_tilt0001.exr (that's right; it just square roots the CAO's bump tilt)
    /bump/UAO_bump_shadows0001.exr
  output:
    /bump/UAO_bumped0001.exr


//// Modulate all 6 PRT channels to add tilt-based bump illumination modulation ////

modulate_prtPX.blend
  inputs:
    /temp/bent_prtPX0001.exr
    /bump/normalGimp.png
  output:
    /temp/bumped_prtPX0001.exr

modulate_prtPY.blend
  inputs:
    /temp/bent_prtPY0001.exr
    /bump/normalGimp.png
  output:
    /temp/bumped_prtPY0001.exr

modulate_prtPZ.blend
  inputs:
    /temp/bent_prtPZ0001.exr
    /bump/normalGimp.png
  output:
    /temp/bumped_prtPZ0001.exrback

modulate_prtNX.blend
  inputs:
    /temp/bent_prtNX0001.exr
    /bump/normalGimp.png
  output:
    /temp/bumped_prtNX0001.exr

modulate_prtNY.blend
  inputs:
    /temp/bent_prtNY0001.exr
    /bump/normalGimp.png
  output:
    /temp/bumped_prtNY0001.exr

modulate_prtNZ.blend
  inputs:
    /temp/bent_prtNZ0001.exr
    /bump/normalGimp.png
  output:
    /temp/bumped_prtNZ0001.exr

modulate_prtP.blend
  inputs:
    /temp/bumped_prtPX0001.exr
    /temp/bumped_prtPY0001.exr
    /temp/bumped_prtPZ0001.exr
    /bump/prtP_fixed0001.exr
  output:
    /temp/bumped_prtP0001.exr

modulate_prtN.blend
  inputs:
    /temp/bumped_prtNX0001.exr
    /temp/bumped_prtNY0001.exr
    /temp/bumped_prtNZ0001.exr
    /bump/prtN_fixed0001.exr
  output:
    /temp/bumped_prtN0001.exr


//// Modulate all 6 PRT channels to add bump shadows modulation ////

shadow_prtPX.blend
  inputs:
    /temp/bent_prtPX0001.exr
    /bump/UAO_bump_shadows0001.exr
  ouput:
    /temp/shadowed_prtPX0001.exr

shadow_prtPY.blend
  inputs:
    /temp/bent_prtPY0001.exr
    /bump/UAO_bump_shadows0001.exr
  ouput:
    /temp/shadowed_prtPY0001.exr

shadow_prtPZ.blend
  inputs:
    /temp/bent_prtPZ0001.exr
    /bump/UAO_bump_shadows0001.exr
  ouput:
    /temp/shadowed_prtPZ0001.exr

shadow_prtNX.blend
  inputs:
    /temp/bent_prtNX0001.exr
    /bump/UAO_bump_shadows0001.exr
  ouput:
    /temp/shadowed_prtNX0001.exr

shadow_prtNY.blend
  inputs:
    /temp/bent_prtNY0001.exr
    /bump/UAO_bump_shadows0001.exr
  ouput:
    /temp/shadowed_prtNY0001.exr

shadow_prtNZ.blend
  inputs:
    /temp/bent_prtNZ0001.exr
    /bump/UAO_bump_shadows0001.exr
  ouput:
    /temp/shadowed_prtNZ0001.exr

shadow_prtP.blend
  inputs:
    /temp/shadowed_prtPX0001.exr
    /temp/shadowed_prtPY0001.exr
    /temp/shadowed_prtPZ0001.exr
    /temp/bumped_prtP0001.exr
  output:
    /temp/bumpshadowed_prtP0001.exr

shadow_prtN.blend
  inputs:
    /temp/shadowed_prtNX0001.exr
    /temp/shadowed_prtNY0001.exr
    /temp/shadowed_prtNZ0001.exr
    /temp/bumped_prtN0001.exr
  output:
    /temp/bumpshadowed_prtN0001.exr

prt_normalizer_2.blend
  inputs:
    /bump/UAO_bumped0001.exr
    /temp/bumpshadowed_prtP0001.exr
    /temp/bumpshadowed_prtN0001.exr
  outputs:
    /bump/final_bumped_prtP0001.exr
    /bump/final_bumped_prtN0001.exr


//// Combine the bump modulated prt's into a new bent normal, then make it tangent-space ////

prt_to_bent_normal_2
  inputs:
    /bump/final_bumped_prtP0001.exr
    /bump/final_bumped_prtN0001.exr
  output:
    /temp/bumped_bent_normal_model_space0001.exr

bent_normal_to_tan_sp_2R.blend
  inputs:
    /bakes/U_vec.exr
    /temp/bumped_bent_normal_model_space0001.exr
  output:
    /temp/bumped_bent_normal_tangent_spaceR0001.exr

bent_normal_to_tan_sp_2G.blend
  inputs:
    /bakes/V_vec.exr
    /temp/bumped_bent_normal_model_space0001.exr
  output:
    /temp/bumped_bent_normal_tangent_spaceG0001.exr

bent_normal_to_tan_sp_2B.blend
  inputs:
    /bakes/N_vec.exr
    /temp/bumped_bent_normal_model_space0001.exr
  output:
    /temp/bumped_bent_normal_tangent_spaceB0001.exr

bent_normal_to_tan_sp_2.blend
  inputs:
    /temp/bumped_bent_normal_tangent_spaceR0001.exr
    /temp/bumped_bent_normal_tangent_spaceG0001.exr
    /temp/bumped_bent_normal_tangent_spaceB0001.exr
  output:
    /bump/final_bent_normal_tangent_space0001.exr
Yeah, that's a lot of noodles to run, and some take as long as a minute or two to complete;
but one thing I can say for it: All you have to do is load one file at a time into Blender and
press the [Use Nodes] button.

The plan is to eventually put all of LaGrande into an executable you only have to run once;
so the use of Blender noodles is only the initial way. Once LaGrande matures, we'll just
code it.
www2
Venturer
Venturer
Posts: 537
Joined: Sat May 14, 2005 10:51 am
Location: milkyway->the sol system->earth->Europe->The Nederland->Soud Holland->Leiden
Contact:

Re: CineMut shader family - Opaque

Post by www2 »

@chuck_starchaser
Your right this is the silents before the storm.
And sofare that i know the project were hellcatv and ace123 use oger.
All Your Base Are Belong To Us
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 »

Thanks for the crarification! And glad it is Ogre-based. That's good news.
denyasis
Hunter
Hunter
Posts: 75
Joined: Thu Mar 19, 2009 10:31 am

Re: CineMut shader family - Opaque

Post by denyasis »

A) beautiful ship - Really

B) New engine?!? - YaY! I hope for the best :-)
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 »

Thanks! :)

Yeah, I just filled their wiki discussion page on coding standards, trying to steer
them in the right direction.
http://www.sirikata.com/wiki/index.php? ... _Standards
As I said to Henrik, the main guy there, by email, I hope their engine will be clear
and easy to work with.
Post Reply