On Donnerstag 28 Oktober 2004 00:59, Ampere K. Hardraade wrote:
> On October 27, 2004 04:18 pm, David Culp wrote:
> > One way to do this will be to define the deck(s)
> > as a set of rectangles; I think two should do it, but maybe more.
> > user aircraft gets close to the deck (using radar range and altitude) the
> > AICarrier will start checking to see if the aircraft is within the area
> > bounded by any of the rectangles.
>
> A seperate class should be made for the deck, call SolidObject. It should
> be activiate by using XML. For example:
> <solid>deck</solid>
> This way, other portions on the aircraft carrier can be definied as solid
> if one desires.
>
> It should also be the aircraft's responsibility to check whether this
> SolidObject is within the aircraft's boundary.
>
> The aim is not to limit the use of this code on the carrier only. It is
> best to be able to reuse the code on other areas.
Defining extra surfaces for carrier decks might be a good idea.
But I think that these geometry should be put inside the scenegraph. The can
be marked invisible either with using the ssgInvisible branch or by putting
them into a seperate branch whitch is not used for renendering at all.
On every update the carrier class needs to update their positions and their
speed.
The benefit of putting those surfaces into the scenegraph is that we can use
intersection test routines we already need for ground reactions too.
No need to implement things twice.
Greetings
Mathias
--
Mathias Fröhlich, email: [EMAIL PROTECTED]
_______________________________________________
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
