Cube maps

[neo albireo]

It will certainly last longer before you might have a chance of using high-quality 8k-16k /one-piece/ cube map textures with Celestia... Not even cubemap support is yet available in Celestia, let alone high-quality cubemap textures (including spherical geometry normalmaps!) .

Either way, patience is required.

Well, I'll first use whatever comes first - if it can release me from my current texture loading pains

[t00fri]

It will certainly last longer before you might have a chance of using high-quality 8k-16k /one-piece/ cube map textures with Celestia... Not even cubemap support is yet available in Celestia, let alone high-quality cubemap textures (including spherical geometry normalmaps!) .

Either way, patience is required.

Well, I'll first use whatever comes first - if it can release me from my current texture loading pains

Of course...In any case, it seems your machine is not really "high-end". So the loading of FOUR 16k /one-piece/ cubemaps will also be a pain!


How about reflecting about a faster harddisk?

Bye Fridger

[neo albireo]

How about reflecting about a faster harddisk?

I would prefer to first wait for some software improvements.. so far the development of Celestia in the last weeks was very promising compared to some long waiting times before. Now I hope that you'll find your free time to prepare some nice packages for us end-users to produce smart textures. And of course I'm hoping for Chris having more Celestia dedicated time as well, not to mention all other contributors.

[cyber_space_doc]

I had a bit of a think about the mathematics and it has become apparent that the spherical texture tiles approximate a square at a small enough anglular variation: eg the points given by the spherical angles u and v with an increment du and dv

(u, v),
(u + du, v),
(u, v + dv),
(u + du, v+dv)

will approximate a right-angled rectangle as du and dv become small enough. I have not bothered with the precise mathematics to prove the error or to show how large the error is on an earth sized planet. The size of an approximate quad will obviously become smaller as the longitude reaches the north or south pole, eventually becoming a trianglular shape at the pole.

The quads on the cubemap seem to mostly approximate diamonds or parallograms as they become smaller and smaller. This is unfortunate for heightmapping.

http://www.vterrain.org/Textures/spherical.html

I think that overall the cubemap provides a good solution to the problem of texture warping at the poles when viewed from a distance from which the texels too small to see. The pinching effect on the cubemap never reaches a triangle and the texture sampler would not need to look up more than one texel for a point, whilst the texture sampler on the spheical map has to sample an entire line of image pixels to apply a texel on the north or south poles. The problem with rendering each cube face seperately is that a blinear or trilinear filter causes texture wrapping (this might be a problem with my graphics card), however this could be fixed by making the texture 2 pixels larger and incrementing the texture coordinates by one texel. The texture should be an extra pixel in size anyway, since the sampled point would be in the wrong place.

Cubemaps could also be used to render the cloud maps from space, which can also look very pinched at the poles. I would prefer a flexible texturing system where the users can specify a mapping method as an option in the ssc file.

[danielj]

So THIS explain the white screens and the strange behavior,when zooming and rotating.My computer is TRASHING.So how can I prevent this?
Actually following the link,it mean that 1 GB IS NOT ENOUGH FOR CELESTIA.At least for BMNG+64K Normal Maps like textures.

"Increase the amount of RAM in the computer (generally the best long-term solution). "

This is the best solution,but it is IMPOSSIBLE at the moment...

ok, I suppose I'll take that as a firm *no*.

my atttude is that:-

"if it ain't broke, don't fix it"

however I can honestly say that I can hardly stand seeing the planet surfaces in Celestia if they are all going to be pinched and warped at the poles...

The Virtual textures do not run on my machine - the system will start to *thrash* the textures.
see:

http://en.wikipedia.org/wiki/Thrash_(computer_science)

This means that the system has to swap massive textures between the graphics memory and the RAM. The thrashing is caused by normal movements in Celestia, such as rotating and zooming.

worth it

was it worth it for me? Yes. I enjoyed writing the software. I would find it very easy to incorporate it into Celestia since I have proffesional experience with large programs. Anyone following my posts would probably think of me as *unqualified* if I did not say that.

btw:-

I think its a shame that no-one can be bothered to even comment on my program ... what is the problem with supporting multiple projection modes? I expect the cubemap format solves the age old question about *how could a sattelite capture a planet texture quickly?*. It is obvious that NVidia, ATI and Microsoft would not have used cubemaps to represent skydomes, reflections and shadows in all their best demonstration programs unless cubemaps looked better - they would have used the cylindrical projection instead.

[t00fri]

cyber_space_doc,

...
I think its a shame that no-one can be bothered to even comment on my program ...

