A very basic scene graph library

[kroll-j]

I started writing a small scene graph library. Its purpose is to create, animate and display some simple 3D shapes quickly, in an ad-hoc/livecoding fashion, without relying on external models. It is currently very basic. Handling of "primitives" (shapes) is similar to fluxus. What it can currently do:

• create some primitive shapes on the fly (currently spheres, created from a subdivided octahedron, and cubes)
• modify their attributes (color, name, translation, scaling, rotation)
• render the scene graph recursively (i.e., transformation matrix of nodes also applies to their children)
• animate nodes with a convenience macro (simplifies (callback) a bit)

It is intended to be used from Scheme context, while the lib itself is written in xtlang, using graphics-pipeline.xtm for rendering nodes. Nodes are referred to using integer IDs, which should make it safe from crashes (important in a livecoding context).

Things that need to be added or fixed:

• no texturing yet
• there are memory leaks
• ID lookup is done by traversing the graph. Obviously this will be slow for larger graphs. I would use a hash or something similar, but I don't know how to do that in xtlang. glib hashes might work, but I'd rather not pull in glib for this.
• needs more primitives, and a simple particle system would be cool
• GLFW stuff should be improved, probably should have some basic camera modification using mouse input (like fluxus)
• documentation :)

Simple example:

(sys:load "simplescenegraph.xtm")

(begin
  (scene_clear)
  (define sphere (build_sphere 2))  ; create a sphere with subdiv level 2
  (define cube (build_cube))        ; and a cube

  (with-node cube     ; convenience macro applies the following stuff to this node
    (translate 2 0 0)
    (scale .5 .5 .5)
    (color 0 1 0)     ; green
    (parent sphere))  ; parent's transformations will be applied to this cube

  (with-node sphere
    (scale 2 2 2)
    (color 1 0 0)     ; red
    (animate (/ 1 30)               ; 'do this every 1/30 seconds'
      (lambda (node time dtime)
        (rotate_node .15  0 1 0)))) ; rotate around y axis

  (with-node 0                  ; the root node
    (identity)
    (rotate_node 0.3  1 0 0))   ; rotate it a bit around the x axis

  (print_scene_graph))

Another example is in test1.xtm.

I started this because I needed to get some location markers in 3-space on the screen quickly and I didn't want to rely on external models. I would be happy if this, or something similar, would be included in Extempore at some point. I am not used to thinking in Scheme, and I'm new to Extempore, so I'd appreciate any comments, suggestions, etc.

[benswift]

Hi there

Thanks for the heads up, it looks cool and I'll have a look as soon as I
can. The extempore mailing list ([email protected]) is
probably a better place to advertise to the community, are you able to
post it there as well?

Cheers
Ben

j. kroll [email protected] writes:

I started writing a small scene graph library. Its purpose is to create, animate and display some basic 3D shapes quickly, in an ad-hoc/livecoding fashion, without relying on external models. It is currently very basic. Handling of "primitives" (shapes) is similar to fluxus. What it can currently do:

• create some basic shapes on the fly (currently spheres, created from a subdivided octahedron, and cubes)
• modify their attributes (color, name, translation, scaling, rotation)
• render the scene graph recursively (i.e., transformation matrix of nodes also applies to their children)
• animate nodes with a convenience macro (simplifies (callback) a bit)

It is intended to be used from Scheme context, while the lib itself is written in xtlang, using graphics-pipeline.xtm for rendering nodes. Nodes are referred to using integer IDs, which should make it safe from crashes (important in a livecoding context).

Things that need to be added or fixed:

• no texturing yet
• there are memory leaks
• ID lookup is done by traversing the graph. Obviously this will be slow for larger graphs. I would use a hash or something similar, but I don't know how to do that in xtlang. glib hashes might work, but I'd rather not pull in glib for this.
• needs more primitives, and a simple particle system would be cool
• GLFW stuff should be improved, probably should have some basic camera modification using mouse input (like fluxus)
• documentation :)

Simple example:

(sys:load "simplescenegraph.xtm")

(begin
  (scene_clear)
  (define sphere (build_sphere 2))  ; create a sphere with subdiv level 2
  (define cube (build_cube))        ; and a cube

  (with-node cube     ; convenience macro applies the following stuff to this node
    (translate 2 0 0)
    (scale .5 .5 .5)
    (color 0 1 0)     ; green
    (parent sphere))  ; parent's transformations will be applied to this cube

  (with-node sphere
    (scale 2 2 2)
    (color 1 0 0)     ; red
    (animate (/ 1 30)               ; 'do this every 1/30 seconds'
      (lambda (node time dtime)
        (rotate_node .15  0 1 0)))) ; rotate around y axis

  (with-node 0                  ; the root node
    (identity)
    (rotate_node 0.3  1 0 0))   ; rotate it a bit around the x axis

  (print_scene_graph))

Another example is in test1.xtm.

I started this because I needed to get some location markers in 3-space on the screen quickly and I didn't want to rely on external models. I would be happy if this, or something similar, would be included in Extempore at some point. I am not used to thinking in Scheme, and I'm new to Extempore, so I'd be happy for any comments, suggestions, etc.

---

You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
#279

[kroll-j]

Thought it wasn't even possible, but I just found out how to post to a google group from a non-google mail account. I posted it there.

[benswift]

Luckily it is possible, I'm in the same boat :)

j. kroll [email protected] writes:

Thought it wasn't even possible, but I just found out how to post to a google group from a non-google mail account. I posted it there.

---

You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
#279 (comment)