Cube maps

Discussion forum for Celestia developers; topics may only be started by members of the developers group, but anyone can post replies.
Avatar
t00fri
Posts: 8814
Joined: 29.03.2002
Age: 16
With us: 16 years 5 months
Location: Hamburg, Germany

Post #61by t00fri » 10.07.2007, 19:39

Chris wrote: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:

Image

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!
Image

++++++++++++++++++++
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.
Image

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
Last edited by t00fri on 11.07.2007, 07:02, edited 1 time in total.
Image

Avatar
t00fri
Posts: 8814
Joined: 29.03.2002
Age: 16
With us: 16 years 5 months
Location: Hamburg, Germany

Post #62by t00fri » 10.07.2007, 22:15

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.

Image

++++++++++++++++++
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":

Chris wrote:I think that you're overstating the effects of these filtering artifacts near the cube seams.
or
cyber_space_doc wrote:There aren't any discontinuities




Bye Fridger
Image

Avatar
Cham M
Posts: 4335
Joined: 14.01.2004
Age: 54
With us: 14 years 8 months
Location: Montreal

Post #63by Cham » 10.07.2007, 22:29

Fridger's example is very convincing to me.

Very interesting study, Fridger, thanks !
"Well! I've often seen a cat without a grin", thought Alice; "but a grin without a cat! It's the most curious thing I ever saw in all my life!"

Avatar
Fenerit M
Posts: 1877
Joined: 26.03.2007
Age: 11
With us: 11 years 5 months
Location: Thyrrenian sea

Post #64by Fenerit » 11.07.2007, 14:00

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?
Never at rest.
Massimo

ElChristou
Posts: 3808
Joined: 04.02.2005
With us: 13 years 7 months

Post #65by ElChristou » 11.07.2007, 14:20

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

Avatar
t00fri
Posts: 8814
Joined: 29.03.2002
Age: 16
With us: 16 years 5 months
Location: Hamburg, Germany

Post #66by t00fri » 11.07.2007, 16:08

ElChristou wrote: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
Image

Avatar
t00fri
Posts: 8814
Joined: 29.03.2002
Age: 16
With us: 16 years 5 months
Location: Hamburg, Germany

Post #67by t00fri » 11.07.2007, 18:56

ElChristou wrote: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.

Image

Bye Fridger
Image

cyber_space_doc
Posts: 53
Joined: 19.03.2007
With us: 11 years 6 months
Location: united kingdom

Post #68by cyber_space_doc » 12.07.2007, 02:10

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.

Image
and here is a wireframe of the same picture
Image
and here is an image of the middle east (inverted)
Image
and here is a wireframe of the same picture
Image
and another picture of a desert area...
Image
and here is a wireframe of the same picture
Image

and a wireframe from space:-
Image

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.
System: AMD 3200+
512Mb RAM
GeForce 7300 FX 256 mb VRAM
Windows XP Home Edition
Nforce4 Motherboard
Service Pack 2
_____________________

Kolano
Posts: 125
Joined: 15.02.2005
With us: 13 years 7 months
Location: New Jersey

Post #69by Kolano » 12.07.2007, 03:59

cyber_space_doc wrote: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.
System:
Asus A8N-SLI Premium nForce4 SLI
AMD Athlon 64 X2 4200+
2xeVGA GeForce 7800 GTX 256MB
2gb Dual Channel DDR (400) 3200

cyber_space_doc
Posts: 53
Joined: 19.03.2007
With us: 11 years 6 months
Location: united kingdom

Post #70by cyber_space_doc » 12.07.2007, 05:09

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.
System: AMD 3200+

512Mb RAM

GeForce 7300 FX 256 mb VRAM

Windows XP Home Edition

Nforce4 Motherboard

Service Pack 2

_____________________

cyber_space_doc
Posts: 53
Joined: 19.03.2007
With us: 11 years 6 months
Location: united kingdom

Post #71by cyber_space_doc » 12.07.2007, 22:52

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.
System: AMD 3200+

512Mb RAM

GeForce 7300 FX 256 mb VRAM

Windows XP Home Edition

Nforce4 Motherboard

Service Pack 2

_____________________

cyber_space_doc
Posts: 53
Joined: 19.03.2007
With us: 11 years 6 months
Location: united kingdom

Post #72by cyber_space_doc » 17.07.2007, 22:50

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.
System: AMD 3200+

512Mb RAM

GeForce 7300 FX 256 mb VRAM

Windows XP Home Edition

Nforce4 Motherboard

Service Pack 2

_____________________

MKruer
Posts: 502
Joined: 18.09.2002
With us: 16 years

Post #73by MKruer » 06.08.2007, 02:47

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
Posts: 1706
Joined: 15.09.2005
With us: 13 years
Location: Pocono Mountains, Pennsylvania, USA

Re: Cube maps

Post #74by cartrite » 24.09.2009, 13:14

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
Windows 7 Home Premium 64, Toshiba Satellite P875=S7200 laptop, Intel i5 processor 2.5 ghz 6 gb ram, Graphics Intel(R) HD Graphics 4000 Driver ver 8.15.10.2752

Topic author
chris
Site Admin
Posts: 4218
Joined: 28.01.2002
With us: 16 years 7 months
Location: Seattle, Washington, USA

Re: Cube maps

Post #75by chris » 25.09.2009, 17:36

cartrite wrote: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

Avatar
selden
Posts: 10238
Joined: 04.09.2002
With us: 16 years
Location: NY, USA

Re: Cube maps

Post #76by selden » 26.09.2009, 11:20

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.
Selden

cartrite
Posts: 1706
Joined: 15.09.2005
With us: 13 years
Location: Pocono Mountains, Pennsylvania, USA

Re: Cube maps

Post #77by cartrite » 26.09.2009, 12:08

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
Windows 7 Home Premium 64, Toshiba Satellite P875=S7200 laptop, Intel i5 processor 2.5 ghz 6 gb ram, Graphics Intel(R) HD Graphics 4000 Driver ver 8.15.10.2752

Avatar
selden
Posts: 10238
Joined: 04.09.2002
With us: 16 years
Location: NY, USA

Re: Cube maps

Post #78by selden » 26.09.2009, 12:31

cartrite wrote: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!
Selden

FSword7
Posts: 12
Joined: 08.09.2017
With us: 1 year

Post #79by FSword7 » 09.10.2017, 00:14

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

Avatar
John Van Vliet
Posts: 2710
Joined: 28.08.2002
With us: 16 years

Post #80by John Van Vliet » 09.10.2017, 01:32

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

cube.png

( 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

lines10.png


Return to “Ideas & News”

Who is online

Users browsing this forum: 1 guest