? JOGL Rendering Issues - Different for v1.1.1 and v2.0 and with Laptop docked vs not ?

I have a very wierd rendering problem that happens when using JOGL 2.0 (build b66-20121101) that I cannot explain, nor do I know what to possibly search for on the internet. I will try to create a small example program but for now let me show you what happens.

I originally wrote a 3D viewer in JOGL v1.1.1 and I converted it over to JOGL v2.0. The conversion is quite simple and NOTHING else changed in the code - only the references to GL2 were added, etc. So effectively I have the exact same program running but using two different versions of JOGL.

I have an HP W76151GA Laptop, Windows 7, 16GB RAM, i7-4910MQ CPU, and an NVIDIA Qadro K3100M graphics card (and integrated Intel HD Graphics 4600). I have no idea which graphics card is being used, but I presume the NVIDIA one is - but with Windows it might switch between cards based on load - who the hell knows.

So, the problem I have is that when I am seeing wierd artifacts when running the program in JOGL v2.0, like lines disappearing at different zoom levels. It seems to be possibly tied to the near/far clipping plane distances, because if something is hidden and I mess with those values then things come back. Look at the attached picture - the image on the TOP LEFT shows the disappearing lines, while the BOTTOM RIGHT shows what you should expect to see.



This is where it gets super wierd. If I undock the laptop and use it separated from my monitors, I get the BAD artifacts that you see on the left side. If I then dock the laptop back I still see that same BAD artifacts. BUT...here is the wierd thing, if while now docked, I start up another instance of this exact same program in JOGL v2.0, I am perfectly fine. That's what you are seeing in this screenshot. I basically started the TOP LEFT instance while undocked, then docked my laptop back in and started a second instance on the BOTTOM RIGHT. Now both instances are running, with my laptop docked and the original instance shows artifacts but the new instance does not.

btw, when I do the same thing using the version with JOGL v1.1.1 there are NO problems.

in short:
     undocked, JOGL v2.0 - BAD
     docked, JOGL v2.0 - GOOD
     undocked, JOGL v1.1.1 - GOOD
     docked, JOGL v1.1.1 - GOOD

I will try to upgrade to the latest JOGL v2.0 release next, and then if it persists, I will try to make an example program. I simply can't explain it and don't know what to even look for to figure out the issue. Like I said, clipping planes distances is the only thing that I think could be the cause, but why would that show up only in JOGL v2.0 and not in JOGL v1.1.1, and also, why would it only show up when undocked as opposed to being docked? Is this where having the integrated and NVIDIA graphics card is causing problems?? And if the dual graphics cards are the issue, why is it that when I dock the laptop back, the first instance still fails, but the new instance works - it's not like both graphics card are active at the same time.

As for clipping plane issues...I'm not completely sold on it being the problem, because as I said, this works perfectly in JOGL v1.1.1 and also, see the series of pictures below where I zoom in closer and closer to the Earth. You will see different things being clipped/artifacted/etc and so if it was a clipping plane issue that should not happen like that at different zoom levels - ie. once I got past the clipping plane, it would be totally off from that point forward and not come back as I moved further in. (if that made ANY sense).

Hi

Sorry but you use an obsolete build of JOGL 2 released in 2012. Please switch to JOGL 2.3.2. We only maintain the very latest version.

Moreover, you should display some information about your hardware when running your software in order to check which GPU is in use and you should provide an example. I remind you that we aren't responsible for the bugs in any docking framework. In my humble opinion, your rendering bugs are probably reproducible with JOGL 1, perhaps your software picks a different GPU when using JOGL 2.

How can I display which GPU is being used?

The problem with you assertion about the possible different GPU is that if I run this with JOGL v2.0 DOCKED it works, if I keep that same program running and then UNDOCK the machine and start the second instance, then only the second instance does not work. Which is what you see in the main screenshot. So once I've undocked, I now have two instances running, yet the one that was started while I was DOCKED works fine, but the one that is started UNDOCKED does not work. SO, how can the GPU be the issue when on one screen I have both versions running and only one is bad and the other good. If undocking changed GPUs then the instance that I started while DOCKED should now be bad as well. I mean, it's not like one GPU is being used to render one view and the second GPU is rendering the other one - only one GPU is active at a time.

And, as I said, this does NOT happen with JOGL 1.1.1 - and the only difference in that code is changing from GL to GL2, no other code changes.

