[Marble-devel] Reference system

Mon Jul 9 16:49:35 UTC 2012

Hi,

I've detected some issues in orbit visualization when the satellite orbit
is behind the Earth. See the images: http://i47.tinypic.com/2u5wa9z.jpg and
http://i50.tinypic.com/2d01c06.jpg

I've used the inertial system reference for the satellite and orbit instead
of the fixed reference system.

I think that I need rotate the bounding box... but I'm not sure...

How can I solve this issue?

Regards.

2012/5/23 marble_developer marble_developer <marbledeveloper at gmail.com>

> Hi all,
>
> I have implemented a small demo that uses the new reference system. The
> small demo contains the next files:
> main.cpp: http://pastebin.com/Z74VBMCu
> marblemanager.h: http://pastebin.com/kXAHLuTz
> marblemanager.cpp: http://pastebin.com/iCwPPnjV
> satitem.h: http://pastebin.com/id30XEeY
> satitem.cpp: http://pastebin.com/NBpV5dus
>
> I have made new changes in the next files, (now I use diffs to make more
> clear the review):
> GeoDataCoordinates_p_h.diff: http://pastebin.com/ak56mVLq
> GeoDataCoordinates_h.diff: http://pastebin.com/mj88Jr4R
> GeoDataCoordinates_cpp.diff: http://pastebin.com/9GfDv1YM
> SphericalProjection_cpp.diff: http://pastebin.com/3GzR72gb
> ViewportParams_cpp.diff: http://pastebin.com/zvizfq2T
>
> I have used a new approach. I haven't used the Marble clock in the
> conversion in ViewportParams because all the times are the same for each
> update. The update interval of Marble corresponds with the step time of my
> orbit propagation. v = e / t --> e = v * t --> lon = lon -
> (earthAngularSpeed * m_time). earthAngularSpeed and m_time are constants in
> my case.
>
> When I run my small demo a point is drawn. The point remains fixed in the
> space although I click and drag over the earth globe.
>
> Can you help me to correct this behaviour?
>
> Best regards.
>
>
> 2012/5/16 Torsten Rahn <tackat at t-online.de>
>
>> 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
>> _______________________________________________
>> Marble-devel mailing list
>> Marble-devel at kde.org
>> https://mail.kde.org/mailman/listinfo/marble-devel
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/marble-devel/attachments/20120709/51557b4e/attachment.html>