[Bf-committers] Blender Manual Git Migration

[Brecht Van Lommel via Bf-committers]

Today the Blender manual and its translations migrated from Subversion to
Git.

See the blog post for more information:
https://code.blender.org/2023/05/sunsetting-subversion/

See the new contributing instructions here:
https://docs.blender.org/manual/en/dev/contribute/index.html

On Linux and macOS, ensure you have git-lfs installed, otherwise you may
get a repository with empty image files.

If you encounter problems, feel free to ask questions on devtalk or
blender.chat:
https://devtalk.blender.org/t/blender-manual-git-migration/29423
https://blender.chat/channel/docs

Regards,
Brecht.
___
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 finished

[Brecht Van Lommel via Bf-committers]

Hi all,

The new projects.blender.org is now online. See this blog post for
important information on how to switch over:
https://code.blender.org/2023/02/new-blender-development-infrastructure/

For developers and module members, please read the following topic
carefully. Here we will also gather feedback for issues to fix and things
to improve.
https://devtalk.blender.org/t/gitea-workflows-and-module-help-needed/27541

Thanks to everyone who helped out with this!

Regards,
Brecht.
___
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 planned for tomorrow

[Brecht Van Lommel via Bf-committers]

Hi all,

The migration from Phabricator to Gitea is planned for tomorrow (Tuesday,
February 7).

In the morning Amsterdam time, developer.blender.org and git.blender.org
will become read-only (or down entirely at times). Then a few hours later
we hope to have projects.blender.org up and running to replace both.

We will then also post more details on how to switch over, and the help
needed from modules to set up their landing pages, project boards and
issues.

Don't forget to change your Blender ID username to what you want it to be
on projects.blender.org, if you haven't already.
https://code.blender.org/2023/01/gitea-diaries-part-3/

Regards,
Brecht.
___
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] Licensing question for ported code

[Brecht Van Lommel via Bf-committers]

If you're creating proprietary software that you're going to distribute to
others, then as a general rule you can not include GPL code in that.
There's various details and debate around when exactly this applies, but
the case you give seems quite clear-cut.

Note that the Cycles code is Apache licensed which does permit this. So if
the same Perlin noise shader is there you can use that code.

On Fri, Jan 27, 2023 at 12:12 AM Joel Sjögren via Bf-committers <
bf-committers@blender.org> wrote:

> Hello developers, I have a licensing question. I have been freelancing for
> a couple of days at a company that has been using Blender's Perlin noise
> shader and needed to get identical results using Unreal Engine and HLSL
> instead.
>
> Now we are considering making a plugin for UE with various ported Blender
> shaders. Of course, given that Blender is GPL (except for files here and
> there that even have BSD 3-clause or that are partially copies of code that
> is in the public domain) it would be fine to publish such a UE plugin under
> the GPL license.
>
> But would it then be permissible for someone else to use such a plugin as a
> dependency in proprietary code? Having read up on this a little on Google
> and FSF's website, the copyleft aspect of GPL (as opposed to LGPL) is much
> more pronounced than I had realized. I also checked the licensing page on
> your Blender website and I gather that it would be permissible to use such
> a plugin to create proprietary models and artwork. But if proprietary
> *software* that has the plugin as a dependency is *redistributed*... would
> this be in any way permitted?
>
> Best wishes,
> Joel
>
> P.S. It's been a long while since I last tried using a mailing list so I
> hope you get this message in the correct way. I also hope that I found the
> most appropriate sublist to send it to. Cheers
> ___
> 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] Bump MacOS minimum requirements to 10.15 for Blender 3.5

[Brecht Van Lommel via Bf-committers]

There is not going to be an OpenGL fallback once Metal is stable. Eevee
next and the viewport compositor will require Metal, it's not just about
performance.

On Thu, Jan 5, 2023 at 5:18 PM Chuck Ocheret via Bf-committers <
bf-committers@blender.org> wrote:

> It seems to me that supporting Metal with a fallback to OpenGL for older
> versions might be equivalent to such a fallback for when a Vulkan
> implementation of the viewport gets rolled out. I have no idea how close
> that is yet. But I’m excited for an aggressive move forward to Vulkan and
> Metal since that will facilitate many new capabilities.
>
> I suppose I’m voting for the 3rd option for now, even though it might be
> more work. That is unless new features enabled by Vulkan and Metal are
> forthcoming. I suspect those are far off so Metal only offers performance
> benefits for newer platforms.
>
> ~chuck
>
> Chuck Ocheret
> http://www.linkedin.com/in/ocheret
>
>
> > On Jan 5, 2023, at 10:09 AM, Jeroen Bakker via Bf-committers <
> bf-committers@blender.org> wrote:
> >
> > Hello all,
> >
> > A few weeks ago we enabled the Metal back-end for the viewport. By
> default
> > Blender will start using OpenGL, but in the User preferences the Metal
> > backend can be enabled. The first responses and test are very positive
> and
> > currently it is very likely that Metal will be released as a secondary
> > backend in Blender 3.5.
> >
> > Currently Master is only able to build on MacOS 10.15 and above due this
> > change. The current minimum requirement is MacOS 10.13.
> >
> > So there are some options to consider here.
> > * Do we release blender 3.5 with Metal Backend?
> > * Do we bump the minimum version from 10.13 to 10.15 for Blender 3.5?
> > * Add logic in many places to make sure that 10.15 code-paths aren't used
> > when run in 10.13?
> >
> > Sergey mentioned that there are already ideas to bump the version to
> 10.15
> > for Blender 3.6. So this proposal is to do this one release earlier.
> >
> > My proposal would be to do the version bump for Blender 3.5 due to these
> > reasons.
> > Would like to have some feedback if this is acceptable.
> >
> > Jeroen.
> > ___
> > 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
>
___
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] Bump MacOS minimum requirements to 10.15 for Blender 3.5

[Brecht Van Lommel via Bf-committers]

The purpose is to make Blender compatible with OS and library versions
specified in the VFX platform.

If we are compatible with more I don't see that as a deviation, and I'm not
aware of any compatibility issue that would be caused by us supporting
macOS 10.15.

We can formally write that in the commit message.


On Thu, Jan 5, 2023 at 5:00 PM Ray Molenkamp via Bf-committers <
bf-committers@blender.org> wrote:

> I have to admit, I don't have a whole lot of experience with macs,
> I have honestly no idea of the real-world impact of a version
> bump. However, given we committed to follow the VFX platform for
> 2023/2024 which targets 11.0 for 2023 shouldn't we either :
>
> a) Follow the VFX platform and Target 11.0
>
> b) Have some rationale documented somewhere why we are deviating
> from the VFX platform by targeting 10.13 or 10.15.
>
> Following the VFX platform for just the things we liked (ie we follow
> it!. but not for the python version) hasn't worked out overly well for
> us
> in the past, and I’d rather not repeat that phase of our commitment
> to the VFX platform, so my naive grasp of the situation has me leaning
> towards option a.
>
> --Ray
>
>
>
> On 2023-01-05 8:26 a.m., Brecht Van Lommel via Bf-committers wrote:
> > I think it's reasonable to do the bump now, instead of 3 months from now
> > when we definitely have to do it. And doing it together with the VFX
> > platform updates and new Linux minimum requirements makes some sense.
> >
> > It's always unfortunate to leave behind hardware, but even macOS 10.15 is
> > already EOL and no longer receiving updates.
> >
> > On Thu, Jan 5, 2023 at 4:10 PM Jeroen Bakker via Bf-committers <
> > bf-committers@blender.org> wrote:
> >
> >> Hello all,
> >>
> >> A few weeks ago we enabled the Metal back-end for the viewport. By
> default
> >> Blender will start using OpenGL, but in the User preferences the Metal
> >> backend can be enabled. The first responses and test are very positive
> and
> >> currently it is very likely that Metal will be released as a secondary
> >> backend in Blender 3.5.
> >>
> >> Currently Master is only able to build on MacOS 10.15 and above due this
> >> change. The current minimum requirement is MacOS 10.13.
> >>
> >> So there are some options to consider here.
> >> * Do we release blender 3.5 with Metal Backend?
> >> * Do we bump the minimum version from 10.13 to 10.15 for Blender 3.5?
> >> * Add logic in many places to make sure that 10.15 code-paths aren't
> used
> >> when run in 10.13?
> >>
> >> Sergey mentioned that there are already ideas to bump the version to
> 10.15
> >> for Blender 3.6. So this proposal is to do this one release earlier.
> >>
> >> My proposal would be to do the version bump for Blender 3.5 due to these
> >> reasons.
> >> Would like to have some feedback if this is acceptable.
> >>
> >> Jeroen.
> >> ___
> >> 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
> ___
> 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] Bump MacOS minimum requirements to 10.15 for Blender 3.5

[Brecht Van Lommel via Bf-committers]

I think it's reasonable to do the bump now, instead of 3 months from now
when we definitely have to do it. And doing it together with the VFX
platform updates and new Linux minimum requirements makes some sense.

It's always unfortunate to leave behind hardware, but even macOS 10.15 is
already EOL and no longer receiving updates.

On Thu, Jan 5, 2023 at 4:10 PM Jeroen Bakker via Bf-committers <
bf-committers@blender.org> wrote:

> Hello all,
>
> A few weeks ago we enabled the Metal back-end for the viewport. By default
> Blender will start using OpenGL, but in the User preferences the Metal
> backend can be enabled. The first responses and test are very positive and
> currently it is very likely that Metal will be released as a secondary
> backend in Blender 3.5.
>
> Currently Master is only able to build on MacOS 10.15 and above due this
> change. The current minimum requirement is MacOS 10.13.
>
> So there are some options to consider here.
> * Do we release blender 3.5 with Metal Backend?
> * Do we bump the minimum version from 10.13 to 10.15 for Blender 3.5?
> * Add logic in many places to make sure that 10.15 code-paths aren't used
> when run in 10.13?
>
> Sergey mentioned that there are already ideas to bump the version to 10.15
> for Blender 3.6. So this proposal is to do this one release earlier.
>
> My proposal would be to do the version bump for Blender 3.5 due to these
> reasons.
> Would like to have some feedback if this is acceptable.
>
> Jeroen.
> ___
> 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

[Bf-committers] New minimum requirements for Linux builds

[Brecht Van Lommel via Bf-committers]

Hi all,

Blender 3.5 will have new minimum required versions for Linux
distributions, following the VFX platform 2023. See here for details:
https://wiki.blender.org/wiki/Reference/Release_Notes/3.5#Compatibility
https://developer.blender.org/T102440

The buildbot infrastructure changes are expected to happen this Monday,
switching to Rocky Linux 8. After this Blender 3.5 daily builds will stop
working on older distributions.

Blender 3.4, 3.3 LTS and 2.93 LTS are not affected, and will continue to be
built on CentOS 7.

Regards,
Brecht.
___
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] Blender file version didn't change

[Brecht Van Lommel via Bf-committers]

This is normal, many DNA changes are automatically handled and do not
require the file version to be changed..

On Sat, Jul 9, 2022 at 9:49 PM Holger Machens via Bf-committers
 wrote:
>
> Hey guys,
>
>
>
> not sure if that was intended, but the DNA file version didn't change
> with the 3.2.1 corrective release, even though structs have been changed.
>
>
>
> Cheers
>
>homac
> ___
> 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

[Brecht Van Lommel via Bf-committers]

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
> ___
> 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

[Brecht Van Lommel via Bf-committers]

For reference there is more discussion about this in the two tasks:
2021: https://developer.blender.org/T83246
2020: https://developer.blender.org/T68774

My preference is still to track the full VFX platform, including the Python
version. However I know I'm in the minority on this, and I'm not expecting
that to change.

I don't think it's practical to support multiple Python versions. For
add-ons and particularly those with binaries, supporting both Python
versions would be more work. Likely many of the add-ons would just not be
tested and not work with the older Python version.

I think other libraries do matter. We still wanted to switch to OpenColorIO
2 around the same time as other apps for example, regardless if file
compatibility is a goal of the VFX platform. It should be a goal for us.
Further some of these libraries have Python APIs that we'd like to expose,
like pyopenvdb.

