Texture2D and offscreen rendering problem

Hi all,

I have a simple JFrame displaying a Sphere with a Texture (Appearance.setTexture) with a Canvas3D
When I add an offscreen Canvas3D to save a picture, the texture is displayed as a background of the image.

Does someone has the same issue?

It was working on java3D 1.5.2, I did not test it with previous jogl/gluegen/java3d releases but I will do it soon.

Test was made with jogl 2.1.2, java3d 1.6-pre8

Regards,
Laurent.

jimmypag wrote

Hi all,

I have a simple JFrame displaying a Sphere with a Texture (Appearance.setTexture) with a Canvas3D
When I add an offscreen Canvas3D to save a picture, the texture is displayed as a background of the image.

Does someone has the same issue?

It was working on java3D 1.5.2, I did not test it with previous jogl/gluegen/java3d releases but I will do it soon.

Test was made with jogl 2.1.2, java3d 1.6-pre8

Regards,
Laurent.

Please re-try with the -pre9 uploaded here:
http://jogamp.org/deployment/java3d/1.6.0-pre9/

Hi

jimmypag wrote

It was working on java3D 1.5.2

Is it still working now with Java3D 1.5.2? Please follow Xerxes' advice. I have to clarify something. As Java3D 1.5.2 and Java3D 1.6 share most of the source code, I know that a few regressions might have appeared when switching to JOGL 2 especially on platforms that used the legacy native renderer but I know that some bugs that we observe with Java3D 1.6 are still reproducible with Java3D 1.5.2 but some developers are unable to deploy the latter nowadays and tested it several years ago whereas Java itself (especially AWT and Swing) has changed since the time Oracle gave up Java3D.

Emmanual has seen a very similar bug with Sweethome3d, I'm not sure at this time where it is coming from...you aren't
sharing your texture 2d objects between different VirtualUniverses by chance?  That seemed to provoke the bug.

Harvey

Thanks for your answers.

Unfortunatelly, I have only one virtual universe.

I tested the app on java3D 1.5.2, it works!
Then I tried with java6 pre6 and pre9 without success.
You can see on the pictures the problem.

test case with java3D 1.5.2: OK

test case with last jogl and j3d 1.6, win7 x64: NOK

Scene only painted on a the texture size area

Here is my test code:

J3dOffscreenTestCase.java


Laurent.

Thanks a lot for the test case, I'll try to have a look this week.  I'm assuming this bug only hits you when rendering offscreen?

If you put this onscreen it works acceptably?

Harvey

 
   
 
 
    Yes, with onscreen is OK.
     
      The app shows the scene onscreen with a Canvas3D in a JFrame.
      There's a menu "save image" to get scene to disk and this is where
      the renderer draws the texture on background.
     
      Laurent.
     

       
     
     
   
   
 

Offscreen capture is working on a mac OSX 10.7.5.

Hi Harvey, did you had time to look at this problem?

Thanks,
Laurent.

Have you tested with Java3D 1.6 pre 9?

Yes, and the same problem occurs.
I tested it with last jogl build: gluegen_761-joal_511-jogl_1200-jocl_903.

I'm afraid I haven't had more than a few minutes here and there to poke at this, no progress to report.

I will of course announce here when I manage to track this down....I have a feeling it comes down to the initial
MacOSX offscreen work August submitted, now I actually have to go understand that stuff!

Harvey

Hi harvey,

I never tried to build jogl nor java3d but I could try to dig in it if you tell where to search for this macosx offscreen stuff.

Laurent.

In Java3d - javax.media.j3d.JoglPipeline

methods:

- resizeOffsreenLayer
- createNewContext
- createOffscreenBuffer

Note in the above: the 'offscreen' argument is Java3d's concept of if the Canvas3D is an offscreen Canvas3D or not, there
is a separate concpet of offscreen for the actual drawable used (On MacOSX, the drawables always seem to be offscreen)

The pipeline classes essentially implement all kinds of callbacks for the Canvas3D object, I'll warn you up front that this
code is a mess.  Any and all help/experiments appreciated!

Harvey

Hi Harvey,


I got sources from git, put them in netbeans and tried to understand something.
But as pipeline is just a bridge, it's quite hard to figure out all the rendering process.

What I just found it is that if I revert changes in createOffScreenBuffer to before february commit of August changes, offscreen works again (deprecated pbuffer used instead of new methods and FBO).

At least it's a start.

Edit:
just replacing

        GLDrawable offDrawable = GLDrawableFactory.getFactory(profile).createOffscreenDrawable(device, offCaps, null, width, height);

by

        GLDrawable offDrawable = GLDrawableFactory.getFactory(profile).createGLPbuffer(GLDrawableFactory.getDesktopFactory().getDefaultDevice() ,offCaps, null,width, height, GLContext.getCurrent());

does the trick but createGLPbuffer is deprecated so we have to find another solution or dig into jogl sources ?

Laurent.

Please make a request for enhancement to reintroduce the support of PBuffer but in a cleaner API. I have a similar need in Ardor3D. However, we may have to add some options to force the use of pbuffers in some cases. In my humble opinion, August's code isn't wrong. Have you tried to use the default device when creating the FBO?

On the FBO, the device variable is initialized to default device so there is no change.
Using pbuffer method introduces other problems like width/height scale and maybe other.
I'll checkout jogl sources to see differences between the two methods.

Laurent.

On 02/10/2014 10:16 AM, gouessej [via jogamp] wrote:
> Please make a request for enhancement to reintroduce the support of PBuffer
> but in a cleaner API. I have a similar need in Ardor3D. However, we may have
> to add some options to force the use of pbuffers in some cases. In my humble
> opinion, August's code isn't wrong. Have you tried to use the default device
> when creating the FBO?

GLDrawableFactory's createOffscreen(..)'s GLCapability argument well determines whether
the underlying offscreen is a bitmap, pbuffer or fbo.
Same goes with createOffscreenAutoDrawable(..).

<http://jogamp.org/deployment/jogamp-next/javadoc/jogl/javadoc/javax/media/opengl/GLDrawableFactory.html#createOffscreenDrawable%28javax.media.nativewindow.AbstractGraphicsDevice,%20javax.media.opengl.GLCapabilitiesImmutable,%20javax.media.opengl.GLCapabilitiesChooser,%20int,%20int%29>

~Sven

Do you plan to remove the support of pbuffers on the long term?

On 02/10/2014 11:14 AM, gouessej [via jogamp] wrote:
> Do you plan to remove the support of pbuffers on the long term?

No, but the deprecated pbuffer-only methods shall be removed.
Hence pbuffer will be always available via said methods where available.

~Sven