Christian Ambros Oct 31 8:50 AM
>________________________________[Non-text portions of this message have been removed]
> Von: Bill J Gray <pluto@...>
>Gesendet: 19:50 Dienstag, 30.Oktober 2012
>Betreff: Re: [guide-user] Using OpenGL for object display.
>> thanks for the answer. Maybe I wasn't that clear about why I brought up OpenGL...
>Aha! I _did_ misunderstand. (And possibly still do, somewhat... but your
>message does clear things up a bit.)
>I gather what you're planning to do is to have a "real time" display of moving
>objects; the moving objects may be planets, asteroids, comets, and artificial
>satellites. I'd assume stars would be treated as "non-moving". Is this the case?
>If true, you may find that the best move is indeed something similar to what
>Guide does: rather than attempt to split the work into several threads and/or
>pass it off to a GPU, try to reduce the amount of work that needs to be done in
>the first place. Because the display will be a real-time one, this may be
>quite straightforward. You'll know that the telescope is tracking a particular
>RA/dec rectangle; compute where all the objects are now, and where they'll be
>in a minute, and you'll know which objects will pass through the field of view
>over the next minute at the specified magnitude limit.
>This will usually mean a much smaller sample of objects, which can be computed
>and displayed as moving targets with great ease. You're now computing the position
>of every object once a minute, rather than on every screen redraw. You can even
>"compute the position" just by linearly interpolating between the start-of-minute
>and end-of-minute positions.
>It may make sense to have that "compute the position of everything" function
>running in a separate thread, with all the drawing done in another thread. With
>a bit of care, you can then make sure that drawing is never interrupted; you need
>to ensure that when your first minute is up, the other thread has already computed
>where objects will be at the end of the second minute.
>Compared to Guide, you do have the advantage that you know in advance what times
>will be required by the system: "right now" and the immediate future. Guide never
>knows when the user may decide to see what the sky will look like next week or what
>it was doing in 3128 BC. So you shouldn't need anything quite as complicated as
>I described in my previous e-mail.
>Hope this helps, and actually answers the right question this time!