Ideas for physics with lubyk

What happens to the messaging connection model when we need to deal with tools like physical or rendering engines which need a more declarative approach ?

Ideally, I would like to be able to create a patch that looks like this:

But this does not work with the current (late 2012) way slots work. Currently, links correspond to function calls without returned values.

In the case of a declarative setup where we want the links to model any type of relation between objects, we need to find some trick to make this work.

One simple and stupid solution is to have the “World” periodically call the objects below with itself as parameter. Each object would then register itself inside the world during the call. But there are obvious issues with this system:

1. We have to deal with multiple registrations of the same objects
2. Registration can be costly and should not be done unnecessarily.
3. Removing a node would not remove the node from the World.

callbacks

What we basically need, is only a way for “World” to know if anything is added or removed, since after an object was added to the world, changing some aspect of the object does not matter because the addition created a direct, native connection (C++ or Lua) between the object (“Ball” for example) and the world.

The simplest solution I can think of would be for the ancestors to be notified when a child or grandchild is added or removed. We could imagine that the child has an “expose” function that would get called by ancestors.

The way it could work is as follows:

1. The user onnects "Ball1" to "Joint" 
2. If "Ball1" does not have an "expose" table, stop here.
3. If "Joint" has a "connect" function, it is called with the "expose" table
   which should have a mandatory 'type' field. It is then up to the different needs
   of connected objects to decide what they want to do with this function call.
4. If the "connect" function does not return true, bubble up to the parent.
5. When a link is removed, the same happens with a "disconnect" function
   call.

For the “physics” engine above, the “childConnected” function call could look like this for the Joint object:

function connect(child)
  if child.type == 'physics.Object' then
    -- world was set the same way by the "World" object
    child:setWorld(world)
    -- connect the object to joint
    joint:AddObject(child.object)
    return true -- no need to bubble up
  end
end

The “disconnect” function would look like:

function disconnect(child)
  if child.type == 'physics.Object' then
    -- world was set the same way by the "World" object
    child:removeWorld(world)
    -- disconnect the object to joint
    joint:removeObject(child.object)
    return true -- no need to bubble up
  end
end

The same system could be used for all kinds of “connected” elements, like OpenGL Shaders on a rendering pipeline, etc.