flickering black spots in clouds

[selden]

Flickering black areas are visible then rendering the Earth at
large magnifications when clouds are enabled.

Here's a screengrab from directly above the north pole,
which I think looks rather entertaining. Unfortunately, I didn't manage
to get a Cel url and now can't get back to exactly the same viewpoint.



Here's a CEL script to take you to the viewing position.

Code: Select all

{
renderflags { set "stars|planets|cloudmaps|atmospheres"}
select { object "Sol/Earth" }
gotolonglat { time 3 distance 100000 longitude 0 latitude 90 }
}


Increase magnification so the fov is 5 seconds of arc.
(Yes, I know it's extreme, but I didn't notice this when I was creating the script for another purpose.)

When I rotate the Earth with the Right-Mouse-Button, I can see areas of the surface flicker black.

This is seen in all the versions of Celestia that I've tried: v1.3.2 through v1.4.1 cvs.

System:
1GB 3.4GHz P4-550, WinXP Pro SP2
128MB GF6600GT, ForceWare v84.21

[t00fri]

I know about this bug (and several others) since quite some time. So I can definitely confirm it. Yet it became more frequently apparent when examining Chris' new atmosphere code in conjunction with my monster normalmap.

There is also this annoying white flickering seam around the (NEW!) atmosphere at times.

Bye Fridger

[chris]

I think that the new depth sorting scheme that I'm working on will fix this problem.

--Chris

[chris]

It turns out that the problem had nothing to do with depth sorting.

There is a floating point precision issue in the atmosphere code that appears when the camera is very distant from a planet relative to the size of that planet. I implemented a workaround that clamps the distance of the camera to a maximum value that eliminates the precision problems. Aside from fixing the bug the effect on rendering should be imperceptible, because at large distances all the rays from viewer to the vertices of an object are nearly parallel. The fix is in CVS.

--Chris

[t00fri]

It turns out that the problem had nothing to do with depth sorting.

There is a floating point precision issue in the atmosphere code that appears when the camera is very distant from a planet relative to the size of that planet. I implemented a workaround that clamps the distance of the camera to a maximum value that eliminates the precision problems. Aside from fixing the bug the effect on rendering should be imperceptible, because at large distances all the rays from viewer to the vertices of an object are nearly parallel. The fix is in CVS.

--Chris

Thanks Chris,

I was also thinking more towards our familiar float precision business. Anyway, that bug was quite disturbing...I'll check ASAP.

Bye Fridger

[selden]

Nope, sorry.
I still see the glitches.

[chris]

Nope, sorry.
I still see the glitches.

Yes, but the really bad problems that you saw with the new atmosphere are gone. The missing triangles in the cloud layer really are a depth buffer precision problem and are likely to be fixed by the new depth sorting code.

--Chris

[selden]

Oh, OK.
Great!
Thanks.

[cartrite]

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

GL vertex mode:



OGL2 mode:



Using cvs 09/01/2006. This effect is seen when a cloudvt and cloud normalmap are used.

I originally posted this in a wrong spot.
http://www.celestiaproject.net/forum/viewtopic ... 6301#76301
I thought I could delete or move the first post but I couldn't. This is probally a better place for this.

cartrite

[selden]

cartrite,

"a cloud vt" is awfully vague.

If you can provide a minimal copy of the failing Vt as an Addon, including a cel:// url of that viewpoint, it'd be much easier to locate the problem and verify the fix.

[cartrite]

It's a 32k cloud vt. I created it and it's the only one I have so I can't test any others right now and it's not available publicly. I never had a problem with it. It works normally with all other versions of Celestia. It also works normally in all render modes except OGL2 with cvs 09/01/2006.

I will download Haralds cloud vt ( level0 and 1) and see if I get the same results.

Edit: I downloaded D Bradys 16k cloud vt and it worked fine. I checked further to find that it only happens when a cloud normalmap is used. That's about all I can do for now. Sorry.

cartrite

