"Yazel, David J." wrote:
>
> Wow I had no idea. For some reason I just assumed they were accessing the
> data directly, since they have access to the geometry.
They aren't for the PickTool code. With the direct collision detection
code they would have to be.
> 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!
That is correct. I tried to optimise around that but because of the bad
design decision with the spec, it won't work.
> 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.
It is part of the utils classes and not the core so PickTool has to
abide by any rules that I have to. PickTool is not set up for doing
high-speed realtime work like terrain following and collision detection.
It is great if you want to handle a mouse picking an object on the
screen and that's it.
--
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".
