CineMut shader family - Opaque

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

Moderator: Mod Contributor

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

Post by chuck_starchaser »

The problem is that the engine doesn't know how to read that very format; --all 6 sides combined. That's what Klauss was going to work on when his videocard died. :-(
pyramid
Expert Mercenary
Expert Mercenary
Posts: 988
Joined: Thu Jun 15, 2006 1:02 am
Location: Somewhere in the vastness of space
Contact:

Post by pyramid »

Anyway, I forgot some files. After recompile I don't get the error anymore. All runs fine...but still not bike to see :-(. I think I'll wait for the pros to finish this one.
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Post by chuck_starchaser »

I'll have to get my files in order soon enough, to test the Hammer.
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Post by chuck_starchaser »

Anybody knows how to turn a bunch of jpg's into a movie?
Got specular self-occlusion sort of working:

Image
Image
Image
Image
Image
Image
Image
Image
Image
Image
Image
Image
Image
Image
Image
Image
Image
Image
Image
Image
Image
Image
Image
Image
Image
Image
Image
Image
Sindwiller
Merchant
Merchant
Posts: 32
Joined: Sun Aug 10, 2008 10:31 pm
Location: Zürich, Switzerland

Post by Sindwiller »

Why don't you try to use glc? http://nullkey.ath.cx/projects/glc If you're under Linux of course.

Or 30 seconds of Fraps^^
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Post by chuck_starchaser »

No; I'm in windooze; found what does it: ffmpeg.
Here we go!

CineMut Opaque shader --specular occlusion test (.mp4 video, 2 megs)

If you have any problem playing it, I know VLC Media Player plays it.
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Post by chuck_starchaser »

For those who didn't know what specular self-occlusion is, this set of new tests should explain it pictorially:

Image

Image

Image

Image

Image

Image

No; it's not really working that well; these are shots taken at a preferetial angle.
But I'm gradually getting there...

On other news, CineMut is finally slowing my 8800GTX down to a crawl! :D
Sindwiller
Merchant
Merchant
Posts: 32
Joined: Sun Aug 10, 2008 10:31 pm
Location: Zürich, Switzerland

Post by Sindwiller »

On other news, CineMut is finally slowing my 8800GTX down to a crawl!
You are some bad S.O.A.B. ^^
Dilloh
Elite Hunter
Elite Hunter
Posts: 1149
Joined: Mon Aug 14, 2006 3:56 pm
Location: Black Forest, Germany

Post by Dilloh »

I've noticed that the light reflections left to the pedal look rather... odd... like a drop of water coming up from that, what is it, piece of metal, and disappearing then.
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Post by chuck_starchaser »

That "drop" is some kind of artifact... :D
It's gone now; I don't know what caused it.
It's all looking much better now, by the way; and I posted an updated cinemut_opaque.fp, but I haven't got around making a movie yet; it's a lot of work, so I'll make one once I finish the work I'm doing on shadows.

@Sindwiller: I was saying in another post elsewhere, that if this shader is heavy enough to overtax even the latest videocards, we could make a Vegastrike Benchmark, that maybe places like Tomshardware could use when testing new videocards. It would be a first for OpenSource games, and great advertising ;-)
Unfortunately, it's fast again; but I got some features to add :D
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Post by chuck_starchaser »

Here's a screenshot of the latest:

Image

Notice how some objects would appear to be reflecting on other objects.
It's totally fake; no ray-tracing here :D
This code does it:

Code: Select all

float prt_spec_shadow( in vec3 dir, in vec3 nor, in vec3 prtp, in vec3 prtn, in float ao )
{
    vec3 VUT = normalize( dir );
    vec3 NOR = normalize( nor );
    vec3 PRT = prtp - prtn;
    vec3 NPRT = normalize( PRT );
    vec3 temp1 = cross( VUT, NOR );
    vec3 temp2 = cross( NPRT, NOR );
    float coplanarity_relevance = dot( temp1, temp1 ) * dot(temp2,temp2) * ao;
    float coplanarity = dot( normalize(temp1), normalize(temp2) );
    coplanarity *= coplanarity;
    float noncoplanarity = 1.0-coplanarity;
    noncoplanarity *= noncoplanarity; //less than full squaring makes weird things
    noncoplanarity *= sqrt(coplanarity_relevance);
    noncoplanarity += (0.1*(1.0-sqrt(dot(temp2,temp2))));
    float vutocclusion = 0.6366*asin(dot(PRT,VUT));
    vutocclusion += (sqrt(ao)+noncoplanarity-0.25);
    vutocclusion *= vutocclusion;
    vutocclusion *= vutocclusion;
    return clamp( vutocclusion, 0.0, 1.0 );
}
That's just about 50% science and 50% magic :P