In my opinion we should stick to the VFX platform by default and make
exceptions as needed. We don't need to retread the Python discussion every
year, the situation is still the same and it's reasonable to assume we
continue being incompatible there. For other libraries, if it's not causing
incompatibility I don't even see that as deviating from the VFX platform.
If it does lead to incompatibility, I think we should take that into
consideration.

On Mon, Jan 17, 2022, 15:16 Ray Molenkamp via Bf-committers <
bf-committers@blender.org> wrote:

> > I don't really feel great about Python
> > being the only exception allowed to be digressed
> > from the platform.
>
> I think you're misunderstanding the VFX Platform goals,
> it has nothing to do with asset compatibility throughout
> the pipeline. Otherwise, it would specify what formats
> would have to be supported in OIIO, or what version
> of blosc should be used for OpenVDB since using the
> "wrong" blosc version will cause files to be unreadable
> by older versions. It does none of these things.
>
> No, what it sets out to do is define a tightly controlled binary
> runtime environment, if I link my binary addon to the library
> versions in the platform, I will be able to load it into the host
> applications that follow the platform without issues.
>
> If we break on python, none of the other things in the platform
> matter, With the only notable exception being the glibc version
> I suppose.
>
> Any commitments we may make to the platform while simultaneously
> breaking on python are pointless, so no, that case I make is not
> "Only python is/should be the exception", the case is, "If we
> break on python there's no need to commit to anything else, so
> best not to make any commitments."
>
> --Ray
>
> ___
> 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] My login and commit rights

[Brecht Van Lommel via Bf-committers]

You appear to still be a member of the Documentation and Translations
projects, which gives you commit rights to those subversion repositories.

The credentials for subversion are your developer.blender.org username and
password. If you forgot your developer.blender.org password you should be
able to reset it yourself.

If none of that works, post the exact error message that you get.


On Mon, Nov 22, 2021 at 3:00 PM Hoang Tran via Bf-committers <
bf-committers@blender.org> wrote:

> To the attention of Document (User Manual Translation) administrator,
>
> Hi, my name is Hoang Duy Tran with email: hoangduytran1...@googlemail.com
> , I haven't been very active
> lately due to being busy on other project, and now I'm ready to go back to
> translating Blender Reference Manual to Vietnamese. I tried to commit some
> changes this morning and seen the error regarding to the authentication
>
> Authentication realm:  Subversion
> Username: hoangduytran
>
> Could you please reminds me/or allowing me to reset my credentials so I
> can commit changes to the 'Blender_manual.po'.
>
> Best Regards,
> Hoang Tran
>
> ___
> 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] Nightly builds on Steam and Snap stores

[Brecht Van Lommel via Bf-committers]

If renaming would break things for users that have already switched to
these channels, then I guess it's not worth changing the name.

For the docs, probably most discoverable would be to have a new page in the
menu on builder.blender.org for Steam and Snap? Seems like the easiest way
for users to find out about this, they will not be browsing the wiki.
Prettiest would be to embed the information there directly, simpler would
be to link to the wiki page.

Most of the "Downloading From Buildbot" section I would leave out. I don't
think we have to document things that should be obvious from looking at the
web page.

On Fri, Jul 16, 2021 at 9:08 PM James Monteath  wrote:

>  Hi Brecht,
>
> * Daily Build - Alpha
>> * Daily Build - 2.93 LTS - Candidate
>> * Daily Build - 2.83 LTS - Candidate
>
>
> I will see what I can do with the names.
> They cannot be renamed but only replaced.
> Can take some time to coordinate a change since the Steam
> branch names are currently used by the Buildbot build pipeline.
>
> I'm also not sure what that launcher option is for? If it's for
>> blender-launcher.exe, that should just always be used.
>
>
> Still investigating how to add launchers correctly to Steam on BETA
> branches.
> Not really obvious and I can easily mess up all the other branches
> and the current live default app if not careful.
> I can work on this once Ray is happy with it.
>
> Thanks !
>
> On Fri, Jul 16, 2021 at 6:35 PM Brecht Van Lommel via Bf-committers <
> bf-committers@blender.org> wrote:
>
>> Maybe we can think of better names for Steam? "autotest" and "vdev" are
>> not
>> terminology for users. I would try to match the buildbot:
>>
>> * Daily Build - Alpha
>> * Daily Build - 2.93 LTS - Candidate
>> * Daily Build - 2.83 LTS - Candidate
>>
>> I'm also not sure what that launcher option is for? If it's for
>> blender-launcher.exe, that should just always be used.
>>
>> On Fri, Jul 16, 2021 at 5:41 PM James Monteath via Bf-committers <
>> bf-committers@blender.org> wrote:
>>
>> > Hi all,
>> >
>> > Nightly builds are now available on Steam (BETA) test branches and Snap
>> > channels.
>> >
>> > **Steam**
>> > The automated delivery of *2.93 / 2.83 LTS - Candidates*
>> > and *3.0 - Alpha* builds are now accessible via Steam (BETA) Test
>> branches.
>> > Blender nightly builds are available for all supported platforms on
>> Steam.
>> >
>> > Using Steam Test Branches:
>> >
>> >
>> https://wiki.blender.org/wiki/Infrastructure/BuildBot#Using_Steam_Test_Branches
>> >
>> > **Snap**
>> > For Linux systems with Snap support, *2.93 / 2.83 LTS - Candidates*
>> > and *3.0 - Alpha *builds can be refreshed using channels.
>> >
>> > Using Snap Test Channels:
>> >
>> >
>> https://wiki.blender.org/wiki/Infrastructure/BuildBot#Using_Snap_Test_Channels
>> >
>> > Cheers !
>> > --
>> > James Monteath - ja...@blender.org - www.blender.org
>> > Blender DevOps Engineer
>> > ___
>> > 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
>>
>
___
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] Nightly builds on Steam and Snap stores

[Brecht Van Lommel via Bf-committers]

Maybe we can think of better names for Steam? "autotest" and "vdev" are not
terminology for users. I would try to match the buildbot:

* Daily Build - Alpha
* Daily Build - 2.93 LTS - Candidate
* Daily Build - 2.83 LTS - Candidate

I'm also not sure what that launcher option is for? If it's for
blender-launcher.exe, that should just always be used.

On Fri, Jul 16, 2021 at 5:41 PM James Monteath via Bf-committers <
bf-committers@blender.org> wrote:

> Hi all,
>
> Nightly builds are now available on Steam (BETA) test branches and Snap
> channels.
>
> **Steam**
> The automated delivery of *2.93 / 2.83 LTS - Candidates*
> and *3.0 - Alpha* builds are now accessible via Steam (BETA) Test branches.
> Blender nightly builds are available for all supported platforms on Steam.
>
> Using Steam Test Branches:
>
> https://wiki.blender.org/wiki/Infrastructure/BuildBot#Using_Steam_Test_Branches
>
> **Snap**
> For Linux systems with Snap support, *2.93 / 2.83 LTS - Candidates*
> and *3.0 - Alpha *builds can be refreshed using channels.
>
> Using Snap Test Channels:
>
> https://wiki.blender.org/wiki/Infrastructure/BuildBot#Using_Snap_Test_Channels
>
> Cheers !
> --
> James Monteath - ja...@blender.org - www.blender.org
> Blender DevOps Engineer
> ___
> 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] Blender 2.93 Released!

[Brecht Van Lommel via Bf-committers]

No, there are no such plans.

On Thu, Jun 24, 2021 at 8:47 AM Ryan Inch via Bf-committers <
bf-committers@blender.org> wrote:

> @ The core developers considering this repository idea.
> With this new online add-on repository you are proposing, you have
> talked about unifying add-on distribution, so I feel I have to ask, are
> there any plans to allow only add-ons from this repository to run in
> Blender or any other restriction above and beyond what already exists?
> ___
> 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] Bf-committers Digest, Vol 953, Issue 1

[Brecht Van Lommel via Bf-committers]

On Sat, Jun 19, 2021 at 8:13 AM Ryan Inch via Bf-committers <
bf-committers@blender.org> wrote:

> If the bundled add-ons were moved out of Blender and into an online
> repository each user would have to explicitly search for and download
> them instead of having them ready to be used out of the box.
>

You can imagine the exact same UI as in the preferences now, but instead it
gets the add-ons from an online repository.

In practice some things in the UI would change, but installing add-ons does
not have to take more steps.
___
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] Blender 2.93 Released!

[Brecht Van Lommel via Bf-committers]

There are certainly challenges implementing such a system, though it's been
done many times in other applications. It's too early to go into such
details, it's not clear this will even happen or when.

On Thu, Jun 17, 2021 at 10:14 PM Dan McGrath 
wrote:

> Hi,
>
> For an official online repository that is integrated into Blender, users
>> would not notice much difference compared to bundled add-ons. I think it
>> would be valuable to have a way for more developers to share their add-ons
>> in the same way.
>>
>
> Out of curiosity, where and how were you thinking of hosting this
> repository? I would suggest our Google workspace area, due to the ACL,
> accountability and immutability of their system, but I don't know that the
> team would prefer that over S3 or self hosting.
>
> If self hosted, what about the security of this? A compromise of a binary
> is trickier; the binary rarely changes, has well known checksums, is signed
> (on Win/Mac) and at least goes through mirrors and Microsoft which surely
> have excellent monitoring for unusual behaviour and known malware. If you
> start self-hosting auto-updating python code, files are directly uploaded
> into users' networks and devices. You bypass a lot of that built in
> security in our delivery pipeline in a way I don't know you can easily
> compensate for, not to mention all of the bandwidth costs which are already
> a challenge to our gigabit link.
>
> --
> Cheers,
> Danny
>
> --
> Danny McGrath - danmcgrath...@gmail.com
> GPG key: EDF6 AFF5 2086 F93A 1F59 36A5 44B6 26F3 6968 71CA
>
___
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] Blender 2.93 Released!

[Brecht Van Lommel via Bf-committers]

On Thu, Jun 17, 2021 at 7:51 AM Ryan Inch via Bf-committers <
bf-committers@blender.org> wrote:

> @Brecht
> As to UI/UX design, add-ons use mostly Blender widgets, so their UIs are
> almost 100% compatible with the rest of blender, and each add-on must be
> reviewed before being included with Blender, and therefore, if their UX
> was incompatible, they wouldn't be accepted.
>

Add-ons are reviewed once, mostly to see if they are useful and don't have
significant design or implementation issues. The UI/UX is not reviewed the
same way. Many of them would need to go through more iterations or get
significant design changes to be accepted in core Blender.


> This was written before your latest email, but I feel it still has many
> good points.  One of the things consistent in both emails is your desire
> for add-ons to be moved to an online repository, however, there are
> already several online repositories that feature add-ons (one of which
> is the Blender Market) and it seems obvious to me that adding another
> into the mix is far less valuable than bundling them with Blender.
>

For an official online repository that is integrated into Blender, users
would not notice much difference compared to bundled add-ons. I think it
would be valuable to have a way for more developers to share their add-ons
in the same way.


> Interestingly enough, add-ons are much better represented in the release
> notes up until 2.92, although never in their own section, which I might
> expect given the unique position they hold.
>

I don't see what changed? Add-ons have had their own page in the wiki
release notes for a very long time, and in the blender.org release notes I
only see an occasional mention of a new add-on.



