Java3d 1.6.0-pre12 released: requires jogl 2.3.1

I've pulled in fixes from Julien and Curtis fixing up the readme file's build instructions and updating for API renames in jogl 2.3.1.

I've pushed out some preliminary changes to the j3d-core repo which should make the Maven changes less invasive, but the circular dependency between j3dcore and j3dutils still exists.

I'm leaning towards just moving a few of the j3dutils packages into j3dcore and calling it a day, it will mean Java3d won't be found in Fedora, but everyone else will likely ship it...so, better than nothing.

As usual, download here:
http://jogamp.org/deployment/java3d/1.6.0-pre12/

Cheers,

Harvey

Hi

Thank you for the good job.

What's wrong with Fedora?

Edit.: You have "forgotten" to create jogamp-java3d.7z, I'll fix it Tuesday at home.

Harvey, thanks for your great work! Just tested it with our Java3D application with Windows 7 64bit/i7/Quadro graphics/Java1.8.0_25 and worked great in Stereo (using a zSpace 200)!!!

Cheers,
Bjorn

bjoern wrote

Java1.8.0_25 and worked great in Stereo

It's strange because there is still an AWT bug affecting stereo.

Bjoern: do you use Babors AWT hack in your application to make Stereo
work?
"Following the path that AWT Component overrides GC of Canvas3D when it is
added to a parent, it is possible to react on such event, find the topmost
Component and reset the original Canvas3D GC to the whole hierarchy using
reflection on setGraphicsConfiguration"
http://forum.jogamp.org/Java3D-stereo-td4029914.html#a4031792

2015-04-20 8:30 GMT+02:00 bjoern [via jogamp] <
ml-node+s762907n4034329h62@n3.nabble.com>:

> Harvey, thanks for your great work! Just tested it with our Java3D
> application with Windows 7 64bit/i7/Quadro graphics/Java1.8.0_25 and worked
> great in Stereo (using a zSpace 200)!!!
>
> Cheers,
> Bjorn
>
> ------------------------------
>  If you reply to this email, your message will be added to the discussion
> below:
>
> http://forum.jogamp.org/Java3d-1-6-0-pre12-released-requires-jogl-2-3-1-tp4034327p4034329.html
>  To start a new topic under java3d, email
> ml-node+s762907n3728156h99@n3.nabble.com
> To unsubscribe from jogamp, click here
> <http://forum.jogamp.org/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=762907&code=eGVyeGVzQGd1ZGlubmEuY29tfDc2MjkwN3wtNTE5NjUwMzEw>
> .
> NAML
> <http://forum.jogamp.org/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>
>

I'm half tempted to add a Java3d property people can set to turn on that code in Canvas3D, basically make it an opt-in fixup for those people that need it.

Will consider.

Harvey

On 04/21/2015 08:22 PM, hharrison [via jogamp] wrote:
> I'm half tempted to add a Java3d property people can set to turn on that code
> in Canvas3D, basically make it an opt-in fixup for those people that need it.
>
> Will consider.

Any chance to add JOGL's stereoscopic renderer to Java3D ?

<http://jogamp.org/deployment/jogamp-next/javadoc/jogl/javadoc/com/jogamp/opengl/util/stereo/StereoClientRenderer.html>

~Sven

It's still pretty intertwined with the AWT Canvas class, that dependency is just everywhere in the rendering pipeline, until we replace that or add a 'side door' to plain drawables, I'm not really sure it's possible to hook up the stereoscopic renderer from jogl.

Harvey

I agree with Harvey. The architecture of Java3D was designed with multiple backends in mind but strongly connected to the AWT canvas. JoglDrawable uses a GLDrawable. In my humble opinion, it can't work as is.

Moreover, I thought that "we" wanted to keep Java3D public API unchanged. Some developers want to improve Java3D by adding some support of Maven (and maybe Gradle), it's nice to drive it more maintainable on the long term but if it hasn't already been done, we should make a decision about whether or not implementing new features into this scenegraph API (and it's not a secret that I'm particularly reluctant to do so but others are free to do so).

I just tried latest version of j3d pre12 and jogl 2.3.1