[cartrite]

Selden wrote:

including a cel:// url of that viewpoint,

I don't have Celestia officially installed on my system so cel://'s don't work for me. Not even the ones you make. What I do is build the current cvs and create a shortcut to the executable on my desktop. For me to install / uninstall everytime I update cvs would probally give me headaches.
I don't even use Windows much and the only reason I've been using it lately was because I was doing something for Don Edwards.

The url's don't work in linux either, something about a unrecognized protocol.

With that in mind, all I did to see this was start celestia and rotate the planet. Then stopped it when I saw something strange.

cartrite

[selden]

Under Windows, the registry URL entries are specified with the textual path to the file, not the file ID. As a result, a cel url will invoke whatever Celestia executable is in the directory that has the same path where you initially installed Celestia.

I change things around a lot without having to reinstall. Usually it just involves copying the newly built executable into the folder of the working version, of course.

[I've found that doing Addon development in the same directory where the cvs version of Celestia gets rebuilt usually leads to disaster.]

One way you could make URLs work (under Windows) is to

rename your root working Celestia folder out of the way, if necessary

install v1.4.1final into the folder named Program Files\Celestia (for example)

rename Program Files\Celestia (or wherever) to be something else (maybe Program Files\Celestia_141 )

rename your root working folder to be Program Files\Celestia (or wherever you installed Celestia)

Then URLs would invoke whatever version of Celestia is in your working folder.

[cartrite]

Selden,

I'll look into getting url's to work on my system. Right now they work if I build a setup.exe with isso from my latest cvs build and install it by running the setup. One of the reasons that they don't work now is my work folders are not on my C drive in Programs Files. They are on another partition.
And I couldn't get them to work there so I gave up. I just have too many other things going on right now.

The images I showed from my first post show a problem. If this is making it difficult for everyone, I won't show anything like this again until I can do it like you say. May take some time for that to happen.

All I did was start Celestia cvs 09/02/2006 with the standard startup script, rotated the Earth with cloud vt and a cloud normalmap vt and there it was.

Someone else will probally see this soon anyhow.

cartrite

[selden]

Unfortunately, since cloud normal maps are brand new, you're the only one who I'm sure is doing anything with them. (The problem does go away when normal maps are disabled, right?)

I'm guessing Fridger and Don Edwards might eventually use them, but that may take a while. They both seem to have other projects that they're working on.

I think Fridger did report having some problems with VT normal maps for surface textures, but that might or might not be related.

[cartrite]

Correct. The problem is not there if a cloud normalmap "VT" is disabled. A non vt cloudnormalmap works fine.


cartrite

[t00fri]

Unfortunately, since cloud normal maps are brand new, you're the only one who I'm sure is doing anything with them. (The problem does go away when normal maps are disabled, right?)

I'm guessing Fridger and Don Edwards might eventually use them, but that may take a while. They both seem to have other projects that they're working on.

I think Fridger did report having some problems with VT normal maps for surface textures, but that might or might not be related.

My problems are gone since Chris' fix of yesterday.
I would love to look into normalmaps for clouds, but I am really working hard on several projects in parallel.

Bye Fridger

[cartrite]

My build was from after the fix also. I should also mention that the files used were in png format. I believe Fridgers problems had more to do with the new dds compression code?

cartrite

[t00fri]

Correct. The problem is not there if a cloud normalmap "VT" is disabled. A non vt cloudnormalmap works fine.


cartrite

My suspicion is this: Just as Chris had forgotten to enable DXT5nm compression for VT's yesterday, he probably also forgot something for cloud normalmaps in case of VT's...?

Bye Fridger

[chris]

My build was from after the fix also. I should also mention that the files used were in png format. I believe Fridgers problems had more to do with the new dds compression code?

In the image you posted, it looks like one virtual texture tile may be rendered as if it had compressed normals. But, I don't understand why this would be happening. Does the problem only occur when the cloud normal map is a VT?

--Chris