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".
