pyopengl-users

[PyOpenGL-Users] Fastest way to draw many spheres

[Mads I. <mad...@gm...>]

Hi,

We are developing a molecular modeling application which basically boils 
down to drawing of the order 10000-60000 spheres when viewing the larger 
system. So far we render spheres by adding a unit gluSphere to a display 
list and then scaling and positioning this appropriately for each atom 
in the system.

I am aware that display lists are old-school. So my questions boils down 
to this: What is the defacto fastest way of rendering a sphere in a 
modern OpenGL framework?

Best regards,

Mads

-- 
+--------------------------------------------------------------+
| Mads Ipsen, Scientific developer                             |
+-------------------------------+------------------------------+
| QuantumWise A/S               | phone:          +45-29716388 |
| Nørre Søgade 27A              | www:     www.quantumwise.com |
| DK-1370 Copenhagen K, Denmark | email:  mad...@gm... |
+-------------------------------+------------------------------+

Re: [PyOpenGL-Users] Fastest way to draw many spheres

[Ian M. <geo...@gm...>]

On Tue, Jan 25, 2011 at 9:56 AM, Mads Ipsen <mad...@gm...> wrote:

> Hi,
>
> We are developing a molecular modeling application which basically boils
> down to drawing of the order 10000-60000 spheres when viewing the larger
> system. So far we render spheres by adding a unit gluSphere to a display
> list and then scaling and positioning this appropriately for each atom
> in the system.
>
> I am aware that display lists are old-school. So my questions boils down
> to this: What is the defacto fastest way of rendering a sphere in a
> modern OpenGL framework?
>
> Best regards,
>
> Mads
>
There's nothing wrong with display lists.  It's just that they're
technically deprecated in future version of OpenGL.  However, because so
much code uses display lists, and because it's overall a very good way of
doing things, I predict support for them won't drop for at least another
decade.  Display lists can also have beer performance than vertex buffer
objects (VBOs), which are the current standard.

VBOs are almost as fast as display lists, but also support a number of fun
features, especially dynamically changing just *sections* of the data.

However, what you're doing is suboptimal to begin with.  10,000-60,000
spheres is a lot of geometry.  Even if you only had 12 vertices per sphere
(icosahedron), that's still around 120,000-720,000 vertices, which is . . .
doable, but only just.  Transforming each sphere to the right position will
take FAR too long individually (10,000-60,000 glTranslate and 10,000-60,000
glScale calls each draw will really eat your framerate).

As I see it, you have two general solutions:

A) Load a single display list (or VBO) containing ALL the spheres positioned
and scaled correctly.
B) Store the desired positions and scalars of each atom as single pixels in
a texture.  For each sphere, give each of its vertice a vertex attribute
corresponding to the sphere's position/scale in the texture.  Draw your
10,000-60,000 spheres in the same place (probably with a DL or VBO), and
then a shader will take care of moving them to the correct place and scaling
them appropriately, based on the information stored in the texture.

The second option has the advantage that, by changing the texture, you can
move the atoms around--you might even write a shader to do this, and have a
full molecular simulation running on the GPU!

Finally, for an extra speed kick, you can use impostors (i.e., point sprites
with an image of a sphere on them).  This will cut the number of vertices
per sphere to 1, which will VASTLY improve performance.  If you write a
shader to output depth, and discard fragments outside the sphere,
intersection with other objects will work exactly the way it would if the
atoms where actual spheres.  Note that doing this procedure is applicable to
both A and B.

Ian

Re: [PyOpenGL-Users] Fastest way to draw many spheres

[Mads I. <mad...@gm...>]

Ian Mallett wrote:
> On Tue, Jan 25, 2011 at 9:56 AM, Mads Ipsen <mad...@gm... 
> <mailto:mad...@gm...>> wrote:
>
>     Hi,
>
>     We are developing a molecular modeling application which basically
>     boils
>     down to drawing of the order 10000-60000 spheres when viewing the
>     larger
>     system. So far we render spheres by adding a unit gluSphere to a
>     display
>     list and then scaling and positioning this appropriately for each atom
>     in the system.
>
>     I am aware that display lists are old-school. So my questions
>     boils down
>     to this: What is the defacto fastest way of rendering a sphere in a
>     modern OpenGL framework?
>
>     Best regards,
>
>     Mads
>
> There's nothing wrong with display lists.  It's just that they're 
> technically deprecated in future version of OpenGL.  However, because 
> so much code uses display lists, and because it's overall a very good 
> way of doing things, I predict support for them won't drop for at 
> least another decade.  Display lists can also have beer performance 
> than vertex buffer objects (VBOs), which are the current standard.
>
> VBOs are almost as fast as display lists, but also support a number of 
> fun features, especially dynamically changing just *sections* of the 
> data. 
>
> However, what you're doing is suboptimal to begin with.  10,000-60,000 
> spheres is a lot of geometry.  Even if you only had 12 vertices per 
> sphere (icosahedron), that's still around 120,000-720,000 vertices, 
> which is . . . doable, but only just.  Transforming each sphere to the 
> right position will take FAR too long individually (10,000-60,000 
> glTranslate and 10,000-60,000 glScale calls each draw will really eat 
> your framerate). 
>
> As I see it, you have two general solutions:
>
> A) Load a single display list (or VBO) containing ALL the spheres 
> positioned and scaled correctly. 
> B) Store the desired positions and scalars of each atom as single 
> pixels in a texture.  For each sphere, give each of its vertice a 
> vertex attribute corresponding to the sphere's position/scale in the 
> texture.  Draw your 10,000-60,000 spheres in the same place (probably 
> with a DL or VBO), and then a shader will take care of moving them to 
> the correct place and scaling them appropriately, based on the 
> information stored in the texture. 
Can you direct me to some pointers for getting started on this type of 
approach. I am pretty new to shaders so it probably has to be pretty 
simple as a starter.
>
> The second option has the advantage that, by changing the texture, you 
> can move the atoms around--you might even write a shader to do this, 
> and have a full molecular simulation running on the GPU!
>
> Finally, for an extra speed kick, you can use impostors (i.e., point 
> sprites with an image of a sphere on them).  This will cut the number 
> of vertices per sphere to 1, which will VASTLY improve performance.  
> If you write a shader to output depth, and discard fragments outside 
> the sphere, intersection with other objects will work exactly the way 
> it would if the atoms where actual spheres.  Note that doing this 
> procedure is applicable to both A and B. 
>
> Ian


-- 
+--------------------------------------------------------------+
| Mads Ipsen, Scientific developer                             |
+-------------------------------+------------------------------+
| QuantumWise A/S               | phone:          +45-29716388 |
| Nørre Søgade 27A              | www:     www.quantumwise.com |
| DK-1370 Copenhagen K, Denmark | email:  mad...@gm... |
+-------------------------------+------------------------------+

Re: [PyOpenGL-Users] Fastest way to draw many spheres

[Ian M. <geo...@gm...>]

On Tue, Jan 25, 2011 at 11:04 AM, Mads Ipsen <mad...@gm...> wrote:

> Can you direct me to some pointers for getting started on this type of
> approach. I am pretty new to shaders so it probably has to be pretty simple
> as a starter.
>
Not really.  It's probably too complicated that, if you can't get it from
that description, it's not practical to try to implement.  It's not really a
thing there are tutorials on either.

If you're new to shaders, then I recommend choice A.  It will run a little
bit faster (no texture samplers), and you won't really even need a shader.
If you need more speed after this (you probably will), then implement point
sprites (for good results, you will need a shader, but there are tutorials
on that).

Ian