Re: [Celestia-developers] JPL Small Body Browser

[Chris L. <cl...@gm...>]

Fridger,

Thanks for doing the testing. Based on the console output, it looks
like the problem is occurring before the depth range allocation. For
some reason, no objects at all are appearing in the render list. I'm
baffled about many aspects of this bug:
- It only appears on the KDE version
- It only affects the Moon (so far...)
- It seems to have only recently appeared--is that true?

I have a hunch that the sensitivity to distance and viewing angle is a
result of other more distant objects coming in or out of the view.
Does the Moon disappear only when there are no other objects in view?

--Chris

On Sat, May 16, 2009 at 9:20 AM, Fridger Schrempp
<fri...@de...> wrote:
> Chris,
>
> Chris Laurel wrote:
>> Here's one thing to try...  Change the DEBUG_COALESCE #define in
>> render.cpp from 0 to 1. Rebuild Celestia, start it, and enable the
>> console log. See if there's any abrupt change in the output as you
>> approach the Moon. Do the depth intervals change dramatically when the
>> Moon disappears?
>
> I followed your suggestion. When rotating the Moon at close distance slowly
> from being rendered to being NOT rendered, there is indeed a *most dramatic*
> change in the console log output within a tiny additional rotation angle that
> makes the Moon "switch off"!
> I made two screnndumps:
> This is just before the Moon switches off (close distance). Look at the
> console output:
>
> http://www.shatters.net/~t00fri/images/moontest4.jpg
>
> After an "epsilontic" further rotation, the Moon switched off and now look at
> the output:
>
> http://www.shatters.net/~t00fri/images/moontest5.jpg
>
> Fridger
>
>>
>> I have know idea why a depth buffer bug would only occur with KDE, but
>> it's worth doing this simple test to see if depth buffer management is
>> at fault.
>>
>> --Chris
>>
>> On Sat, May 16, 2009 at 8:21 AM, Fridger Schrempp
>> <fri...@de...> wrote:
>>> Pat Suwalski wrote:
>>>> Fridger Schrempp wrote:
>>>>> Sorry, but all this smells like a rendering bug to me!
>>>> Indeed, this is a good mystery. What could be common between GTK and
>>>> KDE, but not with Qt?
>>>>
>>>> I tried what you did, and got an X-server crash. However, I recently had
>>>> to switch to the open-source drivers since ATI dropped r300-r500 support
>>>> from their binary blob. I recall trying similar steps to what you
>>>> described at work yesterday on nVidia and I couldn't get the moon to
>>>> disappear.
>>>>
>>>> --Pat
>>> I resolved part of the "mystery" meanwhile: for gtk and Gnome, the Moon
>>> rendering problem went away after rebuilding also celestia-gtk and
>>> celestia-gnome from scratch.
>>>
>>> However for KDE it is indeed persistent.
>>>
>>> Since I work with the KDE desktop, I have also tested the KDE case much more
>>> thoroughly. Note the KDE libs are regularly updated (via smart). So there
>>> might be something wrong in some kdelib update!? Still why should it only
>>> affect the Moon and NOTHING else in my system? Sounds implausible...
>>>
>>> So it now boils down to a pure KDE problem, hence there is also no
>>> contradiction with your findings anymore.
>>>
>>> It's even more mysterious, since also celestia-KDE turns out to get the Moon
>>> right, once I start celestia from *within* the source directory, i.e. like
>>> ./celestia! If I start it via the the PATH variable, the Moon ceases to be
>>> rendered as described previously. Note I did a bona fide 'make install' after
>>> compilation (no fiddling).
>>>
>>> Here is my ./configure commandline that I used for KDE (since ages!):
>>>
>>> ./configure --prefix=/usr/local --with-kde --with-lua
>>> --with-cspice-dir=/usr/local/cspice CXXFLAGS="-I /opt/kde3/include"
>>>
>>> The celestia data dir is correctly set up in /usr/local/share.
>>>
>>>
>>> Fridger
>>>
>
>