OpenGL + OS X

Hello everyone,

I should probably also post this question to the JOGL forum, but since Java3D now exclusively uses the JOGL pipeline this issue is relevant here:

It was brought up in an internal discussion that Apple may drop OpenGL support at some point - probably w/o warning.
But does it really matter for Java3D and other JOGL-based apps? Isn't it really a question of whether Nvidia, ATI and Intel don't compile OpenGL drivers for OS X?

Tom

Hi

As far as I know, even older versions of Java3D use JOGL under OS X, Java3D 1.6.0 and later aren't in a worse position than older obsolete versions.

Apple won't drop OpenGL support, simply because tons of softwares use OpenGL. If it did so, it would lose a lot of customers. Lots of companies don't want to maintain a completely separate code path for OS X, especially for non gaming softwares (CAD for example).

Java3D isn't a good choice for the future as no new features will be implemented (except a few things brought by some contributors). There won't be any new renderers relying on Metal and Vulkan in Java3D.

If there was no support of OpenGL, yes it would really matter for Java3D and JOGL softwares as JOGL is a Java binding for the OpenGL API, it's not magic: no OpenGL => no JOGL => no Java3D.

>Java3D isn't a good choice for the future as no new features will be implemented (except a few things brought by some >contributors). There won't be any new renderers relying on Metal and Vulkan in Java3D.
>If there was no support of OpenGL, yes it would really matter for Java3D and JOGL softwares as JOGL is a Java binding >for the OpenGL API, it's not magic: no OpenGL => no JOGL => no Java3D.

What about Ardor3D, will it have pipelines for JOGL, Metal and Vulkan?

Don't the graphics vendor supply the support for OpenGL and DirectX anyway?

Tom

Ardor3D != JogAmp's Ardor3D Continuation: the former was abandoned almost 2 years ago whereas the latter is still under development. JogAmp's Ardor3D Continuation already has a partial support of OpenGL ES, it is able to emulate the fixed pipeline thanks to JOGL when only the programmable pipeline is available which means that even its current JOGL renderer is more capable than the one of Java3D, it's particularly useful as some Macs support only OpenGL 2.1 and OpenGL 3 core without the ARB compatibility extension, it will be more useful with drivers supporting only OpenGL >= 3 core.

Phil talked about his new pipeline for Java3D, I agree with integrating his stuff as it would help Java3D to go on working in better conditions longer but if he gives up, I won't implement a brand new pipeline alone.

There is no point of maintaining tons of scenegraph APIs doing similar things; in my humble opinion, I would be more efficient if I could concentrate myself on fewer scenegraph APIs and if some contributors spent some time in maintaining their favourite ones which is exactly what is happening for LibGDX. As I don't want to favour any API by relying only on my own tastes, I prefer seeing some participations of other developers and I won't try to implement some features in some scenegraph APIs with very serious design flaws when I know that it's extremely hard or impossible to achieve, i.e I won't entirely rewrite Java3D to use directly JOGL canvases and windows and I will probably not allow JMonkeyEngine 3 to support multiple windows. There is no "perfect" API that would fit into everyone's needs:
- JMonkeyEngine 3 is modern, it is very actively developed, it has a huge community and a nice integrated game development environment but it's not the best bet outside gaming especially if you need something very reliable (some developers admitted that they have had to rewrite most build-in shaders for their projects) and supporting multiple windows. Note that it can't work with OpenGL < 2.1
- JogAmp's Ardor3D Continuation is less modern (written with the fixed pipeline in mind but supporting shaders and OpenGL ES), it is developed and maintained (less actively as I'm mostly alone), it has a tiny community but it is by far the most reliable scenegraph API supporting JOGL (the bugs are fixed within days or two weeks in the worst case), it has an excellent support of multiple windows, it's less suited for gaming than for visualization (it has some very useful utilities to write a visualizer including some manipulators and numerous loaders, ply and stl supports are on the way, it has a good OBJ exporter). It works with OpenGL 1.2 to 4.x
- LibGDX is less high level which is an advantage if you look for something lighter but it puts much more responsibility into the hands of the developer, it has a large community but as far as I know it can't work with old OpenGL versions like JMonkeyEngine 3
- Java3D has still a surprising huge user base with tons of examples on Internet but it can't work without the fixed pipeline for now and it has some important design flaws that none of the APIs above has because it was designed with Direct3D and OpenGL in mind instead of fully relying on JOGL

Metal doesn't get any hype in the Java community.

As far as I know, Vulkan support is vaguely planned in LibGDX (but improving OpenGL ES 3 support first is a priority) and JMonkeyEngine (not in the current major version, not a priority). I will improve the support of OpenGL 4 and OpenGL ES 3 in JogAmp's Ardor3D Continuation (not a trivial task) before supporting Vulkan.

Anyway, the JOGL backends of all those APIs will remain maintained. It seems to be difficult to merge JogAmp's Ardor3D Continuation into JMonkeyEngine as they have diverged a lot too much.

Yes the GPU manufacturers can provide the drivers but I'm not sure it would be possible if Apple prevented the install of OpenGL drivers somehow.

Hi Julien,

