How to run Java 3D 1.6 under old Intel processors with integrated graphics?

Hi,

Some Sweet Home 3D users reported they can't run this Java 3D 1.6 program under Windows 10 64 bit with recent versions of Java 8.
It looks like that they are generally using a computer with an old enough Intel processor with integrated graphics.
At the moment, the only way to fix this issue is to run the program with Java 3D 1.5.2 in 32 bit mode.
Would anyone be aware of some Java or Java 3D options that could avoid this solution?
Or at worst, does anybody know how to detect the family of the graphics card used on a computer, so the installer of the program can automatically choose Java 3D 1.5.2 and Java 32 bit, even if the computer is running under 64 bit?

Thanks for your help...

Hey

I know this problem, we already mentioned it several times in this forum. Some machines are allowed to migrate to Windows 10 whereas Intel plans to drop the support of their chipsets, the driver is available but just crashes with a software detected as Windows 10 compliant (which is the case of the most recent updates of Java 1.8). This problem affects all Windows 10 compliant OpenGL softwares, not only Java3D.

Your end users should install this shim:
https://communities.intel.com/servlet/JiveServlet/download/523544-180582/legacy-igpu-x64.zip
Note that it makes Minecraft work anew ;)

Yes it's possible to detect the family of graphics card by using JOGL but if you use Java3D 1.5.2, you'll face some unfixed bugs in the context creation. You'll have to drop Java3D 1.5.2 in order to use JOGL 2 without any risk of conflict. If your installer runs with enough privileges, it could suggest the end user to download and install the shim, it's not ideal but it's better than nothing.

I appreciate your effort to satisfy your end users. However, sometimes you'll have to advise them to buy "better" hardware or to use an operating system not encouraging planned obsolescence. I know that it's not pleasant, I'd prefer to have a clear situation, either OpenGL is supported or it isn't, not what Intel does, i.e it's supported only to migrate and it intentionally leaves a broken driver after the migration. The GPU manufacturers are to blame.

Thanks for your answer

At the moment, when this problem arises, Sweet Home 3D runs with Java 8 64 bit and Java 3D 1.6. I want to propose to users to run legacy-igpu-x64.zip but only if it will be helpful. If I add a RenderingErrorListener to VirtualUniverse, do you know what errorCode, errorMessage and/or other attributes I should get in the RenderingError that will be returned? I don't have any computer at my disposal with this issue, so it's difficult for me to guess.
If using RenderingError data is not a good idea, how can I detect the issue with JOGL classes (possibly using reflection to avoid some dependencies at compilation time)?

More generally, I don't understand why this problem is still here. As far as I know, Minecraft belongs to Microsoft, so I would think that this kind of partnership would give them enough influence to fix this issue in Windows 10. How does Minecraft handle this issue? On the other side, why this issue can't be fixed by Oracle in Java? Doesn't this issue happen in JavaFX 3D too?
If it's allowed to redistribute legacy-igpu-x64.zip, could it be a problem to run it at Sweet Home 3D installation time on all Windows 10 64 bit computers, even if it's not needed?

PS: If you have any link to some discussions that could help, please share them

Why using the reflection whereas JOGL 2 is already a dependency as you use Java3D 1.6? If you drop Java3D 1.5, adding JOGL 2 as a compile time dependency won't be a problem.

Why do you use a link to an obsolete unmaintained version of Java3D? The correct link is here:
http://jogamp.org/deployment/java3d/1.6.0-final/javadoc/javax/media/j3d/RenderingErrorListener.html

I think that it just complains about the version of OpenGL being too low.

The Minecraft maintainers don't really take care of this issue, they don't mind and it can't be fixed by Oracle, it's none of their concern, Intel is to blame. JavaFX 3D doesn't use the OpenGL pipeline by default under Windows.

If I were you, I would run the necessary command only when it's needed.

Maybe this helps:
https://jogamp.org/bugzilla/show_bug.cgi?id=1278

An exception should be thrown in JoglPipeline.setupCanvasProperties() when it goes wrong.

You should try this solution but I think it won't be enough:
http://forum.jogamp.org/Java-3D-crash-or-flickering-tp4035074p4037370.html

gouessej wrote

