I say go for it :) Daniel Salazar - 3Developer.com wrote: > As long as the bug tracker is taken seriously now about this render > improvement (it wasn't during Durian) I don't have a problem with bugs > > cheers > > Daniel Salazar > www.3developer.com > > > > On Wed, Aug 11, 2010 at 12:52 AM, Tom M<letter...@gmail.com> wrote: > >> Personally I'm fairly agnostic on merging it. Presumably it is 'more >> buggy' than head. The strongest arguements I can see for it are >> >> 1) Durian was rendered with it - it seems a bit contradictory to use >> Durian film shots as our screenshots if they were rendered with a >> different renderer than what is in head. >> >> 2) Changes of this nature might be preferred sooner rather than later. >> >> 3) It can actually render really high poly sculpts with less >> likelyhood of dying due to running out of ram. >> >> Biggest argument against it are that it quite likely has broken >> features that weren't used during Durian. >> >> As Campbell said it is mostly you and ton that should be making this >> decision. >> >> LetterRip >> >> On Tue, Aug 10, 2010 at 10:40 PM, Campbell Barton<ideasma...@gmail.com> >> wrote: >> >>> Hi Brecht, think you know my opinion on the topic but since you didn't >>> get a reply yet may as well post. >>> *Disclaimer that I dont know render internals* >>> >>> My impression is that the render branch is reasonably stable in terms >>> of crashing, but breaks compatibility in areas, some of these areas we >>> didn't use for Durian so perhaps there are cases which users complain >>> about immediately. >>> >>> Breaking compatibility I think we can cope with and merge soon - just >>> needs to be documented. Stability is not so simple if you merge in >>> bugs in not-well-tested code that can become really problematic later >>> on (especially if you aren't available so much for render bug fixes). >>> >>> I remember minor changes I made in trunk could somethings conflict >>> with the render branch and its nice to be able to look into a bug >>> report without having to check the render branch to see if it still >>> applies there, but these are fairly minor. >>> Bottom line is you and Ton should decide since you will be the ones >>> maintaining it. >>> >>> Assuming the problems are more about compatibility then stability: >>> +1 for a merge soon. >>> >>> On Fri, Aug 6, 2010 at 11:12 PM, Brecht Van Lommel<bre...@blender.org> >>> 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 >>>> Bf-committers@blender.org >>>> http://lists.blender.org/mailman/listinfo/bf-committers >>>> >>>> >>> >>> >>> -- >>> - Campbell >>> _______________________________________________ >>> Bf-committers mailing list >>> Bf-committers@blender.org >>> http://lists.blender.org/mailman/listinfo/bf-committers >>> >>> >> _______________________________________________ >> Bf-committers mailing list >> Bf-committers@blender.org >> http://lists.blender.org/mailman/listinfo/bf-committers >> >> > _______________________________________________ > Bf-committers mailing list > Bf-committers@blender.org > http://lists.blender.org/mailman/listinfo/bf-committers >
-- Christopher Cherrett ccherr...@openoctave.org http://www.openoctave.org _______________________________________________ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers