From: Matti L. <m-Matti-a.Lehtonen@IKI.Fi> - 2011-06-23 12:50:05
|
Hi! I have managed to do a hackish port of stub of freeglut 2.6.0, that is using X11 and EGL for OpenGL ES 2.0 initialization. Works with PowerVR's OpenGL ES 2 emulator at Ubuntu, but still have some issues with Nokia N900 OpenGL ES 2 library. This hacked stub do not include font, menu, geometry and teapot parts of freeglut. How ever, I am willing to write proper port during summer/autumn, but I would gladly hear community's opinion about how Freeglut's API shall be extended for shaders. Note that I may need some support for windows code, because I have no related windows experience. I realized during hacking that maybe current configuration should be changed so that there are separate configuration, how native window is created&initialized (by e.g. X11), who initializes OpenGL (by e.g. X11 or EGL) and which [OpenGL] API is used (if several choices are available, like EGL do have). I also wonder, would it be possible to create a single freeglut library that can be used together with OpenGL 1+, OpenGL ES 1.x and OpenGL ES 2.x (at Nokia N900 it is currently possible to choose between all three of them). Two or even three separate freeglut libraries feels excessive. Lehtonen, Matti -- Life is complex. It has real and imaginary parts. |
From: Diederick C. N. <dc...@gm...> - 2011-06-23 14:56:48
|
Hi Matti, Nice work! There are a couple of issues that spring to my mind (though I am not one of the powers that be in the freeglut project, so they might feel differently). Keep in mind that I know absolutely nothing about OpenGL ES. - Extending the API is something that the FreeGLUT project tends to refrain from, as it is not in line with FreeGLUT's goal, which is compatibility with the original GLUT above all else. That being said, adding some thing to glutSetOption tell extend (not change existing behavior unless it is wrong!) internal behavior of the library without otherwise affecting the API is probably fine. A (relatively) recent exampe of this is flags for support of creating OpenGL 3 contexts. - So if some of the things you are talking about can be implemented that way (I know nothing about the various options you discuss), that might be a way to go. - #ifdef hell: it is probably a good idea to avoid adding a lot more ifdef's. Maybe you could make a start moving towards putting platform specific code in its own files per platform, at least for the new code that you are adding. That would be a good example for what shoul happen to the codebase in general. - on what way does the API need to be extended for shaders by the way? That is glxxxx function that have nothing to do with freeglut? Or is that different in the embedded version? - on your last question, again not knowing anything about opengl es, is there any way in which freeglut needs to explicitly support the various opengl versions, except for some context creation flags and such? Just to get some view on this. Thanks! Dee On Thu, Jun 23, 2011 at 20:49, Matti Lehtonen <m-M...@ik...> wrote: > Hi! > > I have managed to do a hackish port of stub of freeglut 2.6.0, that is using > X11 and EGL for OpenGL ES 2.0 initialization. Works with PowerVR's OpenGL ES > 2 emulator at Ubuntu, but still have some issues with Nokia N900 OpenGL ES 2 > library. > > This hacked stub do not include font, menu, geometry and teapot parts of > freeglut. How ever, I am willing to write proper port during summer/autumn, > but I would gladly hear community's opinion about how Freeglut's API shall > be extended for shaders. Note that I may need some support for windows code, > because I have no related windows experience. > > I realized during hacking that maybe current configuration should be changed > so that there are separate configuration, how native window is > created&initialized (by e.g. X11), who initializes OpenGL (by e.g. X11 or > EGL) and which [OpenGL] API is used (if several choices are available, like > EGL do have). > > I also wonder, would it be possible to create a single freeglut library that > can be used together with OpenGL 1+, OpenGL ES 1.x and OpenGL ES 2.x (at > Nokia N900 it is currently possible to choose between all three of them). > Two or even three separate freeglut libraries feels excessive. > > Lehtonen, Matti > -- > Life is complex. It has real and imaginary parts. > > > ------------------------------------------------------------------------------ > Simplify data backup and recovery for your virtual environment with vRanger. > Installation's a snap, and flexible recovery options mean your data is safe, > secure and there when you need it. Data protection magic? > Nope - It's vRanger. Get your free trial download today. > http://p.sf.net/sfu/quest-sfdev2dev > _______________________________________________ > Freeglut-developer mailing list > Fre...@li... > https://lists.sourceforge.net/lists/listinfo/freeglut-developer > > |
From: Matti L. <m-Matti-a.Lehtonen@IKI.Fi> - 2011-06-23 16:51:12
|
Hi, On 23 June 2011 17:56, Diederick C. Niehorster <dc...@gm...> wrote: > Hi Matti, > > Nice work! > > There are a couple of issues that spring to my mind (though I am not > one of the powers that be in the freeglut project, so they might feel > differently). Keep in mind that I know absolutely nothing about OpenGL > ES. > > - Extending the API is something that the FreeGLUT project tends to > refrain from, as it is not in line with FreeGLUT's goal, which is > compatibility with the original GLUT above all else. That being said, > adding some thing to glutSetOption tell extend (not change existing > behavior unless it is wrong!) internal behavior of the library without > otherwise affecting the API is probably fine. A (relatively) recent > exampe of this is flags for support of creating OpenGL 3 contexts. > Most likely the used [OpenGL] API selection shall behave very similarly than that one, > - So if some of the things you are talking about can be implemented > that way (I know nothing about the various options you discuss), that > might be a way to go. > > - #ifdef hell: it is probably a good idea to avoid adding a lot more > ifdef's. Maybe you could make a start moving towards putting platform > specific code in its own files per platform, at least for the new code > that you are adding. That would be a good example for what shoul > happen to the codebase in general. > Yeah, noticed that one ;-) > - on what way does the API need to be extended for shaders by the way? > That is glxxxx function that have nothing to do with freeglut? Or is > that different in the embedded version? > The original glut were born when there were only OpenGL 1.x. The same issues will rise again, when people are asking, if freeglut will work with OpenGL 4.x (no more glColor(), glRotate(), glScale(), glTranslate() etc, situation like OpenGL ES 2.x does now have). If e.g. a solid cube (geometry: glutSolidCube(double dSize) ) is wanted to be some where else than origo or with different orientation or other color than white with shaders, things can be difficult .... :) So something extra must be passed ... maybe the current shader program shall have freeglut 'standardized' (btw ES 2.0 has very limited list of build-in variables) vertex attributes and uniforms or something more complicated solution. Anyway, some solution that can be used with OpenGL 4.x later. - on your last question, again not knowing anything about opengl es, > is there any way in which freeglut needs to explicitly support the > various opengl versions, except for some context creation flags and > such? Just to get some view on this. > After EGL is initialized with eglInitialize() function call, it is possible (and I believe later again, before contex creation) to select used API by eglBindAPI() function call. Supported APIs at EGL 1.4 are EGL_OPENGL_API. EGL_OPENGL_ES_API and EGL_OPENVG_API. And when a windows surface is created, it can be required to support several APIs simultaneously. The EGL_RENDERABLE_TYPE attribute can have EGL_OPENGL_BIT (OpenGL 1.x or 2.x), EGL_OPENGL_ES_BIT (OpenGL ES 1.x), EGL_OPENGL_ES2_BIT (OpenGL ES 2.x), EGL_OPENVG_BIT (OpenVG 1.x). With EGL it would be possible that freeglut is not limiting what version of OpenGL is used at applications. And hopefully only one freeglut library is needed to support full range of OpenGL APIs. Lehtonen, Matti -- Life is complex. It has real and imaginary parts. |
From: John T. <nu...@me...> - 2011-06-24 00:04:37
|
On Thu, Jun 23, 2011 at 07:51:04PM +0300, Matti Lehtonen wrote: > > - on what way does the API need to be extended for shaders by the way? > > That is glxxxx function that have nothing to do with freeglut? Or is > > that different in the embedded version? > > > > The original glut were born when there were only OpenGL 1.x. The same issues > will rise again, when people are asking, if freeglut will work with OpenGL > 4.x (no more glColor(), glRotate(), glScale(), glTranslate() etc, situation > like OpenGL ES 2.x does now have). > > If e.g. a solid cube (geometry: glutSolidCube(double dSize) ) is wanted to > be some where else than origo or with different orientation or other color > than white with shaders, things can be difficult .... :) > > So something extra must be passed ... maybe the current shader program shall > have freeglut 'standardized' (btw ES 2.0 has very limited list of build-in > variables) vertex attributes and uniforms or something more complicated > solution. Anyway, some solution that can be used with OpenGL 4.x later. Glut should have nothing to do with shaders. Since OpenGL is apparently now governed by inmates of a mental institution, and they decided to DROP THE WHOLE API, the only reasonable way for glut to go about supporting the standard primitives it provides is to just drop the vertex data to OpenGL and let the user handle the rest with their custom shader. That's what glut's primitive did up to now anyway, we don't touch lighting states and whatnot, it just happened that up to now the OpenGL API was reasonable enough to handle those things for the user. Now it doesn't so let the user go bitch at khronos. Or even better yet, let the user understand that creating a new "crippled opengl context" is a stupid thing to do. No vendor in their right mind will ever stop supporting the original OpenGL context anyway. Trying to add a series of "standard attributes" for the equivalent of the fixed-function lights, matrices, and materials, and telling the user to please pass those things to us, I think is rather stupid. </rant> -- John Tsiombikas http://nuclear.mutantstargoat.com/ |
From: Diederick C. N. <dc...@gm...> - 2011-06-24 02:28:03
|
On Fri, Jun 24, 2011 at 00:51, Matti Lehtonen <m-M...@ik...> wrote: > Hi, > > On 23 June 2011 17:56, Diederick C. Niehorster <dc...@gm...> wrote: >> >> Hi Matti, >> >> Nice work! >> >> There are a couple of issues that spring to my mind (though I am not >> one of the powers that be in the freeglut project, so they might feel >> differently). Keep in mind that I know absolutely nothing about OpenGL >> ES. >> >> - Extending the API is something that the FreeGLUT project tends to >> refrain from, as it is not in line with FreeGLUT's goal, which is >> compatibility with the original GLUT above all else. That being said, >> adding some thing to glutSetOption tell extend (not change existing >> behavior unless it is wrong!) internal behavior of the library without >> otherwise affecting the API is probably fine. A (relatively) recent >> exampe of this is flags for support of creating OpenGL 3 contexts. > > Most likely the used [OpenGL] API selection shall behave very similarly than > that one, > > >> >> - So if some of the things you are talking about can be implemented >> that way (I know nothing about the various options you discuss), that >> might be a way to go. >> > Hi Matti, On Fri, Jun 24, 2011 at 00:51, Matti Lehtonen <m-M...@ik...> wrote: > Hi, > > On 23 June 2011 17:56, Diederick C. Niehorster <dc...@gm...> wrote: >> - #ifdef hell: it is probably a good idea to avoid adding a lot more >> ifdef's. Maybe you could make a start moving towards putting platform >> specific code in its own files per platform, at least for the new code >> that you are adding. That would be a good example for what shoul >> happen to the codebase in general. > > Yeah, noticed that one ;-) > Hmm, I'd be willing to help doing this on the Windows side, but I won't/can't touch the Linux code. The simple way would be to have subdirectories in the src directory, one for each platform that is significantly different from the other (I'd want to keep the windows and windows CE code together for instand due to its very significant overlap) and move all the platform-specific code into functions in that directory. Probably leave the internal header untouched for now as far as possible. This might require working some internal logic/flow but not too much I suspect. This is a worthy endeavor anyway as it'll make future ports much easier (think native OSX if someone ever wants to start that). >> >> - on what way does the API need to be extended for shaders by the way? >> That is glxxxx function that have nothing to do with freeglut? Or is >> that different in the embedded version? > > The original glut were born when there were only OpenGL 1.x. The same issues > will rise again, when people are asking, if freeglut will work with OpenGL > 4.x (no more glColor(), glRotate(), glScale(), glTranslate() etc, situation > like OpenGL ES 2.x does now have). > > If e.g. a solid cube (geometry: glutSolidCube(double dSize) ) is wanted to > be some where else than origo or with different orientation or other color > than white with shaders, things can be difficult .... :) > > So something extra must be passed ... maybe the current shader program shall > have freeglut 'standardized' (btw ES 2.0 has very limited list of build-in > variables) vertex attributes and uniforms or something more complicated > solution. Anyway, some solution that can be used with OpenGL 4.x later. Good point, didn't think of those. I'm afraid that with the new-style OpenGL versions the user will be stuck with rolling its own solution (in line with the philosophy of those OpenGL versions....). One might make a small addition to the interface whereby the vertices of the object are returned to client code instead of drawn to the GPU, so you can do whatever manipulations and wrap it in whatever drawing code you need. Simple new glutGet item or maybe a new glutGetGeometry, while I'd go for the first. But as first 'solution' I'd say one can't use these functions unless one sticks to OpenGL 2.x or less. >> - on your last question, again not knowing anything about opengl es, >> is there any way in which freeglut needs to explicitly support the >> various opengl versions, except for some context creation flags and >> such? Just to get some view on this. > > After EGL is initialized with eglInitialize() function call, it is possible > (and I believe later again, before contex creation) to select used API by > eglBindAPI() function call. Supported APIs at EGL 1.4 are EGL_OPENGL_API. > EGL_OPENGL_ES_API and EGL_OPENVG_API. > And when a windows surface is created, it can be required to support several > APIs simultaneously. The EGL_RENDERABLE_TYPE attribute can have > EGL_OPENGL_BIT (OpenGL 1.x or 2.x), EGL_OPENGL_ES_BIT (OpenGL ES 1.x), > EGL_OPENGL_ES2_BIT (OpenGL ES 2.x), EGL_OPENVG_BIT (OpenVG 1.x). > > With EGL it would be possible that freeglut is not limiting what version of > OpenGL is used at applications. And hopefully only one freeglut library is > needed to support full range of OpenGL APIs. How I am reading this is the same as your response to the firs question: I think a couple of glutSetOptions can give us all the flexibility needed and the logic will be internal to FreeGLUT. By the way, is this something that only plays a role on embedded devices, or also for desktops? In general, better wait for a person of substance on this list to voice their opinion before attempting this big project however. Especially as it will involve significant infrastructure work. Once we got a green light (who would be able to give us such a light?), we could start work, maybe in a separate SVN branch? Would you be around after the summer by the way to maintain the code you wrote? Best, Dee |
From: Matti L. <m-Matti-a.Lehtonen@IKI.Fi> - 2011-06-24 08:58:25
|
Hi, On 24 June 2011 03:04, John Tsiombikas <nu...@me...> wrote: > Glut should have nothing to do with shaders. Since OpenGL is apparently > now governed by inmates of a mental institution, and they decided to > DROP THE WHOLE API, the only reasonable way for glut to go about > supporting the standard primitives it provides is to just drop the > vertex data to OpenGL and let the user handle the rest with their custom > shader. > Programmable pipeline do have its advantages over fixed pipeline, but like everything, advantages come usually with some costs. > That's what glut's primitive did up to now anyway, we don't touch > lighting states and whatnot, it just happened that up to now the OpenGL > API was reasonable enough to handle those things for the user. All that is needed is to pass vertices and in some cases, normals too to shader. That is it. Nothing more. Nothing less, ... well that is not true, no more QUADs. Have to use triangles. > No vendor in their right mind will ever stop > supporting the original OpenGL context anyway. > Actually that is not true, e.g. Nokia N900 offers only ES contexts with HW acceleration. Trying to add a series of "standard attributes" for the equivalent of > the fixed-function lights, matrices, and materials, and telling the user > to please pass those things to us, I think is rather stupid. > Did I said somewhere that everything must be passed to freeglut functions? As I said earlier, passing vertex and normal information for shader is enought. The ported freeglut code shall look something like this: // Fill vertex and normal arrays ... // Pass arrays to shader program GlInt cp, val, nal; glGetIntegerv( GL_CURRENT_PROGRAM, &cp ); val = glGetAttribLocation( p, "a_Vertex3" ); glEnableVertexAttribArray( val ); glVertexAttribPointer( val, 3, GL_FLOAT, GL_TRUE, 0, vertexArray ); nal = glGetAttribLocation( p, "a_Normal" ); if( nal != -1 ) { // Shader program needs normals as input glEnableVertexAttribArray( nal ); glVertexAttribPointer( nal, 3, GL_FLOAT, GL_TRUE, 0, normalArray ); } // Do the rendering ... Lehtonen, Matti -- Life is complex. It has real and imaginary parts. |
From: Diederick C. N. <dc...@gm...> - 2011-06-24 09:37:40
|
Hi Matti, On Fri, Jun 24, 2011 at 16:58, Matti Lehtonen <m-M...@ik...> wrote: > Hi, > > Did I said somewhere that everything must be passed to freeglut functions? > As I said earlier, passing vertex and normal information for shader is > enought. > > The ported freeglut code shall look something like this: > // Fill vertex and normal arrays > ... > // Pass arrays to shader program > GlInt cp, val, nal; > glGetIntegerv( GL_CURRENT_PROGRAM, &cp ); > val = glGetAttribLocation( p, "a_Vertex3" ); > glEnableVertexAttribArray( val ); > glVertexAttribPointer( val, 3, GL_FLOAT, GL_TRUE, 0, vertexArray ); > nal = glGetAttribLocation( p, "a_Normal" ); > if( nal != -1 ) > { > // Shader program needs normals as input > glEnableVertexAttribArray( nal ); > glVertexAttribPointer( nal, 3, GL_FLOAT, GL_TRUE, 0, normalArray ); > } > // Do the rendering > ... Ah yes, that might be a good thing to do, passing the vertex data in one way or the other, depending on the context used (forward-compatible openGL 3+ and opengl ES). Just asking as I don't know: is the attrib location such as a_Vertex3 in glGetAttribLocation( p, "a_Vertex3" ) fixed? Guess not? Then FreeGLUT would be forcing shader programmers to use these names if they use glut's objects. I don't see a nice way around it, my earlier suggestion of returning vertex buffers leaves the resource freeing responsibility to the programmer, which is not ideal either... Best, Dee |
From: Matti L. <m-Matti-a.Lehtonen@IKI.Fi> - 2011-06-24 10:10:01
|
Hi, On 24 June 2011 12:37, Diederick C. Niehorster <dc...@gm...> wrote: > Hi Matti, > > On Fri, Jun 24, 2011 at 16:58, Matti Lehtonen <m-M...@ik...> > wrote: > > Hi, > > > > Did I said somewhere that everything must be passed to freeglut > functions? > > As I said earlier, passing vertex and normal information for shader is > > enought. > > > > The ported freeglut code shall look something like this: > > // Fill vertex and normal arrays > > ... > > // Pass arrays to shader program > > GlInt cp, val, nal; > > glGetIntegerv( GL_CURRENT_PROGRAM, &cp ); > > val = glGetAttribLocation( p, "a_Vertex3" ); > > glEnableVertexAttribArray( val ); > > glVertexAttribPointer( val, 3, GL_FLOAT, GL_TRUE, 0, vertexArray ); > > nal = glGetAttribLocation( p, "a_Normal" ); > > if( nal != -1 ) > > { > > // Shader program needs normals as input > > glEnableVertexAttribArray( nal ); > > glVertexAttribPointer( nal, 3, GL_FLOAT, GL_TRUE, 0, normalArray ); > > } > > // Do the rendering > > ... > > Ah yes, that might be a good thing to do, passing the vertex data in > one way or the other, depending on the context used > (forward-compatible openGL 3+ and opengl ES). Just asking as I don't > know: is the attrib location such as a_Vertex3 in glGetAttribLocation( > p, "a_Vertex3" ) fixed? Guess not? Yes and no. Typically the location zero (0) is reserved for vertex information "gl_Vertex" (type vec4). If shader isn't using "gl_Vertex", then its location is -1 and location zero is typically left empty. If some other name is used for vertex information, then it's location can be pretty much everything ... except zero. Of course there are function that says that use this location for that input (doable before linking). I once tried to redefine "gl_Vertex" to be vec2 instead of vec4, but the final result were unexpected. I were expecting error at compilation phase, but instead, I got shader that passed compilation *and* linking , but location of "gl_Vertex" were -1. :O Lehtonen, Matti -- Life is complex. It has real and imaginary parts. |
From: Jason W. <jas...@gm...> - 2011-06-24 13:10:36
|
On Thu, Jun 23, 2011 at 7:04 PM, John Tsiombikas <nu...@me...> wrote: > Glut should have nothing to do with shaders. Since OpenGL is apparently > now governed by inmates of a mental institution, and they decided to > DROP THE WHOLE API... This made my whole day :) I've actually thought about starting a project to write an API that adds back all the stuff OpenGL is going to be missing. Even with shaders I am constantly having to dig around trying to figure out how to do things that OpenGL USED TO DO sensibly for me, like handle degenerate normals in Phong lighting (would love it if nvidia could just give us the shader code for its fixed function lighting). And to top it off I have to deal with pinheads on Wiki's who remind me that things like texture coordinate generation are OMG DEPRECATED. </rant> |
From: Matti L. <m-Matti-a.Lehtonen@IKI.Fi> - 2011-06-26 07:41:36
|
Hi, On 24 June 2011 16:10, Jason Wilkins <jas...@gm...> wrote: > On Thu, Jun 23, 2011 at 7:04 PM, John Tsiombikas <nu...@me...> > wrote: > > Glut should have nothing to do with shaders. Since OpenGL is apparently > > now governed by inmates of a mental institution, and they decided to > > DROP THE WHOLE API... > > This made my whole day :) > > I've actually thought about starting a project to write an API that > adds back all the stuff OpenGL is going to be missing. Even with > shaders I am constantly having to dig around trying to figure out how > to do things that OpenGL USED TO DO sensibly for me, like handle > degenerate normals in Phong lighting (would love it if nvidia could > just give us the shader code for its fixed function lighting). And to > top it off I have to deal with pinheads on Wiki's who remind me that > things like texture coordinate generation are OMG DEPRECATED. </rant> I have similar feelings, when I did implement cube environment reflection mapping with shaders. A real pain in ass, to get results match each other at OpenGL 1.x and OpenGL ES 2 :( I were also wondering, what the hell they were thinking, when there is no support for matrix operations outside of shaders, but you "have to" pass matrices that may have multiplied or inverted on embedded devices that typically don't have support for HW based floats at CPU :O Lehtonen, Matti -- Life is complex. It has real and imaginary parts. |
From: John T. <nu...@me...> - 2011-06-24 14:23:38
|
On Fri, Jun 24, 2011 at 11:58:18AM +0300, Matti Lehtonen wrote: > > Programmable pipeline do have its advantages over fixed pipeline, but like > everything, advantages come usually with some costs. There's no need to pay any costs, OpenGL 2 is perfect in that respect. Allows you to use the programmable pipeline or the fixed function pipeline and mix them together at your discretion. They are not mutually exclusive. > > No vendor in their right mind will ever stop > > supporting the original OpenGL context anyway. > > > > Actually that is not true, e.g. Nokia N900 offers only ES contexts with HW > acceleration. I was rather referring to the new desktop OpenGL versions. Sadly mobile platforms are all using that ES crap. > Trying to add a series of "standard attributes" for the equivalent of > > the fixed-function lights, matrices, and materials, and telling the user > > to please pass those things to us, I think is rather stupid. > > > > Did I said somewhere that everything must be passed to freeglut functions? > As I said earlier, passing vertex and normal information for shader is > enought. I'm sorry I forgot that OpenGL 4 deprecates even the standard attributes. I thought you meant having a custom shader and telling the user to give us all the relevant state. > val = glGetAttribLocation( p, "a_Vertex3" ); > nal = glGetAttribLocation( p, "a_Normal" ); I think that it would be much more reasonable to use the standard OpenGL 2+ attribute names: gl_Vertex, gl_Normal, etc. -- John Tsiombikas http://nuclear.mutantstargoat.com/ |
From: Matti L. <m-Matti-a.Lehtonen@IKI.Fi> - 2011-06-26 07:26:47
|
Hi, On 24 June 2011 17:23, John Tsiombikas <nu...@me...> wrote: > On Fri, Jun 24, 2011 at 11:58:18AM +0300, Matti Lehtonen wrote: > > > > Did I said somewhere that everything must be passed to freeglut > functions? > > As I said earlier, passing vertex and normal information for shader is > > enought. > > I'm sorry I forgot that OpenGL 4 deprecates even the standard > attributes. I thought you meant having a custom shader and telling the > user to give us all the relevant state. > Yes and no. User has responsibility to setup current shader so far that only vertex (and normal) informations are missing before rendering. Instead of fixed vertex and normal attribute names, there could be freeglut set functions that user can use to tell freeglut, which names user has used for vertices and normals in shaders. > > val = glGetAttribLocation( p, "a_Vertex3" ); > > nal = glGetAttribLocation( p, "a_Normal" ); > > I think that it would be much more reasonable to use the standard OpenGL > 2+ attribute names: gl_Vertex, gl_Normal, etc. > I believe that those standard attribute names were only introduces to get fixed pipeline to work with programmable pipeline. Both OpenGL ES 2.0 and OpenGL 4.0 don't have fixed pipeline and no standard vertex attributes except "vec4 gl_Vertex". Most likely e.g. glVertexPointer() were only a wrapper that finally called glVertexAttribPointer() (or something similar) on those OpenGLs that mixed fixed and programmable pipelines. Actually I tried to use those standard names for my shaders, when I ported my application to OpenGL ES 2, but I quickly noticed that shader compiler won't allow that. And so I ended into naming scheme, where I used body of std. name and replaced "gl_" with either "a_" or "u_". Lehtonen, Matti -- > Life is complex. It has real and imaginary parts. |
From: Jason W. <jas...@gm...> - 2011-06-26 08:57:55
|
I really do not think it is worth adding APIs to freeglut to support drawing a teapot without deprecated functionality. If you are going through all the trouble of setting up to draw using an API that is even more low level than it was before then I think you can just draw your own damned teapot :) It would be better to just say these things won't work if you do not have standard attributes. So if you request "core" functionality freeglut should also disable features that don't work and give a warning if you use it. Honestly if you've already written all the code to compile/link a shader and setup VBOs then the code to draw a cube or teapot is not a big deal. You are not going to be able to write a 50 line glut program that does anything interesting without the deprecated functionality. However, freeglut will still be able to portably make a window for you and get your mouse events, and that is what is most important. On Sun, Jun 26, 2011 at 2:26 AM, Matti Lehtonen <m-M...@ik...> wrote: > Hi, > > On 24 June 2011 17:23, John Tsiombikas <nu...@me...> wrote: >> >> On Fri, Jun 24, 2011 at 11:58:18AM +0300, Matti Lehtonen wrote: >> > >> > Did I said somewhere that everything must be passed to freeglut >> > functions? >> > As I said earlier, passing vertex and normal information for shader is >> > enought. >> >> I'm sorry I forgot that OpenGL 4 deprecates even the standard >> attributes. I thought you meant having a custom shader and telling the >> user to give us all the relevant state. > > Yes and no. User has responsibility to setup current shader so far that only > vertex (and normal) informations are missing before rendering. > > Instead of fixed vertex and normal attribute names, there could be freeglut > set functions that user can use to tell freeglut, which names user has used > for vertices and normals in shaders. > > >> >> > val = glGetAttribLocation( p, "a_Vertex3" ); >> > nal = glGetAttribLocation( p, "a_Normal" ); >> >> I think that it would be much more reasonable to use the standard OpenGL >> 2+ attribute names: gl_Vertex, gl_Normal, etc. > > I believe that those standard attribute names were only introduces to get > fixed pipeline to work with programmable pipeline. Both OpenGL ES 2.0 and > OpenGL 4.0 don't have fixed pipeline and no standard vertex attributes > except "vec4 gl_Vertex". Most likely e.g. glVertexPointer() were only a > wrapper that finally called glVertexAttribPointer() (or something similar) > on those OpenGLs that mixed fixed and programmable pipelines. > > Actually I tried to use those standard names for my shaders, when I ported > my application to OpenGL ES 2, but I quickly noticed that shader compiler > won't allow that. And so I ended into naming scheme, where I used body of > std. name and replaced "gl_" with either "a_" or "u_". > > Lehtonen, Matti > -- > > Life is complex. It has real and imaginary parts. > > > ------------------------------------------------------------------------------ > All of the data generated in your IT infrastructure is seriously valuable. > Why? It contains a definitive record of application performance, security > threats, fraudulent activity, and more. Splunk takes this data and makes > sense of it. IT sense. And common sense. > http://p.sf.net/sfu/splunk-d2d-c2 > _______________________________________________ > Freeglut-developer mailing list > Fre...@li... > https://lists.sourceforge.net/lists/listinfo/freeglut-developer > > |
From: Matti L. <m-Matti-a.Lehtonen@IKI.Fi> - 2011-06-26 11:15:16
|
On 24 June 2011 05:27, Diederick C. Niehorster <dc...@gm...> wrote: > > By the > way, is this something that only plays a role on embedded devices, or > also for desktops? > OpenGL ES 2 is mainly for embedded devices, but I can run OpenGL ES 2 applications on desktop with emulation (e.g. Powervr). Debugging applications at desktop is much nicer :) I believe that there isn't much use for simultaneously access different OpenGL APIs from the same application. I think that I could write for demonstration an application that creates threads [and windows] for each available OpenGL API to "show off" some freeglut geometry objects. > In general, better wait for a person of substance on this list to > voice their opinion before attempting this big project however. > Especially as it will involve significant infrastructure work. Once we > got a green light (who would be able to give us such a light?), we > could start work, maybe in a separate SVN branch? Would you be around > after the summer by the way to maintain the code you wrote? > I don't see problem with [free] time. Lehtonen, Matti -- Life is complex. It has real and imaginary parts. |
From: Matti L. <m-Matti-a.Lehtonen@IKI.Fi> - 2011-06-26 18:53:34
|
Hi, On 26 June 2011 14:15, Matti Lehtonen <m-M...@ik...> wrote: > > > On 24 June 2011 05:27, Diederick C. Niehorster <dc...@gm...> wrote: > >> >> By the >> way, is this something that only plays a role on embedded devices, or >> also for desktops? >> > > OpenGL ES 2 is mainly for embedded devices, but I can run OpenGL ES 2 > applications on desktop with emulation (e.g. Powervr). Debugging > applications at desktop is much nicer :) > > I believe that there isn't much use for simultaneously access different > OpenGL APIs from the same application. I think that I could write for > demonstration an application that creates threads [and windows] for each > available OpenGL API to "show off" some freeglut geometry objects. > Thinking again, linking different opengl libraries to same application will be next to impossible. Lehtonen, Matti -- Life is complex. It has real and imaginary parts. |
From: John T. <nu...@me...> - 2011-06-26 19:28:41
|
On Sun, Jun 26, 2011 at 03:57:47AM -0500, Jason Wilkins wrote: > I really do not think it is worth adding APIs to freeglut to support > drawing a teapot without deprecated functionality. > > If you are going through all the trouble of setting up to draw using > an API that is even more low level than it was before then I think you > can just draw your own damned teapot :) > > .... yada yada .... > > However, freeglut will still be able to portably make > a window for you and get your mouse events, and that is what is most > important. I agree 100%. It seems there is no sane way to implement the GLUT primitives in OpenGL 4/OpenGL ES 2. Anything we could try to make this work is pointless and complicated, and most importantly incompatible with the original GLUT usage, where you simply called glutSolidTeapot and it just worked. -- John Tsiombikas http://nuclear.mutantstargoat.com/ |
From: Matti L. <m-Matti-a.Lehtonen@IKI.Fi> - 2011-06-26 20:09:19
|
Hi, On 26 June 2011 22:28, John Tsiombikas <nu...@me...> wrote: > I agree 100%. It seems there is no sane way to implement the GLUT > primitives in OpenGL 4/OpenGL ES 2. Anything we could try to make this > work is pointless and complicated, and most importantly incompatible > with the original GLUT usage, where you simply called glutSolidTeapot > and it just worked. > It sounds like you are afraid that you will lose the old way of using [free]GLUT. I am not proposing anything like that. What I am proposing that everybody can use freeglut with any branch of OpenGL they want, like I do. I have ported an application to work with OpenGL ES 1.x, OpenGL 1.x, OpenGL 2.x (with shaders) and OpenGL ES 2.x. Each compilations use some version of freeglut. Okay, that application don't use freeglut fonts, menus or geometries, but some other may need them. Lehtonen, Matti -- Life is complex. It has real and imaginary parts. |
From: Jason W. <jas...@gm...> - 2011-06-26 23:21:12
|
I do not think it is a matter of fear at all. The reason why GLUT and GLU could provide some convenience functions for some simple geometric models is that the original OpenGL has a nice generic way of sending primitives to the library that allowed you to ignore state. (I happen to LOVE immediate mode, its brilliant for prototyping, unlike filling and managing a VBO). GLU goes as far as allowing you to tell it to send texcoords and normals if you want, and GLUT just sends it all. OpenGL had nice easy to use behavior even if it wasn't the most efficient. You can write code that works with other's code easily because everybody had to send colors or whatever in the same way. Now in the name of making OpenGL smaller and faster they are tossing this out. IMHO they are just making it so that everybody can implement the common behavior less efficiently and with more bugs than the dedicated people at AMD/NVIDIA would. I'm still bitter that I can't figure out how to keep the knob of the lid of the teapot from turning black in a shader due to the degenerate normals while the fixed function pipeline handles this magically somehow :) Anyway, I guess I should make my point. The new way of setting up OpenGL is very open ended. When there was "one way(tm)" to do it, having glutSolidTeapot made sense. If you try to write a function like that now it seems arbitrary. It feels like the user will have to write a shader that supports freeglut's teapot instead of glutSolidTeapot supporting what they were going to do anyway. On Sun, Jun 26, 2011 at 3:09 PM, Matti Lehtonen <m-M...@ik...> wrote: > Hi, > > On 26 June 2011 22:28, John Tsiombikas <nu...@me...> wrote: >> >> I agree 100%. It seems there is no sane way to implement the GLUT >> primitives in OpenGL 4/OpenGL ES 2. Anything we could try to make this >> work is pointless and complicated, and most importantly incompatible >> with the original GLUT usage, where you simply called glutSolidTeapot >> and it just worked. > > It sounds like you are afraid that you will lose the old way of using > [free]GLUT. I am not proposing anything like that. What I am proposing that > everybody can use freeglut with any branch of OpenGL they want, like I do. > > I have ported an application to work with OpenGL ES 1.x, OpenGL 1.x, OpenGL > 2.x (with shaders) and OpenGL ES 2.x. Each compilations use some version of > freeglut. Okay, that application don't use freeglut fonts, menus or > geometries, but some other may need them. > > Lehtonen, Matti > -- > Life is complex. It has real and imaginary parts. > > > ------------------------------------------------------------------------------ > All of the data generated in your IT infrastructure is seriously valuable. > Why? It contains a definitive record of application performance, security > threats, fraudulent activity, and more. Splunk takes this data and makes > sense of it. IT sense. And common sense. > http://p.sf.net/sfu/splunk-d2d-c2 > _______________________________________________ > Freeglut-developer mailing list > Fre...@li... > https://lists.sourceforge.net/lists/listinfo/freeglut-developer > > |
From: John T. <nu...@me...> - 2011-06-27 06:12:38
|
On Sun, Jun 26, 2011 at 11:09:12PM +0300, Matti Lehtonen wrote: > Hi, > > On 26 June 2011 22:28, John Tsiombikas <nu...@me...> wrote: > > > I agree 100%. It seems there is no sane way to implement the GLUT > > primitives in OpenGL 4/OpenGL ES 2. Anything we could try to make this > > work is pointless and complicated, and most importantly incompatible > > with the original GLUT usage, where you simply called glutSolidTeapot > > and it just worked. > > > > It sounds like you are afraid that you will lose the old way of using > [free]GLUT. I am not proposing anything like that. What I am proposing that > everybody can use freeglut with any branch of OpenGL they want, like I do. Afraid?! What on earth makes you say that? THE major consideration behind any change in freeglut is maintaining compatibility with GLUT. That's a given, nothing is going to be lost. What we're discussing here is about finding a way to implement the same functionality, on top of OpenGL ES 2, or pure OpenGL 4 context-using programs. And what I was just saying is that it seems like it can't be done for the glut primitives. > I have ported an application to work with OpenGL ES 1.x, OpenGL 1.x, OpenGL > 2.x (with shaders) and OpenGL ES 2.x. Each compilations use some version of > freeglut. Okay, that application don't use freeglut fonts, menus or > geometries, but some other may need them. Yes, as I said the most important service provided by GLUT is in my opinion the window-system abstraction, which is apparently the only thing you're using. -- John Tsiombikas http://nuclear.mutantstargoat.com/ |
From: Matti L. <m-Matti-a.Lehtonen@IKI.Fi> - 2011-06-27 22:00:45
|
Hi, On 27 June 2011 09:12, John Tsiombikas <nu...@me...> wrote: > What we're discussing here is about finding a way to implement the same > functionality, on top of OpenGL ES 2, or pure OpenGL 4 context-using > programs. And what I was just saying is that it seems like it can't be > done for the glut primitives. > How about implementation like this one? Which part(s) are offending GLUT specification API 3, if this is looked as a black box? #if defined(OPENGL_ES2) # if !defined( GLdouble ) # if defined( double ) # define GLdouble double # else # define GLdouble GLfloat # endif # endif #endif ... void FGAPIENTRY glutSolidCube( GLdouble dSize ) { FREEGLUT_EXIT_IF_NOT_INITIALISED ( "glutSolidCube" ); #if ... #elif defined(OPENGL_ES2) glutSolidCube_ext( dSize ); #endif } // Or would glutSolidCubef() be better .... void FGAPIENTRY glutSolidCube_ext( GLfloat fSize ) { float size = fSize * 0.5f; FREEGLUT_EXIT_IF_NOT_INITIALISED ( "glutSolidCube_ext" ); { const float vertices3[ 6*2*3 ] = {...}; const float normals3[ 6*2*3 ] = {...}; GlInt cp, val; glGetIntegerv( GL_CURRENT_PROGRAM, &cp ); val = glGetAttribLocation( cp, glutGetVertexAttributeName( GLUT_ATTRIBUTE_NAME_FOR_VERTEX ) ); glEnableVertexAttribArray( val ); glVertexAttribPointer( val, 3, GL_FLOAT, GL_TRUE, 0, verticies3 ); val = glGetAttribLocation( cp, glutGetVertexAttributeName( GLUT_ATTRIBUTE_NAME_FOR_NORMAL ) ); if( val != -1 ) { // Shader program needs normals as input glEnableVertexAttribArray( val ); glVertexAttribPointer( val, 3, GL_FLOAT, GL_TRUE, 0, normals3 ); } glDrawArrays( GL_TRIANGLES, 0, 6*2*3 ); } } > Yes, as I said the most important service provided by GLUT is in my > opinion the window-system abstraction, which is apparently the only > thing you're using. > Actually, the application is using also other non-rendering related services of freeglut. Lehtonen, Matti -- Life is complex. It has real and imaginary parts. |