RE: RFC - GL in scheme (long, with code)

[Greg Pettyjohn <GregP@bsquare.com>]

> For the past few weeks I've been investigating the possibility of
> adding OpenGL bindings as an extension to MzScheme.  This is not a
> small task, and I'm aware of a few previous aborted attempts.

Hi Robert, My name is Greg Pettyjohn, I'm the author of the "aborted
attempts".
I'll add that the code I have isn't as "aborted" as you might think.
"Sidetracked" is a much better word.

Anyway, I've noticed that you have found the with-gl-context and
swap-gl-buffers
that I added to canvas% and that Matthew graciously rolled into v200 earlier
this year.


> Here's a bit of sample MrEd code using the extension...

Yup, I have some fractal terrain generators, with color and lighting.
I also have a rather-too-complicated binding for vertex arrays that I
was playing with. By all means I will share code if you are interested!

> 
> * A GL CANVAS CLASS
> 
> If one prefers that GL calls be methods of a gl-canvas%, such a canvas
> has a straightforward definition.  Note that each of its methods will
> have to thunkify the GL procedure, and pass it to with-gl-context by
> hand.
Hmm... For about a day and a half I thought this might be neat, but like
you,
I decided it would be a clumsy way to do it. That's why the canvas% has
only two OpenGL related methods. (I must have posted something about
that earlier on...)


> 
> * FUTURE IDEAS
> 
> GL makes heavy use of blocks of data for things such as vertex arrays
> and textures.  It will be necessary to create vector types for each of
> the GL types: gl-float-vec, gl-uint-vec, gl-ubyte-vec, etc.  These
> would support make-, -length, -ref, and -set! vector operations, and
> would hopefully be as unsurprising as possible.

I already have a binding for the vertex array stuff! In particular, I have
a low level binding that allows you to write a byte just about anywhere,
as well has some utilities for managing data alignment etc. Then I was
experimenting with a form that allows you to make a vertex-array% class.
It's very flexible, but pretty complicated too.

> Given that many modern GL applications are bus-bound, transform-bound,
> or fill-bound, the ability to define vertex arrays using such vectors
> would allow for scheme GL code that performs every bit as well as the
> equivalent C code.

That was my hope.
 
 
> I'm considering creating a few wrappers.  For instance, there are a
> wide variety of vertex commands for different argument types and
> counts: gl-vertex-3f, gl-vertex-4f, gl-vertex-2i, etc.  It might be
> convenient to have a gl-vertex function that counts the arguments and
> chooses which gl-vertex-* to call, possibly converting all arguments
> up to a consistent type.  While this would hurt performance in
> immediate mode, any overhead would magically disappear when using
> display lists.

I have lots and lots of gl-vertex bindings. Maybe even one like what you
describe.
 
> * QUESTIONS
> 
> How can the use of a GL extension be made more scheme-ish?  SHOULD the
> use of a GL extension be more scheme-ish?

Good question. The conclusion that I came to was, if you want something more
Scheme-ish then don't use OpengGL. But even then, it seems you have a
dilema:

What you are doing is describing geometry: points, lines, planes, solids
etc.
So suppose you want to draw this geometry. Then it is natural to think of
some sort of draw primitive:

(draw <geometry description>)

But this returns void. So it seems that drawing to the screen is analgous to
writing to a file. I.e. it is like an output operation. Now I've heard that
the Haskell guys have some sort of duvalaki called a moniker that provides
a more "functional" way of doing I/O, but that is all I know.

> The C functions all return scheme_void (with the exception of some
> unimplemented state queries).  Does this make sense?

The OpenGL state queries are especially annoying. It seems you are stuck
with
'em though, unless you wanna hurt performance.


> A very large majority of GL functions have side effects.  So, naming
> the procedures as gl-do-something! might be in order.  However, the
> state being changed is external to the environment.  A ! on every GL
> call begins to look cluttered anyway.  Thoughts on this?

I agree with Matthew, don't use "!".

> 
> Should the GL extension be packed into a unit somehow?

Yup.

> How's the naming?  Would a different choice of symbols be better?
> It would seem that gl-vertex-3f is more scheme-ish than glVertex3f.

I started out with glVertex3f and then moved to gl-vertex-3f. I even have
a tool that take a list of gl function prototypes (as an s-expression)
and then spits out a binding. While it's at it, it converts glVertex3f
to gl-vertex-3f.

> If you have ANYTHING AT ALL to say about this, or GL scheme in
> general, please let me know.  Reply to the list, or to my mail of need
> be.

If you are serious about this (and it seems you are!) then allow me
to share my code with you. Mostly, I've been lacking motivation.

What I have:
1. Bindings for all the "easy" stuff e.g. gl-vertex-whatever
2. Low level primitives for building vertex arrays.
3. Some high-level code that wraps the vertex array stuff and
makes it a little cleaner/safer.

What I don't have:
1. Texture support.
2. Bitmap support.
3. Display lists (these should be easy.)


Also, Matthew add a slick little "C foreign function interface"
which I think would greatly simplify a *lot* of the binding code.
i.e. "easy" stuff like gl-vertex-whatever would go well in
a CFF binding.

On the other hand, stuff like my vertex array support would work better
in a separate C/C++ source file.

Cheers.