I’m using gl-context 3.3 and have done some fairly simple drawing in 2d, using an orthographic projection. I’ve requested 4-component position attributes, but, so far only really used .x & .y. No problem, until I want to add the extra component, .z
No problem since sending vec2 data that has the components written as
(*GLfloat ) pos= glMapBufferRange(…)
pos[ 0 ] = (GLfloat ) vec2.x ;
pos[ 1 ] = (GLfloat ) vec2.y ;
pos[ 2 ] = (GLfloat ) 0.f ;
pos[ 3 ] = (GLfloat ) 1.f ;
works just fine, so, just plug in .z as
ptr[ 2 ] = (GLfloat ) z_var ;
Just … that it won’t work. The point vanishes. It’s used on_drag_point(), so it’s easy to test.
I’ve tested sizeOf(z_var) for any trouble. I’ve replaced the variable with other constant litteral values and fixed the var in a pointer, but nothing works except for the litteral constant 0.f.
I have no clue of what’s going on and where to look.
Is the value of
z_var valid according to the math you’re doing in your shader (including the contents of your matrices)? It’s pretty much impossible to say without actually seeing your code.
I’ve tested positive and negative values. And, I read the value in cout << right before it’s used.
I do have a clue though:
It must be a missing frustrum.
I just had a look at glOrtho(), it’s the 4-component one missing near & far.
That’ll have to be the culprit.
Thanks for your quickie
… oh well, that optimism didn’t last long.
As for the matrices, they are hardly used.
glOrtho() is sat once, covering the screen and a default translateMatrix are used to
outMat = ortho*translateMatrix
This outMat is written once.
If I drag the full polygon, the point will reappear without changing any matrixes. Everything is drawn with this global matrix with screen-pixels as model-values.
there we go … swapping your sense of near and far did the trick. And some obsolete code of my own that should not have been called.