Why using the reflection whereas JOGL 2 is already a dependency as you use Java3D 1.6?

Reflection allows to compile and use the same program with Java 3D 1.5.2 and 1.6. I won't drop support for Java 3D 1.5.2 and even added options in the installer to switch between Java 3D 1.5.2 and 1.6, because Java 3D 1.5.2 works better for some users.

Thanks for the links
I hope it will help me to find the easiest solution for Sweet Home 3D users.

Manu wrote

Reflection allows to compile and use the same program with Java 3D 1.5.2 and 1.6. I won't drop support for Java 3D 1.5.2 and even added options in the installer to switch between Java 3D 1.5.2 and 1.6, because Java 3D 1.5.2 works better for some users.

I highly doubt that Java3D 1.5.2 works better than Java3D 1.6.0-Final and Java3D 1.7.0. "better" is very vague. When Java3D 1.5.2 uses JOGL 1 for the rendering, the end user might have problems because of the numerous bugs we fixed only in JOGL 2. When Java3D 1.5.2 uses the native renderer based on OpenGL, the end user might have problems because of the numerous bugs or limitations only handled in JOGL itself. When Java3D 1.5.2 uses the native renderer based on Direct3D, the end user might have problems because of its numerous bugs and in all cases, (s)he might have some problems because of the bugs we fixed elsewhere.

