The specification of a world and a predefined flight path through that world may not exactly specify an end-user's view.
Different HMDs have different optics, making it unreasonable for application developers to hard-wire such parameters or allow end-users to vary that parameter at will.Īnother example is a system that automatically computes view parameters as a function of the user's current head position. One example of this is a head-mounted display (HMD), where the optics of the head-mounted display directly determine the field-of-view that the application should use. Letting the application control all viewing parameters is not reasonable in systems where the physical environment dictates some of the view parameters. The Java 3D view model, when operating in a non head-tracked environment and rendering to a single, standard display, acts very much like a traditional camera-based view model, with the added functionality of being able to transparently generate stereo views.Ĩ.1.1 The Physical Environment Influences the View The Java 3D view model incorporates head tracking directly, if present, with no additional effort from the developer, thus providing end-users with the illusion that they actually exist inside a virtual world. Developers must continuously reposition a camera to emulate "a human in the virtual world." This makes sense when dealing with custom applications, less sense when dealing with systems that wish to have broader applicability: systems such as viewers or browsers that load and display whole worlds as a single unit or that the end user view, navigate, display, and even interact with that world.Ĭamera-based view models emulate a camera in the virtual world, not a human in a virtual world. Appendix C, "View Model Implementation Details," describes the Java 3D view model from an advanced developer and Java 3D implementor's perspective.Ĭamera-based view models as found in low-level APIs give developers control over all rendering parameters. Finally, it presents the relevant parts of the API from a developer's perspective. It next describes how that model operates in the simple case of a standard computer screen without head tracking-the most common case. This chapter first explains why Java 3D chose a different view model and some of the philosophy behind that choice. The application controls the ViewPlatform's position and orientation the renderer computes what view to render using this position and orientation, a description of the end-user's physical environment, and the user's position and orientation within the physical environment. This model distinguishes between how an application positions, orients and scales a ViewPlatform object (a viewpoint) within the virtual world and how Java 3D's renderer constructs the final view from that viewpoint's position and orientation. Java 3D's view model achieves this versatility by cleanly separating the virtual and the physical world.
It also means that the same application, once again without modification, can render stereoscopic views and can take advantage of the input from a head-tracker to control the rendered view. This "write once, view everywhere" nature of the new view model means that an application or applet written using the Java 3D view model can render, without modification of the scene graph, images to a broad range of display devices including standard computer displays, multiple-projection display rooms, and head-mounted displays. To use a non-default renderer, you can specify via the size() function.Java 3D introduces a new view model that takes Java's vision of "write once, run anywhere" and generalizes it to include display devices and six-degree-of-freedom input peripherals such as headtrackers.
There are five render modes: the default renderer, P2D, P3D, PDF, and SVG. This work is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License. If you see any errors in this tutorial or have comments, please let us know.
0 kommentar(er)