as before it builds with vc8 and Direct3d on windows only. The new version is set to load textures instead of generate them. I have hosted large 2048 sized textures at:-

I would find it very easy to incorporate it into Celestia since I have proffesional experience with large programs.

Then I really don't understand, why you wrote your program for Direct3d and Windows rather than for OpenGL and CrossPlatform!? Some of us then could have directly used your code for doing further experiments in Celestia...That's what matters, after all.


Also 2k x 1k textures are so low in resolution that it is impossible to examine any concerns as to hi-quality losses in filtered overlap regions from the cube maps! The issue I am concerned with requires 16k cubemaps or at least 8k. Your previous example image was of pretty low quality altogether and not even spherical...

Most of the devs are aware how cube maps work in principle.

The crucial issue is rather whether they are good enough at hires >=8k and how to generate high-quality cubemaps for Celestia from the published raw data.

Up to now, nobody has produced any convincing argument how it can be avoided to loose valuable image content after mapping scientific cylindrical raw data first into cube maps and then back onto spherical objects in Celestia! In game programming this is of no concern whatsoever as long as these border regions between the cube faces are filtered sufficiently.

But filtering also means information loss...no doubt. And in Celestia we want to display textures with optimal information content!


Bye Fridger

[cyber_space_doc]

cyber_space_doc,

...
I think its a shame that no-one can be bothered to even comment on my program ...

as before it builds with vc8 and Direct3d on windows only. The new version is set to load textures instead of generate them. I have hosted large 2048 sized textures at:-

I would find it very easy to incorporate it into Celestia since I have proffesional experience with large programs.

Then I really don't understand, why you wrote your program for Direct3d and Windows rather than for OpenGL and CrossPlatform!? Some of us then could have directly used your code for doing further experiments in Celestia...That's what matters, after all.

I did my best to use generic code when a class would be useful in a different program. The Heightpatch class can be moved into OpenGL without too much trouble, and the noise generation routines are cross platform too.

Also 2k x 1k textures are so low in resolution that it is impossible to examine any concerns as to hi-quality losses in filtered overlap regions from the cube maps! The issue I am concerned with requires 16k cubemaps or at least 8k. Your previous example image was of pretty low quality altogether and not even spherical...

Most of the devs are aware how cube maps work in principle.

The crucial issue is rather whether they are good enough at hires >=8k and how to generate high-quality cubemaps for Celestia from the published raw data.

I have not had time to generate an 8k*8k texture for each cube face, although I have taken the time to generate 4k*4k maps, which took all day incidently. The maps can also be doubled in size using an appropriate program such as Adobe Photoshop CS2. I will be able to host them within the next couple of days.

Up to now, nobody has produced any convincing argument how it can be avoided to loose valuable image content after mapping scientific cylindrical raw data first into cube maps and then back onto spherical objects in Celestia! In game programming this is of no concern whatsoever as long as these border regions between the cube faces are filtered sufficiently.

There would not be any need for a conversion because the original texture functions used by libnoise will generate a spherical map anyway.
The program will curently crash if attempting to generate a planetary spherical map because the textures will not load up afterwards, however I expect it will generate the texture.
As both forms of texture can be saved I suppose it would be interesting to see the difference between a texture that is generated as a spherical map and a texture that was converted from a cubemap, and visa versa.

But filtering also means information loss...no doubt. And in Celestia we want to display textures with optimal information content!


Bye Fridger

I meant that the standard trilinear filters used in the graphics pipeline for all textures including the spherical ones caused a problem at the seams on my 6 seperate textured patches.

The problem was due to the fact that the Graphics card's bilinear filter sampler will search to the other side of a texture at the edges in order to get a filter kernel of 9 pixels. The filtering is currently used for VT's as well as all of the ordinary textures and only serves to smooth the textures a bit to make them look less grainy. The trilinear filter is the same as a bilinear filter with a Mipmap filter added.

[t00fri]

I did my best to use generic code when a class would be useful in a different program. The Heightpatch class can be moved into OpenGL without too much trouble, and the noise generation routines are cross platform too.

But then, why didn't you do it right for use in Celestia from the start?

...
There would not be any need for a conversion because the original texture functions used by libnoise will generate a spherical map anyway.
...

Sorry, I am not really interested in how your little demo program does things in that particular example.

+++++++++++++++++++++++
The Celestia distribution is exclusively based on published scientific texture data.
+++++++++++++++++++++++