It seems more realistic to me, that when you start up on one mode (say DOCKED), JOGL v2.0 configures itself based on what the capabilities/settings, etc are for that configuration. When you then switch configurations (i.e. go to UNDOCKED mode), if a JOGL application is still running then it doesn't change any of its capabilities/settings, but if you start a new one then it uses the newest capabilities/settings - and for some reason the UNDOCKED capabilities/settings are causing a problem.

and yes, as I said, I need to upgrade to the latest JOGL 2.0+ and I'm about to do that now. Thanks for the thoughts - as always, Julien, I know i can count on you.  Merci.

It has taken some time to do the conversion from JOGL v2.0 to v2.3.2 due to imports changing and I lost GLPbuffer, so had to comment that out for now.

Then I had issues with my clip distances - so it might be the cause. I just can't dial them in right now to get things to work. I may have had to big of a ratio of far/near before but no matter what I try now it still is screwy. And now I get the same effect even in docked mode.

EDIT: it just has to be the clip distances that I pass to gluPerspective().  I tested by adjusting them manually and I just need to play with the numbers to get it to work, but it looks like that was the culprit. It seems like the latest JOGL has some good error checking that v1.1.1 didn't have so it has helped me find this problem. Good job.



btw, any suggestion on how to replace the GLPbuffer? It was still available in version 2.0, but now in 2.3.2 the GLDrawableFactory has the 'canCreateGLPbuffer' test - although different inputs now. But there is no factory.createGLPbuffer() method, is that still available somewhere?

btw, when I was talking about DOCKING/UNDOCKING, I was referring to the physical laptop being connected to a docking station where it outputs the video to separate monitors. When undocked I meant that I removed the laptop from the station and it was sitting on my desk with the screen open.

Are you using immediate mode?

Few considerations, intel driver on windows simply suxs, there are things such as the sRGB implementation that are completely broken for example. And things got worst with Win10.

Moreover, the Optimus technology is a cool idea applied in the worst way. We had a lot of troubles at work...

If you want to use the Nvidia gpu, select maximum perfs in the nv panel. Like if all of this wasn't enough, you should know that the dedicated gpu gets always penalized by the integrated when you use anything attached to the video outputs because even if you use the dedicated for the rendering, because everything needs to be first copied to the integrated one framebuffer and then sent out. This increases latency and lower perfs.

To summarize, try to use another machine ^^

immediate mode: to some degree yes, but lots of what I have is either display list or VBO.

I'll try to use the nvidia panel, good idea, thanks.

I think the main thing is that my damn clipping plane distances were screwed up and I was probably exceeding the depth buffer. What's surprising is that under JOGL v1.1.1 that didn't seem to matter - even with a large near/far ratio it was still looking good. As a matter of fact, I even had the far plane value as NEGATIVE!!! and that seemed to work find in v1.1.1, but v2.3.2 warned me about via an exception. I just need to nail down the various clip plane values over the next few days and then I should be fine. I hope.

now I just need to figure out how to do the GLPbuffer under v2.3.2...if it even exists.

You should avoid any deprecated stuff, immediate and display list usage, completely. The driver may intervene producing unexpected results.

It is likely also that the nvidia driver was fixing the clipping plane for you in 1.1.1 but not now, for whatever reason.

Do everything as it supposed to be done, don't rely on some drivers otherwise you will be screwed up when you switch to some less invasive drivers, such as amd or intel.

What do you need GLPbuffer for? Texture streaming?

I agree that the I should move to the latest based OpenGL API, but I'm kind of stuck with this immediate mode and display list stuff because I was developing for older hardware that did not support shaders. So it would take a very large effort to now move to shaders - I'm guessing that's what you mean. I'm not trying to make excuses but I think I'd get fired if I started over right now - I couldn't justify that much redevelopment, so for now I have to continue with what I started even though we do have better hardware now. Original development was for Redhat linux 4 (I believe) and didn't have great graphics cards to handle shaders, etc.

