Off-Screen Canvas3D
Can an off-screen Canvas3D object (to be used for saving an image to a file) be instantiated without instantiating a separate on-screen one? If so, is there any special setup needed to render it to a buffer. (I am using the standard setup which includes (in part) the specifying of Screen3D parameters and ImageComponent object for the buffer, associating the canvas with a View object, creating the scene, and attempting to render the canvas, at which point I get an internal exception (OpenGL and Thread references) and a core dump.) If not, is there any way to prepare the off-screen canvas without having the on-screen one realized via a JFrame.show? So far, I have to realize the on-screen canvas, synchronize and wait for its thread to complete postSwap processing before rendering the off-screen canvas to save its image to a file.)
I tried to keep this inquiry short, but will supply additional detail/code to clarify any of the above. As noted above, I have had some success in capturing an image for saving it to a file, but need to be able to save the image without displaying it. BTW, the image is not animated.
Any help would be appreciated. Thanks.
[1181 byte] By [
stmoss] at [2007-9-30 19:57:39]
Hi stmoss,
Based on the description under
http://www.btconsulting.ch/paper/java3d/java_3d_samples_main.htm
you can download the related sample zip-file.http://www.btconsulting.ch/btc3ddemo.zip
> Canvas3D in offset mode, no Jframe, no postswap, no on-screen-mode but simple server side coding.
The example is based on a JSP where a J3D-scene is returned to a browser but basically you can use the code also outside a web server and as a standalone process.
II also tried the code under WEB-Services, J2ME-server-side and EJB's (behind a J2EE-Application-Server) and it works fine as well.
Hope this will help you....
BTW. The issue of Hardware (and your other posts on offscreen) is of course (unfortunately) still valid here. On the other hand I now tested and used the above mentioned code (as a first environment check) on quite a number of environments and never had particular problems except for the hours spent in looking for (and installing) drivers for a specific hardware environment.
I don't count the number of JVM-Crashes and Core-Dumps anymore and believe me, never had to change a byte of Java but rather system configuration and drivers...
Hi Fabini!
I figured that, if anyone would respond to my query, it would be you. Thanks!
I looked at your utilities, especially BTC3DSimpleServerAdapter.java, and your document. Basically, it looks like my application of the Canvas3D methods for off-screen rendering is similar to yours. (Of course there may be nuances that I am not taking into full account.) However, your code inspired me to create an extension class of Canvas3D (separate from my Java3D class) and to move off-screen processing outside of my Swing (JFrame) class.
At the risk of being a bit long-winded, I will attempt to briefly describe my general program and my latest results (some of which may sound familiar). (Also, this may help to better inform others of my problem.)
In a Java virtual machine driver (launched from a C++ wrapper program), a loop is executed in which commands from a UNIX session window are read and processed. If a DRAW command is executed, then a method associated with the driver collects the required data and either calls a display method (from an extension class of JFrame) or it calls my Java3D class constructor to create and retrieve an off-screen Canvas3D object, from which object the image saving method is invoked. (My Java3D class constructor is also called by my JFrame display method.)
If the display option is invoked prior to invoking (via another command) the image saving option, image saving works. (Print statements within the code indicate that the canvas objects are different, which is good. See below.) However, if the image saving option is invoked first, I get a "glversion == null" statement upon the call to renderOffScreenBuffer with processing hanging up at waitForOffScreenRendering. (So I am back to where I began.)
I have come across two interesting points, which may or may not have any bearing on my problem. First, when I do a System.out.println on one of my Canvas3D extension objects, the output is of the form:
[canvas#,x,y,wxh,invalid] ==> e.g., [canvas1,0,0,720x720,invalid]
where canvas# is the object identifier, # is an non-negative integer, x and y are the image's upper-left corner location (via setLocation), and wxh is the image's size (via setSize). The purpose of the term "invalid" eludes me. However, during the course of displaying an image, the on-screen canvas output will lose the invalid term, e.g., [canvas1,0,0,720x720], after my JFrame object is pack'ed and show'n. (Note, even after an off-screen canvas image is successfully saved, the canvas' output retains the invalid term.) Second, in the scenario where I display an on-screen canvas before saving a different off-screen canvas, the properties of the prior on-screen supersedes those of the off-screen one. (Note, my Java3D class uses one and only one canvas, and I also invoke my Java3D constructor whenever I create an image/canvas.) As a illustration of this, if I first request an on-screen image to fill one-quarter of my 720x720 JPanel object (contained in the JFrame object), followed by a request to save an off-screen image of size 720x720, then I will find my Canvas3D objects will have the following System.out.println output:
[canvas0,0,360,360x360,invalid] // first canvas (on-screen) after construction
[canvas0,0,360,360x360] // after invoking JFrame.show()
[canvas1,0,0,720x720,invalid] // second canvas (off-screen) after construction
[canvas1,0,0,720x720,invalid] // after image is saved
The saved image is, for the case above, only the lower-left quarter of itself, i.e., its size, location, and partial content (not image) corresponds to the properties of the previous on-screen canvas.
I have used the Canvas3D method queryProperties, and I have found some differences between the on-screen and off-screen canvases, but none that I can use to resolve the problem. (E.g., the difference between an on-screen canvas followed by an off-screen one is doubleBufferAvailable = true --> false, which is to be expected. If an off-screen canvas is requested first, then, using the previous case on-screen canvas properties as a reference, the differences are doubleBufferAvailable = true --> false (as before), various texture properties [e.g., texture3Davailable = true --> false, textureColorTableSize = 256 --> 0, and textureWidth(Height)Max = 4096 --> 0], and (perhaps most telling) native.version = 1.2 Sun OpenGL 1.2.2 for Solaris -->[ i.e., no value].)
I am continuing to investigate this problem and am willing to supply addition information upon request. Again, sorry about the length of this note, but I wanted to clarify my situation as best as possible without listing code.
Thanks in advance to you or anyone who can contribute to resolve this problem.
stmoss
P.S. I am still waiting for system updates. (Cf. topic "More Re: Off Screen Rendering".)
Well....
I keep tuned till you fix it... since I am somehow also waiting until you will post a success on this.
I am not an opengl specialist but...
glversion == null
is produced, as far as I could understand, when the opengl engine is not (yet) initialized. Since your code works when the display option is used first, there must be a difference in this direction.
The question is if by calling the code from C++, maybe you also need to invoke an opengl
(or X-Windows) initialization statement (or set an environment variable) first in order to initialize the graphical engine (which may implicitely occur when you invoke display first). Are you by the way
running your sample from the shell or behind X-Windows ?
As I already mentionned once, I suddenly also got the "glversion == null" error on J3D after having played with opengl settings on a linux configuration. I actually changed the opengl libraries at that time and probably an environment variable pointing to a wrong library was the issue.
Question: Have you also tried my sample code (as is) behind a webserver on your environment ?
It would be an indication if you can see the cube on a browser or not or if you get the same error.
If you don't have a Web-Server (like Tomcat) avalable I also have a fully standalone version of the sample using Jetty (i..e you start a simple unix shell and the J3D server sample is on).
I may also post this option sometime on my homepage but... time is these days quite short....
I keep tuned....
Regards
Fabio
This is my last (I hope) missive on this topic. The problem that I was having with rendering an off-screen Canvas3D image (see my previous inquiries on this subject) was found to be due to the color-depth setting on my SunBlade 100 workstation. Apparently when the workstation was originally setup, the color-depth was set to 24-bit. It took a system administrator to remotely reset the workstation to 32-bit color-depth. (I was told that I could not have done this reset from any workstation control panel.)
I hope that my experience on and resolution of this matter is of help to others. I would like to thank all those (especially fabio) who at least took the time to read about my trails and tribulations on this subject. Finally, a last commentary (i.e., informational gripe) aimed toward Sun:
Couldn't Sun provide better documentation or help regarding a workstation's requirements and setup for Java3D? In particular, on my workplace's UNIX system:
(a) Sun's README notes for installation of Java3D had no reference regarding the color-depth setting.
(b) The messages "glversion == null" and "glXMakeCurrent fails" from a Canvas3D object's renderOffScreenBuffer and (first reference of) queryProperties, respectively, were not helpful and difficult (I never succeeded) to capture.
Better information would have saved me many months of fruitless efforts and frustration.
stmoss
