Use of JCP site is subject to the
JCP Terms of Use and the
Oracle Privacy Policy
|
JSRs: Java Specification Requests
JSR 148: 3D Media Utilities
This JSR has been Withdrawn
Identification |
Request |
Contributions |
Additional Information
Section 1. Identification Submitting Member: Sun Microsystems, Inc. Name of Contact Person: Brian Burkhalter E-Mail Address: brian.burkhalter@sun.com Telephone Number: +1 650 786 0102 Fax Number: +1 650 786 5152 Specification Lead: Brian Burkhalter E-Mail Address: brian.burkhalter@sun.com Telephone Number: +1 650 786 0102 Fax Number: +1 650 786 5152 Initial Expert Group Membership: Sun Microsystems, Inc. Section 2: Request
2.1 Please describe the proposed Specification:The 3D Media Utilities API would be a non-core Java package. It would allow the implementation of applications which require three-dimensional vector operations or volumetric imaging. 2.2 What is the target Java platform? (i.e., desktop, server, personal, embedded, card, etc.)Server and desktop. 2.3 What need of the Java community will be addressed by the proposed specification?This package will provide three-dimensional utilities needed by two other extant non-core packages, Java3DTM and JavaTM Advanced Imaging (JAI). The ability to have available 3D vector operations outside the context of Java3D has also been expressed by certain Java developers. 2.4 Why isn't this need met by existing specifications?The interfaces defined in this class are required by both of the aforementioned packages which cannot be interdependent. 2.5 Please give a short description of the underlying technology or technologies:The following functional areas will be addressed: 1. Three-dimensional Vector Operations. The proposed three-dimensional vector math package provides a set of classes to perform those vector and matrix operations on 2D, 3D, and 4D points that are needed for 3D graphics and imaging. It is not intended to be a general purpose vector math package. 2. Volumetric Imaging The proposed volumetric imaging package provides a set of classes and interfaces that can be used to represent volumetric images sampled in a topological grid in three dimensional space. They also allow external developers to extend classes to support specific representations of images with unique features or to meet specific requirements. The classes are defined in such a way that similarities between the 2D image representation specified by the Java2D API and volumetric image representation are maintained as much as possible. Two indices address pixels in a 2D image, whereas three indices address voxels in a volumetric image. 2.6 Is there a proposed package name for the API Specification? (i.e., javapi.something, org.something, etc.)The specification will use the package names javax.vecmath for the 3D vector algebra component and javax.media.volumeimage for the volumetric imaging component. 2.7 Does the proposed specification have any dependencies on specific operating systems, CPUs, or I/O devices that you know of?No as it is written entirely in Java. 2.8 Are there any security issues that cannot be addressed by the current security model?No 2.9 Are there any internationalization or localization issues?There are no internationalization issues. The localization strategy is yet to be determined. 2.10 Are there any existing specifications that might be rendered obsolete, deprecated, or in need of revision as a result of this work?No 2.11 Please describe the anticipated schedule for the development of this specification.A beta version is expected to be available in conjunction with the release of Java3D 1.3-beta tentatively planned for October 2001. 2.12 Please describe the anticipated working model for the Expert Group working on developing this specification.After a mailing list is created for this JSR, design proposals and API specifications will be sent to Expert Group members via e-mail. Once the Expert Group has reviewed the supplied documentation, a meeting will be held via conference call. Subsequent discussions will be conducted via e-mail. No further conference calls nor in-person meetings will occur unless deemed necessary by the Expert Group. The vote by the Expert Group on the proposal will be conducted via e-mail. Section 3: Contributions
3.1 Please list any existing documents, specifications, or implementations that describe the technology. Please include links to the documents if they are publicly available.1. Java 3D API Documentation http://java.sun.com/products/java-media/3D/forDevelopers/J3D_1_2_API/j3dguide/index.html 2. javax.vecmath Javadoc http://java.sun.com/products/java-media/3D/forDevelopers/J3D_1_2_API/j3dapi/javax/vecmath/package-summary.html 3. Shared Volume Package API Documentation The javadoc of the package javax.media.volumeimage which was to have been part of the JAI 1.2 JSR (not yet submitted). 4. Proposal: Volume Imaging Architecture A description of the original proposal to have been submitted to the JAI 1.2 Expert Group. 5. Java2D API Documentation
http://java.sun.com/products/java-media/2D/index.html 3.2 Explanation of how these items might be used as a starting point for the work.The javax.vecmath portion of the Java3D 1.2 specification defines the 3D vector operation portion of this JSR. The javax.media.volumeimage specification defines the volumetric imaging portion of this JSR. The Volume Imaging Architecture proposal provides an overview of the javax.media.volumeimage package in the context of volumetric imaging in JAI. The Java2D specification discusses the 2D imaging classes of which the volumetric. Section 4: Additional Information (Optional)
4.1 This section contains any additional information that the submitting Member wishes to include in the JSR.As alluded to above, the volumetric imaging portion of this JSR was to have been included in the JAI 1.2 JSR which is yet to be submitted as of the date of submission of this JSR. Joint discussions between the Java3D and JAI teams concluded that architecturally as well as from an implementation standpoint it would be better to separate the 3D Media Utilities JSR from that of JAI 1.2. This provides better control over architectural content as well as over the release schedule of the various affected packages. |