[Bf-committers] Render Branch Plans

[Tom M]

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 <ideasman42 at 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 <brecht at 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 at blender.org
>> http://lists.blender.org/mailman/listinfo/bf-committers
>>
>
>
>
> --
> - Campbell
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>