> Ryan
>
> On 2021-06-12 06:00 AM, bf-committers-requ...@blender.org wrote:
> > Date: Fri, 11 Jun 2021 16:44:40 +0200
> > From: Dalai Felinto
> > To: bf-blender developers
> > Subject: Re: [Bf-committers] Blender 2.93 Released!
> > Message-ID:
> >qf-2h...@mail.gmail.com>
> > Content-Type: text/plain; charset="UTF-8"
> >
> > As for the "fancy" release notes. Not everything that is in the wiki
> shows
> > up there.
> >
> > The communication team makes a selection on what is worth showing, what
> to
> > simply mention, and what to leave only to the wiki. The "Blender Features
> > in 5 minutes" and the reel editors also reverse the right to pick and
> > choose what is highlighted.
> >
> > -Dalai-
> > --------
> > Dalai Felinto -da...@blender.org  -www.blender.org
> > Blender Development Coordinator
> > Buikslotermeerplein 161, 1025 ET Amsterdam, the Netherlands
> >
> >
> > Op vr 11 jun. 2021 om 15:11 schreef Brecht Van Lommel via Bf-committers <
> > bf-committers@blender.org>:
> >
> >> Personally, I wouldn't change this.
> >>
> >> Add-ons authors are credited in the add-on preferences, where you go to
> >> enable the add-on. The fact that they are bundled rather than installed
> >> from an online repository (which is what we should do eventually) makes
> >> little practical difference I think.
> >>
> >> For the release notes, I don't think we should be putting much emphasis
> on
> >> add-ons that often have a UI/UX and design different than core Blender,
> >> usually created by individuals without review. The freedom to do that
> >> creates very useful functionality and leads to fast development, but I
> >> wouldn't market that as part of Blender the product in the same way.
> >>
> >> The way I see it is that as an add-on author you get both the freedom
> and
> >> the responsibility for development, docs, and marketing. If anything we
> >> should decouple such things more, rather than integrating them.
> >>
> >> On Fri, Jun 11, 2021 at 6:07 AM Ryan Inch via Bf-committers <
> >> bf-committers@blender.org> wrote:
> >>
> >>> Hi Dalai,
> >>> I'm not talking about an add-on in particular, I'm referring to add-ons
> >>> in general.
> >>>
> >>> In regard to your first point, we are agreed that the credit gen script
> >>> is skipping add-ons; however, from what you've shown me, it looks like
> >>> it would be easy to support.  So I'm wondering why it is that add-ons
> >>> are being skipped and what can be done to correct it for the 2.93
> >> release?
> >>> In regard to your second point, I am aware that it is the
> responsibility
> >>> of the developer to docume

Re: [Bf-committers] Blender 2.93 Released!

[Brecht Van Lommel via Bf-committers]

To give a bit more context to what I wrote, since I got some comments about
this.

What I am arguing for is that the BF should invest in an online add-on
repository and API (including API stability), while giving control and
responsibility to add-on developers. I believe that will give a better
outcome for users and most open-source add-on developers, many of whom
develop add-ons not bundled with Blender. Credits and promotion can then be
on a web page dedicated to the add-on.

As long as add-ons are bundled it's not a bad thing to promote them or put
the authors in the credits. It's just not where I see things going long
term.


On Fri, Jun 11, 2021 at 3:11 PM Brecht Van Lommel 
wrote:

> Personally, I wouldn't change this.
>
> Add-ons authors are credited in the add-on preferences, where you go to
> enable the add-on. The fact that they are bundled rather than installed
> from an online repository (which is what we should do eventually) makes
> little practical difference I think.
>
> For the release notes, I don't think we should be putting much emphasis on
> add-ons that often have a UI/UX and design different than core Blender,
> usually created by individuals without review. The freedom to do that
> creates very useful functionality and leads to fast development, but I
> wouldn't market that as part of Blender the product in the same way.
>
> The way I see it is that as an add-on author you get both the freedom and
> the responsibility for development, docs, and marketing. If anything we
> should decouple such things more, rather than integrating them.
>
> On Fri, Jun 11, 2021 at 6:07 AM Ryan Inch via Bf-committers <
> bf-committers@blender.org> wrote:
>
>> Hi Dalai,
>> I'm not talking about an add-on in particular, I'm referring to add-ons
>> in general.
>>
>> In regard to your first point, we are agreed that the credit gen script
>> is skipping add-ons; however, from what you've shown me, it looks like
>> it would be easy to support.  So I'm wondering why it is that add-ons
>> are being skipped and what can be done to correct it for the 2.93 release?
>>
>> In regard to your second point, I am aware that it is the responsibility
>> of the developer to document changes in the wiki release notes, I do so
>> for every release, and I thank you for your willingness to help with any
>> problems accessing the wiki.  I was, however, referring to the fancier
>> release notes [1] that are compiled from the wiki release notes, and
>> that these have been lacking a section for add-ons recently.  So, what
>> is required to have an add-ons section added to the 'fancy' release notes?
>>
>> Ryan
>>
>> [1] https://www.blender.org/download/releases/2-93/
>>
>> On 2021-06-07 06:00 AM, bf-committers-requ...@blender.org wrote:
>> > Date: Mon, 7 Jun 2021 10:05:36 +0200
>> > From: Dalai Felinto
>> > To: bf-blender developers
>> > Subject: Re: [Bf-committers] Blender 2.93 Released!
>> > Message-ID:
>> >   > zavhavyzc5rws4jbbg1m...@mail.gmail.com>
>> > Content-Type: text/plain; charset="UTF-8"
>> >
>> > Hi Ryan,
>> > Are you talking about an add-on in particular? There are two related but
>> > separate topics in your email:
>> >
>> > 1. Contributors credit
>> > The script that generates the credits [1] is indeed be skipping the
>> add-on
>> > repositories.
>> >
>> > 2. Release notes
>> > It is the responsibility of any developer that contributes code, to
>> > document the changes and mention them in the (wiki) release notes [2].
>> If
>> > an add-on maintainer needs wiki access they can contact me directly via
>> > email or as dfelinto in blender.chat.
>> >
>> > [1] -
>> >
>> https://developer.blender.org/diffusion/BDT/browse/master/utils/credits_git_gen.py
>> > [2] -https://wiki.blender.org/wiki/Reference/Release_Notes/2.93/Add-ons
>> >
>> > -Dalai-
>> > 
>> > Dalai Felinto -da...@blender.org  -www.blender.org
>> > Blender Development Coordinator
>> > Buikslotermeerplein 161, 1025 ET Amsterdam, the Netherlands
>> >
>> >
>> > Op za 5 jun. 2021 om 07:10 schreef Ryan Inch via Bf-committers <
>> > bf-committers@blender.org>:
>> >
>> >> Congratulations on the release!  Everything looks good, there seems to
>> >> be tons of great improvements,
>> >> and the reels are quite impressive.
>> >>
>> >> However, I have noticed that Add-ons are treated differently in the
>> >> release notes.  Judging by the emails from the bf-extensions mailing
>> >> list, many of the Add-ons bundled with Blender receive dozens of
>> updates
>> >> between each release, but this hasn't lately been advertised in the
>> >> release notes (aside from the occasional mention in @SouthernShotty's 5
>> >> minute videos, very grateful to him for that), plus the
>> >> authors/maintainers and their commits to these Add-ons don't seem to be
>> >> credited on the credits page[1].  Since the Add-ons are bundled with
>> >> Blender, is there a reason that they aren't credited at release?
>> >>
>> 

Re: [Bf-committers] Blender 2.93 Released!

[Brecht Van Lommel via Bf-committers]

Personally, I wouldn't change this.

Add-ons authors are credited in the add-on preferences, where you go to
enable the add-on. The fact that they are bundled rather than installed
from an online repository (which is what we should do eventually) makes
little practical difference I think.

For the release notes, I don't think we should be putting much emphasis on
add-ons that often have a UI/UX and design different than core Blender,
usually created by individuals without review. The freedom to do that
creates very useful functionality and leads to fast development, but I
wouldn't market that as part of Blender the product in the same way.

The way I see it is that as an add-on author you get both the freedom and
the responsibility for development, docs, and marketing. If anything we
should decouple such things more, rather than integrating them.

On Fri, Jun 11, 2021 at 6:07 AM Ryan Inch via Bf-committers <
bf-committers@blender.org> wrote:

> Hi Dalai,
> I'm not talking about an add-on in particular, I'm referring to add-ons
> in general.
>
> In regard to your first point, we are agreed that the credit gen script
> is skipping add-ons; however, from what you've shown me, it looks like
> it would be easy to support.  So I'm wondering why it is that add-ons
> are being skipped and what can be done to correct it for the 2.93 release?
>
> In regard to your second point, I am aware that it is the responsibility
> of the developer to document changes in the wiki release notes, I do so
> for every release, and I thank you for your willingness to help with any
> problems accessing the wiki.  I was, however, referring to the fancier
> release notes [1] that are compiled from the wiki release notes, and
> that these have been lacking a section for add-ons recently.  So, what
> is required to have an add-ons section added to the 'fancy' release notes?
>
> Ryan
>
> [1] https://www.blender.org/download/releases/2-93/
>
> On 2021-06-07 06:00 AM, bf-committers-requ...@blender.org wrote:
> > Date: Mon, 7 Jun 2021 10:05:36 +0200
> > From: Dalai Felinto
> > To: bf-blender developers
> > Subject: Re: [Bf-committers] Blender 2.93 Released!
> > Message-ID:
> >zavhavyzc5rws4jbbg1m...@mail.gmail.com>
> > Content-Type: text/plain; charset="UTF-8"
> >
> > Hi Ryan,
> > Are you talking about an add-on in particular? There are two related but
> > separate topics in your email:
> >
> > 1. Contributors credit
> > The script that generates the credits [1] is indeed be skipping the
> add-on
> > repositories.
> >
> > 2. Release notes
> > It is the responsibility of any developer that contributes code, to
> > document the changes and mention them in the (wiki) release notes [2]. If
> > an add-on maintainer needs wiki access they can contact me directly via
> > email or as dfelinto in blender.chat.
> >
> > [1] -
> >
> https://developer.blender.org/diffusion/BDT/browse/master/utils/credits_git_gen.py
> > [2] -https://wiki.blender.org/wiki/Reference/Release_Notes/2.93/Add-ons
> >
> > -Dalai-
> > 
> > Dalai Felinto -da...@blender.org  -www.blender.org
> > Blender Development Coordinator
> > Buikslotermeerplein 161, 1025 ET Amsterdam, the Netherlands
> >
> >
> > Op za 5 jun. 2021 om 07:10 schreef Ryan Inch via Bf-committers <
> > bf-committers@blender.org>:
> >
> >> Congratulations on the release!  Everything looks good, there seems to
> >> be tons of great improvements,
> >> and the reels are quite impressive.
> >>
> >> However, I have noticed that Add-ons are treated differently in the
> >> release notes.  Judging by the emails from the bf-extensions mailing
> >> list, many of the Add-ons bundled with Blender receive dozens of updates
> >> between each release, but this hasn't lately been advertised in the
> >> release notes (aside from the occasional mention in @SouthernShotty's 5
> >> minute videos, very grateful to him for that), plus the
> >> authors/maintainers and their commits to these Add-ons don't seem to be
> >> credited on the credits page[1].  Since the Add-ons are bundled with
> >> Blender, is there a reason that they aren't credited at release?
> >>
> >> If the reason for this is, in part, that authors/maintainers aren't
> >> adding their changes to the wiki version of the
> >> release notes in time, then I would like to inquire as to when the
> >> cutoff for editing the wiki is to make it into the
> >> release notes, or what else could be done to have them included?
> >>
> >> Ryan Inch (Imaginer)
> >> Developer of the Collection Manager Add-on.
> >>
> >> [1]https://www.blender.org/about/credits/
> >>
> >> On 2021-06-03 06:00 AM,bf-committers-requ...@blender.org  wrote:
> >>> --
> >>>
> >>> Message: 1
> >>> Date: Wed, 2 Jun 2021 19:18:32 +0200
> >>> From: Dalai Felinto
> >>> To: bf-blender developers
> >>> Subject: [Bf-committers] Blender 2.93 Released!
> >>> Message-ID:
> >>>

Re: [Bf-committers] Deprecation of Phabricator

[Brecht Van Lommel via Bf-committers]

A big reason for choosing Phabricator at the time was because it was
designed for larger projects. That means being able to organize tasks and
code reviews into projects and subprojects, even if they all apply to the
same code repository. Moving tasks between projects, assigning tasks to
multiple projects, configuration for triaging, custom forms to help users
make good bug reports, etc. At the time, Gitlab did not support such
features, but they have been adding them in the past few years. I don't
know to what extent the various systems support such things now, but it's
something to pay attention to.



On Tue, Jun 1, 2021 at 2:09 PM Sebastian Parborg via Bf-committers <
bf-committers@blender.org> wrote:

> On Mon, May 31, 2021 at 07:02:44PM -0400, Aaron Carlisle via Bf-committers
> wrote:
> > HI,
> >
> > James and I spoke briefly about the possibility of moving to Gitlab
> before
> > the deprecation was announced.
> > I would highly recommend that this is the channel we go down. Gitlab is a
> > big project that is well established,
> > open-source, and opens many tools that are not possible with Phabricator.
> > For example, GitLab would allow online editing of the user manual and
> other
> > repositories.
> > I have identified the lack of online editing as a major deficit in the
> > current development workflow for the user manual.
> >
>
> A year ago I did some research into the matter as well.
> For me the two main candidates are GitLab and Gitea.
>
> Feature wise, GitLab and Gitea seems to be mostly on par.
> One of the biggest differences feature wise is that Gitea doesn't come
> with built in CI, but for us that shouldn't be an issue as we already
> have a build/testing system in place.
>
> The next big thing is that Gitea doesn't have a premium version.
> So everything is open source and all features are available and not
> locked behind a pay gate.
>
> Here is a long list that breaks down what is available in the different
> GitLab versions:
> https://about.gitlab.com/pricing/self-managed/feature-comparison/
>
> Note that only the "free" version is open source.
>
> One fear I have is that with GitLab even if we wrote our own
> implementation of one of the premium features, it would not be accepted
> upstream as it will conflict with their business model.
>
> So for me I think we should at the very least try out both during a
> testing period so we can get some hand on experience before we make a
> decision.
>
> > I would like to be included in the discussion here to make sure we meet
> the
> > needs of the documentation project,
> > we should also include James in this discussion as he might have other
> > recommendations or needs.
> >
>
> Of course! Everyone that wants to participate should!
> We were not planning to exclude neither you or James from this as you
> are some of the people that we must have on board at the very least in my
> opinion.
>
> We still need to figure out a time schedule and allocate time for this
> as nothing has been decided yet.
>
> Regards,
> Sebastian Parborg
> ___
> 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] VFX reference platform 2022 draft

[Brecht Van Lommel via Bf-committers]

Hi,

There is a draft for the next VFX reference platform up now. Since we had
some issues with the last one, it would be good to give feedback if
necessary.

https://vfxplatform.com/
https://groups.google.com/g/vfx-platform-discuss/c/bnyJ2X1SwAw/m/bA_hW2MpBQAJ

Python was upgraded to 3.9, which will still trail behind 3.10 that will be
released this year. So the question about diverging or not will remain.

The only other potential difficulty I see is that TBB remains on version
2020, presumably because 2021 has significant breaking changes. Blender
code currently builds with both versions, to support Linux distributions
that have the latest version. I guess it's not a major issue to keep that
working.

Regards,
Brecht.
___
Bf-committers mailing list
Bf-committers@blender.org
https://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Need HELP About An Addon

[Brecht Van Lommel via Bf-committers]

Hi,

For help with add-on development, devtalk.blender.org is the better place
to ask for help. I see you already opened a discussion topic there.
https://devtalk.blender.org/t/about-drag-and-drop-textures/16819

Regards,
Brecht.

On Wed, Dec 30, 2020, 04:31 Adult Engineering via Bf-committers <
bf-committers@blender.org> wrote:

> Hey, I am Praveen having doubt about how to access drag and drop
> image textures on the object or mesh with the script.
> Please help me with this
> ___
> 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

Re: [Bf-committers] .git-blame-ignore-revs entries.

[Brecht Van Lommel via Bf-committers]

On wiki.blender.org, click on Code Review in the sidebar.

On Tue, Dec 29, 2020, 02:22 amdbcg via Bf-committers <
bf-committers@blender.org> wrote:

> I'm new to this. Where is the procedure for code review?
>
> On Mon, Dec 28, 2020 at 6:06 PM Ray Molenkamp via Bf-committers <
> bf-committers@blender.org> wrote:
>
> > I'd prefer if we excluded small commits completely, but willing to
> > settle on clarifying that the "smaller" commits still ought to be
> > the result of automated tools, If there is no clear indication a
> > cleanup was automated the commit should not be added. ie a commit
> > "Cleanup: clang-tidy some-check" could still very much be a manual
> > cleanup of the warns exposed by clang-tidy and suspect to unintentional
> > functional changes.
> >
> > --Ray
> >
> > On 2020-12-28 5:01 p.m., Brecht Van Lommel via Bf-committers wrote:
> > > Hi Ankit,
> > >
> > > Please go through code review for all commits, unless you are a module
> > > owner or admin that is the policy.
> > >
> > > Note that there are guidelines in the file itself. We could document it
> > in
> > > the wiki too, but I'm not sure it's needed. Perhaps the wording can be
> > > clarified? Suggestions are welcome. The text is as follows:
> > >
> > > # Changes that belong here:
> > > # - Massive comment, doxy-sections, or spelling corrections.
> > > # - Clang-format, PEP8 or other automated changes which are *strictly*
> > "no
> > > functional change".
> > > # - Several smaller commits should be added to this list at once,
> because
> > > adding
> > > #   one extra commit (to edit this file) after every small cleanup is
> > noisy.
> > >
> > > Note that only massive or automated changes are mentioned as belonging
> > > here, nothing else. And commits like these have functional changes:
> > >
> > > # Fix T82520: error building freestyle with Python3.8
> > > # Build-system: Force C linkage for all DNA type headers
> > > # Cleanup: use preprocessor version check for PyTypeObject declaration
> > >
> > > So as far as I can tell this is just not following the documented
> > > guidelines.
> > >
> > > Thanks,
> > > Brecht.
> > >
> > >
> > >
> > > On Mon, Dec 28, 2020 at 8:48 PM Ankit via Bf-committers <
> > > bf-committers@blender.org> wrote:
> > >
> > >> Hello
> > >> I'm getting used to it.
> > >> I'll remove several commits soon, now that I have received the
> > >> feedback on the last commit, and will use stricter conditions in the
> > >> future.
> > >>
> > >> My premise
> > >> - for being lenient was that it saves other people from committing to
> > >>   the file which keeps the noise in git log low.
> > >> - for renames was that a refactoring tool was used
> > >>   with as little human intervention as possible.
> > >> - for clang-tidy being the auto-fixes feature that clang-tidy gives.
> > >>
> > >>> All,
> > >> That's a new way of raising concerns on commits.
> > >>
> > >>> but I really
> > >>> would still like to see smaller and clearly manual cleanups
> > >>> in git blame.
> > >> If I see "cleanup" in the title, the onus is on the committer to make
> > >> sure that it really is a cleanup. If that promise is kept, I don't see
> > >> why a cleanup commit interests you.
> > >>
> > >>> Changes in this file don't even seem to go through code review.
> > >> I thought it keeps the overhead of keeping a utility file low.
> > >>
> > >> Ankit
> > >>
> > >>
> > >>> On 29-Dec-2020, at 00:40, Ray Molenkamp via Bf-committers <
> > >> bf-committers@blender.org> wrote:
> > >>> All,
> > >>>
> > >>> What's going in with this file? there's 50+ commits in there
> > >>> and I disagree with virtually every single hash I sampled
> > >>> from it.
> > >>>
> > >>> If we want to hide large changes made by automated tools like
> > >>> the big clang-format [1] change, yeah awesome, but I really
> > >>> would still like to see smaller and clearly manual cleanups
> > >>> in git blame.
> > >>>
>

Re: [Bf-committers] .git-blame-ignore-revs entries.

[Brecht Van Lommel via Bf-committers]

Hi Ankit,

Please go through code review for all commits, unless you are a module
owner or admin that is the policy.

Note that there are guidelines in the file itself. We could document it in
the wiki too, but I'm not sure it's needed. Perhaps the wording can be
clarified? Suggestions are welcome. The text is as follows:

# Changes that belong here:
# - Massive comment, doxy-sections, or spelling corrections.
# - Clang-format, PEP8 or other automated changes which are *strictly* "no
functional change".
# - Several smaller commits should be added to this list at once, because
adding
#   one extra commit (to edit this file) after every small cleanup is noisy.

Note that only massive or automated changes are mentioned as belonging
here, nothing else. And commits like these have functional changes:

# Fix T82520: error building freestyle with Python3.8
# Build-system: Force C linkage for all DNA type headers
# Cleanup: use preprocessor version check for PyTypeObject declaration

So as far as I can tell this is just not following the documented
guidelines.

Thanks,
Brecht.



On Mon, Dec 28, 2020 at 8:48 PM Ankit via Bf-committers <
bf-committers@blender.org> wrote:

> Hello
> I'm getting used to it.
> I'll remove several commits soon, now that I have received the
> feedback on the last commit, and will use stricter conditions in the
> future.
>
> My premise
> - for being lenient was that it saves other people from committing to
>   the file which keeps the noise in git log low.
> - for renames was that a refactoring tool was used
>   with as little human intervention as possible.
> - for clang-tidy being the auto-fixes feature that clang-tidy gives.
>
> > All,
>
> That's a new way of raising concerns on commits.
>
> > but I really
> > would still like to see smaller and clearly manual cleanups
> > in git blame.
>
> If I see "cleanup" in the title, the onus is on the committer to make
> sure that it really is a cleanup. If that promise is kept, I don't see
> why a cleanup commit interests you.
>
> > Changes in this file don't even seem to go through code review.
>
> I thought it keeps the overhead of keeping a utility file low.
>
> Ankit
>
>
> > On 29-Dec-2020, at 00:40, Ray Molenkamp via Bf-committers <
> bf-committers@blender.org> wrote:
> >
> > All,
> >
> > What's going in with this file? there's 50+ commits in there
> > and I disagree with virtually every single hash I sampled
> > from it.
> >
> > If we want to hide large changes made by automated tools like
> > the big clang-format [1] change, yeah awesome, but I really
> > would still like to see smaller and clearly manual cleanups
> > in git blame.
> >
> > Changes in this file don't even seem to go through code review.
> > In the original review [2] both Brecht and Campbell mention
> > that it be "OK for larger changes" but that is not what appears to
> > be happening.
> >
> > This is not how this is supposed to work, is it?
> >
> > --Ray
> >
> > [1]
> https://developer.blender.org/rBe12c08e8d170b7ca40f204a5b0423c23a9fbc2c1
> > [2] https://developer.blender.org/D9234
> > ___
> > 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

Re: [Bf-committers] Aligning with the vfx reference platform in 2020

[Brecht Van Lommel via Bf-committers]

There are two parts to this. I think upgrading to the 2021 reference
platform as proposed in the task is an easy decision. There are no real
downsides that I know of. We might as well keep up with recent versions of
libraries like OpenVDB, OpenColorIO and OpenEXR, the new versions provide
real improvements for users. Upgrading to a newer Python bugfix release
should also be non-controversial. I think we can simply go ahead with that
unless there is an objection.
https://developer.blender.org/T83246

The other question is, do we upgrade Python to a newer version than the
reference platform? We haven't gotten much feedback, so I guess the Blender
administrators will simply have to make a decision together.


On Thu, Dec 3, 2020 at 4:05 PM Ton Roosendaal via Bf-committers <
bf-committers@blender.org> wrote:

> Hi everyone,
>
> The year is almost over. I would like to hear feedback on this topic -
> whether it was useful or if lead to a benefit for using Blender in
> studios or companies.
>
> Thanks,
>
> -Ton-
> --
> Ton Roosendaal - t...@blender.org - www.blender.org
> Chairman Blender Foundation, Director Blender Institute
> Buikslotermeerplein 161, 1025 ET Amsterdam, the Netherlands
>
>
> On 10/01/2020 18:03, Ton Roosendaal wrote:
> > Hi everyone,
> >
> > Blender has always been an early adopter of new libraries. We moved to
> > Python 3 ten years ago already. Unfortunately that made Blender
> > incompatible with the Python 2.7 infrastructure in many studios. But
> > the industry is catching up! Python 3.7 is now the reference standard.
> >
> > To give studios enough time and confidence to check out on Blender, I
> > propose to respect the VFX Platform versions for the entire year of
> > 2020. That implies we will be very conservative with upgrading
> > libraries, for example Python will stick to 3.7 this year for official
> > releases.
> >
> > I've checked it with the core team and administrators, and they're OK
> > - provided this won't hold back essential improvements for our users.
> >
> > Check the reference platform here:
> > https://vfxplatform.com/
> >
> > Thanks,
> >
> > -Ton-
> > --
> > Ton Roosendaal - t...@blender.org - www.blender.org
> > Chairman Blender Foundation, Director Blender Institute
> > 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

