roll my own scene graph or find a library?

[samwan]

Hi all, I am looking for a way to manipulate graphical objects in a simple hierarchy with efficient rendering. Do Love developers typically roll their own scene graph libraries, or is there one out there with the basics?

- add/remove/reindex children nodes
- translate/transform a scene node
- draw anti-aliased geometries and bitmaps into a scene node
- hit detection on the hierarchy of nodes

I understand that Love has primitives for redrawing the whole screen, but a scene graph with make the management and rendering of graphical objects more efficient. Any suggestions?

Thanks,
Sam

[miko]

Hi all, I am looking for a way to manipulate graphical objects in a simple hierarchy with efficient rendering. Do Love developers typically roll their own scene graph libraries, or is there one out there with the basics?

I guess everyone makes his own library, because there are different models of scene graphs, so everyone uses something optimized for his game.

I am (slowly) working on such library, inspired by clutter.

- add/remove/reindex children nodes
- translate/transform a scene node
- draw anti-aliased geometries and bitmaps into a scene node
- hit detection on the hierarchy of nodes

Of the above points, the hit detection is the most difficult part (unless you don't use scaling nor rotating). Clutter uses helper functions using optimized matrix functions. I wish love2d had similar low-level matrix API. Until then, you need to implement such helper functions in plain lua.

[slime]

For any game that uses box2d with LÖVE 0.8.0 you can use the world:queryBoundingBox method to cull offscreen objects. Most of the time you probably won't need to do any sort of optimization like that though - 2d games are generally fillrate-bound.

[samwan]

Thanks for your responses, Miko and Slime. Can I ask three follow up questions?

1. Slime, what do you mean by "fill rate bound"? I realize it's a low-level graphics concept, but I have never worked below a certain level of abstraction before with computer graphics, which is why I'm interested in learning these things via Love.

2. Miko, thanks for the pointer to Clutter (really interesting, but big!). In your comment about hit detection, do you mean having to run a mouse coordinate through the stack of matrix transforms walking down the tree of elements? This gets into the whole set of problems around optimizing hit detection with partitioning strategies, caching transforms, etc., right?

3. Miko, with the library you're working on, are you taking the strategy of drawing to a cached framebuffer for each node (element, entity, component, whatever you call them), so that you only have to render the node once per local state change rather than drawing the whole screen every tick?

Thanks for any tips you can provide!

[miko]

2. Miko, thanks for the pointer to Clutter (really interesting, but big!). In your comment about hit detection, do you mean having to run a mouse coordinate through the stack of matrix transforms walking down the tree of elements? This gets into the whole set of problems around optimizing hit detection with partitioning strategies, caching transforms, etc., right?

Unfortunately, yes. You can go either with vector math (like transform/rotate/scale for each child in a tree), or use some matrix operations. The latter could have more sense when using hardware optimization (ac clutter/cogl does), in plain lua the former would be easier.

3. Miko, with the library you're working on, are you taking the strategy of drawing to a cached framebuffer for each node (element, entity, component, whatever you call them), so that you only have to render the node once per local state change rather than drawing the whole screen every tick?

My idea is to have one library for different backends, some of which use translate/rotate/scale (like Love), while others do not (libGD). For now, I have just tested only non-caching cases, but the caching could be relatively easy added. You just need the tree elements to be able to signal "redraw-needed", and add a step of redrawing all "dirty" elements (which would be different than "relayout-needed", but the idea is similar: notify which nodes needs redrawing, and redraw them later).

Anyways, I am just playing with the idea, not sure how far it will go. And my initial plan was to be able to draw some graphs (in multiple backends), so I did not need collision detection at start.

[samwan]

Cool, thanks a lot for your answers, Miko!