Celestia Forums

Tonight I had some interesting ideas about ways to use cube maps in Celestia. A cube map is a set of six square textures, each the face of a cube. All modern graphics hardware supports them. A normal texture is indexed by two coordinates (u,v); but with a cube map, the lookup uses a 3-vector (x, y, z) The cube map is sampled at the point where the vector intersects the cube. Despite the extra complexities, it's just as fast as regular texture mapping.

So what is it good for? It's most often used for a technique called reflection mapping. More generally, a cube map is used as a lookup table for functions of direction. Here's an article with some samples:

http://developer.nvidia.com/object/cube ... orial.html

They're incredibly useful when dealing with spheres . . . In Celestia, a cube map could be used to store a planet texture. The equivalent of a 16k x 8k texture could be stored in a cube map with 6 4k x 4k faces. That's 25% less memory, because there's less memory used for the polar regions of a planet which are oversampled relative to the equatorial areas when using rectangular maps (simple cylindrical projections.)

There's also no singularity around the poles with cube maps. However, when producing a cube map, the source is probably going to be a simple cylindrical projection. You could do some high quality filtering when generating the cube map to limit the artifacts near the pole. Or better yet, you could start with images that weren't cylindrical projects and go directly to a cube map.

Another use of cube maps would be to overcome the size limitations of cloud maps. GeForce cards have a maximum texture size of 4k x 4k; a cube map with 4 4k x 4k faces gives you a cube map that is effectively 16k x 8k. And rotation and cloud shadows would work with such a texture. In fact, cloud shadows would work much better with cube maps because you could skip the very expensive spherical to cartesian coordinate conversion that's required when you have a regular cloud map.

A big down side is that there isn't any way to split cube maps or do virtual texturing with them. But, there are enough benefits that I'll probably add support for them to Celestia some time in the future--sooner rather than later if I can convince a skilled texture creator to produce a cube map texture without an intermediate simple cylindrical projection.

--Chris

It sounds to me like we'll also need a program that converts one or more of the standard map projections into cube-map projections.

I've found several Web pages that discuss the algorithms involved, but so far I've only found one downloadable purported conversion program which fails to install.

That?€™s an interesting idea. I have known that games in the past have used this technique to create the larger world outside the game arena, but I never though of doing it in reverse. This could be a huge improvement for various reasons. I would not think that it would be that difficult to take existing maps and break them into 6 smaller textures. With a little extra tweaking you might be able to fix the normal pinching that occurs with cylindrical mapping.

selden wrote:It sounds to me like we'll also need a program that converts one or more of the standard map projections into cube-map projections.

I've found several Web pages that discuss the algorithms involved, but so far I've only found one downloadable purported conversion program which fails to install.

It would not be difficult to write a program to generate a cube map from a simple cylindrical projection. My cmodsphere utility actually does something similar, except that it generates geometry. I think most of the time would be spent trying to get the best possible filtering in order to make the polar regions look good.

--Chris

I contacted Matthew Arcus about doing it with MMPS. It turns out that it can be done without adding any special conversion routines. If the input is a simple cylindrical map, the following commands will generate six cube faces. Of course, one might like to use a high resolution input file and create much larger output files


Now we just need a way to specify the six faces in an SSC file

I also persuaded him to add Hammer-Aitoff projection to the formats that MMPS can handle. An updated version of MMPS will be available RSN.

selden wrote:I contacted Matthew Arcus about doing it with MMPS. It turns out that it can be done without adding any special conversion routines. If the input is a simple cylindrical map, the following commands will generate six cube faces. Of course, one might like to use a high resolution input file and create much larger output files

Code: Select all

./project gnomonic -scale 2 -lat 0 -long 0 -w 512 -h 512 -f images/earth.ppm >earth0000.ppm
./project gnomonic -scale 2 -lat 0 -long 90 -w 512 -h 512 -f images/earth.ppm >earth0090.ppm
./project gnomonic -scale 2 -lat 0 -long 180 -w 512 -h 512 -f images/earth.ppm >earth0180.ppm
./project gnomonic -scale 2 -lat 0 -long 270 -w 512 -h 512 -f images/earth.ppm >earth0270.ppm
./project gnomonic -scale 2 -lat 90 -long 0 -w 512 -h 512 -f images/earth.ppm >earth9000.ppm
./project gnomonic -scale 2 -lat -90 -long 0 -w 512 -h 512 -f images/earth.ppm >earth1800.ppm


