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,
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.
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?