It works fine but generally the Java3D initialization seem to be slower than before (pre9). But more noticeably there is a problem with a window briefly poping up and disappearing when a call to getBestConfiguration() is made:

printProperties(VirtualUniverse.getProperties());
GraphicsConfigTemplate3D template = new GraphicsConfigTemplate3D();
template.setSceneAntialiasing(GraphicsConfigTemplate.PREFERRED);
GraphicsDevice defaultScreenDevice = GraphicsEnvironment.getLocalGraphicsEnvironment().getDefaultScreenDevice();
GraphicsConfiguration config = defaultScreenDevice.getBestConfiguration(template);

Thank you for the feedback. Please try the other builds in order to find in which one a regression might have appeared.

Thanks for the version 1.6.0-pre12. I tried it successfully under Mac OS X.
Under Windows 8.1 running with Parallels Desktop, I still have a crash with the following stack trace:

C  [prl_gldd.dll+0x134d9]
C  0x0000000002c65e34

Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
j  jogamp.opengl.gl4.GL4bcImpl.dispatch_glColor4f1(FFFFJ)V+0
j  jogamp.opengl.gl4.GL4bcImpl.glColor4f(FFFF)V+47
j  javax.media.j3d.JoglPipeline.resetColoringAttributes(Ljavax/media/j3d/Context;FFFFZ)V+28
j  javax.media.j3d.Canvas3D.resetColoringAttributes(Ljavax/media/j3d/Context;FFFFZ)V+12
j  javax.media.j3d.Canvas3D.resetImmediateRendering()V+131
j  javax.media.j3d.Renderer.doWork(J)V+3824
j  javax.media.j3d.J3dThread.run()V+19
v  ~StubRoutines::call_stub

Manu wrote

Under Windows 8.1 running with Parallels Desktop, I still have a crash with the following stack trace:
C  [prl_gldd.dll+0x134d9]
C  0x0000000002c65e34

Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
j  jogamp.opengl.gl4.GL4bcImpl.dispatch_glColor4f1(FFFFJ)V+0

This looks like a defect in the parallels desktop prl_gldd.dll driver, I suggest you to report the issue to parallels.

Try re-install the Parallel Desktop Tools.
http://kb.parallels.com/en/122485 
http://kb.parallels.com/en/115835

Parallels Desktop currently supports OpenGL 2.1 only (not higher).
http://kb.parallels.com/en/115487

It works flawlessly under Windows 8.1 without using Parallels. The crash seems to occur very early. Do you reproduce it with a very dummy example based on JOGL but not using Java3D? Please try this one.

Xerxes Rånby wrote

This looks like a defect in the parallels desktop prl_gldd.dll driver, I suggest you to report the issue to parallels.

I don't mind to report it to Parallels, but as this issue provokes a crash of the program, I'd prefer first that Java3D reports at least an exception instead of a VM crash.

Xerxes Rånby wrote

Parallels Desktop currently supports OpenGL 2.1 only (not higher).

If the origin of this issue is because of the minimum version of OpenGL, then sorry I'll continue to use Java 3D 1.5.2 under Windows and Linux which looks quite stable. I can't force many Sweet Home 3D users to upgrade their PC before running the program.

gouessej wrote

It works flawlessly under Windows 8.1 without using Parallels.

If it doesn't work under Parallels, I fear it doesn't work under other old PCs too, that's the main reason why I'd like that we fix this issue before I consider using Java 3D 1.6.0 in Sweet Home 3D under Windows and Linux.

gouessej wrote

The crash seems to occur very early. Do you reproduce it with a very dummy example based on JOGL but not using Java3D? Please try this one.

I just tried JOGLQuad example successfully.
Feel free to make me test whatever you want.

Manu wrote

gouessej wrote

It works flawlessly under Windows 8.1 without using Parallels.

If it doesn't work under Parallels, I fear it doesn't work under other old PCs too, that's the main reason why I'd like that we fix this issue before I consider using Java 3D 1.6.0 in Sweet Home 3D under Windows and Linux.

Sorry but this is a wrong assumption. I don't see the point of comparing old machines with virtualization technologies. Java3D 1.6.0 still works correctly on old computers, I can use it on a Macbook Pro 3.1 (sold in 2007) and on my old computers (sold between 2005 and 2008). It requires OpenGL 1.3 like Java3D 1.5, it has a chance to work more or less on OpenGL 1.2. I'm not the kind of guy who asks people to upgrade their computers to run a program.

