"Gary L. Graf" wrote:
>
> There is a subtle difference here between 2D and 3D. In conventional Java
> applications the objects are layered on the screen. On a mouse click the VM
> looks for the object beneath the cursor in the topmost view layer and sees if
> it has a listener attached. It is oblivious to anything in lower layers. In a
> 3D scene, the objects 'exist' in a world with depth information, a world where
> the preception of the object is a function of your view point and other
> environmental parameters. When you click your mouse, how does the system know
> what the perceived line of sight is from the cursor?
Very simple - take the current camera position in the world and project
a ray that is perpendicular to the view plane.
> control an orbit behavior. How do you define the center of the orbit, and what
> happens when the viewpoint changes. If the object with the 'orbit listener'
> attached is in a distant, nearly invisible, background corner, it is still
> active so a mouse move would suddenly slew the view around that object and
> dramatically alter your view.
This is a very hard thing - and one of the very basics - that the VRML
specification has had for years. There is an EXAMINE mode, and the spec
does not specific how to locate the centre point of the orbit. Each
browser seems to do it differently. Some ask you to select an object and
then it rotates around that, others pick some arbitrary point and use
that. I think the coming conclusion that will go into the spec will be
to take the centre as being the origin of the transform above the
viewpoint. Then, any offset information that you put into the viewpoint
is the "radius" that the orbit works around.
> There is nothing stopping you from taking AWT events and manipulating screen
> objects with your own code. For simple scenes where you maintain strict
> control of the viewpoint and the objects within the scene, this works fine and
> will probably be easier and faster than Java3D. As more objects get
> introduced, as they begin to move relative to each other, or the user gets more
> freedom to move around the scene, managing your events becomes much more
> difficult. I would suggest that you bite the bullet now and learn how to use
> behaviors.
Yes, there's an interesting problem here too. I don't know how Sun
implements their behavior handling internally. I have both approaches -
directly registering a MouseMotionListener on the Canvas3D and also
using behaviors. Using the former, you start to loose events in a
heavily loaded scene, where you don't in the later. I have a sneeking
suspicion that Sun does not use the normal AWT event capture and
distribution mechanism for their handling of AWT events. The other hard
part to deal with is that under the behavior model you get given
everything. It's hard to actually filter out mouse events to only be a
certain list. (though I haven't tried setting an event mask and using
processEvents directly on the canvas).
--
Justin Couch http://www.vlc.com.au/~justin/
Freelance Java Consultant http://www.yumetech.com/
Author, Java 3D FAQ Maintainer http://www.j3d.org/
-------------------------------------------------------------------
"Humanism is dead. Animals think, feel; so do machines now.
Neither man nor woman is the measure of all things. Every organism
processes data according to its domain, its environment; you, with
all your brains, would be useless in a mouse's universe..."
- Greg Bear, Slant
-------------------------------------------------------------------
===========================================================================
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".
