Thread: [PyOpenGL-Users] Fastest way to draw lots of points
Brought to you by:
mcfletch
From: Ryan H. <rm...@gm...> - 2012-10-19 16:52:12
|
I am working on a pygame app that I recently converted to using opegl for the backend. The game has a parallax star field in the background so I have been looking for the most efficient way of drawing multiple points. My game updates the display every 33ms. Bellow are the draw points methods I have tried. def point(point, color, size=1.0, alpha=255.0): glPointSize(size) glDisable(GL_TEXTURE_2D) glBegin(GL_POINTS) glColor4f(color[0] / 255.0, color[1] / 255.0, color[2] / 255.0, alpha / 255.0) glVertex3f(point[0], point[1], 0) glEnd() glEnable(GL_TEXTURE_2D) def points(points, indices, color, size=1.0, alpha=255.0): glPointSize(size) glDisable(GL_TEXTURE_2D) glColor4f(color[0] / 255.0, color[1] / 255.0, color[2] / 255.0, alpha / 255.0) glEnableClientState(GL_VERTEX_ARRAY) glVertexPointer(2, GL_FLOAT, 0, points) glDrawElementsui(GL_POINTS, indices) glDisableClientState(GL_VERTEX_ARRAY) glEnable(GL_TEXTURE_2D) def points2(points, color, size=1.0, alpha=255.0): glPointSize(size) glDisable(GL_TEXTURE_2D) glBegin(GL_POINTS) glColor4f(color[0] / 255.0, color[1] / 255.0, color[2] / 255.0, alpha / 255.0) for p in points: glVertex2f(p[0], p[1]) glEnd() glEnable(GL_TEXTURE_2D) I've tested these with different size arrays of points, a small array of 250 and a large array of 2000. The first of the 3 methods I would obviously call N times in a loop. For the small array this is not an issue but for the larger array the overhead of glBegin starts to take over. The second method is better than the first but there are some weird numpy array operations that occur and add overhead with some weird interactions. If points is a regular python list there seems to be a linear increase in time with more points. If I points is a numpy array of dtype="f" it starts faster but seems to increase non-linearly. The fastest solution is the third function regardless of the size of the array. Does anyone have any thoughts on this or ideas of how I can improve any of these methods? -- Ryan Hope, M.S. CogWorks Lab Cognitive Science Department Rensselaer Polytechnic Institute |
From: Ian M. <geo...@gm...> - 2012-10-19 17:00:53
|
The most efficient ways to draw points are none of what you have here. You should look into display lists (or better, VBOs). Most of your overhead is caused by having to transfer all the data across the graphics bus to the GPU *each frame*. Display lists and VBOs both transfer the data once and then invoke the GPU to draw the cached data. Ian |
From: Ryan H. <rm...@gm...> - 2012-10-19 17:02:23
|
I think miss the point that this is a moving star field, the points are in new locations every frame. I dont see how display lists can help with dynamic data. On Fri, Oct 19, 2012 at 1:00 PM, Ian Mallett <geo...@gm...> wrote: > The most efficient ways to draw points are none of what you have here. You > should look into display lists (or better, VBOs). > > Most of your overhead is caused by having to transfer all the data across > the graphics bus to the GPU each frame. Display lists and VBOs both transfer > the data once and then invoke the GPU to draw the cached data. > > Ian -- Ryan Hope, M.S. CogWorks Lab Cognitive Science Department Rensselaer Polytechnic Institute |
From: Derakon <de...@gm...> - 2012-10-19 17:30:57
|
On Fri, Oct 19, 2012 at 10:02 AM, Ryan Hope <rm...@gm...> wrote: > I think miss the point that this is a moving star field, the points > are in new locations every frame. I dont see how display lists can > help with dynamic data. If the points aren't changing with respect to each other (e.g. they just scroll as the view changes) then you should still be able to use a display list, yes? Just set up your view transform before using the display list. Of course, if you're manually scrolling the stars then this wouldn't work. So don't manually scroll the stars. :) > > On Fri, Oct 19, 2012 at 1:00 PM, Ian Mallett <geo...@gm...> wrote: >> The most efficient ways to draw points are none of what you have here. You >> should look into display lists (or better, VBOs). >> >> Most of your overhead is caused by having to transfer all the data across >> the graphics bus to the GPU each frame. Display lists and VBOs both transfer >> the data once and then invoke the GPU to draw the cached data. >> >> Ian > > > > -- > Ryan Hope, M.S. -Chris |
From: Rajan <nag...@gm...> - 2012-10-19 17:32:05
|
The usual idea is that the star field is in one place and the camera moves through it, so the star field can stay static. If you want to move your star field and keep the camera in one place (like a hail storm), you can still get away with a static star field and a shader which adds the dynamic nature to the star field. The shader can take as input the time as parameter and add offset to each starfield coordinate depending on the time. This will be much much faster than sending new starfield coordinates each frame. A major rule of thumb for fast graphics... transfer minimum data between CPU / GPU - whatever you want to send, do it in the beginning and manipulate stuff on the GPU. On Fri, Oct 19, 2012 at 10:02 AM, Ryan Hope <rm...@gm...> wrote: > I think miss the point that this is a moving star field, the points > are in new locations every frame. I dont see how display lists can > help with dynamic data. > > On Fri, Oct 19, 2012 at 1:00 PM, Ian Mallett <geo...@gm...> wrote: > > The most efficient ways to draw points are none of what you have here. > You > > should look into display lists (or better, VBOs). > > > > Most of your overhead is caused by having to transfer all the data across > > the graphics bus to the GPU each frame. Display lists and VBOs both > transfer > > the data once and then invoke the GPU to draw the cached data. > > > > Ian > > > > -- > Ryan Hope, M.S. > CogWorks Lab > Cognitive Science Department > Rensselaer Polytechnic Institute > > > ------------------------------------------------------------------------------ > Everyone hates slow websites. So do we. > Make your web apps faster with AppDynamics > Download AppDynamics Lite for free today: > http://p.sf.net/sfu/appdyn_sfd2d_oct > _______________________________________________ > PyOpenGL Homepage > http://pyopengl.sourceforge.net > _______________________________________________ > PyOpenGL-Users mailing list > PyO...@li... > https://lists.sourceforge.net/lists/listinfo/pyopengl-users > |
From: Chris B. <chr...@no...> - 2012-10-19 17:59:56
|
On Fri, Oct 19, 2012 at 10:02 AM, Ryan Hope <rm...@gm...> wrote: > I think miss the point that this is a moving star field, the points > are in new locations every frame. I dont see how display lists can > help with dynamic data. You're right, that when the data are changing (not jsut the view on the data) you lose much of the benefit of OpenGL. NOne the less, you still can get benefit, particularly in Python, from using VBOs -- that way there is no looping in Python -- you can build a VBO from a numpy array at the speed of C. Display lists probably wont' help as you would still need to build up the list -- it's also old-style and practically deprecated approach. -Chris > On Fri, Oct 19, 2012 at 1:00 PM, Ian Mallett <geo...@gm...> wrote: >> The most efficient ways to draw points are none of what you have here. You >> should look into display lists (or better, VBOs). -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chr...@no... |
From: Ian M. <geo...@gm...> - 2012-10-19 18:16:38
|
On Fri, Oct 19, 2012 at 11:59 AM, Chris Barker <chr...@no...>wrote: > Display lists probably wont' help as you would still need to build up > the list -- it's also old-style and practically deprecated approach. > You have to build the VBO too, but yes, display lists are deprecated. As far as dynamic stars, yes, the idea is to use either a display list or a VBO and either transform or use a vertex program to move your stars. For starfields, I personally have gotten compelling results by simply making several static starfields of different sizes and then scrolling them with glTranslatef at different rates. This gives a nice parallax effect, and is essentially just as fast as drawing the stars completely static. Ian |
From: Derakon <de...@gm...> - 2012-10-19 18:27:18
|
On Fri, Oct 19, 2012 at 11:16 AM, Ian Mallett <geo...@gm...> wrote: > On Fri, Oct 19, 2012 at 11:59 AM, Chris Barker <chr...@no...> > wrote: >> >> Display lists probably wont' help as you would still need to build up >> the list -- it's also old-style and practically deprecated approach. > > You have to build the VBO too, but yes, display lists are deprecated. > > As far as dynamic stars, yes, the idea is to use either a display list or a > VBO and either transform or use a vertex program to move your stars. For > starfields, I personally have gotten compelling results by simply making > several static starfields of different sizes and then scrolling them with > glTranslatef at different rates. This gives a nice parallax effect, and is > essentially just as fast as drawing the stars completely static. It occurs to me that you could probably rig up a procedural texture that would simulate a starfield for you. Then you could just use a set of textured quads to do your parallax scrolling starfield. I'm not an OpenGL expert though; would anyone more experienced have a sense of how this would compare speedwise to the VBO approach? The advantages to a procedural texture would be that there'd be no repetition to the field, and that of course you'd never have to send more data over to the card, except for the parameters to the shader used to generate the texture. -Chris |
From: Ryan H. <rm...@gm...> - 2012-10-19 18:29:40
|
Thanks for the ideas guys. I am a complete OpenGL noob, just started using it last week so things like VBOs and shaders are a little over my head at the moment. I start looking into these things though. On Fri, Oct 19, 2012 at 2:27 PM, Derakon <de...@gm...> wrote: > On Fri, Oct 19, 2012 at 11:16 AM, Ian Mallett <geo...@gm...> wrote: >> On Fri, Oct 19, 2012 at 11:59 AM, Chris Barker <chr...@no...> >> wrote: >>> >>> Display lists probably wont' help as you would still need to build up >>> the list -- it's also old-style and practically deprecated approach. >> >> You have to build the VBO too, but yes, display lists are deprecated. >> >> As far as dynamic stars, yes, the idea is to use either a display list or a >> VBO and either transform or use a vertex program to move your stars. For >> starfields, I personally have gotten compelling results by simply making >> several static starfields of different sizes and then scrolling them with >> glTranslatef at different rates. This gives a nice parallax effect, and is >> essentially just as fast as drawing the stars completely static. > > It occurs to me that you could probably rig up a procedural texture > that would simulate a starfield for you. Then you could just use a set > of textured quads to do your parallax scrolling starfield. I'm not an > OpenGL expert though; would anyone more experienced have a sense of > how this would compare speedwise to the VBO approach? The advantages > to a procedural texture would be that there'd be no repetition to the > field, and that of course you'd never have to send more data over to > the card, except for the parameters to the shader used to generate the > texture. > > -Chris > > ------------------------------------------------------------------------------ > Everyone hates slow websites. So do we. > Make your web apps faster with AppDynamics > Download AppDynamics Lite for free today: > http://p.sf.net/sfu/appdyn_sfd2d_oct > _______________________________________________ > PyOpenGL Homepage > http://pyopengl.sourceforge.net > _______________________________________________ > PyOpenGL-Users mailing list > PyO...@li... > https://lists.sourceforge.net/lists/listinfo/pyopengl-users -- Ryan Hope, M.S. CogWorks Lab Cognitive Science Department Rensselaer Polytechnic Institute |
From: Henry G. <he...@ca...> - 2012-10-19 18:38:00
|
On Fri, 2012-10-19 at 14:29 -0400, Ryan Hope wrote: > Thanks for the ideas guys. I am a complete OpenGL noob, just started > using it last week so things like VBOs and shaders are a little over > my head at the moment. I start looking into these things though. > They're the modern way to do things. To the point that it's probably not much worth learning anything else. Henry |
From: Ian M. <geo...@gm...> - 2012-10-19 18:58:48
|
On Fri, Oct 19, 2012 at 12:37 PM, Henry Gomersall <he...@ca...> wrote: > On Fri, 2012-10-19 at 14:29 -0400, Ryan Hope wrote: > > Thanks for the ideas guys. I am a complete OpenGL noob, just started > > using it last week so things like VBOs and shaders are a little over > > my head at the moment. I start looking into these things though. > > > They're the modern way to do things. To the point that it's probably not > much worth learning anything else. > > Henry Just because they won't be supported in hardware in 10 years doesn't mean they're inherently a bad thing. Derakon is right; immediate-mode OpenGL is easy to use. No, high-end, forward-thinking applications don't use it (as much), but that doesn't mean it's a worthless technology. Plus, it sounds like the OP already knows how to use them (and they aren't hard to learn anyway). They may even have lower overhead than VBOs, because they don't require expensive buffer glBind(...). It occurs to me that you could probably rig up a procedural texture > that would simulate a starfield for you. Then you could just use a set > of textured quads to do your parallax scrolling starfield. I'm not an > OpenGL expert though; would anyone more experienced have a sense of > how this would compare speedwise to the VBO approach? The advantages > to a procedural texture would be that there'd be no repetition to the > field, and that of course you'd never have to send more data over to > the card, except for the parameters to the shader used to generate the > texture. > I would suspect that this would be much slower: any such implementation would probably be implemented as a fragment program (or at best, and OpenCL kernel). As such, unless you were very *very* careful, it would be linear with the number of pixels on the screen, and opposed to linear in the number of stars. Randomly generating the stars on the CPU into a mapped VBO implementing a circular buffer would probably accomplish much the same thing, but faster. Ian |
From: Derakon <de...@gm...> - 2012-10-19 18:41:07
|
On Fri, Oct 19, 2012 at 11:37 AM, Henry Gomersall <he...@ca...> wrote: > On Fri, 2012-10-19 at 14:29 -0400, Ryan Hope wrote: >> Thanks for the ideas guys. I am a complete OpenGL noob, just started >> using it last week so things like VBOs and shaders are a little over >> my head at the moment. I start looking into these things though. >> > They're the modern way to do things. To the point that it's probably not > much worth learning anything else. To be fair, glPoints is a heck of a lot easier to wrap your head around than VBOs are. To some extent it's worth learning the "wrong but functional" approach only to unlearn it later, in the interests of smoothing out the learning curve. Plus, it's not like support for the old functions is going to go away. They just don't work quite as well. > > Henry > -Chris |
From: Ryan H. <rm...@gm...> - 2012-10-19 18:58:55
|
I made a library that is API consistent with pygame 2d calls but uses opengl in the background. I did this because things were starting to slow down in my non HW accelerated pygame game. Now that I have the basics working I do want to learn the right way to do things. On Fri, Oct 19, 2012 at 2:41 PM, Derakon <de...@gm...> wrote: > On Fri, Oct 19, 2012 at 11:37 AM, Henry Gomersall <he...@ca...> wrote: >> On Fri, 2012-10-19 at 14:29 -0400, Ryan Hope wrote: >>> Thanks for the ideas guys. I am a complete OpenGL noob, just started >>> using it last week so things like VBOs and shaders are a little over >>> my head at the moment. I start looking into these things though. >>> >> They're the modern way to do things. To the point that it's probably not >> much worth learning anything else. > > To be fair, glPoints is a heck of a lot easier to wrap your head > around than VBOs are. To some extent it's worth learning the "wrong > but functional" approach only to unlearn it later, in the interests of > smoothing out the learning curve. > > Plus, it's not like support for the old functions is going to go away. > They just don't work quite as well. > >> >> Henry >> > > -Chris > > ------------------------------------------------------------------------------ > Everyone hates slow websites. So do we. > Make your web apps faster with AppDynamics > Download AppDynamics Lite for free today: > http://p.sf.net/sfu/appdyn_sfd2d_oct > _______________________________________________ > PyOpenGL Homepage > http://pyopengl.sourceforge.net > _______________________________________________ > PyOpenGL-Users mailing list > PyO...@li... > https://lists.sourceforge.net/lists/listinfo/pyopengl-users -- Ryan Hope, M.S. CogWorks Lab Cognitive Science Department Rensselaer Polytechnic Institute |
From: Henry G. <he...@ca...> - 2012-10-19 19:09:43
|
On Fri, 2012-10-19 at 11:41 -0700, Derakon wrote: > On Fri, Oct 19, 2012 at 11:37 AM, Henry Gomersall <he...@ca...> > wrote: > > On Fri, 2012-10-19 at 14:29 -0400, Ryan Hope wrote: > >> Thanks for the ideas guys. I am a complete OpenGL noob, just > started > >> using it last week so things like VBOs and shaders are a little > over > >> my head at the moment. I start looking into these things though. > >> > > They're the modern way to do things. To the point that it's probably > not > > much worth learning anything else. > > To be fair, glPoints is a heck of a lot easier to wrap your head > around than VBOs are. To some extent it's worth learning the "wrong > but functional" approach only to unlearn it later, in the interests of > smoothing out the learning curve. True, but when I was learning I spent ages wondering why there were multiple ways of doing everything. It was much easier for me when I realised most of them were legacy! My email was more to make that point that anything else. Henry |
From: Greg E. <gre...@ca...> - 2012-10-20 01:02:02
|
Ian Mallett wrote: > I personally have gotten compelling results by > simply making several static starfields of different sizes and then > scrolling them with glTranslatef at different rates. Or you could create a true 3D starfield and use a perspective projection. -- Greg |
From: Mike C. F. <mcf...@vr...> - 2012-10-22 19:41:52
|
On 12-10-19 12:52 PM, Ryan Hope wrote: > I am working on a pygame app that I recently converted to using opegl > for the backend. The game has a parallax star field in the background > so I have been looking for the most efficient way of drawing multiple > points. My game updates the display every 33ms. Bellow are the draw > points methods I have tried. VBO approach on my machine fullscreen at 1920x1200 shows around 280 fps (no actually change with resolution change, btw). I'm just rendering a random starfield of the same size as the Bright Star Catalog (9,100 stars). That looks good if you wander around near the center, but if you make it small enough to see changes you rapidly run out of stars. I'm guessing you want to update the stars so that you see more stars as you move out of the central star-field? That is, as you move positions you want to add another "slice" of stars off to the side toward which you are walking? Unless you are travelling faster than light (or dealing with extremely long time-scales) you don't actually see any significant parallax with a star-field AFAIK. VBO approach looks like this: from numpy import random numpy_pointset = random.rand( 9110, 3 ) points = vbo.VBO( numpy_pointset ) then, during render: glVertexPointerf(points) glEnableClientState( GL_VERTEX_ARRAY ) glDrawArrays( GL_POINTS, 0, len(points)) glDisableClientState( GL_VERTEX_ARRAY ) I'm guessing that each update will wind up scatter-shot across your VBO so you'll likely want to re-upload the whole thing each time you change the star-field. Code I'm using to test is here: http://bazaar.launchpad.net/~mcfletch/openglcontext/trunk/view/head:/tests/starfield.py <http://bazaar.launchpad.net/%7Emcfletch/openglcontext/trunk/view/head:/tests/starfield.py> Hope that helps, Mike -- ________________________________________________ Mike C. Fletcher Designer, VR Plumber, Coder http://www.vrplumber.com http://blog.vrplumber.com |
From: Derakon <de...@gm...> - 2012-10-22 19:56:29
|
On Mon, Oct 22, 2012 at 12:41 PM, Mike C. Fletcher <mcf...@vr...> wrote: > > I'm guessing you want to update the stars so that you see more stars as > you move out of the central star-field? That is, as you move positions > you want to add another "slice" of stars off to the side toward which > you are walking? Unless you are travelling faster than light (or dealing > with extremely long time-scales) you don't actually see any significant > parallax with a star-field AFAIK. The suggestion I made off-thread was to have a repetitive starfield -- a 3x3 grid of the same pattern. That way you can invisibly loop the scrolling of the pattern when you get far enough from the center -- since it's repetitive, there's no way to tell, say, the position (-10, 0) from the position (0, 0) (if each "cell" in the grid were 10x10). Make the base pattern large enough (2x screen resolution should do) and the repetition should be hard to notice. Real-life parallax would be very hard to notice on these scales, but scrolling starfields are a time-honored tradition for space games. :) -Chris |