starting from 3D points in world coordinates, using the geometry shader I would like to:

move each point for example 5 pixels on the left

reconvert each point in world coordinates

extract the points using the trasformfeedbackbuffer

I have a problem with the reconversion of the points (from screen coordinates to world coordinates). Although I don’t move the points (step (1)) their position is not the same.

You can’t expect to get the same value back when you discard part of the value in the process.

In “fromWorldCoordsToScreenCoords”, you divide by the clip-space W. However, you also destroy the clip-space W, since W/W == 1 (or NAN if W is zero). And even if you had properly retained the clip-space W, you still just drop that value on the floor, by returning just the XYZ. Then, in “fromScreenCoordsToWorldCoords”, you divide by… er, something. I have no idea what [var]vec4(sc,1.0)[/var] is supposed to be, but it is most certainly not something which can be multiplied by the inverse projection matrix to get a reasonable result.

Also, if you want to invert an operation, you have to invert each step, but you also must do the steps backwards. The division is the last thing in “fromWorldCoordsToScreenCoords”, so it must be the first thing in the inverse.

And another thing: you’re not in world space. The modelview matrix, as the name suggests, goes from model space to view space. And this, the inverse of this goes from view space to model space. World space never actually happens.

[QUOTE=Albert85;1263657]
There are multiple coordinate Systems involved in 3D Graphics:

Object Space
World Space (aka Model Space)
Camera Space (aka Eye Space or View Space)
Screen Space (aka Clip Space)

So World space IS EQUAL to Model Space.
Right?[/QUOTE]

That’s just the author’s choice of terminology.

Legacy OpenGL doesn’t have any equivalent of “World Space (aka Model Space)”. Vertices are specified in object space and transformed by the model-view matrix to eye space, then by the projection matrix to clip space.

If you’re using shaders, you can have as many different spaces as you wish. OpenGL just treats the value written to gl_Position in the vertex shader as the vertex position in clip space. It doesn’t care what you did to generate that value.

[QUOTE=Albert85;1263657]herethere is written the following:

There are multiple coordinate Systems involved in 3D Graphics:

Object Space
World Space (aka Model Space)
Camera Space (aka Eye Space or View Space)
Screen Space (aka Clip Space)

So World space IS EQUAL to Model Space.
Right?[/QUOTE]

Um, no. That page is criminally wrong.

Model space is a synonym for object space. Again, this is why it’s called the “modelview” matrix. Old-school OpenGL makes this abundantly clear.

Also, clip space is not a synonym for screen space. Screen space and window space are interchangeable, but I’ve never seen anyone call clip space “screen space”. Again, the OpenGL specification defines these two concepts, and they are not the same. Clip space is most assuredly not in screen-relative coordinates.

If that page has such glaring errors, I would strongly suggest you forget everything on it.

Sometimes the MODELVIEW matrix (see 1st box on left) is split into its component transforms: MODELING * VIEWING. When this is done, the coordinate space between these two transforms is WORLD coordinates (aka WORLD space).

The MODELING matrix transforms objects in OBJECT space into WORLD space, and then the VIEWING matrix takes them from WORLD space and transforms them into EYE space.

[QUOTE=Albert85;1263700]Do you have some suggestions about my problem?..
starting from 3D points in world coordinates, using the geometry shader I would like to:

move each point for example 5 pixels on the left

reconvert each point in world coordinates

extract the points using the trasformfeedbackbuffer
[/QUOTE]

Conceptually:

Compute eye-space position of point (eye_space = gl_ModelViewMatrix * gl_Vertex).

Compute pixels/unit_of_distance (approx)

Offset eye-space position of point (eye_space += 5*pixels/unit_of_distance)

You can do it this way, or you can apply it in clip space at the end of the shader. The latter has several advantages. First, it doesn’t require you to pass in ModelView and Projection separately – you can just pass in ModelViewProjection (one matrix instead of two). Second, you can get exact displacements in pixels with this, whereas the eye-space technique (while easier to understand) only approximates this.