I'm doing approximately what you describe. For each object that moves, I test for collisions by testing a number of pick segments that represent lines between points on the surface of the moving object in its old and new positions. Choosing 'enough' pick rays is the delicate part. I'm using 8 to 12, since my moving objects typically have simple shapes.
Rob
Greg von Beck wrote:
I understand a downward pick to perform terrain following is quite good for that purpose, but is there a way to use it for forward/backward collisions that would give you the same quality of detection as a bounding box style? Would you just have to hope that the objects you can collide with are large enough to be hit by the few pick rays you send out? I'm guessing if thats not the case, you would need to go with a more intensive version of collision detection.
Greg von Beck
On Fri, 2003-02-21 at 07:24, Rob Nugent wrote:
John,
Nicely put, particularly the last paragraph. This was what I was trying to say, but without the eloquence !
Rob
John Wright wrote:
We also use a downward pick to perform terrain following and it works fine. The "trick" is to make sure that the ground is broken into pieces so that the detailed pick isn't slow.
In my opinion it all depends on how you have the data for your terrain. We make no distinction between buildings and ground and hence our code allows people to climb stairs, etc without any special code.
In my opinion it is very fast because the initial bounds check rules out most of the scene leaving the geometry pick to be efficient. (However if your ground was one HUGE object this wouldn't work so well)
- John Wright Starfire Research
Rob Nugent wrote:
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".
=========================================================================== 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".
=========================================================================== 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".
