[Bf-committers] Proposal to Remove Features

[Nathan Vegdahl]

> * 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 <matt at mke3.net> 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
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>