Georg, This sounds very similar to what I did in the KeyNavigateTest example from my book: http://www.manning.com/selman/
The example defines (code online) a KeyCollisionBehavior which extends a KeyBehavior and takes a TransformGroup and an instance of a CollisionDetector interface. Before modifying the TransformGroup using the super-class KeyBehavior the KeyCollisionBehavior calls the isCollision method (passing the new modified Transform3D) on the CollisionDetector. If the return value is true the modification is applied to the TransformGroup, otherwise it is discarded. A class that maintains the world state (model) implements the CollisionDetector interface, providing rudimentary control over what values within the avatar's Transform3D instance are legal or illegal. I can think of several enhancements (such as an avatar falling under the influence of gravity) that might require a tighter coupling between the avatar's movement behavior and the world model. I think your second approach is closer to what I did for the Particle System code I checked into the J3D.ORG repository. A pipeline of MovementFunctions is defined that cooperate/compete to control a Particle's position. The MovementFunctions that are later in the pipeline have more opportunity to influence/veto the final position than those that run earlier. This approach worked well for particles (earlier MovementFunctions apply force, accelerations etc. to the particles, later system convert these into coordinate changes). In your case the avatar is a "particle" and your key input, collision avoidance, physics etc. determine final position. I don't think I'd like a system that used competing behaviors however. Behavior could be scheduled to run on independent threads, and while Java 3D provides some guarantees about when certain classes of behavior are run, historically this has been unreliable. I think you might find that you'd get jitter (see the BillboardTest example from the book). I would start with a simple system using something like the CollisionDetector interface and a single behavior. You could always augment this internally with a pipeline-like approach if required. This gives you a single behavior which determines avatar position, while allowing you to modularize the collision detection/physics code if necessary. Amway, sorry to ramble. Let me know how things work out. Sincerely, Daniel Selman Author - "Java 3D Programming" http://www.manning.com/selman -----Original Message----- From: Discussion list for Java 3D API [mailto:[EMAIL PROTECTED]]On Behalf Of Georg Rehfeld Sent: Monday, May 20, 2002 11:40 PM To: [EMAIL PROTECTED] Subject: Conceptual question: where to do collision avoidance? Dear group, having my quake style Behavior (subclass of ViewPlatformAWTBehavior) working now smoothly a conceptual question arises: which class is responsible to do (avatar) collision avoidance? I've currently a preference to let the Behavior be responsible, indirectly by cooperating with some specialized class(es), that are able to do the actual collision checks. Such specialized class would implement a listener interface to be called by the Behavior, and the programmer adds any interested implementor of that interface (any class instance attempting to control the avatars position, or may be direction or even scale) as a Listener to the Behavior. The Behavior would call each Listener in turn with the avatars planned Transform3D (and, as I'm wanting to implement Verlet integration similar to the ideas in http://ns.ioi.dk/Homepages/tj/publications/gdc2001.htm, also with the LAST Transform3D), getting back a potentially modified Transform3D. If there are more than 1 Listeners, the subsequent ones would get the already restricted Transform3D, adding up constraints without intervention from the Behavior itself. Is this concept shortminded or pointing me into a wrong direction? Upside argument: - the Behavior controls most of the avatar anyway, thus it seems to be convenient to have some service classes attached doing the rest of the job (i.e. keeping the avatar on the ground and outside of walls) Downside argument: - the recognizion of such Listeners isn't built into J3D, thus it only works with my own (Sub)classes. Subclassing might be difficult, when integrateTransforms() heavily accesses private class members and/or requires special attention (as is the case with OrbitBehavior for instance, which lets one not easily set arbitrary locations for the ViewPlatform). Another concept I can come up with, is to have additional independent Behaviors around attempting to restrict the avatars Transform3D, i.e. woken up on each elapsed frame or might be a postId from the AWTEvent handling Behavior. Upside: - that Behaviors have full control over the target T3D, have not to implement some special interface and are thus available in J3D yet. - There may be specialized restricting Behaviors in certain areas of the scene taking over control, when neccessary, without special attention by the programmer. Downside: - the Behaviors have to fight for the target T3D, controllable by the programmer only via setSchedulingInterval() - the AWTEvent handling Behavior has no knowledge of the changes by other Behaviors and can't veto (hmm, except it wakes up on some postId and all the others send that) Having written down all that I'm just about to change my mind to the other concept using independent Behaviors, hmm. Any thoughts or hints are very welcome! Thanks Georg ___ ___ | + | |__ Georg Rehfeld Woltmanstr. 12 20097 Hamburg |_|_\ |___ [EMAIL PROTECTED] +49 (40) 23 53 27 10 =========================================================================== To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff JAVA3D-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help". =========================================================================== To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff JAVA3D-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help".
