Java3D + OpenGL ES

Can Java3D work with only the ES subset of OpenGL? Is there a way to test?

Phil is working on that in the version 1.7.0 but I don't know the exact state of his work.

Java3D 1.7 has the newer OpenGL profile support.

It continues to support the same fixed function pipeline (with basic shader support) as Java3D1.6 and will default to that rendering system when used.

If it is given the property System.setProperty("j3d.rend", "jogl2es2"); then it will use it's newer pipeline that uses the GL2ES2 profile.

It will then map all of the Java3D scene graph elements across to the shader system automatically. It also has a new sub class of ShaderAppearance called SimpleShaderAppearance, which allows all current Shape3D Appearance structures to automatically build reasonable basic shaders incorporating the attributes of the appearance.

It also automatically checks for some features that are not backward compatible (like VAO use) and uses the correct structure for the profile it is given.

To answer the question, in Java3D 1.7 you are free to use any shader functionality that's supported by the OpenGL system your GPU supports, but you will be significantly constrained by the way that shader attributes are loaded into the shaders from the Java3D pipeline.

The OpenGL profile is encapsulated in the pipeline and removed from access by design in Java3D and I can't think of (off the top of my head) any OpenGL 3 or 4 functions that an implementation using Java3D 1.7 would want to use but be unable to use because of the profile requested (profile = GLProfile.get(GLProfile.GL2ES2);).

The design requirement for GL2ES2 support in Java3D was to get it running on ES devices rather than to leverage teh power of the newer features of OpenGL, and given that Vulcan is here that will probably be the next thing to get support in Java3D rather than OpenGL3+

I hope this helps, please do ask any more questions so I can give a clearer answer.
Phil.

Thanks for the detailed reply!

I was considering experimenting with the trial version of MoltenGL, but it currently only supports OpenGL ES (They may have plans to implement full OpenGL in the future). We make heavy use of probably all of Java3D's capability, so there's no point in trying if ES alone won't support everything in Java3D.

What exactly does GL2ES mean?

Thomas,
I wasn't too clear I think, Java3D itself doesn't allow users to take advantage of advanced OpenGL features easily, but Java3D 1.7 on the ES pipeline supports nearly everything that Java3D 1.6 supports, and the advantage of being able to easily write shaders is very useful
The following are limitations:
1. Coordinates must be defined and float type, colors must be float type, if defined.
2. Decaling is not supported.
3. Model Clip is not supported and must be reimplemented in shaders
4. QuadArray or IndexedQuadArray cannot be supported.
5. Texture Lod, Filter, Sharpen and Combine cannot be supported.
6. Texture3D cannot be supported.
7. RasterOps from RenderingAttributes cannot be used.
8. ReadRaster for depth requires a custom shader and color read instead.
9. Note LineArray and LineStripArray will not render as nicely as the fixed function pipeline.

The SimpleShaderAppearance class will let you print out the resultant shader from a given set of attributes, so for most features an example shader can be seen.

1. Coordinates and colors in float is not a major change usually (if at all)
2. Decaling can be done in the shaders, SimpleShaderAppearance won't output an example
3. Model Clip needs to be implemented in shader and its a fiddly piece of work if needed, SimpleShaderAppearance won't output an example
4. QuadArray to Triangle array is normally trivial (just update the coordinate index to point at 1,2,3,1,3,4 instead of 1,2,3,4)
5/6. The texture features mentioned and Texture3D are old system that aren't needed anymore, just dump them.
7/8. RasterOps can all be done in shaders more nicely, SimpleShaderAppearance won't output an example

So in my experience of converting across, the Quad array index updates are required fairly often (particularly on any billboard type geometry) and the LineArray not rendering nicely makes stencil outlines look fairly rubbish.

I'm very happy to given more specific advice if you can point me at code examples that need updating.

GL2ES2 is one of the compatibility profiles that Jogl will return when requested.

