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
-----Urspr�ngliche Nachricht-----
Von: Kevin Glass [mailto:[EMAIL PROTECTED]]
Gesendet: Freitag, 21. Februar 2003 08:00
An: [EMAIL PROTECTED]
Betreff: Re: [JAVA3D] Advantages of picking over consulting the actual
geometry
Andy,
I agree with you, picking for terrain following is too comple and
results in poor performance. I think the tutorial on j3d org is just an
example of how you "could" do it. I don't think there is any really
great advantage to do it this way.
Kev
Andy Gombos wrote:
What is the main reason to use picking in terrain following (or
collison detection, or whatever) rather than the actual geometry
data? Picking seems to involve a lot of work (creating the
pick shape, asking the scene graph for the objects, and then comparing
each returned object) versus (in the case of terrain following) asking
the terrain to interpolate a height for a given set of coordinates.
You get the height at a given point instantly, although this does
ignore stuff like buildings you may be in - the framework would need
to be extended for that.
It seems with a class to automatically determine what is below you,
and at what height, would be faster than picking. While the picking
API may infact do this, the more generalized implementation must cause
slow downs somewhere.
Any thoughts?
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.449 / Virus Database: 251 - Release Date: 1/27/2003
--
Jose UML - http://www.newdawnsoftware.com/jose
Pondering RPG - http://pondering.newdawnsoftware.com
===========================================================================
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".
--
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".