There is no doubt that scientific-grade texture displays in Celestia will need such conversions, since scientific textures ar generally NOT published as cubemaps! Mostly, they are published as simple cylindrical projections. Sometimes with some separate polar cap views...But certainly not as cube maps! Or they are published as real photographs, requiring complex reprojections with suitable software.

Here is where my criticism starts. All the rest is rather trivial to me, since I know the mapping mathematics for cubemaps very well.

That's the starting point we have to face in REALITY. We need excellent cross-platform software algorithms to convert these data (including elevation data) into the respective cubemaps.

These then will have to be mapped and filtered within Celestia's core onto spherical bodies. Then for hires textures as big as 8k - 16k I will carefully examine the areas on the spheres where according to my calculations the overlapping boundaries of the 6 cubemap faces are mapped!

You guys want to tell me that in these critical regions, where heavy filtering took place, there will be NO visible loss of image information? Sorry, I just do not believe it until proven wrong. . Show me a 16k rendering based on a cubemap that was generated from a simple cylindical map and I will spot the regions where information got lost.


Bye Fridger

[chris]

I did my best to use generic code when a class would be useful in a different program. The Heightpatch class can be moved into OpenGL without too much trouble, and the noise generation routines are cross platform too.

But then, why didn't you do it right for use in Celestia from the start?

...
There would not be any need for a conversion because the original texture functions used by libnoise will generate a spherical map anyway.
...

Sorry, I am not really interested in how your little demo program does things in that particular example.

+++++++++++++++++++++++
The Celestia distribution is exclusively based on published scientific texture data.
+++++++++++++++++++++++

There is no doubt that scientific-grade texture displays in Celestia will need such conversions, since scientific textures ar generally NOT published as cubemaps! Mostly, they are published as simple cylindrical projections. Sometimes with some separate polar cap views...But certainly not as cube maps! Or they are published as real photographs, requiring complex reprojections with suitable software.

Here is where my criticism starts. All the rest is rather trivial to me, since I know the mapping mathematics for cubemaps very well.

That's the starting point we have to face in REALITY. We need excellent cross-platform software algorithms to convert these data (including elevation data) into the respective cubemaps.

These then will have to be mapped and filtered within Celestia's core onto spherical bodies. Then for hires textures as big as 8k - 16k I will carefully examine the areas on the spheres where according to my calculations the overlapping boundaries of the 6 cubemap faces are mapped!

You guys want to tell me that in these critical regions, where heavy filtering took place, there will be NO visible loss of image information? Sorry, I just do not believe it until proven wrong. . Show me a 16k rendering based on a cubemap that was generated from a simple cylindical map and I will spot the regions where information got lost.


Bye Fridger

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

First of all, there's neither the need nor the available data to to create a 16k or larger map for every body in the solar system. Cube maps solve the polar pinch problem for smaller maps; VTs make the polar pinch problem less noticeable with larger maps, but cube maps still have the advantage here (up until you reach the maximum hardware texture size.)

