Re: Stereo setup for visad

Thanks for the suggestion about super().  I now have a version of SpreadSheet 
that works in stereo, but I need to fix the eye separation problem now.  I have 
used the following code to fix it in other apps, but I am unsure as to how to 
make it work with visad:

PhysicalBody myBody = simpleU.getViewer().getPhysicalBody();
myBody.setLeftEyePosition( new Point3d(-.0033, 0.0, 0.0));
// default is(-0.033, 0.0, 0.0)
myBody.setRightEyePosition(new Point3d(+.0033, 0.0, 0.0));

What I am wondering is where I would 'getPhysicalBody()' from.  I see that 
visad uses VirtualUniverse rather than SimpleUniverse, and I would think that 
their interfaces would be similar (though I'm looking through the 
java/j3d/visad javadocs right now and can't find anything on 
SimpleUniverse...weird), but it also appears that there is no way to directly 
access a VirtualUniverse, as when a VirtualUniverse is created, it is private 
and there are no methods to access it in  Is there 
another way to go about getting the relevent viewer or physical body?
-Tim Costa

--- Bill Hibbard <billh@xxxxxxxxxxxxx> wrote:
>Hi Tim,
>> I'm trying to add stereo to visad as was discussed here:  
>> and I'm having some problems making it work as part 2 of that email 
>> indicated, extending FancySSCell and SpreadSheet.
>> The problem I am having is that the only time you can call super() is on the 
>> first line of the constructor.  Therefore, the only time I can call 
>> setSSCellClass() is after I call super() in my extension.  However, calls to 
>> setSSCellClass() that are performed after the constructor appear to be 
>> ignored.  I verified this by directly modifying my copy of 
>> to call setSSCellClass() at the very beginning of StereoSSCell's 
>> constructor, with my extension of FancySSCell.  When I did this, the code I 
>> added to setup stereo was called.  I then put that call on the last line of 
>> the constructor, and tried again.  This time my code was not executed (the 
>> constructor does not get called).
>> One possible workaround that I am aware of is simply copying the entire 
>> constructor from into my extension of SpreadSheet, but that 
>> would obviously not be considered proper OO programming, and I would like to 
>> know if there is another way to do it.
>Another work-around is to call a super() signature that
>has arguments, and to "compute" one of those arguments
>by calling a static method of your extension class, that
>calls SpreadSheet.setSSCellClass(). That is, your static
>method might always return 2 for the number of rows (or
>whatever), but before returning 2 call
>I suspect that Curtis's intention in the SpreadSheet
>design was that applications would call
>SpreadSheet.setSSCellClass() before calling the
>SpreadSheet constructor (or extension class
>constructor), something I didn't realize when I
>answered Mike Redmond's question about stereo.
>As to proper OO programming, my feeling is that it is
>important for core system classes to have proper OO
>programming so that lots of things can be changed by
>extending classes, but that it is not important for
>application classes to have neat OO programming. My
>motto is sort of "let the system be designed well, so
>applications can be easy hacks."
>Good luck,

<a href="";> Email Service</a> - "Plenty of 1's 
and 0's"

Select your own custom email address for FREE! Get you@xxxxxxxxxxxxxx w/No Ads, 
6MB, POP & more!