Excellent! I'm glad that there's already a utility which can do this.

Now we just need a way to specify the six faces in an SSC file

.dds files can contain cube faces. The simplest thing to do would be enable cube maps any time a cube map was specified in a Texture directive.

--Chris

Presumably there'll be a convention defined for the order that the cube faces should be loaded into the dds file. Otherwise some objects will look a little strange.

selden wrote:Presumably there'll be a convention defined for the order that the cube faces should be loaded into the dds file. Otherwise some objects will look a little strange.

There is a defined order for cube faces in a DDS file:

http://msdn.microsoft.com/archive/defau ... ntmaps.asp

--Chris

Hi Chris,

I was wondering other then overcoming the 2k texture issues, and saving some space on the video ram, why go to cubic textures? What are the limitation of the tangentspace shadow projection.

Thanks

-Matt-

Hi,

I've been working on creating a cubemaps for planets i.e. heightmap data and image data. I'm willing to share the source when its finished - its still a bit messy at the moment. I simply use the near plane of a view frustrum transformed for each face of the cubemap to align a grid and cast rays that intersect a unit sphere - I then get the intersection position and use this to index a 3d texture which I assume has unit size.

The cubemaps I have generated so far have been good - although I still need to align the texels properly as I have included the edges of the view frustrum in the cast rays, when instead the rays should be offset by half a texel size.

I thought I would mention that ATI's cubemap generator is a good tool for combining multiple textures into cubemaps. It also has filtering commands and a blur command to get rid of seams.

http://ati.amd.com/developer/cubemapgen/index.html

Thanks

a demo with source of the cubemap algorithm is available at:-

http://www.kai-soft.co.uk/noise.zip

requires directX and vc8 to compile.

cheers

the demo is still available from the above link, although i have removed it from the main page. The code is a real mess because I created the demo in a matter of hours.

I just thought that I should justify my reason for posting the code - I think it is best to use a cubemap for a planetary terrain, I happen to have made one and I used celestia math to calculate the cubemap coordinates.

The best reasons for using a cubemap for a planet texture are:

1) most heightmap algorithms use a rectangular array, and the cubemap allows the entire sphere to be represented by rectangular arrays.

2) The cubemap eliminates any warp in the texture at the poles.

3) Most planet engines apart from VTP (http://www.vterrain.org/) use a cubemap to represent the planet texture.

4) Artificial Intelligence programs for Strategy computer games usually use a rectangular array for the map. (The pathfinding algorithm is often the A* algorithm which works on a graph which is created from the array).


I realize that the development requests post is now closed, however I think it would be a good to add a feature that allows users to swap to a cubemap representation of the terrain if they choose to (or if hardware is suitable) since the planet engines are quite good for representing a terrain.

As a former Software Engineer I think it would also be nice to see a plugin facility for engines such as Open Scene Graph and Open Dynamics Engine.

cyber_space_doc wrote:the demo is still available from the above
link, although i have removed it from the main page. The code is a real
mess because I created the demo in a matter of hours.

I just thought that I should justify my reason for posting the code -
I think it is best to use a cubemap for a planetary terrain, I
happen to have made one and I used celestia math to calculate the
cubemap coordinates.
...

Many Celestia users are only marginally interested in texture sizes
small enough to be rendered in "one piece".

++++++++++++++++++++++
If advertising cubemaps you should also address the fact that currently
virtual textures (tiles) cannot be handled with cubemaps!
++++++++++++++++++++++

That's what many of us actually use/want, however. Personally, I am
way too spoiled by >=64k textures to watch e.g. a "small" 16k x 8k texture display of Earth or Mars

Moreover with the code that my VT tile-generation tools are using the
rendering problems near the poles are no problem really, since the
resolution is appropriately reduced in the relevant tiles.

Along the same lines, I don't buy that memory argument by Chris
in favor of cubemaps:

In Celestia, a cube map could be used to store a planet texture. The
equivalent of a 16k x 8k texture could be stored in a cube map with 6
4k x 4k faces. That's 25% less memory, because there's less
memory used for the polar regions of a planet which are
oversampled relative to the equatorial areas when using rectangular
maps (simple cylindrical projections.)

