Andy, Kevin,
(*Disclaimer*: I'm not part of the Java3D group, the following is through
experiment).
I'm getting good results by using picking to follow my terrain. This allows to
do additional things like allow the user to move the ViewPlatform into a house
and up a flight of stairs, without special case code.
I'm simply casting a PickRay downwards each frame and testing the distance to
what it hits, and move the ViewPlatform as appropriate.
I use a combination of Locale.pickAll() which gets a list of Shape3Ds by their
bounds, followed by a geometry based pick using Shape3D.intersect()
There are a few things to make sure of to get good perfomance. This largely
consists of ensuring that the terrain is represented a number of 'appropriately
sized' pieces of geometry aranged ander a heirarchy of groups chosen
'appropriately'.
E.G. A group for each 100m square above several subgroups representing parts of
that square, above more subgroups if necessary... etc followed by the geometry
for that patch.
This makes the Locale.pickAll() very fast, and keeping the geometry of each
patch not too big means that the Shape3D.intersect() is also fast.
Be very careful about using compile() on your terrain though, as it tends to
flatten the BranchGraph and ruin all this careful heirarchy, slaughtering the
performance.
I'm doing one of these 'picks' to follow the terrain, and another 11 similar
picks *per frame* on average to do collision detection, so it's more than fast
enough.
Note that the code to do the pick is *very* simple. Getting the scene graph set
up appropriately is less so.
My personal bugbear, however, is the amount of garbage that Java3D generates
when calling Locale.pickAll() and Shape3D.intersect() which can be substantial
under some conditions if you are doing the volume of picking that I am.
Rob
Kevin Glass wrote:
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".
--
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".
