[Marble-devel] Reference system
Torsten Rahn
tackat at t-online.de
Wed May 16 11:06:06 UTC 2012
Hi,
Please rather create diffs or even better add an entry to reviewboard :-)
Otherwise other people won't be able to spot the differences.
On Dienstag, 15. Mai 2012 20:55:24 marble_developer marble_developer wrote:
> 1.- I have added an attribute in GeoDataCoordinatesPrivate class to set the
> new type and I have added another attribute to set the marble clock. Code
> for GeoDataCoordinates_p.h: http://pastebin.com/mCF0eLn7 The type indicates
> the reference system to use for the GeoDataCoordinates object.
This needs to be a flag at some point.
> 2.- Then I have modified the GeoDataCoordinates class to declare and
> implement the get and set methods for the the new type and for the marble
> clock. Code for GeoDataCoordinates.h: http://pastebin.com/pFF8hjGe and code
> for GeoDataCoordinates.cpp: http://pastebin.com/BUGqVETW
I don't think that the clock should be a property of the GeoDataCoordinate
class. That's neither acceptable semantically nor in terms of ressource
consumption :-)
> 3.- Later I have gone to the SphericalProjection class because the methods
> in there are executed whenever geodetic coordinates converted to screen
> coordinates. I have modified the method that has this prototipe: 'bool
> SphericalProjection::screenCoordinates( const GeoDataCoordinates
> &coordinates, const ViewportParams *viewport, qreal &x, qreal &y, bool
> &globeHidesPoint ) const'. This is the new code for
> SphericalProjection.cpp: http://pastebin.com/yhGEfDf9
> 4.- I have modified ViewportParamsPrivate::setPlanetAxis() method to use
> another reference system to a specific kind of GeoDataCoordinates. Code:
> http://pastebin.com/NDFaXJGz
The changes look about correct (at least for a first prototype). Did you test
whether it works as expected?
Did you check whether the resulting longitudes increase with time as expected?
Of course the problem is still with the MarbleClock: I guess we wouldn't want
to introduce the MarbleClock as a property for the viewport params. So how
would the the time get accessed which currently is only accessible from the
model?
Also there is the catch with BoundingBoxes ("GeoDataLatLonAltBox"): They'd
either be reference system aware or always fed with the fixed reference system
even if the coordinates involved are inertial ones. The latter approach would
require a conversion which again would require the clock to be accessible from
the classes involved.
So maybe we should make MarbleClock a singleton?
Additionally we'd need to investigate possible side effects of the newly
introduced reference system onto other code involved (beyond the bounding
boxes).
So the new code so far introduces some conceptual issues (Marble Clock
availability, Sideeffects and possibly required handling in other classes such
as the LatLonAltBox, API complexity burden).
So we need to weigh up those disadvantages against the advantages (possible
performance improvements - but those need to get verified). And only then we
could think of adding this feature to our code base. It might very well be
that it turns out not to be worth the trouble so that you might need to
continue with your previous approach.
I just had a chat with Guillaume ("smarter") and he would think that the
performance impact is likely not to be noticable in most use cases. But maybe
we could have this verified.
BR,
Torsten
> Problems:
> 1.- I'm not sure that the new implementation added in ViewportParams is
> correct because the SphericalProjection::screenCoordinates() method doesn't
> call ViewportParamsPrivate::setPlanetAxis() directly.
>
> Best regards.
>
> 2012/5/13 Torsten Rahn <tackat at t-online.de>
>
> > Hi,
> >
> > Now I get it :-)
> >
> > Yes, I can see why this kind of problem occurs with Orbit data.
> >
> > Right now we basically calculate the screen positions of objects for a
> > certain
> > position inside the projection classes. See
> >
> > src/lib/Projections/SphericalProjection.cpp
> >
> > with methods like
> >
> > bool SphericalProjection::screenCoordinates( const GeoDataCoordinates
> > &coordinates, const ViewportParams *viewport,
> >
> > qreal &x, qreal &y, bool &globeHidesPoint ) const
> >
> > for example. The expensive part there is the line qpos.rotateAroundAxis(
> > *(
> > viewport->planetAxisMatrix() ) ); which does the basic coordinate
> > transformation between geodetic GeoDataCoordinates and pixel coordinates.
> >
> > I guess that would be the proper place in the code where one could
> > introduce
> > other such possible reference systems. If you really want to "save" CPU
> > cycles
> > there then you'd probably introduce an alternative planetAxisMatrix that
> > is used for the rotateAroundAxis method (have a look at the other places
> > in the
> > code where the planetAxis is calculated to do this in a similar way).
> > This would avoid having to "convert" the positions for all the
> > GeoDataCoordinates of the Satellites. Instead you'd just create a fitting
> > matrix once that would work for all :-)
> >
> > We'd gladly accept patches that do this in a nice way ;) This means it
> > should
> > work for all projections with a nice API. Ideally you'd also provide some
> > basic unit regression tests :)
> >
> > BR,
> >
> > Torsten
> >
> > On Sonntag, 13. Mai 2012 13:20:14 marble_developer marble_developer wrote:
> > > Hi,
> > >
> > > I will try to explain it a bit better.
> > >
> > > When the Earth turns the corresponding angle in each update of Marble
> > > clock, the points added turn the same angle too, it's the normal
> >
> > behaviour
> >
> > > in Marble because the reference system rotates with the Earth globe.
> > >
> > > In this case, a point that has the next values for lon, lat and alt
> >
> > doesn't
> >
> > > generate an orbit. lon, lat, alt = (0, 0, 20000 * 1000). The point is
> >
> > drawn
> >
> > > always in the same point of space.
> > >
> > > I want that the points remain fixed in the space and they doesn't turn
> >
> > with
> >
> > > the Earth.
> > >
> > > In this case a point that has the next values for lon, lat and alt
> > > generates an orbit. lon, lat, alt = (0, 0, 20000 * 1000). The point is
> > > drawn in differents points of space because the point drawn remain
> > > fixed
> >
> > in
> >
> > > space.
> > >
> > > For example, we consider that the update interval of Marble clock is
> >
> > 10800
> >
> > > s, (10800 s is the time that the Earth use to turn 45º) and that a
> > > point with values lon, lat, alt = 0,0, 20000 * 1000 is added in each
> > > update of Marble clock. At first, when the time is 0 s, the point p is
> > > drawn in
> >
> > 0,0,
> >
> > > 20000 * 1000, then, when the time is 10800 s, the point p is drawn in
> >
> > 0,0,
> >
> > > 20000 * 1000 but the last point p' is in -45, 0, 20000 * 1000 respect
> > > the new point p.
> > >
> > > I have performed this behaviour by recalculating the new lon position
> > > in every update but it's very slowly when the number of points is
> > > elevated.
> > >
> > > How can I do this task in a better way? Is it possible to change the
> > > reference system using in Marble?
> > >
> > > Regards.
> > >
> > > 2012/5/7 marble_developer marble_developer <marbledeveloper at gmail.com>
> > >
> > > > Hi all,
> > > >
> > > > Is it possible to change the reference system using in Marble?
> > > > In affirmative case, how can I change it?
> > > > I need to use an inertial reference system instead of fixed reference
> > > > system.
> > > >
> > > > Best regards.
> >
> > _______________________________________________
> > Marble-devel mailing list
> > Marble-devel at kde.org
> > https://mail.kde.org/mailman/listinfo/marble-devel
More information about the Marble-devel
mailing list