The reflections look inaccurate and chaotic partly because the PRT bakes don't provide enough info to make out exact shapes; and mostly because the model is garbage, the unwrap is worse, and the bakes you guess... But even so, seeing those shapes moving as the bike moves does evoke self-reflections.
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Post by chuck_starchaser »

Shadows working!!! :D

CineMut Opaque shader --shadow test (.ogg video, 0.8 megs)
It's always a good idea, with video files, to right-click and download, then play off your hard drive.
If you have any problem playing it, I know VLC Media Player plays it.

BTW, I made the bike 50% diffuse gray for this test, as specular materials don't receive shadows.
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Post by chuck_starchaser »

If, by any chance, you get a 404 on the video above (I got one report of such an event taking place),
download it as a zip from here:
http://deeplayer.com/cinemut/0001_0031.zip

Or if you can't play ogg, here's an mpeg version, but it looks really crappy...
http://deeplayer.com/cinemut/test7777.mpeg

Here's an update of the routine, and a full explanation I emailed to Klauss:

Code: Select all

float prt_spec_shadow( in vec3 dir, in vec3 nor, in vec4 prt )
{
    vec3 VUT = normalize( dir );
    vec3 NOR = normalize( nor );
    vec3 PRT = prt.rgb;
    float ao = prt.a;
    vec3 NPRT = normalize( PRT );
    vec3 temp1 = cross( VUT, NOR );
    vec3 temp2 = cross( NPRT, NOR );
    float coplanarity_relevance = dot( temp1, temp1 ) * dot(temp2,temp2) * ao;
    float coplanarity = dot( normalize(temp1), normalize(temp2) );
    coplanarity *= coplanarity;
    float noncoplanarity = 1.0-coplanarity;
    noncoplanarity *= noncoplanarity; //less than full squaring makes weird things
    noncoplanarity *= sqrt(coplanarity_relevance);
    noncoplanarity += (0.1*(1.0-sqrt(dot(temp2,temp2))));
    float vutocclusion = 0.6366*asin(dot(PRT,VUT));
    vutocclusion += (sqrt(ao)+noncoplanarity-0.03);
    vutocclusion *= vutocclusion;
    vutocclusion *= vutocclusion;
    vutocclusion *= vutocclusion;
    vutocclusion *= vutocclusion;
    vutocclusion *= vutocclusion;
    vutocclusion *= vutocclusion;
    vutocclusion *= vutocclusion;
    vutocclusion *= vutocclusion;
    vutocclusion *= vutocclusion;
    return clamp( vutocclusion, 0.0, 1.0 );
}
Let's take it piece by piece:

Code: Select all

    vec3 VUT = normalize( dir );
    vec3 NOR = normalize( nor );
These are probably unnecessary; I just normalized them just in case.

Code: Select all

    vec3 PRT = prt.rgb;
    float ao = prt.a;
I made the prt_decode routine output a vec4 "prt", where prt.rgb = prtp-prtn and prt.a is the same uniform ao that comes with the prt texture's alpha channel.

Code: Select all

    vec3 NPRT = normalize( PRT );
A normalized PRT will be needed for the coplanarity computations.

Code: Select all

    vec3 temp1 = cross( VUT, NOR );
    vec3 temp2 = cross( NPRT, NOR );
To compute coplanarity, I need two vectors showing azimuth rotations of the VUT (Vector Under Test) and the PRT (bent normal) vector.
What is coplanarity?
Well, if you're looking at a point at a surface in front of you, and the PRT vector is pointing to the left, it means there's an occluder to the right, and such an
occluder does not occlude your reflection vector, no matter how big it is. So, coplanarity is a computation of how closely in the same plane are your view,
reflection and prt vectors.
So, what I'm doing is computing cross products between the normal and the reflection (or light) --i.e. VUT-- and between the normal and the PRT bent normal.
If the vectors are parallel OR opposite, the VUT and PRT are co-planar. If they are at 90 degrees, they are maximally non-coplanar.

