From: Sylvain <be...@be...> - 2012-03-24 13:36:04
|
Hi, I'm trying to make the new geometry code draw for OpenGL (ES) 2 and later, with glVertextAttribPointer, and I need the number of vertices to create a (sized) VBO. (we could keep relying on client-side arrays without VBO, but that's dropped in OpenGL 3...) I hit my head on the wall a few times before understanding exactly the 'numVertices' parameter for fghDrawGeometrySolid(). Depending on how the shape is built, it may refer to the number of distinct vertices, or to the number of low-level OpenGL vertices sent to the card with glDrawArray (possibly with duplicates). I try to modify the code with 2 parameters instead of one: GLsizei numVertices => GLsizei numDistinctVertices, GLsizei numElements which changes the current code only a bit. When documenting the new parameters I realized numDistinctVertices was irrelevent for figures drawn with glDrawArray, and this was quite complex to explain it in the comment. Then I realized, is there a real value to not using glDrawElements for all shapes? This would simplify the code much and avoid the confusion between indexed and non-indexed vertices. -- Sylvain |
From: Diederick C. N. <dc...@gm...> - 2012-03-24 13:53:01
|
Hi Sylvain, You understood it all correctly from what you describe, sorry for the confusing reuse of variables. Well, Always using glDrawElements would mean you have to build (and the gl code has to use) index vertices when they aren't actually useful, I was hoping to avoid unecessary overhead as much as possible. I suppose we could make add boolean instead, something like isDecomposed or hasTrianglePrimitives, or somehting better that is failing me. The glDrawElements path is needed for shapes whose primitives are quads or pentagons, whereas if the shapes are already composed of triangles, we can stream the whole array direct an in its original order to the graphics card. But easiest might be to comment like this: If numEdgePerFace==3, the original shape's faces are composed of triangles and we can take an optimized path streaming all vertices to the server directly. When numEdgePerFace>3, the original shapes were quads or pentagon that were decomposed into triangles by drawing some vertices more than once. This "sampling scheme" is encoded in the indexArray input generated in fghGenerateGeometryWithIndexArray below, which is only needed and used in this case. Is that clear? Thanks for the help commenting an dotherwise critically looking at my code! Do you see any other changes that might be good? Best, Dee On Sat, Mar 24, 2012 at 21:35, Sylvain <be...@be...> wrote: > Hi, > > I'm trying to make the new geometry code draw for OpenGL (ES) 2 and > later, with glVertextAttribPointer, and I need the number of vertices > to create a (sized) VBO. > > (we could keep relying on client-side arrays without VBO, but that's > dropped in OpenGL 3...) > > I hit my head on the wall a few times before understanding exactly the > 'numVertices' parameter for fghDrawGeometrySolid(). Depending on how > the shape is built, it may refer to the number of distinct vertices, > or to the number of low-level OpenGL vertices sent to the card with > glDrawArray (possibly with duplicates). > > I try to modify the code with 2 parameters instead of one: > GLsizei numVertices > => GLsizei numDistinctVertices, GLsizei numElements > which changes the current code only a bit. > > When documenting the new parameters I realized numDistinctVertices was > irrelevent for figures drawn with glDrawArray, and this was quite > complex to explain it in the comment. > > > Then I realized, is there a real value to not using glDrawElements for > all shapes? This would simplify the code much and avoid the confusion > between indexed and non-indexed vertices. > > -- > Sylvain > > ------------------------------------------------------------------------------ > This SF email is sponsosred by: > Try Windows Azure free for 90 days Click Here > http://p.sf.net/sfu/sfd2d-msazure > _______________________________________________ > Freeglut-developer mailing list > Fre...@li... > https://lists.sourceforge.net/lists/listinfo/freeglut-developer |
From: Sylvain <be...@be...> - 2012-03-24 14:20:01
|
Hi Diederick, On Sat, Mar 24, 2012 at 09:52:52PM +0800, Diederick C. Niehorster wrote: > You understood it all correctly from what you describe, sorry for the > confusing reuse of variables. > Well, Always using glDrawElements would mean you have to build (and > the gl code has to use) index vertices when they aren't actually > useful, I was hoping to avoid unecessary overhead as much as possible. > > I suppose we could make add boolean instead, something like > isDecomposed or hasTrianglePrimitives, or somehting better that is > failing me. The glDrawElements path is needed for shapes whose > primitives are quads or pentagons, whereas if the shapes are already > composed of triangles, we can stream the whole array direct an in its > original order to the graphics card. I think quads or pentagons could be expressed using glDrawArrays as well. I'm not sure numEdgePerFace==3 is equivalent to "requires glDrawArrays" either. I remember now that the main need to avoid glDrawElements is when we need several normals on the same vertex (e.g. for a cube - otherwise the lighting won't work well AFAICR, especially Phong shading). Which shapes require glDrawArrays in your opinion? > But easiest might be to comment like this: > > If numEdgePerFace==3, the original shape's faces are composed of > triangles and we can take an optimized path streaming all vertices to > the server directly. When numEdgePerFace>3, the original shapes were > quads or pentagon that were decomposed into triangles by drawing some > vertices more than once. This "sampling scheme" is encoded in the > indexArray input generated in fghGenerateGeometryWithIndexArray below, > which is only needed and used in this case. > > Is that clear? That's still long and we still need to explain the num(Distinct)Vertices/numElements parameters. However with your idea with a boolean may make things clearer. Something like isDrawnWithElements could do the trick. > Thanks for the help commenting an dotherwise critically looking at my > code! Do you see any other changes that might be good? I was wondering if it would be clearer to describe the shapes with an array of parameters, indexed with an enum, interpreted with code, rather than through macro generation. But that would require rewriting a good part of the code to do the same job. We'll otherwise probably find more things to improve as we port other shapes ;) - Sylvain > On Sat, Mar 24, 2012 at 21:35, Sylvain <be...@be...> wrote: > > Hi, > > > > I'm trying to make the new geometry code draw for OpenGL (ES) 2 and > > later, with glVertextAttribPointer, and I need the number of vertices > > to create a (sized) VBO. > > > > (we could keep relying on client-side arrays without VBO, but that's > > dropped in OpenGL 3...) > > > > I hit my head on the wall a few times before understanding exactly the > > 'numVertices' parameter for fghDrawGeometrySolid(). Depending on how > > the shape is built, it may refer to the number of distinct vertices, > > or to the number of low-level OpenGL vertices sent to the card with > > glDrawArray (possibly with duplicates). > > > > I try to modify the code with 2 parameters instead of one: > > GLsizei numVertices > > => GLsizei numDistinctVertices, GLsizei numElements > > which changes the current code only a bit. > > > > When documenting the new parameters I realized numDistinctVertices was > > irrelevent for figures drawn with glDrawArray, and this was quite > > complex to explain it in the comment. > > > > > > Then I realized, is there a real value to not using glDrawElements for > > all shapes? This would simplify the code much and avoid the confusion > > between indexed and non-indexed vertices. |
From: Paul M. <pm...@sk...> - 2012-03-24 15:15:45
|
Just to clarify, buffer objects are *not* required in GL3+ contexts, glVertexAttribPointer() can still source its data from client-side memory (no error is generated if 0 is bound to GL_ARRAY_BUFFER). -Paul On 3/24/2012 7:35 AM, Sylvain wrote: > (we could keep relying on client-side arrays without VBO, but that's > dropped in OpenGL 3...) |
From: Sylvain <be...@be...> - 2012-03-24 17:07:07
|
Hi, Thanks for the info. Though this looks like on its way to deprecation to the least: Legacy Note: Versions of OpenGL prior to 3.0 allowed the use of client-side data for vertex rendering, but GL 3.0 deprecated this. Core GL 3.1 and greater forbid client-side vertex data, so VBOs are the only means for rendering. http://www.opengl.org/wiki/Vertex_Buffer_Object Spec 3.0 §2.10 says: An INVALID OPERATION error is generated if any of the *Pointer commands specifying the location and organization of vertex array data are called while a non-zero vertex array object is bound and zero is bound to the ARRAY_BUFFER buffer object binding point [2]. [2] This error makes it impossible to create a vertex array object containing client array pointers. clarified in 3.1 with: An INVALID_OPERATION error is generated if any of the *Pointer commands specifying the location and organization of vertex array data are called while zero is bound to the ARRAY_BUFFER buffer object binding point, and the pointer argument is not NULL [3]. [3] This error makes it impossible to create a vertex array object containing client array pointers, while still allowing buffer objects to be unbound. (in 3.2 you find the same bits in both the core and compatibility profile, §2.8) The explanation is somewhat obscure, but the footnote is quite clear: we can anticipate the disparition of client-side vertex data :/ - Sylvain On Sat, Mar 24, 2012 at 09:15:35AM -0600, Paul Martz wrote: > Just to clarify, buffer objects are *not* required in GL3+ contexts, > glVertexAttribPointer() can still source its data from client-side memory (no > error is generated if 0 is bound to GL_ARRAY_BUFFER). > -Paul > > > On 3/24/2012 7:35 AM, Sylvain wrote: > > (we could keep relying on client-side arrays without VBO, but that's > > dropped in OpenGL 3...) |
From: Paul M. <pm...@sk...> - 2012-03-24 19:24:28
|
If the goal is support for the core profile, then yes, you must use a vertex array object (the default VAO is no longer available) and must therefore bind a buffer to GL_ARRAY_BUFFER prior to calling glVertexAttribPointer(). Good work! Go for it! :-) -Paul On 3/24/2012 11:06 AM, Sylvain wrote: > Hi, > > Thanks for the info. > Though this looks like on its way to deprecation to the least: > > Legacy Note: Versions of OpenGL prior to 3.0 allowed the use of > client-side data for vertex rendering, but GL 3.0 deprecated > this. Core GL 3.1 and greater forbid client-side vertex data, so > VBOs are the only means for rendering. > > http://www.opengl.org/wiki/Vertex_Buffer_Object > > Spec 3.0 §2.10 says: > > An INVALID OPERATION error is generated if any of the *Pointer > commands specifying the location and organization of vertex array > data are called while a non-zero vertex array object is bound and > zero is bound to the ARRAY_BUFFER buffer object binding point [2]. > > [2] This error makes it impossible to create a vertex array object > containing client array pointers. > > clarified in 3.1 with: > > An INVALID_OPERATION error is generated if any of the *Pointer > commands specifying the location and organization of vertex array > data are called while zero is bound to the ARRAY_BUFFER buffer > object binding point, and the pointer argument is not NULL [3]. > > [3] This error makes it impossible to create a vertex array object > containing client array pointers, while still allowing buffer > objects to be unbound. > > (in 3.2 you find the same bits in both the core and compatibility > profile, §2.8) > > The explanation is somewhat obscure, but the footnote is quite clear: > we can anticipate the disparition of client-side vertex data :/ > > - Sylvain > > On Sat, Mar 24, 2012 at 09:15:35AM -0600, Paul Martz wrote: >> Just to clarify, buffer objects are *not* required in GL3+ contexts, >> glVertexAttribPointer() can still source its data from client-side memory (no >> error is generated if 0 is bound to GL_ARRAY_BUFFER). >> -Paul >> >> >> On 3/24/2012 7:35 AM, Sylvain wrote: >>> (we could keep relying on client-side arrays without VBO, but that's >>> dropped in OpenGL 3...) > > ------------------------------------------------------------------------------ > This SF email is sponsosred by: > Try Windows Azure free for 90 days Click Here > http://p.sf.net/sfu/sfd2d-msazure > _______________________________________________ > Freeglut-developer mailing list > Fre...@li... > https://lists.sourceforge.net/lists/listinfo/freeglut-developer > > |
From: Sylvain <be...@be...> - 2012-03-24 20:55:23
|
Hi, Hopefully the code would be shared for OpenGL 2 and 3. Do you mean it is not possible to use just VBOs? - Sylvain On Sat, Mar 24, 2012 at 01:24:15PM -0600, Paul Martz wrote: > If the goal is support for the core profile, then yes, you must use a vertex > array object (the default VAO is no longer available) and must therefore bind a > buffer to GL_ARRAY_BUFFER prior to calling glVertexAttribPointer(). > > Good work! Go for it! :-) > -Paul > > > On 3/24/2012 11:06 AM, Sylvain wrote: > > Hi, > > > > Thanks for the info. > > Though this looks like on its way to deprecation to the least: > > > > Legacy Note: Versions of OpenGL prior to 3.0 allowed the use of > > client-side data for vertex rendering, but GL 3.0 deprecated > > this. Core GL 3.1 and greater forbid client-side vertex data, so > > VBOs are the only means for rendering. > > > > http://www.opengl.org/wiki/Vertex_Buffer_Object > > > > Spec 3.0 §2.10 says: > > > > An INVALID OPERATION error is generated if any of the *Pointer > > commands specifying the location and organization of vertex array > > data are called while a non-zero vertex array object is bound and > > zero is bound to the ARRAY_BUFFER buffer object binding point [2]. > > > > [2] This error makes it impossible to create a vertex array object > > containing client array pointers. > > > > clarified in 3.1 with: > > > > An INVALID_OPERATION error is generated if any of the *Pointer > > commands specifying the location and organization of vertex array > > data are called while zero is bound to the ARRAY_BUFFER buffer > > object binding point, and the pointer argument is not NULL [3]. > > > > [3] This error makes it impossible to create a vertex array object > > containing client array pointers, while still allowing buffer > > objects to be unbound. > > > > (in 3.2 you find the same bits in both the core and compatibility > > profile, §2.8) > > > > The explanation is somewhat obscure, but the footnote is quite clear: > > we can anticipate the disparition of client-side vertex data :/ > > > > - Sylvain > > > > On Sat, Mar 24, 2012 at 09:15:35AM -0600, Paul Martz wrote: > >> Just to clarify, buffer objects are *not* required in GL3+ contexts, > >> glVertexAttribPointer() can still source its data from client-side memory (no > >> error is generated if 0 is bound to GL_ARRAY_BUFFER). > >> -Paul > >> > >> > >> On 3/24/2012 7:35 AM, Sylvain wrote: > >>> (we could keep relying on client-side arrays without VBO, but that's > >>> dropped in OpenGL 3...) |
From: Paul M. <pm...@sk...> - 2012-03-24 21:29:21
|
I apologize, but I'm confused... Are you using vertex array objects or aren't you? Your spec quotes are from section 2.10, so I thought that meant you're using vertex array objects. If you're using VAOs, then VBOs are required as per your spec quotes from section 2.10. But you won't be able to run on (unextended) GL2. If you are not using VAOs, then you can use "just VBOs", or (as I said in my original post on this thread) you can source the data from client memory. But in this situation you can't use a core profile context. -Paul On 3/24/2012 2:55 PM, Sylvain wrote: > Hi, > > Hopefully the code would be shared for OpenGL 2 and 3. > Do you mean it is not possible to use just VBOs? > > - Sylvain > > On Sat, Mar 24, 2012 at 01:24:15PM -0600, Paul Martz wrote: >> If the goal is support for the core profile, then yes, you must use a vertex >> array object (the default VAO is no longer available) and must therefore bind a >> buffer to GL_ARRAY_BUFFER prior to calling glVertexAttribPointer(). >> >> Good work! Go for it! :-) >> -Paul >> >> >> On 3/24/2012 11:06 AM, Sylvain wrote: >>> Hi, >>> >>> Thanks for the info. >>> Though this looks like on its way to deprecation to the least: >>> >>> Legacy Note: Versions of OpenGL prior to 3.0 allowed the use of >>> client-side data for vertex rendering, but GL 3.0 deprecated >>> this. Core GL 3.1 and greater forbid client-side vertex data, so >>> VBOs are the only means for rendering. >>> >>> http://www.opengl.org/wiki/Vertex_Buffer_Object >>> >>> Spec 3.0 §2.10 says: >>> >>> An INVALID OPERATION error is generated if any of the *Pointer >>> commands specifying the location and organization of vertex array >>> data are called while a non-zero vertex array object is bound and >>> zero is bound to the ARRAY_BUFFER buffer object binding point [2]. >>> >>> [2] This error makes it impossible to create a vertex array object >>> containing client array pointers. >>> >>> clarified in 3.1 with: >>> >>> An INVALID_OPERATION error is generated if any of the *Pointer >>> commands specifying the location and organization of vertex array >>> data are called while zero is bound to the ARRAY_BUFFER buffer >>> object binding point, and the pointer argument is not NULL [3]. >>> >>> [3] This error makes it impossible to create a vertex array object >>> containing client array pointers, while still allowing buffer >>> objects to be unbound. >>> >>> (in 3.2 you find the same bits in both the core and compatibility >>> profile, §2.8) >>> >>> The explanation is somewhat obscure, but the footnote is quite clear: >>> we can anticipate the disparition of client-side vertex data :/ >>> >>> - Sylvain >>> >>> On Sat, Mar 24, 2012 at 09:15:35AM -0600, Paul Martz wrote: >>>> Just to clarify, buffer objects are *not* required in GL3+ contexts, >>>> glVertexAttribPointer() can still source its data from client-side memory (no >>>> error is generated if 0 is bound to GL_ARRAY_BUFFER). >>>> -Paul >>>> >>>> >>>> On 3/24/2012 7:35 AM, Sylvain wrote: >>>>> (we could keep relying on client-side arrays without VBO, but that's >>>>> dropped in OpenGL 3...) > > ------------------------------------------------------------------------------ > This SF email is sponsosred by: > Try Windows Azure free for 90 days Click Here > http://p.sf.net/sfu/sfd2d-msazure > _______________________________________________ > Freeglut-developer mailing list > Fre...@li... > https://lists.sourceforge.net/lists/listinfo/freeglut-developer > > |
From: Sylvain <be...@be...> - 2012-03-24 21:58:15
|
Hi Paul, Don't worry, I was the one confused :) I'm more familiar with GLES2, so I didn't know enough about VAOs, and quoted the spec inappropriately. So: I thought that OpenGL 3 removed client-side arrays in glVertexAttribPointer, and so says the page I quoted from the OpenGL wiki, but I cannot find where that's written in the spec :/ Since it doesn't hurt to create VBOs instead of specifying client-side arrays, I guess I'll do just that. Also, you wrote "the default VAO is no longer available [in core profile]", so I suppose we cannot be compatible with both GL2 and GL3-core-profile? - Sylvain On Sat, Mar 24, 2012 at 03:29:08PM -0600, Paul Martz wrote: > I apologize, but I'm confused... Are you using vertex array objects or aren't > you? Your spec quotes are from section 2.10, so I thought that meant you're > using vertex array objects. > > If you're using VAOs, then VBOs are required as per your spec quotes from > section 2.10. But you won't be able to run on (unextended) GL2. > > If you are not using VAOs, then you can use "just VBOs", or (as I said in my > original post on this thread) you can source the data from client memory. But in > this situation you can't use a core profile context. > -Paul > > > On 3/24/2012 2:55 PM, Sylvain wrote: > > Hi, > > > > Hopefully the code would be shared for OpenGL 2 and 3. > > Do you mean it is not possible to use just VBOs? > > > > - Sylvain > > > > On Sat, Mar 24, 2012 at 01:24:15PM -0600, Paul Martz wrote: > >> If the goal is support for the core profile, then yes, you must use a vertex > >> array object (the default VAO is no longer available) and must therefore bind a > >> buffer to GL_ARRAY_BUFFER prior to calling glVertexAttribPointer(). > >> > >> Good work! Go for it! :-) > >> -Paul > >> > >> > >> On 3/24/2012 11:06 AM, Sylvain wrote: > >>> Hi, > >>> > >>> Thanks for the info. > >>> Though this looks like on its way to deprecation to the least: > >>> > >>> Legacy Note: Versions of OpenGL prior to 3.0 allowed the use of > >>> client-side data for vertex rendering, but GL 3.0 deprecated > >>> this. Core GL 3.1 and greater forbid client-side vertex data, so > >>> VBOs are the only means for rendering. > >>> > >>> http://www.opengl.org/wiki/Vertex_Buffer_Object > >>> > >>> Spec 3.0 §2.10 says: > >>> > >>> An INVALID OPERATION error is generated if any of the *Pointer > >>> commands specifying the location and organization of vertex array > >>> data are called while a non-zero vertex array object is bound and > >>> zero is bound to the ARRAY_BUFFER buffer object binding point [2]. > >>> > >>> [2] This error makes it impossible to create a vertex array object > >>> containing client array pointers. > >>> > >>> clarified in 3.1 with: > >>> > >>> An INVALID_OPERATION error is generated if any of the *Pointer > >>> commands specifying the location and organization of vertex array > >>> data are called while zero is bound to the ARRAY_BUFFER buffer > >>> object binding point, and the pointer argument is not NULL [3]. > >>> > >>> [3] This error makes it impossible to create a vertex array object > >>> containing client array pointers, while still allowing buffer > >>> objects to be unbound. > >>> > >>> (in 3.2 you find the same bits in both the core and compatibility > >>> profile, §2.8) > >>> > >>> The explanation is somewhat obscure, but the footnote is quite clear: > >>> we can anticipate the disparition of client-side vertex data :/ > >>> > >>> - Sylvain > >>> > >>> On Sat, Mar 24, 2012 at 09:15:35AM -0600, Paul Martz wrote: > >>>> Just to clarify, buffer objects are *not* required in GL3+ contexts, > >>>> glVertexAttribPointer() can still source its data from client-side memory (no > >>>> error is generated if 0 is bound to GL_ARRAY_BUFFER). > >>>> -Paul > >>>> > >>>> > >>>> On 3/24/2012 7:35 AM, Sylvain wrote: > >>>>> (we could keep relying on client-side arrays without VBO, but that's > >>>>> dropped in OpenGL 3...) > > > > ------------------------------------------------------------------------------ > > This SF email is sponsosred by: > > Try Windows Azure free for 90 days Click Here > > http://p.sf.net/sfu/sfd2d-msazure > > _______________________________________________ > > Freeglut-developer mailing list > > Fre...@li... > > https://lists.sourceforge.net/lists/listinfo/freeglut-developer > > > > > > ------------------------------------------------------------------------------ > This SF email is sponsosred by: > Try Windows Azure free for 90 days Click Here > http://p.sf.net/sfu/sfd2d-msazure > _______________________________________________ > Freeglut-developer mailing list > Fre...@li... > https://lists.sourceforge.net/lists/listinfo/freeglut-developer |
From: Diederick C. N. <dc...@gm...> - 2013-03-17 14:11:34
|
Hi Sylvain, On Sun, Mar 17, 2013 at 8:53 PM, Sylvain <be...@be...> wrote: > Now with a longer-term view: I believe the current compile-time > detection of GLES1 could be replaced by a run-time detection (SDL does > this if I remember correctly) and hence avoid the need for > double-compiling FreeGLUT. > > So maybe consider keeping the option to do the GLuit/GLushort choice > at run-time, if that's possible. If not, well no big deal for now. Good point, think this would be the desired situation. Hmm.. leave it as a todo for now then, a GLushort should still have plenty of space except for the most (i'd dare say ridiculously) detailed objects. I'll write something about it in the header of the file. Thanks, Dee |
From: Diederick C. N. <dc...@gm...> - 2012-03-24 16:01:56
|
Hi Sylvain, On Sat, Mar 24, 2012 at 22:19, Sylvain <be...@be...> wrote: > I think quads or pentagons could be expressed using glDrawArrays as > well. I'm not sure numEdgePerFace==3 is equivalent to "requires > glDrawArrays" either. I suppose logically it isn't yes. > I remember now that the main need to avoid glDrawElements is when we > need several normals on the same vertex (e.g. for a cube - otherwise > the lighting won't work well AFAICR, especially Phong shading). > > Which shapes require glDrawArrays in your opinion? For shapes that have triangles as faces, each combination of normals and vertex coordinates in the hardcoded arrays is used only once. Hence I call glDrawArrays in those cases. numEdgePerFace==3 could be phrased as hasTrianglesAsFaces or something like that, though the other booleans we discuss might be clearer in intent. For objects with quads or pentagons, we need to decompose each face into two or three (respectively) triangles. In this decomposition, some vertex/normal combinations are reused (the triangles on a face that make up the quad or pentagon share identical vertices+normals). Hence here glDrawElements is the natural choice, saving bloat in memory and offering possible performance enhancment as a smart driver only needs to process each normal/vertex combination once (through the use of indices it knows its reused). I think this becomes more important for the other objects (sphere, cylinder, torus, cone). The solid versions of those are all mostly made up of quads, and their drawing will thus require similar decomposing (though I hope to use gl_triangle_strip instead, so we can just use glDrawArrays again!). But thats on the todo for now... Drawing with a triangle strip will require a separate glDrawArrays call for each "stack" though... would that be portable? In any case, I was hoping to use the same glDrawGeometry function for this, just adding an extra input for the vertex_mode to be used when drawing. In that case the numEdgePerFace input indeed becomes a big misnomer and should simply be replaced with something like isDrawnWithElements as you say below. > >> But easiest might be to comment like this: >> >> If numEdgePerFace==3, the original shape's faces are composed of >> triangles and we can take an optimized path streaming all vertices to >> the server directly. When numEdgePerFace>3, the original shapes were >> quads or pentagon that were decomposed into triangles by drawing some >> vertices more than once. This "sampling scheme" is encoded in the >> indexArray input generated in fghGenerateGeometryWithIndexArray below, >> which is only needed and used in this case. >> >> Is that clear? > > That's still long and we still need to explain the > num(Distinct)Vertices/numElements parameters. > > However with your idea with a boolean may make things clearer. > Something like isDrawnWithElements could do the trick. Cool! If I don't get to this and the further rewriting next week (unlikely, two big deadlines looming at work), it'll take a while before I get back to this. The two weeks after that I'll be on a trip with limit internet access. But we'll get to this! Don't let things keep up your work of course though, I'm not married to what I've already done ;) > >> Thanks for the help commenting an dotherwise critically looking at my >> code! Do you see any other changes that might be good? > > I was wondering if it would be clearer to describe the shapes with an > array of parameters, indexed with an enum, interpreted with code, > rather than through macro generation. But that would require I'm not sure what you're envisioning. Would you have a very simple example of the scheme you're thinking of? The macros now only generate boilerplate functions, the actual shape definitions are in the arrays, which are interpretable because of the few preprocessor definitions defining stuff such as how many faces an object has and how many edges per face (or did I call those vert_per_face? some standardization of naming is probably still needed). Best, Dee |
From: Sylvain <be...@be...> - 2012-03-24 17:47:23
|
Hi, On Sun, Mar 25, 2012 at 12:01:46AM +0800, Diederick C. Niehorster wrote: > On Sat, Mar 24, 2012 at 22:19, Sylvain <be...@be...> wrote: > > I remember now that the main need to avoid glDrawElements is when we > > need several normals on the same vertex (e.g. for a cube - otherwise > > the lighting won't work well AFAICR, especially Phong shading). > > > > Which shapes require glDrawArrays in your opinion? > > For shapes that have triangles as faces, each combination of normals > and vertex coordinates in the hardcoded arrays is used only once. > Hence I call glDrawArrays in those cases. OK, I just understood that current glDrawArrays already reference unique vertex+normal pairs. So indeed it makes sense to avoid using glDrawElements without reusing any of these pairs. Thanks for enlightening me :) > > However with your idea with a boolean may make things clearer. > > Something like isDrawnWithElements could do the trick. > > Cool! If I don't get to this and the further rewriting next week > (unlikely, two big deadlines looming at work), it'll take a while > before I get back to this. The two weeks after that I'll be on a trip > with limit internet access. But we'll get to this! Don't let things > keep up your work of course though, I'm not married to what I've > already done ;) > > > > >> Thanks for the help commenting an dotherwise critically looking at my > >> code! Do you see any other changes that might be good? > > > > I was wondering if it would be clearer to describe the shapes with an > > array of parameters, indexed with an enum, interpreted with code, > > rather than through macro generation. But that would require > > I'm not sure what you're envisioning. Would you have a very simple > example of the scheme you're thinking of? For instance: #define CUBE_VERT_ELEM_PER_OBJ ... static GLfloat name##_verts[nameCaps##_VERT_ELEM_PER_OBJ] => could become: enum shapes {CUBE, TETRAHEDRON, ...}; vert_elem_per_obj[CUBE] = ...; static GLfloat verts[CUBE] = malloc(...); This makes the data structure visible instead of hidden in macro definitions. However, this is probably more difficult to initialize in C. More important and unrelated suggestion: we may need to add a glBindBuffer(GL_ARRAY_BUFFER,0) before calling glVertexPointer (before glEnableClientState), otherwise we may use the user's buffer rather than our static buffer, search glBindBuffer in: http://www.opengl.org/sdk/docs/man/xhtml/glVertexPointer.xml -- Sylvain |
From: Sylvain <be...@be...> - 2012-03-24 19:53:54
|
On Sat, Mar 24, 2012 at 06:47:12PM +0100, Sylvain wrote: > Hi, > > On Sun, Mar 25, 2012 at 12:01:46AM +0800, Diederick C. Niehorster wrote: > > On Sat, Mar 24, 2012 at 22:19, Sylvain <be...@be...> wrote: > > > I remember now that the main need to avoid glDrawElements is when we > > > need several normals on the same vertex (e.g. for a cube - otherwise > > > the lighting won't work well AFAICR, especially Phong shading). > > > > > > Which shapes require glDrawArrays in your opinion? > > > > For shapes that have triangles as faces, each combination of normals > > and vertex coordinates in the hardcoded arrays is used only once. > > Hence I call glDrawArrays in those cases. > > OK, I just understood that current glDrawArrays already reference > unique vertex+normal pairs. > > So indeed it makes sense to avoid using glDrawElements without reusing > any of these pairs. Well, - I added a comment insisting on vertex+normal unicity, - added 'GLsizei numVertIdxs' as a parameter, - called 'fghDrawGeometrySolid' with: numVertices,numVertIdxs => nameCaps##_VERT_PER_OBJ,nameCaps##_VERT_PER_OBJ_TRI This way the variables are clearer (numVertices != numElements), and we'll have numVertices at all times to allocate the VBO :) -- Sylvain |
From: Sylvain <be...@be...> - 2012-03-24 22:56:59
|
Hi, The experiment with GL2 is going well. Currently I have in my client code: glutSetVertexAttribCoord3(attribute_v_coord); glutSetVertexAttribNormal(attribute_v_normal); glutSolidTetrahedron(); glutSetVertexAttribCoord3/Normal defines the shader attributes - set statically and globally, so we don't need to add a new API. (We might want to change that.) The internal code uses VBOs. Only fghDrawGeometrySolid was modified. I didn't test wireframe yet though. Here are a few screenshots with a phong shader and 2 lights :) http://www.beuc.net/tmp/freeglut/ - Sylvain On Sat, Mar 24, 2012 at 08:53:43PM +0100, Sylvain wrote: > On Sat, Mar 24, 2012 at 06:47:12PM +0100, Sylvain wrote: > > Hi, > > > > On Sun, Mar 25, 2012 at 12:01:46AM +0800, Diederick C. Niehorster wrote: > > > On Sat, Mar 24, 2012 at 22:19, Sylvain <be...@be...> wrote: > > > > I remember now that the main need to avoid glDrawElements is when we > > > > need several normals on the same vertex (e.g. for a cube - otherwise > > > > the lighting won't work well AFAICR, especially Phong shading). > > > > > > > > Which shapes require glDrawArrays in your opinion? > > > > > > For shapes that have triangles as faces, each combination of normals > > > and vertex coordinates in the hardcoded arrays is used only once. > > > Hence I call glDrawArrays in those cases. > > > > OK, I just understood that current glDrawArrays already reference > > unique vertex+normal pairs. > > > > So indeed it makes sense to avoid using glDrawElements without reusing > > any of these pairs. > > Well, > - I added a comment insisting on vertex+normal unicity, > - added 'GLsizei numVertIdxs' as a parameter, > - called 'fghDrawGeometrySolid' with: > numVertices,numVertIdxs => nameCaps##_VERT_PER_OBJ,nameCaps##_VERT_PER_OBJ_TRI > > This way the variables are clearer (numVertices != numElements), and we'll > have numVertices at all times to allocate the VBO :) |
From: Diederick C. N. <dc...@gm...> - 2012-03-25 02:55:50
|
Hi Sylvain, >> > I was wondering if it would be clearer to describe the shapes with an >> > array of parameters, indexed with an enum, interpreted with code, >> > rather than through macro generation. But that would require >> >> I'm not sure what you're envisioning. Would you have a very simple >> example of the scheme you're thinking of? > > For instance: > > #define CUBE_VERT_ELEM_PER_OBJ ... > static GLfloat name##_verts[nameCaps##_VERT_ELEM_PER_OBJ] > > => could become: > > enum shapes {CUBE, TETRAHEDRON, ...}; > vert_elem_per_obj[CUBE] = ...; > static GLfloat verts[CUBE] = malloc(...); > > This makes the data structure visible instead of hidden in macro > definitions. However, this is probably more difficult to initialize > in C. Hmm, true the code is not easy to parse by human by now (went through a few rounds of reduction, hiding things in macros to avoid errors and copy pasting... If we don't like it or find it too difficult to follow, we can always get part of the definitions out of the macros again, leaving only the function definitions in the macro and having the array (not malloc) array memory allocations writting out in the code. Think that would make things easier to read indeed. I think what you propose above might be more than necessary, as most other things have to be defined separately for different shapes anyway. On Sun, Mar 25, 2012 at 03:53, Sylvain <be...@be...> wrote: > On Sat, Mar 24, 2012 at 06:47:12PM +0100, Sylvain wrote: >> Hi, >> >> On Sun, Mar 25, 2012 at 12:01:46AM +0800, Diederick C. Niehorster wrote: >> > On Sat, Mar 24, 2012 at 22:19, Sylvain <be...@be...> wrote: >> > > I remember now that the main need to avoid glDrawElements is when we >> > > need several normals on the same vertex (e.g. for a cube - otherwise >> > > the lighting won't work well AFAICR, especially Phong shading). >> > > >> > > Which shapes require glDrawArrays in your opinion? >> > >> > For shapes that have triangles as faces, each combination of normals >> > and vertex coordinates in the hardcoded arrays is used only once. >> > Hence I call glDrawArrays in those cases. >> >> OK, I just understood that current glDrawArrays already reference >> unique vertex+normal pairs. >> >> So indeed it makes sense to avoid using glDrawElements without reusing >> any of these pairs. > > Well, > - I added a comment insisting on vertex+normal unicity, > - added 'GLsizei numVertIdxs' as a parameter, > - called 'fghDrawGeometrySolid' with: > numVertices,numVertIdxs => nameCaps##_VERT_PER_OBJ,nameCaps##_VERT_PER_OBJ_TRI > > This way the variables are clearer (numVertices != numElements), and we'll > have numVertices at all times to allocate the VBO :) I saw your changes, they are great! Things are much clearer after you two commits now. Sorry for writing code thats hard to penetrate. I wont comment on the gl3 stuff as I'm not too familiar, but its cool what you've got working an the API additions to make that work are really minimal how you'v done it now, looks good to me :) Best, Dee |
From: Sylvain <be...@be...> - 2012-03-25 08:57:04
|
Hi, On Sun, Mar 25, 2012 at 10:55:40AM +0800, Diederick C. Niehorster wrote: > Hmm, true the code is not easy to parse by human by now (went through > a few rounds of reduction, hiding things in macros to avoid errors and > copy pasting... If we don't like it or find it too difficult to > follow, we can always get part of the definitions out of the macros > again, leaving only the function definitions in the macro and having > the array (not malloc) array memory allocations writting out in the > code. Think that would make things easier to read indeed. I think what > you propose above might be more than necessary, as most other things > have to be defined separately for different shapes anyway. My suggestion may help - or may just make things worse ;) Let's make the changes when we feel they are necessary. > I saw your changes, they are great! Things are much clearer after you > two commits now. Sorry for writing code thats hard to penetrate. > > I wont comment on the gl3 stuff as I'm not too familiar, but its cool > what you've got working an the API additions to make that work are > really minimal how you'v done it now, looks good to me :) Thanks to you for writing nice geometry code that is easy to port :) -- Sylvain |
From: Paul M. <pm...@sk...> - 2012-03-25 18:37:37
|
On 3/24/2012 3:58 PM, Sylvain wrote: > Hi Paul, > > Don't worry, I was the one confused :) Oh, it's all totally confusing, there's no doubt about that. :-) I'm sure the confusion is partially responsible for the slow adoption rate of GL3+... > I'm more familiar with GLES2, so I didn't know enough about VAOs, and > quoted the spec inappropriately. > > So: I thought that OpenGL 3 removed client-side arrays in > glVertexAttribPointer, and so says the page I quoted from the OpenGL > wiki, but I cannot find where that's written in the spec :/ There was a lot of initial confusion over what 3.0 deprecated. I, too, initially thought that client side arrays were deprecated. Perhaps it was, in an early draft of the 3.0 spec, and that's how it got in the wiki. Or perhaps the wiki is referring to the core profile. > Since it doesn't hurt to create VBOs instead of specifying client-side > arrays, I guess I'll do just that. I think that's the way to go! :-) > Also, you wrote "the default VAO is no longer available [in core > profile]", so I suppose we cannot be compatible with both GL2 and > GL3-core-profile? I got that information from the 3.2 spec, page 331, the bullet paragraph that starts with "client vertex and index arrays". This does impede compatibility between GL2 and GL (>= 3.2) core profile. One way to support both would be with separate "plug-in" style c source files that expose the same interface but provide their functionality in a way specific to a particular OpenGL version. Developers could select which OpenGL version to build freeglut for in CMake, and the appropriate c source files would be added to the project (and others left out). But those of you in the freeglut design control seat will have to make that call; I'm kind of a bit player, and feel that my role is just to provide input based on my GL3 experience. -Paul > > - Sylvain > > On Sat, Mar 24, 2012 at 03:29:08PM -0600, Paul Martz wrote: >> I apologize, but I'm confused... Are you using vertex array objects or aren't >> you? Your spec quotes are from section 2.10, so I thought that meant you're >> using vertex array objects. >> >> If you're using VAOs, then VBOs are required as per your spec quotes from >> section 2.10. But you won't be able to run on (unextended) GL2. >> >> If you are not using VAOs, then you can use "just VBOs", or (as I said in my >> original post on this thread) you can source the data from client memory. But in >> this situation you can't use a core profile context. >> -Paul >> >> >> On 3/24/2012 2:55 PM, Sylvain wrote: >>> Hi, >>> >>> Hopefully the code would be shared for OpenGL 2 and 3. >>> Do you mean it is not possible to use just VBOs? >>> >>> - Sylvain >>> >>> On Sat, Mar 24, 2012 at 01:24:15PM -0600, Paul Martz wrote: >>>> If the goal is support for the core profile, then yes, you must use a vertex >>>> array object (the default VAO is no longer available) and must therefore bind a >>>> buffer to GL_ARRAY_BUFFER prior to calling glVertexAttribPointer(). >>>> >>>> Good work! Go for it! :-) >>>> -Paul >>>> >>>> >>>> On 3/24/2012 11:06 AM, Sylvain wrote: >>>>> Hi, >>>>> >>>>> Thanks for the info. >>>>> Though this looks like on its way to deprecation to the least: >>>>> >>>>> Legacy Note: Versions of OpenGL prior to 3.0 allowed the use of >>>>> client-side data for vertex rendering, but GL 3.0 deprecated >>>>> this. Core GL 3.1 and greater forbid client-side vertex data, so >>>>> VBOs are the only means for rendering. >>>>> >>>>> http://www.opengl.org/wiki/Vertex_Buffer_Object >>>>> >>>>> Spec 3.0 §2.10 says: >>>>> >>>>> An INVALID OPERATION error is generated if any of the *Pointer >>>>> commands specifying the location and organization of vertex array >>>>> data are called while a non-zero vertex array object is bound and >>>>> zero is bound to the ARRAY_BUFFER buffer object binding point [2]. >>>>> >>>>> [2] This error makes it impossible to create a vertex array object >>>>> containing client array pointers. >>>>> >>>>> clarified in 3.1 with: >>>>> >>>>> An INVALID_OPERATION error is generated if any of the *Pointer >>>>> commands specifying the location and organization of vertex array >>>>> data are called while zero is bound to the ARRAY_BUFFER buffer >>>>> object binding point, and the pointer argument is not NULL [3]. >>>>> >>>>> [3] This error makes it impossible to create a vertex array object >>>>> containing client array pointers, while still allowing buffer >>>>> objects to be unbound. >>>>> >>>>> (in 3.2 you find the same bits in both the core and compatibility >>>>> profile, §2.8) >>>>> >>>>> The explanation is somewhat obscure, but the footnote is quite clear: >>>>> we can anticipate the disparition of client-side vertex data :/ >>>>> >>>>> - Sylvain >>>>> >>>>> On Sat, Mar 24, 2012 at 09:15:35AM -0600, Paul Martz wrote: >>>>>> Just to clarify, buffer objects are *not* required in GL3+ contexts, >>>>>> glVertexAttribPointer() can still source its data from client-side memory (no >>>>>> error is generated if 0 is bound to GL_ARRAY_BUFFER). >>>>>> -Paul >>>>>> >>>>>> >>>>>> On 3/24/2012 7:35 AM, Sylvain wrote: >>>>>>> (we could keep relying on client-side arrays without VBO, but that's >>>>>>> dropped in OpenGL 3...) >>> >>> ------------------------------------------------------------------------------ >>> This SF email is sponsosred by: >>> Try Windows Azure free for 90 days Click Here >>> http://p.sf.net/sfu/sfd2d-msazure >>> _______________________________________________ >>> Freeglut-developer mailing list >>> Fre...@li... >>> https://lists.sourceforge.net/lists/listinfo/freeglut-developer >>> >>> >> >> ------------------------------------------------------------------------------ >> This SF email is sponsosred by: >> Try Windows Azure free for 90 days Click Here >> http://p.sf.net/sfu/sfd2d-msazure >> _______________________________________________ >> Freeglut-developer mailing list >> Fre...@li... >> https://lists.sourceforge.net/lists/listinfo/freeglut-developer > > ------------------------------------------------------------------------------ > This SF email is sponsosred by: > Try Windows Azure free for 90 days Click Here > http://p.sf.net/sfu/sfd2d-msazure > _______________________________________________ > Freeglut-developer mailing list > Fre...@li... > https://lists.sourceforge.net/lists/listinfo/freeglut-developer > > |
From: John T. <nu...@me...> - 2012-03-25 18:40:28
|
On Sun, Mar 25, 2012 at 12:37:29PM -0600, Paul Martz wrote: > > > > So: I thought that OpenGL 3 removed client-side arrays in > > glVertexAttribPointer, and so says the page I quoted from the OpenGL > > wiki, but I cannot find where that's written in the spec :/ > > There was a lot of initial confusion over what 3.0 deprecated. I, too, initially > thought that client side arrays were deprecated. Perhaps it was, in an early > draft of the 3.0 spec, and that's how it got in the wiki. Or perhaps the wiki is > referring to the core profile. I've said at least 2-3 times in this discussion about revamping the geometry already that vertex arrays are supported accross ALL OPENGL VERSIONS including GL3 and GLES. If people listened to me, there would be much less confusion in this world. -- John Tsiombikas http://nuclear.mutantstargoat.com/ |
From: John F. F. <joh...@cy...> - 2012-03-25 19:32:44
|
Gee, I thought that was MY line. (grin) - John F. On 3/25/2012 1:40 PM, John Tsiombikas wrote: > If people listened to me, there would be much less confusion in this > world. > > |
From: John T. <nu...@me...> - 2012-03-25 18:48:15
|
On Sun, Mar 25, 2012 at 12:37:29PM -0600, Paul Martz wrote: > > Oh, it's all totally confusing, there's no doubt about that. :-) I'm sure the > confusion is partially responsible for the slow adoption rate of GL3+... The slow adoption rate of GL3+ is due to the fact that nobody cares if a bunch of people gathered around a table and said: "right... let's drop 90% of the OpenGL API and call it a new version". -- John Tsiombikas http://nuclear.mutantstargoat.com/ |
From: Sylvain <be...@be...> - 2012-03-25 19:20:47
|
Hi, On Sun, Mar 25, 2012 at 08:40:21PM +0200, John Tsiombikas wrote: > On Sun, Mar 25, 2012 at 12:37:29PM -0600, Paul Martz wrote: > > > > > > So: I thought that OpenGL 3 removed client-side arrays in > > > glVertexAttribPointer, and so says the page I quoted from the OpenGL > > > wiki, but I cannot find where that's written in the spec :/ > > > > There was a lot of initial confusion over what 3.0 deprecated. I, too, initially > > thought that client side arrays were deprecated. Perhaps it was, in an early > > draft of the 3.0 spec, and that's how it got in the wiki. Or perhaps the wiki is > > referring to the core profile. > > I've said at least 2-3 times in this discussion about revamping the > geometry already that vertex arrays are supported accross ALL OPENGL > VERSIONS including GL3 and GLES. [citation needed] ;) No offense intented, I've just heard that and the contrary so looking at the spec was interesting to get the official stance. I guess that in practice this doesn't matter, except that OpenGL tends to be both stricter and more widespread, with lots of new implementations on various embedded chips, so better be on the safe side. Moreover, if GLES3 removes all the functions deprecated by GL3, we can anticipate that client-side arrays won't work anywhere anymore in the near future. Now, I share your annoyment with deprecation, but try not get rude on this list nonetheless. Or add a smiley or two if you intended a joke. -- Sylvain |
From: John T. <nu...@me...> - 2012-03-25 19:58:05
|
On Sun, Mar 25, 2012 at 09:20:39PM +0200, Sylvain wrote: > > Now, I share your annoyment with deprecation, but try not get rude on > this list nonetheless. Or add a smiley or two if you intended a joke. I didn't mean to be rude, I'm just pissed off with the decline of my favourite graphics API into a Direct3D 10 clone :) Btw WebGL has dropped vertex arrays, but I assumed it's because of javascript idiosynchracies. I have no idea if they plan to remove them from GL versions >3 too, but the OpenGL 3 standard that I have does include a vertex arrays section. OpenGL ES 2 definitely has them as I've used them on iOS. -- John Tsiombikas http://nuclear.mutantstargoat.com/ |
From: Diederick C. N. <dc...@gm...> - 2012-03-26 01:51:56
|
Hi, On Mon, Mar 26, 2012 at 02:37, Paul Martz <pm...@sk...> wrote: > One way to support both would be with separate "plug-in" style c source files > that expose the same interface but provide their functionality in a way specific > to a particular OpenGL version. Developers could select which OpenGL version to > build freeglut for in CMake, and the appropriate c source files would be added > to the project (and others left out). Maybe the way that Sylvain is adding support now (see few emails back) could make this all work at runtime. For instance, a call to glutSetVertexAttribCoord3 could take care of the switch between use of GL3+ or not (shader or not actually) render path. Guess for this a flag needs to be stored per context tho. Best, Dee |
From: Sylvain <be...@be...> - 2012-03-27 21:16:06
|
Hi, On Mon, Mar 26, 2012 at 09:51:49AM +0800, Diederick C. Niehorster wrote: > On Mon, Mar 26, 2012 at 02:37, Paul Martz <pm...@sk...> wrote: > > One way to support both would be with separate "plug-in" style c source files > > that expose the same interface but provide their functionality in a way specific > > to a particular OpenGL version. Developers could select which OpenGL version to > > build freeglut for in CMake, and the appropriate c source files would be added > > to the project (and others left out). > > Maybe the way that Sylvain is adding support now (see few emails back) > could make this all work at runtime. > For instance, a call to glutSetVertexAttribCoord3 could take care of > the switch between use of GL3+ or not (shader or not actually) render > path. Guess for this a flag needs to be stored per context tho. I was wondering how to care about thread safety - storing in the context sounds like a good idea :) -- Sylvain |
From: Diederick C. N. <dc...@gm...> - 2012-03-31 23:50:49
|
Hi Sylvain, I'm in the plane, about to leave (and be unresponsive for the next 11 days), but i just saw your commits. Nice progress! Too bad we need to use glshort for index functions, its a limit that might be just too low for some, admittedly, somewhat extreme usage case, but soit for now. Do note that the sphere code needs a bunch more optimization and slight rewriting, so that drawing code can be split off and used for cylinders and cones as well. I have some plans for that but wont get to it for a while. So no need to go out of your way to make it work now, just leave it as is and disable if needed. The core will remain gldrawelements of course. Cya! Dee On 28/03/2012, Sylvain <be...@be...> wrote: > Hi, > > On Mon, Mar 26, 2012 at 09:51:49AM +0800, Diederick C. Niehorster wrote: >> On Mon, Mar 26, 2012 at 02:37, Paul Martz <pm...@sk...> wrote: >> > One way to support both would be with separate "plug-in" style c source >> > files >> > that expose the same interface but provide their functionality in a way >> > specific >> > to a particular OpenGL version. Developers could select which OpenGL >> > version to >> > build freeglut for in CMake, and the appropriate c source files would be >> > added >> > to the project (and others left out). >> >> Maybe the way that Sylvain is adding support now (see few emails back) >> could make this all work at runtime. >> For instance, a call to glutSetVertexAttribCoord3 could take care of >> the switch between use of GL3+ or not (shader or not actually) render >> path. Guess for this a flag needs to be stored per context tho. > > I was wondering how to care about thread safety - storing in the > context sounds like a good idea :) > > -- > Sylvain > > ------------------------------------------------------------------------------ > This SF email is sponsosred by: > Try Windows Azure free for 90 days Click Here > http://p.sf.net/sfu/sfd2d-msazure > _______________________________________________ > Freeglut-developer mailing list > Fre...@li... > https://lists.sourceforge.net/lists/listinfo/freeglut-developer > |