Hello, As others, I agree with some of the changes, but from my production experience:
Fields support - many tv stations around the world still work with the old standard (just few months ago I did a pal commercial for czech tv). And, although using progressive frames usually doesn't hurt, it's definitely a missing feature that should work seamlessly in a professional application. Also, it's not only the 'old' standards, actually also various HD standards are still 'i', thus interlaced. Also for images, I noticed it's broken, just didn't have time to make proper report - it can actually change the framerate of videotexture(!) in the 3d scene, if you change the fields option(there's actually no way to tell blender how to interpret video framerate, it always works with framerate selected in render options as basis, somehow multiplied or divided by fields option). Edge rendering actually, you can easily simulate it with current nodes, and with help of zbuffer pass and normal pass actually achieve much better results. Object color can be used in games indeed, but is very very confusing, so it could be somehow replaced with material color. For game engine, some simpler material definition could be found, since main reason to use obcolor instead of glsl material with alpha is performance and compatibility. Animateable object layers: first to mention, this doesn't work in 2.5, and I miss that feature a lot. as allready mentioned, it actually saves performance when moving objects between layers instead of animating their hiding. Also, currently animating hiding of objects with the restrict prop is a pita, since animation editors don't show hidden objects, so moving the keys for these is nearly impossible. I did a special driver for animating hiding of objects, this was also quite slow. I think a great solution for this would be: 1. the ability to not only restrict visibility, but also depsgraph evaluation of objects(thus their modifiers, constraints e.t.c. wouldn't be considered at all), thus keeping the advantage of performance. 2. possibility to show also hidden object's keys in animation editors. -then I think this (weird) functionality could be dropped Blend sky - if this is replaced by the newer sunsky option, I am all for removal but otherwise, I also use it in cases for lightning the scene with ambient quickly. Irregular shadow buffer -I use it quite often. In cases when a sharp (toony) shadow is needed, it's the very best option, mainly because you can keep raytracing switched of. Is it somehow hindering the (future) evolution of the renderer? If yes, removal can be bearable. Shadow pass - I consider this pass quite important, although it can be replaced with shadow only material renderlayer. I'd love to add 1 thing to the list for removal: -possibility to drag-drop reshuffle panels in the UI. this wannabe fancy feature of the ui I consider to be one of the biggest evils in the new ui transfered from the old ui. If the panel order is fixed, you'll always find the correct panel soon. If it can be reshuffled, than you can end up looking for the panel quite a long time, especially if it's not a file you originally made. If this needs more clarification, I could write a longer 'why' page in the wiki. Otherwise, I really welcome the removal of confusing hacky features, especially when their behaviour can be reasonably reproduced under the hood of more general features. cheers Vilem > ------------ Původní zpráva ------------ > Od: Brecht Van Lommel <[email protected]> > Předmět: Re: [Bf-committers] Proposal to Remove Features > Datum: 08.7.2010 22:53:41 > ---------------------------------------- > Hi, > > I've made some modifications, and left out a few that may be best to > keep (particle features mostly). Also added more explanation to the > second list. > > On Thu, Jul 8, 2010 at 10:08 PM, Kent Mein <[email protected]> wrote: > >> Here's a proposal to remove a number of features before 2.6. I've been > >> gathering items on this list for the last few months as I came across > >> them. If there is enough agreement I can make the changes quickly. If > >> you agree or disagree with items on the list, please read the > >> explanation at the top and comment on the wiki page. > > I don't mind making edge rendering a node, it's pretty simple, and can > then be more easily improved. > > On Thu, Jul 8, 2010 at 10:33 PM, William Reynish <[email protected]> wrote: > > I'd add Slow Parent, Old Track and Curve Animation, which have been replaced > by constraints. Slow Parent is not farm safe and seems to cause issues. > > Old Track is already gone, Slow Parent is on the list, and also added > Curve Animation now. > > On Thu, Jul 8, 2010 at 10:14 PM, Shaul Kedem <[email protected]> wrote: > > regarding plug ins, is there some concrete way to make them more useful? > > They should work like operators or render engines now, appear just > like native textures or sequencer effects. Not a plugin texture type > where you have to load a .dll/.so file each time. > > On Thu, Jul 8, 2010 at 10:36 PM, Mitchell Stokes <[email protected]> wrote: > > Slow parenting is used in games frequently, so I wouldn't remove it. > > Forgot about this, perhaps we can keep it only visible the game engine > and remove the functionality from the animation system. > > On Thu, Jul 8, 2010 at 10:43 PM, Kent Mein <[email protected]> wrote: > > What do people think of removing Background from Scene? > > It can be done in sequencer pretty straight forward, and > > with more options, kind of odd to have the duplication? > > Agreed, already removed it in the render branch, added to the list. > > Brecht. > _______________________________________________ > 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