Code: Select all

    float coplanarity_relevance = dot( temp1, temp1 ) * dot(temp2,temp2) * ao;
    float coplanarity = dot( normalize(temp1), normalize(temp2) );
Coplanarity relevance is a bit long to explain, but pretty simple:
Suppose the PRT bent normal and the normal are parallel: Their cross product is zero. They don't define a plane at all, so the coplanarity test is not applicable.
Similarly, if your view/reflection/light... VUT vector is parallel to the normal, coplanarity is a non-issue. So, relevance is essentially the product of the lengths
of the cross product vectors. Now, I'm also multiplying by the ao, and there's a reason for that. Non-coplanarity can make a strong force to negate occlusion;
but in very hidden places that can be a bad thing. There were lights appearing all over in the fins on the cylinders until I multiplied by the ao.
Note that we cannot simply leave the cross products un-normalized and let them carry their own relevance. I tried that first. Problem is, we need relevance
to apply to NON-coplanarity. See below.

So. now, coplanarity is simply the dot product of the two normalized cross-products. If coplanarity is close to 1 or -1, the VUT and PRT are coplanar with the
normal. If the dot product is close to zero, they are maximally non-coplanar, and we will avoid occluding.

Code: Select all

    coplanarity *= coplanarity;
Should be obvious: Coplanarity is at +1 OR -1, so obviously the true measure is the square of the dot product.

Code: Select all

    float noncoplanarity = 1.0-coplanarity;
:)

Code: Select all

    noncoplanarity *= noncoplanarity; //less than full squaring makes weird things
This is a discovery item during testing. It needed squaring; though I'm not exactly sure why. Multiplying by its square root was not enough.

Code: Select all

    noncoplanarity *= sqrt(coplanarity_relevance);
NON-coplanarity multiplied by relevance. Well, by its square root...
Here again, this was a bit hackish, if you want to call it that. The relevance I arrived at was too strong; it made coplanarity detection irrelevant too readily.
I tried a million things. No; can't get rid of the ao; or any of the other terms; but square-rooting the whole thing is okay.

Code: Select all

    noncoplanarity += (0.1*(1.0-sqrt(dot(temp2,temp2))));
This is the biggest hack of all; but it can still be explained: The lack of it caused very strange, vein-like or thread-like, or river-like artifacts.
The reason for the artifacts, after a lot of experimentation, was not, as I initially suspected, a problem with the relevance computation.
One typical artifact location was along the middle of the oval depression on the air filter unit. What happened along that middle was that PRT became
parallel to the normal, producing a zero length cross product, which got normalized to some random direction. So, along the center of the oval, there
was a river of points that produced totally random coplanarities. The relevance factor should have taken care of it, but for some reason it didn't.
Well, I know the reason: The vectors are normalized before dotting, so they produce stron coplanarity signals, whereas the relevance factor is
an analog signal that only goes down gradually. The artifact was not strong; only visible at shallow angles, but I wanted to get rid of it, and so the
the temp2 term came handy, which is already the PRT dot normal. By adding a bit of its inverse to non-coplanarity, the problem was fixed.

Code: Select all

    float vutocclusion = 0.6366*asin(dot(PRT,VUT));
    vutocclusion += (sqrt(ao)+noncoplanarity-0.03);
This is really the heart of the algorithm:
First let's discuss the rough terms and then refine it:
If PRT dot VUT were zero, we know the ray is occluded, UNLESS the AO is exactly 1.0.
If the AO is zero, we know the ray is occluded unless PRT dot VUT is exactly 1.0.
See a pattern?
If the sum of the two is 1.0 or greater, the ray is unoccluded. If their sum is less than 1.0, the ray is occluded.
At least that's what I thought: My first attempt was to write vtocclusion = dot(PRT,VUT) + ao.
But the linearity was not right.
So, what should the linearity be?
Well, the AO we pack with the PRT's is a uniform ao, for good reasons. You can say that the ao value represents the un-occluded solid angle.
Now, the dot product of PRT and VUT had to be converted back to an angle. The AO represents solid angles where 1.0 is a hemisphere; but so
the square root of the ao represents regular angle in 0-1 representing 0-90 degrees. But asin returns radians, so I had to multiply by 2/pi to get
to 0-1 representing 0-90 degrees.
So, the heart of ray occlusion is really 0.6366*asin(PRT,VUT)+sqrt(ao), where the threshold is 1.0
The non-coplanarity signal is added so that it negates occlusion to the extent that the VUT and PRT are not coplanar.
Then, the 0.03 subtracted is a hack. :)

