Hi, I don't buy the argument of 'it was used in Durian screenshots so it should be in the main Blender'. Not all rendering is equivalent, especially when you're dealing with something that designed to meet the needs of a specific project. It's quite possible that the things that have been implemented for Durian might be great for Durian but cause lots of problems for other kinds of usage. I'm not saying this is the case here, but I'm trying to demonstrate that this is not a valid argument - this code/functionality needs to be considered on its own merits and faults.
So, some additional questions: * How likely is it that a decent shading system will be implemented soon? This isn't really something for brecht to answer, but a general issue. If it's likely to happen relatively soon, then it would be best to leave these render branch changes until then, to avoid breaking compatibility twice in a row. If not, and blender internal is still stuck with it's 90s era system indefinitely, then it's less of an issue. * How 'complete' is the render branch work? Will it need further development in order to be usable by blender users in general? It's been implemented for Durian to solve their particular production needs, but on at least my brief looks at it so far it's hard to see how it integrates with other features they may not have been using. It would also be interesting to know what things haven't been implemented since they weren't necessary for Durian, but are important for general purpose usage. This has been the case in the renderer work of previous open projects, so it wouldn't be anything new, but it does make things worse. * How much of it is based on telling the artists in the studio "oh, don't do that, it doesn't work properly, just do it this way for now"? I totally understand when using project-specific tools put together in production that there are often rough edges. For the purposes of that job, you just work around the flaws to get the job done - I've done it many times. However there can also be quite a difference between this and something that's suitable and reliable for general purpose use in a variety of scenarios. To what extent is this the case for the render branch work? * How stable/bug-free is it? I haven't seen much evidence of wider production testing outside of Durian, and bug reports with it were discouraged during Durian (totally understandably - there was enough to deal with!) But if problems are found, how likely is it that they can be fixed? Are there problems with it that are due to more general issues with blender's renderer (eg. lack of derivatives in raytracing?), but that get amplified or made more apparent when using the new features? Just some things to think about - it's important to consider the costs vs benefits and there are quite some potential costs to merging this right now, too. cheers Matt On 06/08/2010, at 23:12 , Brecht Van Lommel wrote: > Hi all, > > I've written some docs on the render branch changes, more coming: > http://wiki.blender.org/index.php/Dev:2.5/Source/RenderBranch > > I'll also release a patch for the new shading nodes, however they are > only in a prototype stage and far from finished. There's no clear plan > yet for when to merge the render branch changes (and I couldn't really > discuss it properly yet before the Octane announcement). There's a few > options: > > * Merge as soon as possible, so it ends up in 2.6. This means the > changes then would be available immediately, disadvantage is that we > make trunk more unstable, and have to break render compatibility > twice, assuming a new shading refactor happens in a following release. > * Merge after the 2.6 release. This means it will take a bit longer, > but not get in the way of current bugfixing work to get a release out. > Does most likely mean breaking render compatibility twice. > * Merge along with a shading nodes refactor. It's unknown when this > would be done, and I can't be involved with it much. Means everything > can be changed at once and tested better. > > I looked into merging only "safe" changes that would not break > compatibility much, but this seems to be very difficult, so I can't > see other options. My personal preference would be to merge things > after 2.6, maybe at that time others may be interested / have the time > to improve things further. > > 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
