Cube maps

[t00fri]

I still maintain that cube maps could be useful in Celestia . . .

Using cyber_space_doc's most recent code above, I did some further investigations of hires quality of cubemaps.

First I used a hires 8k x 4k lossless TIFF image of the BlueMarble Earth
http://earthobservatory.nasa.gov/Newsro ... _2002.html
and converted it into PPM.

Next I wrote a small script to convert earth8k.png into the 6 required 2k x 2k cubemap patches with correct orientations as required by the code. The 6 cubemap reprojections were performed with mmps(project) by Matthew Arcus
http://www.users.globalnet.co.uk/~arcus/mmps/mmps.html
as usual. The format conversions and rotations were done with ImageMagick's convert/mogrify utilities.

Code: Select all

#! /bin/sh
convert ../../earth8k.png ../../earth8k.ppm

project gnomonic -scale 2 -lat 0 -long  90 -w 2048 -h 2048 -grid -gridcolor 255:0:0 -f ../../earth8k.ppm > real_earth03.ppm
project gnomonic -scale 2 -lat 0 -long 270 -w 2048 -h 2048 -grid -gridcolor 255:0:0 -f ../../earth8k.ppm >real_earth02.ppm
project gnomonic -scale 2 -lat  90 -long 0 -w 2048 -h 2048 -grid -gridcolor 255:0:0 -f ../../earth8k.ppm >real_earth04.ppm
project gnomonic -scale 2 -lat -90 -long 0 -w 2048 -h 2048 -grid -gridcolor 255:0:0 -f ../../earth8k.ppm >real_earth05.ppm
project gnomonic -scale 2 -lat 0 -long   0 -w 2048 -h 2048 -grid -gridcolor 255:0:0 -f ../../earth8k.ppm >real_earth00.ppm
project gnomonic -scale 2 -lat 0 -long 180 -w 2048 -h 2048 -grid -gridcolor 255:0:0 -f ../../earth8k.ppm >real_earth01.ppm

mogrify -rotate 180  -format bmp real_earth00.ppm
mogrify -format bmp real_earth01.ppm
mogrify -rotate 90 -format bmp real_earth02.ppm
mogrify -rotate -90 -format bmp real_earth03.ppm
mogrify -format bmp real_earth04.ppm
mogrify -rotate 180 -format bmp real_earth05.ppm


Now, let's do a careful comparison:

Seen from a distance the resulting cubemap rendering from cyber_space_doc's code looks quite nice:



Note the purple square! It indicates one of the critical regions that I was pointing out all along. The point, where 3 cubemap faces are meeting!

Let's zoom into the purple square:

In the following, magnified image of cyber_space_doc's cubemap rendering of my 8k hires texture you can see the three lines with a discontinuouls rendering where three cubemap faces are meeting! It's where the red grid-line ends, towards the center of the image. What is most disturbing is that the surface patterns change direction abruptly across the discontinuity lines!


++++++++++++++++++++
No doubt, this is NOT nice and illustrates the kind of cubemap discontinuities I expected to appear all along. Definitely a serious loss of image quality/detail along extended regions of the texture rendering!
++++++++++++++++++++

For comparison, here is the analogous rendering of the original 8k simple cylindrical texture via Celestia in the same region. Everything perfect, of course.


In summary: I conclude that at the hires level, the price for getting rid of the two polar pinches with cubemaps is HIGH.

Bye Fridger

[t00fri]

For completelness, here is the appearance of the linear regime, along which 2 cubemap faces meet in case of a 16k x 8k cylindical texture. The reference texture is of very high quality. It is derived from the published binary Blue Marble Next Generation data of Earth using my new txtools.

Again cyber_space_doc's above cubemap rendering, mmps and ImageMagick were used.



++++++++++++++++++
Quite a damaging effect, since the discontinuities extend over LARGE texture regions! Note: it's precisely as I prediced it before I made these quantitative studies...
++++++++++++++++++
See e.g. other opinions/"predictions":

I think that you're overstating the effects of these filtering artifacts near the cube seams.

or

There aren't any discontinuities

Bye Fridger

[Cham]

Fridger's example is very convincing to me.

Very interesting study, Fridger, thanks !

[Fenerit]

