Join GitHub today
GitHub is home to over 36 million developers working together to host and review code, manage projects, and build software together.Sign up
Incorrect rendering with Nvidia Quadro K4100M (driver number 332.21) under Windows 7 #29
I am curious - does this mean that Ardor3D will never work correctly with JOGL?
PS Please do not take this as criticism - I am a great admirer of all your fantastic work and achievements in this area!
At first, the title of your issue is very inaccurate.
Secondly, the fact that you have one problem doesn't mean that the whole rendering with JOGL doesn't work at all. Keep in mind that several softwares in production (and some in pre-beta and alpha) are using JogAmp's Ardor3D Continuation.
Please can you take a few minutes to indicate which test case you use and/or to provide a sscce? Indicate which revision of JogAmp's Ardor3D Continuation you use too, the JRE, the graphics card, etc... I cannot fix a bug that I cannot reproduce. Have you modified the "Shapes example"? Does it work better when you revert some recent changes?
Moreover, as you use the legacy version of Ardor3D provided by Renanse, I advise you to reduce the number of variants by running it with JOGL so that we can find the culprit easier. I remember that I found a bug when using interlaced VBOs in Renanse's version several years ago but he didn't reproduce it and I didn't succeed in fixing it. If the bug was already in Renanse's version, we will probably work together to fix it so that both "forks" benefit of our efforts.
By the way, I don't take your report as a criticism but there is a huge contradiction between your last sentence and the rest of your post that lacks of balancing as you don't even consider that your own code could be to blame just because it works as is with the backend I removed (yes it's a JogAmp project) and you don't seem to realize that finding one bug doesn't mean that the whole product doesn't work. When I gather an apple, if there is only a small rotten part, I'll remove this part and eat the rest, I won't throw the whole apple into the bin.
This branch is 183 commits ahead, 7 commits behind Renanse:master. Where is the matter of time or resources?
Thanks for the quick response.
I have now noticed that the error only occurs with 24 bpp.
Here is the SSCCE "SimpleShapesExample.java" (derived from ShapesExample to limit the shapes and remove BMTextBackground), attached as a zip file.
I am using:
Windows 7 Professional
Sorry - not sure why the closed option was activated.
With the Renanse/Ardor3D version from Github:
nVidia driver version is 332.21
Yes the nVidia control panel indicates that the base profile is selected.
I have no idea what Optimus is, I think that the answer will be no.
Thank you for the feedback. Your bug isn't reproducible under Microsoft Windows 10 with the graphics card Nvidia Quadro 600:
Numerous laptops with Nvidia graphics chips use Optimus, you should see it in your control panel:
Is NVIDIA Optimus mentioned in your case?
The problem is that Optimus might pick another GPU at runtime or when starting the example. We have no control on that.
Moreover, if Optimus isn't involved, you should simply update your driver as it seems to be very old. The graphics card I used for the test was manufactured in 2010, it's older than yours but my driver is a lot less old and the current behaviour is probably caused by a driver bug. I'll retry your example. JOGL is mostly a Java binding for the OpenGL API, we don't do anything special when you select "24 bpp" instead of "16 bpp" and I have no idea of what the other binding does under the hood.
Ok I've just tested both ShapesExample and SimpleShapesExample with JogAmp's Ardor3D Continuation 1.0-Snapshot + JOGL 2.3.2, both with "16 bpp" and "24 bpp" again. I still don't reproduce your bug.
If you modify the near plane of the frustum to move it too close from the shapes, you'll obtain a similar effect even in a program written in plain C.
In my humble opinion, there is something wrong in the OpenGL driver in the depth buffer only when asking for "24 bpp". It's neither a JOGL bug nor a bug of JogAmp's Ardor3D Continuation. Either the other binding silently ignores your query and uses "16 bpp" whatever you pass, or Renanse's Ardor3D doesn't pass this information (it's probably not the case). I'll check whether a more recent driver is available for your hardware.
Thank you very much for the feedback.
However, please keep in mind that JOGL 2.0rc11 is terribly obsolete, please use the very latest version of JogAmp's Ardor3D Continuation with JOGL 2.3.2. If you don't use the latest version, any bug that you will report later will be simply rejected and you'll be bothered by the bugs we've already fixed.