> * Slow parenting > We've also used slow parenting for animation in the past, > and just baked it to keyframes before farm submission - was > very useful in those cases. If it's possible to reproduce the > same functionality easily using some other method (drivers?), > i don't mind getting rid of it though, especially if a pre-made > script can be provided ;)
Just bake the child's animation and offset the bake in time. This is also more flexible. You can have fast-parent too. ;-) --Nathan Vegdahl On Fri, Jul 9, 2010 at 8:22 AM, Matt Ebb <[email protected]> wrote: > Hi, > > Firstly I would quite strongly recommend against removing most shading > related things here, until we have a new shading system. There will already > be quite significant changes then, and I think it will be a better time to > clean out the old junk, when there's at least a better framework to build > functional replacements upon, or at least for users to construct replacements > themselves with improved nodes. > > Barring that, I agree with many of the non-controversial ones, some extra > notes/emphasis here: > > * Slow parenting > We've also used slow parenting for animation in the past, and just baked it > to keyframes before farm submission - was very useful in those cases. If it's > possible to reproduce the same functionality easily using some other method > (drivers?), i don't mind getting rid of it though, especially if a pre-made > script can be provided ;) > > * Stars > Yes please let's get rid of this, the code is pretty nasty too. There are > much better ways of achieving this. > > * Object Colour > This has been quite useful for me in the past, as a way of individually > manipulating aspects of materials instanced multiple times in linked > objects/groups (yep, using animatable bones and drivers! Jez might remember > :). Though I used this pretty much by making a separate shadeless material > with ob colour on, that was used as an input into a node tree. I'd be happy > to see the current 'multiply by colour' method go, if the same functionality > could be added as part of an 'object data' input into a shader node tree for > example - i.e. this can be done in new shader system, but let's not remove > until then. > > * 3D View lock to object > Why remove this? Been quite handy for some things in the past - ask Jez. > > * Blend Sky > This is currently the only decent way to get tonal variation in environment > lighting (with AAO). I'd love to see the entire world shading get torn up and > replaced with something sensible (fixing the bizarre real/paper options, > strange hemispherical mapping modes, etc), and then the same functionality > could be available just using blend textures, which could then get properly > sampled for environment lighting, stored in spherical harmonics etc.. But > again, a job for new shading system, please don't remove it until then. > > * Environment Map > Still very useful in some situations, we were still using it in production > work at promotion. Would not like to see this go. > > * Particle line rendering > Still very useful - again, I'd love to see the halo system torn up/turned > into something better (eg. properly motion blurred points? krakatoa?), but > until there's a replacement, please keep. > > * Particle instance modifier > Not sure if this has changed recently, but I used that a while ago as a way > of applying cloth sim to the results of an instanced particle sim for papers > flying in a tornado - don't think that's possible to do otherwise. If better > functionality for manipulating particle-instanced-objects becomes available, > sure - but i wouldn't get rid of it until then. > > * Curves in the image editor > Mentioned this in a tracker report, I think just replacing it with exposure > isn't really solving the problem - there needs to be a better distinction > between what is just a 'viewer' feature, so viewer exposure, viewer LUTs, etc > vs what's actually editing the image itself. The way it actually edits the > pixels of the 8bit representation of float images is quite nasty I think. > > > cheers > > Matt > > _______________________________________________ > Bf-committers mailing list > [email protected] > http://lists.blender.org/mailman/listinfo/bf-committers > _______________________________________________ Bf-committers mailing list [email protected] http://lists.blender.org/mailman/listinfo/bf-committers