Fridger, is this worst effect independent from the graphic hardware configuration, ea. antialiasing, anisotropic filter, etc.? It appear in all the system operations? There is a minimum resolution in which never occur, or it ever occur?

[ElChristou]

Fridger, curiosity, could you post a shot at the altitude where the cutting appear (I mean the point between visible/invisible)?

[t00fri]

Fridger, curiosity, could you post a shot at the altitude where the cutting appear (I mean the point between visible/invisible)?

That will depend on a number of ingredients. Like texture size, contrast & pattern type of texture (!), Monitor sharpness,...

Tonight, I'll make a shot with a configuration, where I just start seeing the discontinuities. But note I have to do (external) /screendumps/ which deteriorate substantially the image content...

Bye Fridger

[t00fri]

Fridger, curiosity, could you post a shot at the altitude where the cutting appear (I mean the point between visible/invisible)?

As I said aleady, the actual visibility of the seam where cubemap faces meet, depends on many settings and on hardware.

Yet, as promised here is a screendump for a generic, 8k x 4k texture using the cubemap rendering. The line of discontinuity is marked by the purple squares. You see that one does not have to go VERY close to the surface to make out this distortion region. Note, it's NOT just the line, it's the discontinuity in the texture patterns! Just magnify the image a bit and you will see it clearly.



Bye Fridger

[cyber_space_doc]

I've tried another approach to the cubemap render which involves a standard cubemap algorithm:-

Code: Select all

[size=7]
         Camera *camTemp = new Camera();
            camTemp->SetupCubemapProjectionMatrix();
                        
            D3DXMATRIX matIdent;
            D3DXMatrixIdentity(&matIdent);

            renderer->GetDevice()->SetTransform(D3DTS_WORLD, &matIdent );
            renderer->GetDevice()->SetTransform( D3DTS_PROJECTION, (D3DXMATRIX*)&camTemp->GetProjMatrix(  ) );
            renderer->GetDevice()->SetRenderState(D3DRS_CULLMODE, D3DCULL_NONE);
            renderer->SaveScreenRenderTarget();
            
            for( i = 0; i < 6; i++ )
            {
               renderer->SetRenderSurface(renderTargets[i]->GetRenderPixelSurface());

               renderer->Clear(CLEAR_BLACK);
               renderer->Begin();

               camTemp->GetCubeMapViewMatrix( i );
               renderer->GetDevice()->SetTransform( D3DTS_VIEW, (D3DXMATRIX*)&camTemp->GetViewMatrix( ) );
               renderer->GetDevice()->SetTexture( 0, renderer->GetTexture(spherical_texture)->GetTexture());//
               m_pMesh->DrawSubset(0);
               
               renderer->End();
               renderer->Flip();

               char name[] = "myBitmap";
               char filename[256];
               sprintf( filename, "Resources/%s%d.png", name, i );
               WCHAR Wfilename[256];
               OutputMessage::ToWchar( filename, Wfilename );

               D3DXSaveTextureToFile( Wfilename, D3DXIFF_PNG, renderTargets[i]->GetRenderedImage(),0);
            }
            renderer->ResetScreenRenderTarget();

            delete camTemp;
[/size]


I decided to use D3D for the code because I already have cubemaps working in d3d and because I noticed that the I could not disable the GL texture filter (perhaps in GLSL?) and I could easily render in D3D without filtering.
When the cubemap textures are rendered without filtering the sampler will tend to blur the pixels with their neighbours causing a problem at the seams, since the adjacent textures would have to be sampled in order to maintain the appearance of continuity at the border pixels.

I used an 8k * 4k blue marble texture and generated 3 sets of textures, of dimensions 512, 1024 and finally 2048.
The first two sets of textures where unsatisfactory, but the third set show that if the cubemap is upsampled properly and displayed without filtering then it is continuous.


and here is a wireframe of the same picture

and here is an image of the middle east (inverted)

and here is a wireframe of the same picture

and another picture of a desert area...

and here is a wireframe of the same picture


and a wireframe from space:-


Obviously the textures look continuous at very high resolution. If a cubemap is created from a cylindrical texture with this method then it will probably look worse than the spherical texture since it still has the pinching problem at the poles, however a noise map or procedurally generated texture can eliminate problems at the poles and maintain apparent continuity at the seams.

