Viewport / gluProject / Java2DOpenGLPipeline problem

OpenGL Development JOGL Development
#1

Hi there,

I 've got a problem with the gluProject-calculations when the pipeline is enabled. My y-values are always lets say 30 pixels to “high/deep”. With disabled pipeline there’s no problem at all. The rendering is nearly the same (and in the right position on the window) with or without the pipeline (with the pipeline it’s a lot faster of course ;D). But the gluProject results in wrong values. I always read the viewport with gl.glGetIntegerv(GL.GL_VIEWPORT, viewport, 0); so there shouldn’t be a cachsing problem.

I have to say, that I move my renderings within the gljpanel using different x,y’s for the viewport than the reshape told me (I translate based on the x,y’s the reshape told me).

Thanks for help
Klemens

#2

I think the problem is how you’re specifying your viewport. The default behavior of reshape() (before your callback is called) is to issue a call to glViewport(x, y, w, h). If you do this, or just leave the viewport alone, you shouldn’t need to do any additional translation related to the x and y passed in to your reshape callback.

#3

Even without the translation the problem occurs. I changed my viewport-definition to the incoming x,y,w,h values of the reshape-method, but it still remains the same error… I can workaround my translation things in the viewport deifnition, but the problem is somewhere in gluProject. When I first started with playing around with the pipeline I had the positioning problem in the rendering. Chris Campbell told me to use the exact x,y values of the reshape-call instead of just 0,0. That solved the rendering offset (there were around 30 pixels offset in the y-axis too). But the gluProject seems to be unaffected by this.

PS: I’m running the tests on an ati radeon 200M xpress.

#4

Try playing with the viewport values you pass to gluProject. Perhaps passing 0 for the viewport’s x and y values is the right thing to do based on the other translations going on.

I’ve looked through JOGL’s gluProject implementation (Project.java in the JOGL source base) and compared it to the OpenGL sample implementation and it looks correct.

#5

Without the pipeline enabled the gluProject calculation calcs the right values. Only when I enable the pipeline, the y values get translated. As I just realized the gluUnProject shows the same behaviour in the opposite direction.

We can forget about my mentioned translations… I removed them and it’s still the same problem (except the location where the error occurs ;D)

If you like I can provide a simple testcase (which shows the error hopefully) along with screenshots on my testing system.

#6

The only difference between having the Java 2D / OpenGL pipeline enabled or not in this area is that the x and y values for the viewport will be non-zero. Try always passing in 0 for them.

#7

Thanks for that… I’ll test it tomorrow when I have access to the other machine

And thanks for your quick replies and help so far… that’s awesome.

#8

I just tried your suggestions. the problem was not only on the gluProject / gluUnProject site. I use false-colored-rendering for selection purposes and didn’t integrate the y-offset (-34) of the reshape’s y parameter within my calculation of the buffer position.

Thanks so far…

#9

Just for understanding… why is there a different viewport location when using the pipeline?

I had to edit most of my “mouse-position-calculations” in order to fix the positioning thing. Well it’s just simple 2d-geometry in my case so there wasn’t any problem, but it took a while to find the error’s (fortunately I got great help here). Maybe there could be inserted a hint somewhere in the javadocs?

Finally I got my custom viewport-translation to work by just subtracting the original viewport-location of the reshape call from my translated one in all gluProject / gluUnproject calls and the calculation for the framebuffer position in the false-color rendering (just for the case, that anyone runs into the same trouble).

Thanks
Klemens

#10

The difference in the (x, y) origin is because when the Java 2D / JOGL bridge is enabled, JOGL is rendering directly into a portion of Swing’s back buffer, and the origin of the back buffer is different than the origin of the sub-region being rendered into. When the bridge is disabled (i.e., when the Java 2D / OpenGL pipeline is off), the GLJPanel renders into its own off-screen pbuffer, and the lower-left corner of the viewport is the same as the lower-left corner of the pbuffer.

I don’t want to specify this too strongly in the javadoc because it may change in the future.

#11

Okay… ;D