Moreover, as far as I remember, the few regressions have been fixed, some of them are only addressed in Java3D 1.7.0. I would like you to tell me what is still wrong with Java3D >= 1.6. Sweet Home 3D is used by lots of people, allowing the use of Java3D 1.5.2 clearly doesn't give a good sign but I wouldn't insist if Java3D >= 1.6 wasn't maintained. The project isn't very active but several developers are still able to fix the bugs and promptly provide binary builds (which isn't very hard as this project contains only Java source code and uses Maven since the version 1.7.0). If some people still refuse to update their drivers, it will cause problems whatever the version of Java3D you use. It would help me if you could indicate what causes some troubles on some machines with Java3D >= 1.6.

Manu wrote

Thanks for the links
I hope it will help me to find the easiest solution for Sweet Home 3D users.

You're welcome.

By the way, Oracle demands JakartaEE to stop using "javax", it shows that the JogAmp community did the right choice.

I think that this repository contains several solutions, I only gave you the most viable one:
https://github.com/pal1000/save-legacy-intel-opengl

Julien,
This is excellent news, thanks for discovering this information about the nightmare intel integrated gpus (and providing it).

For anyone else browsing this topic a very useful post about this shim is on the intel forums here
https://communities.intel.com/message/511079#511079

It has links to more information and a very detailed video of how to create this shim (and any other required shims), it's shows that it's all above board and a "proper" work around to the Intel decision to let these gpu's die.

Interestingly minecraft look like they just gave it away by setting the requirements to Ivy Bridge and up
https://minecraft.gamepedia.com/Java_Edition_hardware_requirements

Intel of course say the older igpu are incompatible with windows 10 (which is crazy)
https://www.intel.com/content/www/us/en/support/articles/000005526/graphics-drivers.html

Thanks,
Phil.

Thank you. I strongly disagree with Intel's decision concerning this hardware. It should have released anew those drivers at least once more under Windows 10. Maybe we'll find a better workaround one day (based on ANGLE or Mesa).

gouessej wrote

I highly doubt that Java3D 1.5.2 works better than Java3D 1.6.0-Final and Java3D 1.7.0. "better" is very vague.

"Better" means simply that the users under Windows 10 64 bit who get Java 3D errors in Sweet Home 3D 64 bit / Java 3D 1.6 are finally able to launch the program as soon as it's run in 32 bit with Java 3D 1.5.2. Maybe some other problems arise elsewhere, but as far as I know, nothing that prevents them from using the program. So, at least in the case of Sweet Home 3D, it's a working solution at the moment and it's a reason why I added some parameters in the installation program to force the installation of Sweet Home 3D with Java 32 bit and Java 3D 1.5.2, because by default, it's installed with Java 64 bit and Java 3D 1.6 under Windows 64.

philjord wrote

Intel of course say the older igpu are incompatible with windows 10 (which is crazy)
https://www.intel.com/content/www/us/en/support/articles/000005526/graphics-drivers.html

Interesting... Is there a way to detect the CPU and graphics card used on a Windows 10 computer, using the registry or some other info? With Intel's list and this info, Sweet Home 3D Inno Setup installer could decide if the program should be installed with Java 32 bit and Java 3D 1.5.2 when needed. I prefer that users with badly supported configurations don't experience a Java 3D blocking error at first launch and/or aren't obliged to download and run a shim command with admin privileges. Running the program in 32 bit instead of 64 bit wouldn't be probably a big loss for them since their computer mustn't be very powerful.

gouessej wrote

By the way, Oracle demands JakartaEE to stop using "javax", it shows that the JogAmp community did the right choice.

That's an other (worrying) subject. Please, let's not mix things...

Maybe you could drive the installation of this shim easier instead of sticking with a 32-bit JRE and an obsolete unmaintained version of Java3D. For example, you could download the shim or put it into your installer and run it with admin privilege if necessary. As far as I remember, it's doable with NSIS (and JNDT), it's probably doable with Inno Setup too.

Not sure the shim works so well. Until now, it didn't work for the few people who tested it.

At the opposite, a user could make Sweet Home 3D work in 64 bit with Java 3D 1.6 by simply replacing the installed JRE 8u162 with a copy of JRE 8u51! Would it possible to set some flags on JRE 8u162 to make it simply work?
At the opposite, beside a few minor bugs that were fixed between 8u51 and 8u162, what could be the problem to install a JRE 8u51 for the users who may have this issue (an installer with an additional JRE will be larger of course, but this problem must be fixed)?

It's a really bad piece of news :( Please can you indicate which GPU they use? Some Minecraft users claim it works but it might fail on slightly different hardware.

There is no such flag, the change that makes the JRE "Windows 10 ready" is deep in the native source code.

The Oracle Binary Code License Agreement for Java SE is quite strict, bundling Oracle JRE is a bad idea, I advise you to use the binary builds provided by adoptopenjdk.net instead (and to ask for 32-bit support so that I will be no longer alone to talk about that). The security risks are smaller if the JRE isn't installed on the system, i.e if it's only used by your program.

Maybe we could make a request for enhancement for a "Windows 10 ready" switch in Java 1.9 or 1.10 but I'm not sure that it can be implemented.

The original fix for this,first discussed here:

https://github.com/LWJGL/lwjgl/issues/119#issuecomment-173983180

From here:

https://jogamp.org/bugzilla/show_bug.cgi?id=1278

Will allow you to bundle any java exe with Sweet Home 3D and work around this. It's a very simple fix relating to the manifest and should literally only take a few minutes to do. Of course then you have to bundle the JRE, but from what I've seen that seems to be no big deal for a lot of programs and is what minecraft does. In fact I notivce even the latest minecraft installs with 1.8.0_25 runtime.  (Now I look I notice it installs the 64bit jre into the program files(x86) which is a very odd system).

Unfortunately I don't have my old laptop anymore to do testing on this bug now.
 

Thank you. I had forgotten that you could "simply" fix the executable that way :)

gouessej wrote

Manu wrote

Reflection allows to compile and use the same program with Java 3D 1.5.2 and 1.6. I won't drop support for Java 3D 1.5.2 and even added options in the installer to switch between Java 3D 1.5.2 and 1.6, because Java 3D 1.5.2 works better for some users.

I highly doubt that Java3D 1.5.2 works better than Java3D 1.6.0-Final and Java3D 1.7.0. "better" is very vague.

I must say I exactly understand what Manu has in his mind...
As you may remember we're developing VisNow (http://visnow.icm.edu.pl) which is Java3D based application, and are struggling with all the same problems and many more
To make the story short - VisNow is still distributed with Java3D 1.5.2 (except MacOS) and running on native OpenGL pipeline as we cannot ultimately migrate to 1.6 or 1.7 due to a number of problems. To keep with the topic, on integrated Intel graphics we also have problems with inverted z-buffering in some cases of triangulated surfaces or surface+line objects. On Windows 10 + Intel (e.g. HD4000) it makes VisNow + Java3D 1.6 practically unusable. On MacOS (e.g. Intel Iris Plus 640) it behaves a bit differently and may be acceptable with known bugs.
On the other hand I still cannot force VisNow to run at all with Java3D 1.7-pre1 on all platforms but MacOS .
   

