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 |
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 > |
Free forum by Nabble | Edit this page |