From: Richard R. <sf...@ol...> - 2003-09-30 14:12:58
|
On Tue, Sep 30, 2003 at 08:42:35AM -0500, Steve Baker wrote: > Richard Rauch wrote: > >On Tue, Sep 30, 2003 at 09:19:36PM +1000, Nigel Stewart and Fiona Smith > >wrote: > > >Once someone points out that GLU's > >cylinder can be used for cones, whether they got that from general > >familiarity with GLU, reading GLUT sources, or studying tea-leaves, > >I think that it's okay. > > If you use the cylinder code for doing cones - won't you get an ickky > zero-sized polygon at the point of the cone? This tends to do VERY > BAD THINGS to the surface normals for shading. gluCylinder() says "Note that if {\it top} is set to 0.0, this routine generates a cone." That seems to endorse using it for cones, though your point about dependancy upon GLU makes a case for dropping it anyway. [...] > I don't think we should be sweating *ANY* effort to do anything > more than GLUT does in the area of shape generation. Yes. > >Which raises a side issue: Is freeglut thread-safe as it stands? Or is > >that a work in progress? > > I doubt it. It might be nice if it were thread-safe. Dunno if we can do that. (My "thread" experience is limited to the Amiga where all processes shared the same memory space. I haven't ever dealt with POSIX threads and don't know what the conventions or issues would be.) > >>>...and there are probably not-too-uncommon cases where the client > >>>application is going to ask for a BUNCH of cones with the same number > >>>of points around. If the {slices} count is the same, you can skip > >>>the whole business about (re)filling the array. > >> > >> A good case for an OpenGL display list. > > ...in the application - yes. In freeglut - No. There is no way for I took him to mean that the application programmer should be smart enough to use a display list (or some other mechanism) if they are doing a bunch of more or less identical cones. A point which I extrapolate to virtually all issues about efficiency with the basic shape support in GLUT (aside from the by-design limited nature of GLUT shapes). > But really - these shapes are almost irrelevent. I could care less > how efficient they are - so long as they work and do exactly what > GLUT does - that's good enough. I only wish to raise three additional points: * Code clarity. Even in an infrequently-visited corner, this is a plus. And if you do it while fixing bugs, all to the better, since you have to be in that corner anyway. * Some points (such as removing precomputed tables whose purpose is solely to optimize code) are worth making and discussing. In those two ways, I'm willing to sweat a bit over the GLUT shapes. -- "I probably don't know what I'm talking about." http://www.olib.org/~rkr/ |