> Date: Wed, 12 Mar 2003 11:49:18 -0800 > From: Justin Couch <[EMAIL PROTECTED]> > > Rob Nugent wrote: > > > I can't say that 1) is a bug, since the way picking works is so fuzzily > > defined. > > What I'd really like is an official way to be able to do picking > > independent of any View. > > hahahahahha... :( The Java3D team has, right from the very start, flat > out refused to actually provide a specification. That has been a > constant bitch of mine (read the archives) and it is a very, very poor > thing to do for such a public standard. No, that PDF on the site that > says "Java3D 1.3 Specification" is not a specification - it's the > Javadoc put into a PDF file format. It's woeful from a specification > perspective as almost nothing is actually specified, just lots of > hand-waving almost spec wording. The picking model is a classic example > of this "yes you can pick, no we're not going to tell you how it works".
I just went and read Chapter 11.3 in the Specification and didn't find it too bad really. I didn't have anything to do with the picking implementation in Java 3D, so I don't think that's a totally biased assessment. However, there are bugs in the documentation, and I agree with you with respect to your specific questions; that information should be in the Specification. The spec is fairly loose about the details of the picking implementation, as it is in other areas. This is primarily to allow some flexibility for different implementations of the Java 3D API. For example, the "distance" metric is deliberately unspecified to allow for either bounds or geometry-based picking. [Even at the geometry level it is possible to define several different metrics that tradeoff accuracy for performance or other criteria. How do you define the distance between two arbitrary, possibly non-convex, partially or fully nested polyhedra? Our implementation uses a sophisticated iterative linear programming algorithm to arrive at what we believe to a good measure of distance. Other implementations may decide that's overkill and use other techniques.] > Date: Thu, 6 Mar 2003 12:47:32 -0800 > From: Justin Couch <[EMAIL PROTECTED]> > > [...] > For example, does pick use render traversal information or not? (is > pickClosest() based on the the OrderedGroup or Switch selection for > example). Basically, you can pick whatever is potentially visible within a view (that is, without regard to the view frustum) and enabled for picking. Nodes that are switched off are unpickable. OrderedGroup only affects rendering order. Section 11.3.2 says that the methods that return objects in sorted order are based on distances to the eyepoint. As far as I can tell, this is *not* true. The methods at the Locale and BranchGroup level appear to be independent of the view, although this is still somewhat fuzzy due to the issues involved with multiple views and their interactions with picking behaviors, LOD switches, and ViewSpecificGroups. For example, if you perform a pickClosest() using a PickRay, then the objects that intersect that ray will be sorted according to their distance from the ray origin, not the eyepoint. It's important also to make a distinction between the utility code and the core. PickCanvas, for example, is totally view-dependent. It constructs PickShapes based on canvas pixel locations and the orientation of the image plate with respect to the virtual world. I do share your feelings about other sections of the Specification, especially the description of the view model. I don't believe it is possible to completely understand the view model from just reading the spec and the javadoc and playing around with it. [In Java 3D 1.3.1 FCS there is a new utility com.sun.j3d.utils.universe.ViewInfo that is essentially a re-implementation of the view model, but designed for public use and source code availability; hopefully the source code will allow developers to understand what goes on under the hood.] I encourage you and everybody else on the list to submit bugs and RFE's through official channels whenever you encounter problems with the documentation or troublesome aspects of the Java 3D design. As Java 3D developers we try to do this as a courtesy for bugs discussed on the interest list, but it's really the customer-submitted bugs that get the attention of the management structure and the hard resources. -- Mark Hood =========================================================================== 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".