Thank you for this excellent background. Sorry I meant to say JogAmp Ardor3D Continuation. I'm a scientist and software developer here at the University of Wisconsin-Madison working on VisAD: https://en.wikipedia.org/wiki/VisAD. VisAD is a Java api primarily used in interactive scientific data fusion and visualization on workstation and laptop computers. It's the basis of many systems including Unidata's Integrated Data Viewer, Julien Chastang has posted here, VisBio (Curtis Rueden, now maintaining Java3d on MavenCentral), HYDRA (HYperspectral viewer for the Development of Research Applications), McIDAS-V and several others. Its dependent on Java3D so we have concerns going forward that it may become less stable or stop working all-together. To be fair, Java3D has proven extremely reliable to this point, as many of these system are deployed around the world on Windows, Linux and OS X. Mac is an extremely important platform as they've become the defacto standard for scientists and engineers at least in our domain, hence my questions on OpenGL and JOGL on OS X in the future.

Stability is an extremely important characteristic, for example HYDRA is used as a professional development tool for remote sensing scientists in seminars sponsored by NASA and NOAA, but it would be nice to begin to leverage new capabilities provided by the gpu via shaders. Currently VisAD renders via the fixed pipeline generating its own textures and geometry from science data which are passed to Java3D. We have our own marching cube algorithm to generate isosurfaces from 3D scalar fields, but Java3D doesn't handle depth sorting of semi-transparent triangles very well. We have texture-based volume rendering (first demonstrated by Bill Hibbard here in Vis5D) but it's slow and requires alot of memory - maybe a ray-casting approach is better. Would Ardor3D Continuation provide better capabilities here? But we also have needs for headless and off-screen rendering. If we can't stay with Java3D, I would prefer not to have to write our own scene api based on JOGL, but to start with something professional and contribute back to the community. My hope is that Java3D can be our base for the next 2 or 3 years while we possibly make a  transition.

Tom

ThomasR wrote

Would Ardor3D Continuation provide better capabilities here? But we also have needs for headless and off-screen rendering. If we can't stay with Java3D, I would prefer not to have to write our own scene api based on JOGL, but to start with something professional and contribute back to the community. My hope is that Java3D can be our base for the next 2 or 3 years while we possibly make a  transition.

JogAmp's Ardor3D Continuation supports headless and offscreen rendering with NEWT for sure, these capabilities were extensively tested by a contributor of a sub-project on headless screen captures named ardor3d-screenshot. runiter and Andreas have (partially?) migrated from Java3D to JogAmp's Ardor3D Continuation. I think that we can check whether it fits into your needs step by step. It's more flexible than Java3D but I can't promise you that it makes the coffee ;) Your hope seems to be realistic to me. In my humble opinion, it will give you some time to evaluate all options before migrating. I would prefer to have a clear winner... It's difficult to support both the fixed pipeline and the fully programmable pipeline which is what JogAmp's Ardor3D Continuation tries to do, there is no other engine doing that, it's promising but for now, it means that it's technically "behind" JMonkeyEngine.

Does NEWT provide a full windowing toolkit: frame, buttons, sliders, layout, etc?
Does NEWT run on embedded devices: iOS and Android. If I write a gui with NEWT
Can I run it on a Windows desktop and an iPad? Do you have any sense of stability?
We can still see crashes on OS X with Swing and Java3D, usually in a thread that's
entered the native layer via JOGL.

NEWT is a windowing toolkit, not a GUI toolkit. There is an API in JOGL for GUI widgets (buttons, sliders, ...) but it requires shaders and I don't see a lot of developers using it. You can find some GUI toolkits in some engines with JOGL backends except Java3D.

NEWT supports Android but there is an important lack of documentation on this aspect.

NEWT doesn't support iOS and there is no plan of changing that. It's a very constrained environment. I remind you that there are a very few Java APIs supporting iOS, even JavaFX doesn't support iOS flawlessly out of the box yet.

NEWT works under GNU Linux, OS X and Windows too. You're not accurate enough about OS X. Numerous end users still run the obsolete Apple JRE, even Apple discourages its use, JogAmp isn't responsible for poor OpenGL drivers even though we do our best to work around some driver bugs (see our GL quirks), I remind you that Java3D 1.3 + JOGL 1 are still installed by default under OS X 10 which can cause some conflicts and crashes with Java3D 1.6 but not with Java3D 1.7.0 and Swing isn't part of JOGL, it's part of the Java standard API. Feel free to provide some complete test cases to reproduce those crashes under OS X, feel some bug reports and we'll see what we can do.

Thank you for the clarification and background on NEWT.

gouessej wrote

You're not accurate enough about OS X. Numerous end users still run the obsolete Apple JRE, even Apple discourages its use, JogAmp isn't responsible for poor OpenGL drivers.

My apologies, I thought the Apple was completely done with Java starting with Mavericks. I understand JogAmp is not responsible for drivers, but I didn't know that Nvidia, AMD don't supply drivers for OS X like they do for Windows and Linux.

gouessej wrote

I remind you that Java3D 1.3 + JOGL 1 are still installed by default under OS X 10 which can cause some conflicts and crashes with Java3D 1.6 but not with Java3D 1.7.0