Re: [Bf-committers] GPencil I/O Project: Request to integrate libharu lib to export PDF format

[Brecht Van Lommel via Bf-committers]

There appears to be consensus that libharu is the way to go, and a week has
passed for people to give feedback.

Let's considered this decided then, and let Antonio and the platform
maintainers take care of the implementation.



On Wed, Dec 16, 2020 at 4:03 PM Ray Molenkamp via Bf-committers <
bf-committers@blender.org> wrote:

> Soo.. this thread has a good run, lots of good feedback, but it
> still seems decision-less, I'll happily do the work to make this happen,
>
> but who makes the final call here?
>
> --Ray
>
> On 2020-12-15 9:19 p.m., Campbell Barton via Bf-committers wrote:
> > To follow up on previous messages:
> >
> > - On my system the stripped library is ~830kb,
> >   over half of the libraries file-size is binary data for fonts and
> > character encoding tables,
> >   if we wanted we could remove these - bringing the size down to ~350kb.
> >
> > - This library is available on mainstream Linux distributions,
> >   so even if this isn't maintained by the author, it's not exactly
> > abandon-ware either.
> >   From checking suse [0] & debian's [1] repository, their patches
> > aren't likely to be useful to us
> >   since they're only tweaks for building & header guards.
> >
> > - I ran some (admittedly basic) tests with valgrind & ASAN
> >   which didn't show up any issues that would be cause for concern.
> >
> > So while I'm still not so keen to depend on unmaintained code.
> > +1 to include this as an optional library.
> >
> > [0] https://build.opensuse.org/package/show/openSUSE:Factory/libharu
> > [1] https://packages.debian.org/stable/source/libharu
> >
> > On Tue, Dec 15, 2020 at 1:17 AM Sybren A. Stüvel via Bf-committers
> >  wrote:
> >> On Fri, 11 Dec 2020 at 18:55, Brecht Van Lommel via Bf-committers
> >>  wrote:
> >>> Adding an abstraction layer so theoretically the library can be
> switched
> >>> out for another is probably not very helpful. If we were using this in
> many
> >>> places maybe, but in my experience, these kinds of abstraction layers
> get
> >>> in the way more than they help.
> >> I agree. IMO such an abstraction layer is generally only really worth
> >> it if you already have two different libraries to support, and you
> >> know enough about the differences in architecture that you can
> >> actually create the proper abstractions.
> >>
> >>> libharu seems like the most reasonable solution.
> >> I agree, although the "not maintained since 2013" is a bit scary. The
> >> fact that we won't be using the known-buggy parts of the code helps,
> >> but I do think this should then be documented properly somewhere. If
> >> the inclusion of the library is done under the assumption that no
> >> images will be read, and no PDF will be imported, because these are
> >> buggy code paths, this should be clear to future contributors as well.
> >> Without such warnings in place, people are bound to be looking at the
> >> library to create some PDF-to-GP importer.
> >>
> >> Sybren
> >> ___
> >> 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

Re: [Bf-committers] GPencil I/O Project: Request to integrate libharu lib to export PDF format

[Brecht Van Lommel via Bf-committers]

 I think we should only use extern/ if the alternative is not possible for
some reason, and I'm not aware of any. So following that libharu would go
to the svn libraries.

Personally I don't really see a significant advantage in bundling it as a
separate executable. It helps in some ways, but then you potentially get
issues with proper passing of arguments, unicode and escaping, error
handling, etc.

Adding an abstraction layer so theoretically the library can be switched
out for another is probably not very helpful. If we were using this in many
places maybe, but in my experience, these kinds of abstraction layers get
in the way more than they help.

Cairo is not that big a library when enabling most backends, but it still
has a required additional dependency (pixman). I guess overall it's
probably not going to simplify building and maintenance.

So weighing the options, to me libharu seems like the most reasonable
solution.



On Fri, Dec 11, 2020 at 1:51 AM Campbell Barton via Bf-committers <
bf-committers@blender.org> wrote:

> By this logic we could blindly accept any patch that's had some production
> testing, without considering long term maintenance.
>
> It's possible alternative solutions that call out to existing well
> maintained
> converters would have been fine in production too.
> It's not that I'm pushing back against including this entirely,
> I'm just not a fan of this "it worked in a production test - so lets
> include it" -- attitude.
>
> Over the years I believe we've spent significant time investigating
> issues with 3rd party libraries (resource leaks, conflicting symbols,
> linking problems, platform specific errors etc).
> If there is a good chance we can avoid this entirely, it could be
> worth looking into.
>
> If we do include libharu, how would this be included?  in extern/ or
> would we bundle it in SVN's lib?
>
> On 12/10/20 8:26 PM, Dalai Felinto wrote:
> > Hi,
> >
> > My suggestion would be the following:
> >
> > * Stick to libharu since it was proven that works for the intended use
> > case.
> > * Make sure libharu integration in the code goes via a layer of
> > abstraction.
> >
> > So instead of trying now to solve an non-existent problem, we use
> > development time to make sure the existing solution is robust enough to
> > be replaced if needs be.
> >
> > Regards,
> > Dalai
> >
> > On 09-12-2020 23:34, Campbell Barton via Bf-committers wrote:
> >> rsvg-convert (which uses cairo), is a utility that converts SVG to
> >> PDF, it can create multi-page PDF's from many SVG's too.
> >>
> >> If for some reason we need more control then a command line utility
> >> provides, there are Python multiple options regarding bindings for
> >> cairo & svg conversion.
> >>  From what I can tell they can convert SVG to PDF quite easily.
> >>
> >> Regarding bundling the conversion tools, if this it's only a few
> >> studios with specific requirements, we don't _necessarily_ need to
> >> include the conversion utilities with Blender, although this is a
> >> decision we could easily change.
> >>
> >> I'm not pushing for this as the final solution, just checking if it
> >> might be a simpler option compared to taking on a PDF library that
> >> isn't maintained anymore.
> >> ___
> >> 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

Re: [Bf-committers] GPencil I/O Project: Request to integrate libharu lib to export PDF format

[Brecht Van Lommel via Bf-committers]

I'm not sure there exists a simple utility to convert SVG to PDF that we
could include, if we want to go that way?

Inkscape uses Cairo for PDF writing, that could be a more actively
maintained alternative.
https://www.cairographics.org/

It has also been proposed to be added to handle Wayland window decorations
in D7989, so it would let us solve both problems with one library.


On Wed, Dec 9, 2020 at 11:46 AM Antonio Vazquez via Bf-committers <
bf-committers@blender.org> wrote:

> There are several reasons why I decided to use libharu.
>
> * The PDF format is very stable and does not change substantially, so we
> are not at great risk due to format changes.
> * I already know that this library is not maintained, but since the PDF
> format does not change, it does not require much maintenance.
> * This library is widely used in other software to generate PDF, so it is
> well proven.
>
> Regarding the bugs you comment, I have seen that several have a patch to
> solve them, but in any case, the use I make of the library does not include
> using images, only a very simple use. I do not expect, in the short or
> medium term, to use anything related to appending images, so these bugs do
> not affect us at all. Attaching images to a PDF does not make much sense in
> our case.
>
> Including a converter from SVG could work, but the problem is that in PDF
> we can generate a document with several pages and in SVG I have not seen
> that this is supported. Imagine that we want to generate a storyboard with
> 100 frames ... we would need to export 100 SVG and join them later ... now
> that is very simple. We would also have to assess the speed of the
> conversion, since now it is all C / C ++ and it is very fast.
>
> The other option I have been considering is to fork libharu and create a
> tiny version with the functions we need and remove any appended image
> support.
>
> Antonio
>
> El mié, 9 dic 2020 a las 0:46, Campbell Barton via Bf-committers (<
> bf-committers@blender.org>) escribió:
>
> > Hi Antonion,
> >
> > From what I can tell libharu hasn't been very active since 2013, their
> > site states they're looking for a new maintainer.
> > Would we become the defacto maintainers of this library?
> >
> > I checked their issue tracker, while many reports are support requests
> > and build issues, there are some more serious looking issues too, eg:
> >
> > https://github.com/libharu/libharu/issues/73
> > https://github.com/libharu/libharu/issues/71
> > https://github.com/libharu/libharu/issues/63
> >
> > Is there a significant advantage in integrating a library compared
> > with bundling a utility that converts SVG to PDF?
> > In this case it could be an optional dependency, or we bundle the
> > conversion tool in official releases so PDF support is still
> > integrated from a user perspective.
> >
> > On Wed, Dec 9, 2020 at 6:31 AM Antonio Vazquez via Bf-committers
> >  wrote:
> > >
> > > Hi All,
> > >
> > >
> > >
> > > As some of you may already know, for version 2.92 we want to focus on
> the
> > > Import and Export processes of Grease Pencil (T83190).
> > >
> > >
> > >
> > > Currently, the grease pencil is in some way an "island" in the studios
> > > pipeline and we need to add tools to integrate it. Part of these
> > > integration processes were the work we did to make image traces (2.91)
> > and
> > > shortly, video traces (2.92).
> > >
> > >
> > >
> > > During the contacts that the members of grease pencil team usually have
> > > with 2D studios, they have detected that some commercial software very
> > > important in the studios pipeline does not support the import of SVG,
> but
> > > of PDF. In addition, the PDF format allows working in many softwares
> and
> > is
> > > very useful for generating storyboards and work in comics.
> > >
> > >
> > >
> > > Past weeks, I have been working on a new I/O module for grease pencil
> in
> > C
> > > ++ and I already have the SVG Importer (T79875) and the SVG Exporter
> > > (T83191) and PDF Exporter (T83192) working. All work has been done on a
> > > private branch on my PC.
> > >
> > >
> > >
> > > You can see a PDF exporter video here: https://youtu.be/BMm0KeMJsI4
> > >
> > >
> > >
> > > To export to PDF I have used an open source library (libharu
> > > http://libharu.org/) and would need to integrate that library into
> > Blender.
> > > This library is very simple (<1.6 MB on Windows) and allows export to
> PDF
> > > easily.
> > >
> > >
> > >
> > > Finally, exporting to PDF opens up a world of possibilities and
> > especially
> > > when the new LineArt module will be integrated into Blender.
> > >
> > >
> > >
> > > If we agree to integrate libharu, I can prepare the patch for review
> the
> > > I/O code I did.
> > >
> > >
> > >
> > > I would like to hear your opinions.
> > >
> > >
> > >
> > > Best Regards,
> > >
> > > Antonio Vázquez
> > >
> > > Grease Pencil Team
> > > ___
> > > Bf-committers mailing list
> > > 

Re: [Bf-committers] Support for 32-bit architectures

[Brecht Van Lommel via Bf-committers]

On Tue, Nov 17, 2020 at 2:40 PM Sybren A. Stüvel via Bf-committers <
bf-committers@blender.org> wrote:

> I'm assuming you mean D9577 with "this specific case", as that's where
> this discussion started before I moved it to this list, and that
> you're talking about a problem that 32-bit Linux can't be compiled
> because some code uses 64-bit atomic functions that are not defined.
> It may be my personal limitation, but somehow I can't combine a patch
> where 64-bit atomics are going to be exposed on 32-bit platforms with
> "Tweak the code to not use 64 bit atomics".
>

We need to fix a regression, it doesn't have to be the particular solution
in the patch. Eliminating the architecture-specific code is a solution too.


> I tried to steer away from discussing the specifics of that patch
> here, though, as I'm more interested in getting a clearer picture of
> the general policy on how we handle incompatibilities with unsupported
> platforms.
>

Implementing a fallback: if it's clear what a function should do (via
> unit tests for example) then no, that's fine.
> Understanding how exactly things get unwinded on a specific platform
> the developer doesn't have access to -- yes, it is too much.
>

