Florin,
This is horses-for-courses obviously, and which to choose will depended on the
app concerned.
For *my* app, I want the moving of the objects to be sensitive to the actual
geometry of the scene. If I move to a 'simplified model' I have the burden of
maintaining that model, and it doesn't do all the things I want to without
making that model of the same complexity as my geometry. (e.g. a door in one of
my buildings opens until it hits something).
My point is that the picking routines *are* fast enough to do this (with
appropriate construction of the scene graph), for those of for whose apps it is
necessary. There is the side-issue of the garbage generated under some
circumstances, but this isn't significant enough for me to want to compromise my
collision model.
Rob
Florin Herinean wrote:
As you say, it's valid to use it every frame and so on, but I wouldn't do
it. For the type of thing you are doing, as I could see from your posted
image, I would use a simplified model to do the picking, eventually an
*extremely* simplified model, like a b&w height bitmap. Knowing the distance
to the ground will be simply a lookup into a table based on x-y, avoiding
completely the picking mechanism.
Cheers,
Florin
-----Urspr�ngliche Nachricht-----
Von: Rob Nugent [mailto:[EMAIL PROTECTED]]
Gesendet: Freitag, 21. Februar 2003 13:07
An: [EMAIL PROTECTED]
Betreff: Re: [JAVA3D] AW: [JAVA3D] Advantages of picking over consulting
the actual geo metry
Florin,
The trouble is that the Locale.pickAll() and Shape3D.intersect() is that
they
are essentially the *only* mechanisms provided by Java3D for testing for
intersections between ray, segment, etc and geometry in the scene.
Yes, calling these from a user interaction as a result of a mouse click is a
common use case. However, it is entirely valid that I should e.g. want to
pick
the object under my view platform every frame or use these routines to do
collision detection. They are the only capabilities provided by Java3D that
allow me to do this, and the garbage they produce can easily be excessive.
Rob
Florin Herinean wrote:
I think that "picking" should simply do that. I mean you move the mouse
over
the screen, and "pick" something. In that case you need the whole picking
framework, and since the picking is done only when you click the mouse, it
shouldn't generate so much garbage. After all, how quickly can you click
the
mouse buttons ??? For the rest like terrain following and maybe collision,
the program itself can be constructed so that it can be really very
efficient, without the picking framework, as was posted before.
However, I do see one circumstance when you can use picking for terrain
following, when you don't know anything about the terrain. You navigate
over
a terrain which was provided by a 3rd party program and you or your
program
doesn't have a single clue of how it looks like.
Cheers,
Florin
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".
--
Rob Nugent
Sun Microsystems, Southampton, UK
[EMAIL PROTECTED]
Tel: +44 (0) 1489 585503
Fax: +44 (0) 1489 881363
===========================================================================
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".