I think that you're overstating the effects of these filtering artifacts near the cube seams. There's a large amount of filtering that occurs in the creating of simple cylindrical projection as well. Introducing another projection step--conversion from simple cylindrical to cube maps--isn't as desirable as directly building a cube map from original image data, but the effects aren't as grave as you keep suggesting. Of course, the proof is in an actual implementation, which I don't have time for right now. But, others should be encouraged to do so: cyber_space_doc, I'd very much like to see a version of your demo that uses a high resolution cube map derived from a simple cylindrical map of a solar system body (such as one of Steve Albers's maps: http://laps.noaa.gov/albers/sos/sos.html) Such a demonstration could be useful even if it's written for Windows using Direct3D.

Fridger, I'm not sure what you mean by 'heavy filtering' in the areas near the cube map edges. The amount of scaling in these areas is never extreme like it is for the polar regions of a simple cylindrical projection.

--Chris

[t00fri]

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

First of all, there's neither the need nor the available data to to create a 16k or larger map for every body in the solar system.

16k I am mainly requesting to be able to critically examine the resulting textures. On the other hand in such a discussion it is a joke to discuss /tiny/ demo images of 2k x 1k size, generated with a computer that has 512k of Ram. That is just bypassing what I am talking about.

Cube maps solve the polar pinch problem for smaller maps; VTs make the polar pinch problem less noticeable with larger maps, but cube maps still have the advantage here (up until you reach the maximum hardware texture size.)

Sorry, my VT's of low level (that are relevant at larger distance from the object) also make the pinch effects virtually invisible for SMALL maps! Should I show respective images?

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

Chris, you are persistently avoiding to discuss how you imagine the process of generating actual hi-quality cube-map textures from the typical scientific imaging we got. And how the imaging errors will behave in such a contrived processing chain...

Let me know how you imagine this to work in practice? You are not denying that scientific texture data are mostly available in form of simple cylindrical maps (admittedly in some rare cases with some separate polar cap imaging in parallel) ? How do your math formulae look like that got to convert these to cubemaps and then in Celestia onto spheres?

Of course, the meeting cube map faces only give rise to /finite/ discontinuities, while the polar region in cylindrical maps involves an infinity. Yet, across the final sphere, the mapped areas from these finite cubemap discontinuidies are extended over comparably large domains.

I admit that these regions will be perfectly smooth after filtering, but I still claim that significant image information will have been lost there due to the required smoothing algorithms. That's what is most relevant in my view!
The result may well LOOK better graphically, but it may nevertheless contain less image detail than the corresponding cylindrical maps (away from the poles).

Introducing another projection step--conversion from simple cylindrical to cube maps--isn't as desirable as directly building a cube map from original image data, but the effects aren't as grave as you keep suggesting.

What kind of "original image data" do you have in mind? BMNG for example is only published as simple cylindrical textures, as far as I am aware. I am confused what you are referring to.

Of course, the proof is in an actual implementation,

Absolutely.

But I wonder where computers with 512 MB of RAM can get us in this respect.... ?

Of course, for me it would cost much less time to just shut up and wait until you or someone else comes forward with a usable test for cubemaps. Yet I am writing here, to hopefully contribute that we do not once more disperse on another "half baked" venture in view of the many much more urgent pending issues...

Fridger, I'm not sure what you mean by 'heavy filtering' in the areas near the cube map edges. The amount of scaling in these areas is never extreme like it is for the polar regions of a simple cylindrical projection.

--Chris

To repeat myself: we talk about finite discontinuities to be mapped onto spheres. These need to be taken care of in form of filtering/smoothing, which necessarily will lead to more or less subtle losses of image information over extended regions on the spherical bodies. You are not denying this, do you?

Bye Fridger

[cyber_space_doc]

To repeat myself: we talk about finite discontinuities to be mapped onto spheres. These need to be taken care of in form of filtering/smoothing, which necessarily will lead to more or less subtle losses of image information over extended regions on the spherical bodies. You are not denying this, do you?

There aren't any discontinuities - the filtering problem was in fact caused by the use of the wrong sampler address mode. The sampler address mode was set to WRAP rather than CLAMP as a default. The use of 2 extra pixels is therefore not correct. It is only neccessary to add 1 extra pixel if you intend on setting the heights of the mesh grid points from the texture, however this would not be correct if the cubemap was only viewed from space.

Using the default values should generate a seamless cubemap.

To use trilinear filtering on the graphics card just paste this HLSL file into the resources folder as a replacement of the old one. (EDIT: this is for the program posted in a former post).

16k I am mainly requesting to be able to critically examine the resulting textures. On the other hand in such a discussion it is a joke to discuss /tiny/ demo images of 2k x 1k size, generated with a computer that has 512k of Ram. That is just bypassing what I am talking about.

Textures 4k in size will not run on my computer - I am not sure if they can be transformed into a cubemap.

cyber_space_doc, I'd very much like to see a version of your demo that uses a high resolution cube map derived from a simple cylindrical map of a solar system body (such as one of Steve Albers's maps: http://laps.noaa.gov/albers/sos/sos.html) Such a demonstration could be useful even if it's written for Windows using Direct3D.

I've thought about a cross platform version of the code with support for interactive mapping format conversion using MMPS. I expect I'll have time to work on it this week.

[cyber_space_doc]

I finally got some work done on the cross platform version of the code I posted earlier. The code has been tested in mingw, and compiled but not tested on linux since my nvidia graphics drivers don't work. I have not added MMPS since this is still in early stages.

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

and there is a windows exe

http://www.kai-soft.co.uk/glut-cpp2.exe

I was thinking that perhaps I should add a feature request for a plugin architecture for celestia, or at least the ability to set up precompiled display lists in lua. I was thinking that a dll plugin would be a good feature because it would allow programmers to use C or C++ for their addons.

compilation
--------------
To compile on windows you need to first build libnoise.a (not lib) by calling

./configure
make libnoise.a

then changing directory to the program root and simply typing make.

The linux build routine is similar, however the libnoise code is compiled in its src directory, and the commands for building the main program are:-

make dll_linux
make glut-cpp-linux

I'll probably update the code in a couple of days when I have transferred it back to windows. ( I am on a mac at the moment ).


credits (haven't made a readme)
--------
The code contains some slightly modified celestia code, a Glut program based on source downloaded from the web and the opengl2 brick shader, a cross platform library, a copy of libnoise and also an implementation of dlfcn.h and dlfcn.cpp that will work on windows.

bye

[cyber_space_doc]

I just noticed a bug on windows with the program posted above, here is the version that works on windows under mingw:-

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

[t00fri]

Your code compiles under Linux, but running it gives a SEGFAULT.

The libs are all found here is the record:

Code: Select all

        linux-gate.so.1 =>  (0xffffe000)
        libGL.so.1 => /usr/lib/libGL.so.1 (0xb7f06000)
        libGLEW.so.1.3 => /usr/local/lib/libGLEW.so.1.3 (0xb7ed4000)
        libglut.so.3 => /usr/lib/libglut.so.3 (0xb7ea0000)
        libGLU.so.1 => /usr/lib/libGLU.so.1 (0xb7e2a000)
        libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0xb7d49000)
        libm.so.6 => /lib/libm.so.6 (0xb7d24000)
        libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xb7d19000)
        libc.so.6 => /lib/libc.so.6 (0xb7bf9000)
        libdl.so.2 => /lib/libdl.so.2 (0xb7bf5000)
        libGLcore.so.1 => /usr/lib/libGLcore.so.1 (0xb7283000)
        libnvidia-tls.so.1 => /usr/lib/tls/libnvidia-tls.so.1 (0xb7280000)
        libXext.so.6 => /usr/X11R6/lib/libXext.so.6 (0xb7272000)
        libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0xb717b000)
        libXmu.so.6 => /usr/X11R6/lib/libXmu.so.6 (0xb7166000)
        libXi.so.6 => /usr/X11R6/lib/libXi.so.6 (0xb715e000)
        libXxf86vm.so.1 => /usr/X11R6/lib/libXxf86vm.so.1 (0xb7158000)
        /lib/ld-linux.so.2 (0xb7fd3000)
        libXt.so.6 => /usr/X11R6/lib/libXt.so.6 (0xb7108000)
        libSM.so.6 => /usr/X11R6/lib/libSM.so.6 (0xb70ff000)
        libICE.so.6 => /usr/X11R6/lib/libICE.so.6 (0xb70e7000)


