Celestia Forums

I know this is the CVS build (from 30 aug. '06) and not an official release,
but I wanted to show this bug already.
It happens only with the moon and only with openGL 2.0
It didn't occur in the build of about 2 weeks earlier .

See:




Ren?©

This looks like the same problem I'm having with my cloudmap models which are cmod models. I didn't notice it before the rendercontext.cpp fix yesterday because I was using 2 cloud textures at once. The default one and the one use by the model to deal with the tranparency issues. So I don't know when it actually started. What I'm seeing is that the texture map is being disabled so only the model is visible. Then the model disappears before the light does. This issue dosn't effect the spheres that are created internally. So when they are both being drawn at once it is easy to see. I posted an example shot of this in the atmosphere thread in the Developer Talk forumn.

Edit. Actually, although they look like the same issue the moon is a sphere created internally. Mabey it something to do with the texture.

Edit I think I may need a break from my computer. I think I am starting to see things that are not there. What are you trying to show us here?

cartrite

I thought that was obvious, the idea was to show that the moon wasn't rendered is should be (I don't expect a nodded border (is that good english) between dark and light side of the moon)
I have even a worse example:




Ren?©

Anyway it isn't a bad idea to get some sleep

Yeah, That's what I thought I saw. Anyhow I can't reproduce this and I using the same cvs version. Are you using Windows? I'm on Suse 10.

Yes,

I am on a windows machine unfortunately.

I have no idea what could cause this behaviour,
it looks as if there is a second lightsource, which light is blocked by
the earth from which I am viewing the moon.


Ren?©

If you havn't already, try turning off ring shadows, eclipse shadows, and cloud shadows. I know. Clouds shadow? How about the Lunar Lambert settings.

cartrite

I found the problem (partly),
it seems to be caused by the moon's normal map I use.
If I skip the normap map then the moon looks like it should
(except ofcourse for the shades in the craters and such).
Maybe it is caused by fiddling a bit with the normal map's height
see:

http://www.celestiaproject.net/forum/viewtopic.php?t=9963

Can't see any of these strange curves in either of the 3 planes.

Ren?©

Check to see if the normalmap has an alpha channel. I use the gimp and whenever I copy an image and "paste as new" it stores an alpha channel along with the image. When these things happen I decompose a RGB and compose as RGB to "fix" the image.

cartrite

Does the default Moon normal map look ok? I'm not seeing any troubles on my computer. If the default normal map looks bad too, I'll have to look at your shaders.log file (ideally from a run of Celestia where you get the camera in the field of view and then quit, else it can be difficult to tell which shader was the one used for the Moon.)

--Chris

Something similar? I get this while using a cloud VT.

GL vertex mode:



OGL2 mode:



Using cvs 09/01/2006.

cartrite

Chris , sorry for the late reply:

yes: the default normal map looks OK , but the height-variations were way
too big in my opinion,so I adjusted the levels, fiddling with the 3 channels.
Can't figure out I managed to get these strange low-frequent area's .


Ren?©

I can duplicate this problem with non-default DDS normal maps.
It doesn't matter whether the DDS has alpha or not, and occurs for both VT and non-VT.
No normal height is specified.
It only happens with the OGL2 path, and the shader log does not report errors.

Specs: Mac OS X 10.4.6, 64M Mobility Radeon 9700

Its getting weirder:
I now have a same sort of bug for Earth , using a standard normal map
(8K DDS type from motherlode) ,
only present using OGL2.0 .
I use the CVS 2006.0901 build on a windows platform.

Look at the white area at the arctic region:




Ren?©

The cvs was last updated on 9/2/2006 15:xx. There were some changes for dds formats. Don't know if it would fix what is shown here though.

cartrite

rra,

that I think I understand. Normalmaps in the usual DDS format are just too bad in quality. On the motherlode you find of course everything

Chris modified the CVS code such that normalmaps in .dds format are now interpreted as DXT5nm compressed. So right now at least, the usual DXT compressed (bad quality) normalmaps don't work anymore. That's what you are seing.

As a test: Just load your .dds normalmap into photoshop (using the dds plugin from nvidia) and map the layers as follows

g -> alpha, r -> g, r->b

Then save it as a dxt5 compressed file. Try again with celestia.

Bye Fridger

I am dependant on the build's supplied by Phoenix ,
the latest is still the one of sept. 1 , so I can't check wether this helps
or makes a difference.

As a test: Just load your .dds normalmap into photoshop (using the dds plugin from nvidia) and map the layers as follows

g -> alpha, r -> g, r->b

Then save it as a dxt5 compressed file. Try again with celestia.

Bye Fridger

I can't get PhotoShop to load the DDS file properly, at the moment it is
loading (?) the file for 15 minutes or so with lots of harddisk activity
but nothing more.
I'll give it a new try tomorrow ,

Ren?©

rra wrote:I am dependant on the build's supplied by Phoenix ,
the latest is still the one of sept. 1 , so I can't check wether this helps
or makes a difference.

As a test: Just load your .dds normalmap into photoshop (using the dds plugin from nvidia) and map the layers as follows

g -> alpha, r -> g, r->b

Then save it as a dxt5 compressed file. Try again with celestia.

Bye Fridger

I can't get PhotoShop to load the DDS file properly, at the moment it is
loading (?) the file for 15 minutes or so with lots of harddisk activity
but nothing more.
I'll give it a new try tomorrow ,

Ren?©

the file should load very quickly. Are you sure you have installed the latest PS plugin from NV Dev??

Bye Fridger

Fridger is correct: my recent change breaks DXT compressed normal maps unless they are in the DXT5nm format. I didn't think that anyone had actually used DXT for normal maps, since the quality is quite poor without the new technique that I implemented a couple days ago. I'm not sure if yet if we should come up with some other method to indicate that a normal map should be interpreted as DXT5nm. It could be done with a new SSC field, so that you would add something like "CompressedNormalMap true" to an ssc definition if you wanted to use a compressed normal map. The shortcoming of that approach is that it won't work for normal maps used inside cmod meshes. What would be idea is if there was a special texture format for compressed normal maps . . . I was hoping that the tools to create compressed normal maps would create files marked with the format 3Dc, but it appears that the files are just plain old DXT5.

--Chris

the file should load very quickly. Are you sure you have installed the latest PS plugin from NV Dev??

Bye Fridger

Yes , I did , PhotoShop (CS2) does load smaller DDS files like the Mars Normal map (only 4K for me).
Eventually I get an error:

"Could not complete your request because of on program error" ,
by that time PhotoShop used over 1 GB of RAM.
Maybe that map is corrupt.
As far as that is concirned I encourage the building of a high-res.
Celestia package with "certified" maps.


Ren?©

[size=100]Chris,

What do mean you didn't think any of us were still using DXT based normalmaps? What would we be using? I know some users use PNG exclusively but I don?€™t have the overhead in memory for that. The DXT5 normalmap format for Celestia has been the ?€?defacto?€