I can only see a benefit in using a cubemap if it is an artificially generated texture.

[Kolano]

Obviously the textures look continuous at very high resolution. If a cubemap is created from a cylindrical texture with this method then it will probably look worse than the spherical texture since it still has the pinching problem at the poles, however a noise map or procedurally generated texture can eliminate problems at the poles and maintain apparent continuity at the seams.

I can only see a benefit in using a cubemap if it is an artificially generated texture.

Sorry cyber_space_doc but...

-Given the upper range of 64x32k (and up) textures used by Celestia, a 8x4k image isn't "very high resolution" it's only middling. Generally, one of my concerns with cubemaps is that they seem to barely keep up with recent higher resolution images of many objects. I understand that we have much lower res images for most known objects, but having the multiple render paths to deal with seems to add needless complexity (i.e. since cube maps can't replace the current render paths).

-Though they are harder to detect, I can still see the irregularities similar to what Fridger was mentioning in your unfiltered images.

-Though the current render path does have some pinching problems at the poles, that's only 2 points. Though I haven't investigated, I believe the cubemap irregularitires occur at 8 seperate locations.

[cyber_space_doc]

Sorry cyber_space_doc but...

nothing to be sorry about,

-Given the upper range of 64x32k (and up) textures used by Celestia, a 8x4k image isn't "very high resolution" it's only middling.

sure thats true - but I am convinced that the higher you go with any projection the better.

seem to barely keep up with recent higher resolution images of many objects.

cubemaps where used by top graphics researchers to encapsulate environments for decades.

-Though they are harder to detect, I can still see the irregularities similar to what Fridger was mentioning in your unfiltered images.

where exactly? Those are very zoomed images.

-Though the current render path does have some pinching problems at the poles, that's only 2 points. Though I haven't investigated, I believe the cubemap irregularitires occur at 8 seperate locations.

yes but cubemaps form a cleaner surface area to pixel ratio.

[cyber_space_doc]

Quote:
seem to barely keep up with recent higher resolution images of many objects.



cubemaps where used by top graphics researchers to encapsulate environments for decades.

ok that was a bad answer since it looks like I am trying to convince you of the technology when you are trying to explain that scientists do not make cubemaps from their planetary surface data sets.

I am just agreeing with or voting for the concept of having an option to use cubemaps on objects in celestia since I am sure that synthesized data sets map well into a cubemap form. The use of cubemaps and synthesized data would probably be better left to the objects that science has little or no accurate knowledge of.

[cyber_space_doc]

I noticed another bug in the code I posted for generating cubemaps from perlin noise. I apologise to anybody who bothered to actually generate huge textures only to notice some slight discontinuities. The problem is very simple. The cubemap sampler needs to be adjusted by 0.5 pixels in both x and y, in the same way that post-processing special effects use a texel alignment.

Code: Select all

V = x - double( m_destWidth / 2 );
U = y - double( m_destWidth / 2 );
W =  double( m_destWidth / 2 );


becomes:

Code: Select all

V = double( x - m_destWidth / 2 + 0.5 );
V = double( y - m_destWidth / 2 + 0.5 );
W =  double( m_destWidth / 2 );


and these need to be rendererd in d3d at the moment for full appreciation since the OpenGL filter breaks at the seams *unless* the textures have been combined into a hardware cubemap, since a hardware cubemap will not have filtering problems. A fix for OpenGL textures larger than the maximum size that will fit into a cubemap is under progress.

[MKruer]

Knowing nothing about anything, I have an idea, but I am not sure how feasible it would be. Instead of using a simple box for the sphere mapping, how difficult would it be to use a geodesic spherical mapping? The idea comes from dymaxion projection, but instead of leaving holes, distorted the image
to fill the entire map. I guess you can call this a geodesic cube map. If I am right, the constant bend in the grid, will batter mask and join lines.

http://en.wikipedia.org/wiki/Dymaxion_projection

[cartrite]

What ever happened to this idea? I see that there are limitations but also some benefits. Like the polar regions. I foresee some new data from polar regions of Mars and the Moon being available soon both in rgb textures and 16 bit heightmaps. Could a cube map be generated for those regions from a polar stereographic projection. If so, this would preserve the data in those regions instead of trying to convert these simple cylindrical maps.

I would think one could also use 6 simple cylindrical maps, each centered on the area used by each cube map. For example, for the north pole, create a simple cylindrical map the is centered on 90n latitude 0 longitude, so the stretching would occur at the equator, and then convert that map to a cube map for use on the cube meshes north face.
cartrite

[chris]

What ever happened to this idea? I see that there are limitations but also some benefits. Like the polar regions. I foresee some new data from polar regions of Mars and the Moon being available soon both in rgb textures and 16 bit heightmaps. Could a cube map be generated for those regions from a polar stereographic projection. If so, this would preserve the data in those regions instead of trying to convert these simple cylindrical maps.

It's an interesting idea that no one has had the time to continue pursuing... There was some (valid) concern about seams between the cube map faces. One has to be very careful when generating the cube map faces in order to minimize the discontinuities. In addition, not all GPUS filter across cube map faces, causing artifacts similar to the seams between virtual texture tiles. There's a new OpenGL extension to enable filtering across cube map faces, but it's not widely supported yet.

I would think one could also use 6 simple cylindrical maps, each centered on the area used by each cube map. For example, for the north pole, create a simple cylindrical map the is centered on 90n latitude 0 longitude, so the stretching would occur at the equator, and then convert that map to a cube map for use on the cube meshes north face.

To generate images for the faces of a cube map, you want to use gnomonic projections, not simple cylindrical.

--Chris

[selden]

To generate images for the faces of a cube map, you want to use gnomonic projections, not simple cylindrical.

http://www.lepp.cornell.edu/~seb/celest ... html#2.1.2
shows the commands for using MMPS to generate cubic maps from a simple cylindrical map.

[cartrite]

Looking at that link leads me to believe that MMPS would probably produce a better map from a polarstereographic projection at the poles. ISIS3 will happily produce this projection for the poles. It would be better to use raw camera images for this. Modis sends these to earth daily.
But.....

It seems likely that Celestia may someday support Cubic Maps in additional to simple cylindrical. They're directly supported in the graphics hardware and avoid some of the problems seen with simple cylindrical projections, although they introduce some of their own.

It is not supported now, right?
cartrite

[selden]

Looking at that link leads me to believe that MMPS would probably produce a better map from a polarstereographic projection at the poles. ISIS3 will happily produce this projection for the poles. It would be better to use raw camera images for this. Modis sends these to earth daily.
But.....

It seems likely that Celestia may someday support Cubic Maps in additional to simple cylindrical. They're directly supported in the graphics hardware and avoid some of the problems seen with simple cylindrical projections, although they introduce some of their own.

It is not supported now, right?
cartrite

Right. It is not. "Likely" now seems overly optimistic, I think, considering the edge and corner issues. At least simple cylindrical has only two poles and one edge to cause problems!

[FSword7]

ok, the code has changed now ...

http://www.kai-soft.co.uk/GLUT_mmps_planet.tar.gz

this time the program has zoom functionality on the right button, and rotation with either the mouse or the IJKL keys. The 'space' key stops the rotation.

I have created a cubemap texture set using MMPS to demonstrate the cubemap, unfortunately I could not find a .png file larger than 'Don's Realistic Earth' on the motherload for the first test.

I think the slight problems can be corrected if an appropriate cubemap size is used - I used a size of 512 with dons 4k png.

A good way to check the errors visually is to convert a cylindrical projection generated in libnoise and compare it to the corresponding cubemap. I'll be able to post up some results of such tests soon, including a high res planet texture.

I discovered that topic today and tried to download demo. It does not exist anymore. That topic was 10 years old. Does anyone still have a copy?

Space Engine is doing VT cubemaps.

Thanks,
Tim

[John Van Vliet]

10 year nekro post

the perl tools in cpan for huggin
"erect2cubic"
http://search.cpan.org/dist/Panotools-Script/

outputs 6 images correctly mapped
you just need to join them in the cross pattern or uv map them for a mesh

( and yes there is a N and a S on the poles )

and the reverse "cubic2erect" takes 6 cube images and makes a simple cylindrical image