PDA

View Full Version : Opinions Wanted on Scheme Based OpenGL Scene Graph



Nakoruru
09-13-2002, 07:34 AM
I was thinking about making a Scheme based graphics programming language. The API would be similar to RenderMan and AL (Animation Language), but designed around OpenGL and hardware acceleration.

Scheme is a dialect of lisp which is statically scoped (like C) and properly tail recursive (which means the intrepreter/compiler can properly optimize some recursive structures into loops if possible). In otherwords, a compiler could produce code almost as efficient as C.

I chose Scheme because its incredibly simple but at the same time fairly powerful. It makes an easy to learn extension language.

Everything that needs to be fast would be implemented in C, and take advantage of extensions like VAR and VAO. I would make an immediate mode interface for sending geometry one vertex at a time, but for performance the language would definitely favor batching of geometry and state.

I think that a Scheme description would be much better and powerful than implementing a custom shading language as ATI recommends in their recent presentation (e.g., Quake 3's shading language).

I'm going to be designing this thing from front to back before coding, so I wanted some people's initial impression. Would you prefer a non-executable description language like Quake 3 or nVIDIA's FX files or a simple extendable and compilable scripting language like Scheme?

And please, no snide remarks about Scheme having too many parenteses ^_^

Also, I've already looked at a few implementations of scheme and have decided to implement my own intrepreter/compiler eventually. Firstly because none of them have garbage collectors that would work well in a nearly real-time environment like OpenGL programming, secondly I believe I could optimize a custom scheme intrepreter/compiler for OpenGL, and secondly because I have the skill set required to write a compiler, but I never have, so I want to (it's my second passion after graphics).

Trurl
09-13-2002, 10:46 AM
First think long and hard about whether Scheme is well suited for such a task.

A scene graph is a structure for representing application and OpenGL state. This conflicts with Scheme's dominant philosophy: functional programming, a fundamentally stateless style of program design.

With this in mind, perhaps Scheme would be suited for describing how a scene is created, but not how a scene IS. Am I making sense?

In any case, if you want to try a little GL programming in Scheme, perhaps just to do some prototyping before you get going on your own interpreter/compiler, here is a complete OpenGL 1.3 binding to MzScheme
I did some time ago: http://aoeu.snth.net/#GLSCM

mcraighead
09-13-2002, 11:06 AM
Ugh, scary reminders of being forced to work in Scheme at MIT...

It seems like OpenGL doesn't mix well with Scheme/Lisp, either. OpenGL is a state machine, and the framebuffer is also a big piece of state.

- Matt

Nakoruru
09-13-2002, 11:35 AM
I am going to think long and hard about it, that is why I am asking for opinions before I start to go full steam on design. I have not settle on Scheme, but it is starting to rise to the top.

I guess I need to clear up that I understand that OpenGL is a statemachine and that Scheme is a functional language. But, opengl is very low level, and what I want to do with Scheme is much higher level.

I was thinking of prototyping using one of the open source implementations of scheme. I was just forcasting that I think I will find them to not be acceptable because they implement all of scheme (which i do not need) and make different tradeoffs than I would make.

Actually, you can use a functional language to describe how things ARE. It is amazing how a description of how something IS can be turned into how things are DONE when the language represents data and code interchangably.

My basic example of this is a BSP tree. If you were to describe a BSP tree using lisp syntax, you could easily transform that description into a program. That program could draw the BSP, save it to disk, or transform it in some way.

I do not want to use the langauge as a low-level interface to make OpenGL calls directly, but as a high level tool to implement algorithms in. All the low level stuff can be done by an API implemented in C.

A very simple use would be to use it like Quake 3 shaders to setup streams, assign fragment and vertex shaders, set the texture objects, etc.

But, being a full featured programming language, you could do much more. Instead of just specifying what, you can also say how. And, if you use a functional programming language then what/how can look so similar that you can interchange them.


[This message has been edited by Nakoruru (edited 09-13-2002).]

[This message has been edited by Nakoruru (edited 09-13-2002).]