[Bf-committers] Render Branch Plans

[Daniel Salazar - 3Developer.com]

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