Manu wrote

gouessej wrote

The crash seems to occur very early. Do you reproduce it with a very dummy example based on JOGL but not using Java3D? Please try this one.

I just tried JOGLQuad example successfully.
Feel free to make me test whatever you want.

Thank you for testing. I fear that the threading model of Java3D causes a few troubles with JOGL in a very few particular cases but Parallels itself is to blame too. However, I can have any application based on Java3D 1.5 crashed with numerous graphics cards under Windows, at least 2 renderer quirks of JOGL cover some of those cases. This isn't what I mean by "quite stable". Some end users just give up when it doesn't work, it doesn't mean that Java3D 1.5.2 is more reliable than Java3D 1.6.0. I have found no public bug tracker for Parallels :s

As Parallels isn't free of charge, maybe I should try to get the same crash with VirtualBox. I don't want to be harsh but I don't work on commercial proprietary softwares for free.

Maybe you can post something on its forum, the team seems to reply. Please give its developers a small testcase and my instructions to install Java3D:
http://jogamp.org/wiki/index.php/Downloading_and_installing_Java3D

gouessej wrote

Sorry but this is a wrong assumption. I don't see the point of comparing old machines with virtualization technologies.

As you know, it's just a question of drivers, not about virtualization. And buggy drivers can be found under many PCs.

gouessej wrote

Java3D 1.6.0 still works correctly on old computers, I can use it on a Macbook Pro 3.1 (sold in 2007) and on my old computers (sold between 2005 and 2008). It requires OpenGL 1.3 like Java3D 1.5, it has a chance to work more or less on OpenGL 1.2. I'm not the kind of guy who asks people to upgrade their computers to run a program.

I'm happy to read that
From Xerxes Rånby's comment, I feared that Java 3D 1.6 targets only recent computers.

gouessej wrote

Thank you for testing. I fear that the threading model of Java3D causes a few troubles with JOGL in a very few particular cases but Parallels itself is to blame too.

As said in the past, I use Parallels to test Sweet Home 3D under Windows and Linux and that's the main reason why I won't use Java 3D 1.6 under Windows and Linux. If I can't test it properly under my own test configuration, why would I deliver it to the thousands of Sweet Home 3D users?

Manu wrote

As you know, it's just a question of drivers, not about virtualization. And buggy drivers can be found under many PCs.

Java3D 1.6.0 is more robust than Java3D 1.5 as it relies on JOGL which contains numerous renderer quirks with no equivalent in the buggy native renderers of Java3D 1.5. I don't see how Java3D 1.5 could work better as OpenGL was used by default in it in some cases and the Direct3D renderer was by far the most buggy part of Java3D.

Manu wrote

From Xerxes Rånby's comment, I feared that Java 3D 1.6 targets only recent computers.

It's open source, you can look at the code by yourself, we use the fixed pipeline everywhere. Maybe there was a small misunderstanding.

Manu wrote

As said in the past, I use Parallels to test Sweet Home 3D under Windows and Linux and that's the main reason why I won't use Java 3D 1.6 under Windows and Linux. If I can't test it properly under my own test configuration, why would I deliver it to the thousands of Sweet Home 3D users?

There are other means of testing Java applications on a Mac but under different operating systems and I remind you that there are numerous free of charge GNU Linux distros you can install. Sven succeeded in installing Debian on a Macbook Pro 3.1, I'm still trying to install Mageia on the same machine, rEFIt and rEFInd are helpful. You can install Windows on a Mac with Boot Camp, can't you? This excellent tutorial in French might be useful. It's logical that we don't have to fix Parallels' bugs but please post a comment on its forum and we'll try to cooperate. As I said in the past, it crashes on the very first OpenGL command, it's still the same than with the older pre builds, we can't make it work without the help of Parallels' team.

According to your own post about Java3D 1.5.1 and Parallels, the native OpenGL renderer detected only the crappy Microsoft GDI renderer (OpenGL 1.1). Was it true with Java3D 1.5.2 and the latest version of Parallels too?