Hey

babor wrote

I must say I exactly understand what Manu has in his mind...

I don't use telepathy yet, sorry.

babor wrote

As you may remember we're developing VisNow (http://visnow.icm.edu.pl) which is Java3D based application, and are struggling with all the same problems and many more
To make the story short - VisNow is still distributed with Java3D 1.5.2 (except MacOS) and running on native OpenGL pipeline as we cannot ultimately migrate to 1.6 or 1.7 due to a number of problems. To keep with the topic, on integrated Intel graphics we also have problems with inverted z-buffering in some cases of triangulated surfaces or surface+line objects. On Windows 10 + Intel (e.g. HD4000) it makes VisNow + Java3D 1.6 practically unusable. On MacOS (e.g. Intel Iris Plus 640) it behaves a bit differently and may be acceptable with known bugs.
On the other hand I still cannot force VisNow to run at all with Java3D 1.7-pre1 on all platforms but MacOS .

JogAmp APIs aren't to blame, we're not responsible for Intel's debatable choices and sometimes you have to tell your end users that they should use some hardware with more professional driver support. We spent several months in looking for some workarounds for the problem with some Intel GPUs no longer working under Windows 10 despite the fact that it's not caused by a bug in our APIs, we can't do more. We aren't responsible for driver bugs. Sometimes we succeed in writing some renderer quirks. We aren't responsible for your technical choices, I already wrote that Java Webstart doesn't help to work around some limitations and bugs.

Moreover, switching from Java3D 1.6 to Java3D 1.7 only requires to update the package names in your code, it's not an unachievable change.

Finally, I cannot fix bugs that aren't in our APIs and bugs that nobody reports. "we cannot ultimately migrate to 1.6 or 1.7 due to a number of problems" doesn't help at all and I still highly discourage the use of Java3D 1.5. Several contributors have worked in fixing bugs, sticking to Java3D 1.5 only to go on supporting a very few Intel GPUs or deprecated Java versions is a nonsense.

gouessej wrote

JogAmp APIs aren't to blame, we're not responsible for Intel's debatable choices and sometimes you have to tell your end users that they should use some hardware with more professional driver support.

True. I'm not blaming you guys, rather than letting know that many such issues exist.
Indeed our described case on Windows 10 was (surprisingly) solved by windows update, while MacOS will probably wait longer... On the other hand the variety of combinations of features, OSes, Java versions, Java3D versions and hardware makes it almost impossible to run properly everywhere.    

gouessej wrote

Moreover, switching from Java3D 1.6 to Java3D 1.7 only requires to update the package names in your code, it's not an unachievable change.

Finally, I cannot fix bugs that aren't in our APIs and bugs that nobody reports. "we cannot ultimately migrate to 1.6 or 1.7 due to a number of problems" doesn't help at all and I still highly discourage the use of Java3D 1.5. Several contributors have worked in fixing bugs, sticking to Java3D 1.5 only to go on supporting a very few Intel GPUs or deprecated Java versions is a nonsense.

I was intentionally not describing all the details in this thread. I'll post each problem separately as soon as we manage to extract them.

babor wrote

True. I'm not blaming you guys, rather than letting know that many such issues exist.
Indeed our described case on Windows 10 was (surprisingly) solved by windows update, while MacOS will probably wait longer...

It's not surprising. Some end users are extremely reluctant to update their software components (operating systems, drivers, ...), I closed a bug report opened by someone using a five-year-old version of JOGL with an almost ten-year-old driver:
https://github.com/gouessej/Ardor3D/issues/29

babor wrote

On the other hand the variety of combinations of features, OSes, Java versions, Java3D versions and hardware makes it almost impossible to run properly everywhere.    

Using a deployment method relying on the JRE installed on the system doesn't help.

babor wrote

I was intentionally not describing all the details in this thread. I'll post each problem separately as soon as we manage to extract them.

I can create a bugzilla account for you if you want. Please rather create one bug report per bug, it's easier to track down each problem that way.