> Date: Fri, 7 Mar 2003 17:17:22 +0100 > From: Karsten Fries <[EMAIL PROTECTED]> > Organization: LION bioscience AG > > > So the orientations of the eyes don't matter, just their positions > > relative to the canvas. Your real eyes will converge and diverge > > depending upon the depth in the rendered image to which you wish to > > focus (although some people have trouble doing this since it requires > > decoupling the focal length of the lens of each eye from the stereo > > disparity between them; keeping objects near the plane of the screen > > helps). > > i don't see that quite. why should people do something like this when having > shutter glasses. i think the program has to set the focus (emulate the focus > on a ceratin object). nobody has to force their eyes to see a stereo effect.
This is just what happens in real life when a person looks at an object. If you have normal stereo vision, you converge your eyes to different distances in order to focus on different planes of depth. The problem I was talking about is unavoidable with non-volumetric displays (flat screens). In real life the lens of your eye will focus differently depending upon how far away your object is, and this is coupled with the stereo disparity. On a computer screen, your eyes must focus on the screen at a fixed distance while your eyes converge depending upon the depth of object of interest. Most people don't have a problems with this, but for others it just doesn't work. > i would argue that each eye has to have its own projection matrix and > thus its own frustrum to experience a real 3D stereo effect. This is what the standard Java 3D view model gives you. Each eye gets is own unique projection matrix and frustum. Sorry if I didn't communicate that very well... The view frustums created by the standard Java 3D view model have a nominal convergence to the center of the canvas. That doesn't mean that the user's eyes have to converge there, but some folks do have difficulty fusing stereo images when the convergence is decoupled from the actual distance to the flat images. To minimize this problem, move the view platform so that the image plane is near the object of interest. I don't see how you could avoid this problem even in compatibility mode. You can easily set a nominal convergence, but then you'd need some sort of eye tracker to determine at what depth the user's eyes are converged from one frame to the next. But in the end you'll still have that flat screen at a fixed distance from the eyes. > i mean if you compare the standard stereo to that one compatibility > mode gave me i have the evidence. before i had a slight impression > that my object is in front or inside of screen. but i had no sensation > of depth in the object itself. in fact the direction the eyes where > looking didn't converge at all. it was like staring into the infite > distance. This probably means that your object is too far away. Try moving it closer and reducing the scale factor. Or if you prefer, adjust the eye separation in the PhysicalBody. > minor note: i once tried default stereo with the DirectX > implementation on Win98 and it was really nice (just as i get now with > open gl) and simply worked from scratch. perhaps there is a minor > difference between these two that may also be driver dependent. What do you see when you run the ObjLoad example program with stereo? % java -Dj3d.stereo=REQUIRED ObjLoad When I run it, I get stereo image that is perhaps a little too close to my eyes for good convergence, but using OrbitBehavior to move it back a bit, it looks fine. Of course, without head tracking the image gets distorted when moving my head around, and I lose stereo convergence if my eyes aren't horizontal, but there's nothing that can be done about that on a conventional display without head tracking; stereo pairs are only "correct" from a particular viewpoint and orientation. (Actually, the same is true of monoscopic images, but the human visual system compensates pretty well for flat images -- we only notice distortion with fairly wide angles of view, and we usually aren't disturbed by flat images being skewed when looking at them from oblique angles). > moreove we where trying our application on autosteroscopic 3D panel > with the same effect. I'm not sure what that setup entails. You could probably handle it with separate monoscopic canvases, but I'll need a few more details on how your device works. > > You might encounter problems with the stereo convergence being too > > wide or narrow. This means that the model in the virtual world is > > scaled too large or small, or that it is too close or far away from > > the eyes. It's preferable to adjust the scale of the virtual world > > through a transform or through an explicit screen scale factor and > > move the view platform appropriately, so that the eye separation in > > the PhysicalBody can be meaningfully calibrated for individual > > users, but some programmers just adjust the eye separation in the > > PhysicalBody directly to solve the problem. > > ?you suggest that the objects in my scene scale in respect to the > distance to the viewer? I suggest that one needs to scale the virtual world appropriately with respect to physical world to get good stereoscopic results, yes. In monoscopic mode this usually doesn't make as much difference. A small object close to the eye looks the same size as a large object far away. In stereo mode, you could be trying to converge your eyes on something 1mm away from your nose or something 1km away, and yes, this makes a significant difference in how the object appears and the effectiveness of the stereo visualization. > > Picking is one of the things that requires the normal Java 3D view > > model to work correctly. No workaround is available. > > and that is pretty sad... It was never our intention that compatibility mode would provide access to all the Java 3D feature set, and this is clearly indicated in the Java 3D Specification and in the class overview for View: Use of these view-compatibility functions will disable some of Java 3D's view model features and limit the portability of Java 3D programs. These methods are primarily intended to help jump-start porting of existing applications. Given a choice of supporting two different view models -- one tailored to simple camera transforms, and one that enables immersive viewing environments -- the Java 3D API designers decided to create a view model that subsumes them both in a consistent framework. We didn't have the resources to provide a picking API that works with compatibility mode as well as the standard view model. It may be that there is a flaw in the standard Java 3D view model that prevents your app from doing what it needs to do on conventional flat displays, but I'm not convinced of that yet. As far as we know, this stuff works -- we have CAVEs, immersive desktops, head-mounted displays, and conventional desktops working in stereoscopic, monoscopic, and head-tracked modes with good results. Getting Java 3D to work on alternative display devices such as volumetric or autostereographic panels may be more problematical, but we're certainly willing to suggest methods that may work. Also, if you have any difficulty understanding how to apply the view model to a standard flat screen for sterescopic displays, don't hesitate to ask specific questions. -- 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".
