> 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.
There are other purposes as well, such as allowing multiple states (e.g. for different animation on multiple instances of a single linked character). But yes, I was under the impression that a proper fine-granularity depgraph was part of the intent as well. Then again, we never got Ipo bags from the animation system re-write, which I thought was one of the main intents of that. I'm coming to accept that we only get 50% of what we want with these re-writes, because we always seem to run against limitations in other parts of Blender's architecture. However, I agree with you. If we want to really be future-proof (inasmuch as anything is), we should do this as a fine granularity depgraph. It's just a matter of whether that is feasible or not... Ton, can you elaborate on the technical hurdles involved in doing a depgraph with a finer granularity than ID blocks? Or perhaps point someone else to this thread who can elaborate? --Nathan On Fri, Dec 23, 2011 at 3:57 PM, Matt Ebb <m...@mke3.net> wrote: > On Fri, Dec 23, 2011 at 7:49 PM, Nathan Vegdahl <ces...@cessen.com> 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 > Bf-committers@blender.org > http://lists.blender.org/mailman/listinfo/bf-committers _______________________________________________ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
