Celestia Forums

Hi Chris. Thanks for all the unbelievable work to get 1.3.2 final ready. A lot of the bugs reported in the past have been fixed. However, a new one has cropped up and I don't know if it is only in 1.3.2 final or in earlier versions (I got rid of them).

The comet tails are all wacky on my system (GeForce 4 TI 4200) with the latest drivers. I am using the default download with no other add-ons. Here are some screenshots of comet Halley, and one of comet Borrelly.











I don't know what is happening, but the tails have lost their realistic appearance. Also, I don't recall such a big blank area around the comet when viewed either head-on or from the rear ...

Can I fix this with some adjustments to the cfg file, or is this a bug? Help!

Frank

Unfortunately, I see the same problem on my system (also a Ti4200 with current drivers) so it's not something wonky on Frank's computer

I have the same problem with a Geforce FX 5700.The comets tails seem to have a defined border

I also have this weird trails effect on my laptop too...

Also does it go in all kinds of directions when time is speeded up a little or is that just me?

I have the same issue on both my work and home computers which use different graphics cards.

Work: GeForce FX 5900 (128 MB)
Home: ATI Radeon 7000 VE (64 MB)

Dave

fsgregs wrote:....I don't know if it is only in 1.3.2 final or in earlier versions (I got rid of them).

I don't visit comets too often, but I'm sure they've been like this for some of the pre-releases aswell....come to think about it, I can't remember how they used to look.

This how Halley looked in Celestia 1.3.1pre11

That is what I recall ... nice looking comet tails that fade into nothing smoothly. Obviously, a bad bug has crept in to 1.3.2. Whatever the program is now doing is probably adversely affecting the drawing of other objects with transparent features (perhaps some of Ras's bug reports are caused by the same thing).

Frank

Part of it I think could be due to the fact that objects that have 2 sides (a shell not 2 sided shape or box but 2 sided mesh. In 3d studio max 6 this can be achieved with the shell modifier) in the case of the comet possibly, and my clouds are now both being rendered on the same visible plane and without depth. This allows the user to see both sides of an object as if it were all facing the same direction. And in some instances when you are close enough to the object, you will see the opposide side over anthing else that may lie within the object, or the object wraps around, as with my clouds around another model of the planet. Lighting is still being rendered correctly at the same time. This our eyes find confusing. When in fact the opposing side before was only rendered if you faced that direction. What the future of this method could be is that one side will be more solid than the opposing side as in real life. Also all polygons will cast shadows based on opaqueness. I have a feeling this problem will not be completely fixed in the near future. Unless we return to the old method in pre 11. In which case we would have to resort to 16 bit z-depth rendering over the now 24 bit. In the Doctor Who project I was working on I got around this to a small percent to autodetect the correct z-depth bit rate to use according to the type of mesh or texture was being rendered. This reduced the amount of tearing that occured when multiple meshes are overlapped. This unfortunately is a problem with OpenGL as I see this tearing in 3d studio max and any other opengl program that overlaps meshes.

Ras, if you are correct and if the new method of rendering 2 sided meshes in 1.3.2 is causing the problem, and if comet tails, certain clouds, some nebula and any objects with 2-sided polygons are going to look poor as in the screenshots, then let's return to the older method of rendering. I know 24 bit vs. 16 bit is supposed to be "better", but at least the realism of these objects was very good. The change has clearly caused a dramatic reduction in quality of images here, at least for comets and some other meshes. That seems a big step backward in the evolution of Celestia, not progress toward an even better visual experience.

Obviously, these things all creep in and Chris's effort to improve other aspects of the program have clearly paid off in 1.3.2. However, I hope there is a coding fix implemented soon that will allow the program to keep 24 bit rendering and get rid of this problem.

Frank

fsgregs wrote:Ras, if you are correct and if the new method of rendering 2 sided meshes in 1.3.2 is causing the problem, and if comet tails, certain clouds, some nebula and any objects with 2-sided polygons are going to look poor as in the screenshots, then let's return to the older method of rendering. I know 24 bit vs. 16 bit is supposed to be "better", but at least the realism of these objects was very good. The change has clearly caused a dramatic reduction in quality of images here, at least for comets and some other meshes. That seems a big step backward in the evolution of Celestia, not progress toward an even better visual experience.

That I do not think is going to happen...The current flow of Celestia has and always will be onward so I see chris fixing the problem instead of reverting to an earlier implimentation...so as I stated I think that this will be a while before its fixed...

Obviously, these things all creep in and Chris's effort to improve other aspects of the program have clearly paid off in 1.3.2. However, I hope there is a coding fix implemented soon that will allow the program to keep 24 bit rendering and get rid of this problem.

Frank

The 24 bit z-depth setting I think is the reason for the change in transparent handling in Celestia. It may be a matter of going about it differently...I dont know for certain because its been quite some time since Ive looked at the code but with my small experience with OpenGL the 2 z-depth settings have a significant effect on meshes merged no matter transparent or not. I think the approach that Chris implemented is incomplete and I forsee him continuing his efforts to improve no matter if we report the bug or not...I tend to report them on the sole reason that I do not know the timeframe involved...weither that fix has priority or has it been placed on a low priority and will be seen in a future version...like emissive rings...I havent tested the newest release yet so I do not know if Chris fixed this or not...He has a tendency of fixing or adding things and forgets to add it on the updates list...Its pretty hard to keep track of everything Im sure...but I know hell get to it very soon *crosses fingers*

The problem is that when a comet is rendered, the clip plane is set too far from the camera position, and so it truncates the comet tail. It doesn't have anything to do with 24-bit z buffers or two-sided objects. I'm not yet sure how I'll fix this. I'm unsatisfied with the rendering of comet tails now and would like to do something much better: computing the apparent brightness by ray casting through the comet tail volume. If it looks like it will be a while before I get to that, I'll implement some short term workaround and adjust the clip plane distance.

--Chris

Thanks, Chris. Looking forward to both the short term and longer term fix.

Frank

chris wrote:The problem is that when a comet is rendered, the clip plane is set too far from the camera position, and so it truncates the comet tail. It doesn't have anything to do with 24-bit z buffers or two-sided objects. I'm not yet sure how I'll fix this. I'm unsatisfied with the rendering of comet tails now and would like to do something much better: computing the apparent brightness by ray casting through the comet tail volume. If it looks like it will be a while before I get to that, I'll implement some short term workaround and adjust the clip plane distance.

Thanks for the info Chris. I'm curious as to why the tails looked OK in 1.3.1 but not 1.3.2? From the pics above the coma appears brighter than the tail in 1.3.1 but much darker than the tail in 1.3.2. Does that have anything to do with the rendering?

Dave

deleted

Found some real pictures of Halleys for comparison..