From: Diederick C. N. <dc...@gm...> - 2012-03-10 03:35:00
|
Dear all, I noticed that there is a lot of code duplication in freeglut_geometry. It'd be easily cleaned up. E.g. void FGAPIENTRY glutWireTetrahedron( void ) { FREEGLUT_EXIT_IF_NOT_INITIALISED ( "glutWireTetrahedron" ); glBegin( GL_LINE_LOOP ) ; glNormal3d ( -tet_r[0][0], -tet_r[0][1], -tet_r[0][2] ) ; glVertex3dv ( tet_r[1] ) ; glVertex3dv ( tet_r[3] ) ; glVertex3dv ( tet_r[2] ) ; glNormal3d ( -tet_r[1][0], -tet_r[1][1], -tet_r[1][2] ) ; glVertex3dv ( tet_r[0] ) ; glVertex3dv ( tet_r[2] ) ; glVertex3dv ( tet_r[3] ) ; glNormal3d ( -tet_r[2][0], -tet_r[2][1], -tet_r[2][2] ) ; glVertex3dv ( tet_r[0] ) ; glVertex3dv ( tet_r[3] ) ; glVertex3dv ( tet_r[1] ) ; glNormal3d ( -tet_r[3][0], -tet_r[3][1], -tet_r[3][2] ) ; glVertex3dv ( tet_r[0] ) ; glVertex3dv ( tet_r[1] ) ; glVertex3dv ( tet_r[2] ) ; glEnd() ; } void FGAPIENTRY glutSolidTetrahedron( void ) { FREEGLUT_EXIT_IF_NOT_INITIALISED ( "glutSolidTetrahedron" ); glBegin( GL_TRIANGLES ) ; glNormal3d ( -tet_r[0][0], -tet_r[0][1], -tet_r[0][2] ) ; glVertex3dv ( tet_r[1] ) ; glVertex3dv ( tet_r[3] ) ; glVertex3dv ( tet_r[2] ) ; glNormal3d ( -tet_r[1][0], -tet_r[1][1], -tet_r[1][2] ) ; glVertex3dv ( tet_r[0] ) ; glVertex3dv ( tet_r[2] ) ; glVertex3dv ( tet_r[3] ) ; glNormal3d ( -tet_r[2][0], -tet_r[2][1], -tet_r[2][2] ) ; glVertex3dv ( tet_r[0] ) ; glVertex3dv ( tet_r[3] ) ; glVertex3dv ( tet_r[1] ) ; glNormal3d ( -tet_r[3][0], -tet_r[3][1], -tet_r[3][2] ) ; glVertex3dv ( tet_r[0] ) ; glVertex3dv ( tet_r[1] ) ; glVertex3dv ( tet_r[2] ) ; glEnd() ; } Can easily be refactored to: /* * Only difference between solid and wire versions is the way vertices are drawn, * so we can take a function with the mode as input to reduce copy paste code. */ void fghTetrahedron( GLenum vertexMode ) { glBegin( vertexMode ) ; glNormal3d ( -tet_r[0][0], -tet_r[0][1], -tet_r[0][2] ) ; glVertex3dv ( tet_r[1] ) ; glVertex3dv ( tet_r[3] ) ; glVertex3dv ( tet_r[2] ) ; glNormal3d ( -tet_r[1][0], -tet_r[1][1], -tet_r[1][2] ) ; glVertex3dv ( tet_r[0] ) ; glVertex3dv ( tet_r[2] ) ; glVertex3dv ( tet_r[3] ) ; glNormal3d ( -tet_r[2][0], -tet_r[2][1], -tet_r[2][2] ) ; glVertex3dv ( tet_r[0] ) ; glVertex3dv ( tet_r[3] ) ; glVertex3dv ( tet_r[1] ) ; glNormal3d ( -tet_r[3][0], -tet_r[3][1], -tet_r[3][2] ) ; glVertex3dv ( tet_r[0] ) ; glVertex3dv ( tet_r[1] ) ; glVertex3dv ( tet_r[2] ) ; glEnd() ; } void FGAPIENTRY glutWireTetrahedron( void ) { FREEGLUT_EXIT_IF_NOT_INITIALISED ( "glutWireTetrahedron" ); fghTetrahedron( GL_LINE_LOOP ); } void FGAPIENTRY glutSolidTetrahedron( void ) { FREEGLUT_EXIT_IF_NOT_INITIALISED ( "glutSolidTetrahedron" ); fghTetrahedron( GL_TRIANGLES ); } Shall I go ahead and do that for this and the other object in there? I'll put the body of the solid and wire version through a diff tool for each first to make sure they really are identical. This allows me to do a bit of structuring in the file too. Best, Dee |
From: John T. <nu...@me...> - 2012-03-10 14:46:23
|
On Sat, Mar 10, 2012 at 11:34:53AM +0800, Diederick C. Niehorster wrote: > Dear all, > > I noticed that there is a lot of code duplication in > freeglut_geometry. It'd be easily cleaned up. > > .... > > void FGAPIENTRY glutWireTetrahedron( void ) > { > FREEGLUT_EXIT_IF_NOT_INITIALISED ( "glutWireTetrahedron" ); > > fghTetrahedron( GL_LINE_LOOP ); > } > void FGAPIENTRY glutSolidTetrahedron( void ) > { > FREEGLUT_EXIT_IF_NOT_INITIALISED ( "glutSolidTetrahedron" ); > > fghTetrahedron( GL_TRIANGLES ); > } > > Shall I go ahead and do that for this and the other object in there? > I'll put the body of the solid and wire version through a diff tool > for each first to make sure they really are identical. > > This allows me to do a bit of structuring in the file too. Very nice, go ahead. Actually I think this kind of restructuring is minor and safe enough that falls under the just do it without asking category. -- John Tsiombikas http://nuclear.mutantstargoat.com/ |
From: Diederick C. N. <dc...@gm...> - 2012-03-10 17:45:05
|
Hi John, On Sat, Mar 10, 2012 at 22:46, John Tsiombikas <nu...@me...> wrote: > Very nice, go ahead. Actually I think this kind of restructuring is > minor and safe enough that falls under the just do it without asking > category Thanks. I'll work on it soon. Best, Dee |
From: John T. <nu...@me...> - 2012-03-14 14:12:47
|
On Wed, Mar 14, 2012 at 07:43:50AM -0600, Paul Martz wrote: > Hey guys -- > > glVertexPointer/glNormalPointer/etc are all deprecated in OpenGL 3.0 and removed > in 3.1: must use generic vertex attributes (glVertexAttrib) instead Indeed, but that is not a big problem. It's easy to conditionally compile code that calls either glVertexPointer, or glVertexAttrib(VERTEX_LOC, ...). The complication, and I'm sure this came up on this list the last time someone suggested converting everything to GL3.x, is that the result would not be very flexible, as we can't easily accomodate custom user shaders without changes to the API. > and I forgot when this was added to core OpenGL but it was not 1.1. You are mistaken, as I said, vertex arrays where introduced in OpenGL 1.1 and are available on windows without resorting to extensions: http://www.opengl.org/registry/doc/glspec11.ps > So on Windows, there's no way to access the OpenGL functionality we > need unless we introduce a dependency on something like GLEW. GLEW?! Absolutely not. GLEW is convenient, and I use it in almost all my programs, but adding it as a dependency to freeglut is out of the question. If we need to access any OpenGL functionality through extensions, we'll have to do it manually. -- John Tsiombikas http://nuclear.mutantstargoat.com/ |
From: John F. F. <joh...@cy...> - 2012-03-11 02:18:31
|
I'll second that. - John F. On 3/10/2012 8:46 AM, John Tsiombikas wrote: > On Sat, Mar 10, 2012 at 11:34:53AM +0800, Diederick C. Niehorster wrote: > >> Dear all, >> >> I noticed that there is a lot of code duplication in >> freeglut_geometry. It'd be easily cleaned up. >> >> .... >> >> void FGAPIENTRY glutWireTetrahedron( void ) >> { >> FREEGLUT_EXIT_IF_NOT_INITIALISED ( "glutWireTetrahedron" ); >> >> fghTetrahedron( GL_LINE_LOOP ); >> } >> void FGAPIENTRY glutSolidTetrahedron( void ) >> { >> FREEGLUT_EXIT_IF_NOT_INITIALISED ( "glutSolidTetrahedron" ); >> >> fghTetrahedron( GL_TRIANGLES ); >> } >> >> Shall I go ahead and do that for this and the other object in there? >> I'll put the body of the solid and wire version through a diff tool >> for each first to make sure they really are identical. >> >> This allows me to do a bit of structuring in the file too. >> > Very nice, go ahead. Actually I think this kind of restructuring is > minor and safe enough that falls under the just do it without asking > category. > > |
From: Paul M. <pm...@sk...> - 2012-03-11 14:57:07
|
The code in question uses the old GL 1.0 glBegin/glEnd drawing paradigm. At some point, I'd like to port this code to use non-deprecated drawing commands (i.e., glDrawElements), but it's unlikely I'll have time to do this in the near future. But, now that Dee has brought up modifying this code, I thought I'd mention the deprecated commands so that he can hopefully bring the code into the 21st century, while he's in there making other changes. -Paul On 3/10/2012 6:49 PM, John F. Fay wrote: > I'll second that. > > - John F. > > > On 3/10/2012 8:46 AM, John Tsiombikas wrote: >> On Sat, Mar 10, 2012 at 11:34:53AM +0800, Diederick C. Niehorster wrote: >> >>> Dear all, >>> >>> I noticed that there is a lot of code duplication in >>> freeglut_geometry. It'd be easily cleaned up. >>> >>> .... >>> >>> void FGAPIENTRY glutWireTetrahedron( void ) >>> { >>> FREEGLUT_EXIT_IF_NOT_INITIALISED ( "glutWireTetrahedron" ); >>> >>> fghTetrahedron( GL_LINE_LOOP ); >>> } >>> void FGAPIENTRY glutSolidTetrahedron( void ) >>> { >>> FREEGLUT_EXIT_IF_NOT_INITIALISED ( "glutSolidTetrahedron" ); >>> >>> fghTetrahedron( GL_TRIANGLES ); >>> } >>> >>> Shall I go ahead and do that for this and the other object in there? >>> I'll put the body of the solid and wire version through a diff tool >>> for each first to make sure they really are identical. >>> >>> This allows me to do a bit of structuring in the file too. >>> >> Very nice, go ahead. Actually I think this kind of restructuring is >> minor and safe enough that falls under the just do it without asking >> category. >> >> > > ------------------------------------------------------------------------------ > Virtualization& Cloud Management Using Capacity Planning > Cloud computing makes use of virtualization - but cloud computing > also focuses on allowing computing to be delivered as a service. > http://www.accelacomm.com/jaw/sfnl/114/51521223/ > _______________________________________________ > Freeglut-developer mailing list > Fre...@li... > https://lists.sourceforge.net/lists/listinfo/freeglut-developer > > |
From: Paul M. <pm...@sk...> - 2012-03-14 15:05:18
|
On 3/14/2012 8:12 AM, John Tsiombikas wrote: > On Wed, Mar 14, 2012 at 07:43:50AM -0600, Paul Martz wrote: >> Hey guys -- >> >> glVertexPointer/glNormalPointer/etc are all deprecated in OpenGL 3.0 and removed >> in 3.1: must use generic vertex attributes (glVertexAttrib) instead > > Indeed, but that is not a big problem. It's easy to > conditionally compile code that calls either glVertexPointer, or > glVertexAttrib(VERTEX_LOC, ...). The complication, and I'm sure this > came up on this list the last time someone suggested converting > everything to GL3.x, is that the result would not be very flexible, as we > can't easily accomodate custom user shaders without changes to the API. If you're referring to the attribute naming issue, I think the solution would be for the application to use a #define in their shader source. For example, if we decide freeglut will send vertices named "fg_Vertex", then the app would add this line at the top of their shader source: #define fg_Vertex myShader_Vertex; This would allow the rest of their shader source to use "myShader_Vertex". >> and I forgot when this was added to core OpenGL but it was not 1.1. > > You are mistaken, as I said, vertex arrays where introduced in OpenGL > 1.1 and are available on windows without resorting to extensions: > http://www.opengl.org/registry/doc/glspec11.ps Sorry, apparently I'm not communicating clearly. - Yes, you're right: glVertexPointer, glNormalPointer, etc., were added in GL 1.1, but they are removed in 3.1. - Generic vertex attributes (glVertexAttribPointer) replace glVertexPointer and friends, but were not introduced until GL 2.0, so are unavailable on Windows without a tool like GLEW. > GLEW?! Absolutely not. GLEW is convenient, and I use it in almost all my > programs, but adding it as a dependency to freeglut is out of the > question. If we need to access any OpenGL functionality through > extensions, we'll have to do it manually. In my email, I suggested GLEW as a soft dependency, but if you prefer doing it manually then it's disappointing that we can't use an off the shelf solution for something so mundane, but I defer to you folks on how you want to run freeglut. -Paul |
From: Diederick C. N. <dc...@gm...> - 2012-03-16 09:38:26
|
On Fri, Mar 16, 2012 at 17:33, Diederick C. Niehorster <dc...@gm...> wrote: > Hi Sylvain, > > On Fri, Mar 16, 2012 at 17:31, Diederick C. Niehorster > <dc...@gm...> wrote: >> Ok. So it would be good to try to keep all shapes as triangles? For a >> cube thats easy. >> I'm trying to figure out the Dodecahedron right now, we can't stream >> the polygons all in one drawarray. Converting to triangles is probably >> best, as that'll work on all platforms later as well. > > Oh wait, that gets us into trouble when drawing the wireframe version > of course... Guess I'll be sending along edgeflags as well for objects with anything other than triangles as primitives. Does that work on OpenGL ES and OpenGL 3+? Best, Dee |
From: Sylvain <be...@be...> - 2012-03-16 11:02:22
|
Hi Diederick, On Fri, Mar 16, 2012 at 05:38:16PM +0800, Diederick C. Niehorster wrote: > On Fri, Mar 16, 2012 at 17:33, Diederick C. Niehorster > <dc...@gm...> wrote: > > Hi Sylvain, > > > > On Fri, Mar 16, 2012 at 17:31, Diederick C. Niehorster > > <dc...@gm...> wrote: > >> Ok. So it would be good to try to keep all shapes as triangles? For a > >> cube thats easy. > >> I'm trying to figure out the Dodecahedron right now, we can't stream > >> the polygons all in one drawarray. Converting to triangles is probably > >> best, as that'll work on all platforms later as well. > > > > Oh wait, that gets us into trouble when drawing the wireframe version > > of course... > > Guess I'll be sending along edgeflags as well for objects with > anything other than triangles as primitives. Does that work on OpenGL > ES and OpenGL 3+? Can you check if the functions / constants you use are valid in GLES? (I posted the links to the reference HTML man pages in my previous post.) -- Sylvain |
From: Diederick C. N. <dc...@gm...> - 2012-03-18 12:15:44
|
On Sun, Mar 18, 2012 at 18:42, Sylvain <be...@be...> wrote: > Hi, > > There's definitely progress on the Android side (see pic) :) Cool! Nice work :) Dee |
From: Diederick C. N. <dc...@gm...> - 2012-03-16 11:12:49
|
Hi Sylvain, On Fri, Mar 16, 2012 at 19:02, Sylvain <be...@be...> wrote: >> >> Guess I'll be sending along edgeflags as well for objects with >> anything other than triangles as primitives. Does that work on OpenGL >> ES and OpenGL 3+? > > Can you check if the functions / constants you use are valid in GLES? > (I posted the links to the reference HTML man pages in my previous > post.) Thats sucks, no they are not (nor are they in OpenGL 3 by the way). Also, the only drawing primitives are GL_POINTS, GL_LINE_STRIP, GL_LINE_LOOP, GL_LINES, GL_TRIANGLE_STRIP, GL_TRIANGLE_FAN, and GL_TRIANGLES. So I guess we'll have to look for another solution. Itd be best if we can keep the code as similar as possible for all platforms, let me see what I can do with these materials. Best, Dee |
From: Sylvain <be...@be...> - 2012-03-18 18:40:11
|
(moving a private discussion on the list) About the double vs. float issue, GLdouble and GL_DOUBLE are just missing in GLES. Internally, we'll have to pass vertices/normals/etc. to glVertexPointer using the best available precision. Externally, in almost all case using GLdouble or GLfloat in the API doesn't have any impact because of C automatic type translation (I'm not sure there's a different in passing the cube size as a float or as a double.) The only case where there an issue is with Sierpinski, because of the 'offset' _array_ of doubles, which isn't translated automatically to an array of floats. This means that if we use GLfloat in GLES, code that passes a double* won't compile with the GLES version. So we have 2 choices: - Convert everything to float for ES builds, can be done with a few #ifdef - Keep the API stable across ES and non-ES by always using double in geometry functions prototypes, and #ifdef to float more selectively in fg_geometry. -- Sylvain |
From: Diederick C. N. <dc...@gm...> - 2012-03-16 11:43:58
|
Hi all, On Fri, Mar 16, 2012 at 19:12, Diederick C. Niehorster <dc...@gm...> wrote: > Thats sucks, no they are not (nor are they in OpenGL 3 by the way). > Also, the only drawing primitives are GL_POINTS, GL_LINE_STRIP, > GL_LINE_LOOP, GL_LINES, GL_TRIANGLE_STRIP, GL_TRIANGLE_FAN, and > GL_TRIANGLES. This are also the only relevant available primitives with OpenGL 3+. So the best we can do, without spending a lot of brainpower on each individual shape is to use GL_TRIANGLES for the filled (the more efficient TRIAGNLE ones will make it hard to get the normals right as far as i can see), and drawing each individual edge using GL_LINES for the wireframe. I should be able to generate arrays for both efficiently, using glDrawArrays as doing now for solids, but glDrawElements for the lines to further compress storage. Do we care about normals for the wire frames, don't think so right? Best, Dee |
From: John T. <nu...@me...> - 2012-03-18 22:45:16
|
On Sun, Mar 18, 2012 at 07:40:04PM +0100, Sylvain wrote: > > GLdouble and GL_DOUBLE are just missing in GLES. > ... > > So we have 2 choices: > > - Convert everything to float for ES builds, can be done with a few > #ifdef > > - Keep the API stable across ES and non-ES by always using double in > geometry functions prototypes, and #ifdef to float more selectively > in fg_geometry. Why not just convert everything to float across all platforms and be done with it? Do we really need all that precision for drawing teapots and cubes? :) Avoiding ifdefs in the code unless absolutely necessary, I think is a worthy goal. -- John Tsiombikas http://nuclear.mutantstargoat.com/ |
From: Sylvain <be...@be...> - 2012-03-20 08:06:44
|
On Sun, Mar 18, 2012 at 11:45:08PM +0100, John Tsiombikas wrote: > On Sun, Mar 18, 2012 at 07:40:04PM +0100, Sylvain wrote: > > > > GLdouble and GL_DOUBLE are just missing in GLES. > > > ... > > > > So we have 2 choices: > > > > - Convert everything to float for ES builds, can be done with a few > > #ifdef > > > > - Keep the API stable across ES and non-ES by always using double in > > geometry functions prototypes, and #ifdef to float more selectively > > in fg_geometry. > > Why not just convert everything to float across all platforms and be > done with it? Do we really need all that precision for drawing teapots > and cubes? :) > > Avoiding ifdefs in the code unless absolutely necessary, I think is a > worthy goal. I didn't dare to suggest switching everything to float, but indeed, given the precision needs, this could be even faster. -- Sylvain |
From: Diederick C. N. <dc...@gm...> - 2012-03-11 15:01:53
|
Hi Paul, On Sun, Mar 11, 2012 at 22:56, Paul Martz <pm...@sk...> wrote: > At some > point, I'd like to port this code to use non-deprecated drawing commands (i.e., > glDrawElements), but it's unlikely I'll have time to do this in the near future. Thanks for the input. How would this go for backward (i.e. old OpenGL versions/installations) compatibility? Best, Dee |
From: John T. <nu...@me...> - 2012-03-14 23:11:36
|
On Wed, Mar 14, 2012 at 08:51:30AM -0600, Paul Martz wrote: > > > On 3/14/2012 8:12 AM, John Tsiombikas wrote: > > On Wed, Mar 14, 2012 at 07:43:50AM -0600, Paul Martz wrote: > >> Hey guys -- > >> > >> glVertexPointer/glNormalPointer/etc are all deprecated in OpenGL 3.0 and removed > >> in 3.1: must use generic vertex attributes (glVertexAttrib) instead > > > > Indeed, but that is not a big problem. It's easy to > > conditionally compile code that calls either glVertexPointer, or > > glVertexAttrib(VERTEX_LOC, ...). The complication, and I'm sure this > > came up on this list the last time someone suggested converting > > everything to GL3.x, is that the result would not be very flexible, as we > > can't easily accomodate custom user shaders without changes to the API. > > If you're referring to the attribute naming issue, I think the solution would be > for the application to use a #define in their shader source. For example, if we > decide freeglut will send vertices named "fg_Vertex", then the app would add > this line at the top of their shader source: > > #define fg_Vertex myShader_Vertex; > > This would allow the rest of their shader source to use "myShader_Vertex". Yes so basically just set a standard set of attribute names. I agree that would be the best solution. > >> and I forgot when this was added to core OpenGL but it was not 1.1. > > > > You are mistaken, as I said, vertex arrays where introduced in OpenGL > > 1.1 and are available on windows without resorting to extensions: > > http://www.opengl.org/registry/doc/glspec11.ps > > Sorry, apparently I'm not communicating clearly. > > - Yes, you're right: glVertexPointer, glNormalPointer, etc., were added in GL > 1.1, but they are removed in 3.1. Sure, true, but that wasn't what I was talking about. I was saying simply that vertex arrays as a drawing method (as opposed to VBOs and immediate mode) are available over the whole range of OpenGL versions and thus the best choice for implementing the geometry functions. Obviously the removal of the fixed function pipeline affected some parts of the vertex arrays API but that's a minor issue in my opinion. > - Generic vertex attributes (glVertexAttribPointer) replace glVertexPointer > and friends, but were not introduced until GL 2.0, so are unavailable on Windows > without a tool like GLEW. I find that overreliance to GLEW pecculiar. You know we did manage to use OpenGL extensions just fine before the GLEW project started :) > > > GLEW?! Absolutely not. GLEW is convenient, and I use it in almost all my > > programs, but adding it as a dependency to freeglut is out of the > > question. If we need to access any OpenGL functionality through > > extensions, we'll have to do it manually. > > In my email, I suggested GLEW as a soft dependency, but if you prefer doing it > manually then it's disappointing that we can't use an off the shelf solution for > something so mundane, but I defer to you folks on how you want to run freeglut. Libraries should be very careful when introducing dependencies to other libraries, that's all. Especially when the dependency in question isn't at all vital, but just makes using OpenGL extensions *slightly* more convenient for us. Plus correct me if I'm wrong but this whole discussion started for the implementation of the geometry functions in an OpenGL ES compatible way. NOT for supporting them in pure OpenGL 3.x contexts. OpenGL ES already has this kind of functionality built in, not as an extension. -- John Tsiombikas http://nuclear.mutantstargoat.com/ |
From: Sylvain <be...@be...> - 2012-03-15 23:08:18
|
Hi, On Thu, Mar 15, 2012 at 12:11:29AM +0100, John Tsiombikas wrote: > On Wed, Mar 14, 2012 at 08:51:30AM -0600, Paul Martz wrote: > > On 3/14/2012 8:12 AM, John Tsiombikas wrote: > > > On Wed, Mar 14, 2012 at 07:43:50AM -0600, Paul Martz wrote: > > the app would add > > this line at the top of their shader source: > > > > #define fg_Vertex myShader_Vertex; > > > > This would allow the rest of their shader source to use "myShader_Vertex". > > Yes so basically just set a standard set of attribute names. I agree > that would be the best solution. Somebody on the list recently suggested making a second set of geometry functions. In which case we could pass the attributes locations as parameters. In addition, some locations (e.g. the normals, the colors, the texcoords) could be made optional, which seems harder to implement if we impose the presence of a number of standard attributes. I'm implementing a few versions of glutSolid/WireCube to see how this fits, it's not easy to speak theoretically :) > this whole discussion started for the > implementation of the geometry functions in an OpenGL ES compatible way. > NOT for supporting them in pure OpenGL 3.x contexts. OpenGL ES already > has this kind of functionality built in, not as an extension. I'm currently aiming at only 2 versions, e.g.: - glutSolidCube Technique: glVertexPointer + glDrawArrays/Elements Compatibility: "Legacy" OpenGL: OpenGL >= 1.1, GLES1 - glutSolidCube2 (or probably a better name ;)) Technique: glVertexAttribPointer + glDrawArrays/Elements + VBO Compatibility: "Modern" OpenGL: OpenGL >= 2.0, GLES2 This requires using extensions to get the proper OpenGL 2.x functions and constants. > Libraries should be very careful when introducing dependencies to other > libraries, that's all. Especially when the dependency in question isn't > at all vital, but just makes using OpenGL extensions *slightly* more > convenient for us. I agree as I fear using GLEW might cause conflicts for GLee users, though somebody should try and tell :) -- Sylvain |
From: Sylvain <be...@be...> - 2012-03-11 15:35:42
|
Hi, On Sun, Mar 11, 2012 at 11:01:47PM +0800, Diederick C. Niehorster wrote: > Hi Paul, > > On Sun, Mar 11, 2012 at 22:56, Paul Martz <pm...@sk...> wrote: > > At some > > point, I'd like to port this code to use non-deprecated drawing commands (i.e., > > glDrawElements), but it's unlikely I'll have time to do this in the near future. > > Thanks for the input. How would this go for backward (i.e. old OpenGL > versions/installations) compatibility? AFAICS glVertexPointer/glDrawElements were introduced in 1997's OpenGL 1.1, so we're probably good wrt old installations. In addition, I can help there: - I need to do something similar for OpenGL ES support because glBegin/glEnd is not supported there. - I'd like to support OpenGL >= 2.0 as well (glVertexAttribPointer/glDrawArrays/glDrawElements with shaders) I have good confidence that ES and non-ES version can be shared. The biggest difference may be the lack of glMap for the teapot, though I have code at http://en.wikibooks.org/wiki/OpenGL_Programming/Modern_OpenGL_Tutorial_07 to do the same thing). Maybe 1.x and 2.x versions can be merged with a minimum of macro-processing, but I'm not sure, I need to test. Since I'm more interested in supporting 2.0 only, I'd welcome help with 1.x. Btw, http://code.google.com/p/glues/ did the same kind of changes to upgrade from glBegin/glEnd in GLU. -- Sylvain |
From: Paul M. <pm...@sk...> - 2012-03-11 17:20:02
|
Perhaps the best solution is to expose a set of parallel geometry functions (using freeglut_ext.h) that are safe for use with forward compatible / core profile / ES 2.0, and leave the existing code compatible with GL v1.0. If we decide this is the best route forward, then Dee could proceed with the reorganization of the existing code, and we can add the new code later. In addition to the teapot solution mentioned by Sylvain, some time ago I captured the glEval output using feedback, so I have an explicit list of GL_TRIANGLES vertices that can be rendered with glDrawArrays, if it's useful. -Paul On 3/11/2012 9:35 AM, Sylvain wrote: > Hi, > > On Sun, Mar 11, 2012 at 11:01:47PM +0800, Diederick C. Niehorster wrote: >> Hi Paul, >> >> On Sun, Mar 11, 2012 at 22:56, Paul Martz<pm...@sk...> wrote: >>> At some >>> point, I'd like to port this code to use non-deprecated drawing commands (i.e., >>> glDrawElements), but it's unlikely I'll have time to do this in the near future. >> >> Thanks for the input. How would this go for backward (i.e. old OpenGL >> versions/installations) compatibility? > > AFAICS glVertexPointer/glDrawElements were introduced in 1997's OpenGL > 1.1, so we're probably good wrt old installations. > > In addition, I can help there: > > - I need to do something similar for OpenGL ES support because > glBegin/glEnd is not supported there. > > - I'd like to support OpenGL>= 2.0 as well > (glVertexAttribPointer/glDrawArrays/glDrawElements with shaders) > > I have good confidence that ES and non-ES version can be shared. The > biggest difference may be the lack of glMap for the teapot, though I > have code at > http://en.wikibooks.org/wiki/OpenGL_Programming/Modern_OpenGL_Tutorial_07 > to do the same thing). > > Maybe 1.x and 2.x versions can be merged with a minimum of > macro-processing, but I'm not sure, I need to test. > > Since I'm more interested in supporting 2.0 only, I'd welcome help > with 1.x. > > > Btw, http://code.google.com/p/glues/ did the same kind of changes to > upgrade from glBegin/glEnd in GLU. > |
From: Diederick C. N. <dc...@gm...> - 2012-03-15 23:25:43
|
Hi Sylvain, On Fri, Mar 16, 2012 at 07:08, Sylvain <be...@be...> wrote: > - glutSolidCube > Technique: glVertexPointer + glDrawArrays/Elements > Compatibility: "Legacy" OpenGL: OpenGL >= 1.1, GLES1 While I'm working on a different function, how does what I'm doing compare to what you plan for this codepath? > - glutSolidCube2 (or probably a better name ;)) > Technique: glVertexAttribPointer + glDrawArrays/Elements + VBO > Compatibility: "Modern" OpenGL: OpenGL >= 2.0, GLES2 If these function differ by input parameter, we don't even need to rename (or is that C++ talking again?) Best, Dee |
From: John T. <nu...@me...> - 2012-03-15 23:56:34
|
On Fri, Mar 16, 2012 at 07:25:37AM +0800, Diederick C. Niehorster wrote: > > - glutSolidCube2 (or probably a better name ;)) > > Technique: glVertexAttribPointer + glDrawArrays/Elements + VBO > > Compatibility: "Modern" OpenGL: OpenGL >= 2.0, GLES2 > > If these function differ by input parameter, we don't even need to > rename (or is that C++ talking again?) No I'm afraid C doesn't have function overloading :) -- John Tsiombikas http://nuclear.mutantstargoat.com/ |
From: Diederick C. N. <dc...@gm...> - 2012-03-16 00:03:51
|
Hi John, On Fri, Mar 16, 2012 at 07:56, John Tsiombikas <nu...@me...> wrote: > On Fri, Mar 16, 2012 at 07:25:37AM +0800, Diederick C. Niehorster wrote: >> > - glutSolidCube2 (or probably a better name ;)) >> > Technique: glVertexAttribPointer + glDrawArrays/Elements + VBO >> > Compatibility: "Modern" OpenGL: OpenGL >= 2.0, GLES2 >> >> If these function differ by input parameter, we don't even need to >> rename (or is that C++ talking again?) > > No I'm afraid C doesn't have function overloading :) Urgh, sorry for the noise then. Dee |
From: Sylvain <be...@be...> - 2012-03-16 08:07:28
|
On Fri, Mar 16, 2012 at 07:25:37AM +0800, Diederick C. Niehorster wrote: > Hi Sylvain, > > On Fri, Mar 16, 2012 at 07:08, Sylvain <be...@be...> wrote: > > - glutSolidCube > > Technique: glVertexPointer + glDrawArrays/Elements > > Compatibility: "Legacy" OpenGL: OpenGL >= 1.1, GLES1 > > While I'm working on a different function, how does what I'm doing > compare to what you plan for this codepath? I didn't know that you were about to commit it this night already :) Moving to glVertexPointer is a common need. However, looking at fg_geometry, I see it is now much more complex, and it relies on functions not available in GLES. In particular, GLES only has lines and triangles (e.g. no quads and polygons). Last time I made a solid cube and a wireframe bounding box in GLES2, I add to write two different functions, I'm not sure it's possible to merge them. GLES also lacks functions such as glPopAttrib. See these pages to check the available functions / features : - 1.1: http://www.khronos.org/opengles/sdk/1.1/docs/man/ - 2.0: http://www.khronos.org/opengles/sdk/docs/man/ -- Sylvain |
From: Diederick C. N. <dc...@gm...> - 2012-03-16 15:31:24
|
Dear All, On Fri, Mar 16, 2012 at 19:43, Diederick C. Niehorster <dc...@gm...> wrote: > This are also the only relevant available primitives with OpenGL 3+. > So the best we can do, without spending a lot of brainpower on each > individual shape is to use GL_TRIANGLES for the filled (the more > efficient TRIAGNLE ones will make it hard to get the normals right as > far as i can see), and drawing each individual edge using GL_LINES for > the wireframe. I should be able to generate arrays for both > efficiently, using glDrawArrays as doing now for solids, but > glDrawElements for the lines to further compress storage. The only thing missing in OpenGL 3 for my current implementation is the edge flags. But they give glMultiDrawArray in return, so other solutions would be easy there. OpenGL ES is a bigger problem. So I think I'll continue as I am doing now, and the OpenGL ES code will have to diverge for thewire frames. I'll make sure all solids are decomposed into triangles (piece of cake to do automatically for quags and pentagons), so that'll work one any OpenGL version we know of. Any thoughts very welcome! Best, Dee |