[Bf-committers] Render Branch Plans

[Christopher Cherrett]

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


-- 
Christopher Cherrett
ccherrett at openoctave.org
http://www.openoctave.org