Re: [Celestia-developers] compile error in eclipsefinderdlg.cpp

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

I just fixed the eclipse finder, tour guide, and goto dialog in the
Win32 UI. Sorry that I broke both that and the KDE UI--I made all
these changes on my MacBook. Fridger, thanks for the KDE patch. Please
check it in.

gotoLocation works fine. The problem is the with the new definition of
the phase lock coordinate system.

This line:
appCore->getSimulation()->gotoLocation(Point3d(0, 0, -distance),
Quatd::yrotation(PI), 2.5);

should be changed to this:
appCore->getSimulation()->gotoLocation(Point3d(0, 0, distance),
Quatd::yrotation(0), 2.5);

We could easily change the phase lock coordinate system to match the
old one, but the new one is arguably more sensible, with +z pointing
from ref object to target instead of -z. What do you think is the
right thing to do here?

I also added a missing updateUniversal() in Observer::setTime(). This
fixes another problem that appeared in the eclipse browser, where the
initial camera location would jump to some apparently random location
in space.

--Chris

On Feb 9, 2008 5:13 AM, Da Woon Jung <dir...@gm...> wrote:
> Looks basically like the changes made by Chris to the OS X version
> recently. Does the new gotoLocation() work ok on the Linux versions?
> (I fear it won't)
>
> DW
>
>
> On Feb 9, 2008 9:51 PM, Fridger Schrempp wrote:
> > Here is my 2-line patch e.g. for KDE, same needs to be done for gtk, gnome,...
> >
> > --- /usr/local/cvs/Sandbox/celestia/src/celestia/kde/eclipsefinderdlg.cpp
> >    2008-02-05 08:37:58.000000000 +0100
> > +++ eclipsefinderdlg.cpp        2008-02-09 13:46:29.000000000 +0100
> > @@ -121,7 +121,7 @@
> >       if (id == 1) {
> >           Selection target =
> > appCore->getSimulation()->findObjectFromPath(std::string(item->text(col ==
> > 1).utf8()), true);
> >          Selection ref = target.body()->getSystem()->getStar();
> > -       appCore->getSimulation()->setFrame(FrameOfReference(astro::PhaseLock,
> > target, ref));
> > +       appCore->getSimulation()->setFrame(ObserverFrame::PhaseLock, target, ref);
> >          QString date = item->text(2);
> >           int yearEnd = date.find('-', 1);
> >           astro::Date d(date.left(yearEnd).toInt(),
> > @@ -134,10 +134,7 @@
> >           appCore->getSimulation()->update(0.0);
> >
> >          double distance = astro::kilometersToMicroLightYears(target.radius()
> > * 4.0);
> > -        RigidTransform to;
> > -        to.rotation = Quatd::yrotation(PI);
> > -        to.translation = Point3d(0, 0, -distance);
> > -        appCore->getSimulation()->gotoLocation(to, 2.5);
> > +        appCore->getSimulation()->gotoLocation(Point3d(0, 0, -distance),
> > Quatd::yrotation(PI), 2.5);
> >
> >       }
> >   }
> >
> >
> > Fridger Schrempp wrote:
> > > compiling the latest SVN under Linux gives for all flavors of Linux:
> > >
> > > eclipsefinderdlg.cpp:124: error: 'PhaseLock' is not a member of 'astro'
> > > eclipsefinderdlg.cpp:124: error: 'FrameOfReference' was not declared in
> > > this scope
> > > eclipsefinderdlg.cpp:137: error: 'RigidTransform' was not declared in
> > > this scope
> > > eclipsefinderdlg.cpp:137: error: expected `;' before 'to'
> > > eclipsefinderdlg.cpp:138: error: 'to' was not declared in this scope
> > > make[5]: *** [eclipsefinderdlg.o] Error 1
> > >
> > > F.
> > >
> > >
> > > Chris Laurel wrote:
> > >> The observer patch is here:
> > >>
> > >> http://www.shatters.net/~claurel/celestia/files/patches/observer/observer.patch
> > >>
> > >>
> > >> It's big because I couldn't get SVN to realize that every single line
> > >> of celx.cpp had not in fact changed. A lot of files had to be
> > >> changed--there was unfortunately no way to break this up into smaller
> > >> changes. observer.cpp and observer.h are almost completely rewritten.
> > >> Many of the changes to other files are simple renamings of the
> > >> standard frames, e.g.. astro::Geographic to ObserverFrame::BodyFixed.
> > >>
> > >> A lot of unnecessarily complex code was replaced with simpler
> > >> constructions. For example, the code to convert to and from the
> > >> PhaseLock frame was replaced with this:
> > >>
> > >>  case PhaseLock:
> > >>       return new TwoVectorFrame(_refObject,
> > >>
> > >> FrameVector::createRelativePositionVector(_refObject, _targetObject),
> > >> 1,
> > >>
> > >> FrameVector::createRelativeVelocityVector(_refObject, _targetObject),
> > >> 2);
> > >>
> > >> --Chris
> > >>
> > >> On Feb 6, 2008 11:28 AM, Chris Laurel <cl...@gm...> wrote:
> > >>> As mentioned on the 1.5.1/1.6.0 features page
> > >>> (http://en.wikibooks.org/wiki/Celestia/151Features#Reference_frame_work)
> > >>> one thing that I want to do in Celestia is clean up the observer code.
> > >>> The code in the observer class is messy, uses confusing terminology,
> > >>> and has some performance troubles.
> > >>>
> > >>> First of all, the observer class uses a very rough implementation of
> > >>> reference frames that was written when I new a lot less about the
> > >>> topic. The reference frames added in 1.5.0 are much more flexible and
> > >>> more cleanly implemented. It makes sense for the observer class to use
> > >>> them instead of the old code. Celx scripts currently work exclusively
> > >>> with the old observer-style frames. A lot of scripts would be easier
> > >>> to write if 1.5.0 frames could be used; it's another argument for
> > >>> unifying the reference frame code in Celestia.
> > >>>
> > >>> The performance problems with the current observer class caused by the
> > >>> fact that the observer's position and orientation in universal
> > >>> coordinates are recalculated every time they are requested, which
> > >>> turns out to be many times per frame. An observer object stores the
> > >>> position in frame coordinates and computes the universal coordinates
> > >>> from that whenever the getPosition() method is called. What appears
> > >>> like a simple member query function can actually involve a lot of
> > >>> calculation, especially when the observer is following an object with
> > >>> a ScriptedOrbit. In the rewrite that I'm working on, the universal
> > >>> coordinates are also stored, so the call to getPosition() actually is
> > >>> almost free.
> > >>>
> > >>> The main point of this message is that one thing I'd like to do as
> > >>> part of the observer rewrite is to change the way the chase and phase
> > >>> lock frames are defined. One of the forum readers expressed the
> > >>> problem quite well:
> > >>>
> > >>> http://www.shatters.net/forum/viewtopic.php?t=12010
> > >>>
> > >>> Using the spin axis of the reference object as one of the frame axes
> > >>> doesn't make a lot of physical sense, and it's also very inconvenient
> > >>> when the object's spin axis isn't constant. As an illustration of the
> > >>> problem, go visit Comet Halley (which has a precessing spin axis) and
> > >>> enter phase lock or chase mode: the view will wobble wildly in a very
> > >>> non-intuitive way. Using the angular momentum vector instead of the
> > >>> spin axis as the second frame vector would eliminate the problem and
> > >>> also define a more physically meaningful frame. For phase lock, I
> > >>> believe that we should should pick the velocity vector as the second
> > >>> axis.
> > >>>
> > >>> Redefining the chase and phase lock frames won't affect cel URLs at
> > >>> all, but it might cause problems with some scripts. I have yet to see
> > >>> a script where the change causes a problem, but it's possible that
> > >>> there's one or two out there. However, I think that this is a small
> > >>> tradeoff for properly working frames. The problem with objects with
> > >>> varying spin axes will only get worse: I'm in the process of defining
> > >>> custom rotations for some outer planet satellites. Adding support for
> > >>> SPICE orientation kernels means that more spacecraft will rotate in
> > >>> ways that make chase/phase lock practically useless--it's already a
> > >>> problem for spacecraft that use SampledOrientation.
> > >>>
> > >>> --Chris
> > >>>
> > >>
> > >> -------------------------------------------------------------------------
> > >> This SF.net email is sponsored by: Microsoft
> > >> Defy all challenges. Microsoft(R) Visual Studio 2008.
> > >> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> > >> _______________________________________________
> > >> Celestia-developers mailing list
> > >> Cel...@li...
> > >> https://lists.sourceforge.net/lists/listinfo/celestia-developers
> > >
> >
> >
> > -------------------------------------------------------------------------
> > This SF.net email is sponsored by: Microsoft
> > Defy all challenges. Microsoft(R) Visual Studio 2008.
> > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> > _______________________________________________
> > Celestia-developers mailing list
> > Cel...@li...
> > https://lists.sourceforge.net/lists/listinfo/celestia-developers
> >
>