Skip to main content

A rough draft for Java 3D 1.4 Picking APIs change is ready for review

6 replies [Last post]
Joined: 2004-03-17

We've completed a rough draft on the proposed Picking changes for Java 3D 1.4 :

Please review it ASAP, we plan to start the implementation pretty soon. Let us know if you have any comments.


- Chien.

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
Justin Couch wrote:

> We've completed a rough draft on the proposed Picking changes for Java 3D 1.4 :

One of the more annoying performance issues we've had with Java3D is in
picking. In particular, the fact that it creates a new object every time
you make a pick request. In the case of Xj3D, that can be in the order
of megabytes of garbage every second. I see this new design is still
propogating the same bad design habits of returning new object instances
for every call. It would be far better if you used the following
signatures, as that way garbage is application controlled:

The following 4 methods will be added to Locale and BranchGroup :
method: public int pickAll( int mode, int flags, PickShape pickShape,
List info)
method: public int pickAllSorted( int mode, int flags, PickShape
pickShape, List info )
method: public void pickClosest( int mode, int flags, PickShape
pickShape, PickInfo info )
method: public void pickAny( int mode, int flags, PickShape pickShape,
PickInfo info )

The List object can contain a pre-populated set of PickInfo classes, and
if the J3D internals can fill in any extras as needed. The int return
value is used to indicate how many were actually found, and thus the
number of valid objects to read from the user-provided List.

Justin Couch
Java Architect & Bit Twiddler
Author, Java 3D FAQ Maintainer
Programming is essentially a markup language surrounding
mathematical formulae and thus, should not be patentable.

To unsubscribe, e-mail:
For additional commands, e-mail:

Joined: 2003-06-10

Justin's proposal causes me problems.
Short lived objects are pretty well handled nowadays, they will be better handled as time goes on (escape analysis coming) and i think that [b]such[/b] collection might be a wrong target. (note the emphasis on 'such', which implies that i don't see all collections as harmless as those. /disclaimer )
All this is conditionnal as i've not made a J3D specific test, nor have i profiled in that direction. (i'd be happy to know the results and conditions of your tests, btw)
Nevertheless, i've been testing extensively the reaction of modern collectors to short lived objects and they reacted perfectly under heavy load.
Using generational GC, this would lead to worse performance and increased memory useage. Lists being alive for longer, they would be much more likely to leave eden, be collected later at lower speed and increase heap artificially.
On a side note, i don't see the proposed design as bad. It follows rules and thus goes in the direction of new optimisations of JVMs. By trying to defeat (current and) past jvms behavior, you just defeat what people making those jvms work for. Well, that's my opinion, don't take it as an attack, just a thought about the interest of doing such thing. /me starts a philosophy flame war. :)

Anyway, here is what i think could be added:
method:public PickInfo pickAllSorted( int mode, int flags, Pickshape pickShape, Comparator comparator )
so that anyone can add their sorting to take different properties in account.
Simple PickAllSorted() would use a (for example) statically instanced basic Comparator and call the other pickAllSorted().

Joined: 2004-03-17

We looked a little more into the idea of making the new picking APIs avoid object generation and there really isn't a clean way of doing it that fits the pattern of other Java 3D APIs (or other Java APIs). This is compounded by a variable length array of inner class objects in each PickObject. Plus, we're not convinced that it is necessary (given many of the arguments Pepe mentioned). We plan to implement the current approach initially, and then benchmark it. If there is a significant problem, we can revisit this later.

-- Kevin

Joined: 2003-06-10

I searched around a bit but came up empty so I'll go ahead and post here...
What is the status of NIO support in the picking tools? I have been getting errors since I switched to NIO.
java.lang.IllegalStateException: GeometryArray: must not be in
USE_NIO_BUFFER mode to use this method

from PickResult.

Perhaps this is already fixed in a daily build?

Joined: 2004-03-17

An issue has been filed for this missing implemenation.
Issue 115 : No picking support for J3DBuffer object.

No promise, but we hope to get this supported by 1.4 FCS.

- Chien.

Matthew Hilliard

If it performs well, I'm all for it.

To unsubscribe, e-mail:
For additional commands, e-mail: