CJ,
Without specific infrastructure enhancements, EIAS isn’t capable of performing some of the features we require as character animators. None of these features are impossible, they just require the foundations to be there to implement. Slowly but surely, these infrastructure enhancements have been making their way into EI as part of regular upgrades. For example, the plugin APIs have been expanded to permit non-modal windows and there is improved interconnectivity between plugins and the host package. Xpressionist was the first plugin to really take advantage of this with EI’s deformations. Now a XP script can drive a deformation in realtime. If plugin manufacturers take advantage of this, we should eventually start seeing plugins that can remain open, allow interaction with the host, and communicate between themselves. Imagine, for example, keeping Dante open and altering the parameters on the fly and seeing particles update in the host package rather than having to close the plugin interface. Theoretically, I believe this is now possible.
The meshing subsystem Animator requires is necessary for Animator to understand what it means to control something on the component level rather than just the object level. If we want tools to draw splines, create clusters, have lattices, and to reshape geometry on the vertex level, Animator has to be taught how to understand all of that. Right now, it doesn’t need to because it relies on an outside modeling package to manipulate geometry. That’s a real bummer for the CA animator cause a lot of our work requires vertex level manipulation.
When Tesla comes back into the picture, there has been some talk about bridging the two applications in a similar method that Lightwave talks to its Modeler through a hub. That’s one potential solution…but not a very graceful method. The other option is teach Animator how to do some of that stuff itself…and the last option is to bypass that all together and just pass the CA animation requirements off to a future Tesla incarnation because Telsa has the foundation already in place.
Other foundational infrastructure subsystems in addition to ‘Mesh’ mentioned by the developers include:
-
Better Data re-routing for improved channel control outside of using expressions. It could also set up cloning scenarios, master/slave capabilities, and so forth. Right now, the user has to script functions like that in XP and that doesn’t really solve everything.
-
Hidden plugin technology for dynamic attribute enhancements to an object. These “hidden plugins” essentially permit users to add dynamic attributes to an objects channel data. A sphere that is tapped by Dante as a surface emitter could then access its “emission” channel data without opening the plugin, plus other “hidden plugins” could talk directly to Dante if they needed to. This kind of stackable interaction between these data bridges (hidden plugins) allows a more open system of communication. A cruder example of this now is what’s found in Paralumino’s geometry plugins. These plugins are designed to stack and talk to each other in order to build new geometry. Trestle feeds Swage, or Braider breaks down an Ubersphere in order for it to become extrusion paths for Swage or Scrim.
I guess the point I’m trying to make CJ is by asking EITG to embrace CA to a degree that is competitive with other packages means EIAS has to make a major evolution. If it doesn’t…whatever is added is just another piecemeal patch to entry level CA tools that exist now. We need more.
One other worry is repeating work. There could be means to make minor enhancements to the existing CA system now, but do we want to waste that effort if something better is possible? Its a really tough call. Right now I believe there are several enhancements that can be made to EIAS that will benefit a Character Animator without repeating or wasting work. Hopefully they’ll be addressed.