I'm talking about processor architectures, not platforms more generally.
And if you look at the handful of actual cases where that matters, it's
just not that hard to ensure there is a working architecture-independent
code path. Either by understanding the behavior, or finding a solution that
doesn't require understanding it.
___
Bf-committers mailing list
Bf-committers@blender.org
https://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Patching the manual as a team responsibility

[Brecht Van Lommel via Bf-committers]

Developers are already welcome to document their features in the manual, I
don't think this is any different?

You do have to be aware that the manual tracks the release branch while it
exists, not master.

Moving the manual to git and using branching would make that easier,
there's a task for that here:
https://developer.blender.org/T73394



On Tue, Nov 17, 2020, 10:28 Jeroen Bakker via Bf-committers <
bf-committers@blender.org> wrote:

> Hi all,
>
> In the geometry nodes project we are using the scrum methodology. We are
> currently performing a sprint that will commit new multiple small
> features to master. As part of this we are updating the manual.
>
> In the non-scrum way of development the developer who is responsible for
> a patch can use a local branch/or copy for keeping track of changes to
> bf-manual and pushes the changes together with the patch. Using the
> scrum methodology the patches are a team responsibility and therefore
> updating the manual is also a team responsibility. We would like to
> update the manual side by side to the patches that land to make sure
> that the manual is in sync with master.
>
> The manual is hosted on SVN what doesn't (have good) support for
> distributed version control. In the short term we created a git
> repository hosted outside of blender.org with the main reason to not
> confuse manual writers.
>
> Using the scrum methodology with blender projects is still experimental,
> but if it is successful more projects could adopt this methodology. It
> would be good to know if the chosen solution is fine for the short term
> (as part of the experiment). What might be issues that other writers
> would see with our chosen solution?
>
> In the longer run we could see if we want to do some changes to our
> current infrastructure. Taken into account the community efforts on
> updating the manual and therefore the tactically choice to host the
> manual in SVN.
>
> Regards,
>
> Jeroen Bakker.
>
>
>
> ___
> 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

Re: [Bf-committers] Support for 32-bit architectures

[Brecht Van Lommel via Bf-committers]

For example in this specific case it's easy to either:
* Copy an implementation from another library known to work
* Switch to using 
* Tweak the code to not use 64 bit atomics

And if you implement an architecture independent fallback, you can test
that by disabling the architecture specific code temporarily.

Is that really too much to ask a developer?

If there are no means of reproducing, testing, and no alternative
implementation that sidesteps the problem, then sure. But that's rare.

On Tue, Nov 17, 2020, 09:53 Sybren A. Stüvel via Bf-committers <
bf-committers@blender.org> wrote:

> On Mon, 16 Nov 2020 at 17:58, Brecht Van Lommel via Bf-committers
>  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.
>
> I agree that assumptions on pointer size and endianness are not good,
> and that this is something that's usually easily detected. What "the
> appropriate #ifdefs" are is already unclear to me, as I have no
> experience with intrinsic calls.
>
> To me the important thing here is that it's hard to write correct code
> in the first place. This is why we have automated tests and want to
> invest more in proper CI. Writing correct code for hardware you don't
> have (either directly or indirectly via a buildbot) is even harder. I
> think it's objectionable to ask developers to fix problems that they
> have no means of reproducing and that occur only on non-supported
> platforms. To make things worse, we don't build libraries for these
> platforms either, so even if you can tell your compiler to build for
> some architecture, you still can't easily attempt a build.
>
> Personally I'm absolutely in favour of something like this:
> - Blender-employed devs don't actively work on fixing issues with
> unsupported platforms, but also don't intentionally write code that
> would break these platforms either.
> - Patches are welcome, and testing on the problematic platform is the
> responsibility of the patch author. Of course tests are performed by
> the reviewer/committer to ensure they don't break supported platforms.
>
> Expressing an intent to not break unsupported platforms is fine, but
> asking developers to understand and recognize problems on platforms
> they don't have access to and cannot test on, for me that's a step too
> far. Again, certain cases are known "cross-platform breakers" and
> should be avoided. I'm trying to get the definition clear of where
> those cases end, and where "supporting unsupported platforms" begins.
>
> Sybren
> ___
> 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

Re: [Bf-committers] Proposing a unique ID for Blender objects system, for use with game engines.

[Brecht Van Lommel via Bf-committers]

I can see how this would solve a real problem and improves usability when
exporting assets to Godot.

Note that USD explicitly chose not to use UUIDs. But I can see how this
makes more sense for simpler pipleines that don't follow more strict naming
conventions or fix up names afterwards.
https://graphics.pixar.com/usd/docs/index.html#IntroductiontoUSD-NoGUIDS

To me a UUID makes sense when you want to make a connection between two
completely different databases. Like Blender and a game engine, or an asset
manager that manages data from multiple applications. Any time you have to
do that kind of syncing and no longer have a single source of truth, it's
not an ideal situation in the first place, but UUIDs do help.

It can be misused as well. For example I've heard requests for this so
add-ons can store relations to Blender datablocks at runtime, or saved in
.blend files. To me that would be a mistake, as references to datablock
should be done explicitly with pointers that are managed by Blender, that
can be properly referenced counted, cleared, replaced, etc. Also for
library linking datablocks between .blend files this is tempting, but again
it also comes with it own set of issues.

If this were to be implemented, it does raise some questions:
* Would we want to do this for every datablock? Presumably not because the
memory overhead and cost of generating a UUID, so I guess it would be
something that is generated on demand.
* Are UUIDs supposed to be unique within one .blend file, or globally
unique across all .blend files? What happens when you copy or rename a
.blend file, do the UUIDs change?
* Do overrides copy the UUID or generate a new one? I'm guessing it should
generate a new one.
* What about datablocks that are the result of geometry nodes evaluation?
How does this UUID remain stable if geometry nodes can output an arbitrary
number of objects, that might even vary over time?
* How does this relate to the asset manager design? There was some
discussion of having UUIDs for that though no conclusion. If it is needed
there, would that UUID be the same?




On Thu, Nov 12, 2020 at 5:24 PM Juan Linietsky via Bf-committers <
bf-committers@blender.org> wrote:

> Hi guys, lead Godot dev here.
>
> I wanted to discuss with you a problem we are often having that I am not
> certain how it can be solved entirely from our side, I add a proposal for
> this, but if you guys have a better recommendation, I'm very open to any
> ideas.
>
> Basically, Godot will import scenes (GLTF/FBX/DAE/etc) as they come from
> blender, and it generates the same object names, resource names, etc. as
> they come from Blender and the resource file.
>
> We use the same names so we can keep track of changes in the Blend file. If
> an object is moved, a material is changed, etc. we detect on re-import and
> everything is updated in Godot.
>
> This is especially more annoying in Godot than in other game engines,
> because Godot can read the whole Blender scene and keep it more or less
> intact, so users love using this for level design workflow (so they can
> design levels in Blender).
>
> So, the problem is that it often happens that for some reason, artists want
> to rename the objects in Blender. Be it because they didn't care at the
> beginning and they want to become more organized later, or because the
> scene became bigger and they need to make their naming of things more
> precise to navigate it around. In this situation, when something is renamed
> on the Blender side and re-exported, the game engines have no idea where
> this object went, so we need to either remove it (resulting in loss data)
> it or orphan it (resulting in duplicated data).
>
> While I do think that good practices solve this and this is probably not
> such an issue in a professional environment, truth is that game development
> has become a huge hobbyist activity, and our users find this situation
> constantly and are annoyed with it, and there is nothing we can do from our
> side.
>
> The obvious proposal to solve this would be to ask Blender whether it's
> possible to generate a unique object ID (UUID?) and make sure it does not
> change over time even if objects are renamed, then changing the exporters a
> bit to (optionally if selected in the export settings) add this information
> as extensions in the existing format (on GLTF it should be rather easy).
>
> If you guys think this is possible, it would be very helpful for us, if you
> have other ideas on how we could solve this, we are very open to
> discussion.
>
> Best
>
> Juan
> ___
> 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

Re: [Bf-committers] Support for 32-bit architectures

[Brecht Van Lommel via Bf-committers]

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
> > [4]: https://developer.blender.org/D9577
> > ___
> > 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

Re: [Bf-committers] Science visualisation: Blender + ANARI

[Brecht Van Lommel via Bf-committers]

ANARI was brought up in the latest rendering meeting. Blender is not
actively involved in it.
https://devtalk.blender.org/t/2020-11-3-blender-rendering-meeting/16020

ANARAI is not designed to do what you describe though. It is a rendering
API, that would sit between a tool like Blender or Paraview, and a renderer
like Cycles or OSPRay. Similar to Hydra or the RenderMan Interface. It
would not be used for importing a neural model into Blender.


On Thu, Nov 5, 2020 at 11:11 AM Mateusz Grzeliński via Bf-committers <
bf-committers@blender.org> wrote:

> Hello,
>
> I am in the middle of researching possibilities of
> visualization and interaction with neural networks (graph based
> structures) in 3d environment, just a project connected with studies.
>
> I came upon quite new project called ANARI - Analytic Rendering
> Interface for Data Visualization. Long story short, it is meant to be a
> bridge connecting data and visualization in standarized ways:
>
> data -> ANARI -> any visualization tool
>
> So in my case:
>
> neural model -> ANARI -> Blender
>
> The ANARI project (owned by Khronos group) is still under development
> thus kept private.
> Recently Ton announced that Blender is a member of Khronos group. I am
> not asking for access, that would be a lot to ask, but still I wonder
> if anyone from Blender participates in development of ANARI? Any plans
> or thoughts about it?
>
> Blender seems to be used quite often in science vis and ANARI seems to
> be next big thing.
>
> As ANARI is still kept private I will probably need to use different
> toolchain for my project :( Now I can appreciate open nature of
> Blender.
>
> Regards,
> Mateusz Grzeliński
>
> Those are pretty much the only public resources about ANARI:
> * ANARI overview: https://www.khronos.org/anari
> * ANRI Q webinar (recording and presentation):
>
> https://www.khronos.org/blog/want-to-learn-how-graphics-vendors-will-use-the-anari-api-to-enable-rendering-technologies-anari-webinar-qa
>
>
> ___
> 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

Re: [Bf-committers] It's time to get rid of cloth

[Brecht Van Lommel via Bf-committers]

To be clear, cloth simulaton does use an implicit solver, including ideas
from the Baraff paper like filtered CG.

For volumetric soft bodies, there was a summer of code project this year.
It uses an implicit solver. However it's not currently in a state that is
good enough to go into master.
https://wiki.blender.org/wiki/User:Mattoverby/GSoC2020/mattoverby_final_report


On Tue, Nov 3, 2020 at 2:19 AM bjornmose via Bf-committers <
bf-committers@blender.org> wrote:

> Well,
>
> my last contribution was ' old man grumbling'
>
> to be more constructive I'd like point to the issues to be focused on:
>
> We do have stiff PDEs ODEs to solve. We know very well, that common
> forward solvers perform very poor under 'stiff' conditions. David Baraff
> proposed using 'implicit backward solvers' some days (~ 10 * 356) ago.
> Even 'numerical recipes' knows stiff differential equations.
>
> How deal with it?
>
> 1. Implement solvers that can do .. expensive but possible in open source.
>
> 2. Think about volume energy constraints ( see 3. )
>
> 3. Think over the model .. a mesh is a mesh .. blender as grown from
> past knows 2D objects in 3D .. a skin of faces. Works very fine if is
> forward driven. But there is no reliable concept if we want to have
> vertex to vertex interaction deep inside. (Think of the cube having
> springs  from (1,1,1) to (-1,-1-1))   The fist thing on the task list
> IMHO should be to add 'edges' that is vertex to vertex connections that
> do not modify the surface but represent physical interaction.
>
>
>
> On 02.11.20 19:07, Brecht Van Lommel via Bf-committers wrote:
> > The paper shows how to make SDF collision more accurate by using the SDF
> > directly rather than sampling it. We have triangle mesh based collision
> in
> > Blender, which in a state-of-the-art implementation would avoid those
> > problems already.
> >
> > The point of switching to SDFs would be performance, at the cost of
> detail
> > loss compared to triangle mesh based methods.
> >
> > On Mon, Nov 2, 2020 at 5:38 PM Aaron Carlisle via Bf-committers <
> > bf-committers@blender.org> wrote:
> >
> >> Hi looking at this thread I wonder if anyone has looked into
> implementing
> >> SDF
> >> based collision detection in Blender. It seems to be quite a bit more
> >> stable
> >> than sample based detection. Here is a recent paper on the topic [1]
> >> <https://mmacklin.com/sdfcontact.pdf>
> >>
> >> 1. https://mmacklin.com/sdfcontact.pdf <
> >> https://mmacklin.com/sdfcontact.pdf>
> >>
> >> On Wed, Oct 21, 2020, 21:56 bjornmose via Bf-committers <
> >> bf-committers@blender.org> wrote:
> >>
> >>> Might it be, that old experienced coders knowing physics and all the
> >>> other things about stiff differential equations turned their back to
> >>> blender development?
> >>>
> >>> May be because lack of time .. may be an ignored patch proposal .. for
> >>> those do not have the time at hand to provide elaborated solutions?
> >>>
> >>> Well ...
> >>>
> >>> bjornmose
> >>>
> >>>
> >>> On 20.10.20 20:35, Joe Eagar via Bf-committers wrote:
> >>>> Brecht, you can avoid the worst numerical instability issues of CCD by
> >>>> adding a small repulsion force when cloth is in close proximity with
> >>>> geometry.  IIRC most commercial cloth sims do this.
> >>>>
> >>>> Ton, I'm sorry I blew up.  Cloth collision is something of a
> >>>> special nightmare for me.
> >>>>
> >>>> Sergej, that's fair.
> >>>> Sebastian, sounds like you're doing good work, just remember that
> >> robust
> >>>> collisions are important :)
> >>>> ___
> >>>> 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 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

