"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".
