Art of Illusion

I was wondering whether this belonged in Dev or in Feature Req. After a bit of thought, I figured this doesn't really represent end-users with any feature, not without additional coding. It's more of an architecture thing. This came to me when I was considering the issue of making a scene where a character performs a backflip, and grabs an object in mid-air. Up to the grab, it's simply a matter of character animation, and trajectory design for the object. Once the object is grabbed, though, it has to be "in-sync" with the character's hand, something that is incredibly difficult to achieve with a manually designed trajectory. Now the sane way to do this, is to actually make two identical objects, one which is used prior to the grab, with a simple trajectory, and a second which is linked to the character's hand, via a pivot on the model (part of the skeleton?). At the moment of the grab, you make one invisible and the other visible. Here's the problem, though: To link the second object to the model, in AoI, actually requires it to be a part of the model. Setting aside the issue of hiding and revealing individual polygon sets in the model as an animation, when you start thinking in a slightly larger scale, you realize that in any large-scale high-action scene, almost all of the objects in the scene would actually have to be represented by a single model. It's not just about objects being grabbed in mid air, it's everything from a chair being pulled, to people sitting in a car. The problem is not specific, it is fundamental. The AoI scene graph, despite it's impressive tree-like structure, is mostly a set of unrelated, unlinked objects. There is literally no way for objects to pass so much as an integer between them. Even if I was to code my own "glue" object, to try to stick the airborne object into the character's hand, I would have no method to either get the hand's position from the character model, or control the position of the object. If I had the "glue" "be" one of the other objects, I would still not be able to work with the other, so the "glue" has to be both objects, which comes back to the original problem of one model, two objects. In a similar vein, the scene graph, while being designed as a tree, has very little in terms of tree-like dependencies. Only a few position related items appear to be inherited from object to object. When examining the boolean operation class, I've noticed that it actually keeps the original object and performs the operation on-demand. So, it seemed odd to me that the objects it operates on can't be animated or edited after the operation is used. Adding an ability for objects to have "true children" inside the scene - ones which the parent object is aware of, and are not, themselves, rendered, would add a whole lot of freedom in creating a variety of "filter objects", ranging from boolean operations, to arbitrary transformations. The idea is not simply to let objects have sub-objects, that alone is already done in the current boolean operation, and similar objects. The idea is to have, for an object, "parameter objects" that would: 1. Appear in the scene graph. 2. Be editable, like any object in the scene. 3. Will be "ObjectInfo"s, meaning they can have their own keyframes, independent of their parent object. 4. May be moved in and out of their "parameter slot" in the parent object. Meaning the "slot" may be filled with any object from the scene, and it's up to the parent object to handle empty slots or incompatible children (probably by returning an empty render-mesh). 5. Will not be rendered directly. 6. May be used by the parent object in any way during render. The parent will be aware of it's children at render-time, and can do anything from boolean operations, to duplicating an object into an array/grid. Parent objects may also be useful for inter-object communication, at least on the "controlling" half, though the "getting information" part would still need a separate solution. It could be used to implement the "glue" as a parent of the grabbed object, above, but would still need the receive pivot information through some other form of inter-object communication with the character model (unless you want the grabbed object to be a child of the character model, which is only *slightly* better than the one model solution). So, let's sum up this request: 1. A method for objects to "export" information in a way other objects could "import" it. 2. A method for an object to contain unrendered "ObjectInfo"s which would appear in and be editable through the scene graph, and which it would be aware of at render time.