| [gef3d-dev] GEF3D and AGF3D animation |
| (cross-posting because it potentially affects both projects) Hi guys, Kristian mentioned in bug 292593 "There is also the broader issue of animation that needs to be adressed. AFAIK you are using a thread to trigger updates in order to animate your visualisation - there needs to be a standard API for animation in GEF3D sooner or later. This needs to go on our to do list." This is exactly an area AGF3D is working on too so we should be able to leverage each other's work or combine it or whatever.. I need to capture all of this stuff in WIki as right now I'm probably the only person who knows what exactly the plan is WRT to that. This fits in with AXF too. FYI, AXF core has no dependencies at all, and AGF3D only on GEF and GEF3D of course. The basic mission of AGF3D is to provide a very high-level set of APIs for people to work with agents (really any kind of object) that moves through space over time. So that covers a lot of ground potentially. :) And part of AXF is to provide a common way for models (here I mean in the object instance sense) to have their state updated over time and then to have that state captured in some way; either through a visualization, persistence, proxy, whatever. Basically it works like the below. IModel can be anything.. IEngine manages IModel state changes..for example, in the Agent-Based Model case, an engine is a scheduler that every period goes through a list of rules and tells each agent to execute it... after each change in state at some granularity (in ABM case this would be once every period), and on life-cycle events like model creation, model initialization, model pause, model stop, model close, the IEngine sends.. Object (in above case a new LifeCycleState) to every.. ILifeCycleListener (extends StateListener) Now, this is important, receivers get to do what ever they want to with the message and until they report back, the engine can't change the model state. (There is some provision for timeout, etc..) This is all provided through adapters / providers, so that these can be wired up at runtime. A GEF3DVIewPart doesn't have to know anything about what it is actually viewing, except that it provides its model components through an ICompositionProvider which gives meta-data about what the view might like to do with that. For example, it could provide an isMutable method that would allow optimizations to edit parts in the case where we know objects aren't going to added or destroyed. Note by the way that because of this approach at least currently AGF3D overrides the default validation behavior. Because we know (from engine) what we've changed and how it might affect things in say the case where most of the object positions have changed it (probably) makes sense to just invalidate everything. Hmm...what was my point.. oh yeah.. The nice thing about this is that GEF3D doesn't have to know anything about what is happening to model state; it just needs to refresh at the appropriate time, but that is all managed through the ScapeEditParts (may change name to something like CompositeEditPart). There could be a very simple AXF Default Engine that simply iterates through all of the objects, asks them to update their state and then tells the viewers, including GEF3D, that it is time to update state. The nice thing about that is that you get animation control widgets, etc.. and that's all coordinated with any other kinds of view updates. Oh and also, I have step animation working again on the new API. That means that the ScapeEditPart can interpolate agent locations. So that if the model provider now thinks the object(s) location should be at x2,y2,z2 but it's GEF3D location is still x1,y1,z1 we can smoothly move from one location to another. :) So just some ideas.. Please don't worry about following up until everyone is back and the dissertation time is over. :) Miles |