NOTICE: This version of the NSF Unidata web site (archive.unidata.ucar.edu) is no longer being updated.
Current content can be found at unidata.ucar.edu.
To learn about what's going on, see About the Archive Site.
NOTICE: This version of the NSF Unidata web site (archive.unidata.ucar.edu) is no longer being updated.
Current content can be found at unidata.ucar.edu.
To learn about what's going on, see About the Archive Site.
Hi Bill, Thanks for your quick reply.
To give you an update, since my post yesterday I managed to get offscreen
rendering working under windows, I am just about to test it under linux. It
is almost identical to the demo in the jav3d directory and I am about to
start adapting it to follow VisAD code more closely. It is quite rough code
at the moment but does work reliably. I should have something nice by late
monday. I will keep you posted on my progress. My current plan is to extend
VisADCanvas to use the java3d demo method of doing things. And pass this to
the constructor of DisplayImpl. I will then construct an OffscreenCanvas
(another extension of VisADCanvas?)
to do my offscreen rendering. My construction of DisplayImplJ3D will have to
change to reflect the extended Canvases.
DisplayRendererJ3D renderer = new DefaultDisplayRendererJ3D();
VisADCanvasJ3D onscreenCanvas = new MyCanvas(renderer, null); //extension of
VisADCanvas
display = new DisplayImplJ3D("display", renderer, onscreenCanvas); //to be
added to frame...
Has anybody used this type of construction before? If so what problems have
they run into?
> First, make sure there really is no way to raise your DisplayImpl's
> Component (returned by getComponent()) so it is not obscured.
>
I was hoping to avoid this because in some operating systems there are
windows that stay absolutely on top of every other window, (ie. task manager
in windows) and if a screen shot is obscured by another window and the
product goes to the public we will have some very unhappy campers on our
hands.
Our main problem is that the system will be running automatically taking
periodic screen shots and if there is a screen saver on or the monitor is
turned off our images will be very odd.
>
> This will be *much* simpler then trying to share a scene graph
> between two DisplayImpls.
>
I hadn't thought of doing it this way but we will still have the same issues
I mentioned above.
> > Another issue found was that when running the main() of VisADCanvasJ3D
under
> > linux we have only had the box and never got a field displayed. Whereas
this
> > has worked on windows. We get the same results for all linux and all
windows
> > configurations.
>
> I will look into this.
>
cheers, I think I have solved that problem, after checking the readme for
the java3d version on the linux box, I found the following line
*SNIP*
Linux-specific Bugs
-------------------
* Offscreen rendering does not work with NVidia drivers
*SNIP*
On finding this I downloaded and tested java3d 1.3. Both VisADCanvasJ3D and
my app work fine (very happy camper : ) )
> If you can't do either of these, I recommend taking the
> temprary memory penalty of a second, offscreen DisplayImpl.
>
At the moment that is our last option but it has some positives. These
include things like not having to make the user turn on or turn off the
various references required for a product. But as I was saying the memory
cost would be massive.
visad archives: