Re: [Bf-committers] Blender developers meeting notes - August 2, 2015
Thats fine, and good common sense. But its not great to have meeting notes, implying developers have been in error... then expand this to 5 dot points after the fact ... which we were supposed to have guessed from the beginning. On Mon, Aug 3, 2015 at 6:40 PM, Ton Roosendaal wrote: > Hi Sergey, > > Thanks for the clarification. :) > > We should also keep doing a call for documtation help. > Remember... the artist/user members of module teams were meant to help there > too. > > -Ton- > > > Ton Roosendaal - t...@blender.org - www.blender.org > Chairman Blender Foundation - Producer Blender Institute > Entrepotdok 57A - 1018AD Amsterdam - The Netherlands > > > > On 3 Aug, 2015, at 10:34, Sergey Sharybin wrote: > >> Answers are inlined this time >> >> I was considering "making them happier", as effecting them too :) >>> (read "user visible optimizations"). >>> >> >> This is to go to the release notes. See for example: >> http://wiki.blender.org/index.php/Dev:Ref/Release_Notes/2.75/Cycles#Performance_Optimizations >> >> This statement imply that devs have been remiss in not documenting their >>> optimizations. >>> >> >> I don't see how it implies that. >> >> For me this is still fuzzy - can anyone point to a couple of optimizations >>> should should have been documented but weren't? >> >> >> We're not talking about optimizations not being documented , we're talking >> about changes which affects other developers not being documented. >> >> Let's put it this way: >> >> - Optimizations which doesn't touch other developers goes to the release >> notes page >> - Changes in python API (which touches both users and developers) goes to >> the release notes page >> - Optimizations which touches other developers goes to wiki >> - Any other changes which touches other developers goes to wiki >> - When in doubts -- write documentation! >> >> Just use a common sense and make sure blender's design is easy to get into. >> >> -- >> With best regards, Sergey Sharybin >> ___ >> 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 -- - Campbell ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Blender developers meeting notes - August 2, 2015
Hi Sergey, Thanks for the clarification. :) We should also keep doing a call for documtation help. Remember... the artist/user members of module teams were meant to help there too. -Ton- Ton Roosendaal - t...@blender.org - www.blender.org Chairman Blender Foundation - Producer Blender Institute Entrepotdok 57A - 1018AD Amsterdam - The Netherlands On 3 Aug, 2015, at 10:34, Sergey Sharybin wrote: > Answers are inlined this time > > I was considering "making them happier", as effecting them too :) >> (read "user visible optimizations"). >> > > This is to go to the release notes. See for example: > http://wiki.blender.org/index.php/Dev:Ref/Release_Notes/2.75/Cycles#Performance_Optimizations > > This statement imply that devs have been remiss in not documenting their >> optimizations. >> > > I don't see how it implies that. > > For me this is still fuzzy - can anyone point to a couple of optimizations >> should should have been documented but weren't? > > > We're not talking about optimizations not being documented , we're talking > about changes which affects other developers not being documented. > > Let's put it this way: > > - Optimizations which doesn't touch other developers goes to the release > notes page > - Changes in python API (which touches both users and developers) goes to > the release notes page > - Optimizations which touches other developers goes to wiki > - Any other changes which touches other developers goes to wiki > - When in doubts -- write documentation! > > Just use a common sense and make sure blender's design is easy to get into. > > -- > With best regards, Sergey Sharybin > ___ > 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] Blender developers meeting notes - August 2, 2015
Answers are inlined this time I was considering "making them happier", as effecting them too :) > (read "user visible optimizations"). > This is to go to the release notes. See for example: http://wiki.blender.org/index.php/Dev:Ref/Release_Notes/2.75/Cycles#Performance_Optimizations This statement imply that devs have been remiss in not documenting their > optimizations. > I don't see how it implies that. For me this is still fuzzy - can anyone point to a couple of optimizations > should should have been documented but weren't? We're not talking about optimizations not being documented , we're talking about changes which affects other developers not being documented. Let's put it this way: - Optimizations which doesn't touch other developers goes to the release notes page - Changes in python API (which touches both users and developers) goes to the release notes page - Optimizations which touches other developers goes to wiki - Any other changes which touches other developers goes to wiki - When in doubts -- write documentation! Just use a common sense and make sure blender's design is easy to get into. -- With best regards, Sergey Sharybin ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Blender developers meeting notes - August 2, 2015
On Mon, Aug 3, 2015 at 6:18 PM, Sergey Sharybin wrote: > The full statement is: > > Reminder: anyone who wants to add something that affects users or other > developers (APIs): always make a nice doc! *Before the commit* Even when > you think it's not interesting (like optimizing). Blender work is > interesting to share by default! > > Key part of the sentence: affects users or other developers (APIs) > > Commits which you listed doesn't affects users (other than making them > happier) and doesn't affect other developers. I was considering "making them happier", as effecting them too :) (read "user visible optimizations"). This statement imply that devs have been remiss in not documenting their optimizations. For me this is still fuzzy - can anyone point to a couple of optimizations should should have been documented but weren't? > On Mon, Aug 3, 2015 at 10:13 AM, Campbell Barton > wrote: > >> > P.S. The commits you've mentioned above are mainly implementation details >> > changes, they don't touch design as we know it. Only arguable thing is >> the >> > sculpt custom data commit, which on the one hand doesn't change anything >> in >> > the CustomData design and just makes it to use existing solutions form >> > there, but on another hand shows that our CustomData area is rather >> > mysterious area which you can't get into so much easy. >> >> Right, but they're optimizations, from the meeting notes, there is the >> comment: >> >> > always make a nice doc! *Before the commit* Even when you think it's not >> interesting (like optimizing). >> > Blender work is interesting to share by default! :) >> ___ >> Bf-committers mailing list >> Bf-committers@blender.org >> http://lists.blender.org/mailman/listinfo/bf-committers >> > > > > -- > With best regards, Sergey Sharybin > ___ > 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] Blender developers meeting notes - August 2, 2015
The full statement is: Reminder: anyone who wants to add something that affects users or other developers (APIs): always make a nice doc! *Before the commit* Even when you think it's not interesting (like optimizing). Blender work is interesting to share by default! Key part of the sentence: affects users or other developers (APIs) Commits which you listed doesn't affects users (other than making them happier) and doesn't affect other developers. On Mon, Aug 3, 2015 at 10:13 AM, Campbell Barton wrote: > > P.S. The commits you've mentioned above are mainly implementation details > > changes, they don't touch design as we know it. Only arguable thing is > the > > sculpt custom data commit, which on the one hand doesn't change anything > in > > the CustomData design and just makes it to use existing solutions form > > there, but on another hand shows that our CustomData area is rather > > mysterious area which you can't get into so much easy. > > Right, but they're optimizations, from the meeting notes, there is the > comment: > > > always make a nice doc! *Before the commit* Even when you think it's not > interesting (like optimizing). > > Blender work is interesting to share by default! :) > ___ > Bf-committers mailing list > Bf-committers@blender.org > http://lists.blender.org/mailman/listinfo/bf-committers > -- With best regards, Sergey Sharybin ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Blender developers meeting notes - August 2, 2015
> P.S. The commits you've mentioned above are mainly implementation details > changes, they don't touch design as we know it. Only arguable thing is the > sculpt custom data commit, which on the one hand doesn't change anything in > the CustomData design and just makes it to use existing solutions form > there, but on another hand shows that our CustomData area is rather > mysterious area which you can't get into so much easy. Right, but they're optimizations, from the meeting notes, there is the comment: > always make a nice doc! *Before the commit* Even when you think it's not > interesting (like optimizing). > Blender work is interesting to share by default! :) ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Blender developers meeting notes - August 2, 2015
Campbell, Changes in the data structures which are used all over the place is surely a subject for documentation. That being said, the changes around all this looptri, modifications in the tangent space calculation, BVH changes (which touching almost anyone working on Blender) is definitely a subject for documentation. If you've got good explanation in the commit message, then just copy-paste the information to the wiki. Previous sentence also answers your question about to share this information -- in the wiki. While the information in there can become outdated it's at least _possible_ to change it (compared to commit message which you can never change). Can we just stop the discussion and consider all blender design solutions are to be in the wiki? (not necessarily in the Dev section, might be just some page under the user page). P.S. The commits you've mentioned above are mainly implementation details changes, they don't touch design as we know it. Only arguable thing is the sculpt custom data commit, which on the one hand doesn't change anything in the CustomData design and just makes it to use existing solutions form there, but on another hand shows that our CustomData area is rather mysterious area which you can't get into so much easy. Joe + Antony, You don't know a-priori if there's users of mesh outside of the viewport and dependency graph wouldn't help with this at all. Think of sculpting, changed in modifier stack, using snapping to a volume and so on. Plus, all the objects are actually requiring having AABB. I'm also not really convinced with deform modifiers being calculated on GPU. Do you have some experimentation results or so? On Mon, Aug 3, 2015 at 6:59 AM, Campbell Barton wrote: > > - Reminder: anyone who wants to add something that affects users or > other developers (APIs): > > always make a nice doc! *Before the commit* Even when you think it's not > interesting (like optimizing). > > Blender work is interesting to share by default! :) > > I don't want to quibble here but this statement makes it sound as if > it should be obvious when to document development, > to me this is way too vague/fuzzy. > > Optimization and general improvements happen fairly often, > applying some common sense I assume the statement above means > optimizations which users are likely to notice. Not the "~3% speedup > on a good day" variety :) > > Even then, we've had improvements to low level code: hashing [0], > optimizing allocations for slop-space [1, 2], merge-sort for > linked-lists [3], misc BMesh improvements [4, 5] > (not a comprehensive list, just to pick some from memory). > > Which ones of these would should be documented *before* committing, and > where? > > Significant speedups are worth mentioning in the release log, but further, > I'd prefer good high level explanations/comments in the code, and > detailed commit-log if its needed. > Instead of docs on the Wiki or developers own blogs which tend to get > outdated. > > [0]: > https://developer.blender.org/rBcfdd27381c6730dc0d8d4bb51c132b29337b8af5 > [1]: > https://developer.blender.org/rBe220d3228f48d4cb3256b398b45b40bf6892e550 > [2]: > https://developer.blender.org/rB19b7bb5975afdc2340538cb48d85e445828e9d7f > [3]: > https://developer.blender.org/rB867cd2048e0e8dd9f0552ac996bb1d352136b9a0 > [4]: > https://developer.blender.org/rB65a95926600027814ef01ce5beaf711d3f41be55 > [5]: > https://developer.blender.org/rB38eef8deee4261f0139d29eb81584131a862bf59 > ___ > Bf-committers mailing list > Bf-committers@blender.org > http://lists.blender.org/mailman/listinfo/bf-committers > -- With best regards, Sergey Sharybin ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Blender developers meeting notes - August 2, 2015
> - Reminder: anyone who wants to add something that affects users or other > developers (APIs): > always make a nice doc! *Before the commit* Even when you think it's not > interesting (like optimizing). > Blender work is interesting to share by default! :) I don't want to quibble here but this statement makes it sound as if it should be obvious when to document development, to me this is way too vague/fuzzy. Optimization and general improvements happen fairly often, applying some common sense I assume the statement above means optimizations which users are likely to notice. Not the "~3% speedup on a good day" variety :) Even then, we've had improvements to low level code: hashing [0], optimizing allocations for slop-space [1, 2], merge-sort for linked-lists [3], misc BMesh improvements [4, 5] (not a comprehensive list, just to pick some from memory). Which ones of these would should be documented *before* committing, and where? Significant speedups are worth mentioning in the release log, but further, I'd prefer good high level explanations/comments in the code, and detailed commit-log if its needed. Instead of docs on the Wiki or developers own blogs which tend to get outdated. [0]: https://developer.blender.org/rBcfdd27381c6730dc0d8d4bb51c132b29337b8af5 [1]: https://developer.blender.org/rBe220d3228f48d4cb3256b398b45b40bf6892e550 [2]: https://developer.blender.org/rB19b7bb5975afdc2340538cb48d85e445828e9d7f [3]: https://developer.blender.org/rB867cd2048e0e8dd9f0552ac996bb1d352136b9a0 [4]: https://developer.blender.org/rB65a95926600027814ef01ce5beaf711d3f41be55 [5]: https://developer.blender.org/rB38eef8deee4261f0139d29eb81584131a862bf59 ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Blender developers meeting notes - August 2, 2015
What might work is detecting if the final derived mesh has any users outside the draw code, and if it does not then it may be possible to use some sort of shader and do the calculation there. If it does, then we will be needing the full result anyway, so we can just upload that and skip the vertex shader cost. Some modifiers, such as the array modifier can also benefit from similar code (+ instancing) but they also need a way to detect cornercases (such as the object used as a duplicated mesh for instance). I must say though, I am not sure if using vertex shaders is the best way to go, because it makes material shaders depend on modifiers which means more shader bind calls plus materials would need a more elaborate shader storing scheme for every material/modifier combination. Maybe the way OpenSubdiv handles this can be generalized, but we'll see if that's possible when/if we have full support in the future. Probably the depsgraph might support these kinds of queries, though Sergey, Lukas or Joshua would know best. The DAG should also be used to detect what mesh data need to be reuploaded to the GPU due to some underlying mesh change as well. Currently though, I'm still porting all mesh code to use vertex buffer objects properly and haven't checked the depsgraph at all. On 2 August 2015 at 19:07, joe wrote: > Who's doing the viewport optimization work? I have some experience here. > The key thing is to limit OpenGL commands, and also the data sent per-frame > to the GPU. It might also be a good idea to move the simpler deform > modifiers into vertex shaders (and make sure to use a node system--it's > actually easier to use a DAG system than to try and code all the edge cases > by hand). > > > > On Sun, Aug 2, 2015 at 9:16 AM, Ton Roosendaal wrote: > >> Hi all, >> >> Here are the notes from today's meeting in irc.freenode.net >> #blendercoders. >> >> 1) Upcoming 2.76 release >> >> - OpenSubdiv: an essential fix was made by the Pixar team, we we can move >> on. (3.0.1 will be out soon). >> Unfortunately 3.0 has no UV texture support yet, will be in 3.1 later this >> year. >> >> For that reason Sergey will add it as optional choice, mainly for >> animation editing and playback >> in viewport. >> >> - Still waiting for a short document outlining the viewport Mesh >> performance work. >> >> - Reminder: anyone who wants to add something that affects users or other >> developers (APIs): >> always make a nice doc! *Before the commit* Even when you think it's not >> interesting (like optimizing). >> Blender work is interesting to share by default! :) >> >> - Due to holidays (2+ weeks absence of several core devs) we also extend >> the 2.76 with two weeks. >> >> - Current projects and planning: >> http://wiki.blender.org/index.php/Dev:Doc/Projects >> >> - Splash: suggested is to do a public contest in BA forums again. Still >> need a proposal for >> who will do the judging... and would we do a theme again? Tradition is to >> have the previous >> team/panel who selected a splash appoint the next. I'll ask the artists >> here to propose something. >> >> - Kevin Dietrich: OpenVDB patch is still waiting for review. There are >> also two (small) Cycles >> features using OpenVDB ready. The platform maintainers have to check on >> inclusion of new libs though. >> >> Check this: >> http://wiki.blender.org/index.php/User:Kevindietrich/OpenVDBRendering >> And this: >> http://wiki.blender.org/index.php/User:Kevindietrich/OpenVDBSmokeExport >> >> Laters, >> >> -Ton- >> >> >> Ton Roosendaal - t...@blender.org - www.blender.org >> Chairman Blender Foundation - Producer Blender Institute >> Entrepotdok 57A - 1018AD Amsterdam - The Netherlands >> >> >> >> ___ >> 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] Blender developers meeting notes - August 2, 2015
Who's doing the viewport optimization work? I have some experience here. The key thing is to limit OpenGL commands, and also the data sent per-frame to the GPU. It might also be a good idea to move the simpler deform modifiers into vertex shaders (and make sure to use a node system--it's actually easier to use a DAG system than to try and code all the edge cases by hand). On Sun, Aug 2, 2015 at 9:16 AM, Ton Roosendaal wrote: > Hi all, > > Here are the notes from today's meeting in irc.freenode.net > #blendercoders. > > 1) Upcoming 2.76 release > > - OpenSubdiv: an essential fix was made by the Pixar team, we we can move > on. (3.0.1 will be out soon). > Unfortunately 3.0 has no UV texture support yet, will be in 3.1 later this > year. > > For that reason Sergey will add it as optional choice, mainly for > animation editing and playback > in viewport. > > - Still waiting for a short document outlining the viewport Mesh > performance work. > > - Reminder: anyone who wants to add something that affects users or other > developers (APIs): > always make a nice doc! *Before the commit* Even when you think it's not > interesting (like optimizing). > Blender work is interesting to share by default! :) > > - Due to holidays (2+ weeks absence of several core devs) we also extend > the 2.76 with two weeks. > > - Current projects and planning: > http://wiki.blender.org/index.php/Dev:Doc/Projects > > - Splash: suggested is to do a public contest in BA forums again. Still > need a proposal for > who will do the judging... and would we do a theme again? Tradition is to > have the previous > team/panel who selected a splash appoint the next. I'll ask the artists > here to propose something. > > - Kevin Dietrich: OpenVDB patch is still waiting for review. There are > also two (small) Cycles > features using OpenVDB ready. The platform maintainers have to check on > inclusion of new libs though. > > Check this: > http://wiki.blender.org/index.php/User:Kevindietrich/OpenVDBRendering > And this: > http://wiki.blender.org/index.php/User:Kevindietrich/OpenVDBSmokeExport > > Laters, > > -Ton- > > > Ton Roosendaal - t...@blender.org - www.blender.org > Chairman Blender Foundation - Producer Blender Institute > Entrepotdok 57A - 1018AD Amsterdam - The Netherlands > > > > ___ > 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] Blender developers meeting notes - August 2, 2015
Hi all, Here are the notes from today's meeting in irc.freenode.net #blendercoders. 1) Upcoming 2.76 release - OpenSubdiv: an essential fix was made by the Pixar team, we we can move on. (3.0.1 will be out soon). Unfortunately 3.0 has no UV texture support yet, will be in 3.1 later this year. For that reason Sergey will add it as optional choice, mainly for animation editing and playback in viewport. - Still waiting for a short document outlining the viewport Mesh performance work. - Reminder: anyone who wants to add something that affects users or other developers (APIs): always make a nice doc! *Before the commit* Even when you think it's not interesting (like optimizing). Blender work is interesting to share by default! :) - Due to holidays (2+ weeks absence of several core devs) we also extend the 2.76 with two weeks. - Current projects and planning: http://wiki.blender.org/index.php/Dev:Doc/Projects - Splash: suggested is to do a public contest in BA forums again. Still need a proposal for who will do the judging... and would we do a theme again? Tradition is to have the previous team/panel who selected a splash appoint the next. I'll ask the artists here to propose something. - Kevin Dietrich: OpenVDB patch is still waiting for review. There are also two (small) Cycles features using OpenVDB ready. The platform maintainers have to check on inclusion of new libs though. Check this: http://wiki.blender.org/index.php/User:Kevindietrich/OpenVDBRendering And this: http://wiki.blender.org/index.php/User:Kevindietrich/OpenVDBSmokeExport Laters, -Ton- Ton Roosendaal - t...@blender.org - www.blender.org Chairman Blender Foundation - Producer Blender Institute Entrepotdok 57A - 1018AD Amsterdam - The Netherlands ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
