It would be easier to reproduce if you provided a small test case. You said that it was working with Java3D 1.5.2, maybe I broke something when porting it; if you tested with exactly the same hardware, this is not caused by a driver bug.
Before trying to build a test case, could you try this current version of Sweet Home 3D jar executable built with Java 3D 1.6 pre 3 and JOGL rc11 available here?
I continuously test versions built with Java 3D 1.5.2 and Java 3D 1.6 on the same hardware.
At program launch, I use some shininess set at 0 for the ground. As I know that the lowest shininess value should be normally equal to 1 in Java 3D, I just tested 1 instead of 0 but it didn't change the way the program crashed.
I vaguely remember that lighting driver bug you're referring to, could you point me to the original conversation that had the details? There were some fixes to some of the lighting attributes in java3d 1.6, maybe it is these parameters actually being passed through that causes the new crashes. Details please.
I check the function that read raster of Z-buffer
using a simple test code.
It works fine. And it works fine in my project too.
The test case(RasterBugReport.java) attached to
http://java.net/jira/browse/JAVA3D-593, only checks
NullPointerException, but my test case can check data
obtained using this function. May I send my test case
I also check JCanvas3D using simple test case.
It works fine too. But in my project, the JFrame that
contains JCanvas3D does not appear at all. So I think
that the problem is in my project code. There are no
error or warning messages. Probably, the reason is that
I do not understand Swing event queue. I continue to
analyze this problem, and I may ask questions if the
problem is not solved.
I found an other PC to try the Sweet Home 3D jar executable built with Java 3D 1.6 pre 3 and JOGL rc11, and it worked, so it seems like the issue I reported under Windows is a driver issue as Julien suspected.
As it didn't happen with Java 3D 1.5.2, it must be bound to the changes programed in version 1.6, or worse, to the fact that Java 3D is bound to JOGL in version 3.6 under Windows.
Are you absolutely sure it didn't happen with Java3D 1.5.2 and exactly the same driver (check the version number)? Maybe there was a hack in the native renderer for Windows; if so, we just have to port it to Java3D 1.6.0 and it will work even with JOGL 2.0 :)
Julien, I believe this is due to a bugfix I made in Java3d where some of the lighting attributes were not being passed
at all to the backend, I don't think this was anything to do with your conversion. Can you point me to any conversation
about the driver bug you suspect?