Moving some of the picking utility functionality into the core is one
of the things being looked at for 1.4.
Doug Twilleager
Java 3D Team
Sun Microsystems
>MIME-Version: 1.0
>Subject: Re: [JAVA3D] ANN: Collision Detection/Terrain tutorial
>To: [EMAIL PROTECTED]
>
>Wow I had no idea. For some reason I just assumed they were accessing the
>data directly, since they have access to the geometry. You mean they are
>pulling the geometry out into an short lived array every time I do a pick
>with GEOMETRY_INTERSECTION? What good is that! I don't understand why they
>can't scan the GeometryArray without copying it... I mean they have direct
>unfettered access to it don't they? (They being Sun, Java3d, etc.) If this
>is because it is a utility and not part of the core then maybe they should
>make it part of the core so they can take advantage of accessing the data
>more quickly and with less memory overhead.
>
>Too bad, the code I am using works well and is simple, but sure the heck
>explains some of the memory consumption I have been getting.
>
>Dave Yazel
>
>
>
>-----Original Message-----
>From: Justin Couch [mailto:[EMAIL PROTECTED]]
>Sent: Wednesday, May 16, 2001 11:06 AM
>To: [EMAIL PROTECTED]
>Subject: Re: [JAVA3D] ANN: Collision Detection/Terrain tutorial
>
>
>"Yazel, David J." wrote:
>
>> A quite excellent tutorial! I think you have inspired me to pick a topic
>> and try something similar. Perhaps on transparency or particle systems or
>> some such thing.
>
>Please send this way!
>
>> Some quick comments:
>>
>> 1. End of chapter 2 (Collision Detection) does not have "next step" links
>> like are at the end of chapter 1.
>
>Will fix.
>
>> 2. I am unclear why you just don't ask java3d to pick the intersection for
>> you? In particular for terrain following, Java3d will even handle the
>> interpolation within the triangle to give the the exact point of
>> intersection.
>
>Java 3D does *not* handle it for you. The utilities provided by Sun do,
>but they are not part of Java 3D. If you have a look at what I've done
>with the tutorial is to leave it open-ended. You could use the pick
>tools or you could use the code I've written. If you look at the
>PickTool code, it is very far from optimal. Compared against my code,
>for full terrain following and collision detection, my code is about 25%
>faster.
>
>To give you an example of why my code is faster:
>
>- For every polygon you need to determine if you are intersecting with
>the plane and then if you are, whether you are inside the polygon -
>which requires the inside/outside test. When dealing with the
>intersections, you need to know where the intersection point is. Sun's
>code does a square root length calculation for every polygon. I do a
>simple length squared as all you really care about is relative measures.
>Square root calcs are extremely expensive.
>
>- The pick tools enable every capability bit known to man. My code could
>well be running on a live scenegraph with changing scene where you
>want/need to enable only certain parts and leave the rest with no
>capabilities set.
>
>- Pick tools have to extract the geometry coordinates from the
>GeometryArray object. This is a very expensive operation because it
>means for every frame you have to (at least) allocate twice an array for
>the geometry to fetch the coordinates - once for terrain, once for
>collision. If you have geometry that is overlaid or Shape3Ds with
>multiple geometry objects and you need to test all of them, the overhead
>becomes astronomical. I use other generated geometry info if at all
>possible.
>
>The allocation problem is due to bad design of the java3d API for get
>coordinates. You cannot pass it an array that is bigger than the number
>of coordinates. That is, you can just allocate a really huge array once
>and re-use it for every request. Instead you have to reallocate every
>time you do a pick - at least twice a frame and possibly more. To give
>you an idea of how bad this was. I did some profiling on a scene with
>20K polygons of indexed triangles and I was allocating and garbage
>collecting 2MB of data per second! That just right royally fucks any
>chance of decent performance.
>
>The pick tools are not optimised for doing simple collision detection.
>They always return you the intersection point. My code will bail as soon
>as it detects *any* intersection. Sun's code will continue to work
>through every polygon of the geometry. With complex geometry inside a
>building, that can be a potentially massive saving of calculations per
>frame.
>
>--
>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".
>
>===========================================================================
>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".
