We have a program that relies on Ardor3D, which has worked fine until recently on some of our computers. Not sure what triggered the problem. But here is the stack trace. Any idea how to fix this?
Caused by: java.lang.reflect.InvocationTargetException
... 6 more
Caused by: com.jogamp.opengl.GLException: Caught RuntimeException: com.ardor3d.util.Ardor3dException: Error in opengl: invalid enumerant on thread AWT-EventQueue-0
at java.security.AccessController.doPrivileged(Native Method)
Caused by: java.lang.RuntimeException: com.ardor3d.util.Ardor3dException: Error in opengl: invalid enumerant
... 25 more
Caused by: com.ardor3d.util.Ardor3dException: Error in opengl: invalid enumerant
... 30 more
Caused by: com.jogamp.opengl.GLException: invalid enumerant
... 34 more
It's not a problem specific to JogAmp's Ardor3D Continuation or JOGL. Some GPU manufacturers (including Intel) provide some OpenGL drivers that stop working under Windows 10 after some Windows updates and fall back to the crappy Microsoft GDI renderer supporting only OpenGL 1.1. Providing such drivers allows to avoid preventing people to switch to Windows 10 even though the manufacturer plans to drop support of its GPU but at the end, you just get unacceptable performance with softwares that claim to be "Windows 10 ready". The easiest workaround I know consists in using an older version of Java 1.8 that doesn't claim to be "Windows 10 ready" so that the driver provided by the GPU manufacturer goes on working.
Another possible root cause is another (unintentional) driver bug. Then, try to use an older version of this driver.
Ardor3D and JogAmp's Ardor3D Continuation are two distinct projects with two distinct agendas that have taken two distinct directions. Personally, I go on copying the fixes of Ardor3D into JogAmp's Ardor3D Continuation but the fixes of JogAmp's Ardor3D Continuation don't get ported to Ardor3D. I know that surprisingly Joshua Slack seems to work anew on the legacy Ardor3D, this is something that I didn't expect as he announced several years ago that he had decided to give up but now, the projects have diverged enough to make it impossible to work together. For example, I dropped the renderer based on an API not maintained by JogAmp and I've been trying to drop Google Guava for years, it drives the merges a bit painful. I implemented some importers whereas Josh wanted to concentrate on Collada, I drove some behaviours a lot easier to override, ... I'm very grateful for his excellent work but I don't want to revert my changes. It's not black or white, our respective decisions make sense in a certain context, I respect his work but I don't expect any cooperation between us now. We made almost 200 commits since Josh left the boat.
We are seeing more and more users cannot run Ardor3D because of this bug. For example, we have a whole school that could not run our Energy3D program on brand new Windows computers. Perhaps Joshua has fixed some of the issues, I am hoping? I suspect that not all bugs can be attributed to driver incompatibility.
I suspect that not all bugs can be attributed to driver incompatibility.
Which bugs are you talking about? Please try to run the program using JogAmp's Ardor3D Continuation with an older OpenGL driver or an older version of Java. I don't try to find a false excuse not to look for a fix, there's just nothing to fix in JOGL and JogAmp's Ardor3D Continuation as they aren't to blame. You wrote "The software worked fine just a couple of weeks ago on the same computers", that's why I suggest you to use an older OpenGL driver or an older version of Java, in order to put yourself into the same conditions than a couple of weeks ago when it was working. I know that some end users don't like to change such things but there is nothing to fix in our APIs, the bug is elsewhere.
N.B: Reminder: Ardor3D != JogAmp's Ardor3D Continuation
I'm not responsible for Ardor3D, I'm responsible for JogAmp's Ardor3D Continuation.
Thanks for your help. I was talking about the same bug as well. The installer has used a Java 8 JRE in the last few months. When it stopped working, I didn't change the installer. And this happened with a computer here that has installed the program before. But all of a sudden, it stops working. I initially suspect it was a Windows update that caused it. But I can't reproduce it on my own computer.
Actually, I don't even know whether the installer provides a separate JRE for the software or if it relies on the JRE installed on the system. If it's the latter, an update of this JRE might have broken Energy3D.
Microsoft has changed, some Windows updates force WebGL to use the software fallback instead of the hardware acceleration, such a similar option shouldn't be excluded for OpenGL too. Please can you tell me exactly which JRE you use with Energy3D and which graphics card or integrated chipset?
We rolled back some of the recent updates on the affected computer and are now looking at each update one by one in hope to nail down which of the updates screwed up. There have been some updates, including one from Adobe Flash Player, since July 4 (before which Energy3D worked fine on the computer). I suspect it could be the Adobe update that broke it. I will let you know if we can confirm this and then we can figure out why.
We found that the problem was caused by Intel HD Graphics 530. After disabling it, Energy3D worked fine again. So we went on to update the driver using the Device Manager of Windows 10. It turned out that Intel just released a new update yesterday and it fixed the problem!
A bit more information about the problem we were having. I believe it was caused by an Intel update in early July (or June), which was included in a Windows 10 update. After the OS update, Energy3D stopped working properly. Intel probably became aware of this bug they created as many people must have complained about it. So they released another update on July 11 that righted the wrong. Now, for the problem to go away for everyone, we probably have to wait for the Intel update to be included in a future Windows 10 update.
Not all driver updates are good!
PS: In order to remind the user of this problem, I added a check in Energy3D to catch this particular exception and then prompt the user to update the driver. I suppose other people may want to do the same thing as we don't know for how long people have to wait for the Intel update to be delivered.
Yes it's a good idea. I even have some code that fixes some values returned by some drivers that lie about their capabilities, I understand your position. When I detect Microsoft GDI renderer, I tell the end user to install a real driver and when something goes wrong, I display both the stack trace and a message to the end user telling her/him to update its driver as it might be the cause of the issue.