CubeMapGen setup

[chuck_starchaser]

For those wanting to get cracking on producing cubemaps, get ATI's CubeMapGen, read the 2-page manual,
and start making cubemaps out of the existing backgrounds.
Below is the set-up I found gives the best results:



There's two things I don't know; maybe someone else can answer:

1) Where to get the background originals. Working from the DDS-compressed backgrounds in the data repo would not be the best idea.

2) What format to save as; naming convention, etc.

[pyramid]

I thought cubemaps would be just a programmatic change and would not require the stitching of all 6 faces into one file.

ad 1) Anyway, you can find all originals in the svn masters/textures/backgrounds folder.

ad 2) Supposedly cubemaps will be mipmaped, logo the .texture extension is applicable here.

[chuck_starchaser]

Perhaps we only need single faces; I don't know. But what I do know is that, either way, we need the mipmaps
for each face to be produced by CubeMapGen, rather than by a generic mipmap generator like nvcompress.
Huge difference when you're looking at reflections off a low shininess material: Individual faces look
blurred, but each face looks blurred separately, with sharp seams between. Check the pics in the CubeMapGen
page:
http://developer.amd.com/gpu/cubemapgen ... fault.aspx
Well, a year ago CubeMapGen did not exist, and that's probably why the issue didn't come up.

R.e.: masters: thanks.

R.e.: extension/naming: I think there has to be some kind of naming and/or extension scheme that will
allow shaders to distinguish the mipmapped cubemaps; not sure. What I'm thinking is...
Nah...
What I WAS just thinking is that older shaders would continue to use spheremaps, but no reason to;
we can change all shaders at once to use cubemaps; only a few lines need to change.
Anyways, IF we want the 6 faces in a single cube cross texture, we'd probably use the name of the background
without the "front", "back", "up", etceteras, parts, and .texture extension, I suppose.


BTW, change of setup: Same as before, but changed Mip Initial Filter angle to 1.4 from 0.8. I don't know
why, in the sense that the theoretically right value is 0.35, but the blurring between mip 0 and mip 1 is not
even visible like that.
It's probably because of the use of a sphere in testing; if a flat plane was reflective it would reflect with higher
resolution and the difference would be more noticeable. On the other hand, a) having flat reflective surfaces is not
a good idea; b) having Mip Filter Angle Scale greater than 2.0, as was my original plan, doesn't give very good
results (kind of inconsistent across mipmaps); c) all mip levels from 1 onwards look smoother with the extra
filtering; d) mipmap 0 should then also be filtered using a Base Filter Angle of like 0.7 to be consistent, yes, but
yet, mipmap 0 doesn't really need filtering, and should not have it if we are going to use it to draw the background
from; and finally e) yes, this means
that our shininess = 1 mipmap level (which is the level we will use for ambient light fetch) becomes mipmap 8,
so that mipmaps 9 and 10 are wasted, but the thing is, mipmaps 9 and 10 should be wasted because they are
are too low-rez, anyways (2x2 pixels and 1x1 pixels sides).

[chuck_starchaser]

UPDATE

Let this post serve as a draft for a wiki How-To:

How to convert existing backgrounds to cube-maps

You need to download and install ATI's CubeMapGen tool.

Launch the program.
You'll see a sphere with colored sqares reflected.
Change the settings so they are exactly like on the right panel on the picture below:



Now,

• Were it says Select Cube Face, there's a drop down box on the right of it. Click the
  little triangle and select the first item at the top: X+ Face <1>.
  Hit the [Load CubeMap Face <F>] button. Browse till you find the texture's front: <background_name>_front.png
  One of the sides on the background, and its reflection on the sphere, should change to the selected image.
• Select the second cube face: X- Face <2>. Load the ..._back texture.
• Select the third cube face: Y+ Face <3>. Load the ..._up texture.
• Select the fourth cube face: Y- Face <4>. Load the ..._down texture.
  Here it's a good idea and fix face orientations. For some reason it seems that the first 3 faces always load
  already with the correct orientation, but the fourth one is wrong.
  There are 3 buttons just below that Flip ... this or that. Try them at random until the face matches
  the neighboring faces seamlessly.
• Select the fifth cube face: Z+ Face <5>. Load the ..._right texture.
• Select the sixth cube face: Z- Face <6>. Load the ..._left texture.
• Verify that everything is seamless by rotating the scene (drag the mouse with the left button down).
  If anything is not matching, fix it
  Problem with CubeMapGen is that there are no labels on the faces, so the only way to know which face a face is
  is to try selecting faces, one by one, with the combo box, and toggling one of the Flip buttons twice.
  (Twice because if you have the wrong face which was right and you flip it, it will be wrong, so you want to flip it back.)
  Once you have the right face (the one that is wrong), flip it till it's right.
• Hit the [Filter Cube Map] button, near the bottom of the panel, and go out for a capuccino. Double.
• Once you're back, try the various LoD levels to make sure the filtering is seamless, rotating the scene
  for each LoD show.
• If satisfied, hit the [Save Cube Map (.dds)] button, near the top. (Yeah, the layout of the buttons does follow
  chronological order... but by development date, rather than usage.)

Needless to say, you should use the master textures for this, rather than the compressed textures from
the game folder...

Cheers!

[chuck_starchaser]

Here's a CubeMapGen-converted background for example/testing/comparison:
http://deeplayer.com/vs/shaders/bluegreen.zip

To modify any fragment program (.fp) shader to use cube-maps, near the top of the file, where it says something like,

Code: Select all

uniform sampler2D envMap;

change that to,

Code: Select all

uniform samplerCube envMap;

Then somewhere in the file there should be a routine, or pair of them, like...

Code: Select all

vec2 EnvMapGen(vec3 f) {
    f = normalize(f);
    float fzp1=f.z+1.0;
    float m=2.0*sqrt(f.x*f.x+f.y*f.y+(fzp1)*(fzp1));
    return vec2(f.x/m+.5,f.y/m+.5);
}
vec3 envMappingLOD( in vec3 direction, in float LoD )
{
    vec4 result = texture2DLod( envMap, EnvMapGen(direction), LoD );
    return result.rgb * result.a * 2.0;
}

That needs to simplify to,

Code: Select all

vec3 envMappingLOD( in vec3 reflection, in float LoD )
{
    vec4 result = textureCubeLod( cubeMap, reflection, LoD );
    return result.rgb * result.a;
}

NOTE: The last " ... * 2.0; " is eliminated because the reason it is there is that, in the current code, when sphere-maps are generated they are cut down in brightness by half, which had no physical basis for, so in my earlier fixing of VS shaders I multiplied by two to get brightness of reflections that matched with the backgrounds; but if we use the same cub-emaps for drawing backgrounds AND environment mapping, then that problem is eliminated.

[Fendorin]

maybe i wil write a stupidity:

isn't possible to use this kind of software/tools for create a high definition surface planet??? because a 2K picture for planet is definitively less

and if we use 2k x 6 picture for texturing a planet maybe is a easy solution for have a high resolution planet ingame no?

i repeat myself : i prefer have a nice environnement nice planet some floating asteroid, dust? than a 10 OX around a jump point o (one is suffisant) or 50 Static Taizong in 1 system....(why?)

[chuck_starchaser]

I'm not sure whether there is hardware support in GPU's to use cubemaps as projective textures. It could be done by modeling a sphere and unwrapping it to 6 square islands; but presently the engine doesn't use models for planets; it generates them on the fly.