Code: Select all

    vutocclusion *= vutocclusion;
    vutocclusion *= vutocclusion;
    vutocclusion *= vutocclusion;
    vutocclusion *= vutocclusion;
    vutocclusion *= vutocclusion;
    vutocclusion *= vutocclusion;
    vutocclusion *= vutocclusion;
    vutocclusion *= vutocclusion;
    vutocclusion *= vutocclusion;
    return clamp( vutocclusion, 0.0, 1.0 );
}
And the multiple squarings simply make a smooth boolean :D
If it's greater than one, it's unoccluded. If it's even slightly less than one it quickly becomes occluded.
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Post by chuck_starchaser »

CineMut is looking spectacular now, to my eyes. Time for others to try it and tell me I'm not hallucinating.
I'm calling this a,

CineMut Opaque shader -- pre-beta release

Image

(Full size image)

Move it around in Real Time! Just make a copy of Vegastrike and replace the following files:

http://deeplayer.com/cinemut/data/bin/v ... niques.exe
http://deeplayer.com/cinemut/data/missi ... ew.mission
http://deeplayer.com/cinemut/data/progr ... _opaque.fp
http://deeplayer.com/cinemut/data/secto ... iew.system
http://deeplayer.com/cinemut/data/techn ... .technique
http://deeplayer.com/cinemut/data/units/units.csv
http://deeplayer.com/cinemut/data/units ... detail.png
http://deeplayer.com/cinemut/data/units ... to_PRT.png
http://deeplayer.com/cinemut/data/units ... _bike.bfxm
http://deeplayer.com/cinemut/data/units ... bike.xmesh
http://deeplayer.com/cinemut/data/units ... _00001.png
http://deeplayer.com/cinemut/data/units ... _10001.png
http://deeplayer.com/cinemut/data/units ... _20001.png
http://deeplayer.com/cinemut/data/units ... _30001.png
http://deeplayer.com/cinemut/data/units ... _40001.png
Once you got all that in place, drag modelview.mission and drop it into vegastrikeR_techniques.exe.

It's not finished yet, however. I still have work to do on two areas:
  • "Shader AI" that a) uses ad-hoc metrics to classify materials and b) enables policies such as for
    main shininess allocation (to metallic or to fresnel specularity) and secondary shininess defaulting;
    as well as detail texture application policy.
  • Detail application policies.
And it also needs cube-maps, of course; and a proper test-bike :D
And LaGrande...
And CineMut FireGlass...
And compatibility versions of the shaders...
...speaking of which, you'd better have a pretty up-to-date videocard...

Features:
  • Single pass shader; up to two dynamic lights for now; both fully computed
  • Soft penumbras and shininess limit for light spots make light sources behave non-point-like
  • Environmentally sampled ambient lighting; 6-way sampled and modulated by prt bakes
  • Supports diffuse reflectivity, metallic specularity and dielectric specularity (fresnel)
  • Unparalleled handling of two-layer materials, such as paints.
  • Supports impure two-layer materials --eg plastics' exposed diffuse material on dielectric surface
  • Material below a dielectric layer can still be controlled in terms of diffuse/specular balance
  • All light refracted in a two layer material is multi-bounce modulated on exit (chroma effect)
  • Normalmapping using rgb for dU, a for dV; for higher precision with dds; encoded as tan(2*angle)
  • Convenient meta-exponential input curves on dielectric constant and shininess channels
  • Shininess applied to lights (Phong) AND to environment mapping LOD offset.
  • Three damage channels: Obscuration, plus two normalmap modifiers
  • Glow texture, of course
  • Universal detail texture with two dUdV modifiers to add sub-texel surface ripples + 2 noise channels
  • Detail control channel selects bumpy or "speckly" sub-texel detail, per-texel
  • Real time shadows AND specular self-occlusion, using Klauss' Global Illumination (GI) system
  • No-tweak policy: No hidden/additional parameters affect the final result; it's *all in the textures*
  • Demanding enough on most videocards that we could publish a Vegastrike Benchmark TM :D
pyramid
Expert Mercenary
Expert Mercenary
Posts: 988
Joined: Thu Jun 15, 2006 1:02 am
Location: Somewhere in the vastness of space
Contact:

Post by pyramid »