This only applies to "one-piece" textures, NOT to VT's.

With my polar-optimized tiles, featuring a proper reduction of polar
resolution, the effective memory consumption should be about
equivalent.

Bye Fridger

t00fri wrote:This only applies to "one-piece" textures, NOT to VT's.

True, but to how many bodies do VT apply? The Earth, the Moon and Mars, that's about it.

That lives cubemaps as a valid alternative for all the other bodies. A worthwhile improvement don't you think?

Christophe wrote:

t00fri wrote:This only applies to "one-piece"
textures, NOT to VT's.

True, but to how many bodies do VT apply? The Earth, the Moon and
Mars, that's about it.

If I had the time, I could also do a pretty big Mercury texture. The data
are there, but need to be tediously assembled. I have done a 8k map
long time ago. The Venus radar maps are LARGE (32k?) as well.

That lives cubemaps as a valid alternative for all the other bodies. A
worthwhile improvement don't you think?

I am not convinced:

-- for the smaller bodies 25% memory saving in cubemaps is
correspondingly less critical. I would still much prefer to tile textures (e.g.
8k sized ones) in case card memory is short and to improve polar rendering.
Meanwhile we have MANY textures from planetary moons at the 8k
size level

-- In my view a "relaxed" handling of cubemaps with spec and cloud
textures etc would require quite specialized mapping software for
Celestia. Personally, I don't think it's worth the effort.

-- I first want to see how in high-end multi-texture cube maps
the seams are handled etc. Remapping USUALLY results in lack of
quality! Don't forget that presently we directly operate with 16bit
integer raw data for normal maps in order to optimize quality. These
considerations are entirely irrelevant for game programming where
cube maps are popular.

-- How are mipmaps handled and packed??


For me there are many important BUT open questions.

At least what I could read up to now did not impress me that much.


Bye Fridger

t00fri wrote:

Christophe wrote:

t00fri wrote:This only applies to "one-piece"
textures, NOT to VT's.

True, but to how many bodies do VT apply? The Earth, the Moon and
Mars, that's about it.

If I had the time, I could also do a pretty big Mercury texture. The data
are there, but need to be tediously assembled. I have done a 8k map
long time ago. The Venus radar maps are LARGE (32k?) as well.

That lives cubemaps as a valid alternative for all the other bodies. A
worthwhile improvement don't you think?

I am not convinced:

-- for the smaller bodies 25% memory saving in cubemaps is
correspondingly less critical. I would still much prefer to tile textures (e.g.
8k sized ones) in case card memory is short and to improve polar rendering.

If the 25% memory savings was the primary advantage of cubemaps, I would definitely say it wasn't worth the effort. But, it's really just a bonus.

Meanwhile we have MANY textures from planetary moons at the 8k
size level

. . . which would nicely fit into a cube map with 2k sides.

-- In my view a "relaxed" handling of cubemaps with spec and cloud
textures etc would require quite specialized mapping software for
Celestia. Personally, I don't think it's worth the effort.

-- I first want to see how in high-end multi-texture cube maps
the seams are handled etc. Remapping USUALLY results in lack of
quality! Don't forget that presently we directly operate with 16bit
integer raw data for normal maps in order to optimize quality. These
considerations are entirely irrelevant for game programming where
cube maps are popular.

There's nothing prohibiting you from generating normal cubemaps from 16-bit data either. Cubemaps have a huge advantage over simple cylindrical maps because there's no singularity at the poles. It would be possible to produce a cube map from a cylindrical projection using very high quality filtering--this map would have much less 'pinching' at the poles than the cylindrical map, because to cylindrical to cubemap converter can do a better job of filtering near the pole than hardware. A better idea is to start with maps that aren't cylindrical projections, such as Cassini's polar maps of Jupiter: http://saturn.jpl.nasa.gov/multimedia/i ... tegoryID=3
This way, the messy business of handling the singularity is completely avoided.

-- How are mipmaps handled and packed??

OpenGL is very clear about the arrangement of mipmap levels for cubemaps. There's no problem here at all.

At least what I could read up to now did not impress me that much.

General support for cubemaps is definitely not my top priority, but they have significant advantages that will be worth exploring eventually. In order to do cloud shadows properly, cube maps are quite important; the special case of cloud cube maps is something that I may implement for 1.5.1.

--Chris

Chris,

