Hi Bill,

thanks a lot, that helped indeed. Maybe I was a bit confused on the whole amount of what there is to do, that I didn't see it so clearly. But that's why we talk about thinks. To get it clear.

To split and pre-calc the moving objects with some safe zone will be the solution to that bottleneck. You are right. The normal guide user keeps one uncertain where to go or what to do next. That's what I had in mind. On the other hand a pro astronomer knows exactly which objects will be next because he has observing schedules correlated with object positions, heights above horizont which match favorable airmasses and fixted exposure times which makes everything a littlebit easier to predict. Sometimes one wishes that all astronomers, not even the pros would get themselves in a more strict behaviour, but I know it's uneasy to learn for most people in the first place.

I will five it a shot and see where it takes me. Thanks again for your advise.
Christian

--
"A little learning never caused anyone's head to explode!"


"Ein wenig Lernen hat noch niemandens Kopf zum Explodieren gebracht!"

>________________________________
> Von: Bill J Gray <pluto@...>
>An: guide-user@yahoogroups.com
>Gesendet: 19:50 Dienstag, 30.Oktober 2012
>Betreff: Re: [guide-user] Using OpenGL for object display.
>
>
> 
>Hi Christian,
>
>> 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!
>
>-- Bill
>
>
>
>
>

[Non-text portions of this message have been removed]