<p>When you draw a point with <code>GL_POINTS</code>, it's not a 3D object with a size in world-space: its size is a fixed number of pixels. Because of that, the size of the point is independent of the distance from the camera.</p>

<p>If you want to draw dots whose size depends on distance, you either need to compute the perspective yourself and change the point size for each point (not recommended, because state changes like that are expensive); or use another method to draw them. For instance, you might draw a quad and use the fragment shader to make it a circle (e.g. by discarding the fragment if the world co-ordinate was more than a particular distance from the centre of the quad, or by using a transparent texture with a circle in it).</p>

CC BY-SA 4.0
2019-09-16T13:57:14.150Z
Excellent, thanks for your explanation! I understand now why the size doesn't change. However, I don't understand why it worked with the speed? The speed increased when approaching the viewer (unless it was an illusion due to my expectation)
Kathia
CC BY-SA 4.0
2019-09-16T14:42:09.533Z
Well, the position is perspective-projected, regardless of what primitive (lines, points, triangles) you use. Since the speed is just the change in position over time, you should expect that to work correctly. It's like you've written code to turn on a single pixel. You use a perspective projection to determine the $(x,y)$ co-ordinates of the pixel to turn on, but you're still always turning on a single pixel.
Dan Hulme
CC BY-SA 4.0
2019-09-16T22:04:07.027Z
But you can very well change the point size per-vertex in the vertex shader. I wouldn't count that as a "state change" in the classical sense (and personally have made good experiences with per-vertex point size). Of course you'd have to compute the screen-space size yourself from the perspective and there's other problems like point clipping, but the statement on "state changes" is a bit confusing when the same paragraph talks about other shader-based approaches.
Christian Rau
CC BY-SA 4.0
2019-09-17T08:06:08.200Z
@ChristianRau That's true, I'd forgotten you can set point size in the vertex shader. That's a better approach if you don't mind writing the perspective computation there.
Dan Hulme
CC BY-SA 4.0
2019-09-16T13:32:59.430Z
2019-09-16T13:32:59.430Z
Dan Hulme
<p>I am new to OpenGL and I am trying to code un optic flow with dots appearing from the background and moving towards the viewer. As a consequence of a perspective projection, the dots are faster and bigger when they move towards the viewer, but they are smaller and slower when they are farther away from the viewer. </p>

<p>As a result of OpenGL perspective projection, I got the dots moving faster when approaching the viewer, but their size does not change with the distance. Isn't the change of size a consequence of the projection -- just as the change of speed? If not, shall I compute it separately?</p>

<p>Thanks in advance for your help<img src="https://i.sstatic.net/hMcPH.gif" alt="![enter image description here">]<a href="https://i.sstatic.net/hMcPH.gif" rel="nofollow noreferrer">1</a></p>

CC BY-SA 4.0
2019-09-16T13:14:06.910Z
What method are you using to draw the dots? Are they point sprites, points, triangle meshes, or something else?
Dan Hulme
CC BY-SA 4.0
2019-09-16T13:27:36.533Z
They are points, I used GL.GL_POINTS
Kathia
<opengl><perspective>
Change of speed but no change of size after OpenGL Perspective Projection
Kathia
# Change of speed but no change of size after OpenGL Perspective Projection

(Asked by: username_0 on 2019-09-16)

I am new to OpenGL and I am trying to code un optic flow with dots appearing from the background and moving towards the viewer. As a consequence of a perspective projection, the dots are faster and bigger when they move towards the viewer, but they are smaller and slower when they are farther away from the viewer.

As a result of OpenGL perspective projection, I got the dots moving faster when approaching the viewer, but their size does not change with the distance. Isn't the change of size a consequence of the projection -- just as the change of speed? If not, shall I compute it separately?

Thanks in advance for your help![![enter image description here](https://i.sstatic.net/hMcPH.gif)][1](https://i.sstatic.net/hMcPH.gif)

**Tags:** opengl, perspective

> **Comments:**
> **username_1**: What method are you using to draw the dots? Are they point sprites, points, triangle meshes, or something else?  
> **username_0**: They are points, I used GL.GL_POINTS  

---

## 1 answers

### Answer by username_1 on 2019-09-16. Score: 1 | Accepted answer

When you draw a point with `GL_POINTS`, it's not a 3D object with a size in world-space: its size is a fixed number of pixels. Because of that, the size of the point is independent of the distance from the camera.

If you want to draw dots whose size depends on distance, you either need to compute the perspective yourself and change the point size for each point (not recommended, because state changes like that are expensive); or use another method to draw them. For instance, you might draw a quad and use the fragment shader to make it a circle (e.g. by discarding the fragment if the world co-ordinate was more than a particular distance from the centre of the quad, or by using a transparent texture with a circle in it).

> **Comments:**
> **username_0**: Excellent, thanks for your explanation! I understand now why the size doesn't change. However, I don't understand why it worked with the speed? The speed increased when approaching the viewer (unless it was an illusion due to my expectation)  
> **username_1**: Well, the position is perspective-projected, regardless of what primitive (lines, points, triangles) you use. Since the speed is just the change in position over time, you should expect that to work correctly. It's like you've written code to turn on a single pixel. You use a perspective projection to determine the $(x,y)$ co-ordinates of the pixel to turn on, but you're still always turning on a single pixel.  
> **username_2**: But you can very well change the point size per-vertex in the vertex shader. I wouldn't count that as a "state change" in the classical sense (and personally have made good experiences with per-vertex point size). Of course you'd have to compute the screen-space size yourself from the perspective and there's other problems like point clipping, but the statement on "state changes" is a bit confusing when the same paragraph talks about other shader-based approaches.  
> **username_1**: @username_2 That's true, I'd forgotten you can set point size in the vertex shader. That's a better approach if you don't mind writing the perspective computation there.  

---

