Dear list, the OrbitBehavior has a public method setRotationCenter() which seems to be the only way to influence the rotation center, since the translation only sets xtrans and ytrans to offset the view but leaving the rotation center where it is.
The method works fine ... except that the view isn't updated in the method. Instead, when the user next clicks on the Canvas3D to manipulate the view, the view suddenly 'jumps' to accomodate the new center. Programatically one CAN'T force the visual update easily, because the integrateTransforms() method is protected. Ok, a solution would be, to subclass OrbitBehavior and override the setRotationCenter() method, calling the super method and then integrateTransforms(). But why does OrbitBehavior behave as it does in the first place? What's the feature here? Then the x/ytrans thingy: it often comes in handy as it is, not moving the rotation center, but more often I would love to have the choice if it _offsets_ or _centers_. Besides, from looking at this lists archive I know that the x/ytrans issue was a source of confusion several times; the solutions suggested by J3D people for handling x/ytrans didn't work in the 2 cases where a suggestion was given at all (and/or I was able to find). Might it be, that the intention of the OrbitBehavior class just is "a (good) sample of code" and the fine details are "left as an exercise to the reader"? If so, has someone already done her/his exercises and is willing to share pointers, algorithms or code? Thanks in advance 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".