Congratulations! Excellent quality job :!:

Now, on my win machine the shading looks nice, though with my 32MB VRAM, the 3 texture units and "Compilation of technique cinemut_opaque failed... trying default" I do not expect the bike to look more than grey. Windows testing on my side will have to wait for the reduced instruction set fallback shader (CineMut_MiniOp).

I'll test all the files later at home on the NV 8600 (I'm very curious).
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Post by chuck_starchaser »

Thanks! Well, huge credits go to Klauss. Besides all the help I got from him throughout development, without his GI implementation this shader wouldn't be half as good; and without techniques it wouldn't even exist. Also Tangents, although this model has no normal-map yet (except for the micro-bumpiness it gets via the detail texture), so the advantage of tangents isn't being fully demonstrated yet. Huge credits also go to Hellcat for having implemented shaders in the engine, first of all.

One feature that is present and fully utilized in this model but not properly shown is LOD modulation of the environment map based on material shininess; and the reason it's not properly shown is because of our present lack of cube-map support. Sphere-maps are terribly anisotropic (deformed) so blurring of the texture is pretty much meaningless. Actually, cube-maps ARE supported. What we do not have in the engine is code that reads unified dds cube-maps, which are currently what ATI's CubeMapGen tool exports (and without CubeMapGen's cross-face filtering features we'd have the infamous problem of traditional cube-maps, whereby LOD's show sharp seams on reflections).

In spite of that, and in spite of the yet to be completed AI and policies, the shader is functional enough that brave artists willing to start experimenting with CineMut texturing techniques can now do so.
(Well, not quite; I need to put together a pre-beta release of LaGrande; --working on it, as I work on the Toad/Hammer...)

EDIT:
Klauss, I have an idea for how to fake specular reflections from baked static lights. It is based on the same idea I implemented in the Blender noodle that bump-modulates radio bakes and AO: guesstimating the direction of incident light by sampling u-1, u+1, v-1 and v+1 in the glow texture. I can do that and come up with a vector in tangent space, then dot it with the reflection vector, raise it to the power of the shininess, multiply again by shininess, and use that to multiply the underlying glow. What do you think?
I need your help for how to do those fetches, though: The u/v offsets should scale with the LOD... (I'm thinking I will need an LOD bias, because of the low precision of dds).

EDIT2:
Another issue I've been thinking about is LOD computations for the environment map. The ATI code example does a lot of weird stuff I don't understand. CubeMapGen optionally puts some kind of LOD bias parameter in the alpha channel of cube-maps. I suppose this has something to do with modulating LOD to account for how surface curvature and distance impact the cubemap fetching stride as we reflect rays off a surface in screen-space? If that's not it, it would make a lot of sense to do so, anyhow. I could try and make a noodle that computes surface curvature from a normalmap bake in model space, then modulates it by the tangent space normalmap, turns that into an LOD bias and writes it to the alpha channel of the glow-map (since we'll have ao in the prt's, already); or else I could simply use it to statically modulate the shininess map (the only problem being that what matters is radius of curvature relative to view distance, rather than absolute curvature... On the other hand, we could modulate shininess with distance globally; or go smack in the middle: modulate shininess by the square root of distance).
pyramid
Expert Mercenary
Expert Mercenary
Posts: 988
Joined: Thu Jun 15, 2006 1:02 am
Location: Somewhere in the vastness of space
Contact:

Post by pyramid »

Congratulations extended to klauss and hellcatv.

The bike looks beautiful on my main machine. The stars of the environment reflecting blurringly on the shiny surface of the fuel tank is a joyful sight. All in all the shading is already excellent as it is now.

Now I need to go look for the correct conversion pipeline. I suppose I had an old model export of yours as it generated 13 separate xmesh files. Is there a chance you can post you blender model, too.
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Post by chuck_starchaser »

Damn! I neglected to post the blend file since I was lazy to look for it, and now I'm at work and don't have it here.
Tonight I'll put the bike and all its files in the models svn repo at the junction server; and create a new repo for shader development. Or, maybe I'll be a bit lazier and just make a cinemut folder in the utilities repo.
Did you delete the .mtl file? The .mtl file would contain 13 materials, and I think mesher assumes that materials mean meshes. My materials are there for baking textures; they don't imply meshes. I think if you just delete the .mtl file mesher should produce a single xmesh file.
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Post by chuck_starchaser »

Sorry, I came home late last night and went straight to bed. Here's the blend file:
http://deeplayer.com/vs/shaders/testmod ... ycle.blend
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Post by chuck_starchaser »

Major hack implemented that fakes specular reflections from static light bakes; with fresnel and all.
Another first in this whole industry...

Image

Image

Image

Image

Thought I'd mention, the lights are a separate mesh that will use the CineMut FireGlass shader;
the point is, there are NO specular reflections; it would take real-time raytracing to have real specular
reflections of static lights. The hack is faking them, though, by measuring glow map light differentials and
using an ad hoc formula to guess the reflection angle.

Shader updated:
http://deeplayer.com/cinemut/data/progr ... _opaque.fp

Well, it doesn't work too well yet; sent the code to Klauss for a second opinion.

By the way, Phlogios had VegastrikeR_techniques.exe crash on him. Long story short: If that happens to you, read this post by JackS:
http://vegastrike.sourceforge.net/forum ... 639#103639

Thought I'd also mention, Klauss and I finally figured out what's wrong with the PRT bakes. We had asked Santiago Orgaz, months ago, to implement PRT baking for us, in xNormal. He did it; but we'd made a mistake in the specifications: One term needed to be squared. We wrote an email to Santiago, and he's going to have the problem fixed on the next version of xNormal; --possibly next week.
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Post by chuck_starchaser »

I've rewritten the shader AI and detail texture application policies from scratch, but it's not tested yet. I went to check my bike materials in Blender and realized I hadn't started using materials in the CineMut way, yet. I did with the Hammer, but not with the test bike. With the test bike I had diffuse and specular colors, and the other channels I produced in Gimp or using noodles. So I started setting up real materials and found I couldn't stand the terrible automatic unwrap and all the artifacts it made, anymore; so I decided to re-unwrap it.
Final proof of a half decent unwrap is an ambient occlusion bake free of artifacts, so here's proof:

Image

This is going to be a much better test for such subtleties as specular self-occlusion. Tons of chrome here.
Hopefully the materials will be much better now, too.
I'll start baking and processing the textures.
Santiago Orgaz said he'll probably have a new version of xNormal by Wednesday, with all the new bells and whistles we asked for :)
Precise PRT's should make a helluva lotta difference.
I also just came up with a new idea to improve the images of specular reflections from statically baked lights: taking help from specular self-occlusion... ;-)
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Post by chuck_starchaser »

New materials bakes:

albedo_bake.tga:
(albedo is the sum of diffuse and specular)

Image

specular_bake.tga:
(red = specularity; green = dielectric coverage; blue = dielectric constant)

Image

misc_bake.tga:
(red = shininess; green = detail; blue not used; always 0.5)

Image

normals_in.tga:

Image

Just following my own instructions from the LaGrande documentation...
pyramid
Expert Mercenary
Expert Mercenary
Posts: 988
Joined: Thu Jun 15, 2006 1:02 am
Location: Somewhere in the vastness of space
Contact:

Post by pyramid »

Nice progress, chuck.
It would be great to have the documentation pointing to the repository for LaGrande set of noodles so that we can always get the latest one.
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Post by chuck_starchaser »

I have probably about a hundred noodles spread out all over the place, and none is yet "standard", exactly. I'm about to start producing standard noodles now; that's why I'm following my own instructions in baking the bike's material textures.
Everything needs adjustment, now, anyhow, due to the change of policy with the glow-map: Originally, the glow map was going to be pre-multiplied by the diffuse; but now it will have to contain just pure light, for the specularities' hack to work. Another change for the glow-map is that, originally, I was going to use gamma in the encoding of it; but because it was premultiplied by diffuse, and the diffuse texture could be speckly, it could have introduced visible artifacts with mipmaps, so I gave up on the idea and changed my noodles accordingly. Now that glow maps are going to be smooth, pure light, I can bring back the gamma idea.
I'll then use the new noodles again on the Hammer, for a second live test, and then I'll put them in svn and release a pre-beta LaGrande set.
pyramid
Expert Mercenary
Expert Mercenary
Posts: 988
Joined: Thu Jun 15, 2006 1:02 am
Location: Somewhere in the vastness of space
Contact:

Post by pyramid »

Thanks for the status update. With such state-of-the-art advancements it's sometimes hard to stay patient and wait to get a grab on the tools. For now, I will persist...
Post Reply