Sorry, no time for hunting the bug.

Bye Fridger

[cyber_space_doc]

ok fixed the bug and tested on linux. The new code is available at

http://www.kai-software.co.uk/glut_mingw_new.tar.gz

the problem was to do with the text format of the pathnames.

I can't get the dynamic libraries to work on the mac, however there is a lot of information on libraries for the mac.

[t00fri]

ok fixed the bug and tested on linux. The new code is available at

http://www.kai-software.co.uk/glut_mingw_new.tar.gz

the problem was to do with the text format of the pathnames.

I can't get the dynamic libraries to work on the mac, however there is a lot of information on libraries for the mac.

Sorry, I cannot download this file. Typo?

Bye Fridger

[cyber_space_doc]

cyber_space_doc wrote:
ok fixed the bug and tested on linux. The new code is available at

http://www.kai-software.co.uk/glut_mingw_new.tar.gz

the problem was to do with the text format of the pathnames.

I can't get the dynamic libraries to work on the mac, however there is a lot of information on libraries for the mac.


Sorry, I cannot download this file. Typo?

Bye Fridger

correction:-

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

[t00fri]

Sorry, I cannot download this file. Typo?

Bye Fridger

correction:-

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

How about trying things out once first ?

Bye Fridger

[t00fri]

Now your code works fine under Linux. Thanks.

Yet I don't know really what I should test with this lores example? We know already that cubemaps don't produce polar pinches.

I have seen many lores examples for cubemap renderings of that kind. But we need to examine HIRES textures. We should start from a 8k x 4k simple cylindrical projection, say, convert it into a cubemap and then render it on a sphere. This rendering has to be critically compared with the direct rendering of the cylindrical texture, notably in the regions that correspond to the touching boundaries of neighboring cubemap textures. The comparison has to be done at HIGH magnification in order to examine whether information was lost in these discontinuous regimes by means of filtering.

Clearly the polar pinches will be better with the cube maps (at least for non-VT's). But there may be a price to pay as I suspect...

Unfortunately we will mostly have to derive the cubemap textures from simple cylindrical ones since cubemaps will not be used by scientists in their publications.

Bye Fridger

[cyber_space_doc]

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.