Even if an app bundles Java,Java3D and JOGL? Perhaps the crashes will cease if I convert to Java3D 1.7.0. I had crashes on OS X with Java3D 1.6.0pre12 using jogl2.3.1, but when I switched to 2.3.2 the problem went away.

Thomas,
You don't even need to bundle Java, just Java3D and Jogl.

But you have to disable the ext folder Java3D.

Which is done by putting this
-Djava.ext.dirs=.\none\
into the Java arguments, it's simple and it works every time.

However the catch it you can't use any other extension like Java Media Framework.

Though I've never met a Java app that didn't bundle the extension it wanted to use, so I feel that it's not a strong reason not to disable the ext folder.

If you MUST have ext enabled you can do the following if you trust your users a LOT.

public static boolean checkForInstalledJ3d()
        {
                // check for java3d installed
                String extProp = System.getProperties().getProperty("java.ext.dirs");
                if (extProp != null)
                {
                        ArrayList<File> preinstalledJ3dJars = new ArrayList<File>();
                        String[] paths = extProp.split(ps);
                        for (String path : paths)
                        {
                                File folder = new File(path);
                                if (folder.exists() && folder.isDirectory())
                                {
                                        File[] listOfFiles = folder.listFiles();
                                        for (int i = 0; i < listOfFiles.length; i++)
                                        {
                                                if (listOfFiles[i].isFile())
                                                {
                                                        if (listOfFiles[i].getName().indexOf("j3d") != -1 || listOfFiles[i].getName().indexOf("vecmath") != -1)
                                                        {
                                                                preinstalledJ3dJars.add(listOfFiles[i]);

                                                        }
                                                }
                                        }
                                }
                        }

                        if (preinstalledJ3dJars.size() > 0)
                        {
                                String mess = "There appears to be some pre installed Java3d files.";
                                mess += "\nThey need to be removed (moved or deleted), otherwise this application will almost certainly fail.";


//Possibly just for fun try and delete the file for them too!
                                for (File jf : preinstalledJ3dJars)
                                {
                                        mess += "\n" + jf.getPath();
                                }
                                System.out.println(mess);
                                int result = JOptionPane.showConfirmDialog(null, mess, "Pre installed Java3d detected, do you want to attempt deletion?", JOptionPane.YES_NO_OPTION,
                                                JOptionPane.WARNING_MESSAGE);
                                if (result == JOptionPane.YES_OPTION)
                                {
                                        boolean success = true;
                                        for (File jf : preinstalledJ3dJars)
                                        {
                                                boolean fileIsNotLocked = jf.renameTo(jf);

                                                System.out.println("jf " + jf + " " + fileIsNotLocked);
                                                success &= jf.delete();
                                        }
                                        JOptionPane.showMessageDialog(null, success ? "Success!" : "Failed, please remove manually and restart");
                                }
                                return true;
                        }

                }

                return false;
        }

Phil,

We don't want our users to have to do anything, so we use Install4j and bundle everything. Don't have
to worry about Apple's crappy Java and Java3D implementation with which we had so many problems.

Tom

As long as you use a JRE with support of the extension mechanism (Java < 1.9), you can still have some troubles but as we renamed some packages in JOGL (before doing the same in Java3D), it happens a lot less.

Actually, some end users go on reinstalling the Apple JRE to work around some limitations/bugs in the detection of the Java plugin but it causes much more problems...

Phil, I wrote in my tutorial that "disabling" the extension mechanism can have some nasty side effects, it breaks some features including NIO2 ZIP support. You should look at Emmanuel's source code, he creates a custom class loader. The best solution consists in bundling Java 1.9 as it has no extension mechanism :)

P.S: I use JNDT which isn't a proprietary black box with numerous limitations...

All,

Thank you for the very interesting thread.

I just want to add Apple has not updated OpenGL in years. It is at version 4.1 back from 2010. It seems to be effectively deprecated (though not officially so), and Apple is implicitly favoring Metal and perhaps now Vulkan (that remains to be seen). But it  appears clear Apple is tacitly discouraging use of OpenGL.

Please read “OpenGL: Still lagging behind”

All that said, it is possible OpenGL will exist on OS X in a semi-moribund state indefinitely (kind of like Java 3D) especially given the number of applications that depend on OpenGL on OS X. Or not, I just don’t know. Apple did away with Carbon, but you can still find the Apple Java 6 JRE several years out now.

I also want to echo Tom’s comments that the scientific software community operates on shoestring budgets, and we simply don’t have the resources and infrastructure to do huge, wholesale refactors. If we must make big changes, we must have a rock solid understanding of what will be supported in the future for many years.

Thank you to all those who keep Java 3D going.

Julien C.

Julien wrote

I also want to echo Tom’s comments that the scientific software community operates on shoestring budgets, and we simply don’t have the resources and infrastructure to do huge, wholesale refactors. If we must make big changes, we must have a rock solid understanding of what will be supported in the future for many years.

That's why I'm very careful and I worked in a subsidiary of a scientific research institute, I know what you're talking about.