Easily confused

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Easily confused

David Faught
I am having a terrible time trying to get my physics demo working.  I
have a TAvatarReplica subclass that is the primary physics particle
type for now.  I have destroyed its inherited downPointer and added a
forwardPointer, which I intend to have pointing in the direction of
the particle movement.  I have tried a couple of different approaches
to making this work over the past few weeks and so far been
unsuccessful.

I have also subclassed TRay and made it visible only for the purpose
of making the default TFrame #renderAxes: z-pointing arrow bigger than
the other two, hopefully indicating the direction of the TRay picking.
 XYZ-RGB, I like it!

In the class comments for TRay, it seems that the best approach should
be to make the TRay a child of the avatarReplica with a zero
translation, but I am having difficulty figuring out how to separate
the child direction-pointing from the parent facing-direction, which
is necessary because the direction of travel and the facing direction
are really separate things (in this world anyway).  Is there maybe a
nice example of this somewhere?

Oh, did I mention that I also replaced all the mouse and keyboard
interaction so that #driveStep always causes the mouse to only change
the viewing direction and got rid of #fall altogether as the
replica/particle movement is always calculated in a future stepping
loop within the TSpace subclass (in #primitiveStep).  I'm using the
WASD keys and arrow keys to add acceleration.

Anyway, the other alternative that I apparently wasted lots of time on
was to make the TRay a child of the TSpace instead of the
avatarReplica and just make its translation equal the translation of
the avatar/particle.  This simplified the calculation of the facing
direction, or at least I thought it should.  Sometimes the TRay seemed
to point in the direction I expected, sometimes it seemed to point in
the opposite direction, and sometimes some other unrelated direction.
Weird!  And this was supposed to be the simple case!  This prompts the
question "in which direction does a TRay test?"  Does it pick things
in a negative Z direction relative to where it's facing?  This is what
I would expect.  Or in a relative positive Z direction?  And how does
this relate to the default TFrame #renderAxes: ?  Does the blue arrow
point in the direction that the TRay is picking in?

Any guidance would be appreciated.

Trying to get unconfused,
Dave
Reply | Threaded
Open this post in threaded view
|

[croquet-dev] Re: Easily confused

David A. Smith
Look at the code for determining if the avatar has collided with a
TPortal. This is a dynamically generated TRay that I used. It's
direction is the the avatar is moving (left, right, up, down - doesn't
matter) - so it should be pretty easy. Check out
TAvatarReplica>>#prepareRayTest and TPortal>>#testEnter:avatar:. To be
honest, I don't remember which way the damn things point either -
sometimes I regret sticking with the OGL negative z thing so closely.

DAS

On 2/3/07, David Faught <[hidden email]> wrote:

> I am having a terrible time trying to get my physics demo working.  I
> have a TAvatarReplica subclass that is the primary physics particle
> type for now.  I have destroyed its inherited downPointer and added a
> forwardPointer, which I intend to have pointing in the direction of
> the particle movement.  I have tried a couple of different approaches
> to making this work over the past few weeks and so far been
> unsuccessful.
>
> I have also subclassed TRay and made it visible only for the purpose
> of making the default TFrame #renderAxes: z-pointing arrow bigger than
> the other two, hopefully indicating the direction of the TRay picking.
>  XYZ-RGB, I like it!
>
> In the class comments for TRay, it seems that the best approach should
> be to make the TRay a child of the avatarReplica with a zero
> translation, but I am having difficulty figuring out how to separate
> the child direction-pointing from the parent facing-direction, which
> is necessary because the direction of travel and the facing direction
> are really separate things (in this world anyway).  Is there maybe a
> nice example of this somewhere?
>
> Oh, did I mention that I also replaced all the mouse and keyboard
> interaction so that #driveStep always causes the mouse to only change
> the viewing direction and got rid of #fall altogether as the
> replica/particle movement is always calculated in a future stepping
> loop within the TSpace subclass (in #primitiveStep).  I'm using the
> WASD keys and arrow keys to add acceleration.
>
> Anyway, the other alternative that I apparently wasted lots of time on
> was to make the TRay a child of the TSpace instead of the
> avatarReplica and just make its translation equal the translation of
> the avatar/particle.  This simplified the calculation of the facing
> direction, or at least I thought it should.  Sometimes the TRay seemed
> to point in the direction I expected, sometimes it seemed to point in
> the opposite direction, and sometimes some other unrelated direction.
> Weird!  And this was supposed to be the simple case!  This prompts the
> question "in which direction does a TRay test?"  Does it pick things
> in a negative Z direction relative to where it's facing?  This is what
> I would expect.  Or in a relative positive Z direction?  And how does
> this relate to the default TFrame #renderAxes: ?  Does the blue arrow
> point in the direction that the TRay is picking in?
>
> Any guidance would be appreciated.
>
> Trying to get unconfused,
> Dave
>