From: Paul M. <pm...@sk...> - 2009-05-05 15:49:43
|
Hi all -- Back when the OpenGL 3 discussion broke out on this list last fall, there was some talk about how functions like glutSolidTeapot would have to be written for OpenGL 3. The issue is really larger than just the fact that the underlying evaluators API has gone away in GL 3.1. Let me explain. Currently, glutSolidTeapot() is really a black box, an object, and you don't know or care how it draws the teapot. In OpenGL 2.x, you can set state just about any way you want, then call that function and render the teapot with that state. Consider how this changes in OpenGL 3. What you _might_, naively, want to do is create a shader to control the appearance, call glUseProgram, then call some function to draw a teapot. But this won't work! Unfortunately, any encapsulated, black-box function for drawing a teapot (or any other object) sends the vertex, normal, and other data as generic vertex attributes. The vertex attribute names are hidden in the black box, and the app shader can't use them. Seems like there's a few ways to handle this. 1) Punt: glutSolidTeapot remains a black box, and always uses its own shader. 2) Freeglut uses some kind of naming convention, and all shaders used in freeglut apps can access teapot (and other object) vertex attribute data by using hardcoded known names in the shader (like "fgVertex", "fgNormal", etc). 3) A more portable and object-oriented approach is some type of "data object" interface for each object with accessor functions that allow the app to get to the data: glutGetTeapotVerts, glutGetTeapotNormals, etc. This leaves buffer object creation and rendering up to the app. Thoughts? Have others thought this far down the road yet? Paul Martz Skew Matrix Software LLC http://www.skew-matrix.com <http://www.skew-matrix.com/> +1 303 859 9466 |
From: Steve B. <st...@sj...> - 2009-05-06 00:35:26
|
Paul Martz wrote: > Hi all -- Back when the OpenGL 3 discussion broke out on this list last > fall, there was some talk about how functions like glutSolidTeapot would > have to be written for OpenGL 3. The issue is really larger than just > the fact that the underlying evaluators API has gone away in GL 3.1. Yeah - it's tough. I think we have to think back to WHY those functions were added in the first place. It's so that you can write a really short demo program to demonstrate a feature - or send a minimal program to show a bug - without having to mess around with loading models. Being able to provide your own shader seems like a requirement here since a large fraction of demo/bug-description programs will be talking about the shader and just wanting a handy teapotahedron to display it on. However, there are other classes of program where NOT having to provide a shader (because they are demoing some other aspect of OpenGL) would be a huge advantage also. That says to me that these should be really minimal functions - with lots of defaults to make it easy to mimic the older behavior. I don't have a problem with reserving names for the vertex attributes. -- Steve. |
From: Paul M. <pm...@sk...> - 2009-05-06 00:53:09
|
If you don't want to drastically change the GLUT API, using a well-documented vertex attribute naming scheme is probably the best solution. (As a footnote to this discussion, I recently wrote some code to back-transform the GL_FEEDBACK output of the teapot and store it in an OSG scene graph. From there, I can export to OpenFlight or .OBJ formats. Both .OBJ and the native .OSG formats are ASCII text so we could essentially cut and paste the data into a header file to create a non-evaluators version of the teapot. If anyone wants this data, I'd be glad to make it available.) Paul Martz Skew Matrix Software LLC http://www.skew-matrix.com +1 303 859 9466 -----Original Message----- From: Steve Baker [mailto:st...@sj...] Sent: Tuesday, May 05, 2009 7:03 PM To: FreeGLUT developers list Subject: Re: [Freeglut-developer] Future of glutSolidTeapot and friends Paul Martz wrote: > Hi all -- Back when the OpenGL 3 discussion broke out on this list > last fall, there was some talk about how functions like > glutSolidTeapot would have to be written for OpenGL 3. The issue is > really larger than just the fact that the underlying evaluators API has gone away in GL 3.1. Yeah - it's tough. I think we have to think back to WHY those functions were added in the first place. It's so that you can write a really short demo program to demonstrate a feature - or send a minimal program to show a bug - without having to mess around with loading models. Being able to provide your own shader seems like a requirement here since a large fraction of demo/bug-description programs will be talking about the shader and just wanting a handy teapotahedron to display it on. However, there are other classes of program where NOT having to provide a shader (because they are demoing some other aspect of OpenGL) would be a huge advantage also. That says to me that these should be really minimal functions - with lots of defaults to make it easy to mimic the older behavior. I don't have a problem with reserving names for the vertex attributes. -- Steve. ---------------------------------------------------------------------------- -- The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your production scanning environment may not be a perfect world - but thanks to Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700 Series Scanner you'll get full speed at 300 dpi even with all image processing features enabled. http://p.sf.net/sfu/kodak-com _______________________________________________ Freeglut-developer mailing list Fre...@li... https://lists.sourceforge.net/lists/listinfo/freeglut-developer |