Re: [Bf-committers] It's time to get rid of cloth

[Brecht Van Lommel via Bf-committers]

The paper shows how to make SDF collision more accurate by using the SDF
directly rather than sampling it. We have triangle mesh based collision in
Blender, which in a state-of-the-art implementation would avoid those
problems already.

The point of switching to SDFs would be performance, at the cost of detail
loss compared to triangle mesh based methods.

On Mon, Nov 2, 2020 at 5:38 PM Aaron Carlisle via Bf-committers <
bf-committers@blender.org> wrote:

> Hi looking at this thread I wonder if anyone has looked into implementing
> SDF
> based collision detection in Blender. It seems to be quite a bit more
> stable
> than sample based detection. Here is a recent paper on the topic [1]
> 
>
> 1. https://mmacklin.com/sdfcontact.pdf <
> https://mmacklin.com/sdfcontact.pdf>
>
> On Wed, Oct 21, 2020, 21:56 bjornmose via Bf-committers <
> bf-committers@blender.org> wrote:
>
> > Might it be, that old experienced coders knowing physics and all the
> > other things about stiff differential equations turned their back to
> > blender development?
> >
> > May be because lack of time .. may be an ignored patch proposal .. for
> > those do not have the time at hand to provide elaborated solutions?
> >
> > Well ...
> >
> > bjornmose
> >
> >
> > On 20.10.20 20:35, Joe Eagar via Bf-committers wrote:
> > > Brecht, you can avoid the worst numerical instability issues of CCD by
> > > adding a small repulsion force when cloth is in close proximity with
> > > geometry.  IIRC most commercial cloth sims do this.
> > >
> > > Ton, I'm sorry I blew up.  Cloth collision is something of a
> > > special nightmare for me.
> > >
> > > Sergej, that's fair.
> > > Sebastian, sounds like you're doing good work, just remember that
> robust
> > > collisions are important :)
> > > ___
> > > 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

Re: [Bf-committers] It's time to get rid of cloth

[Brecht Van Lommel via Bf-committers]

The most important thing for cloth is that you can get it to give good
results in real world cases, and the cloth simulation changes were based on
work done for Agent 327.
https://www.youtube.com/watch?v=jU6-cI-z8HA

In practice you use smaller time steps and the fast-moving cube will get
collided with anyway.

Continuous collision detection is great for handling fast-moving objects,
but arguably handling cloth that is nearly at rest and continuously
colliding with the character is a much harder problem. Most cloth
simulation demo videos stop while everything is still in motion, but what
happens after is just as important.

Anyway, there's definitely much room for improvement here, but it should be
tested on real-world cases. For example from what I've seen, Bullet cloth
is more reliable at high frame rates, but does not produce good results or
wrinkling details when turning up the quality. I've not yet seen an
open-source cloth library that we could just plug in and get much better
results, but it would be great if there was one.

Some work on cloth collision is being done here:
https://developer.blender.org/D8577

On Tue, Oct 20, 2020 at 11:52 AM Ton Roosendaal via Bf-committers <
bf-committers@blender.org> wrote:

> Hi Joe,
>
> This is a bit harsh, there have been good cloth contributions to Blender
> by Luca Rood. The current module owner for it is Sebastian Parborg though.
>
> I'd suggest to connect with them to see what steps forward could be.
>
> We are also in the process of making a good node physics system to allow
> solvers like this in a more generic setting. Design for this is ongoing.
>
> It's super cool to see you want to come back, just give it a bit of time
> to figure out who's doing what now.
>
> Als note that we (including Blender Foundation / Institute) are in the
> process of organizing ourselves much better, including onboarding, best
> practices, engineering standards amd strict requirements for a good
> design process - including the docs.
>
> We lack in a lot of areas, and the consensus is to especially put
> efforts in bringing the current state of the code in control (functional
> and technical specs), before recoding modules entirely.
>
> -Ton-
> --
> Ton Roosendaal - t...@blender.org - www.blender.org
> Chairman Blender Foundation, Director Blender Institute
> Buikslotermeerplein 161, 1025 ET Amsterdam, the Netherlands
>
>
> On 20/10/2020 00:30, Joe Eagar via Bf-committers wrote:
> > So, ten years ago I wrote several continuous collision detection systems
> > for cloth/hair, one of which I tried to push into trunk:
> >
> > https://www.youtube.com/watch?v=QBM3TBKO9w8
> >
> > And, here's how the cloth sim performs today:
> >
> > https://www.youtube.com/watch?v=5462m9yEkU8=youtu.be
> >
> > If the cloth development process is this dysfunctional (this patch
> actually
> > passed review?
> > https://developer.blender.org/rB0666ece2e2f96571200d693d9d7bee1ca72d026f
> )
> > then I propose we eliminate the cloth code entirely and go with a third
> > party lib (Bullet?).
> >
> > Joe
> > ___
> > 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

Re: [Bf-committers] Commit access for branch

[Brecht Van Lommel via Bf-committers]

It's not clear to me that being triangle based only is a good thing about
dynamic topology. It would be better if it preserved ngons and only
triangulated parts of the mesh where actual changes are being made. And
also did not lose vertex colors and UV maps.

Maybe it's possible to use MVert and MPoly, and find a way to dynamically
grow/shrink the arrays? Then there would be one less special case in the
sculpt code.

On Wed, Oct 14, 2020 at 10:55 PM Joe Eagar via Bf-committers <
bf-committers@blender.org> wrote:

> I’ve actually copied the existing DynTopo code for a base, but with a
> triangle mesh lib (with a BMesh like API) instead of BMesh. I’m modifying
> it from there, design is contingent on further profiling (for example, I’m
> not sure we’ll end up needing the topology update to be multithreaded, so
> far most performance bugs have been cache related).
>
>
>
> On Wed, Oct 14, 2020 at 9:12 AM Dalai Felinto  wrote:
>
> > Hi Joe,
> >
> > By the way, could you please put together a design document before you
> > go on with the branch development? This way we can get the design
> > cleared out before you spend your time coding it.
> >
> > Thank you,
> > -Dalai-
> > 
> > Dalai Felinto - da...@blender.org - www.blender.org
> > Blender Development Coordinator
> > Buikslotermeerplein 161, 1025 ET Amsterdam, the Netherlands
> > <
> https://www.google.com/maps/search/Buikslotermeerplein+161,+1025+ET+Amsterdam,+the+Netherlands?entry=gmail=g
> >
> >
> > Em qua., 14 de out. de 2020 às 15:11, Dalai Felinto
> >  escreveu:
> > >
> > > Hi Joe,
> > >
> > > It is worth taking a look at this refresh course:
> > > https://wiki.blender.org/wiki/Developer_Intro/Committer
> > >
> > > It goes over format style, branches, test builds, ...
> > >
> > > And welcome back :)
> > > -Dalai-
> > > 
> > > Dalai Felinto - da...@blender.org - www.blender.org
> > > Blender Development Coordinator
> > > Buikslotermeerplein 161, 1025 ET Amsterdam, the Netherlands
> > >
> > > Em qua., 14 de out. de 2020 às 04:10, Joe Eagar via Bf-committers
> > >  escreveu:
> > > >
> > > > Thanks, I got it to work.  I was just confused.
> > > >
> > > > On Tue, Oct 13, 2020 at 6:11 PM Julian Eisel via Bf-committers <
> > > > bf-committers@blender.org> wrote:
> > > >
> > > > > Hey,
> > > > >
> > > > > People who had commit rights with SVN still have in the Git
> > repository. So
> > > > > you should already/still have them.
> > > > > Nowadays, giving commit rights means adding someone as member to
> the
> > BF
> > > > > Blender project on developer.blender.org <
> > http://developer.blender.org/>
> > > > > -- which you are:
> > > > >
> >
> https://developer.blender.org/project/?member=PHID-USER-dh5md27jh3dxb57kokls
> > > > > <
> > > > >
> >
> https://developer.blender.org/project/?member=PHID-USER-dh5md27jh3dxb57kokls
> > > > > >.
> > > > >
> > > > > Cheers,
> > > > > - Julian -
> > > > >
> > > > >
> > --
> > > > > Julian Eisel - jul...@blender.org - www.blender.org
> > > > > Software Developer
> > > > >
> > > > > > On 14. Oct 2020, at 01:25, Joe Eagar via Bf-committers <
> > > > > bf-committers@blender.org> wrote:
> > > > > >
> > > > > >
> > > > > > Hi.  I've been working on the DynTopo code a bit and I'd like a
> > branch to
> > > > > > commit my work.  Can I get whatever account permissions are
> needed
> > for
> > > > > > this?  I promise I won't commit to master. :P
> > > > > >
> > > > > > Best,
> > > > > > Joe Eagar
> > > > > > ___
> > > > > > 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 mailing list
Bf-committers@blender.org
https://lists.blender.org/mailman/listinfo/bf-committers

[Bf-committers] Bug Sprint Week - 2.90 Bcon2

[Brecht Van Lommel via Bf-committers]

Hi everyone,

This week we are doing another bug sprint, which will now be a regular part
of the release cycle. For more details, see the blog post:
https://code.blender.org/2020/07/bug-sprints/

Developers working for the Blender Institute will work the entire week of
July 13 to 17 exclusively on bug fixing. Everyone else is welcome to
contribute as well of course.

There will be another bug sprint in Bcon 3, planned for the week of August
3 to 7.

Thanks,
Brecht.
___
Bf-committers mailing list
Bf-committers@blender.org
https://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] 2.90 per-module roadmap

[Brecht Van Lommel via Bf-committers]

Details about planned version numbers are here:
https://code.blender.org/2020/05/long-term-support-pilot/
https://code.blender.org/2020/02/release-planning-2020-2025/

On Thu, Jun 11, 2020 at 7:34 PM Chad Fraleigh via Bf-committers
 wrote:
