Re: [Bf-committers] Changes to the Blender.Git submodule configuration
Hi, There is some feedback loop which I've missed yesterday. The new version of the `make update` is needed to bring the repository to the proper state. So, `git pull` (or other means of updating your working branch) is needed to grab the new version of the `make update` script. Best regards, - Sergey - Sergey Sharybin - ser...@blender.org - www.blender.org Principal Software Engineer, Blender Buikslotermeerplein 161, 1025 ET Amsterdam, the Netherlands On Tue, Feb 21, 2023 at 4:23 PM Sergey Sharybin wrote: > Hi everyone, > > A quick announcement about the changes in the submodule organization of > the blender.git repository. It affects both blender-v3.5-release and main > branches. > > In order to resolve the confusion about submodule hashes we are completely > removing submodules. The locales and developers tools will become part of > the main repository, and the addons will be a checkout into a git-ignored > folder. > > Once the changes are committed, running `make update` will take care of > properly re-initializing the worktree configuration. > > For the details please refer to the devtalk tthread > https://devtalk.blender.org/t/changes-to-the-blender-git-submodule-configuration/27831 > > Best regards > - Sergey - > -------- > Sergey Sharybin - ser...@blender.org - www.blender.org > Principal Software Engineer, Blender > Buikslotermeerplein 161, 1025 ET Amsterdam, the Netherlands > ___ Bf-committers mailing list Bf-committers@blender.org List details, subscription details or unsubscribe: https://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] Changes to the Blender.Git submodule configuration
Hi everyone, A quick announcement about the changes in the submodule organization of the blender.git repository. It affects both blender-v3.5-release and main branches. In order to resolve the confusion about submodule hashes we are completely removing submodules. The locales and developers tools will become part of the main repository, and the addons will be a checkout into a git-ignored folder. Once the changes are committed, running `make update` will take care of properly re-initializing the worktree configuration. For the details please refer to the devtalk tthread https://devtalk.blender.org/t/changes-to-the-blender-git-submodule-configuration/27831 Best regards - Sergey - Sergey Sharybin - ser...@blender.org - www.blender.org Principal Software Engineer, Blender Buikslotermeerplein 161, 1025 ET Amsterdam, the Netherlands ___ Bf-committers mailing list Bf-committers@blender.org List details, subscription details or unsubscribe: https://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] Discontinuing git.blender.org
Hi everyone, Just a brief announcement that on March 1 we plan to discontinue the git.blender.org domain. Since the migration to Gitea on projects.blender.org the git.blender.org is no longer used to provide the actual sources and is marked to be in the archive/read-only mode. Please make sure your build scripts and everything else that uses git.blender.org is switched to using projects.blender.org. Best regards, - Sergey - Sergey Sharybin - ser...@blender.org - www.blender.org Principal Software Engineer, Blender Buikslotermeerplein 161, 1025 ET Amsterdam, the Netherlands ___ Bf-committers mailing list Bf-committers@blender.org List details, subscription details or unsubscribe: https://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] Migration to Gitea is about to start!
Hi everyone, Just a quick note that the migration process from Phabricator to Gita is planned to start at 10:00 CET time (in about 20 minutes). The infrastructure will be set to read-only mode for SVN, Git, and developer.blender.org. Bigger intermittent disruptions are possible. We will keep you posted in the best of our abilities in the bf-committers room on our blender.chat Best regards, - Sergey - Sergey Sharybin - ser...@blender.org - www.blender.org Principal Software Engineer, Blender Buikslotermeerplein 161, 1025 ET Amsterdam, the Netherlands ___ Bf-committers mailing list Bf-committers@blender.org List details, subscription details or unsubscribe: https://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] Task force: Mark non-trivial DNA as such for C++
Hi everyone, With more parts of Blender moving to C++ some of the shortcomings of old-style DNA structures started to become a bit of annoyance for on-going development (compiler warnings, not-so-semanticly-obvious code, ...). Me and Jacques did some ground work to make operations on DNA structures from C++ code more modern and more in a way which C++ developers expect them to be. We've covered a handful of DNA structures, but there are much more to cover. Likely, it is a straightforward process, which is easy to multi-task and has the full benefit of module developers and volunteers around! More details of what and how are written up in the https://developer.blender.org/T96847 If you have any questions talk to me on blender-coder chat. Best regards, - Sergey - Sergey Sharybin - ser...@blender.org - www.blender.org Principal Software Engineer, Blender Buikslotermeerplein 161, 1025 ET Amsterdam, the Netherlands ___ Bf-committers mailing list Bf-committers@blender.org List details, subscription details or unsubscribe: https://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Proposal for clarified VFX Reference Platform Support
Hi Brecht, Sure there are trade-offs and different ways of solving problems. It is more of what the Blender project considers important. For example: is it more important to spend developers' time on patching our own version (effectively, fork) of Python, or deviate from the Platform by updating to a vanilla newer version of upstream and focus actual development on something more impactful. For the distros: we know Blender is used there and that distros contribute back to Blender. Or, at least, participate in Blender development. To me, making this part unnecessarily complicated for the distros, and prioritizing benefits for an unknown number of studios, doesn't seem to play in the best of open source community driven nature of Blender. P.S. If the VFX Platform finds it important to use libraries like Python for longer than the upstream supports them, why can't the people who benefit from the VFX Platform maintain the forks? Best regards, - Sergey - Sergey Sharybin - ser...@blender.org - www.blender.org Principal Software Engineer, Blender Buikslotermeerplein 161, 1025 ET Amsterdam, the Netherlands On Mon, Jan 24, 2022 at 1:09 PM Brecht Van Lommel via Bf-committers < bf-committers@blender.org> wrote: > There are definite trade-offs, but a few things: > * Linux distribution packages are not expected to follow the VFX platform. > They have always deviated in the library versions compared to our own > builds, including the Python version. > * Upgrading to the latest Python version is not the only way to fix bugs, > we can also patch our Python build with a fix for the rare case that > happens and is important. > * The platform library versions are not that old, and in some cases it has > made us upgrade quicker. We've never tracked the latest libraries closely > for every Blender release. > * At least for me, tracking to the VFX platform did not stop me making > upstream contributions or fixing build issues with latest versions of > libraries. > * It's not clear to me how the VFX platform could negatively affect studios > making contributions to Blender, that would be an argument against LTS > releases if anything. > * Studios will stick to a particular platform for the duration of a > project, and in parallel use newer platforms for new projects. That's the > sane option for them regardless if we like it. > > > On Mon, Jan 24, 2022 at 12:28 PM Sybren A. Stüvel via Bf-committers < > bf-committers@blender.org> wrote: > > > On Fri, Jan 21, 2022 at 02:27:19PM +0100, Dalai Felinto via > Bf-committers > > wrote: > > > To have studios contributing to Blender is a two-way street. And > Blender > > > sticking to the VFX is the least the Blender project can do on its end. > > > > This seems to ignore the fact that we've already broken with the VFX ref > > platform when it comes to the Python version. It was done simply because > a > > Blender-crashing bug was fixed in Python, and the only way to get that > fix > > was to get a newer version of Python. > > > > On Fri, 21 Jan 2022 at 16:31, Sebastian Parborg via Bf-committers < > > bf-committers@blender.org> wrote: > > > > > It will lead to very rigid and stale development environment which will > > > use obsolete library versions and APIs even before we do a new release. > > > Our developers will not be able to be agile when handling library > > > related issues or follow upstream development incrementally. This also > > > means that we can't collaborate with upstream that well either. > > > > > > > This is also what I suspect might happen when we take the stance to stick > > to the VFX platform. > > > > > > > To me the easiest solution would simply just to take the stance that if > > > someone wants to use a frozen and outdated target platform, then they > > > can simply just use an older version of Blender that uses the required > > > python version and libraries. > > > > > > > Part of the problem is that the VFX platform is all over the place when > it > > comes to the age of the libraries. It's not just sticking to old > versions, > > but also has suggested a version of OpenEXR that wouldn't even be > released > > yet. It's the combination of unusably old and not-yet-usable new that > > boggles my mind. There is no old version of Blender that matches the old > > versions of the VFX ref platform, because there is no moment in time when > > all those versions were considered "current". > > > > Sybren > > ___
Re: [Bf-committers] Bf-committers Digest, Vol 1040, Issue 1
Hi Brian, Thanks for sharing the insights. I've almost missed your reply. We have a dedicated mailing list thread for it. The bright side of supporting newer early Python is that the moment VFX Platform releases its new version for the next year all the work is already done and even tested! :) While the following questions might not be directly related to the ongoing VFX Platform discussion, I've got couple of questions to have a deeper understanding of the situation and what could potential solutions be: - Is using Python's Limited API [1] something that was investigated? From a quick look it seems that it covers everything we use in Cycles Python module. - How much easier render engine's development and distribution would be if they would have access to C++ RNA (same as we use in Cycles) ? [1] https://docs.python.org/3/c-api/stable.html#c.Py_LIMITED_API Best regards, - Sergey - Sergey Sharybin - ser...@blender.org - www.blender.org Principal Software Engineer, Blender Buikslotermeerplein 161, 1025 ET Amsterdam, the Netherlands On Sat, Jan 15, 2022 at 2:25 PM Brian Savery via Bf-committers < bf-committers@blender.org> wrote: > > > > > > Let’s not beat around the bush, no-one has > > ever complained about our OIIO, Boost, VDB or > > TBB versions. People get ..passionate.. > > about python, anytime someone brings up the > > VFX Platform it's python, It's never anything > > else, it's python, the rest of the VFX platform > > may as well not exist. The issue is, and will > > always be python. > > > > The real question is, are we going to follow > > the platform in regards to python or not. > > > > Ray I think hit the nail on the head here. And just to put a finer point on > it. The issue is not python scripts (those will always be forward > compatible) but python c extensions. > > For example the RenderMan guys include a python binding of the RenderMan > API in their distro. This is compiled for a specific python version(s) > usually based one the VFX reference platform because they have to work in > Maya Houdini etc. Moving to a newer version of python breaks compatibility > for add-ons like this. > > Usually for add-ons developers moving their build systems to a new version > of python to compile against causes significant pain which is why you hear > the complaints. I'm not saying this pain should hold blender back > nescessarily but just explaining it. And as an add-on developer who > supports multiple Softwares we don't see this python issue other places. > > > > > -- > brian.sav...@gmail.com > 508-274-8700 > ___ > Bf-committers mailing list > Bf-committers@blender.org > List details, subscription details or unsubscribe: > https://lists.blender.org/mailman/listinfo/bf-committers > ___ Bf-committers mailing list Bf-committers@blender.org List details, subscription details or unsubscribe: https://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Proposal for clarified VFX Reference Platform Support
Hi, Jason, taking the LTS release schedule, Python/other libraries release schedule, and VFX platform release schedule, I am not really sure how to achieve this in practice. Not even sure it brings more solutions than problems. Ray, our paths might be different but the goal is the same: minimize gray area. Define what is really important for the project, and work towards that. It might not be something the Platform is aimed to solve, but is something Blender will find important. Best regards, - Sergey - Sergey Sharybin - ser...@blender.org - www.blender.org Principal Software Engineer, Blender Buikslotermeerplein 161, 1025 ET Amsterdam, the Netherlands On Fri, Jan 21, 2022 at 12:51 AM Ray Molenkamp via Bf-committers < bf-committers@blender.org> wrote: > I don't think any of the major vendors (nor us) will build openvdb > with a wonky blosc version that will give compatibility issues, point > is neither the danger of using a "wrong" blosc version nor any other > mention of file compatibility is in the platform (but it is in the > openvdb documentation) So my argument was about not referring to > the platform as an authority on file compatibility, since they aren't. > The choice to follow the platform or not is a completely separate > choice. > > I'm desperately trying to get us to a point where rather than an > uncommitted, "we follow some things, not others, kinda depends on our > mood, and if we like to make a random exception or not, also here are > some arbitrary commitments to things that platform doesn't even seem to > do" to a crystal clear: > > -These are the things we do > -These are the things we don't > > I'd rather give users like you solid hard disappointment you can > count on, than comforting false hope that will disappoint. Guaranteed > platform adherence would have been acceptable as well, but that does > not appear to be the direction we are appear to be leaning. > > My objective is to minimize/eliminate the "gray zone" blender has > been in for the last few years regarding the platform, VFX Platform in or > out, I'm cool either way, but we have to pick a team and communicate it > clearly to our users. > > --Ray > > On 2022-01-20 12:40 p.m., Scott Wilson wrote: > > I'm sort of out of the loop, but has there been communications with the > VFX Reference Platform recently? I think that some of the issues brought up > such as build flags for OpenVDB could be resolved. I know that as a > pipeline TD in a studio, having all of the vendors on the same page about > all attributes of the build environment makes my life much easier. So, I > throw what little say I have into getting Blender and the platform aligned. > > > > On Thu, Jan 20, 2022, 11:22 AM Ray Molenkamp via Bf-committers < > bf-committers@blender.org> wrote: > > > > While I do not mind the practical nuts and bolts of this > > proposal at all, I do mind the language, referring to the > > VFX Platform as something worth looking at regarding file > > or platform compatibility is unfortunate. > > > > The Platform as is makes no attempt to manage file compatibility > > throughout the pipeline, the big-ticket items in this space such > > as USD and/or MaterialX aren't even in the platform, the things > > that are in the platform, such as OpenVDB that have _severe_ > > file compat issues if build incorrectly do not even have a footnote > > about it. The only logical conclusion here is, the VFX Platform > > is a not authority to appeal to regarding file compatibility, so > > best not to. > > > > As for platform compatibility, the messaging in the VFX Platform > > is confusing, for linux it declares a glibc version, for macOS it > > declares a deployment target, so far so good, but then for windows > > it does none of these things, and just recommends a compiler and SDK > of > > which neither determine the OS versions the resulting code can > > run on, the inclusion of python 3.9 indirectly implies windows 8.1 > > is their minimum windows deployment target, but honestly I'm unsure > > if even they are aware of this implication. > > > > I'd like to see the proposal move more into concrete direction: > > > > > Blender does NOT follow the VFX platform. > > > > > > - Blender aims be compatible with operating systems VFX Platform > compatible software will be able run on. > > > - blender aims not to break file compatibility for 3rd party > formats such as EXR, VDB, Alembic: files exported from Blender shoul
Re: [Bf-committers] Proposal for clarified VFX Reference Platform Support
Hi everyone, I had a discussion with Brecht here. He brought up a good point which I do agree with him is important: keep render engines working. We do have an official render engine API, and breaking render engines support without good reason is not very nice. Here is an update of my proposal: > Blender runs on an operating system stated by the VFX Reference Platform, but the exact library versions are not followed. The constraints/restrictions are: - Not to break file compatibility for 3rd party formats such as EXR, VDB, Alembic: files exported from Blender should be openable in another software used in the pipeline, and vice-versa - Not to break external render engines Think summary of practical implications goes as following: - We don't update libraries unless there is benefit for Blender users - All known breakages are announced - If an unpredicted breakage happens we look into it (same as we look, say, into conflicts between Mesa and OSL via LLVM) For the moving forward I think if BF admins agree on the proposal we make it official and stick to it. Best regards, -Sergey - ---- Sergey Sharybin - ser...@blender.org - www.blender.org Principal Software Engineer, Blender Buikslotermeerplein 161, 1025 ET Amsterdam, the Netherlands On Thu, Jan 20, 2022 at 4:58 AM Ray Molenkamp via Bf-committers < bf-committers@blender.org> wrote: > The reason that is, most of the people involved are in the > discussion are not in a position to make this decision > (and that includes me) We can have good arguments on either > side of following or not following, but none of us can > decide. > > This is something that will have to be decided at the top. > It's essentially between Ton and the project admins, decide > what what the position is of the blender project, VFX Platform > are we in or are we out? > > The stance we had for the last few years, "We're in, this > year, since it kinda aligns, next year? maybe not? there's > exceptions... if we feel like it.." isn't working, the > sooner we realize that the better. > > If we again do not take a solid stance, I guarantee you > we will have the same song and dance in between 6 and 12 > months from now. > > I'm not overly interested in deciding on the > python upgrade right now (even though that personally > puts me in a rough spot with bcon3 this close) I'd > rather see this through and have HQ sort it out once > and for all. > > --Ray > > On 2022-01-19 8:34 p.m., Campbell Barton via Bf-committers wrote: > > This discussion seems to suffer the same fate as other VFX platform > > threads... fizzle out with no conclusion. > > > ___ > Bf-committers mailing list > Bf-committers@blender.org > List details, subscription details or unsubscribe: > https://lists.blender.org/mailman/listinfo/bf-committers > ___ Bf-committers mailing list Bf-committers@blender.org List details, subscription details or unsubscribe: https://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Proposal for clarified VFX Reference Platform Support
Hi Bastien, That's a good question you're bringing. For the Python my thoughts are aligned with Campbell. For other libraries I wouldn't make it an official support in the terms that it is us who verifies Blender compiles and works with library versions we don't use ourselves, but we should be open to fixes (assuming they are small, non-intrusive) from people who actually compile Blender with those library versions. Very similar to how we support platforms other than x86_64 and arm64. Bets regards, - Sergey - Sergey Sharybin - ser...@blender.org - www.blender.org Principal Software Engineer, Blender Buikslotermeerplein 161, 1025 ET Amsterdam, the Netherlands On Mon, Jan 17, 2022 at 1:42 PM Campbell Barton via Bf-committers < bf-committers@blender.org> wrote: > On Mon, Jan 17, 2022 at 11:12 PM Bastien Montagne via Bf-committers > wrote: > > > > Hi Sergey and all, and thanks for this proposition. > > > > This proposal makes complete sense to me. I do not see any benefit for > > Blender to stick to a strict compatibility with VFX platform, but indeed > > ensuring a file-level compatibility seems a good minimum guaranty. > > > > I have one question though, should we still guarantee that we keep > > Blender working with the VFX platform versions of the libraries, or not? > > E.g. do we keep Blender working with python 3.9, even if we switch our > > own builds to 3.11? Think the answer to this question should also be > > clearly stated. > > > > And if we do keep this compatibility level, how do we ensure it? Add new > > buildbot instances with VFX-versioned dependencies? Just 'do our best' > > and fix issues when reported? > > For other libraries, I don't have a strong opinion, for Python though > - keeping *official* support for multiple versions adds too much > overhead. > Even for tracker triage, switching Python versions to match the user > who's reporting takes extra time. > And as you mention - integrating this into the build-bot etc would be > needed too (ideally at least) > > We could consider *unofficial* support by not breaking builds for > older Python versions for a period of time, > meaning that users who have a requirement for an older version can > still build Blender themselves. > Although I'm not sure this is an important use case, just noting that > I wouldn't rule it out entirely. > > > Cheers, > > Bastien > > > > ___ > > Bf-committers mailing list > > Bf-committers@blender.org > > List details, subscription details or unsubscribe: > > https://lists.blender.org/mailman/listinfo/bf-committers > > > > -- > - Campbell > ___ > Bf-committers mailing list > Bf-committers@blender.org > List details, subscription details or unsubscribe: > https://lists.blender.org/mailman/listinfo/bf-committers > ___ Bf-committers mailing list Bf-committers@blender.org List details, subscription details or unsubscribe: https://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Proposal for clarified VFX Reference Platform Support
Hi, Thanks for the feedback. I don't really feel great about Python being the only exception allowed to be digressed from the platform. It is the most impactful library from the ones which are directly facing users. If we allow it to be different from what the Platform is stating, I don't see issues with digression in other libraries which nobody from users is likely to even notice. For the TBB sure there were no big passionate discussions, at least yet. It doesn't mean staying at an older (officially unsupported, btw) version doesn't bring, say, maintenance and development and moving forward complications. Campbell, it seems something went wrong with URLs in your message. Not sure which exact mail/thread the first one is supposed to be pointing, and the second one is 404. Do you mind sending a followup with updated links? I agree that the outcome should be much more prominently communicated. That's what I think should happen as an outcome of discussion in this thread: we come up with policy and explicitly communicate it. Ray, Campbell: The Python situation is a subset of the proposal in my original message. So in this regard we are aligned. But it is not really clear to me what your position is when it comes to non-Python. Do you disagree with the proposal, are you fine with it, or suggest something else? Best regards, - Sergey - Sergey Sharybin - ser...@blender.org - www.blender.org Principal Software Engineer, Blender Buikslotermeerplein 161, 1025 ET Amsterdam, the Netherlands On Mon, Jan 17, 2022 at 5:58 AM Campbell Barton via Bf-committers < bf-committers@blender.org> wrote: > As far as I'm aware, the decision for Blender *not* to follow the VFX > platform for Python is still in place (allowing us to follow Python's > release schedule, unless there are good reasons not to). > > Last time the topic came up was May 2021, the discussion petered out > and there were no conclusions from that thread or meeting minutes at > the time that any changes were planned. see: [0] "VFX reference > platform 2022 draft" thread. > Although it would have been good if the outcome of this discussion was > noted in meeting minutes (or noted needing further discussion if > developers involved thought the topic was unresolved). > > My opinion on this hasn't changed from the comments made here [1]. > > [0]: > https://lists.blender.org/pipermail/bf-committers/2021-May/thread.html#50990 > [1]: https://lists.blender.org/pipermail/bf-committers/2021-May/050998. > > > On Sat, Jan 15, 2022 at 11:57 AM Ray Molenkamp via Bf-committers > wrote: > > > > All right, looks like we're tiptoeing around > > the elephant in the room, time to rip that > > Band-Aid off (feels like this metaphor kinda > > got away from me, but I'm sticking with it!) > > > > Let’s not beat around the bush, no-one has > > ever complained about our OIIO, Boost, VDB or > > TBB versions. People get ..passionate.. > > about python, anytime someone brings up the > > VFX Platform it's python, It's never anything > > else, it's python, the rest of the VFX platform > > may as well not exist. The issue is, and will > > always be python. > > > > The real question is, are we going to follow > > the platform in regards to python or not. > > > > The way the python [1] and VFX Platforms [2] > > are released those most we'll ever have is a > > 5-month window where the two will overlap and > > there will actually be active bug fix support > > on python the python version of the VFX Platform. > > Are we OK with that? > > > > People get upse..uhh passionate when we "suddenly" > > change our python version. What is needed is a > > clear and decisive message regarding how we pick > > our python versions. > > > > Are we following: > > > > A) The python release schedule > > B) The VFX platform schedule > > C) Well, you know maybe, VFX kind of works out > > this year so why not, next year maybe not so > > much, we'll see, oh hey this years python has …. > > [check notes]..better….. error.. messages? we got > > to upgrade! > > D) Other > > > > We have been doing C, and I don't think anyone > > is super thrilled about how this is working out. > > > > I mostly don’t even care what we pick (not C!!) > > pick something, write it down somewhere, so people > > can rely on it. > > > > --Ray > > > > [1] https://www.python.org/dev/peps/pep-0602/ > > [2] https://vfxplatform.com/about/ > > > > ___ > > Bf-committers mailing list > > Bf-committers@blender.o
[Bf-committers] Proposal for clarified VFX Reference Platform Support
Hi everyone, This message is meant to address some ongoing confusion about how Blender is adhering to the VFX Reference Platform, and clarify the Blender project’s goals. Currently developers and platform maintainers are spending considerable amount of time in discussions when a library update is proposed (or even when it is needed as a bug fix). This time is spent on weighting cons and pros, sometimes ending up with decisions that go against measurable benefits of Blender users who are not following the VFX Reference Platform in their pipeline or work environment. In other cases, some libraries are already not following the VFX Reference Platform because of critical bug fixes that required a library update. I propose to limit the compatibility scope with the VFX Reference Platform to the following: > Blender runs on an operating system stated by the VFX Reference Platform, but the exact library versions are not followed. This allows Blender to run in an “industry” pipeline, while at the same time provides developers with the freedom of quickly improving and fixing Blender for the whole community. In order to help the industry to mitigate risks of symbol conflicts when their Python add-ons use mismatching libraries, we can make the symbol hiding more aggressive. The restriction on the libraries update would be not to break file compatibility for 3rd party formats such as EXR, VDB, Alembic: files exported from Blender should be openable in another software used in the pipeline, and vice-versa. Surely, the proposal above is based on my own observations and experience of working in the related areas. Feedback is welcome. Best regards, - Sergey - ---- Sergey Sharybin - ser...@blender.org - www.blender.org Principal Software Engineer, Blender Buikslotermeerplein 161, 1025 ET Amsterdam, the Netherlands ___ Bf-committers mailing list Bf-committers@blender.org List details, subscription details or unsubscribe: https://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] Let's Encrypt SSL certificates incident on the blender.org servers
Hi, Just a quick memo about the issue of expired Let's Encrypt certificates. It might be useful for developers who experience issues with HTTPS connection to our servers. One of the root Let's Encrypt certificates did expire today which affected parts of our development infrastructure. In all cases it doesn't seem to be an issue with the server configuration but is caused by quirks on the client side. We are only aware of issues on Windows. The Subversion clients did not trust the SSL certificate of https://svn.blender.org/. The work-around we did for the builder.blender.org was to install the Let’s Encrypt R3 intermediate certificate [1]. This "worked (tm)", although ideally intermediate certificates shouldn't need to be installed and the system should go by the root CA certificates from the Windows Certificates Store. The Arcanist uses the CURL extension of PHP, and it does not use the Windows Certificates Store. The way it was fixed on the buildbot workers was by creating a cacert.pem with the "ISRG Root X1" certificate which was exported from the Store (and matched the one from Let's Encrypt information page [1]). Our server administrator Danny McGrath also took the liberty of disabling TLSv1.0 and TLSv1.1 on some of the sites during tests. Provided that this doesn't make matters worse, the changes are likely to be kept. [1] https://letsencrypt.org/certificates/ Best regards, - Your Engineering Team Danny and Sergey - ---- Sergey Sharybin - ser...@blender.org - www.blender.org Principal Software Engineer, Blender Buikslotermeerplein 161, 1025 ET Amsterdam, the Netherlands ___ Bf-committers mailing list Bf-committers@blender.org List details, subscription details or unsubscribe: https://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] Blender developer week notes - 2021.08.02
Hello everyone, There are no announcements for this week of development. The complete report with modules and projects updates, links and images read it on: https://devtalk.blender.org/t/2-august-2021/19781 Best regards, - Sergey - Sergey Sharybin - ser...@blender.org - www.blender.org Principal Software Engineer, Blender Buikslotermeerplein 161, 1025 ET Amsterdam, the Netherlands ___ Bf-committers mailing list Bf-committers@blender.org List details, subscription details or unsubscribe: https://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] Blender developer week notes - 2021.07.26
Hello everyone, Here are the compiled notes for this week's development. For the complete report with modules and projects updates, links and images read it on: https://devtalk.blender.org/t/26-july-2021/19713 Announcements = The comments section [1] of the style-guide document has been updated (based on T81452 [2]). For the most part this formalizes current conventions. There is a dedicated mailing list thread as well [3]. [1] https://wiki.blender.org/wiki/Style_Guide/C_Cpp#Comments [2] https://developer.blender.org/T81452 [3] https://lists.blender.org/pipermail/bf-committers/2021-July/051106.html Best regards, - Sergey - Sergey Sharybin - ser...@blender.org - www.blender.org Principal Software Engineer, Blender Buikslotermeerplein 161, 1025 ET Amsterdam, the Netherlands ___ Bf-committers mailing list Bf-committers@blender.org List details, subscription details or unsubscribe: https://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Harmonious collaboration - reverting commit process
Hi, Currently I do not believe submodules change is important enough to grant a revertal. Some reasoning: - It is often harmless - It is easy to recover from - It is hard to avoid by mistake (even happens for me when committing from a non-main PC!) I do believe the situation with submodules is to be changed, to make it easier to do the right thing, but this is a separate topic. --- Some thoughts on the matter. Doing it in this thread because I do not have a concrete proposal yet to grant a useful conversation. Although, bringing some points on the table will help to understand the situation better. Part of the issue is that we don't use submodules and configuration correctly. When we did an initial transition from Subversion to Git the `ignore = all` meant that the submodule is ignored for both DIFF and STAGE family of Git commands. But! This is how code worked, not how it was documented. After some time the Git code got fixed to follow documentation. That's why we now have lots of submodule changes committed. The current state is very confusing: git status/diff will not show changes in the submodules, but git add and git commit will make it so changes are very easy to land to the official repository. One thing we can/should do is to remove the `ignore = all` setting, so that it is at least visible what is in the commit. Maybe add a post-receive check about submodules on the server? But how to make it so it's easy to commit still? Ask everyone to never stage submodules? Don't think this is a good solution. Maybe make an easy-to-install local hook which will do some unstage magic for the submodules? Anyway, so for the topic of commit revertal I do not think submodules change should be reverted simply because our current setup feels messy and unfriendly. If someone feels like looking into a solution, I suggest moving this matter to a separate ML thread, to keep discussions more focused. Best regards, - Sergey - Sergey Sharybin - ser...@blender.org - www.blender.org Principal Software Engineer, Blender Buikslotermeerplein 161, 1025 ET Amsterdam, the Netherlands On Wed, Jun 9, 2021 at 6:20 PM Howard Trickey via Bf-committers < bf-committers@blender.org> wrote: > Speaking of that error -- submodules changed by mistake -- what is the best > practice to avoid that? My GSoC mentee was asking about that, and I told > him > what I do, but it seems clunky and there is probably a better way. > > What I do: > 1) make sure I've used "make update" or something similar to ensure that > the > submodules are up to date > 2) when I "git add" files, I always add explicitly, one by one, only those > files > that "git status" shows I've changed. In other > > Is there something easier than (2)? > > On Wed, Jun 9, 2021 at 7:46 AM Jeroen Bakker via Bf-committers < > bf-committers@blender.org> wrote: > > > A common reason why I revert commits is that submodules were changed by > > mistake. Is reverting a good solution? Perhaps worth mentioning. > > > > Jeroen > > > > > > On Wed, Jun 9, 2021 at 12:55 PM Sergey Sharybin via Bf-committers < > > bf-committers@blender.org> wrote: > > > > > Hi, > > > > > > Today I continued to update the development process guidelines and > > policies > > > on the Wiki. This is based on previous discussions with the other > > > bf-admins, and I'm working with Dalai on the final text adjustments. So > > > today we handled the "polemic" topic of reverting commits: > > > https://wiki.blender.org/wiki/Process/Revert_Commit > > > > > > Feedback and suggestions are welcome. > > > > > > Please note that we do read the feedback you are giving. Currently we > are > > > focusing on finishing the first pass of the process update. We will > then > > > look into addressing your feedback to make the development process fun > > and > > > smooth! > > > > > > Best regards, > > > - Sergey - > > > > > > Sergey Sharybin - ser...@blender.org - www.blender.org > > > Principal Software Engineer, Blender > > > Buikslotermeerplein 161, 1025 ET Amsterdam, the Netherlands > > > ___ > > > Bf-committers mailing list > > > Bf-committers@blender.org > > > https://lists.blender.org/mailman/listinfo/bf-committers > > > > > ___ > > Bf-committers mailing list > > Bf-committers@blender.org > > https://lists.blender.org/mailman/listinfo/bf-committers > > > ___ > Bf-committers mailing list > Bf-committers@blender.org > https://lists.blender.org/mailman/listinfo/bf-committers > ___ Bf-committers mailing list Bf-committers@blender.org https://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] Harmonious collaboration - reverting commit process
Hi, Today I continued to update the development process guidelines and policies on the Wiki. This is based on previous discussions with the other bf-admins, and I'm working with Dalai on the final text adjustments. So today we handled the "polemic" topic of reverting commits: https://wiki.blender.org/wiki/Process/Revert_Commit Feedback and suggestions are welcome. Please note that we do read the feedback you are giving. Currently we are focusing on finishing the first pass of the process update. We will then look into addressing your feedback to make the development process fun and smooth! Best regards, - Sergey - -------- Sergey Sharybin - ser...@blender.org - www.blender.org Principal Software Engineer, Blender Buikslotermeerplein 161, 1025 ET Amsterdam, the Netherlands ___ Bf-committers mailing list Bf-committers@blender.org https://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Simple steps to get an harmonious collaboration
Campbell, those are valid points, but here is what I propose: (a) Focus on making already-agreed-on topics public, go into more specific cases later. (b) Until the future of the Phabricator is known, do not spend too much time in finding Phabricator-specific solutions for the cases we want to cover. Ray, the overall goal is to align the development process across the team, to make expectations and ways of working match better. I was typing replies to the notes you're bringing, but it started to be a bit lengthy and started to hide the point we are bringing up here. The best way I can describe it is that one needs to be more open-hearted and open-minded when reading the guidelines we've put on wiki. Look at them from an angle "how this improves overall team development experience/process". Best regards, - Sergey - -------- Sergey Sharybin - ser...@blender.org - www.blender.org Principal Software Engineer, Blender Buikslotermeerplein 161, 1025 ET Amsterdam, the Netherlands On Wed, Jun 2, 2021 at 9:22 AM Ray Molenkamp via Bf-committers < bf-committers@blender.org> wrote: > I'm somewhat confused on the goal some of the (proposed?) rules. > But I'll just pick on the "Patch description should match the > commit message."-rule for now not to make this longer than it > needs to be. > > Most people are much more verbose in their patch description, > some have visual aids (images/clips), benchmark results, and > perhaps test files attached to them. Rich content is possible > and often used. > > While commit messages are a much more somber endeavor, no rich > content and strict requirements on the formatting (50 chars > for the first line ie) > > The guidance we offer for what should be in a patch [1] > and what should be in a commit message [2] also paint two > rather different pictures. > > Personally, I welcome justifications in a diff on al the ways the > problem could have been solved, but were ultimately not chosen for > reason X, Y or Z. While in commit messages I honestly only care for > "what does it do, how does it do it" when I'm bisecting I have > no interest whatsoever in learning about all the ways a certain > commit doesn't solve the issue. > > Patch descriptions and commit messages just seem fundamentally > different things, and I struggle a bit on seeing why unifying > the two would be a "good thing" > > I have similar concerns with many of the other rules on this list, > most seem perfectly fine rules on first sight, but without a clear > justification on how they contribute to.. [check notes] .. "harmonious > collaboration in the code review platform", its just a list of > seemingly oddball rules, I could add a "keyboard layout must be > set to dvorak while typing patch description" rule and it wouldn't > even look out of place. > > --Ray > > [1] > https://wiki.blender.org/wiki/Process/Contributing_Code#Ingredients_of_a_Patch > [2] https://wiki.blender.org/wiki/Style_Guide/Commit_Messages > > > On 2021-06-01 5:05 a.m., Sergey Sharybin via Bf-committers wrote: > > Hi, > > > > Just a quick note. The bf-admin team worked on several process related > > documents to ensure a pleasant and efficient development process. > > > > Today we've updated wiki with the patch review process: > > https://wiki.blender.org/wiki/Process/Patch_Review > > > > Feedback is welcome. > > > > Best regards, > > - Sergey - > > > > Sergey Sharybin - ser...@blender.org - www.blender.org > > Principal Software Engineer, Blender > > Buikslotermeerplein 161, 1025 ET Amsterdam, the Netherlands > > ___ > > Bf-committers mailing list > > Bf-committers@blender.org > > https://lists.blender.org/mailman/listinfo/bf-committers > ___ > Bf-committers mailing list > Bf-committers@blender.org > https://lists.blender.org/mailman/listinfo/bf-committers > ___ Bf-committers mailing list Bf-committers@blender.org https://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] Simple steps to get an harmonious collaboration
Hi, Just a quick note. The bf-admin team worked on several process related documents to ensure a pleasant and efficient development process. Today we've updated wiki with the patch review process: https://wiki.blender.org/wiki/Process/Patch_Review Feedback is welcome. Best regards, - Sergey - Sergey Sharybin - ser...@blender.org - www.blender.org Principal Software Engineer, Blender Buikslotermeerplein 161, 1025 ET Amsterdam, the Netherlands ___ Bf-committers mailing list Bf-committers@blender.org https://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] Deprecation of Phabricator
Hi, Just wanted to let everyone know that today Phacility announced that development of Phabricator is phasing out [1] [2]. This does not affect the Blender project immediately, but we need to find a solution to the situation (be it a fork of Phabricator, or be it a migration to some other platform). There is no plan of action yet, it will be looked into in the coming time. We will keep you posted with updates on the topic. Would like to mention that Sebastian Parborg together with Dalai are working on a plan of action. At some point we'll share it with Blender developers, triagers, and the community. So don't be surprised :) [1] https://admin.phacility.com/phame/post/view/11/phacility_is_winding_down_operations/ [2] https://secure.phabricator.com/ Best regards, - Sergey - Sergey Sharybin - ser...@blender.org - www.blender.org Principal Software Engineer, Blender Buikslotermeerplein 161, 1025 ET Amsterdam, the Netherlands ___ Bf-committers mailing list Bf-committers@blender.org https://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] Code quality day changes
Hi everyone, We have been doing the quality day for a few months already. The idea was to motivate and facilitate all the modules to solve technical debts in their code. Unfortunately, this didn't quite work that great. While there were some nice improvements in localized areas, it didn't work out as an activity, scheduled for an entire team. The new proposal goes as: it is up to the module to choose when it is the most suitable to do quality improvement activities. In practice this means that from a modules' perspective schedule is more flexible and they can organize themselves in a more efficient way. Everyone is welcome to join this Friday's quality activities, but it will not be broadcastly announced or centrally managed. Best regards, - Sergey - Sergey Sharybin - ser...@blender.org - www.blender.org Principal Software Engineer, Blender Buikslotermeerplein 161, 1025 ET Amsterdam, the Netherlands ___ Bf-committers mailing list Bf-committers@blender.org https://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] Code Quality Day - 5/March
Hi, This Friday we have February's code quality day [1]. For the Clang-Tidy project we'll come up with a decision on which warnings we still want to address and support. ANd I would really like to see the WIP patches to be either finished or officially stated that we do not want to address the warning. The goal is: finalize the project! Note that there are still a lot of things to do from [2]. There are a couple of new entries there added since the previous quality day. There are also a lot of quality improvements possible in many areas which are not listed in the document. I would encourage all module owners and members to work on quality improvements in their areas! Best regards and see you all tomorrow! - Sergey - [1] - https://wiki.blender.org/wiki/Style_Guide/Code_Quality_Day [2] - https://developer.blender.org/T73586 Sergey Sharybin - ser...@blender.org - www.blender.org Principal Software Engineer, Blender Buikslotermeerplein 161, 1025 ET Amsterdam, the Netherlands ___ Bf-committers mailing list Bf-committers@blender.org https://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] Clang-Tidy: Request for Feedback
Hi, During the past months we seem to cover the majority of the warnings from Clang-Tidy [1]. The remaining onbes either require a newer Clang-Tidy version, or have a patch, or are a bit controversial than it originally looked. I would say we have reached the point where we can declare the Clang-Tidy project as a "maintenance" -- there are always things to get addressed for new versions or new warnings in the code, but there is no need to keep it an ongoing project. One of the open topics is that modification of .clang-tidy file does not cause full source recompilation. Personally, I do not think this is a huge problem: the file is not being edited that often, and it is similar to the .clang-format. And there is an advantage to having the warnings defined in the file: it is easier to "override" or port them to different areas of Blender. So to me it seems the corresponding point in the T78535 we can just ignore. So here are some questions to the developers: - Do you have a strong feeling about leaving a .clang-tidy file as it is now (where file modification requires manual re-compilation) ? - What do you think we still need to do before we can call the project done? - Shall we enable it by default? Maybe for `make developer` ? - Any other relevant feedback? [1] https://developer.blender.org/T78535 Best regards, - Sergey - ---- Sergey Sharybin - ser...@blender.org - www.blender.org Principal Software Engineer, Blender Buikslotermeerplein 161, 1025 ET Amsterdam, the Netherlands ___ Bf-committers mailing list Bf-committers@blender.org https://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] Code Quality Day - 5/Feb
Hi, This Friday we have February's code quality day [1]. The full list of approved projects for the quality day is combined in a dedicated task [2]. There are few remaining warnings from Clang-Tidy to be addressed for code modernization [3]. Is time for us to look into how to make Clang-Tidy to fit into a regular development process. Volunteers to help make it a smooth integration are welcome! It has been a while since last quality Friday for me, so I need to catch up a bit with the current state. For the time being I'd encourage modules to look into their specific areas and tackle everything they find a quality improvement. Let's stay in touch tomorrow in #blender-coders in blender.chat! We'll sure find plenty of things to address! Everyone is welcome to help! [1] - https://wiki.blender.org/wiki/Style_Guide/Code_Quality_Day [2] - https://developer.blender.org/T73586 [3] - https://developer.blender.org/T78535 Have fun tomorrow, -Sergey- Sergey Sharybin - ser...@blender.org - www.blender.org Principal Software Engineer, Blender Buikslotermeerplein 161, 1025 ET Amsterdam, the Netherlands ___ Bf-committers mailing list Bf-committers@blender.org https://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] Code Quality Day - 4/Dec
Hi, This Friday we have December's code quality day [1]. The full list of approved projects for the quality day is combined in a dedicated task [2]. Last day we finished what one might consider essential Clang-Tidy integration warnings. There are now modernize category warnings enabled, which helps us bring code to 2020 standards [3]. From the last day there is still [4]. It was partially tackled, but there are still some ideas which can end up in a nice quality improvement. There are again some ideas I have in mind of improving the build process. Let's talk about it tomorrow! I would also encourage every module to come with ideas (and solutions ;) to what they consider a quality/technical-depth improvement! Everyone is welcome to help! For feedback on what to do, code review, and everything else we should use #blender-coders in blender.chat. [1] - https://wiki.blender.org/wiki/Style_Guide/Code_Quality_Day [2] - https://developer.blender.org/T73586 [3] - https://developer.blender.org/T78535 [4] - https://developer.blender.org/P1756 Have fun tomorrow, -Sergey- Sergey Sharybin - ser...@blender.org - www.blender.org Principal Software Engineer, Blender Buikslotermeerplein 161, 1025 ET Amsterdam, the Netherlands ___ Bf-committers mailing list Bf-committers@blender.org https://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Support for 32-bit architectures
Hi, I think Sybren will bring some points here, so I will try not to interfere with those to not create too much noise here. One thing which I am missing here is what is the recovery checklist? Mistakes do happen, how can they be efficiently addressed/resolved? Regards, -Sergey- Sergey Sharybin - ser...@blender.org - www.blender.org Principal Software Engineer, Blender Buikslotermeerplein 161, 1025 ET Amsterdam, the Netherlands On Mon, Nov 16, 2020 at 5:58 PM Brecht Van Lommel via Bf-committers < bf-committers@blender.org> wrote: > The difference is between: > * Providing active support for a processor architecture > * Rejecting or fixing code that only builds on a specific processor > architecture > > Developers should not write code which e.g. relies on pointers being 64 > bit, integers being little-endian, or adding an x86_64 intrinsic call > without the appropriate #ifdefs. That's not something you should wait on > the community to fix. It's a bug in your code, like a null pointer > dereference or invalid memory access. > > > On Mon, Nov 16, 2020 at 4:55 PM Ray Molenkamp via Bf-committers < > bf-committers@blender.org> wrote: > > > I've always understood our position to be > > > > - We do not plan to break or remove 32 bit support. > > - Given we don't CI on 32 bit anymore, breakage can sometimes happen > > without us knowing. > > - If external parties supply patches to fix such breakage and they pass > > code review, we merge them. Even if they are for platforms we ourselves > do > > not ship. D2860 (haiku OS) is a nice example there. > > > > I'm not sure if that is the official position, but that's my current > > understanding of it. > > > > --Ray > > > > On 2020-11-16 8:36 a.m., Sybren A. Stüvel via Bf-committers wrote: > > > Hello list, > > > > > > Blender 2.80 was the last version of Blender for which 32-bit builds > > > were officially supported. This was announced by Brecht in [1]. > > > That announcement was a bit unclear to me, which I let pass because it > > > wasn't that relevant for my position back then. However, now that I'm > > > the Linux platform maintainer, I wouldn't mind if the situation was > > > clarified. > > > > > > In that announcement, Brecht writes: > > >> Blender 2.80 was the last release where we officially support 32 bit > > Windows and Linux builds. [...] > > >> We will continue to support it to the level that we do for example > ARM. > > That is we keep the Blender code working independent of the processor > > architecture, particularly for Linux packages. But we don't actively test > > them or release our own builds. > > > This sounds like an impossibility to me: the promise that we keep > > > things working, but without building, or testing. Apparently there is > > > also a distinction between "official support" and "support to some > > > level". > > > > > > The Blender requirements page [2] does list 64-bit as a requirement. > > > But, there is no "last version that supported 32-bit" in the "Previous > > > Versions" section of that page. Also there is no mention of dropping > > > official support for 32-bit architectures in the 2.81 release notes > > > [3]. > > > > > > I found out about this unclear situation when looking at a patch that > > > ought to fix an issue on 32-bit platforms [4]. In the discussion on > > > that patch, Brecht writes: > > >> When writing or reviewing code, you ensure that there is always a > > processor architecture independent code path. And if you get a report and > > it turns out such a code path is missing or broken, you fix it. It's the > > same for x86, mips, sparc, etc. > > > This looks like a statement that these platforms are still supported. > > > > > > Personally I would summarize the above as: > > > - Blender Foundation does not provide buildbots for 32-bit platforms. > > > - Developers have to ensure these platforms keep working. > > > - Testing such fixes is unnecessary. > > > > > > I think I'm misunderstanding the situation here, and I wouldn't mind > > > if this was clarified. > > > > > > Sybren > > > > > > [1]: > > > https://lists.blender.org/pipermail/bf-committers/2019-August/050124.html > > > [2]: https://www.blender.org/download/requirements/ > > > [3]: https://wiki.blender.org/wiki/Reference/Release_Notes/2.81 > > >
Re: [Bf-committers] Code Quality Day - 6/Nov
Hi, Thought to give a quick update of what happened today. - A lot of all-around cleanup From Campbell - Jacques continued working on moving Blend I/O to IDType - Sergey did various Clang-Tidy warnings - Sybren looked into using Blender's C++ container types in Alembic/USD. Turned out to be more tricky than it sounds. Moved to Clang-Tidy related tasks. - Sebastian Barschkis did general cleanup of fluid API - Richard was working on solving ambiguity in frame variables naming in sequencer. One of the outcomes of Clang-Tidy tasks is that within the current version of Clang-Tidy all readability and bugprone warnings on Linux are solved. The new category of modernize warnings has been enabled! Myself, Sybren, and Jacques handled some of the modernize warnings already. I've also put some new ideas, currently under a text file: https://developer.blender.org/P1756 Would be nice to talk about them with developers from modules and either accept them officially or discard them. Most likely I've missed someone's contribution. There were a lot of commits happening, a lot of work which kept away from looking into mail. Feel free to send a followup here with your details. On Thu, Nov 5, 2020 at 3:53 PM Sergey Sharybin wrote: > Hi, > > This Friday we have November's code quality day [1]. > > The current progress is nicely written up by Dalai in the blog post [2]. > > The full list of approved projects for the quality day is combined in a > dedicated task [3]. > Smaller and isolated projects are to tackle Clang-Tidy [4]. We need to > wrap those up and enable possibly Clang-Tidy by default for developers! > > There are bigger impact projects I have in mind, but was preoccupied an > entire week with other tasks and didn't have time to properly add them to > the T73586. Suggest we all talk tomorrow morning and see which of the > bigger projects and tasks we want to be tackled. > > Everyone is welcome to help! > > For feedback on what to do, code review, and everything else we should use > #blender-coders in blender.chat. > > [1] - https://wiki.blender.org/wiki/Style_Guide/Code_Quality_Day > [2] - https://code.blender.org/2020/11/code-quality-day/ > [3] - https://developer.blender.org/T73586 > [4] - https://developer.blender.org/T78535 > > Have fun tomorrow, > -Sergey- > > -- > With best regards, Sergey Sharybin > -- With best regards, Sergey Sharybin ___ Bf-committers mailing list Bf-committers@blender.org https://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] Code Quality Day - 6/Nov
Hi, This Friday we have November's code quality day [1]. The current progress is nicely written up by Dalai in the blog post [2]. The full list of approved projects for the quality day is combined in a dedicated task [3]. Smaller and isolated projects are to tackle Clang-Tidy [4]. We need to wrap those up and enable possibly Clang-Tidy by default for developers! There are bigger impact projects I have in mind, but was preoccupied an entire week with other tasks and didn't have time to properly add them to the T73586. Suggest we all talk tomorrow morning and see which of the bigger projects and tasks we want to be tackled. Everyone is welcome to help! For feedback on what to do, code review, and everything else we should use #blender-coders in blender.chat. [1] - https://wiki.blender.org/wiki/Style_Guide/Code_Quality_Day [2] - https://code.blender.org/2020/11/code-quality-day/ [3] - https://developer.blender.org/T73586 [4] - https://developer.blender.org/T78535 Have fun tomorrow, -Sergey- -- With best regards, Sergey Sharybin ___ Bf-committers mailing list Bf-committers@blender.org https://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] Code Quality Day - 4/Sept
Hi, This Friday we have September's code quality day [1]. The purpose of this day is to solve long-standing technical debt, and to deploy new techniques and tools to help our work as developers. Over time these practices should naturally be incorporated in the day-to-day code. But the old code is nice to take the time for house cleaning. We will carry on with the Clang-Tidy project [2], which is getting close to be finished for its minimal core integration! Tomorrow we will look into extending the rules with the modernize category. The full(er) list of proposed tasks can be found ar [3]. There are also possible quality improvements in the per-module basis. Everyone is welcome to help! For feedback on what to do, code review, and everything else we should use #blender-coders in blender.chat. [1] - https://wiki.blender.org/wiki/Style_Guide/Code_Quality_Day [2] - https://developer.blender.org/T78535 [3] - https://developer.blender.org/T73586 Have fun tomorrow, -Sergey- -- With best regards, Sergey Sharybin ___ Bf-committers mailing list Bf-committers@blender.org https://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] Code Quality Day - 7/Aug
Hi, This Friday we have August's code quality day [1]. The purpose of this day is to solve long-standing technical debt, and to deploy new techniques and tools to help our work as developers. Over time these practices should naturally be incorporated in the day-to-day code. But the old code is nice to take the time for house cleaning. We will carry on with the Clang-Tidy project [2], which is about half-way through from what we plan to be its minimal core integration! A small teaser, once we are done with the "core" warnings, we will unlock the "modernize" class of Clang-Tidy warnings which will help bring the code to a more modern state! If someone is less enthusiastic about doing "boring" code cleanup, there is an entry in the tracker with all the other proposed tasks [3]. And everyone is welcome to help! For feedback on what to do, code review, and everything else we should use #blender-coders in blender.chat. [1] - https://wiki.blender.org/wiki/Style_Guide/Code_Quality_Day [2] - https://developer.blender.org/T78535 [3] - https://developer.blender.org/T73586 Have fun tomorrow, -Sergey- -- With best regards, Sergey Sharybin ___ Bf-committers mailing list Bf-committers@blender.org https://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] C++ standard has been upgraded to C++17
Hi, The C++ standard used by Blender has been raised to C++17. This allows developers to use newly introduced features in the language [1]. We are still compliant with the VFX platforms, since there are no binary plugins in Blender, and the precompiled external libraries will not go above C++14. [1] https://developer.blender.org/T76783 -- With best regards, Sergey Sharybin ___ Bf-committers mailing list Bf-committers@blender.org https://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] Buildbot is updated is out of maintenance!
Hi everyone, Just a quick note that after a few days of work the Buildbot is considered to be back to regular business! So what did change? All the workers which are compiling latest Git sources are now at the latest available toolchains for their platforms. This allows us to process further with C++17 update as per [1]. [1] https://developer.blender.org/T76783 -- With best regards, Sergey Sharybin ___ Bf-committers mailing list Bf-committers@blender.org https://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Embree library update to 3.8.0
Hi, Linux is done as well. On Fri, Feb 14, 2020 at 9:14 PM Ray Molenkamp wrote: > Windows is done! > > Tracking ticket in : https://developer.blender.org/T73819 > > --Ray > > On 2020-02-14 11:19 a.m., Stefan Werner wrote: > > Hello platform maintainers, > > > > I updated the Embree version for `make deps` and install_deps.sh to > 3.8.0. > > Please update the binaries when you get a chance. > > > > Currently, there is no code in Blender that requires this new version > yet. Once updated binaries for all the platforms are available, I will > check in features that require the newer Embree library (D6575). > > > > -Stefan > > ___ > > Bf-committers mailing list > > Bf-committers@blender.org > > https://lists.blender.org/mailman/listinfo/bf-committers > ___ > Bf-committers mailing list > Bf-committers@blender.org > https://lists.blender.org/mailman/listinfo/bf-committers > -- With best regards, Sergey Sharybin ___ Bf-committers mailing list Bf-committers@blender.org https://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Mantaflow landing and unit tests.
Hi, There seems to be deeper issues than setting up new fluid scene for the regression test, and its solution was dragging for too long. So I have disabled the test which was failing. Next week when Sebastian is back to the office we will see if we can support fluid velocity for 2.82. On Fri, Jan 3, 2020 at 7:27 PM Ray Molenkamp wrote: > > One cruel thing i can think about is to force everyone to pay more > > attention is to prevent new build from being uploaded if regression tests > > are failing. We'll hear very quickly from users that there are no new > > builds on buildbot. > Cruel or not, It'll cost less resources to deal with > a single well defined test case, rather than triaging > and managing an unknown number of tickets that may > come from the same issue. I don't mind this idea *at all* > > --Ray > > ___ > Bf-committers mailing list > Bf-committers@blender.org > https://lists.blender.org/mailman/listinfo/bf-committers > -- With best regards, Sergey Sharybin ___ Bf-committers mailing list Bf-committers@blender.org https://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Blender developer meeting notes - 2020.1.6
Hi, > Original plan is to move to bcon3 this Thursday (9/1) Regressions tests are to be passing prior to this. Do we consider fluids officially broken and disable the test? > Pablo Dobarro mention that if the multires fix are not planned for 2.82 he suggests lowering the priority for review all other pending sculpt related patches Which exact multires fix? T58473? It does not affect the way sculpting tools interact with multires and i don't see how that's a stopper for improvements in the area. If it's a bottleneck, feel free to pick the task up and work on a solution. On Mon, Jan 6, 2020 at 7:45 PM Dalai Felinto wrote: > Hi all, > > Here are the notes from today's developer meeting. Next meeting is Monday, > 13 January 10:00 CET / 9:00 UTC, in #blender-coders onblender.chat. > > For the complete report read it on: > https://devtalk.blender.org/t/6-january-2020/11123 > > Announcements > = > * Starting this year/January, we now have Richard Antalik working fulltime > :) (triaging at first, drifting towards VSE) > * Tracker curfew is ongoing, devs remember to untag tasks from the > #tracker-curfew project after triaging (move them to bug or known issue( > /fixing them > > Blender 2.82 bcon3 > === > * Original plan is to move to bcon3 this Thursday (9/1) > * Grease Pencil / annotation patch needs review by then - D6467 > * Lukas Stockner says at least one UDIM patch needs review, specially the > Eevee/Workbench patch (D6456) - other patches: D6465 (simple), D6492 > (packing, more complex, not priority) - Clement will try to look at it > * Lukas will also work in UDIM manual in the coming days > * Pablo Dobarro wants the IK pose brush (D6389) to be in bcon3 > > Blender 2.83 bcon1 > === > * Just a reminder that we then also start 2.83 bcon1 this week > * Time when consider what to schedule in the modules roadmaps let's > remember of the tracker curfew > (so devs are expected to work 2 full days a week with bug triaging, fixing > and patch review) > This will impact the inflow of new features, but it is temporary > > Other > = > * Pablo Dobarro mention that if the multires fix are not planned for 2.82 > he suggests lowering the priority for review all other pending sculpt > related patches > * Ray Molenkamp reminds every to run unittests > * Happy 2020! > > Regards, > Dalai > ___ > Bf-committers mailing list > Bf-committers@blender.org > https://lists.blender.org/mailman/listinfo/bf-committers > -- With best regards, Sergey Sharybin ___ Bf-committers mailing list Bf-committers@blender.org https://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Mantaflow landing and unit tests.
t wishes, > > Sebastián > > > >> On 2. Jan 2020, at 22:31, Ray Molenkamp wrote: > >> > >> All, > >> > >> Hate to be a heckler for running the unit tests, but please: > >> > >> When you land and/or review something big, RUN THE UNIT TESTS! > >> > >> When the monster 10 patch mantaflow patch landed, it broke > >> 6 cycles unit tests on all platforms, 5 with different renders > >> than the reference images and one full on blender crash [1] > >> > >> bda4a284d20164fec2433f7c40f49fc903319400 [2] fixed the render > >> differences and turned the crash into a render difference [3] > >> > >> Unrelated side note: whats with the less than helpful > >> commit message on this commit? it may as well have been > >> committed with the message 'something fluid' or 'Tuesday' > >> would have just as enlightening for other developers. > >> > >> To summarize: > >> > >> - The person submitting the patches has not run the tests > >> - The reviewers have not run the tests > >> - Less than optimal commit messages > >> - 18!! days after landing, there is still a failing test > >> > >> Holiday season or not: I think we can and should do better than this > >> > >> --Ray > >> > >> [1] https://i.imgur.com/LE3baOg.png > >> [2] > https://developer.blender.org/rBbda4a284d20164fec2433f7c40f49fc903319400 > >> [3] https://i.imgur.com/5we0hEv.png > >> > >> > >> _______ > >> Bf-committers mailing list > >> Bf-committers@blender.org > >> https://lists.blender.org/mailman/listinfo/bf-committers > > ___ > > Bf-committers mailing list > > Bf-committers@blender.org > > https://lists.blender.org/mailman/listinfo/bf-committers > ___ > Bf-committers mailing list > Bf-committers@blender.org > https://lists.blender.org/mailman/listinfo/bf-committers > -- With best regards, Sergey Sharybin ___ Bf-committers mailing list Bf-committers@blender.org https://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] Paying attention to regression tests
Hi, I would like to ask developers to have closer attention to regression tests. Run regression suit before you push changes to master. If test fails investigate why. If it's really expected change update the test. If it's unexpected, fix the code. If it's unrelated to the changes either investigate what's going on, or pass it to the responsible module members. The following document should help having a setup [1]. Also keep an eye on the builds and tests happening on buildbot [2] to catch possible regressions on other platforms. [1] https://wiki.blender.org/wiki/Tools/Tests/Setup [2] https://builder.blender.org/admin/#/builders -- With best regards, Sergey Sharybin ___ Bf-committers mailing list Bf-committers@blender.org https://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Blender 2.81a: Revisions to backport
Hi, There are extra revisions added to the 'a' release after discussion in blender.chat. Those are now all ported and documented in the release notes: https://wiki.blender.org/wiki/Reference/Release_Notes/2.81/a Think we are ready for builds. Will start doing it in about 1.5 hours if nothing pops out. On Tue, Dec 3, 2019 at 2:44 PM Sergey Sharybin wrote: > Hi again! > > Sorry for the spam, but need to keep the release team in sync. > > Added: > - 4a440ecb99d Fix T72071: Crash on snap to edge > - ed5b81f5 Fix T71678: Rigify crash if the Advanced mode is set to New. > > Thing to cover still: > - Wouldn't mind having a second eye on the branch to verify everything is > good and that nothing is missing. > - Adjust release notes page. > > Updated list: > Blender: > - 4e42a98edd8 Fix T71147 Eevee stops rendering after selection attempt > - f1ac64921b4 Fix T71213: Mask or Mirror before Armature breaks weight > paint > - aadbb794cd6e Fix T71612: Viewport rotate doesn't work > - 8cb55f8d1672 Fix T71741: Crash showing the object relations menu > - a8d29ad6e06 Fix T71558: Hair particles: Brush effect not occluded by > emitter geometry > - 73ce35d3325 Fix segfault when polling `MESH_OT_paint_mask_extract` > - bdfcee347eb Fix T71864: Broken 'Select' > 'More' in face mode in UV > Editor > - 60e817693ce Fix T69332: 'Reset to Default Value' on a custom string > property crashes > - 4a440ecb99d Fix T72071: Crash on snap to edge > > Addons: > - ee818b2a Fix T71774: SVG import error on specific files > - ed5b81f5 Fix T71678: Rigify crash if the Advanced mode is set to New. > > On Tue, Dec 3, 2019 at 2:11 PM Sergey Sharybin > wrote: > >> Hi, >> >> Just an on-going update. Added to following commits: >> >> - bdfcee347eb Fix T71864: Broken 'Select' > 'More' in face mode in UV >> Editor >> - 60e817693ce Fix T69332: 'Reset to Default Value' on a custom string >> property crashes >> >> Updated list: >> >> Blender: >> - 4e42a98edd8 Fix T71147 Eevee stops rendering after selection attempt >> - f1ac64921b4 Fix T71213: Mask or Mirror before Armature breaks weight >> paint >> - aadbb794cd6e Fix T71612: Viewport rotate doesn't work >> - 8cb55f8d1672 Fix T71741: Crash showing the object relations menu >> - a8d29ad6e06 Fix T71558: Hair particles: Brush effect not occluded by >> emitter geometry >> - 73ce35d3325 Fix segfault when polling `MESH_OT_paint_mask_extract` >> - bdfcee347eb Fix T71864: Broken 'Select' > 'More' in face mode in UV >> Editor >> - 60e817693ce Fix T69332: 'Reset to Default Value' on a custom string >> property crashes >> >> Addons: >> - ee818b2a Fix T71774: SVG import error on specific files >> >> On Tue, Dec 3, 2019 at 12:36 PM Sergey Sharybin >> wrote: >> >>> Hi, >>> >>> Backported "73ce35d3325 Fix segfault when polling >>> `MESH_OT_paint_mask_extract`" as well now. >>> >>> Updated list: >>> >>> Blender: >>> - 4e42a98edd8 Fix T71147 Eevee stops rendering after selection attempt >>> - f1ac64921b4 Fix T71213: Mask or Mirror before Armature breaks weight >>> paint >>> - aadbb794cd6e Fix T71612: Viewport rotate doesn't work >>> - 8cb55f8d1672 Fix T71741: Crash showing the object relations menu >>> - a8d29ad6e06 Fix T71558: Hair particles: Brush effect not occluded by >>> emitter geometry >>> - 73ce35d3325 Fix segfault when polling `MESH_OT_paint_mask_extract` >>> >>> Addons: >>> - ee818b2a Fix T71774: SVG import error on specific files >>> >>> On Tue, Dec 3, 2019 at 10:57 AM Sergey Sharybin >>> wrote: >>> >>>> Hi, >>>> >>>> I've started 'a' release cycle inside of the blender-v2.81-release >>>> branch. >>>> The reason to re-use the branch is just to make it easier for buildbot >>>> and other users of `make update` to properly find libraries (which are >>>> expected to have same tag as the branch name). >>>> The 2.81 release was tagged already, so there isn't really anything to >>>> worry about. >>>> >>>> I've backported the following changes: >>>> >>>> Blender: >>>> - 4e42a98edd8 Fix T71147 Eevee stops rendering after selection attempt >>>> - f1ac64921b4 Fix T71213: Mask or Mirror before Armature breaks weight >>>> paint >>>> - aadbb794cd6e Fix T71612: Viewport rotate doesn't work >>>> - 8cb55f8d1672 Fix T71741: Crash showing the object relations menu >>>>
Re: [Bf-committers] Blender 2.81a: Revisions to backport
Hi again! Sorry for the spam, but need to keep the release team in sync. Added: - 4a440ecb99d Fix T72071: Crash on snap to edge - ed5b81f5 Fix T71678: Rigify crash if the Advanced mode is set to New. Thing to cover still: - Wouldn't mind having a second eye on the branch to verify everything is good and that nothing is missing. - Adjust release notes page. Updated list: Blender: - 4e42a98edd8 Fix T71147 Eevee stops rendering after selection attempt - f1ac64921b4 Fix T71213: Mask or Mirror before Armature breaks weight paint - aadbb794cd6e Fix T71612: Viewport rotate doesn't work - 8cb55f8d1672 Fix T71741: Crash showing the object relations menu - a8d29ad6e06 Fix T71558: Hair particles: Brush effect not occluded by emitter geometry - 73ce35d3325 Fix segfault when polling `MESH_OT_paint_mask_extract` - bdfcee347eb Fix T71864: Broken 'Select' > 'More' in face mode in UV Editor - 60e817693ce Fix T69332: 'Reset to Default Value' on a custom string property crashes - 4a440ecb99d Fix T72071: Crash on snap to edge Addons: - ee818b2a Fix T71774: SVG import error on specific files - ed5b81f5 Fix T71678: Rigify crash if the Advanced mode is set to New. On Tue, Dec 3, 2019 at 2:11 PM Sergey Sharybin wrote: > Hi, > > Just an on-going update. Added to following commits: > > - bdfcee347eb Fix T71864: Broken 'Select' > 'More' in face mode in UV > Editor > - 60e817693ce Fix T69332: 'Reset to Default Value' on a custom string > property crashes > > Updated list: > > Blender: > - 4e42a98edd8 Fix T71147 Eevee stops rendering after selection attempt > - f1ac64921b4 Fix T71213: Mask or Mirror before Armature breaks weight > paint > - aadbb794cd6e Fix T71612: Viewport rotate doesn't work > - 8cb55f8d1672 Fix T71741: Crash showing the object relations menu > - a8d29ad6e06 Fix T71558: Hair particles: Brush effect not occluded by > emitter geometry > - 73ce35d3325 Fix segfault when polling `MESH_OT_paint_mask_extract` > - bdfcee347eb Fix T71864: Broken 'Select' > 'More' in face mode in UV > Editor > - 60e817693ce Fix T69332: 'Reset to Default Value' on a custom string > property crashes > > Addons: > - ee818b2a Fix T71774: SVG import error on specific files > > On Tue, Dec 3, 2019 at 12:36 PM Sergey Sharybin > wrote: > >> Hi, >> >> Backported "73ce35d3325 Fix segfault when polling >> `MESH_OT_paint_mask_extract`" as well now. >> >> Updated list: >> >> Blender: >> - 4e42a98edd8 Fix T71147 Eevee stops rendering after selection attempt >> - f1ac64921b4 Fix T71213: Mask or Mirror before Armature breaks weight >> paint >> - aadbb794cd6e Fix T71612: Viewport rotate doesn't work >> - 8cb55f8d1672 Fix T71741: Crash showing the object relations menu >> - a8d29ad6e06 Fix T71558: Hair particles: Brush effect not occluded by >> emitter geometry >> - 73ce35d3325 Fix segfault when polling `MESH_OT_paint_mask_extract` >> >> Addons: >> - ee818b2a Fix T71774: SVG import error on specific files >> >> On Tue, Dec 3, 2019 at 10:57 AM Sergey Sharybin >> wrote: >> >>> Hi, >>> >>> I've started 'a' release cycle inside of the blender-v2.81-release >>> branch. >>> The reason to re-use the branch is just to make it easier for buildbot >>> and other users of `make update` to properly find libraries (which are >>> expected to have same tag as the branch name). >>> The 2.81 release was tagged already, so there isn't really anything to >>> worry about. >>> >>> I've backported the following changes: >>> >>> Blender: >>> - 4e42a98edd8 Fix T71147 Eevee stops rendering after selection attempt >>> - f1ac64921b4 Fix T71213: Mask or Mirror before Armature breaks weight >>> paint >>> - aadbb794cd6e Fix T71612: Viewport rotate doesn't work >>> - 8cb55f8d1672 Fix T71741: Crash showing the object relations menu >>> - a8d29ad6e06 Fix T71558: Hair particles: Brush effect not occluded by >>> emitter geometry >>> >>> Addons: >>> - ee818b2a Fix T71774: SVG import error on specific files >>> >>> Still pending: >>> - T71678 (will ask Alexander to help backporting) >>> - T71576 >>> >>> I would like to have all the changes ready at the end of today and >>> tested until tomorrow. If you are working on something crucial and feel you >>> need more time please let me know. >>> >>> Under investigation >>> - 2d7effc27d8b (think it's safe, but would want to hear from others >>> about their opinion) >>> >>> On Mon, Dec 2, 2019 at 12:37 PM wrote: >>> >>>> I think this is important:htt
Re: [Bf-committers] Blender 2.81a: Revisions to backport
Hi, Just an on-going update. Added to following commits: - bdfcee347eb Fix T71864: Broken 'Select' > 'More' in face mode in UV Editor - 60e817693ce Fix T69332: 'Reset to Default Value' on a custom string property crashes Updated list: Blender: - 4e42a98edd8 Fix T71147 Eevee stops rendering after selection attempt - f1ac64921b4 Fix T71213: Mask or Mirror before Armature breaks weight paint - aadbb794cd6e Fix T71612: Viewport rotate doesn't work - 8cb55f8d1672 Fix T71741: Crash showing the object relations menu - a8d29ad6e06 Fix T71558: Hair particles: Brush effect not occluded by emitter geometry - 73ce35d3325 Fix segfault when polling `MESH_OT_paint_mask_extract` - bdfcee347eb Fix T71864: Broken 'Select' > 'More' in face mode in UV Editor - 60e817693ce Fix T69332: 'Reset to Default Value' on a custom string property crashes Addons: - ee818b2a Fix T71774: SVG import error on specific files On Tue, Dec 3, 2019 at 12:36 PM Sergey Sharybin wrote: > Hi, > > Backported "73ce35d3325 Fix segfault when polling > `MESH_OT_paint_mask_extract`" as well now. > > Updated list: > > Blender: > - 4e42a98edd8 Fix T71147 Eevee stops rendering after selection attempt > - f1ac64921b4 Fix T71213: Mask or Mirror before Armature breaks weight > paint > - aadbb794cd6e Fix T71612: Viewport rotate doesn't work > - 8cb55f8d1672 Fix T71741: Crash showing the object relations menu > - a8d29ad6e06 Fix T71558: Hair particles: Brush effect not occluded by > emitter geometry > - 73ce35d3325 Fix segfault when polling `MESH_OT_paint_mask_extract` > > Addons: > - ee818b2a Fix T71774: SVG import error on specific files > > On Tue, Dec 3, 2019 at 10:57 AM Sergey Sharybin > wrote: > >> Hi, >> >> I've started 'a' release cycle inside of the blender-v2.81-release branch. >> The reason to re-use the branch is just to make it easier for buildbot >> and other users of `make update` to properly find libraries (which are >> expected to have same tag as the branch name). >> The 2.81 release was tagged already, so there isn't really anything to >> worry about. >> >> I've backported the following changes: >> >> Blender: >> - 4e42a98edd8 Fix T71147 Eevee stops rendering after selection attempt >> - f1ac64921b4 Fix T71213: Mask or Mirror before Armature breaks weight >> paint >> - aadbb794cd6e Fix T71612: Viewport rotate doesn't work >> - 8cb55f8d1672 Fix T71741: Crash showing the object relations menu >> - a8d29ad6e06 Fix T71558: Hair particles: Brush effect not occluded by >> emitter geometry >> >> Addons: >> - ee818b2a Fix T71774: SVG import error on specific files >> >> Still pending: >> - T71678 (will ask Alexander to help backporting) >> - T71576 >> >> I would like to have all the changes ready at the end of today and tested >> until tomorrow. If you are working on something crucial and feel you need >> more time please let me know. >> >> Under investigation >> - 2d7effc27d8b (think it's safe, but would want to hear from others about >> their opinion) >> >> On Mon, Dec 2, 2019 at 12:37 PM wrote: >> >>> I think this is important:https://developer.blender.org/rBSa8d29ad6e062 >>> (https://developer.blender.org/rBSa8d29ad6e062) - Fix T71558: Hair >>> particles: Brush effect not occluded by emitter geometry >>> Em Seg, Dez 2, 2019 às 07:17, Sergey Sharybin escreveu: >>> Hi, >>> >>> As agreed in the meeting we are doing a corrective release for 2.81. The >>> plan is to make the builds on Wednesday, December 4. >>> >>> So far the known-to-be-backported revisions are: >>> >>> - 4e42a98edd8 Fix T71147 Eevee stops rendering after selection attempt >>> - f1ac64921b4 Fix T71213: Mask or Mirror before Armature breaks weight >>> paint. >>> >>> There are also annoying regressions which are still under investigation: >>> >>> - https://developer.blender.org/T71576 ( >>> https://developer.blender.org/T71576) >>> - https://developer.blender.org/T71678#818622 ( >>> https://developer.blender.org/T71678#818622) >>> >>> Please review your area and see which of the changes are crucial to have >>> in >>> 2.81a. >>> Keep in mind, we should really stick to the crucial-only. For the >>> nice-to-have there will be 2.82 release quite soon. >>> >>> -- >>> With best regards, Sergey Sharybin >>> ___ >>> Bf-committers mailing list >>> Bf-committers@blender.org (mailto:Bf-committers@blender.org) >>> https://lists.blender.org/mailman/listinfo/bf-committers ( >>> https://lists.blender.org/mailman/listinfo/bf-committers) >>> ___ >>> Bf-committers mailing list >>> Bf-committers@blender.org >>> https://lists.blender.org/mailman/listinfo/bf-committers >>> >> >> >> -- >> With best regards, Sergey Sharybin >> > > > -- > With best regards, Sergey Sharybin > -- With best regards, Sergey Sharybin ___ Bf-committers mailing list Bf-committers@blender.org https://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Blender 2.81a: Revisions to backport
Hi, Backported "73ce35d3325 Fix segfault when polling `MESH_OT_paint_mask_extract`" as well now. Updated list: Blender: - 4e42a98edd8 Fix T71147 Eevee stops rendering after selection attempt - f1ac64921b4 Fix T71213: Mask or Mirror before Armature breaks weight paint - aadbb794cd6e Fix T71612: Viewport rotate doesn't work - 8cb55f8d1672 Fix T71741: Crash showing the object relations menu - a8d29ad6e06 Fix T71558: Hair particles: Brush effect not occluded by emitter geometry - 73ce35d3325 Fix segfault when polling `MESH_OT_paint_mask_extract` Addons: - ee818b2a Fix T71774: SVG import error on specific files On Tue, Dec 3, 2019 at 10:57 AM Sergey Sharybin wrote: > Hi, > > I've started 'a' release cycle inside of the blender-v2.81-release branch. > The reason to re-use the branch is just to make it easier for buildbot and > other users of `make update` to properly find libraries (which are expected > to have same tag as the branch name). > The 2.81 release was tagged already, so there isn't really anything to > worry about. > > I've backported the following changes: > > Blender: > - 4e42a98edd8 Fix T71147 Eevee stops rendering after selection attempt > - f1ac64921b4 Fix T71213: Mask or Mirror before Armature breaks weight > paint > - aadbb794cd6e Fix T71612: Viewport rotate doesn't work > - 8cb55f8d1672 Fix T71741: Crash showing the object relations menu > - a8d29ad6e06 Fix T71558: Hair particles: Brush effect not occluded by > emitter geometry > > Addons: > - ee818b2a Fix T71774: SVG import error on specific files > > Still pending: > - T71678 (will ask Alexander to help backporting) > - T71576 > > I would like to have all the changes ready at the end of today and tested > until tomorrow. If you are working on something crucial and feel you need > more time please let me know. > > Under investigation > - 2d7effc27d8b (think it's safe, but would want to hear from others about > their opinion) > > On Mon, Dec 2, 2019 at 12:37 PM wrote: > >> I think this is important:https://developer.blender.org/rBSa8d29ad6e062 ( >> https://developer.blender.org/rBSa8d29ad6e062) - Fix T71558: Hair >> particles: Brush effect not occluded by emitter geometry >> Em Seg, Dez 2, 2019 às 07:17, Sergey Sharybin escreveu: >> Hi, >> >> As agreed in the meeting we are doing a corrective release for 2.81. The >> plan is to make the builds on Wednesday, December 4. >> >> So far the known-to-be-backported revisions are: >> >> - 4e42a98edd8 Fix T71147 Eevee stops rendering after selection attempt >> - f1ac64921b4 Fix T71213: Mask or Mirror before Armature breaks weight >> paint. >> >> There are also annoying regressions which are still under investigation: >> >> - https://developer.blender.org/T71576 ( >> https://developer.blender.org/T71576) >> - https://developer.blender.org/T71678#818622 ( >> https://developer.blender.org/T71678#818622) >> >> Please review your area and see which of the changes are crucial to have >> in >> 2.81a. >> Keep in mind, we should really stick to the crucial-only. For the >> nice-to-have there will be 2.82 release quite soon. >> >> -- >> With best regards, Sergey Sharybin >> ___ >> Bf-committers mailing list >> Bf-committers@blender.org (mailto:Bf-committers@blender.org) >> https://lists.blender.org/mailman/listinfo/bf-committers ( >> https://lists.blender.org/mailman/listinfo/bf-committers) >> ___ >> Bf-committers mailing list >> Bf-committers@blender.org >> https://lists.blender.org/mailman/listinfo/bf-committers >> > > > -- > With best regards, Sergey Sharybin > -- With best regards, Sergey Sharybin ___ Bf-committers mailing list Bf-committers@blender.org https://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Blender 2.81a: Revisions to backport
Hi, I've started 'a' release cycle inside of the blender-v2.81-release branch. The reason to re-use the branch is just to make it easier for buildbot and other users of `make update` to properly find libraries (which are expected to have same tag as the branch name). The 2.81 release was tagged already, so there isn't really anything to worry about. I've backported the following changes: Blender: - 4e42a98edd8 Fix T71147 Eevee stops rendering after selection attempt - f1ac64921b4 Fix T71213: Mask or Mirror before Armature breaks weight paint - aadbb794cd6e Fix T71612: Viewport rotate doesn't work - 8cb55f8d1672 Fix T71741: Crash showing the object relations menu - a8d29ad6e06 Fix T71558: Hair particles: Brush effect not occluded by emitter geometry Addons: - ee818b2a Fix T71774: SVG import error on specific files Still pending: - T71678 (will ask Alexander to help backporting) - T71576 I would like to have all the changes ready at the end of today and tested until tomorrow. If you are working on something crucial and feel you need more time please let me know. Under investigation - 2d7effc27d8b (think it's safe, but would want to hear from others about their opinion) On Mon, Dec 2, 2019 at 12:37 PM wrote: > I think this is important:https://developer.blender.org/rBSa8d29ad6e062 ( > https://developer.blender.org/rBSa8d29ad6e062) - Fix T71558: Hair > particles: Brush effect not occluded by emitter geometry > Em Seg, Dez 2, 2019 às 07:17, Sergey Sharybin escreveu: > Hi, > > As agreed in the meeting we are doing a corrective release for 2.81. The > plan is to make the builds on Wednesday, December 4. > > So far the known-to-be-backported revisions are: > > - 4e42a98edd8 Fix T71147 Eevee stops rendering after selection attempt > - f1ac64921b4 Fix T71213: Mask or Mirror before Armature breaks weight > paint. > > There are also annoying regressions which are still under investigation: > > - https://developer.blender.org/T71576 ( > https://developer.blender.org/T71576) > - https://developer.blender.org/T71678#818622 ( > https://developer.blender.org/T71678#818622) > > Please review your area and see which of the changes are crucial to have in > 2.81a. > Keep in mind, we should really stick to the crucial-only. For the > nice-to-have there will be 2.82 release quite soon. > > -- > With best regards, Sergey Sharybin > ___ > Bf-committers mailing list > Bf-committers@blender.org (mailto:Bf-committers@blender.org) > https://lists.blender.org/mailman/listinfo/bf-committers ( > https://lists.blender.org/mailman/listinfo/bf-committers) > ___ > Bf-committers mailing list > Bf-committers@blender.org > https://lists.blender.org/mailman/listinfo/bf-committers > -- With best regards, Sergey Sharybin ___ Bf-committers mailing list Bf-committers@blender.org https://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] Blender 2.81a: Revisions to backport
Hi, As agreed in the meeting we are doing a corrective release for 2.81. The plan is to make the builds on Wednesday, December 4. So far the known-to-be-backported revisions are: - 4e42a98edd8 Fix T71147 Eevee stops rendering after selection attempt - f1ac64921b4 Fix T71213: Mask or Mirror before Armature breaks weight paint. There are also annoying regressions which are still under investigation: - https://developer.blender.org/T71576 - https://developer.blender.org/T71678#818622 Please review your area and see which of the changes are crucial to have in 2.81a. Keep in mind, we should really stick to the crucial-only. For the nice-to-have there will be 2.82 release quite soon. -- With best regards, Sergey Sharybin ___ Bf-committers mailing list Bf-committers@blender.org https://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] File VERSION -> MINVERSION
Hi, There is a structure definition in every .blend, which allows to know under which offset what property is stored. Long story short: reading is not just 1:1 mapping of data on disk to data in memory, some remapping of layout will happen based on the data mentioned above when needed. There are some places where you can get some deeper insights of how it happens: - https://archive.blender.org/wiki/index.php/Dev:Source/Architecture/File_Format/ - https://developer.blender.org/diffusion/B/browse/master/doc/blender_file_format/ There is also Python implementation of .blend file reader which can be used to dig into some specifics: https://developer.blender.org/source/blender-file/ On Sun, Dec 1, 2019 at 1:03 AM Holger Machens wrote: > Hi, > > > thank you for your answer, Sergey Sharybin. > > > To summarize: > > MINVERSION refers to the minimum Blender version required to > read that particular file. > > > > I thought about it and then I noticed the following: > > Given the case I described before: Different struct layout in version > 2.80 and 2.81. How does Blender in version 2.80 deal with the changed > struct layout in a file of version 2.81? > > I could think of three options: > > a) Future changes for 2.81 have already been considered in 2.80 and >conversion code exists in blenloader/intern/versioning_2_81.c in >blender 2.80. (probably not) > > b) Blender 2.80 did not use those structs or attributes which >got moved in position, even though those already existed in >that version. > > c) Those structs are used in memory only and get never stored in a >file, even though their type is declared in block DNA1. > > > This question is interesting, because (b) and (c) would also mean, that > (theoretically) data of a .blend file of v2.80 can also be stored in DNA > structs of v2.81 without conversion and without loss of information. > Thus, I could always use a pointer on struct of v2.81 and point it on > data of v2.80 and get the same (old) information. Is that correct? > > > This would have some implications I would like to clarify in my > documentation. That's why I try to get this right. > > > > Kind regards > Holger Machens > > > On 30.11.19 19:58, Sergey Sharybin wrote: > > Hi, > > > > This is a part of forward compatibility (ability to open newer files in > > older Blender versions). > > > > Most of the time opening newer files does what you would expect, but in > > others there is a huge data loss. For example, you can not open 2.8x > files > > in 2.7x because older Blender versions are not aware of Collections, and > > old Layers are not stored in .blend file. > > You can, however, open 2.82 and 2.81 files in Blender 2.80 (there might > be > > minor differences in final render due to changes in shaders, but nothing > > too drastic). > > > > Hence the miniversion of 2.80. > > > > P.S. As far as i remember, it is only used to communicate users that the > > file is too new, and no extra logic on read/write is dependent on the > > miniversion. > > > > On Sat, Nov 30, 2019 at 2:26 PM Holger Machens wrote: > > > >> Hello folks! > >> > >> > >> TLDR question: > >> > >> What is the meaning of the attributes > >> minversion and minsubversion in DNA > >> struct FileGlobal? > >> > >> (ref: source/makesdna/DNA_fileglobal_types.h) > >> > >> > >> > >> Too Long Explanation: > >> > >> I've just updated my Java API (Java .Blend) to reflect recent DNA > >> changes in release 2.81-16. I've noticed, that BLENDER_MINVERSION still > >> refers to release 2.80-0 while some changes in the DNA of release 2.81-x > >> render older files incompatible on a binary level. For example some > >> attributes of structs in the DNA exchanged their position or new > >> attributes were added inbetween existing attributes, which also changes > >> the relative position of other attributes in the data structure. Thus, > >> you cannot just use a pointer to a C struct of version 2.81 to interpret > >> the data of a C struct in version 2.80. But it would have been possible > >> if attributes were only added to the end of a struct only for example. > >> > >> I looked in the source code and read the recent manual but didn't find > >> an explanation regarding the meaning of MINVERSION and MINSUBVERSION. > >> According to my observations, I have to assume, that files in the range > >> from MINVERSION t
Re: [Bf-committers] File VERSION -> MINVERSION
Hi, This is a part of forward compatibility (ability to open newer files in older Blender versions). Most of the time opening newer files does what you would expect, but in others there is a huge data loss. For example, you can not open 2.8x files in 2.7x because older Blender versions are not aware of Collections, and old Layers are not stored in .blend file. You can, however, open 2.82 and 2.81 files in Blender 2.80 (there might be minor differences in final render due to changes in shaders, but nothing too drastic). Hence the miniversion of 2.80. P.S. As far as i remember, it is only used to communicate users that the file is too new, and no extra logic on read/write is dependent on the miniversion. On Sat, Nov 30, 2019 at 2:26 PM Holger Machens wrote: > Hello folks! > > > TLDR question: > > What is the meaning of the attributes > minversion and minsubversion in DNA > struct FileGlobal? > > (ref: source/makesdna/DNA_fileglobal_types.h) > > > > Too Long Explanation: > > I've just updated my Java API (Java .Blend) to reflect recent DNA > changes in release 2.81-16. I've noticed, that BLENDER_MINVERSION still > refers to release 2.80-0 while some changes in the DNA of release 2.81-x > render older files incompatible on a binary level. For example some > attributes of structs in the DNA exchanged their position or new > attributes were added inbetween existing attributes, which also changes > the relative position of other attributes in the data structure. Thus, > you cannot just use a pointer to a C struct of version 2.81 to interpret > the data of a C struct in version 2.80. But it would have been possible > if attributes were only added to the end of a struct only for example. > > I looked in the source code and read the recent manual but didn't find > an explanation regarding the meaning of MINVERSION and MINSUBVERSION. > According to my observations, I have to assume, that files in the range > from MINVERSION to VERSION are not meant to be binary compatible with > each other. On the other hand, Blender can read and translate Blender > files from much older versions than 2.80 for example. Thus, I wonder > what purpose the MINVERSION in the global files structure has. Is it > eventually going to be removed in future releases? > > > > > Thanks in advance > Holger Machens > ___ > Bf-committers mailing list > Bf-committers@blender.org > https://lists.blender.org/mailman/listinfo/bf-committers > -- With best regards, Sergey Sharybin ___ Bf-committers mailing list Bf-committers@blender.org https://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Moving to Python-3.8
Hi, > Given we are formalizing lots of things, perhaps now that module teams are more established we should assign responsibly for the deps they require to them? Well.. Such decisions should be aligned with general Blender policies. And in the case of VFX Reference Platform we don't really have one. What way do we want to go: - Follow versions exactly according to reference platform? - Follow as long as this doesn't hurt Blender development? (and somehow draw the line between we-can-work-this-around vs. we-do-need-to-use-newer-library)? - Only use libc version advertised by the reference platform, making it so Blender release can run in the studio environment? Couple of related statements: - Being a fully static application which has no binary plugin system doesn't mean that diverting from VFX Reference Platform will immediately make Blender unusable in a studio. - Sticking to exact versions from reference platform could slow development down, which might as well be a factor in why Blender isn't be used in a studio. P.S. Shall we continue discussion here or move to T68774? On Fri, Nov 8, 2019 at 3:44 PM Ray Molenkamp wrote: > On 2019-11-08 1:37 a.m., dr. Sybren A. Stüvel wrote: > > > Are there any concrete reasons we stick to those particular versions? Or > > is it just a matter of someone taking the time to update them? > > I don't think we have official rules about this but > the un-official one I have been using for years is: > > Module owners what rely on a dependency can integrate > newer versions and ask for an update of a dep once they > are done on bf-c and the platform devs will take care > of the rest. Previous examples [1][2][3] > > That being said the integration *has* to be done by the > module teams, the platform devs just don't/can't know > every single implementation detail of the 30-40 deps we > rely on. > > Sometimes we get patches that include lib building > support (like embree) which is appreciated but by no means > required, odds are the platform devs for a platform > are better and quicker at scripting deps than a dev > that has never developed on said platform. > > So the barrier for lib updates is a low as I can make it > all you have to do is test the new version works, and ask. > > Given we are formalizing lots of things, perhaps now > that module teams are more established we should > assign responsibly for the deps they require to them? > > --Ray > > [1] > https://lists.blender.org/pipermail/bf-committers/2018-December/049691.html > [2] > https://lists.blender.org/pipermail/bf-committers/2019-June/050006.html > [3] > https://lists.blender.org/pipermail/bf-committers/2019-August/050119.html > ___ > Bf-committers mailing list > Bf-committers@blender.org > https://lists.blender.org/mailman/listinfo/bf-committers > -- With best regards, Sergey Sharybin ___ Bf-committers mailing list Bf-committers@blender.org https://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Phabricator rights lost
Hi, After recent modifications you need to be either an admin or a member of Moderators project to triage reports. This was done to avoid unintended triage which caused reports slipping through the cracks. Added you to moderators now. Will see about covering some other projects as people who can help triaging as well. On Wed, Oct 16, 2019 at 8:50 AM Julien Duroure wrote: > Hello, > > Seems I recently lost rights to change status of tickets in phabricator > (for example changing from need triage by Developper to confirmed). > I still can comment or assigned it. Seems by commit closed it too. > > I used it mainly to manage glTF tickets. > > Regards, > > Julien > ___ > Bf-committers mailing list > Bf-committers@blender.org > https://lists.blender.org/mailman/listinfo/bf-committers > -- With best regards, Sergey Sharybin ___ Bf-committers mailing list Bf-committers@blender.org https://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Should we change the splash image when theversion number changes?
Hi, The way i see the splash screen is something what identifies the release. We shouldn't have two releases or versions with the same splash, and we shouldn't change splash somewhere at the middle or end of a release cycle since that kind of looses the identity of that release. So from this point of view i am all up for changing splash screen in master right after stable branch was done. On Tue, Oct 15, 2019 at 9:52 AM Sybren A. Stüvel wrote: > On 12-10-19 02:42, Stephen Swaney wrote: > > For a development splash, let's just take the last release splash and > overlay > > it with some yellow police tape and Under Construction signs. > > I think a possible downside of having the daily builds marked too much > as "different" could be that it scares people of. If we want to make it > tempting to use daily builds (which helps us find & fix bugs sooner in > the release cycle) we should make it as non-scary as possible. > > -- > Sybren A. Stüvel > > https://stuvelfoto.nl/ > https://stuvel.eu/ > > ___ > Bf-committers mailing list > Bf-committers@blender.org > https://lists.blender.org/mailman/listinfo/bf-committers > -- With best regards, Sergey Sharybin ___ Bf-committers mailing list Bf-committers@blender.org https://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Platform maintainers: new lib + options for FFmpeg
Hi, The Linux buildbot is updated for those changes. On Fri, Oct 4, 2019 at 4:43 PM Sybren A. Stüvel wrote: > Dear platform maintainers, > > I just pushed two commits to master that require some libraries to be > rebuilt. > > - libvpx: is now forced to configure with --enable-vp8 --enable-vp9. > Without this, VP9 wasn't enabled on buildbot builds. > - libopus: was added to add Opus audio support to FFmpeg > - ffmpeg: is build with Opus audio support > > The steps required are: > > - Rerun 'make deps' > - When updating an existing build (rather than building from scratch), > running 'cmake -U FFMPEG_LIBRARIES .` may be required in the build > directory to ensure the FFMPEG_LIBRARIES variable is refreshed to > contain the opus library. > > This is not urgent, but would be nice if it happens relatively soon. > > Thanks, > > Sybren > > > -- > Sybren A. Stüvel > > https://stuvelfoto.nl/ > https://stuvel.eu/ > > ___ > Bf-committers mailing list > Bf-committers@blender.org > https://lists.blender.org/mailman/listinfo/bf-committers > -- With best regards, Sergey Sharybin ___ Bf-committers mailing list Bf-committers@blender.org https://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Upgrade Python 3.7.0 to 3.7.4
I'll take care of Linux on Monday morning. P.S. That is indeed good point of not do many libraries in one go. On Fri, Aug 2, 2019 at 5:13 PM dr. Sybren A. Stüvel wrote: > PS: This is not an urgent needs-to-be-done-on-Friday-afternoon update. > We could decide to defer updating the platform libs a bit and do more > library updates in one go? Then again, if then something breaks it's > harder to tell which library update caused it. > > > On 02-08-19 16:55, dr. Sybren A. Stüvel wrote: > > Dear platform maintainers, > > > > I've just modified versions.cmake and install_deps.sh to install the > > latest version of Python, namely 3.7.4. Please update the platform > > libraries accordingly. > > > > https://developer.blender.org/rB454daf9b6b87d008e66650927109511f1c1befd2 > > > > Kind regards, > > > > Sybren > > > > > -- > Sybren A. Stüvel > > https://stuvelfoto.nl/ > https://stuvel.eu/ > > ___ > Bf-committers mailing list > Bf-committers@blender.org > https://lists.blender.org/mailman/listinfo/bf-committers > -- With best regards, Sergey Sharybin ___ Bf-committers mailing list Bf-committers@blender.org https://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Blender 2.80 Release Candidate 2 AHOY
Hi, Just a quick follow up. The source tree has been tagged. On Fri, Jul 19, 2019 at 10:34 AM Bastien Montagne wrote: > Hi, > > API doc has been updated for RC2 as well. > > Cheers, > Bastien > > On 18/07/2019 16:58, Brecht Van Lommel wrote: > > Hi all, > > > > We are ready for the second Release Candidate for the Blender 2.80 > release. > > > > Information for platform maintainers: > > > > - Build from the blender-v2.80-release branch, SHA > > 38d4483c6a51d70744d5e146dc87f5da8558448d > > - Addons revision: 979298511916b25ec97bb22feb1c06cc9fbc86dd > > - Locale revision: 6625026f62f492dd677f5f29c68b9d70c96fb34b > > - Libraries SVN tag: blender-2.80-release > > > > Suggested name: blender-2.80rc2-. > > > > Put builds to the usual location and let me know when they are ready. > > Tagging will happen soon after all builds are ready. > > > > Thanks, > > Brecht. > > ___ > > Bf-committers mailing list > > Bf-committers@blender.org > > https://lists.blender.org/mailman/listinfo/bf-committers > > > _______ > Bf-committers mailing list > Bf-committers@blender.org > https://lists.blender.org/mailman/listinfo/bf-committers > -- With best regards, Sergey Sharybin ___ Bf-committers mailing list Bf-committers@blender.org https://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Blender 2.80 Release Candidate 1 (re)AHOY
Hi, All the builds are up and tagging has been made. On Thu, Jul 11, 2019 at 5:12 PM Sergey Sharybin wrote: > Hi, > > We've spotted some quite bad issues and crashes which has been fixed since > yesterday, > so we are calling for a re-AHOY of the 2.80 Release Candidate. > > Information for platform maintainers: > > - Build from the blender-v2.80-release branch, SHA > 06312c6d2db8a6d959bed153f76a28f9faf866f8 > - Addons revision: f54338c63ba36cbbe83161c0b3d4d2b1aa01c4a9 > - Locale revision: 38e501b4d7a37d2db0f48d47bdb07c57f3fb9a0d > - Libraries SVN tag: blender-2.80-release > > Suggested name: blender-2.80rc1-. > > Put builds to usual location and let me know when they are ready. > Tagging will happen soon after all builds are ready. > > -- > With best regards, Sergey Sharybin > -- With best regards, Sergey Sharybin ___ Bf-committers mailing list Bf-committers@blender.org https://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] Blender 2.80 Release Candidate 1 (re)AHOY
Hi, We've spotted some quite bad issues and crashes which has been fixed since yesterday, so we are calling for a re-AHOY of the 2.80 Release Candidate. Information for platform maintainers: - Build from the blender-v2.80-release branch, SHA 06312c6d2db8a6d959bed153f76a28f9faf866f8 - Addons revision: f54338c63ba36cbbe83161c0b3d4d2b1aa01c4a9 - Locale revision: 38e501b4d7a37d2db0f48d47bdb07c57f3fb9a0d - Libraries SVN tag: blender-2.80-release Suggested name: blender-2.80rc1-. Put builds to usual location and let me know when they are ready. Tagging will happen soon after all builds are ready. -- With best regards, Sergey Sharybin ___ Bf-committers mailing list Bf-committers@blender.org https://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Blender 2.80 Release Candidate 1 AHOY
Correction for the git branch: blender-v2.80-release Sorry for the noise and confusion. On Wed, Jul 10, 2019 at 6:16 PM Sergey Sharybin wrote: > Hi, > > We are ready for the first Release Candidate for Blender 2.80 release. > > Information for platform maintainers: > > - Build from the blender-2.80-release branch, SHA > 3fe0c32fae20be4146bfa20fe64f56f5716a132b > - Addons revision: f54338c63ba36cbbe83161c0b3d4d2b1aa01c4a9 > - Locale revision: 38e501b4d7a37d2db0f48d47bdb07c57f3fb9a0d > - Libraries SVN tag: blender-2.80-release > > Suggested name: blender-2.80rc1-. > > Put builds to usual location and let me know when they are ready. > Tagging will happen soon after all builds are ready. > > Thanks everybody for the hard work! > > -- > With best regards, Sergey Sharybin > -- With best regards, Sergey Sharybin ___ Bf-committers mailing list Bf-committers@blender.org https://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] Blender 2.80 Release Candidate 1 AHOY
Hi, We are ready for the first Release Candidate for Blender 2.80 release. Information for platform maintainers: - Build from the blender-2.80-release branch, SHA 3fe0c32fae20be4146bfa20fe64f56f5716a132b - Addons revision: f54338c63ba36cbbe83161c0b3d4d2b1aa01c4a9 - Locale revision: 38e501b4d7a37d2db0f48d47bdb07c57f3fb9a0d - Libraries SVN tag: blender-2.80-release Suggested name: blender-2.80rc1-. Put builds to usual location and let me know when they are ready. Tagging will happen soon after all builds are ready. Thanks everybody for the hard work! -- With best regards, Sergey Sharybin ___ Bf-committers mailing list Bf-committers@blender.org https://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] Libraries update: OpenSubdiv 3.4 RC2
Hi, This is a request for platform maintainers to update OpenSubdiv library to 3.4 RC2. All the needed changes are done to versions.cmake. The update is needed to bring fixes for non-manifold and non-regular meshes, which allows us to solve several reports in the tracker. Unfortunately, the final release is not yet available, but there no much changes is expected and we'd better do such rather intrusive changes as early as possible. -- With best regards, Sergey Sharybin ___ Bf-committers mailing list Bf-committers@blender.org https://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] Linux 64 bit builders are moved to CentOS 7
Hi, Nightly 64bit builds are now done using CentOS 7 based environment, which makes it possible to run Blender on any platform which is complaint to VFX reference platform [1]. No functional changes are expected, just means more users can now use Blender. 32bit builds are still done in Debian Stretch based environment, which will fade away with time. P.S. Script which was used to prepare toolchain in CentOS virtual machine: https://developer.blender.org/P1013 [1] https://vfxplatform.com/ -- With best regards, Sergey Sharybin ___ Bf-committers mailing list Bf-committers@blender.org https://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] [Bf-blender-cvs] [5dbda334623] master: Depsgraph API: Allow preserving custom data layers
Hi,
Forgot to alter the commit message: the proper name of argument
is preserve_all_data_layers.
Sorry for the confusion.
On Mon, May 27, 2019 at 11:01 AM Sergey Sharybin
wrote:
> Commit: 5dbda33462349a4ac78f08e8ed4ec7922ca7394f
> Author: Sergey Sharybin
> Date: Fri May 24 14:37:47 2019 +0200
> Branches: master
> https://developer.blender.org/rB5dbda33462349a4ac78f08e8ed4ec7922ca7394f
>
> Depsgraph API: Allow preserving custom data layers
>
> This commit extends dependency graph API with an argument which
> denotes that all custom data layers are to be preserved. This
> forces modifier stack re-evaluation with more inclusive mask.
>
> Far from ideal, since this might fail in certain configurations
> with indirectly used objects which might be missing layers needed
> for the current object evaluation. But this is how it worked for
> a long time, so should be good enough for until more sophisticated
> solution is found.
>
> In order to use this new behavior two things are to be passed:
>
> - Pass keep_all_data_layers=True
> - Pass a valid dependency graph.
>
> The dependency graph is only needed if keep_all_data_layers=True
> and is NOT to be passed if keep_all_data_layers=False.
>
> If keep_all_data_layers=True the dependency graph MUST be passed.
>
> Reviewers: mont29, brecht
>
> Reviewed By: mont29
>
> Maniphest Tasks: T64994, T64794
>
> Differential Revision: https://developer.blender.org/D4940
>
> ===
>
> M intern/cycles/blender/blender_util.h
> M source/blender/blenkernel/BKE_mesh.h
> M source/blender/blenkernel/BKE_object.h
> M source/blender/blenkernel/intern/mesh_convert.c
> M source/blender/blenkernel/intern/object.c
> M source/blender/editors/object/object_bake_api.c
> M
> source/blender/freestyle/intern/blender_interface/BlenderFileLoader.cpp
> M source/blender/makesrna/intern/rna_main_api.c
> M source/blender/makesrna/intern/rna_object_api.c
>
> ===
>
> diff --git a/intern/cycles/blender/blender_util.h
> b/intern/cycles/blender/blender_util.h
> index 972d7296727..69e55d67532 100644
> --- a/intern/cycles/blender/blender_util.h
> +++ b/intern/cycles/blender/blender_util.h
> @@ -75,11 +75,13 @@ static inline BL::Mesh object_to_mesh(BL::BlendData &
> /*data*/,
> * UV are not empty. */
> if (mesh.is_editmode() ||
> (mesh.use_auto_smooth() && subdivision_type ==
> Mesh::SUBDIVISION_NONE)) {
> - mesh = object.to_mesh();
> + BL::Depsgraph depsgraph(PointerRNA_NULL);
> + mesh = object.to_mesh(false, depsgraph);
> }
>}
>else {
> -mesh = object.to_mesh();
> +BL::Depsgraph depsgraph(PointerRNA_NULL);
> +mesh = object.to_mesh(false, depsgraph);
>}
>
> #if 0
> diff --git a/source/blender/blenkernel/BKE_mesh.h
> b/source/blender/blenkernel/BKE_mesh.h
> index c410946f438..54fbda1fa31 100644
> --- a/source/blender/blenkernel/BKE_mesh.h
> +++ b/source/blender/blenkernel/BKE_mesh.h
> @@ -209,11 +209,22 @@ float (*BKE_mesh_vertexCos_get(const struct Mesh
> *me, int *r_numVerts))[3];
> void BKE_mesh_split_faces(struct Mesh *mesh, bool free_loop_normals);
>
> /* Create new mesh from the given object at its current state.
> - * The owner of this mesh is unknown, it is up to the caller to decide. */
> -struct Mesh *BKE_mesh_new_from_object(struct Object *object);
> + * The owner of this mesh is unknown, it is up to the caller to decide.
> + *
> + * If preserve_all_data_layers is truth then the modifier stack is
> re-evaluated to ensure it
> + * preserves all possible custom data layers.
> + *
> + * NOTE: Dependency graph argument is required when
> preserve_all_data_layers is truth, and is
> + * ignored otherwise. */
> +struct Mesh *BKE_mesh_new_from_object(struct Depsgraph *depsgraph,
> + struct Object *object,
> + bool preserve_all_data_layers);
>
> /* This is a version of BKE_mesh_new_from_object() which stores mesh in
> the given main database. */
> -struct Mesh *BKE_mesh_new_from_object_to_bmain(struct Main *bmain, struct
> Object *object);
> +struct Mesh *BKE_mesh_new_from_object_to_bmain(struct Main *bmain,
> + struct Depsgraph
> *depsgraph,
> + struct Object *object,
> + bool
> preserve_all_data_layers);
>
> struct Mesh *BKE_mesh_create_derived_for_modifier(struct Depsgraph
&
Re: [Bf-committers] [GSoC 2019] Embree BVH for GPU Questions
Hi, Answers are inlined. On Sat, Apr 6, 2019 at 5:45 AM Alex Ozer wrote: > Thank you for the reply Sergey. > > If you wouldn't mind I'd like to try going through the steps myself to > make sure I've got the right idea. Feel free to correct me if I'm > wrong and feel free to suggest more details I might be missing. > > > Implement converter from Embree BVH to Cycles BVH data structures. > > For this step, what we'd like to do here is attempt to use Embree's > BVH builder completely in-place-of Cycles' native BVH builder, without > using any fancy features of Embree's BVH data structure itself yet. > This wouldn't work for every type of BVH that Embree could produce > since we don't aim to support STBVH-esque features in Cycles' BVH just > yet. Packing the BVH for GPU, GPU traversal etc. stays the same. > Sounds about right. > I guess I am most fuzzy about which sacrifices exactly are we making > converting Embree's BVH to Cycles' without modifying Cycles' BVH much > (no OBBs? no motion?) > It will limit us to AABB, with all motion steps per primitive in one node (effectively limiting motion_steps to 1). Before going to the next steps, verification of the render result of all regression tests/scenes is to be done. > Verify if Embree can export oriented bounding boxes and motion steps, and > if needed improve Embree API. > > In order to eventually implement something like the STVBH in Cycles' > BVH, we'll need to export all STBVH-related features from Embree, > including the time-varying bounding boxes and node time intervals. > Both OBB and time steps for BVH nodes are to be converted from Embree. > Do we choose not to try to export OBBs until after the initial converter > task in order to keep the initial converter task simple? Exactly. > Additionally, where may I look in the Cycles codebase to get a good idea > for where > OBBs / hair are being used? > Main heuristic code for OBB builder can be found there: https://developer.blender.org/diffusion/B/browse/master/intern/cycles/bvh/bvh_unaligned.cpp Traversal code for OBB is using functions like bvh_unaligned_node_intersect_child: https://developer.blender.org/diffusion/B/browse/master/intern/cycles/kernel/bvh/bvh_nodes.h > Adjust Cycles kernel BVH traversal for faster motion blur. > > In this step we aim to replace Cycles' internal BVH with one that > supports faster motion blur similar to Embree's. We need to: > > * Modify Cycles' BVH data structure to support features which Embree's does > * Implement a more complete converter from Embree's BVH to a > Cycles-internal BVH > * Modify the non-Embree BVH traversal code implemented in the Cycles > kernel to leverage Cycles' BVH redesign for faster motion blur. BVH > packing for the kernel will also need to be modified. > Modifications in BVH structure needs to happen for both OBB and motion blur. So while the implementation of those features is to happen separately, might be good idea to plan modifications ahead, to avoid duplicate work. Other than that, rough plan seems fine. > Thanks again for the time and consideration; let me know if I should > direct follow-ups to this project to another place like the Cycles > mailing list. > > Alex > > On Fri, Apr 5, 2019 at 3:50 AM Sergey Sharybin > wrote: > > > > Hi, > > > > The answers are inlined. > > > > On Fri, Apr 5, 2019 at 6:53 AM Alex Ozer wrote: > > > > > > Implement converter from Embree BVH to Cycles BVH data structures. > > > > Adjust Cycles kernel BVH traversal for faster motion blur. > > > > > > I'm not sure whether this means to convert Embree's BVH to Cycles' BVH > > > with or without modifying Cycles' BVH. At first I thought it was > > > "without", but I'm not sure what adjusting Cycles kernel BVH traversal > > > would specifically entail unless maybe it would be for taking > > > advantage of the special properties of the "Spacial-Temporal" type of > > > BVH which Embree constructs [3]. Essentially, would this task involve > > > implementing features of Embree's BVH (such as its time bounds) in > > > Cycles' BVH, and modifying the Cycles kernel to leverage this for > > > faster motion blur? > > > > > > > Those are two incremental steps. > > > > Cycles uses bare-arrays-alike data structures, which are easy to put and > > use on GPU. So first step of the project is to put Embrees data > structures > > to Cycles with minimal changes on Cycles side. This eases testing and > > verification process before going more advanced. > > > > Then, since Embree has better builder for motion blur support (i.e. as > > you've pointed,
Re: [Bf-committers] [GSoC 2019] Embree BVH for GPU Questions
Hi, The answers are inlined. On Fri, Apr 5, 2019 at 6:53 AM Alex Ozer wrote: > > Implement converter from Embree BVH to Cycles BVH data structures. > > Adjust Cycles kernel BVH traversal for faster motion blur. > > I'm not sure whether this means to convert Embree's BVH to Cycles' BVH > with or without modifying Cycles' BVH. At first I thought it was > "without", but I'm not sure what adjusting Cycles kernel BVH traversal > would specifically entail unless maybe it would be for taking > advantage of the special properties of the "Spacial-Temporal" type of > BVH which Embree constructs [3]. Essentially, would this task involve > implementing features of Embree's BVH (such as its time bounds) in > Cycles' BVH, and modifying the Cycles kernel to leverage this for > faster motion blur? > Those are two incremental steps. Cycles uses bare-arrays-alike data structures, which are easy to put and use on GPU. So first step of the project is to put Embrees data structures to Cycles with minimal changes on Cycles side. This eases testing and verification process before going more advanced. Then, since Embree has better builder for motion blur support (i.e. as you've pointed, STBVH), we can benefit from this as well by replacing multi-step BVH with more boundbox-interpolation alike approach. This would require changes in both data structures and travsersal code. > > Verify if Embree can export oriented bounding boxes and motion steps, > and if needed improve Embree API. > > I'm not sure what the purpose of this is; it seems to me that Cycles' > BVH uses axis-aligned bounding boxes. Also, I'm not sure on the > terminology "motion steps". > Cycles uses both AABB and OBB (oriented bounding box). Those are essential for fast hair rendering. Embree supports OBB but in the past it was only available for the Embree's traversal. This needs to be verified, and, possibly, implemented on Embree side. Motion step is basically bounding box of a node at a specific time step. Those are then interpolated to get bounding box for the ray's time during rendering. -- With best regards, Sergey Sharybin ___ Bf-committers mailing list Bf-committers@blender.org https://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Blender with no widgets
Hi, If it's same exact Blender release (i.e. 2.79b from our website) worked before and stopped working means that some change on your system caused it. Most likely it is something to do with the graphics card or its driver. On Tue, Feb 12, 2019 at 10:27 AM Dave Plater wrote: > Hi, what could cause blender 2.79b to suddenly have no widgets or menus? > This has suddenly happened in the openSUSE:Tumbleweed build, the same > build in Leap:15.0 has everything and the cmake outputs are the same. > Where can I look? > Thanks > Dave Plater > ___ > Bf-committers mailing list > Bf-committers@blender.org > https://lists.blender.org/mailman/listinfo/bf-committers > -- With best regards, Sergey Sharybin ___ Bf-committers mailing list Bf-committers@blender.org https://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] GSOC 2019 - viewport caching - Idea proposal
Hi, Thanks for the proposal. Unfortunately, the complexity of the project is higher than it sounds, and is beyond complexity of the Google Summer of Code project. On a more positive side, this project is in our roadmap for 2.8 series, and will happen sooner than later. On Tue, Feb 5, 2019 at 3:10 PM Luciano A. Muñoz Sessarego < luci...@pintamonos.cl> wrote: > First, congratulations everyone on the Annie award and on all the years of > hard work, at my current job i got animators crying to learn blender (which > i'll help them with), it makes me very proud to be part of this community > and see how far it's gone, cant imagine where it'll take us. > > Okay so GSOC proposal. > > *VIewport caching for animation playback.* > > >- *Benefits*: Giving animators the tools to make animation better and >faster, the faster you can see in the viewport, the more you can > iterate, >the more you can iterate the better you can work, the more you can > improve. >Directly the benefit to the users is playing one or several characters >in realtime in the viewport even if they are heavy in polygons, this > with >the power of the workbench engine for visualization will reduce the > ammount >of "playblasts" made while doing animation and also give the > possibility to >see what's going on around the character not only in the one perspective >where the playblast is made from. This will hugely improve the animation >workflow, I think at the end of the day what every animator wants is > rigs >that play realtime every time. > >- *Description*: for the user in the viewport basically there should be >just a button to turn on and off, with a sub-button to flush cache in > case >that's needed. It should basically work like the prefetch that is being >done for the vse, with a bar drawn in the timeline describing what > frames >have been cached. > >- *Requirements*: should be non intrusive and automatic, (the idea is >not to add extra steps or work for the user, but on the contrary make > it as >invisible as possible) it would happen in the background and with > optional >way to "force" recaching for when that's necessary. > >- *Difficulty*: One of the main difficulty and concerns is that if i >move a part of the rig the cache doesnt get invalidated completely, just >the affected frames, in example i have 100 frames and i tweak an eye of > my >character that only affects 5 frames of the timeline, after i let go the >eye control those 5 frames should be recached not the entire range of >frames. > >- *Possible mentors*: i guess sybren could be the ideal mentor since >he's been working other kinds of caching (?) > > To finalize, this idea has been around the industry for years, Premo > (dreamworks animation software) has this same system since pre how to train > your dragon time ~2014, pixar's presto also features it via their USD and > its render engine Hydra, and maya 2019 recently acquired this feature > (that's when i first got a taste hands on of it), and for the animation > process it is a game changer. > > all my love, > > L > > Luciano A. Muñoz Sessarego > > Web: www.pintamonos.cl > > Email: luci...@pintamonos.cl > > Vimeo: www.vimeo.com/lucianomunoz > > Gumroad: https://gumroad.com/lucianomunoz > > Imdb: https://www.imdb.com/name/nm8355386/ > > Linkedin: http://www.linkedin.com/in/lucianomunoz > > Instagram: https://www.instagram.com/lucianomunoz > ___ > Bf-committers mailing list > Bf-committers@blender.org > https://lists.blender.org/mailman/listinfo/bf-committers > -- With best regards, Sergey Sharybin ___ Bf-committers mailing list Bf-committers@blender.org https://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Outage with SVN commits related to Phabricator update
Hi, The issue is supposed to be fixed now. Please let me know here or in person if you still experiencing issues. On Tue, Feb 5, 2019 at 12:16 PM Dan McGrath wrote: > Hi, > > Just a heads up that it would appear that a recent update to Phabricator to > hide certain activity from being displayed on our recent activity section, > also inadvertently broke our SVN account synchronisation. > > Reads (anonymous) should be just fine, but expect to not be able to commit > to any SVN until this issue is resolved. > > Sorry for the inconvenience! > > > Cheers, > > Dan McGrath > ___ > Bf-committers mailing list > Bf-committers@blender.org > https://lists.blender.org/mailman/listinfo/bf-committers > -- With best regards, Sergey Sharybin ___ Bf-committers mailing list Bf-committers@blender.org https://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Dev User Interface Project
Hi, Can you try watching it again? It seems to work for me now. On Fri, Jan 25, 2019 at 9:19 AM Sergey Sharybin wrote: > Hi, > > Seems like a Phabricator issue. Will have a look shortly. > > On Fri, Jan 25, 2019 at 12:23 AM Harley Acheson > wrote: > >> Hello, >> >> I have only just noticed the User Interface project page >> <https://developer.blender.org/project/profile/12/>. When I click >> the "Watch Project" button it says I don't have permissions. I was hoping >> to become at least a watcher as the "Workboard" seems full of interesting >> goodies. >> >> I have been submitting small patches >> <https://developer.blender.org/people/revisions/20967/> yet again lately >> and these little UI >> jobs seem to fit my spare time well. At least until cycling season starts >> again... >> >> Regards, >> Harley Acheson (harley) >> ___ >> Bf-committers mailing list >> Bf-committers@blender.org >> https://lists.blender.org/mailman/listinfo/bf-committers >> > > > -- > With best regards, Sergey Sharybin > -- With best regards, Sergey Sharybin ___ Bf-committers mailing list Bf-committers@blender.org https://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] Blender developers meeting notes - 2019-02-04
Hi all, Here are the notes from today's developer meeting. Next meeting is Monday, 11 February 10:00 CET / 09:00 UTC. 1) New Features and Changes * About 105 bugs were fixed last week, total number of closed reports is 222, * Bevel: better corner shapes for inner arc miters. (Howard Trickey) * Workbench support for material transparency. (Clément Foucault) 2) Development * Jeroen Bakker starts work at the Blender Institute this week, welcome! He will first focus on Cycles OpenCL optimizations, funded by AMD. * Bug tracker priority names have been changed to make their meaning more clear. We also encourage developers to set High priority more often so important bugs do not get buried. * Richard Antalik is working on a sequencer prefetch patch, which needs design and code review: https://developer.blender.org/D3934 3) Google Summer of Code * This is a period for organizations to apply. * The list of ideas needs update with the deadline of February 6: https://wiki.blender.org/wiki/GSoC/Ideas_Suggestions 4) Weekly Reports * Bastien: https://wiki.blender.org/wiki/User:Mont29/Foundation/2019#Week_281_-_01.2F26_to_02.2F01 * Brecht: https://wiki.blender.org/wiki/User:Brecht/Reports/2019 * Campbell: https://download.blender.org/ftp/ideasman42/donelist/2019.html#week-310-january-28 * Clément: https://wiki.blender.org/wiki/User:Hypersomniac/Foundation/2019#Week_108_:_28th_-_3rd_Feb * Dalai: https://wiki.blender.org/wiki/User:Dfelinto/Reports/2019#January_28_-_February_1 * Jacques: https://wiki.blender.org/wiki/User:JacquesLucke/Reports/2019#Week_18:_January_28_-_01 * Jeroen: https://wiki.blender.org/wiki/User:Jbakker/reports/2019#Week_201905:_2019.2F02.2F01_-_2019.2F02.2F03 * Philipp: https://wiki.blender.org/wiki/User:PhilippOeser/Foundation/2019#Calendar_Week_5_.28Jan_28th_-_Feb_1st.29 * Sebastian: https://wiki.blender.org/wiki/User:Zeddb#January_28_-_Feb_1 * Sergey: https://wiki.blender.org/wiki/User:Sergey/Foundation/2019#Week_371:_28th_January_-_3rd_February -- With best regards, Sergey Sharybin ___ Bf-committers mailing list Bf-committers@blender.org https://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Error after Updates to developer/git/svn/buildbot
Ah, indeed need to be non-anonymous to see the issue.
Tried to quickly poke the code to convert the octal values to a proper
Python3 notation, and then also needed to tweak exception handling syntax..
But that just opens a bigger rabbit hole to hell: more and more areas of
Gitosis seems to be incompatible with Python3.
Python2 seems to be unavailable on that host anymore. Restoring it probably
is easier/faster.
P.S. I am also not quite sure why we are still on Gitosis and not on
Gitolite. The former is no longer maintained, the latter one is what Linux
distors are providing. So can not expect Gitosis to be ported to Python3.
On Sat, Feb 2, 2019 at 7:09 PM Bastien Montagne
wrote:
> Can confirm same issue here as well (debian64 testing).
>
> On 02/02/2019 18:36, Ray Molenkamp wrote:
> > Same issue here,
> >
> > anonymous usage seems to work
> >
> > git clone git://git.blender.org/blender.git
> >
> > works, however authenticated users
> >
> > git clone g...@git.blender.org:blender.git
> >
> > fail with the error mentioned earlier
> >
> > --Ray
> >
> >
> > On 2/2/2019 10:30 AM, Howard Trickey wrote:
> >> Happens for me too. git pull from origin/master of blender repository
> >>
> >>
> >> On Sat, Feb 2, 2019 at 12:14 PM Sergey Sharybin
> >> wrote:
> >>
> >>> Hi,
> >>>
> >>>> util.mkdir(p, 0750)
> >>> AFAIK, this should be 0o750 for Python3. The code seems to be from
> >>> gitsosis, which we use from an upstream.
> >>>
> >>> What is more weird is that for me `git pull` works fine. Does this
> still
> >>> happen for you? Which exact repo causes the issue?
> >>>
> >>> On Sat, Feb 2, 2019 at 5:15 PM blendergit
> wrote:
> >>>
> >>>> Hi,
> >>>>
> >>>> Not sure if you have completed the update, but today when I try to run
> >>>> “git pull”, I get this:
> >>>>
> >>>> $ git pull
> >>>> Traceback (most recent call last):
> >>>>File "/usr/local/bin/gitosis-serve", line 11, in
> >>>> load_entry_point('gitosis==0.2', 'console_scripts',
> >>> 'gitosis-serve')()
> >>>>File
> >>> "/usr/local/lib/python3.6/site-packages/pkg_resources/__init__.py",
> >>>> line 487, in load_entry_point
> >>>> return get_distribution(dist).load_entry_point(group, name)
> >>>>File
> >>> "/usr/local/lib/python3.6/site-packages/pkg_resources/__init__.py",
> >>>> line 2728, in load_entry_point
> >>>> return ep.load()
> >>>>File
> >>> "/usr/local/lib/python3.6/site-packages/pkg_resources/__init__.py",
> >>>> line 2346, in load
> >>>> return self.resolve()
> >>>>File
> >>> "/usr/local/lib/python3.6/site-packages/pkg_resources/__init__.py",
> >>>> line 2352, in resolve
> >>>> module = __import__(self.module_name, fromlist=['__name__'],
> level=0)
> >>>>File "/usr/local/lib/python3.6/site-packages/gitosis/serve.py",
> line
> >>> 142
> >>>> util.mkdir(p, 0750)
> >>>> ^
> >>>> SyntaxError: invalid token
> >>>> fatal: Could not read from remote repository.
> >>>>
> >>>> Please make sure you have the correct access rights
> >>>> and the repository exists.
> >>>>
> >>>> I’m running on Windows 10.
> >>>>
> >>>> Regards,
> >>>> Antonio Vázquez
> >>>>
> >>>> De: Dan McGrath
> >>>> Enviado: sábado, 2 de febrero de 2019 12:45
> >>>> Para: bf-blender developers
> >>>> Asunto: [Bf-committers] Updates to developer/git/svn/buildbot
> >>>>
> >>>> Hi,
> >>>>
> >>>> Just a heads up that today I upgraded the following sites to the
> latest
> >>>> 2019Q1 ports in FreeBSD:
> >>>>
> >>>>- developer.blender.org
> >>>>- git.blender.org
> >>>>- svn.blender.org
> >>>>- builder.blender.org
> >>>>
> >>>> As well, the Phabricator (developer.b.o) PH
Re: [Bf-committers] Error after Updates to developer/git/svn/buildbot
Hi,
> util.mkdir(p, 0750)
AFAIK, this should be 0o750 for Python3. The code seems to be from
gitsosis, which we use from an upstream.
What is more weird is that for me `git pull` works fine. Does this still
happen for you? Which exact repo causes the issue?
On Sat, Feb 2, 2019 at 5:15 PM blendergit wrote:
> Hi,
>
> Not sure if you have completed the update, but today when I try to run
> “git pull”, I get this:
>
> $ git pull
> Traceback (most recent call last):
> File "/usr/local/bin/gitosis-serve", line 11, in
> load_entry_point('gitosis==0.2', 'console_scripts', 'gitosis-serve')()
> File "/usr/local/lib/python3.6/site-packages/pkg_resources/__init__.py",
> line 487, in load_entry_point
> return get_distribution(dist).load_entry_point(group, name)
> File "/usr/local/lib/python3.6/site-packages/pkg_resources/__init__.py",
> line 2728, in load_entry_point
> return ep.load()
> File "/usr/local/lib/python3.6/site-packages/pkg_resources/__init__.py",
> line 2346, in load
> return self.resolve()
> File "/usr/local/lib/python3.6/site-packages/pkg_resources/__init__.py",
> line 2352, in resolve
> module = __import__(self.module_name, fromlist=['__name__'], level=0)
> File "/usr/local/lib/python3.6/site-packages/gitosis/serve.py", line 142
> util.mkdir(p, 0750)
> ^
> SyntaxError: invalid token
> fatal: Could not read from remote repository.
>
> Please make sure you have the correct access rights
> and the repository exists.
>
> I’m running on Windows 10.
>
> Regards,
> Antonio Vázquez
>
> De: Dan McGrath
> Enviado: sábado, 2 de febrero de 2019 12:45
> Para: bf-blender developers
> Asunto: [Bf-committers] Updates to developer/git/svn/buildbot
>
> Hi,
>
> Just a heads up that today I upgraded the following sites to the latest
> 2019Q1 ports in FreeBSD:
>
> - developer.blender.org
> - git.blender.org
> - svn.blender.org
> - builder.blender.org
>
> As well, the Phabricator (developer.b.o) PHP was upgraded from PHP 5.6 to
> 7.2. Overall the site seems nice and zippy when doing cached pages, but
> otherwise, keep an eye out for horrible stuff!
>
> Also, if it's good, nice! But if it breaks, it wasn't me that touched
> anything, and is all Sergey Sharybin's fault! ><
>
> At some point the host will go down for a FreeBSD upgrade from 11 to 12.
> Probably on Monday or so, I will let you know here.
>
>
> Cheers,
>
> Dan
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> https://lists.blender.org/mailman/listinfo/bf-committers
>
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> https://lists.blender.org/mailman/listinfo/bf-committers
>
--
With best regards, Sergey Sharybin
___
Bf-committers mailing list
Bf-committers@blender.org
https://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Dev User Interface Project
Hi, Seems like a Phabricator issue. Will have a look shortly. On Fri, Jan 25, 2019 at 12:23 AM Harley Acheson wrote: > Hello, > > I have only just noticed the User Interface project page > <https://developer.blender.org/project/profile/12/>. When I click > the "Watch Project" button it says I don't have permissions. I was hoping > to become at least a watcher as the "Workboard" seems full of interesting > goodies. > > I have been submitting small patches > <https://developer.blender.org/people/revisions/20967/> yet again lately > and these little UI > jobs seem to fit my spare time well. At least until cycling season starts > again... > > Regards, > Harley Acheson (harley) > ___ > Bf-committers mailing list > Bf-committers@blender.org > https://lists.blender.org/mailman/listinfo/bf-committers > -- With best regards, Sergey Sharybin ___ Bf-committers mailing list Bf-committers@blender.org https://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Blender 2.8 git
Hi, This is correct that not all submodules have 2.8 branch. You can do: `git submodule update --remote` That will update all the submodules to latest revision of the branch they are tracking. This will keep submodules on a detached HEAD, which is finr Git state, but might be confusing for some use. Alternatively, you can do `make update` in the root of the source trees. That updates blender checkout and all submodules. Or can manually run the following submodules update commands from gnu makefile: git submodule foreach "git checkout blender2.8 || git checkout master" git submodule foreach git pull --rebase origin On Thu, Dec 20, 2018 at 10:27 AM Paul Melis wrote: > Hi, > > I'd like to build 2.8 here locally, as I can't use the daily builds > (glibc is too old on our cluster system and won't be updated soon). > I build 2.7 regularly, so that's not an issue for me, but I'm having > trouble doing a correct checkout from git of the various 2.8 stuff. > The instructions on https://wiki.blender.org/wiki/Tools/Git are not > fully portable to 2.8, so any help is appreciated. > > As a first step I clone the repo (but only the 2.8 branch): > > git clone --single-branch --branch blender2.8 > git://git.blender.org/blender.git blender28-git > > Next comes the first hurdle, the submodules: > > # Works > git submodule update --init --recursive > > # git submodule foreach --recursive git checkout blender2.8 > git checkout blender2.8 > Entering 'release/datafiles/locale' > error: pathspec 'blender2.8' did not match any file(s) known to git. > Stopping at 'release/datafiles/locale'; script returned non-zero status. > > So looking at .gitmodules it seems not all submodules use a branch2.8 > branch. Should I replace the foreach with a manual set of checkouts of > the submodules with the correct branches? And I guess with the submodule > pull commands that would need the same? And finally, for keeping things > up-to-date over time, it would need another per-submodule command? > > Thanks, > Paul > > -- > > Paul Melis > | Visualization group leader & developer | SURFsara | > | Science Park 140 | 1098 XG Amsterdam | > | T 020 800 1312 | paul.me...@surfsara.nl | www.surfsara.nl | > ___ > Bf-committers mailing list > Bf-committers@blender.org > https://lists.blender.org/mailman/listinfo/bf-committers > -- With best regards, Sergey Sharybin ___ Bf-committers mailing list Bf-committers@blender.org https://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Rights on dev.b.o
Hi again, Should be fixed now. On Tue, Dec 11, 2018 at 9:42 AM Sergey Sharybin wrote: > Hi, > > Looking into this. > > On Tue, Dec 11, 2018 at 8:58 AM blendergit wrote: > >> Hi, >> >> I have the same problem since two or three days. Maybe it was something >> in the last SO update. >> >> Antonio Vazquez >> >> De: Julien Duroure >> Enviado: lunes, 10 de diciembre de 2018 23:40 >> Para: bf-blender developers >> Asunto: [Bf-committers] Rights on dev.b.o >> >> Hello, >> >> It seems that I have no more rights on d.b.o to assign me on an issue or >> change priority. >> I wanted to assign me on T59127. >> I did same on previous glTF issues, without any problems. >> >> I have now following error message: >> >> Access Denied: T59127 >> You do not have permission to edit this object. >> Users with the "Can Edit" capability: >> >> This object has a custom policy controlling who can take this action. >> The owner of a task can always view and edit it. >> ___ >> Bf-committers mailing list >> Bf-committers@blender.org >> https://lists.blender.org/mailman/listinfo/bf-committers >> >> _______ >> Bf-committers mailing list >> Bf-committers@blender.org >> https://lists.blender.org/mailman/listinfo/bf-committers >> > > > -- > With best regards, Sergey Sharybin > -- With best regards, Sergey Sharybin ___ Bf-committers mailing list Bf-committers@blender.org https://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Rights on dev.b.o
Hi, Looking into this. On Tue, Dec 11, 2018 at 8:58 AM blendergit wrote: > Hi, > > I have the same problem since two or three days. Maybe it was something in > the last SO update. > > Antonio Vazquez > > De: Julien Duroure > Enviado: lunes, 10 de diciembre de 2018 23:40 > Para: bf-blender developers > Asunto: [Bf-committers] Rights on dev.b.o > > Hello, > > It seems that I have no more rights on d.b.o to assign me on an issue or > change priority. > I wanted to assign me on T59127. > I did same on previous glTF issues, without any problems. > > I have now following error message: > > Access Denied: T59127 > You do not have permission to edit this object. > Users with the "Can Edit" capability: > > This object has a custom policy controlling who can take this action. > The owner of a task can always view and edit it. > ___ > Bf-committers mailing list > Bf-committers@blender.org > https://lists.blender.org/mailman/listinfo/bf-committers > > ___ > Bf-committers mailing list > Bf-committers@blender.org > https://lists.blender.org/mailman/listinfo/bf-committers > -- With best regards, Sergey Sharybin ___ Bf-committers mailing list Bf-committers@blender.org https://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Planned maintenance on the development server
Hi, The maintenance is over, and we are now running latest OS and software on the development server. Let me know if something is misbehaving. P.S. There is a background indices optimization process is running, so ignore the warning reported by Phabricator if you see it. On Wed, Dec 5, 2018 at 2:37 PM Sergey Sharybin wrote: > Hi, > > We've planned maintenance on our development server which hosts: > > - builder.blender.org > - developer.blender.org > - git.blender.org > - svn.blender.org > > The server will receive OS update. Additionally, we will update our > developer.b.o install to a latest Phabricator website. > > We start on this Sunday at noon CET time, and expect to be finished in 3 > hours. During this time some services will not be available or will work > with interruption. > We will be doing extra announcement on our #blendercoders IRC channel. > > -- > With best regards, Sergey Sharybin > -- With best regards, Sergey Sharybin ___ Bf-committers mailing list Bf-committers@blender.org https://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] Cycles: OpenCL on macOS has been disabled
Hi, There was a growing payload of bugs in Cycles related on OpenCL on macOS platform, and those issues were caused by a compiler bug, which we have no control over. Surely, it is sometimes possible to work compiler bugs around from a source, but we are facing some of the issues which are not solvable in this way. Also, such solutions are usually short-living,. since adding more features are often kicking compiler to provide buggy binary again. In this case compiler will not get fixed since Apple decided to discontinue OpenCL on its platform. So the decision was made to drop support of OpenCL, keep official features of Blender stable and predictable, and focus on things we have control over. P.S. Older Blender releases are always available. Surely, this sounds like using an ancient software without neat features. But we can't push Cycles OpenCL on macOS measurably beyond that anyway. -- With best regards, Sergey Sharybin ___ Bf-committers mailing list Bf-committers@blender.org https://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] Planned maintenance on the development server
Hi, We've planned maintenance on our development server which hosts: - builder.blender.org - developer.blender.org - git.blender.org - svn.blender.org The server will receive OS update. Additionally, we will update our developer.b.o install to a latest Phabricator website. We start on this Sunday at noon CET time, and expect to be finished in 3 hours. During this time some services will not be available or will work with interruption. We will be doing extra announcement on our #blendercoders IRC channel. -- With best regards, Sergey Sharybin ___ Bf-committers mailing list Bf-committers@blender.org https://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] Updating release/buildbot environment to Glibc-2.24
Hi, We are moving official release environment and buildbot to newer platform, which is based on Debian Stretch, with Glibc version 2.24. This is caused by the following technical reasons: - Platform we used before was based on Debian Jessie, which became oldstable a year ago. While it is still receiving security updates, the usual period for this is one year. So is quite likely that Jessie will be moved to archive soon. - There was a lot of libraries update, which always goes smoother in a newer environment. For the users this means: - Only platforms newer than 2 years old are supported bu the newer Blender builds. This surely includes Debian Stretch+, Ubuntu 17.10+, Fedora 26+. - With some luck Ubuntu 16.04 and Slackware 14.2 will work, since currently Blender (and its dependencies) do not use 2.24 symbols and only using 2.23. - All the dependencies are updated to way newer versions, and now are same across all platforms. This includes years of security updates for dependencies like PNG, OpenJPEG and more. For developers this means: - The current build environment is based on minimal chroot (the script i've used to generate it [1]). The rest is done by `make deps` in the blender's root directory. This means, everyone can create his own static release environment! - Maybe Also makes it easier to wrap things up into docker images and such. NOTE: While everything seems to work in the new environment, there is always a room for bugs. If something is misbehaving with the new builds, submit bug reports to the tracker as usual. [1] http://download.blender.org/ftp/sergey/buildbot-chroot/ -- With best regards, Sergey Sharybin ___ Bf-committers mailing list Bf-committers@blender.org https://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] [Bf-blender-cvs] [73f20560529] master: Cycles: Add BVH8 and packeted triangle intersection
Hi, Correction/clarification: The original BVH8 patch was done by both Maxym and Anton. Maxym was mentoring during Intel Summer Students. On Wed, Aug 29, 2018 at 4:06 PM Sergey Sharybin wrote: > Commit: 73f20560529457ea177cb93e8e8eaaf44a589643 > Author: Sergey Sharybin > Date: Wed Feb 14 11:23:30 2018 +0100 > Branches: master > https://developer.blender.org/rB73f20560529457ea177cb93e8e8eaaf44a589643 > > Cycles: Add BVH8 and packeted triangle intersection > > This is an initial implementation of BVH8 optimization structure > and packated triangle intersection. The aim is to get faster ray > to scene intersection checks. > > SceneBVH4 BVH8 > barbershop_interior10:24.94 10:10.74 > bmw27 02:41.25 02:38.83 > classroom 08:16.49 07:56.15 > fishy_cat 04:24.56 04:17.29 > koro 06:03.06 06:01.45 > pavillon_barcelona 09:21.26 09:02.98 > victor 23:39.65 22:53.71 > > As memory goes, peak usage raises by about 4.7% in a complex > scenes. > > Note that BVH8 is disabled when using OSL, this is because OSL > kernel does not get per-microarchitecture optimizations and > hence always considers BVH3 is used. > > Original BVH8 patch from Anton Gavrikov. > Batched triangles intersection from Victoria Zhislina. > Extra work and tests and fixes from Maxym Dmytrychenko. > ___ > Bf-blender-cvs mailing list > bf-blender-...@blender.org > https://lists.blender.org/mailman/listinfo/bf-blender-cvs > -- With best regards, Sergey Sharybin ___ Bf-committers mailing list Bf-committers@blender.org https://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] Dependency graph filtering
Hi, While it's cool and everything to have faster motion paths, the implementation way i find completely wrong, with big intrinsic design flaws. Here goes just a brief overview of things which bothers me most. - Committing without any code review? Surely, all this filtering API is coming from an original author of the new dependency graph. But that "new" dependency graph was re-written quite a lot by both Lukas and myself. And it is me who is spending at least 50% of time maintaining the dependency graph. I do not find it cool at all committing things without even talking to me, without discussing ways to achieve particular goal, and without asking even whether i am interested in having a review on the code. - Why is it even a thing for "filtering" ? The goal is: have a dependency graph which is enough to evaluate datablocks which you're interested in at some specific task. Most reliably and shortest way to do so, is to invoke dependency graph builder starting from that datablock. Nowadays it's almost as simple as calling `build_id()` for node and relations builder. Surely, you'll need to take collections and overrides into account, but that is also just few extra calls. This way you: a) Do not need to implement all those weird and wonderful traversals b) Make it possible to create such a dependency graph from a thread, or create multiple dependency graphs at the same time (the foreach API explicitly says it is not safe from threading point of view). Just to state the obvious: we do need to support building dependency graphs (including their "minimal" versions) from multiple threads. c) You guarantee that dependency graph is fully consistent, and fully matches situation when one manually simplifies scene to the same state. Next big issue with filtering is that it requires original dependency graph to have up-to-date relations. This means, before you can filter, you have to ensure relations are up to date. Filtering API doesn't even do any sanity checks in this regard. I see an argument "motion paths do have dependency graph up to date already". But then why is this filtering in depsgraph/ ? Anything what goes there must be generic and reusable and reliable. Current implementation is none of that. And last but not least, all the comments about per-operation or per-component filtering are not compatible with the current expectations of what dependency graph is supposed to deliver: you are not supposed to have partially evaluated datablocks after calling DEG_evaluate_on family of functions. None of the areas should even care whether dependency graph is "filtered" or not, there must be no cases where you can't access evaluated object properties based on the nature of dependency graph. - What is `DAG_EVAL_BACKGROUND` ? While i see that potentially some of the areas might want to do something special for such kind of evaluation, but currently this breaks visibility/simplification settings checks: those are expecting either viewport or render evaluation. If new evaluation modes are added, all users of mode are to be checked. You can't just add new evaluation modes and expect all the areas properly pick it up. - Keep areas unaware of where dependency graph came from. This is very red-flagging when comment says things like "don't pass filtered depsgraph here". I do not see any reason why filtering will not be able to narrow dependency down even further. If it's unable to do so, this means dependency graph it produces is wrong. - Naming. Stop calling everything a `target`. This is ambiguous word, which is in most cases it is obviously inverted. Don't modify naming in the existing code you didn't write, especially if the author of that code is still around and does close to 100% maintenance in the area. Stop changing ownership of a variables. This is very confusing when up to some point `depsgraph` is owned by a scene, but after calling `filter()` it is owned by the function itself (which forces you to have all the obscure things like `free_depsgraph` (which should really at least prefixed `need_`)). - Dead code. Never commit it. It adds a lot of confusion, and is almost never gets pushed forward. Things like `detail_level` never gets implemented or used for years, and during those years they only cause confusion about what should one pass there. - Moving forward. I would really strongly advice removing this filtering API. This is really a dead end. Implement BUILDING of dependency graph from a datablock. If you want to be more generic, allow building dependency graph from a list of datablocks. -- With best regards, Sergey Sharybin ___ Bf-committers mailing list Bf-committers@blender.org https://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] Blender developers meeting notes - 2018-08-20
Hi everyone, Here are the notes from today's developer meeting. Next meeting is Monday, 27 August 10:00 CEST (08:00 UTC). 1) Blender 2.8 - Dalai did a lot of work bringing motion tracking back to usable state in, including reconstruction drawing in viewport, camera backgruond setup, clip playback in viewport. - Sebastian Koenig is working on porting "Setup Tracking Scene" to collection, shadow catcher and other modern 2.8 technologies. - Sergey got multires modifier to work on CPU using OpenSubdiv. Tools and sculpting surrounding multires are the next in line. - Martin Felke worked on proposal for fracture modifier in 2.8: https://developer.blender.org/T54888#528900 - There is a call for content: default studio lights: https://devtalk.blender.org/t/call-for-content-studio-lights/1869 You can also watch video about the call: https://youtu.be/so7rCVlIoXg - Work is being done on Armature support for grease pencil objects. - Weekly reports: * Bastien Montagne: https://wiki.blender.org/wiki/User:Mont29/Foundation/2018#Week_257_-_08.2F11_to_08.2F17 * Brecht Van Lommel: https://wiki.blender.org/wiki/User:Brecht/Reports/2018#Augest_13_-_17 * Campbell Barton: https://gitlab.com/ideasman42/bf-blender-donelist/blob/master/content/2018.rst * Clément Foucault: https://wiki.blender.org/wiki/User:Hypersomniac/Foundation/2018#Week_84_:_13th_-_19th_August * Sergey Sharybin: https://wiki.blender.org/wiki/User:Sergey/Foundation/2018#Week_350:_13th_-_19_August 2) Google Summer of Code - All mentors please make sure you've submitted the evaluation form! 3) Other topics - Libraries update is in progress, OSL needs some work from Blender side to solve crashes. Also, OSL doesn't currently build on 32bit platforms. - We've got new committer: Vuk Gardašević (aka lijenstina), welcome aboard! -- With best regards, Sergey Sharybin ___ Bf-committers mailing list Bf-committers@blender.org https://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Blender Compile Error
Hi, Don't think you can attach pictures in this mailing list. It is also more helpful to see error messages as plain text (that how they are reported in the first place ;). Anyway, to share text snippets, screenshots, .blend files you can use pasteall.org. Or, alternatively, plain-text only hastebin.com. Send link here and we will have a look. That being said, i did not see visual studio ever installed incorrectly, unless you pull you computer power plug out for the socket during install :) On Sat, Aug 11, 2018 at 9:28 PM Ágoston Princz wrote: > Hi Blender Developers > > I'm not sure that is the right place to send message like this. > If it is the case, please tell me where to ask about compile errors. > > Other case: I had that error message (attached picture). > Is it possible that Visual Studio Community Version was installed > incorrectly? > > Thansk a lot! > > -- > Ágoston Princz > ___ > Bf-committers mailing list > Bf-committers@blender.org > https://lists.blender.org/mailman/listinfo/bf-committers > -- With best regards, Sergey Sharybin ___ Bf-committers mailing list Bf-committers@blender.org https://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] Blender developers meeting notes - 2018-08-06
He everyone, Here are the notes from today's developer meeting. Next meeting is Monday, 13 August 10:00 CEST (08:00 UTC). 1) Blender 2.8 - Grease pencil is nicely under control, no big issues are reported, all the reports atre tackled quick. Good work! - Bastien spent all the time in the bug tracker, fixing lots of bugs! - Clement optimized mapping node, now it does not recompile shader. - Updated planning for SIGGRAPH release and further Beta will be announced - Sergey was working on OpenSubdiv modifier (CPU side). Getting close to enabling it in the official builds. - Weekly reports: * Bastien Montagne https://wiki.blender.org/wiki/User:Mont29/Foundation/2018#Week_255_-_07.2F28_to_08.2F03 * Clément Foucault https://wiki.blender.org/wiki/User:Hypersomniac/Foundation/2018#Week_82_:_30th_-_5th_August * Sergey Sharybin: https://wiki.blender.org/wiki/User:Sergey/Foundation/2018#Week_348:_30th_July_-_5th_August 2) Google Summer of Code - Student's evaluation and code submission started now. Deadline is 14th August. Don't miss it! - After that mentor's evaluation starts. - Weekly reports: * Erik Englesson: https://lists.blender.org/pipermail/soc-2018-dev/2018-August/000169.html * Geraldine Chua: https://lists.blender.org/pipermail/soc-2018-dev/2018-August/000174.html * Leonardo E. Segovia: https://lists.blender.org/pipermail/soc-2018-dev/2018-August/000170.html * Yiming Wu: https://lists.blender.org/pipermail/soc-2018-dev/2018-August/000173.html 3) Other topics - Libraries update is still needed. - For Freetype update see https://developer.blender.org/D3581 - Arto and Ray are working on a cmake script to update all libraries at once! Sergey will check on using same update script on Linux as well. -- With best regards, Sergey Sharybin ___ Bf-committers mailing list Bf-committers@blender.org https://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Library updates for Blender 2.8
One thing which is raising my attention in 3.7.1 release log is: - Fixed a performance regression for reading streams with tarfile. Also, 3.7.1 is planned to be released soon-ish? Their original plan actually mentions July, not sure what is the updated planning. Are we really in a hurry for this update? On Fri, Aug 3, 2018 at 10:46 AM Sybren A. Stüvel wrote: > On 23/07/2018 19:43, Brecht Van Lommel wrote: > > * Python 3.7.0 (or should we wait until there is a 3.7.1 or so with > > bugfixes?) > > Let's go to 3.7.0, unless somebody already knows of actual bugs that'll > influence our use. > > Sybren > > ___ > Bf-committers mailing list > Bf-committers@blender.org > https://lists.blender.org/mailman/listinfo/bf-committers > -- With best regards, Sergey Sharybin ___ Bf-committers mailing list Bf-committers@blender.org https://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Library updates for Blender 2.8
Hi, Firstly. please don't mix discussion of libraries required for Blender with discussion about someone-is-requesting-handy-tool-to-be-shipped-with-blender. As for the oiiotool, guess the most use of it is to generate .tx. In this case Blender can do it using library API, no need to call an external process. If that is for another type of integration purpose -- i'd say such tools do not belong to Blender package. There are far too many handy tools which lots of people will want have distributed. That would easily bump package size to over 10 gig. If that is just to give random folks builds -- i am even more against it. We are not a building service for that library, and i don't want even get close to opening discussions like "can you update because we definitely need a newer version for our purpose (which, btw, has nothing to do with Blender)". In any case, suggest moving this discussion to a separate topic. On Tue, Jul 24, 2018 at 1:46 PM Ray Molenkamp wrote: > Currently we're only shipping idiff since the unit tests need it, we could > add the other tools > however since we build for blender they are all statically linked, so just > oiiotool would be > 12 megs, while the whole set of binaries would be 45. not sure we want to > add this much > dead weight to the libs? > > --Ray > > On 7/24/2018 12:36 AM, Stefan Werner wrote: > > While not directly applicable to Blender, would it be any trouble to > include oiiotool.exe in the Windows binaries? There was just someone asking > for binaries on the oiio mailing list: > > > http://lists.openimageio.org/pipermail/oiio-dev-openimageio.org/2018-July/001254.html > < > http://lists.openimageio.org/pipermail/oiio-dev-openimageio.org/2018-July/001254.html > > > > > > -Stefan > > > >> On 23. Jul 2018, at 21:53, Ray Molenkamp wrote: > >> > >> There's quite a few libraries we build for the various platforms > >> (57 by the last count) and it's not always clear who the module > >> owner is and who is supposed to ask for newer versions of certain > >> libs. > >> > >> I took a quick survey of the versions we use and the latest versions > >> available. (based on build_files\build_environment\cmake\versions.cmake) > >> > >> > https://docs.google.com/spreadsheets/d/e/2PACX-1vRnu75FDmw8NvbJiH9hjrGNBvrwXU9ocWWMCWZY0ISwcfLOnL7Ep1z67Y5FpN_TaI0QRwbPR2KmrQie/pubhtml?gid=0=true > >> > >> (or in case the email ruins the long link: https://tinyurl.com/y9st4fyt > ) > >> > >> There are several libs with known CVE's, personally I would prefer > >> to upgrade those to the latest versions (most seem low risk upgrades) > >> but for everything else I really have no strong opinion. > >> > >> Any module owner that wants edit rights, please poke me (email/irc) and > >> I'll get you an editable link. > >> > >> --Ray > >> > >> > >> On 7/23/2018 11:43 AM, Brecht Van Lommel wrote: > >>> Hi all, > >>> > >>> It's been a while since we updated libraries, and with the upgrade to > >>> Visual Studio 2017 this has now become easier on Windows as well. > Since the > >>> platform maintainers have time now to do updates, let's try to get > this in > >>> motion. > >>> > >>> Some of the latest library versions need C++11, I also propose we > require > >>> C++11 in master. This mostly involves removing the WITH_CXX1 option and > >>> code cleanups for STL data types compatibility. > >>> > >>> For libraries, these are the ones I know of. Let us know if any other > >>> library updates are needed. > >>> > >>> * OSL, LLVM, OIIO: so we no longer need a really old LLVM version. > >>> https://developer.blender.org/D3398 > >>> https://developer.blender.org/D2915 > >>> > >>> * OpenVDB 5.1.0: so we can read files written by other applications > that > >>> have OpenVDB 5.x. > >>> > >>> * Python 3.7.0 (or should we wait until there is a 3.7.1 or so with > >>> bugfixes?) > >>> > >>> * OpenSubdiv: this will need to include a number of Sergey's bugfixes, > the > >>> revision needed is not known (or doesn't exist) yet. > >>> > >>> Thanks, > >>> Brecht. > >>> ___ > >>> Bf-committers mailing list > >>> Bf-committers@blender.org > >>> https://lists.blender.org/mailman/listinfo/bf-committers > >> ___ > >> Bf-committers mailing list > >> Bf-committers@blender.org > >> https://lists.blender.org/mailman/listinfo/bf-committers > > ___ > > Bf-committers mailing list > > Bf-committers@blender.org > > https://lists.blender.org/mailman/listinfo/bf-committers > > ___ > Bf-committers mailing list > Bf-committers@blender.org > https://lists.blender.org/mailman/listinfo/bf-committers > -- With best regards, Sergey Sharybin ___ Bf-committers mailing list Bf-committers@blender.org https://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] Operators copy-on-write taskforce
Hi, There are many small TODO's for operators to work with copy-on-write changes in dependency graph which happened for Blender 2.8. These are mainly to get existing operators to account for difference between data and state. Joshua and I have made some small reference commits which can be used as a reference. See: https://developer.blender.org/T54810 A lot of the tasks don't require code work, but only verification that they are still working as before. If anyone would be interested to help out it would be welcome. As soon as we done with this, we can have modifiers working in Blender 2.8! =) -- With best regards, Sergey Sharybin ___ Bf-committers mailing list Bf-committers@blender.org https://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Blender 2.8: Moving modifiers away from DerivedMesh
Doing such kind of design changes is outside of scope of this particular project. Not saying it's not being considered. But keep things separate and manageable. On Wed, Apr 18, 2018 at 12:13 PM, Sybren A. Stüvel <syb...@stuvel.eu> wrote: > Hey, > > > On 17-04-18 14:16, Sergey Sharybin wrote: > > One of the design decision for Blender 2.8 was to switch modifier stack > > from DerivedMesh to Mesh. > > > > Here is a rough plan and ideas how to do this: > > https://wiki.blender.org/index.php/Dev:2.8/Source/Modifiers > > Just like the current code, that wiki doc makes the distinction between > "Deformation-only" and "Constructive". When working with Alembic > importing this turned out to be a limitation, as in an Alembic file > sometimes the mesh is deformed and sometimes it needs to be > reconstructed from scratch (this can change from frame to frame). In the > current code this distinction is exclusive, that is, a modifier is > either deforming or constructing, but AFAIK can't be both. I just want > to point out that in future code we may want to allow a modifier to do > both. > > -- > Sybren A. Stüvel > > https://stuvelfoto.nl/ > https://stuvel.eu/ > > ___ > Bf-committers mailing list > Bf-committers@blender.org > https://lists.blender.org/mailman/listinfo/bf-committers > -- With best regards, Sergey Sharybin ___ Bf-committers mailing list Bf-committers@blender.org https://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] Blender 2.8: Moving modifiers away from DerivedMesh
Hi, One of the design decision for Blender 2.8 was to switch modifier stack from DerivedMesh to Mesh. Here is a rough plan and ideas how to do this: https://wiki.blender.org/index.php/Dev:2.8/Source/Modifiers Mai Lavelle will be working on this. But there is a mention of taskforce. It will happen once we're ready for it, and it will be announced here in the list. Stay tuned! -- With best regards, Sergey Sharybin ___ Bf-committers mailing list Bf-committers@blender.org https://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] Blender developers meeting notes - 2018-03-26
Hi all, Here are the notes from today's 16 UTC (18 CEST) meeting in irc.freenode.net #blendercoders. Reminder: meetings are on Mondays now, next meeting is 2 April, 08 UTC (18 CEST). 1) Blender 2.79 'b' release - The release is officially happened, thanks everyone! Changes: https://wiki.blender.org/index.php/Dev:Ref/Release_Notes/2.79/b 2) Blender 2.8 projects - Reminder: Blender 2.8 is still under heavy development, and we are still limiting bug reports to module team members only. - Grease pencil merge proposal/planning: https://developer.blender.org/T54426 More ddetails being discussed in the mailing list: https://lists.blender.org/pipermail/bf-committers/2018-March/049293.html - Blender 2.8 Highlights: https://code.blender.org/2018/03/blender-2-8-highlights/ - Weekly reports: -- Sergey Sharybin: https://wiki.blender.org/index.php/User:Nazg-gul/Foundation/2018#Week_329:_19th_-_25th_March -- Joshua Leung: https://wiki.blender.org/index.php/User:Aligorith/Foundation/2018#March_19_-_March_23 -- Dalai Felinto: https://wiki.blender.org/index.php/User:Dfelinto/Foundation18#Week_10_.28March_19th_-_25th.29 -- Clément Foucault: https://wiki.blender.org/index.php/User:Hypersomniac/Foundation/2018#Week_63:_19th_-_25th_March -- Campbell Barton: http://download.blender.org/ftp/ideasman42/donelist/2018.html#week-366-march-19 -- Bastien Montagne: https://wiki.blender.org/index.php/User:Mont29/Foundation/2018#Week_236_-_03.2F17_to_03.2F23 3) GSoC & Other Projects - 27th March (tomorrow) is the deadline for GSoC proposals submission! - Windows buildbot will be updated to MSVC 2017 - MSVC 2013 support will be retired soon. More details and planning later. - DevTalk forum is out of Beta and ready for general use Link to forum: https://devtalk.blender.org/ Announcement mail: https://lists.blender.org/pipermail/bf-committers/2018-March/049280.html - We are interested in someone to help with weekly developer log https://thisweekinblenderdev.github.io Reply in this thread if you're interested. -- With best regards, Sergey Sharybin ___ Bf-committers mailing list Bf-committers@blender.org https://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Blender 2.79b Release AHOY
Arto, thanks! Now all the builds and sources are published on our FTP. Now we wait for mirrors to catch up and we can do official release! Thanks everyone! On Fri, Mar 23, 2018 at 5:53 PM, Arto Kitula <arto.kit...@gmail.com> wrote: > Housewife zippd, on ftp > > MD5 18d7c73def50d068e47034a73331f7ee > > > On 23 Mar 2018, at 9.56, Sergey Sharybin <sergey@gmail.com> wrote: > > > > Hi, > > > > Thanks Ray and Arto! > > > > Arto, we did not make decision to stop [providing .zip to my knowledge. > And > > i do not see .zip for 2.79b. Any change of getting it? > > > > On Thu, Mar 22, 2018 at 11:20 PM, Arto Kitula <arto.kit...@gmail.com> > wrote: > > > >> HousewifeOS build done > >> > >> MD5: 8cd9962ecbe8911ac1eb763076b28a8d > >> > >>> On 22 Mar 2018, at 17.03, Sergey Sharybin <sergey@gmail.com> > wrote: > >>> > >>> Clarification: > >>> > >>> Libraries SVN tag: blender-2.79a-release > >>> > >>> Sorry for the confusion! > >>> > >>> On Thu, Mar 22, 2018 at 3:58 PM, Sergey Sharybin <sergey@gmail.com > > > >>> wrote: > >>> > >>>> Hi, > >>>> > >>>> We are ready for 2.79b corrective release! > >>>> Only crucial bug fixes and regression were fixed there. Details can be > >>>> seen [1] > >>>> > >>>> Information for platform maintainers: > >>>> > >>>> - Build from the blender-2.79b-release branch, SHA > >>>> f4dc9f9d68bddaa206b692e1d077d1a1f2bb1528 > >>>> - Addons revision: 2609a1018e469dde627cfe2147ef993ee9c90f8f > >>>> - Locale revision: 1bbc9bdabe4ed26c164aef8a43ef39657dc23cfb > >>>> - Libraries SVN tag: blender-2.79b-release > >>>> > >>>> Suggested name: blender-2.79b-. Keep the same register and > >>>> everything as 'a' release. > >>>> > >>>> Make sure you're using 2.79a tag for libraries, and same CUDA verison > as > >>>> for 2.79a release. > >>>> > >>>> Put builds to usual location and let me know when they are ready. > >>>> > >>>> Tagging will happen soon after all builds are ready. > >>>> > >>>> [1] https://developer.blender.org/T54255 > >>>> > >>>> -- > >>>> With best regards, Sergey Sharybin > >>>> > >>> > >>> > >>> > >>> -- > >>> With best regards, Sergey Sharybin > >>> ___ > >>> Bf-committers mailing list > >>> Bf-committers@blender.org > >>> https://lists.blender.org/mailman/listinfo/bf-committers > >> > >> -- > >> Arto Kitula > >> arto.kit...@gmail.com > >> > >> > >> > >> > >> ___ > >> Bf-committers mailing list > >> Bf-committers@blender.org > >> https://lists.blender.org/mailman/listinfo/bf-committers > >> > > > > > > > > -- > > With best regards, Sergey Sharybin > > ___ > > Bf-committers mailing list > > Bf-committers@blender.org > > https://lists.blender.org/mailman/listinfo/bf-committers > > -- > Arto Kitula > arto.kit...@gmail.com > > > > > ___ > Bf-committers mailing list > Bf-committers@blender.org > https://lists.blender.org/mailman/listinfo/bf-committers > -- With best regards, Sergey Sharybin ___ Bf-committers mailing list Bf-committers@blender.org https://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Blender 2.79b Release AHOY
Hi, Thanks Ray and Arto! Arto, we did not make decision to stop [providing .zip to my knowledge. And i do not see .zip for 2.79b. Any change of getting it? On Thu, Mar 22, 2018 at 11:20 PM, Arto Kitula <arto.kit...@gmail.com> wrote: > HousewifeOS build done > > MD5: 8cd9962ecbe8911ac1eb763076b28a8d > > > On 22 Mar 2018, at 17.03, Sergey Sharybin <sergey@gmail.com> wrote: > > > > Clarification: > > > > Libraries SVN tag: blender-2.79a-release > > > > Sorry for the confusion! > > > > On Thu, Mar 22, 2018 at 3:58 PM, Sergey Sharybin <sergey@gmail.com> > > wrote: > > > >> Hi, > >> > >> We are ready for 2.79b corrective release! > >> Only crucial bug fixes and regression were fixed there. Details can be > >> seen [1] > >> > >> Information for platform maintainers: > >> > >> - Build from the blender-2.79b-release branch, SHA > >> f4dc9f9d68bddaa206b692e1d077d1a1f2bb1528 > >> - Addons revision: 2609a1018e469dde627cfe2147ef993ee9c90f8f > >> - Locale revision: 1bbc9bdabe4ed26c164aef8a43ef39657dc23cfb > >> - Libraries SVN tag: blender-2.79b-release > >> > >> Suggested name: blender-2.79b-. Keep the same register and > >> everything as 'a' release. > >> > >> Make sure you're using 2.79a tag for libraries, and same CUDA verison as > >> for 2.79a release. > >> > >> Put builds to usual location and let me know when they are ready. > >> > >> Tagging will happen soon after all builds are ready. > >> > >> [1] https://developer.blender.org/T54255 > >> > >> -- > >> With best regards, Sergey Sharybin > >> > > > > > > > > -- > > With best regards, Sergey Sharybin > > ___ > > Bf-committers mailing list > > Bf-committers@blender.org > > https://lists.blender.org/mailman/listinfo/bf-committers > > -- > Arto Kitula > arto.kit...@gmail.com > > > > > ___ > Bf-committers mailing list > Bf-committers@blender.org > https://lists.blender.org/mailman/listinfo/bf-committers > -- With best regards, Sergey Sharybin ___ Bf-committers mailing list Bf-committers@blender.org https://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Blender 2.79b Release AHOY
Clarification: Libraries SVN tag: blender-2.79a-release Sorry for the confusion! On Thu, Mar 22, 2018 at 3:58 PM, Sergey Sharybin <sergey@gmail.com> wrote: > Hi, > > We are ready for 2.79b corrective release! > Only crucial bug fixes and regression were fixed there. Details can be > seen [1] > > Information for platform maintainers: > > - Build from the blender-2.79b-release branch, SHA > f4dc9f9d68bddaa206b692e1d077d1a1f2bb1528 > - Addons revision: 2609a1018e469dde627cfe2147ef993ee9c90f8f > - Locale revision: 1bbc9bdabe4ed26c164aef8a43ef39657dc23cfb > - Libraries SVN tag: blender-2.79b-release > > Suggested name: blender-2.79b-. Keep the same register and > everything as 'a' release. > > Make sure you're using 2.79a tag for libraries, and same CUDA verison as > for 2.79a release. > > Put builds to usual location and let me know when they are ready. > > Tagging will happen soon after all builds are ready. > > [1] https://developer.blender.org/T54255 > > -- > With best regards, Sergey Sharybin > -- With best regards, Sergey Sharybin ___ Bf-committers mailing list Bf-committers@blender.org https://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] Blender 2.79b Release AHOY
Hi, We are ready for 2.79b corrective release! Only crucial bug fixes and regression were fixed there. Details can be seen [1] Information for platform maintainers: - Build from the blender-2.79b-release branch, SHA f4dc9f9d68bddaa206b692e1d077d1a1f2bb1528 - Addons revision: 2609a1018e469dde627cfe2147ef993ee9c90f8f - Locale revision: 1bbc9bdabe4ed26c164aef8a43ef39657dc23cfb - Libraries SVN tag: blender-2.79b-release Suggested name: blender-2.79b-. Keep the same register and everything as 'a' release. Make sure you're using 2.79a tag for libraries, and same CUDA verison as for 2.79a release. Put builds to usual location and let me know when they are ready. Tagging will happen soon after all builds are ready. [1] https://developer.blender.org/T54255 -- With best regards, Sergey Sharybin ___ Bf-committers mailing list Bf-committers@blender.org https://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Blender 2.79a failed to build with gcc 8.0.1
Hi,
You should be able to fix this compilation error by changing it to: return
_mm_castsi128_ps(_mm_shuffle_epi32(a, _MM_SHUFFLE(i3, i2, i1, i0)));
Patch version is: https://hastebin.com/efopofoboy.diff
Let me know if it indeed fixes the problem.
On Sat, Mar 17, 2018 at 8:02 PM, Luya Tshimbalanga <l...@fedoraproject.org>
wrote:
> On 2018-03-17 12:32 AM, PerfectionCat wrote:
> > Hi there.
> >
> > /builddir/build/BUILD/blender-2.79a/intern/cycles/kernel/../util/util_sseb.h:119:57:
> error: could not convert '_mm_shuffle_epi32(a, i3 << 6) | (i2 << 4)) |
> (i1 << 2)) | i0))' from '__m128i' {aka '__vector(2) long long int'} to
> 'const ccl::sseb' return _mm_shuffle_epi32(a, _MM_SHUFFLE(i3, i2, i1, i0));
> ^
> > make[2]: ***
> > [intern/cycles/kernel/CMakeFiles/cycles_kernel.dir/build.make:90:
> intern/cycles/kernel/CMakeFiles/cycles_kernel.dir/kernels/cpu/kernel_sse2.cpp.o]
> Error 1
> >
> >
> I don't know how to resolved that issue as debugging such codes is
> beyond my skills. It seems the rules arestricter in GCC 8 than GCC7.
> Could someone provide a patch for testing purpose?
>
> Thanks
>
>
> --
> Luya Tshimbalanga
> Graphic & Web Designer
> E: l...@fedoraproject.org
> W: http://www.coolest-storm.net
>
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> https://lists.blender.org/mailman/listinfo/bf-committers
>
--
With best regards, Sergey Sharybin
___
Bf-committers mailing list
Bf-committers@blender.org
https://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Blender modeling and viewport perfomance in blender 2.8
Hi, It usually helps to mention your hardware configuration and OS when talking about performance. Giving exact .blend file (or telling which of the existing demo files you use) also helps understanding what's exactly going on. General answer is: we did not focus on fine-tuning performance yet, but rather were putting bigger foundations. For ultimate performance we are just starting to benchmack bottlenecks and address them. As for the quado: you're comparing Maxwell M5000 card with Pascal GTX1060. The latter one is newer generation GPU. Also, quadros are running on lower clockrates and using lower memory frequencies. This (together with ECC memory and double-precision floating support) makes them reliable. Quadros in general are slower than corresponding GTXes. That being said, Blender should for sure be usable on all GPUs. On Tue, Mar 6, 2018 at 12:06 PM, Alberto Velázquez <alberto3d.1...@gmail.com > wrote: > Hi > > I want to ask about Blender perfomance in the future Blender2.8, actually > Blender have problems editing meshes with medium triangles (50k triangles) > models that actually you can see in videogames without problems. > > It's a recurrent topic in Blender community, the problems with editing > perfomance in Blender, the perfomance in big scenes and seeing models with > a lot of triangles. The lack of proxies to reduce load (or use LOD for > proxies), other users talk about problems when blender have a few > characters,... > > The main points are: > > - Bad perfomance editing meshes with 50k triangles. When sculpting this > meshes is not a big problem ¿Will we see improvements in this part? Other > software can edit meshes with millions of triangles without problems ¿It's > a problem of the lack of multrithreading CPU, GPU perfomance, bad > implementation or an intrinsic blender problem? > > - Viewport perfomance in object mode with dense meshes or a lot of objects. > I understand that workbench could address this problem making new view > modes to sculpt and modeling, but until we have information about it ¿Will > we see a optimized mode of view with minimal perfomance impact and > improvements in this part? > > - ¿Could we see a proxy system to reduce load in big scenes? maybe a simple > LOD option that allow to see only LODs in viewport instead of the full > meshes. > > - Some users have problems with their graphic cards, e. g. M5000, a really > expensive card, have worst perfomance that a GTX1060 ¿It's a specific > problem of some cards or lack of support of some libraries? > > > Warm Regards > ___ > Bf-committers mailing list > Bf-committers@blender.org > https://lists.blender.org/mailman/listinfo/bf-committers > -- With best regards, Sergey Sharybin ___ Bf-committers mailing list Bf-committers@blender.org https://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Blender 2.79a Release AHOY
Hi, Following thins are DONE: - All builds are on our ftp server. - 2.79a release has been tagged in git. - sources tgz is updated to our download site as well. Now we need to wait for the mirrors to syn changes and then we can do a release. NOTE: This mail is NOT a statement of final release ready. It is only a report that platform maintainers finished their tasks. On Wed, Feb 21, 2018 at 10:00 PM, Ray Molenkamp <r...@lazydodo.com> wrote: > Windows builds are done, please validate the md5's before using the files > > --Ray > > > On 2/21/2018 9:08 AM, Sergey Sharybin wrote: > > Hi, > > > > We are ready for2.79a release! > > > > Information for platform maintainers: > > > > - Build from the blender-2.79a-release branch, SHA > > 8928d99270ff0dcafe23605221f271308e33f297 > > - Addons revision: bd60e89fa04fc037377db48694770f283eb3cafd > > - Locale revision: 1bbc9bdabe4ed26c164aef8a43ef39657dc23cfb > > - Libraries SVN tag: blender-2.79a-release > > > > Suggested name: blender-2.79a- > > > > Make sure you're using 2.79a tag for libraries. > > > > Put builds to usual location and let me know when they are ready. > > > > Tagging will happen soon after all builds are ready. > > > > ___ > Bf-committers mailing list > Bf-committers@blender.org > https://lists.blender.org/mailman/listinfo/bf-committers > -- With best regards, Sergey Sharybin ___ Bf-committers mailing list Bf-committers@blender.org https://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] Blender 2.79a Release AHOY
Hi, We are ready for2.79a release! Information for platform maintainers: - Build from the blender-2.79a-release branch, SHA 8928d99270ff0dcafe23605221f271308e33f297 - Addons revision: bd60e89fa04fc037377db48694770f283eb3cafd - Locale revision: 1bbc9bdabe4ed26c164aef8a43ef39657dc23cfb - Libraries SVN tag: blender-2.79a-release Suggested name: blender-2.79a- Make sure you're using 2.79a tag for libraries. Put builds to usual location and let me know when they are ready. Tagging will happen soon after all builds are ready. -- With best regards, Sergey Sharybin ___ Bf-committers mailing list Bf-committers@blender.org https://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] Booleans: Carve solver has been removed
Hi everyone, Just a quick update on Boolean modifier. For a long time we had two different solvers: Carve and BMesh. Now BMesh solver matured to the state when it's same or better than Carve. Surely, it has some corner cases when it fails, but so does Carve. It is just more efficient to stick to a single solver, which is fully controlled by us, and much better maintained (last commit to Carve upstream was done years ago). So here by i declare bye-bye Carve, thanks everyone who helped maintaining it in Blender. Now i'll be joining BMesh boolean department, helping resolving remaining bugs and corner cases. Also thanks everyone (especially Campbell) who made BMesh boolean solver! -- With best regards, Sergey Sharybin ___ Bf-committers mailing list Bf-committers@blender.org https://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] GSoC 2018 BVH8
Hi, Answers are inlined. On Tue, Jan 30, 2018 at 11:56 AM, Brecht Van Lommel < brechtvanlom...@pandora.be> wrote: > Hi, > > On Tue, Jan 30, 2018 at 9:32 AM, Sergey Sharybin <sergey@gmail.com> > wrote: > > > Was more like discussed, and agreed that it's still lots of open ends in > > there? > > > > With the current state it is not really convincing that it's THE way to > > go.It will become THE way to go when we will know answers to those open > > ends, which will not increase already tedious burden of GPU support. > > > The way I see it is that there is still a lot of work, not so much open > questions. > The amount of work of is only measurable once you have a goal. What is the goal here: ditch everything and replace with Embree? It has consequences on a longer term. I do get your point about not duplicating code from Embree when they already have done everything. But, this is only true for CPU. When you are mixing GPU support into account, things becomes less obvious. Consequences i see for GPU: - We would need to have some way of "extracting" BVH from Embree. Surely, this could be solved with some more comprehensive Embree API. So maybe at the end of a day it's not that much of a code even. But this is to be done, and ONLY to be done for GPU. Which leads to potential issues of either Embree changing something in their library which will break our "extraction", or that we will make some improvement in BVH which will break GPU. - We need to mimic primitives intersection from Embree. It is POSSIBLE to use own intersection code in Embree, but this is NOT recommended due to performance impacts. So if we want ultimate performance on CPU, we would have to accept DUPLICATION of code for GPU (remember, the idea of using Embree was to avoid code or work duplication, which is violated here). - We need to mimic OBB BVH intersection on GPU. Surely, we do have SOME code for this, but i'm not sure orientation is still denoted the same way as it originally was in Embree, and will it ever change? If Embree changes something related on this, we would need to duplicate work for GPU once again. - We need to support proper motion BVH on GPU. While on CPU we do have nodes interpolation "for free" with Embree, we would NEED to re-implement this on GPU. Again, duplicated work and code, which defeats original idea of reducing burden of maintaining own BVH builder/traversal. Or, it brings us back to question: do we care about GPU? Or do we just stagnate at current state, and do not improve rays intersection at all? > Well, sure, as Stefan mentioned above, there is no way for a custom node > > builder function to know orientation for hair BVH, but i don't see why > > would AABB BVH take long time to do such a test. > > > > Further, (as Stefan mentioned already), you would HAVE to implement that > in > > one way or another in order to use BVH built by Embree on GPU. > > > > I don't think we have to implement 8-wide BVH traversal for the GPU, or any > of the SSE optimizations or CPU specific tuning. > Well, maybe not 8 wide, but what about 4? Is it possible to extract GOOD QUALITY 2-wide BVH from Embree? To my knowledge, for final result they removed binary BVH support, but i'm not sure they are building binary first and then merge, or if they build 4-BVH to begin with. If it's not possible to extract binary BVH, then we would need to have some node splitting implemented on our side. Doing simple split will degrade quality of BVH, defeating the whole idea of using Embree for higher quality BVH on GPU. Or we are doomed to (re)implement some smart heuristics to find a good split of the node. I'm not sure what you would expect from such a test. If it's slower than > Embree's traversal, then we can attribute that to our implementation not > being tuned as much as theirs, which is what I would expect. If it's > faster, then that would be interesting but it seems unlikely to happen? > I would expect better understanding what is the actual problem, and see what consequences it causes on a bigger picture. Currently all the work i see is more like "let's go full-speed hacks and what not for Embree on CPU, and GPU support we will hack on later, and hope for the best in there". > For me the big reason to adopt Embree is so we don't have to do all this > optimizations for the CPU, we don't have to worry about SSE, AVX, 16-wide, > pack triangle intersection, ray packet traversal, etc. > Yes, this is indeed good thing. > > And last but not least here, you would HAVE to duplicate Embree code in > one > > way or another: primitives intersection on GPU is something you would > HAVE > > to re-implement. > > > > Yes, but we only need a simpler scalar version of it, with one BVH layout > t
Re: [Bf-committers] GSoC 2018 BVH8
with the GPU: > > > 6. Using Embree’s ray stream API for the CPU split kernel. > > > 7. Embree’s built-in displacement. > > > 8. Embree’s quad primitive. > > > 9. Compare Embree’s subdivision implementation to Cycles’ and use it if > > > it’s better. The on-demand cache could help reduce memory usage at the > > > expense of performance. > > > > > > Feel free to take over any of these tasks. I would be happy to work on > > > them myself, but as it stands I can’t make any promises regarding a > time > > > line. The embree integration in its current state is sufficient for our > > > current production needs. I don’t expect to have a lot of spare time > for > > > extra polish in the next few months. > > > > > > The current state of my Embree integration is here: > > > https://git.blender.org/gitweb/gitweb.cgi/blender.git/ > > > shortlog/refs/heads/cycles_embree <https://git.blender.org/ > > > gitweb/gitweb.cgi/blender.git/shortlog/refs/heads/cycles_embree> > > > > > > It does rely on a patched version of Embree which you can find in this > > > branch: > > > https://github.com/skwerner/embree/tree/cycles_compatible > > > > > > Don’t hesitate to ask if you have any questions about this. > > > > > > -Stefan > > > > > > > On 29. Jan 2018, at 18:58, Brecht Van Lommel < > > brechtvanlom...@pandora.be> > > > wrote: > > > > > > > > Hi Anton, > > > > > > > > We're planning to move to Embree, so improving our existing BVH > builder > > > and traversal is not the best use of time. > > > > https://lists.blender.org/pipermail/bf-committers/2017- > > > November/048936.html <https://lists.blender.org/ > > > pipermail/bf-committers/2017-November/048936.html> > > > > > > > > However a lot of work is still needed to get the Embree integration > > > stable, and I imagine whatever the state will be this summer, there > will > > be > > > a lot room for improvement. Finding optimizations in the integration, > > > memory usage reductions, etc. Some of the bigger topics would be: > > > > * Use Embree for building the GPU BVH, so we can remove our own > > builder. > > > > * For subdivision surfaces, implement more memory efficient grid > > > primitive to intersect directly. > > > > * Optimizations for tracing short rays on a single object for > > subsurface > > > scattering, bevel, curvature. > > > > > > > > Stefan, do you have an idea about which tasks will be open still this > > > summer? > > > > > > > > Regards, > > > > Brecht. > > > > > > > > On Sun, Jan 28, 2018 at 11:07 PM, Антон Гавриков < > > > gavrikovantonk...@gmail.com <mailto:gavrikovantonk...@gmail.com>> > wrote: > > > > Hello, I worked on this (https://developer.blender.org/D2875 < > > > https://developer.blender.org/D2875>) project as a > > > > summer intern in Intel. I would like to know if there is any interest > > in > > > > working on this project in GSoC 2018. Or maybe there are any similar > > > tasks > > > > to optimize Cycles for new architectures. > > > > > > > > Regards, > > > > > > > > Anton. > > > > ___ > > > > Bf-committers mailing list > > > > Bf-committers@blender.org <mailto:Bf-committers@blender.org> > > > > https://lists.blender.org/mailman/listinfo/bf-committers < > > > https://lists.blender.org/mailman/listinfo/bf-committers> > > > > > > > > > > ___ > > > Bf-committers mailing list > > > Bf-committers@blender.org > > > https://lists.blender.org/mailman/listinfo/bf-committers > > > > > > > > > > > -- > > With best regards, Sergey Sharybin > > ___ > > Bf-committers mailing list > > Bf-committers@blender.org > > https://lists.blender.org/mailman/listinfo/bf-committers > > > ___ > Bf-committers mailing list > Bf-committers@blender.org > https://lists.blender.org/mailman/listinfo/bf-committers > -- With best regards, Sergey Sharybin ___ Bf-committers mailing list Bf-committers@blender.org https://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] GSoC 2018 BVH8
I do not see any particular reason why Embree can not provide orientation for the bounding box, or why it can't provide steps for the motion blur. Surely, then you'll need to implement ray transform to a node space on GPU (which we already have), and node interpolation (which we can easily implement). To me it's more like an API limitation, which could be easily changed. That would save us from keeping GPU's port of rtcImtersect being done every time something is changed on Embree side? On Mon, Jan 29, 2018 at 9:39 PM, Stefan Werner <stew...@gmail.com> wrote: > > > > On 29. Jan 2018, at 21:10, Sergey Sharybin <sergey@gmail.com> wrote: > > > >> 4. Extract BVH data from Embree and write GPU traversal code. > > > > To my knowledge you can provide Embree a custom node/primitive builder > > functions, so not sure what exactly "extract" mean here? > > You can, but not with full feature access. There’s no motion blur or OOBB > (for hair) > when using the separate BVH builder. To make use of those (IMHO essential) > features, > one needs to either use Embree’s own rtcIntersect calls for traversal or > extract the > raw BVH data from it like in this sample code: > https://github.com/embree/embree/blob/master/tutorials/ > bvh_access/bvh_access.cpp > > My current implementation is using rtcIntersect, so it’s not using Cycles’ > BVH > traversal code at all. To get this to the GPU, we’ll need to port > rtcIntersect > to the GPU and extract the necessary data structures from the opaque > RTCScene > pointer in order to copy them to device memory. > > -Stefan > ___ > Bf-committers mailing list > Bf-committers@blender.org > https://lists.blender.org/mailman/listinfo/bf-committers > -- With best regards, Sergey Sharybin ___ Bf-committers mailing list Bf-committers@blender.org https://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] GSoC 2018 BVH8
gt;> wrote: > > Hello, I worked on this (https://developer.blender.org/D2875 < > https://developer.blender.org/D2875>) project as a > > summer intern in Intel. I would like to know if there is any interest in > > working on this project in GSoC 2018. Or maybe there are any similar > tasks > > to optimize Cycles for new architectures. > > > > Regards, > > > > Anton. > > ___ > > Bf-committers mailing list > > Bf-committers@blender.org <mailto:Bf-committers@blender.org> > > https://lists.blender.org/mailman/listinfo/bf-committers < > https://lists.blender.org/mailman/listinfo/bf-committers> > > > > ___ > Bf-committers mailing list > Bf-committers@blender.org > https://lists.blender.org/mailman/listinfo/bf-committers > -- With best regards, Sergey Sharybin ___ Bf-committers mailing list Bf-committers@blender.org https://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] Blender 2.79a Release Candidate AHOY
Hi everyone, A huge work was done to port crucial fixes (and even more!), and we are ready for 2.79a Release Candidate now. Yes, that's right. There are so much things that changed, that we do an extra steps for corrective release, something we didn't do before. Full list of changes can be found there: https://developer.blender.org/T53683 We will work on a better release page shortly. Information for platform maintainers: - Build from the blender-2.79a-release branch, SHA 61335d853d113c827a54ab3b71e357fab2aa507a - Addons revision: cf60d1ad47622f85d8294609198de482fb8c4f22 - Locale revision: 1bbc9bdabe4ed26c164aef8a43ef39657dc23cfb - Libraries SVN tag: blender-2.79a-release Suggested name: blender-2.79a-rc- Make sure you're using 2.79a tag for libraries. Put builds to usual location and let me know when they are ready., Special thanks to Bastien Montagne for coordinating 2.79a, and everyone else who invested their time on porting fixes to the branch! -- With best regards, Sergey Sharybin ___ Bf-committers mailing list Bf-committers@blender.org https://lists.blender.org/mailman/listinfo/bf-committers
