If you are just interested in experimenting, I d suggest picking a 3D framework with bindings for a dynamic language you are already familiar with.

I started doing experiments with Ruby/OpenGL a year or three ago and that was easy enough to play around with.

If you seriously want to build a project (for whatever reason), I d suggest picking a framework based on a combination of

• The native language it s implemented in (or runtime it runs on)
• The dynamic language bindings available for the engine or runtime
• The license of the framework

If you want your project to be fairly easily running across different OS es, you ll probably want to pick a framework written in Java (because the JVM runs everywhere) with bindings in Ruby (jRuby) or JavaScript (because these languages are well supported there). This would, however, limit the frameworks available to you. (This is my OSS + linux bias showing).

Wikipedia has a list of game engines. Based on several criteria I started a project with jMonkeyEngine (v2) and found it easy to work with and control from Rhino (a JVM JavaScript implementation).

I recently saw a presentation from another Java-based framework with bindings for several languages that looked really cool (inspired by the Ogre engine), but I forget the name and can t find it in the list.

Doing C# at the time I did look at projects/frameworks targeting both dotNet and Mono for running across platforms but it was too much hassle to get the development builds of the (Tao?) framework and the Mono Lua bindings running. Maybe things have changed.

To sum it up, pick a framework that can run on the environment(s) you want with bindings for the dynamic language that you want to use. Even if the framework library code available for the dynamic language you want to use is fairly minimal you can easily extend it if you can work with the underlying language. If you re fluent with C++, Java and C# shouldn t be too much of a stretch.

Given you are familiar with C++, you might give Lua a try. Lua is a dynamic language that can be embedded in any C/C++ program. It is very popular in the game industry.

I would like to mention Python with PyOpenGL as an option to consider.

If you are already familiar with OpenGL, PyOpenGL is basically a API wrapper written in Python. I was surprised at first how similar the code looks in Python and in C++. Like this (note I m also using Pyglet):

def setup_render(self):
       First rendering setup   
    glClearColor(0.0, 0.0, 0.0, 1.0) 
    glClearDepth(1.0)       

    glEnable(GL_LIGHTING)       
    glEnable(GL_DEPTH_TEST)    
    glEnable(GL_ALPHA_TEST)         
    glEnable(GL_CULL_FACE)              

def draw(self, time_passed):
       Drawing events   
    if self.has_exit:
        pyglet.app.exit()
        return

    glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT)
    glUseProgram(self.shader.program)
    self.set_lights()

    # Draw objects here
    glTranslate(0, 0, -10)
    glScale(5.0, 5.0, 5.0)
    glutSolidSphere(1, 16, 16)

See how similar it is to C++ code.

I was able to quickly pick up PyOpenGL in Python, and implemented a Quaternion class under 200 lines. If you re comfortable with Python, I wouldn t hesitate to recommend you to check it out.

By the way, PyOpenGL s API documentation is far more readable than the official one, too.

If you are looking for dynamic languages that support OpenGL out-of-the-box (no external bindings) try these:

• PLT Scheme
• Spark-Scheme
• Factor

My personal suggestion if you are after maturity and support would be Processing - very flexible, open source, well documented and a great community. Syntax is C-like so you should have no difficulty picking it up.

One slightly more cutting edge solution that looks very promising (but I haven t got round to testing yet!) is Penumbra - a Clojure library for OpenGL development in a dynamic functional programming style. Here s a elegant little snippet:

(enable :light0)
(push-matrix
  (translate 0 0 -10)
  (draw-quads
    (vertex 0 0 0)
    (vertex 0 1 0)
    (vertex 1 1 0)
    (vertex 1 0 0)))

Note that thanks to lots of Clojure macro cleverness, it automatically and transparently handles things like popping the transformation matrices at the right time. Other things that look good are things like GPGPU support.