This profile will allow you to call any of the GL2 functions calls as well as any of the OpenGL ES2 function calls on the profile and Jogl sorts out in the background how to make calls on the device driver.
In this post
http://forum.jogamp.org/What-profile-to-choose-tp3575514p3575561.html 
Sven covers the the concept in more detail.

Thanks Phil,

LineArray and LineStripArray not rendering as nicely might be an issue depending how it looks.

Here's a code snippet showing our use of Texture2D:

    Texture2D texture = new Texture2D(Texture.BASE_LEVEL, getTextureType(new_image_type), current_image.getWidth(), current_image.getHeight());
     ImageComponent2D image2d = new ImageComponent2D(getImageComponentType(new_image_type), new_image, true, true);
     image2d.setCapability(ImageComponent.ALLOW_IMAGE_WRITE);
     image2d.setCapability(ImageComponent.ALLOW_IMAGE_READ);
     texture.setImage(0, image2d);
     texture.setMinFilter(Texture.BASE_LEVEL_POINT);
     texture.setMagFilter(Texture.BASE_LEVEL_POINT);
     tile.setImageComponent(image2d);
     TextureAttributes texture_attributes = app.getTextureAttributes();
     texture.setEnable(true)
     app.setTexture(texture)

I would have to determine the impact of not have the minification/magnification filter

We make heavy use of (From the original Java3D doc) for efficiency:

public ImageComponent2D(int format,
                        java.awt.image.BufferedImage image,
                        boolean byReference,
                        boolean yUp)

Constructs a 2D image component object using the specified format, BufferedImage, byReference flag, and yUp flag. The image class is set to ImageClass.BUFFERED_IMAGE.

Parameters:
format - the image component format, one of: FORMAT_RGB, FORMAT_RGBA, etc.
image - the BufferedImage used to create this 2D image component
byReference - a flag that indicates whether the data is copied into this image component object or is accessed by reference
yUp - a flag that indicates the y-orientation of this image component. If yUp is set to true, the origin of the image is the lower left; otherwise, the origin of the image is the upper left.

Tom
                       

From that thread you suggested:

/** The intersection of the desktop GL3, GL2 and embedded ES2 profile */
public static final String GL2ES2 = "GL2ES2";

So this means that there's some common set of capabilities from GL3,GL2 and ES2 that are supported, but that some capabilities from each of those profiles may not be supported? I think the current version of MoltenGL would be an ES2 only profile, but I can't say that for sure.

Yes it's the intersection, and given that Java3D 1.6 was the GL2 spec you can see that the items I listed above are the features of ES2 that are removed by going to GL2ES2.

However I need to update that list a little as it was written early in the development and I've since updated the mip-map support.

The mip-map system for ES2 is "auto generated only" meaning that if the chip is ES2 then a Texture2D will only use the 0 level ImageComponent2D. My first cut of support didn't include mip-map generation so the Lod clamp and min/max filter did nothing. (And I incorrectly labelled them, along with Texture3D old and out of date above).  
Java3D 1.7 now does create mip-maps for ES2 chips, and therefore the Lod and min/max filters are back in play and work fine.

Java3D 1.7 does not support Texture3D, even though it's in the spec, I simply haven't put that support in yet.
Sharpen and combine aren't support and will never be.


For the list of ES2 features this is easy to read, and gives a semi-comparative with GL2
https://www.khronos.org/files/opengles_spec_2_0.pdf

For the example code you've given it will run with Java3D as it is, it is very similar to code I use right running on both Desktop and Android. However somewhere along something required me to use yUp = false, but I didn't get the inefficiency the efficiency doc suggested, right now I can't see why that is, and I can't recall what changed.

You may have to simply try it and see, but if yUp is required then a simple BufferedImage.createGraphics().drawImage with vertical flip transform would allow it to be set to true again, of course this may have all sorts of other negative effects depending on your code.

Phil.

For some reason, if yUp != true a copy was always made before rendering.  Perhaps that is no longer the case. In fact, byRef=true and yUp = true works so well, we have to be careful with the reference to the image data (you can see a change in the displayed image by changing the values of the backing byte array!)