Re: [Bf-committers] Render Branch Plans
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
Re: [Bf-committers] Render Branch Plans
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
Re: [Bf-committers] Render Branch Plans
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
Re: [Bf-committers] Render Branch Plans
The 2.5x series are development series, so we have to take advantage of that state. Here we are a small studio waiting for use blender for long term project with blender internal render engine and we think that people can stand with bugs, but what they can't stand is to get the compatibility broken in the middle of a production. I don't know about the magnitude of the compatibility break for the new node based shading system, but seems that it won't be as big as the actual render branch changes. The merge should happen as soon as possible, also that will push to all of us to solve problems sooner. Regards. Agustin. 2010/8/11 Christopher Cherrett ccherr...@openoctave.org 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 Mletter...@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 Bartonideasma...@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 Lommelbre...@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
Re: [Bf-committers] Render Branch Plans
Hi, I don't buy the argument of 'it was used in Durian screenshots so it should be in the main Blender'. Not all rendering is equivalent, especially when you're dealing with something that designed to meet the needs of a specific project. It's quite possible that the things that have been implemented for Durian might be great for Durian but cause lots of problems for other kinds of usage. I'm not saying this is the case here, but I'm trying to demonstrate that this is not a valid argument - this code/functionality needs to be considered on its own merits and faults. So, some additional questions: * How likely is it that a decent shading system will be implemented soon? This isn't really something for brecht to answer, but a general issue. If it's likely to happen relatively soon, then it would be best to leave these render branch changes until then, to avoid breaking compatibility twice in a row. If not, and blender internal is still stuck with it's 90s era system indefinitely, then it's less of an issue. * How 'complete' is the render branch work? Will it need further development in order to be usable by blender users in general? It's been implemented for Durian to solve their particular production needs, but on at least my brief looks at it so far it's hard to see how it integrates with other features they may not have been using. It would also be interesting to know what things haven't been implemented since they weren't necessary for Durian, but are important for general purpose usage. This has been the case in the renderer work of previous open projects, so it wouldn't be anything new, but it does make things worse. * How much of it is based on telling the artists in the studio oh, don't do that, it doesn't work properly, just do it this way for now? I totally understand when using project-specific tools put together in production that there are often rough edges. For the purposes of that job, you just work around the flaws to get the job done - I've done it many times. However there can also be quite a difference between this and something that's suitable and reliable for general purpose use in a variety of scenarios. To what extent is this the case for the render branch work? * How stable/bug-free is it? I haven't seen much evidence of wider production testing outside of Durian, and bug reports with it were discouraged during Durian (totally understandably - there was enough to deal with!) But if problems are found, how likely is it that they can be fixed? Are there problems with it that are due to more general issues with blender's renderer (eg. lack of derivatives in raytracing?), but that get amplified or made more apparent when using the new features? Just some things to think about - it's important to consider the costs vs benefits and there are quite some potential costs to merging this right now, too. cheers Matt On 06/08/2010, at 23:12 , Brecht Van Lommel 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 ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] Render Branch Plans
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
