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