[Soc-2013-dev] Weekly Report #8 Depsgraph Refactor

[Sergey Sharybin]

Jishua, apparently i couldn't remember by hand, only remember that was
needed to make constraints work properly and that relation was suggested by
Ton. I'll dig into tomato branch logs today and will answer your question :)

P.S. Was afk for a while, so failed to reply your earlier.


On Sat, Aug 10, 2013 at 7:34 PM, Ton Roosendaal <ton at blender.org> wrote:

> Hi Joshua,
>
> Looks all very cool to me already!
> The open issues - especially proxy and duplicators - we should spend some
> time on this and next week. Sergey will be back from USA tomorrow too.
>
> -Ton-
>
> --------------------------------------------------------
> Ton Roosendaal  -  ton at blender.org   -   www.blender.org
> Chairman Blender Foundation - Producer Blender Institute
> Entrepotdok 57A  -  1018AD Amsterdam  -  The Netherlands
>
>
>
> On 9 Aug, 2013, at 15:06, Joshua Leung wrote:
>
> > == This Week ==
> > I've been porting over the existing depsgraph building code over to
> > the new system.
> > * As of the time of writing, the majority of the existing stuff has
> > now been ported over and/or converted in some way (more on this in a
> > sec)
> > * Particles and collision are the main parts that still haven't been
> > defined yet
> > * Evaluation stuff for geometry data still needs to be fleshed
> out/completed.
> > * The custom dependency-definition callbacks for modifiers haven't
> > been touched yet either. Dealing with those though will have to wait
> > until I start integrating the core engine into Blender's source tree
> > soon...
> > * Where possible, when porting over the old code, I've modernised it
> > to take advantage of the new expressive powers of the new system. This
> > is most obvious in the animation/drivers/constraints/bones/parenting
> > parts, which I'm most familiar with and especially mindful of the
> > severe limitations that used to exist there in the past.
> > * Bones are now represented as subcomponents attached to the "Pose"
> > component. Note: This has very little impact on the final runtime
> > granularity of operations (as with all other components); this change
> > just makes it more convenient for managing/getting the nodes related
> > to bones. Although this generally works, there are just a few issues
> > currently when trying to identify operation nodes for bones (since
> > they both currently use the same "name" parameter in the API's for
> > doing this mapping). Some tweaks to those API's will be needed before
> > that can work
> >
> >
> > == Issues ==
> > 1) I'm not quite sure what to do with a few features in the old system
> > which only half-worked - namely, proxies and duplis. As a first pass,
> > I could just try and port them straight across in the same way that
> > they used to be done, though perhaps avoiding some of the absolute
> > worst problems...
> >
> > 2) ATTN Sergey - While trying to port the Camera tracker constraint
> > nodes, I was a bit baffled as to what exactly the "Scene Relation"
> > relationship at the very end was for. Knowing a bit more about what
> > that is about will help me figure out whether there's some other stuff
> > which is needed to support that
> >
> > 3) Functionality not supported by old depsgraph (i.e. stuff like
> > rigidbody sim links). While I'm aware of some of these things (and
> > will duly add them in the meantime), we are going to have cases where
> > there's stuff which couldn't be represented in the past but which can
> > now be represented (but we don't know about this, since the old graph
> > didn't have anywhere to note these). More likely than not, we're going
> > to have to need a fine-tuning phase once I get this thing hooked up to
> > the rest of Blender where others more knowledeable about certain areas
> > can go through and check that all hooks that are needed but couldn't
> > exist in the past are now in place...
> >
> > 4) What to do with the customdata and layer flags that used to get
> > passed around the place? When do these vary and/or need to vary from
> > what just gets set once at the start? Will need to investigate more
> > about this...
> >
> >
> > == Next Week ==
> > 1) Write up a little "How to Guide" for building graph structure/nodes
> > used in the Depsgraph, based on what I've been doing so far. This will
> > just cover things like general style-guide for how to go about
> > breaking things down into nodes (i.e. when a new component type is
> > needed, what operations should be, how to go about linking up those
> > components+operations, etc.)
> >
> > 2) Finish porting over graph building code for unfinished bits + make
> > a few API changes for problems encountered this week
> >
> > 3) Rigidbody support in the graph
> >
> > 4) Start figuring out how to get the depsgraph to feed nodes to
> > Sergey's task scheduler. I've started taking a look at how that stuff
> > worked, but will need to investigate a bit more.
> > _______________________________________________
> > Soc-2013-dev mailing list
> > Soc-2013-dev at blender.org
> > http://lists.blender.org/mailman/listinfo/soc-2013-dev
>
> _______________________________________________
> Soc-2013-dev mailing list
> Soc-2013-dev at blender.org
> http://lists.blender.org/mailman/listinfo/soc-2013-dev
>



-- 
With best regards, Sergey Sharybin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.blender.org/pipermail/soc-2013-dev/attachments/20130812/64a7cfb3/attachment.htm