>
> Is the semantic versioning style migration (e.g. 3.x [or maybe 9.x])
> being revisited for 2.9x? Since last time it was after 2.80 was started
> and would have been too confusing to try then.
>
> On 6/10/2020 6:25 AM, Dalai Felinto via Bf-committers wrote:
> > Hi,
> >
> > Yesterday there were meetings with all the module owners regarding the
> > 2.90 targets. As always these are initial plans and are expected to
> > change.
> >
> > For a more detailed list, check the complete meeting notes:
> > https://devtalk.blender.org/t/2020-06-09-blender-2-90-roadmap/13788
> >
> > User Interface (*)
> > ===
> > * Modifiers new layout / drag & drop
> > * Statistics
> > * Cursors (and tools) final design.
> >
> > Modeling
> > ===
> > * Fast mesh editing T73360 (not the entire milestone)
> > * UV Editing polishing.
> > * Add Object Tool polishing.
> > * Polishing other tools.
> >
> > Python & Add-ons
> > ==
> > * No API breakage.
> >
> > Sculpt, Paint, Texture (*)
> > 
> > * Multires wrapping up.
> > * Vertex paint in sculpt.
> > * Technical debts
> >
> > Animation & Rigging
> > 
> > * Performance and bug fixing.
> >
> > Nodes & Physics
> > =
> > * Particles nodes as experimental feature - won’t be production ready
> > * Initial point cloud support
> > * OpenVDB integration with mantaflow
> > * Mantaflow usability polishing
> >
> > VFX & Video
> > ==
> > * Distortion nodes.
> > * Compositor - bug fixing.
> > * VSE - bug fixing but no refactor.
> >
> > EEVEE & Viewport
> > ===
> > * Motion blur.
> > * Stereoscopy polishing.
> > * Point cloud rendering.
> > * Vulkan groundwork (GL encapsulation, cleanups).
> > * Fix MacOS volume drawing.
> >
> > Data, Assets & I/O
> > ==
> > * Alembic refactor.
> > * USD exporter improvements.
> > * More work on static override
> >
> > Grease Pencil
> > ===
> > * Annotation arrows.
> > * Blocking and 3d-2d pipeline.
> >
> > Render & Cycles
> > =
> > * Embree.
> > * OIDN.
> > * Sampling patches.
> > * Other smaller patches.
> >
> > --
> >
> > (*) - both "User Interface" and the "Sculpt, Paint, Texture" modules
> > need an extra module-wide meeting to help clarify the targets. Both
> > are scheduled for next week.
> >
> > Thank you,
> > -Dalai-
> > 
> > Dalai Felinto - da...@blender.org - www.blender.org
> > Blender Development Coordinator
> > ___
> > 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

Re: [Bf-committers] Proposal: New Importer for both glTF and COLLADA

[Brecht Van Lommel via Bf-committers]

Hi Recep,

Thanks for the overview, AssetKit being a small well-written library
is good. However there would be a significant amount of work involved
in integrating it in Blender. Not just in getting the implementation
to work, but also in refining both AssetKit itself and the Blender
integration based on actual user testing, which is often the hardest
part.

We already have glTF and COLLADA integrations which while not perfect,
have been tested by users and improved over time. The glTF add-on in
particular has active developers. For COLLADA it's not clear it's
worth investing much time as it has few active users, and the standard
has not been updated since 2008.

I think changing as little as possible in COLLADA and working on
improving the glTF and USD integrations is the way forward for the
Blender project. It's not clear to me that integrating a library like
AssetKit is the most efficient way to do that.

Regards,
Brecht.


On Sat, May 16, 2020 at 6:44 PM Recep Aslantas via Bf-committers
 wrote:
>
> Hi,
>
> My name is Recep,
>
> I was working on library called AssetKit ( https://github.com/recp/assetkit )
> Recently I have implemented importing Morph Targets and Animation from glTF.
>
> AssetKit can import all glTF 2.0 and with 
> "KHR_materials_pbrSpecularGlossiness"
> extension. So it can import Metallic Roughness + Specular Glossiness 
> materials.
>
> It also supports COLLADA 1.4 and COLLADA 1.5 (common profile).
> It uses single interface for both glTF and COLLADA 1.4/1.5.
>
> AssetKit comes with lot of options (and utils), a few options are (all are 
> optional):
> * Triangulate polygons
> * Generate normals
> * Compute Bounding Box
> * Bugfixes for Transparency
> * Compute exact center
> * Convert Coordinate System to Another (Any-to-Any)
> I'm trying to make it faster and more flexible by time. Recently I have 
> written a json and xml parser
> to parse glTF and COLLADA fast as possible. These new parsers also reduced 
> the binary size and
> make the build time faster and portable. Because these are header-only, see 
> my Github https://github.com/recp?tab=repositories to see them
>
> AssetKit is written in C99 and its size is only ~ 240KB + 50KB stb_image.h == 
> 290KB, and it can import
> glTF and COLLADA files and load images. This will reduce Blender size too and 
> increase build time.
>
> The API interface must be very easy to work with.
>
> AssetKit also tries to make the loading and rendering faster by providing 
> utilities and options.
>
> For instance, after you loaded a file with AssetKit like:
>
> AkDoc *doc;
> AkResult ret;
>
> ret = ak_load(, "sample.gltf or .dae", NULL);
>
> you can import morph targets into single buffer with desired inputs with 
> desired order:
>
> void  *morphBuffer;
> size_t buffSize, targetByteStride;
>
> static AkInputSemantic desiredInputs[] = {
> AK_INPUT_SEMANTIC_POSITION,
> AK_INPUT_SEMANTIC_NORMAL,
> AK_INPUT_SEMANTIC_TANGENT
> };
>
> ak_morphInterleaveInspect(, , morph, desiredInputs, 
> 3);
> morphBuffer = malloc(buffSize);
> ak_morphInterleave(morphBuffer, morph, desiredInputs, 3);
>
> now you can pass morphBuffer to GPU directly. This is optional step of course.
>
> AssetKit also provides simple and elegant API like Javascript:
>
> object1 = ak_getObjectById(doc, "object-id")
> object2 = ak_getObjectByUrl(url)
>
> The memory management in AssetKit is awesome. It provides hierarchical memory 
> allocator,
> if you free parent node or document then sub nodes or the whole document will 
> be freed.
>
> I propose to replace OpenCOLLADA and glTF importer with AssetKit.
> AssetKit will also support additional formats without changed the integration 
> if possible
> as extension library like AssetKit-Ext.lib
>
> I can help to integrate it with Blender and feedbacks are always welcome.
> You can propose or request some changes before integration if you like it.
>
> I'll provide CMake build files as soon as possible. The exporter side will be 
> available in the future.
>
> Please take a look at the repo and sources at https://github.com/recp/assetkit
> and ask any questions if you have any.
>
> You will also get better support for this library than others :) I always 
> respond fast as possible on Github.
> Also any contributions/contributors/feedbacks... are always welcome.
>
> Thanks
>
> - Recep
> ___
> 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

Re: [Bf-committers] OptiX Denoiser

[Brecht Van Lommel via Bf-committers]

The release notes about Optix denoising are here.
https://wiki.blender.org/wiki/Reference/Release_Notes/2.82/Cycles#Denoising
https://wiki.blender.org/wiki/Reference/Release_Notes/2.83/Cycles#OptiX_Viewport_Denoising

Note there are specific requirements for graphics cards, driver versions,
and that viewport denoising was added only in 2.83.


On Wed, Apr 29, 2020 at 2:23 PM Никита Mitich via Bf-committers <
bf-committers@blender.org> wrote:

> Hello, maby i've got some wrong knowledge where to write. But i met a
> problem with OptiX, denoising. On official site there is article that OptiX
> Denoiser is included in Blender 2.82? but? unfortunately in my blender 2.82
> there isn't this thing though. I even can't find information about it in
> internet. I've redownloaded Blender, installed OptiX from Nvidia official
> one... Still no OptiX Denoiser for Cycles!
> Best wishes :D
> ___
> 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

Re: [Bf-committers] Google Summer of Code 2020

[Brecht Van Lommel via Bf-committers]

Blender supports matcaps and cavity for visualizing fine details when
sculpting, which is a pretty similar use case.

So I would recommend trying those and checking how the feature you propose
to add are different or how they might be integrated.

On Thu, Mar 12, 2020 at 1:14 PM Lorenzo Lastilla via Bf-committers <
bf-committers@blender.org> wrote:

> Hi,
>
> thank you very much for your reply and suggestions. I’ll keep them in mind
> when realizing the project proposal.
>
> Best regards,
> Lorenzo
>
> Il giorno mer 11 mar 2020 alle ore 18:58 Dalai Felinto 
> ha scritto:
>
> > Hi Lorenzo,
> > Fascinating research.
> >
> > The challenge for your project will be to find a way to present the
> > tools you have in a way that benefit people working outside the niche
> > of archeology. There is a sweet spot between proposing something too
> > simple, or too ambitious. Keep that in mind when proposing your set of
> > shaders and tools.
> >
> > All the information you need to submit a GSoC proposal is here:
> > https://wiki.blender.org/wiki/GSoC/Getting_Started
> >
> > Regards,
> > -Dalai-
> > 
> > Dalai Felinto - da...@blender.org - www.blender.org
> > Blender Development Coordinator
> >
> >
> > Em ter., 10 de mar. de 2020 às 15:27, Lorenzo Lastilla via
> > Bf-committers  escreveu:
> > >
> > > Dear all,
> > >
> > > I am Lorenzo Lastilla, a Ph. D. student in Data Science at Sapienza
> > > University of Rome. I am writing to you because I would really enjoy
> > > working with Blender community in occasion of the next Google Summer of
> > > Code 2020. My research field is focused on Digital Humanities, namely
> on
> > 3D
> > > digitization of ancient undeciphered scripts and on the development of
> > > strategies based on machine learning to help the paleographers to
> > decipher
> > > these scripts, in the context of the ERC INSCRIBE project (
> > > https://site.unibo.it/inscribe/en).
> > >
> > > Because of this, I would really be interested in developing ad-hoc
> > shading
> > > tools (such as radiance scaling, curvature enhancement) for
> > paleographical
> > > purposes (and, in general, for 3D shape analysis) on Blender, useful to
> > > enhance the legibility of the ancient scripts, which would be of utmost
> > > importance to scholars to disambiguate the debated inscriptions.
> > >
> > > I think that the scientific community would really benefit from this
> > > cooperation with yours, but also Blender would benefit from it, by
> > > expanding the spectrum of its users, in terms of quantity and type.
> > >
> > > For any clarification, do not hesitate to contact me.
> > >
> > > I thank you in advance for your availability.
> > >
> > > Best regards,
> > >
> > > Lorenzo
> > >
> > > --
> > > 
> > > Le informazioni
> > > contenute in questo messaggio di posta elettronica sono strettamente
> > > riservate e indirizzate esclusivamente al destinatario. Si prega di non
> > > leggere, fare copia, inoltrare a terzi o conservare tale messaggio se
> non
> > > si è il legittimo destinatario dello stesso. Qualora tale messaggio sia
> > > stato ricevuto per errore, si prega di restituirlo al mittente e di
> > > cancellarlo permanentemente dal proprio computer.
> > >
> > > The information
> > > contained in this e mail message is strictly confidential and intended
> > for
> > > the use of the addressee only.  If you are not the intended recipient,
> > > please do not read, copy, forward or store it on your computer. If you
> > have
> > > received the message in error, please forward it back to the sender and
> > > delete it permanently from your computer system.
> > > ___
> > > Bf-committers mailing list
> > > Bf-committers@blender.org
> > > https://lists.blender.org/mailman/listinfo/bf-committers
> >
>
> --
> 
> Le informazioni
> contenute in questo messaggio di posta elettronica sono strettamente
> riservate e indirizzate esclusivamente al destinatario. Si prega di non
> leggere, fare copia, inoltrare a terzi o conservare tale messaggio se non
> si è il legittimo destinatario dello stesso. Qualora tale messaggio sia
> stato ricevuto per errore, si prega di restituirlo al mittente e di
> cancellarlo permanentemente dal proprio computer.
>
> The information
> contained in this e mail message is strictly confidential and intended for
> the use of the addressee only.  If you are not the intended recipient,
> please do not read, copy, forward or store it on your computer. If you
> have
> received the message in error, please forward it back to the sender and
> delete it permanently from your computer system.
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> https://lists.blender.org/mailman/listinfo/bf-committers
>