I think for v1.1.1, it was probably JOGL, more than a specific driver that handled the clipping planes better for me - like it probably automatically took the absolute value of the far plane (because I've had negative values in there for a while). I also think it was JOGL because I was developing previously on an ATI machine and had no problems - just got a new computer in the last couple of weeks which has NVIDIA.

I'm trying to remember what I was using the GLPbuffer for - it's been a while since I looked at this part of the code - it was for a different project so not related to my images above. Basically I had a project where I was rendering to a buffer and I believe then I was retrieving the pixels from that buffer and counting how many were visible and how many were background. Using that info told me what percentage of the screen was covered so I could use that to calculate the visible area of the object. I needed to calculate a frontal area for an object that could be in different attitudes, so the best way I figured was to simply project that view in an orthographic projection and then count pixels - it worked pretty well.
Looking back at this code, I do indeed render to the GLPbuffer. And in the renderer, I do the glReadPixels() to get the pixel data. I'm not exactly sure why the GLPbuffer was or is necessary to do this, but that was my code from a while back and now I can't run it because the GLDrawableFactory.createGLPbuffer() is different, but more importantly there is no more GLDrawableFactory.createGLPbuffer() method....is there a substitute method elsewhere?

Edit: I guess I need to look at the actual docs for more info rather than simply relying on netbeans...I found this in the v2.0.2 docs, and this hence since been removed from v2.3.2, so I need to learn the new way:

  createGLPbuffer(AbstractGraphicsDevice device, GLCapabilitiesImmutable capabilities, GLCapabilitiesChooser chooser, int initialWidth, int initialHeight, GLContext shareWith)
          Deprecated. GLPbuffer is deprecated, use createOffscreenAutoDrawable(AbstractGraphicsDevice, GLCapabilitiesImmutable, GLCapabilitiesChooser, int, int, GLContext)

Edit #2: That was an easy update. It looked scary because of the bigger words, but it was almost a one-for-one change, like going from JOGL v1 to v2. Sweet.

Z-Knight wrote

I agree that the I should move to the latest based OpenGL API, but I'm kind of stuck with this immediate mode and display list stuff because I was developing for older hardware that did not support shaders. So it would take a very large effort to now move to shaders - I'm guessing that's what you mean. I'm not trying to make excuses but I think I'd get fired if I started over right now - I couldn't justify that much redevelopment, so for now I have to continue with what I started even though we do have better hardware now. Original development was for Redhat linux 4 (I believe) and didn't have great graphics cards to handle shaders, etc.

I didn't mean to the latest one, but 2.1 or 3.3 would be infinitively better. Take in account we talk about 2008 technologies.

I can image moving would require a very large effort, but you should think about that everytime you develop on such an old version you may have to pay an overhead. All these overheads may be smaller than the large effort in the long term.
If the conditions let you do it, you could develop and test it on a side, in parallel.

Z-Knight wrote

I think for v1.1.1, it was probably JOGL, more than a specific driver that handled the clipping planes better for me - like it probably automatically took the absolute value of the far plane (because I've had negative values in there for a while). I also think it was JOGL because I was developing previously on an ATI machine and had no problems - just got a new computer in the last couple of weeks which has NVIDIA.

Then it should be as you say.

Z-Knight wrote

I'm trying to remember what I was using the GLPbuffer for - it's been a while since I looked at this part of the code - it was for a different project so not related to my images above. Basically I had a project where I was rendering to a buffer and I believe then I was retrieving the pixels from that buffer and counting how many were visible and how many were background. Using that info told me what percentage of the screen was covered so I could use that to calculate the visible area of the object. I needed to calculate a frontal area for an object that could be in different attitudes, so the best way I figured was to simply project that view in an orthographic projection and then count pixels - it worked pretty well.
Looking back at this code, I do indeed render to the GLPbuffer. And in the renderer, I do the glReadPixels() to get the pixel data. I'm not exactly sure why the GLPbuffer was or is necessary to do this, but that was my code from a while back and now I can't run it because the GLDrawableFactory.createGLPbuffer() is different, but more importantly there is no more GLDrawableFactory.createGLPbuffer() method....is there a substitute method elsewhere?

Edit: I guess I need to look at the actual docs for more info rather than simply relying on netbeans...I found this in the v2.0.2 docs, and this hence since been removed from v2.3.2, so I need to learn the new way:

  createGLPbuffer(AbstractGraphicsDevice device, GLCapabilitiesImmutable capabilities, GLCapabilitiesChooser chooser, int initialWidth, int initialHeight, GLContext shareWith)
          Deprecated. GLPbuffer is deprecated, use createOffscreenAutoDrawable(AbstractGraphicsDevice, GLCapabilitiesImmutable, GLCapabilitiesChooser, int, int, GLContext)

Edit #2: That was an easy update. It looked scary because of the bigger words, but it was almost a one-for-one change, like going from JOGL v1 to v2. Sweet.

If that doesn't work for you, you should create the pixel buffer/texture in your own.

Good points about OpengGL 2.1+. I am partially there except that I've not started implementing shaders in my code. I still use the fixed function pipeline although I do use VBOs/Vertex Array for rendering of my models. It's just that everything else is still display lists (like 3D shapes, etc), but I have very few of those. Most of my rendering is the 3D models of vehicles and the other stuff like occasional 3D shapes, or thruster plumes, etc are done with display lists, but as I said, that is so small that performance does not suffer.

anyway, you can see below I have limited use of shapes, etc that so I'm ok for now.

Anyway, the screenshots look really cool, what program is that?

I call it "Asset View". It is a 3D (obviously) visualization of the International Space Station and approaching vehicles. It is used to show the ISS in the correct orbit location, in attitude and with solar array, and robot arm in actual positions. It also shows the relative position of the approaching vehicles and can show their state/attitude, their thruster firings. It uses telemetry or playback data or can be manually overridden. It's primarily used to verify that the approaching vehicles are at a safe distance and on the proper course while approaching the ISS. It is used in Mission Control at NASA.

Awesome, simply awesome!

Would it be possible to add in under http://jogamp.org/jogl/www/ ?

I'd really like to take a look/partecipate if you would ever want to open it and need help to develop it

Z-Knight wrote

How can I display which GPU is being used?

I missed this, you can do the following:

        System.out.println("" + GLContext.getCurrent().getGLVersion());
        System.out.println("Vendor: " + gl4.glGetString(GL_VENDOR));
        System.out.println("Renderer: " + gl4.glGetString(GL_RENDERER));
        System.out.println("Version: " + gl4.glGetString(GL_VERSION));
        System.out.println("Shading Language Version: " + gl4.glGetString(GL_SHADING_LANGUAGE_VERSION));

Unfortunately, at the moment I couldn't release it. This would require approval that would be hard to get because it has some international partner proprietary stuff. Technically, since it is US government than it is public domain since I have submitted it as a New Technology Evaluation so technically it would be available for release eventually, but will require stripping out some of the proprietary stuff when someone requests it.

trust me though, it is bass-ackwards at the moment. The best thing about it is the old JOGLUTILS 3DS loader that I took a very rough version and significantly updated - though it isn't completely working, but better than the one currently probably still available from JOGLUTILS. The rest is poorly coded fixed function pipeline code.

btw, I wish I could release it today and get critiques/suggestions because I wrote this a while back (obviously around JOGL v1.1.1 time) and it has been hacked on for a while since then. I know there are a bunch of things that I don't have fully working that would be nice to have people tell me what I did wrong. For example, as we discussed I use display lists, but I also use VBOs/Vertex Arrays for the 3DS vehicle rendering. Unfortunately, my VBOs implementation is not exactly the best and sometimes I found display lists to be faster at rendering than my VBOs and that should not be the case. Actually, my JOGLUTILS implementation could probably be released since that is based on the previous JOGLUTILS code so I need to contribute back to that cause.

I advise you not to use display lists even on old hardware. Lots of drivers have buggy implementations and anyway they are emulated with VBOs under the hood. I get better performance with VBOs except on hardware that emulate them with vertex arrays even in static draw mode. I advise you to use static VBOs and to use the constant indicating the maximum element count in order to avoid creating too big ones in order to keep decent performance.

Z-Knight wrote

Unfortunately, at the moment I couldn't release it. This would require approval that would be hard to get because it has some international partner proprietary stuff. Technically, since it is US government than it is public domain since I have submitted it as a New Technology Evaluation so technically it would be available for release eventually, but will require stripping out some of the proprietary stuff when someone requests it.

I understand.. and what about opening only the graphic part/engine? Does it also involve proprietary stuff?
Is it feasible to isolate it from the rest?

gouessej wrote

I advise you not to use display lists even on old hardware. Lots of drivers have buggy implementations and anyway they are emulated with VBOs under the hood. I get better performance with VBOs except on hardware that emulate them with vertex arrays even in static draw mode. I advise you to use static VBOs and to use the constant indicating the maximum element count in order to avoid creating too big ones in order to keep decent performance.

I understand, but it was the best solution for my setup and it has worked thus far. Also, my VBO implementation - though it seems to work - is likely wrong since I seemed to have better performance with Display Lists. But, that's a different question and I'll get to it eventually.