From: <ja...@ma...> - 2006-06-19 19:19:41
|
Hi, I'm writing a 3D molecular viewer for Kalzium (in KDE-edu), to be released with KDE 4. I need to render spheres, and I need to optimize that for PCs without hardware acceleration. So I'd like to ask the following questions, all being understood in the context of software-only rendering: 1) Is glDrawArrays much faster than glDrawElements ? 2) Are VBOs faster than traditional Vertex Arrays ? 3) Is there already some fast sphere rendering code out there, which I might include in a GPL'd project ? Please CC me, I've not subscribed to this list. Cheers, Benoit |
From: Brian P. <bri...@tu...> - 2006-06-20 15:41:47
|
Beno=EEt Jacob wrote: > Hi, >=20 > I'm writing a 3D molecular viewer for Kalzium (in KDE-edu), to be relea= sed=20 > with KDE 4. >=20 > I need to render spheres, and I need to optimize that for PCs without h= ardware=20 > acceleration. >=20 > So I'd like to ask the following questions, all being understood in the= =20 > context of software-only rendering: >=20 > 1) Is glDrawArrays much faster than glDrawElements ? Hard to say. If your primitive has lots of shared vertices,=20 glDrawElements might be a bit faster. > 2) Are VBOs faster than traditional Vertex Arrays ? Not necessarily. It depends on the particular OpenGL driver. If VBOs=20 can actually live on-card, for example, they can be a win. > 3) Is there already some fast sphere rendering code out there, which I = might=20 > include in a GPL'd project ? A web search should turn up something. I'd suggest looking for a=20 tesselation algorithm that produces a geodesic sphere, rather than the=20 slices/stacks type of gluSphere(). You'll get nicer results. I think the original GLUT distro has a geodesic sphere demo. If you don't need a geometric (vertices/normals) sphere, you might=20 consider using "impostors" rendered with a vertex/fragment program.=20 You'd just render a square quadrilateral. The fragment program would=20 compute the Z value and shading/color of each pixel in the quad to=20 wind up with the image of a sphere. -Brian |
From: Benoit J. <ja...@ma...> - 2006-06-21 11:41:30
|
Hi, I am not so sure anymore that I need "real" 3d primitives, and your "impostors" look very interesting to me. I have seen on mesa3d.org that shading language support is available as of Mesa 6.5, but it says that it's a development release, so when will there be a stable release with this feature? I'd need it to be stable before KDE4 is beta, which is about the end of 2006. Also what happens if the user has a 3d graphics card with a GL driver not supporting the shading language : on X11, will rendering then fall back to the software implementation in Mesa? And what will happen on Windows? (KDE4 will likely also be released for Windows) I need to draw molecules where the atoms are rendered as spheres, and the bonds between the atoms are rendered as cylinders. Do you think that is doable with impostors? I mean, do you think there can be a cylinder impostor? Another style of rendering that I need to do is : the atoms are rendered as big, intersecting spheres, and the bonds are not rendered (completely hidden by the spheres). Do you think intersection of spheres can be correctly handled by impostors? I mean, can I write an impostor that writes correctly in the z-buffer for each pixel? Also I need a good fillrate. That's, say, rendering a molecule with 20 atoms at 20 fps in a 500x500 window on a pentium III at 1 GHz. Is that possible with the Mesa software shading language implementation? Thank you very much Benoit |
From: <ran...@nc...> - 2006-06-20 16:49:35
|
Hello=2C If you really want fast spheres on PCs w/o HW=2C don=27t use OpenGL=2E Spheres are a very special case and there are very fast mechanisms to render them=2E As Brian mentions=2C you can use 2D impostors and = something like the OpenGL point sprite=2E If you include occlusion culling (explicit via spatial hash=2C not via OpenGL)=2C you can easily render nearly many tens of thousands of spheres per second on most = machines in SW and I have seen custom software renderers for spheres capable of a million (effective) spheres/sec=2E Brian notes the use of a fragment program for handling the Z intersections=2C but you can also do this as a post process using a good Eucliean distance map approximation (e=2Eg=2E just render a single point for each non-occluded = sphere location with depth and radius=2C then apply conditinoal 2D image processing dilation techniques to generate the = appropriate spheres)=2E Much faster than OpenGL IMHO=2E Thanks=2E ----- Original Message ----- From=3A Brian Paul =3Cbrian=2Epaul=40tungstengraphics=2Ecom=3E Date=3A Tuesday=2C June 20=2C 2006 11=3A42 am Subject=3A Re=3A =5BMesa3d-users=5D efficient rendering of spheres withou= t hw accel To=3A Beno=EEt Jacob =3Cjacob=40math=2Ejussieu=2Efr=3E Cc=3A mesa3d-users=40lists=2Esourceforge=2Enet =3E Beno=EEt Jacob wrote=3A =3E =3E Hi=2C =3E =3E = =3E =3E I=27m writing a 3D molecular viewer for Kalzium (in KDE-edu)=2C t= o be = =3E released = =3E =3E with KDE 4=2E =3E =3E = =3E =3E I need to render spheres=2C and I need to optimize that for PCs = =3E without hardware = =3E =3E acceleration=2E =3E =3E = =3E =3E So I=27d like to ask the following questions=2C all being underst= ood = =3E in the = =3E =3E context of software-only rendering=3A =3E =3E = =3E =3E 1) Is glDrawArrays much faster than glDrawElements =3F =3E = =3E Hard to say=2E If your primitive has lots of shared vertices=2C = =3E glDrawElements might be a bit faster=2E =3E = =3E = =3E =3E 2) Are VBOs faster than traditional Vertex Arrays =3F =3E = =3E Not necessarily=2E It depends on the particular OpenGL driver=2E If= = =3E VBOs = =3E can actually live on-card=2C for example=2C they can be a win=2E =3E = =3E = =3E =3E 3) Is there already some fast sphere rendering code out there=2C = =3E which I might = =3E =3E include in a GPL=27d project =3F =3E = =3E A web search should turn up something=2E I=27d suggest looking for a= = =3E tesselation algorithm that produces a geodesic sphere=2C rather than = =3E the = =3E slices/stacks type of gluSphere()=2E You=27ll get nicer results=2E =3E = =3E I think the original GLUT distro has a geodesic sphere demo=2E =3E = =3E If you don=27t need a geometric (vertices/normals) sphere=2C you migh= t = =3E consider using =22impostors=22 rendered with a vertex/fragment progra= m=2E = =3E You=27d just render a square quadrilateral=2E The fragment program = =3E would = =3E compute the Z value and shading/color of each pixel in the quad to = =3E wind up with the image of a sphere=2E =3E = =3E -Brian =3E = =3E = =3E =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F =3E Mesa3d-users mailing list =3E Mesa3d-users=40lists=2Esourceforge=2Enet =3E https=3A//lists=2Esourceforge=2Enet/lists/listinfo/mesa3d-users =3E |
From: <ja...@ma...> - 2006-06-20 17:04:50
|
Thanks a lot, Brian and Randall! As spheres aren't the only thing I have to render, I think I really have to= =20 use OpenGL. Also I probably need a real, geometric sphere. I think I'll go= =20 for a traditional, indexed vertex array. I'll look for code generating a=20 geo-sphere. Many thanks, Benoit Le mardi 20 juin 2006 18:49, vous avez =E9crit=A0: > Hello, > If you really want fast spheres on PCs w/o HW, > don't use OpenGL. Spheres are a very special case > and there are very fast mechanisms to render them. > As Brian mentions, you can use 2D impostors and > something like the OpenGL point sprite. If you > include occlusion culling (explicit via spatial hash, > not via OpenGL), you can easily render nearly many > tens of thousands of spheres per second on most > machines in SW and I have seen custom software renderers > for spheres capable of a million (effective) spheres/sec. > Brian notes the use of a fragment program for handling > the Z intersections, but you can also do this as a post > process using a good Eucliean distance map approximation > (e.g. just render a single point for each non-occluded > sphere location with depth and radius, then apply conditinoal > 2D image processing dilation techniques to generate the > appropriate spheres). Much faster than OpenGL IMHO. > > Thanks. |
From: <ran...@nc...> - 2006-06-21 12:46:42
|
Hello, The shading language is in SW in Mesa and using it cuts the fill-rate a great deal. That having been said, cylinder imposters come in a couple of forms, but as long as the ends of the cylinders are "filled" with spheres (either end entirely inside a sphere or they are "capped" with a sphere), cylinder imposters work just fine. The simplest is a planar rectangle. You can use a thick line, but you would have to adjust the thickness based on projected angle because of how OpenGL renders these. If you are using dilation techniques, the base pimitive is a depth buffered line segment and you compute the Euclidean distance map off the line, mapped to a half circle (for lighting). Thanks. ----- Original Message ----- From: Benoit Jacob <ja...@ma...> Date: Wednesday, June 21, 2006 7:41 am Subject: Re: [Mesa3d-users] efficient rendering of spheres without hw accel To: mes...@li... Cc: Brian Paul <bri...@tu...> > Hi, > > I am not so sure anymore that I need "real" 3d primitives, and your > "impostors" look very interesting to me. > > I have seen on mesa3d.org that shading language support is > available as of > Mesa 6.5, but it says that it's a development release, so when will > therebe a stable release with this feature? I'd need it to be > stable before > KDE4 is beta, which is about the end of 2006. > > Also what happens if the user has a 3d graphics card with a GL > driver not > supporting the shading language : on X11, will rendering then fall > back to > the software implementation in Mesa? And what will happen on Windows? > (KDE4 will likely also be released for Windows) > > I need to draw molecules where the atoms are rendered as spheres, > and the > bonds between the atoms are rendered as cylinders. Do you think > that is > doable with impostors? I mean, do you think there can be a cylinder > impostor? > > Another style of rendering that I need to do is : the atoms are > renderedas big, intersecting spheres, and the bonds are not > rendered (completely > hidden by the spheres). Do you think intersection of spheres can be > correctly handled by impostors? I mean, can I write an impostor that > writes correctly in the z-buffer for each pixel? > > Also I need a good fillrate. That's, say, rendering a molecule with 20 > atoms at 20 fps in a 500x500 window on a pentium III at 1 GHz. Is that > possible with the Mesa software shading language implementation? > > Thank you very much > Benoit > > > _______________________________________________ > Mesa3d-users mailing list > Mes...@li... > https://lists.sourceforge.net/lists/listinfo/mesa3d-users > |
From: Benoit J. <ja...@ma...> - 2006-06-21 12:52:46
|
Thanks for your help! On Wed, 21 Jun 2006 ran...@nc... wrote: > The shading language is in SW in Mesa and using it > cuts the fill-rate a great deal. I see. So what is faster, when using Mesa: impostors using the shading language, or vertex arrays? Benoit |
From: Brian P. <bri...@tu...> - 2006-06-21 14:33:09
|
Benoit Jacob wrote: > Thanks for your help! > > On Wed, 21 Jun 2006 ran...@nc... wrote: > >> The shading language is in SW in Mesa and using it >>cuts the fill-rate a great deal. > > > I see. So what is faster, when using Mesa: impostors using the shading > language, or vertex arrays? With software rendering, vertex arrays would definitely be faster. If you were using an OpenGL/Mesa driver that had hardware support for the shading language (or vertex/fragment programs) impostors may be faster, especially if you want high quality (no visible tesselation). When asking questions about performance, you need to consider the fact that different OpenGL implementations, drivers and hardware may have very different performance characteristics. Even with Mesa, there's a lot of different drivers with different features and performance levels. -Brian |
From: Benoit J. <ja...@ma...> - 2006-06-21 14:45:09
|
> > I see. So what is faster, when using Mesa: impostors using the shading > > language, or vertex arrays? > > With software rendering, vertex arrays would definitely be faster. Many thanks, that's what I needed to know. Benoit |