On Fri, Dec 23, 2011 at 7:49 PM, Nathan Vegdahl <[email protected]> wrote:
> let's at least not pretend that "detect cycle + call x > times" is a real solution to granularity issues. Blender will still > have a granularity issues with it's dependencies, it will just be > pushed x levels down (at a performance cost of x). When the idea of a 'depgraph project' was first announced, I thought that this was exactly what was going to be tackled. IMO lack of granularity is the single greatest problem with blender's dependency system as it stands - much more important than things like lack of threading. It's not just a problem for character animation, but has far-reaching consequences for the rest of blender too (eg. bad physics behaviour, dodgy 'collision modifiers' etc). I realise it's probably a very difficult problem to solve internally, but I wonder if it's really worthwhile to be spending the resources on a redesign here if this issue isn't seriously addressed. For some of these other non-character animation problems where data needs to be depended on and accessed at different points in the evaluation chain, not just after final evaluation, I'm not sure they even can be solved by re-cycling several times (correct me if i'm wrong!), since what's needed for these tasks is access to and control over how data is transferred and evaluated through the system. These limitations also cause roadblocks for further tools from being developed such as node based modifiers, better physics systems like node based particles, node based animation/contraints. In modern cg and fx, animation is not just objects or bones moving around any more, it's complex procedural geometry creation and animation, scripted variable expressions and relationships, data flow connecting separate systems like physics solvers. I really think if this depgraph project is intended to set blender up for the future, it needs to do more to acknowledge and prepare for these sorts of functionality, even if it's not possible to implement them all right now. cheers Matt _______________________________________________ Bf-committers mailing list [email protected] http://lists.blender.org/mailman/listinfo/bf-committers