it is of course true that the map of a cylinder onto a sphere is singular at the poles. But if I project a cube onto a sphere there are also "singular" regions: the cube edges and the corners. These are just mapped onto regions of the sphere that are different from the poles. Did you look at these regions already with highest zoom and resolution, checking critically the definition??

I just know the mathematics involved in these maps and simply have problems to believe that one is getting "a free present" here...

How are the edge and corner singularities smoothed out without loosing delicate definition in case of cubemaps??

If you want to make use of genuine polar imaging for the
cube maps, which cross-platform projection software did you have in mind for use in Celestia?? I suppose, all this will have to be coded first, if it is to satisfy e.g. my high-quality requirements, ...

On the other hand, the polar problem can be easily taken care of NOW by reducing the resolution of polar tiles without using cubemaps at all.

I can't help thinking that there are more urgent tasks than supporting cubemaps in Celestia.

Bye Fridger

t00fri wrote:I can't help thinking that there are more urgent tasks than supporting cubemaps in Celestia.

I ABSOLUTLY agree with Fridger here.

t00fri wrote:Chris,

it is of course true that the map of a cylinder onto a sphere is singular at the poles. But if I project a cube onto a sphere there are also "singular" regions: the cube edges and the corners. These are just mapped onto regions of the sphere that are different from the poles. Did you look at these regions already with highest zoom and resolution, checking critically the definition??

I just know the mathematics involved in these maps and simply have problems to believe that one is getting "a free present" here...

Then you know that the polar singularity is of a completely different nature and much more problematic than the discontinuities at the cube edges.

How are the edge and corner singularities smoothed out without loosing delicate definition in case of cubemaps??

Quite nicely. Not all hardware can filter texels across cube faces, but the artifacts from this are barely perceptible when faces match at the edges. Contrast this with the plainly visible spikes at the poles of planets with simple cylindrical textures.

If you want to make use of genuine polar imaging for the
cube maps, which cross-platform projection software did you have in mind for use in Celestia?? I suppose, all this will have to be coded first, if it is to satisfy e.g. my high-quality requirements, ...

On the other hand, the polar problem can be easily taken care of NOW by reducing the resolution of polar tiles without using cubemaps at all.

Agreed that some tool development is probably necessary. I don't know what's currently available. But, cube maps will handle the polar mapping problem better than reducing the resolution of VT tiles near the pole. VTs don't solve the problem as well, and only a minority of objects have VTs anyhow.

I can't help thinking that there are more urgent tasks than supporting cubemaps in Celestia.

I agree with this. I just wanted to emphasize the real advantages that cubemaps have for texture mapping spheres.

--Chris

chris wrote:Then you know that the polar singularity is of a completely different nature and much more problematic than the discontinuities at the cube edges.

Correct, but on the other hand, the pole singularities are confined to the environments of 1 point each! The maps of the many edge and corner singularities are spreading over many regions of the sphere where we usually want to render more concise information than at the poles...

Show me a really high resolution map from cubemap rendering! I am always ready to be convinced

How are the edge and corner singularities smoothed out without loosing delicate definition in case of cubemaps??

Quite nicely. Not all hardware can filter texels across cube faces, but the artifacts from this are barely perceptible when faces match at the edges. Contrast this with the plainly visible spikes at the poles of planets with simple cylindrical textures.

Whether one can "perceive" the results of such smoothing/filtering is a tricky issue, depending on resolution etc. But there is definitely a considerable loss of information in the critical regions. That is for sure.
...

But, cube maps will handle the polar mapping problem better than reducing the resolution of VT tiles near the pole. VTs don't solve the problem as well, and only a minority of objects have VTs anyhow.

The circle in this image marks the South pole in my optimized 64k tile set. The mountaineous glacier range at the bottom is very close to the pole since this is really hires!



Could you please indicate whether you can see here any kind of 'pinch' problem? This display is just the result from my RGBA base+spec tiles obtained with my new txtools, together with my normalmap tiles from the nmtools. This would clearly be MUCH worse in case of a "one piece" cylindrical texture. "Pole-optimized" VT's really do a good job. I have studied this in great detail in the past.

It is no problem to convert many 8-16k moon + planet textures into tiles with my tools. Then there would be many more VT's without a polar 'pinch' problem
All required tools are available NOW.

Bye Fridger