Still trying to resolve the issue of Java 3D 1.6 under Parallels, I discovered that removing the two calls to glColor4f in resetColoringAttributes and updateMaterialColor in JoglPipeline fixed the problem without changing colors in the scenes rendered by Sweet Home 3D!
Actually, these two calls happen only in the resetImmediateRendering method of Canvas3D and there's probably an issue in Parallels driver that doesn't like a change of the current color before rendering is started, because other calls to glColor4f work correctly.
Thank you for sharing your findings. Maybe Phil can confirm or infirm whether this change doesn't cause any regression. I'd prefer we move them elsewhere instead of removing them. If your fix is correct, it will be included in Java3D 1.7.0 (probably no backport in Java3D 1.6.0 as we'll probably not release another pre-build of this version).
I've had a few more requests for a final java3d version 1.6 release. I will be collecting patches over the next two weeks to round up any strays and do a -final release to close that line of development, the 1.7 development can then continue as others have time to do so.
Ok, good idea, it will be helpful for those who have to stick with Java3D 1.6.0. Please can you upload the Java documentation into jogamp.org too?
Maybe we should put the Java3D into the JogAmp repository and get accustomed with pushing our changes into it. Then, the scripts will have to be modified. It's up to you to decide whether we do this change in Java3D 1.6.0 or only in Java3D 1.7.0.
Good to read news from you Harvey Your proposal is great and would avoid me to keep the fork I had to create for the same purpose. Note that I may also have found a solution for bug #1006, but as Phil found a workaround, it might not be mandatory to add this fix to version 1.6.