Future of glutSolidTeapot and friends

[Paul Martz]

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

[phone]

------------------------------------------------------------------------------
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
Freeglut-developer@...
https://lists.sourceforge.net/lists/listinfo/freeglut-developer

[Steve Baker-10]

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
Freeglut-developer@...
https://lists.sourceforge.net/lists/listinfo/freeglut-developer

[Paul Martz]

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
[phone]

-----Original Message-----
From: Steve Baker [mailto:steve@...]
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
Freeglut-developer@...
https://lists.sourceforge.net/lists/listinfo/freeglut-developer


------------------------------------------------------------------------------
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
Freeglut-developer@...
https://lists.sourceforge.net/lists/listinfo/freeglut-developer