{"id":715,"date":"2012-02-27T20:00:00","date_gmt":"2012-02-27T19:00:00","guid":{"rendered":"http:\/\/shadowcovenant.com\/blog\/2012\/02\/27\/effect-system\/"},"modified":"2012-02-27T20:00:00","modified_gmt":"2012-02-27T19:00:00","slug":"effect-system","status":"publish","type":"post","link":"http:\/\/shadowcovenant.com\/blog\/2012\/02\/27\/effect-system\/","title":{"rendered":"Effect System"},"content":{"rendered":"

Been working on a new Effect System for Spellbook and Grey lately (not much time for it, though)\u2026<\/p>\n

For discussion purposes, an Effect System is a subsystem that will allow me to quickly build and modify effects. Effects in this context are any sequence of visual\/audio items that need to do be done in a sequence to augment the animations of the characters\u2026<\/p>\n

For example, when Grey does a life-shaping spell, he needs to play his animation (with any sound effects needed), turn on two point lights that follow his hands, draw a beam of light from the ground to the sky, etc\u2026 When the effect ends, we need to activate whatever he life-shaped into existence (which can have any number of effects as well).<\/p>\n

I\u2019ve defined some goals for this effect system:<\/p>\n

    \n
  1. \n
    Independent \u2013 The system should be independent of most existing Spellbook systems, specially minimizing dependencies with the animation system (because of a point below).<\/div>\n<\/li>\n
  2. \n
    Multithreaded \u2013 This system should be able to run in a separate thread, synchronizing only for the rendering parts. I want this so that I can do more complex effects, like physics-based cloth animation, etc, without nuking the frame rate.<\/div>\n<\/li>\n
  3. \n
    Data-driven \u2013 I should be able to design a whole effect without doing any actual coding. For phase 1, the idea is to have a XML-driven effect, which describes the effect and the changes in properties of the entities that make up the effect, but in the future I want to build a component in SurgeEd that allows me to design the effects in a more user-friendly environment (a Flash-like timeline)<\/div>\n<\/li>\n
  4. \n
    Jump-to-frame \u2013 Because I want one day to have a decent application to author effects, I need the effects to be capable of jumping to a specific frame (so I can implement the timeline). In most casts, it\u2019s simple enough to do this (because the state is implicit in a formula), but cases with more random components (like particle systems), this might be more complicated.<\/div>\n<\/li>\n
  5. \n
    Event-tracking \u2013 The effect must be capable of raising events (for example, if the spawn of the creature needs to start at a specific time in the effect)<\/div>\n<\/li>\n
  6. Time-scaling \u2013 The effects must be capable of going faster or slower, depending on the instancing of the effect: for example, if the cast time of a fireball is normally 3 seconds and I want it to be done in 2 seconds, the effect must be speeded up.<\/li>\n
  7. \n
    Hierarchy \u2013 The effects must have components that can aggregate other components (and respect the scaling\/orientation\/position of its parent)<\/div>\n<\/li>\n
  8. \n
    Object reference \u2013 All effects must have a source object (that will be the target of animation controls, for example)<\/div>\n<\/li>\n
  9. \n
    Reuse of meshes \u2013 The system must be capable of reusing meshes; for example, if I have the same effect running 10 times, I must be able to use the same mesh for all of them, so I can cut the DIP calls from 10 to 1.<\/div>\n<\/li>\n<\/ol>\n

     <\/p>\n

    Of course, some of these will clash with others; for example 9 makes it harder to implement 7, since I have to do all hierarchy calculations in the CPU, instead of going for the GPU.<\/p>\n

    Anyway, what I have for now is an Effect System, that manages Effect Instances, which contains Effect Objects. The instance is build from an Effect Declaration, which describes properties and interpolators. The Effect Instance animates the properties using the interpolators (in this context, interpolators are everything from a linear interpolator in which a value goes from A to B in C time, to random interpolators which just assign a random value A to the property). The Effect Objects then use these properties to update a renderable mesh that it requests the Effect System\u2026<\/p>\n

    All in all, the system is becoming interesting, with a good decoupling of animation and render tasks (because of 2), and the fact that I treat everything as a function of properties and interpolators helps along with 3.<\/p>\n

    Hopefully I\u2019ll have some more on this by the end of the week, on the Spellcaster Studios<\/a> blog. Any questions\/suggestions, don\u2019t hesitate! \"Smile\"<\/p>\n

    Tweet<\/a><\/div>","protected":false},"excerpt":{"rendered":"

    Been working on a new Effect System for Spellbook and Grey lately (not much time for it, though)\u2026 For discussion purposes, an Effect System is a subsystem that will allow me to quickly build and modify effects. Effects in this context are any sequence of visual\/audio items that need to do be done in a […]<\/p>\n