Re: [Bf-committers] Migration to Gitea planned for tomorrow

[Sybren A . Stüvel via Bf-committers]

On Blender ID you can change your username. At the moment this does not
transfer to Gitea, though. The Gitea team is working on making this
possible for us, and I do expect it to be rolled out in the coming month or
so. Renaming users unfortunately is not that simple, because it also ties
into the location and URLs of their personal repositories.

The work on pushing username changes from Blender ID to Gitea is tracked at
https://projects.blender.org/infrastructure/blender-projects-platform/issues/1
The work on clarifying the "contact your site admin" is tracked at
https://projects.blender.org/infrastructure/blender-projects-platform/issues/53

Cheers,
Sybren

On Fri, 10 Mar 2023 at 12:38, happysmash27 via Bf-committers <
bf-committers@blender.org> wrote:

> I missed this email when it came in, and am only noticing now as I am
> resuming development and the source code wouldn't download with the old
> repository URL. How can I change my username to "happysmash27" at this
> point in time? Currently it says "Non-local users are not allowed to change
> their username. Please contact your site administrator for more details. ",
> but I do not know who the site administrator is.
>
> --- Original Message ---
> On Monday, February 6th, 2023 at 07:26, Brecht Van Lommel via
> Bf-committers  wrote:
>
>
> > 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
> ___
> 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] Enquiry about python contribution

[Sybren A . Stüvel via Bf-committers]

Hi Chirag,

Thanks for the offer to help!

If you want to indeed limit yourself to Python, that's fine. It means you
don't have to build Blender and can just edit files & see the changes.

https://wiki.blender.org/wiki/Developer_Intro is the place to start
reading. It'll cover a lot of things that are on the C/C++ side of Blender,
so you can skip those if you want.

Once you have more concrete questions, ask around on #blender-coders
 , there will be plenty of
people there to help you out.

Cheers,.
Sybren




On Tue, 29 Mar 2022 at 19:49, Chirag Mathur via Bf-committers <
bf-committers@blender.org> wrote:

> Hey there,
> I am a profecient coder in python and would like to contribute in blender
> using the same, I have taken a glance at the good first issues as well.
> It would be great if anyone of you could point me out as where and how to
> start with it, what to read, etc.
> A little help would be gladly appreciated.
> Thanks and regards
> Chirag Mathur
> (blender chat: Chirag-Mathur)
> ___
> 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] Studio Library addon

[Sybren A . Stüvel via Bf-committers]

Hi Martin,

Nice to meet you and welcome to this list.

On Mon, 14 Mar 2022 at 08:30, VDiabloV1 via Bf-committers <
bf-committers@blender.org> wrote:

> Currently, the workflow is very tedious for our animators, where many have
> suggested we develop a python tool similar to that of *Maya's "Studio
> Library"*: https://www.studiolibrary.com/
>

It's a little bit frowned upon to say something along the lines of "Blender
should be like tool X", as usually that's the extent of the feature
request. You're saying something different though, in that you've analysed
what Blender lacks, and even are willing to invest time into developing new
features!


> there is an asset browser that If I'm understanding correctly, can be used
> for any blender "data-block" asset.
>

In theory, it can. In alpha builds of Blender you can enable an
experimental flag that allows you to mark any data-block as asset. However,
this is experimental for a reason, as not all data-block types are equally
well supported. For example, you could mark a Collection as asset, but that
doesn't mean that a reasonable thumbnail is rendered, or that it works as
you expect when dragging the asset into a scene.


> Besides these similar present features, Blender still lacks an easy use,
> and convenient library for not only poses, and selection sets but
> ANIMATIONS as well. Where the artist can utilize a wide range of
> user-friendly organization tools to help them easily create assets that are
> aligned with their preferred workflow.
>

This is what's included in the design of the asset browser based pose
library. It's one of the major reasons that every pose asset is its own
Action data-block: to have space available for multiple frames of
animation. You might be interested in
https://code.blender.org/2021/05/pose-library-v2-0/ and
https://code.blender.org/2021/06/asset-browser-workshop-outcomes/ as well.


> *My question is:*
> Are there any Blender developers that are currently working on
> implementing these features?


Nope, nobody is working on that at the moment.


> If you guys aren't, I will just go ahead and try my hand at developing
> this python addon for Blender.
>

To be fair, I think this shouldn't be done in yet another add-on. Your help
is very much appreciated, and IMO the result of your efforts should be that
Blender itself has this functionality.

What I feel are the steps that need to be taken:

   1. Agree on terminology. We could call it "Animated Pose", or "Animation
   Asset", or "Animation Snippet Pose Asset", or anything else we can come up
   with.
   2. Design a way for artists to determine which frame range gets
   converted to an asset, and which keys/bones are (not) included.
   3. Design UI changes that are necessary for the asset browser to show
   that a pose asset is animated. This could include animated icons (probably
   only animating on mouse-over or something like that, to keep the UI calm).
   This might require quite a few changes in Blender's UI layer, as I don't
   think this is supported at all.
   4. Design different ways in which the animation can be applied to the
   current character. Snippets could be inserted (so any keys after the
   current frame get pushed back in time) or they could overwrite the current
   animation. This should also take care to properly handle pre-existing keys
   that fall between the keys of the animation snippet that overwrites them.
   And I'm sure there are more things to consider here.
   5. And then of course this needs to be implemented, tested, fine-tuned,
   etc.

Part of the implementation would go into the Pose Library add-on, and part
would be in C/C++ in Blender itself.

It's far from a trivial task, but I'd be super happy to have you on board
to work on this!

The project would have to involve the *Pipeline, Assets, and IO* module as
well; that's where the Asset Browser is managed, whereas the *Animation &
Rigging* module deals with the pose library and the other animation-related
functionality.

This Thursday at 18:00 CET/Amsterdam time we'll have the next Animation &
Rigging module meeting (agenda:
https://devtalk.blender.org/t/2022-03-17-animation-rigging-meeting-upcoming/23283).
This would be a great place to discuss this further. You can also find the
module members at https://blender.chat/channel/animation-module.

Cheers,
Sybren
___
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

[Sybren A . Stüvel via Bf-committers]

 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

Re: [Bf-committers] Change in code style guideline: location of documentation

[Sybren A . Stüvel via Bf-committers]

On Sat, 20 Nov 2021 at 05:26, Campbell Barton  wrote:

> > Please note that this is not a proposal to immediately start modifying
> all
> > of Blender's sources to put the docs in their new location.
>
> This sounds like header files not ending up as a good central
> reference for API's (which is one of the main benefits of the
> proposal) for as long as this is only applied to new code. Years could
> pass with many comments remaining in the implementation files instead
> of the headers.
>
> Worse, as long as they're split between both files, developers will
> need to check both the declaration and the implementation to know if a
> function has public-documentation or not.
>

I didn't want to muddle the "how do we want the code to be structured"
discussion with "when do we want to do the work" kind of discussions, or to
have it open to "but it would require so much work" counter-arguments. Now
that we have the "how" out of the way, it's indeed time for the "when".

Without pushing to migrate all doc-strings at once we could consider
> making each module team responsible for moving doc-strings into
> headers. If/when they think it's reasonable. Within a few releases (or
> less) the migration could be completed.
>

I think this is a nice approach. Not every module is equally active in
terms of development, so maybe at some point we'll have to do some
cross-module work anyway. We could create a task for each module to tackle
this, then at least we have a way to track the status.


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] Change in code style guideline: location of documentation

[Sybren A . Stüvel via Bf-committers]

Hi all,

Recently there has been a discussion about the location of code
documentation (as in, the in-source documentation comments). The gist of it
is that, in my opinion, documentation of the public interface of some
module should be done in its header file. This promotes black-boxing, and
gives a nice overview of how to use the code without having to dive into
the implementation details.

For a more thorough description, and to join in the discussion, please
visit https://developer.blender.org/T92709

If you agree with the proposal, please leave a thumbs-up token. If not,
please suggest how we can improve the proposal. Do that on the task itself,
though, and not here on the mailing list, so that we have all the
discussions in one place.

Please note that this is not a proposal to immediately start modifying all
of Blender's sources to put the docs in their new location. This guideline
would be in effect for new code, and can be handled as well for existing
code when people work on it.

If there are no major objections / adjustments, I want to put the new
guideline in effect in a week. That should give us plenty of time to get
the details right.

Cheers,
Sybren
___
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] Feature for 3D Animation

[Sybren A . Stüvel via Bf-committers]

Hi Sharvane Muralidharan,

There is a lot of info for new developers at
https://wiki.blender.org/wiki/Developer_Intro. If you have any questions
about what's written there, pop over to the #blender-coders channel on
Blender Chat (https://blender.chat/channel/blender-coders).

Before you start coding, it's a good idea to talk with the people of the
reponsible module. In your case, it would be the Animation & Rigging
module, who live in the #animation-module channel on Blender Chat. Make
sure that the feature you want to build, and the way you want to design it,
is aligned with the overall design of Blender. The best way to do this is
to talk with folks.

Cheers,
Sybren


On Tue, 28 Sept 2021 at 17:11, sharvane muralidharan via Bf-committers <
bf-committers@blender.org> wrote:

> Hey ,
> I would like to include a new feature into blender for 3D animation , to
> use motion capture algorithm and insert keyframes to the generated armature
> according to the movement of the subject(model) from the given video file.
> Is it possible to insert such feature in blender ?
> And what is the procedure to accomplish the same.
> ___
> 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!

[Sybren A . Stüvel via Bf-committers]

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

> Bundling does make a difference because it marks the add-ons as
> officially endorsed by Blender, they are available to every blender user
> and these add-ons are universally recognized and frequently mentioned in
> tutorials.


I agree.

Furthermore, moving add-ons to an online repository would
> negatively affect Blender users, invalidating many tutorials, and
> decreasing the attainability of tools that users have relied upon for
> years.


I disagree here. Having an online repository would:

   - make updating add-ons easier, allowing add-on developers to push
   updates faster than once per Blender release,
   - provide a unified way for add-ons to be published and made available
   in Blender, making more add-ons available with the same ease as the bundled
   ones,
   - make the base download of Blender smaller (by a small fraction, but
   still), and
   - given that it would still be possible to bundle add-ons together and
   provide them as one downloadable package, still allow for private/offline
   installs.


Blender is made for artists and other users, and not for the benefit of
tutorial makers. Tutorials can be updated, and new ones are made all the
time.


> Add-ons, plugins, mods, these are what make great enduring
> applications and vibrant, thriving, user communities, and it is to
> everyone's benefit to showcase and include them.
>

I agree, to the point that having easy updating, a publishing platform
that's available to more people, and that can include things like ratings,
reviews, a bug reporting system, etc. would benefit the people &
communities around Blender.


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

Having a curated list of add-ons is tangential to the way these add-ons are
distributed. This curation work could still happen for an online repository
as well. Might be an easier process too, and might make it more visible for
developers how to get your add-ons in there.


> All Blender devs, regardless of whether they are working on "core"
> Blender or an add-on, are required to provide documentation for the
> features they develop, and are generally expected to continue to develop
> and help maintain the area of their choice.  Since add-on developers put
> in similar work and their add-ons are distributed with Blender and
> provide part of its functionality, it seems natural that they should
> receive the same marketing, and that denying them that will only hurt
> Blender as a whole.


I agree that it would be nice for a page with "this is the new stuff you'll
get when you download this version of Blender" to also include some add-on
highlights.

Having said that, I don't think that it's a matter of "denying them [the
same marketing]". There is so much work done (also in the marketing
department) by so few people, that the lack of something could easily be
attributed to a lack of time. Where in the community is there a "changelog"
or "release notes" page that can be copied to the official fancy Blender
release notes? Who is taking it up themselves to do this work, to not only
keep track of what's changing, but also to cherry-pick the most important
changes, and to contact artists to show these off in some visually pleasing
way?

Only after the above has been done, and things are presented in a way that
is as nice (or maybe even better) than the current fancy release notes, and
then the offer to include that in the official release notes is still
denied, THEN you can talk about denying. Otherwise I would just see it as
"work not done" instead.


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

There is a difference between a paid-for online repository (like Blender
Market) vs. a Blender Foundation run (or backed) free repository that's
used by Blender by default. I think the latter would still be attractive,
regardless of the fact that there are other online add-on repositories out
there.

Cheers,
Sybren
___
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] Simple steps to get an harmonious collaboration

[Sybren A . Stüvel via Bf-committers]

On Wed, 2 Jun 2021 at 07:56, Campbell Barton via Bf-committers <
bf-committers@blender.org> wrote:

> If the proposed policies are followed to the letter, we end up in
> situations where extra review iterations would be required for running
> clang-format, stripping what-space and spelling mistakes.
>

I don't really see a problem here. Somebody needs to do that work anyway.
This is typically done by the patch author if they have commit access, and
a reviewer otherwise. As someone with too many unread emails from
still-to-be-reviewed patches, I would prefer to not have to do these
cleanups myself when I land a patch. Often such formatting & whitespace
issues can be solved permanently by configuring the patch author's IDE to
do this for them, after which all subsequent patches will be fine in this
respect. To me that looks like a better solution than to accept
badly-formatted patches. I know I'm polarizing the situation here, but I
also feel that if one extra review iteration is so troublesome, we could
also look at the source of that trouble and see if we can improve things.
For example, is `arc diff` too hard to use, and should we maybe look at
some other tool to make reviewing easier? Or should we have an automatic
cleanup on patches, so that they adhere to the coding standard?


> When the issues are trivial though (trailing white-space) it adds some
> burden on the patch reviewer to have to remember that some patch which
> was otherwise fine - needs an extra iteration.
>

You don't have to remember when you write it in the review comments.

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

Re: [Bf-committers] VFX reference platform 2022 draft

[Sybren A . Stüvel via Bf-committers]

On Tue, 18 May 2021 at 14:50, Ray Molenkamp via Bf-committers <
bf-committers@blender.org> wrote:

> As much as I picked on them last year for making very
> strange recommendations, I feel they struck a good balance
> for 2022.
>

You make a good point, as usual.

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

Re: [Bf-committers] VFX reference platform 2022 draft

[Sybren A . Stüvel via Bf-committers]

Hello,

On Mon, 17 May 2021 at 19:54, Brecht Van Lommel via Bf-committers <
bf-committers@blender.org> wrote:

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

Good call.


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

My preference would be to, for non-LTS releases at least, stick to versions
of Python that still receive bugfixes. In the past we've had crashes of
Blender that were due to a bug in Python. The only way to solve that was to
upgrade Python itself. This in itself is rare, but I don't remember having
such issues at all until we stuck to the old py3.7 to adhere to the VFX
Platform.

Is there anything known about the policy of the VFX Platform when it comes
to picking which Python version to stick to? Is it always going to be
"whatever version was released a year earlier"? Or is there still an
acceleration happening after sticking to py2.7 so long, and will they
eventually be targeting the latest versions? If it's the latter I'd be fine
with following the VFX Platform and sticking to py3.9 for a while longer.
If sticking to the platform means that for a significant amount of time
we'll be on versions of Python that don't receive bugfixes any more, I'm
less positive.

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

Re: [Bf-committers] Proposal: Export extensions for better integration with game engines.

[Sybren A . Stüvel via Bf-committers]

Hi Juan,

On Thu, 4 Mar 2021 at 19:05, Juan Linietsky via Bf-committers <
bf-committers@blender.org> wrote:

>The main topic is the ability for Blender to have a "Metadata Export"
> plugin. This means, that at the time of export,and for each object exported
> (node, material, skeleton, mesh, etc) Blender should be able to ask for
> "metadata" to the export plugins.


Either I'm not understanding things well, or there is some inconsistency in
the terminology. It seems that what you're describing is actually more
"extra data" or "augmentation" of the exported file format. For example,
what you descsribe in export of materials, splines, IK properties, etc.
are, at least from Blender's point of view, data, and not metadata.

What I mean is that I see a difference between:

   - What is exported? This seems like both data (camera/light parameters,
   physics sim results) and metadata (like a name-invariant identifier).
   - How is it exported? Here you could indeed (mis)use free-form metadata
   fields of the export file format to contain the data you're interested in.

I think it's bad to focus on the last bit, though, because if a file format
natively supports the desired data, it should be exported in that way and
not crammed into some metadata string field.

So, all this could be done if exporters polled export metadata plugins for
> metadata at the time of export (so we ensure we convert from the most
> recent version of the object) on any object, then added it in the exported
> data. This is a minimal non-invasive change in Blender exporters, but adds
> huge flexibility to engine export.
>

I don't know if I'm such a fan of "any add-on can add anything to any
exporter". More often than not, with an everything-should-be-possible
super-flexible design, things get very hairy.

Why not work on the glTF or USD exporter, so that it gets more powerful and
actually exports everything game engines like Godot (and others, of course)
need?

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

Re: [Bf-committers] Clang-Tidy: Request for Feedback

[Sybren A . Stüvel via Bf-committers]

On Thu, 4 Mar 2021 at 09:53, Sergey Sharybin via Bf-committers <
bf-committers@blender.org> wrote:

> - Do you have a strong feeling about leaving a .clang-tidy file as it is
> now (where file modification requires manual re-compilation) ?
>

No, not really. Of course it would be nice if changes are picked up
automatically, but I don't have a problem with an occasional clean +
rebuild.


> - What do you think we still need to do before we can call the project
> done?
>

There are a few rules mentioned in T78535 that haven't been crossed off
yet, but also have no clear status:
- readability-non-const-parameter and modernize-use-equals-default: seem to
still be in progress
- modernize-loop-convert: I worked on that before, but probably won't have
time to continue on it this Friday. I have some work for the studio that
has a clear deadline; I'll catch up on code quality work after that's been
delivered.
- modernize-pass-by-value: needs a decision on whether we want it or not.

I think these need a finalizing decision, to either continue & finish the
work, or a decision that it won't be done. After that I think we can call
the project finished.

- Shall we enable it by default? Maybe for `make developer` ?
>

To see the impact of that, I did a quick (N=1) test on my machine. I'm
using GCC 9.3 with CCache on the master branch. Both tests have had a full
build with this combo before measuring the build timing, so the CCache
cache is up to date. This to me is resembling my personal development
situation more than doing clean builds without caching.

Building without clang-tidy took 152 sec (wallclock time).
Building with clang-tidy took 275 sec (wallclock time).

This means that it's very roughly twice as slow to build with clang-tidy
enabled. To me this means that I won't be using it for regular builds in my
code-build-test cycle. If other developers feel the same way, that I expect
them to disable it right after they run `make developer`, in which case
it's probably better to just disable it by default.

- Any other relevant feedback?
>

IMO we should configure the buildbots to run with clang-tidy enabled. That
way violations of the rules are noted, even when most devs work with
clang-tidy disabled. Case in point: I had to fix one error before I could
run the above timing test.

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

Re: [Bf-committers] Blender developer meeting notes - 2020.02.01

[Sybren A . Stüvel via Bf-committers]

In short: yes.
For more info, take a look at https://developer.blender.org/T68908

Sybren

On Tue, 2 Feb 2021 at 05:38, Jacob Merrill via Bf-committers
 wrote:
>
> Is there any concern for animation speedups in the long term or short term?
>
> CPU armature skinning is very very slow for playblasts,
> everything else is top notch.
> ___
> 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

[Sybren A . Stüvel via Bf-committers]

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

Re: [Bf-committers] Suggestions for improving the triaging process

[Sybren A . Stüvel via Bf-committers]

Hey Philipp.

All these proposals make sense to me.

Sybren

On Mon, 23 Nov 2020 at 15:08, Philipp Oeser via Bf-committers
 wrote:
>
> Hi all,
> there was some recent talk amongst triagers about some issues / open 
> questions in our triaging process. This mail tries to sum them up and bring 
> forth possible ways to improve here.
> Feedback is welcome, everyone interested is also invited to join the new 
> https://blender.chat/channel/blender-triagers
>
>
> Problem 1 - Many reports marked with "Needs Triage" are 'stuck'
> 
> We already have guidelines on the triaging process such as
> https://wiki.blender.org/wiki/Process/Bug_Reports/Triaging_Playbook
> https://wiki.blender.org/wiki/Process/Help_Triaging_Bugs
> https://wiki.blender.org/wiki/Process/A_Bugs_Life
> But still, there are reports that are tagged "Needs Triage" longer than 
> desirable.
>
> Examples of these are
>
> *** No access to hardware/software needed to reproduce the problem ***
> In order to find someone quicker who could be able to reproduce 
> hardware/software specific issues, it would be good to gather this 
> information somewhere.
> ==> Proposal: The most obvious place would be the user profiles in 
> Phabricator where GPU (driver, OS, tablets, ...) could be stored, similar to 
> what **System Information** gives when reporting a bug
>
> *** It is a technical problem, but it is unclear if it involves a bug in 
> blender or the user's system ***
> These come in many different flavors like "installation problems", "computer 
> administration problems", "user support questions", "driver issues", "system 
> configuration issues".
> Often times, it can also take a bit of back and forth until it becomes 
> clearer if the issue is one of the above [in which case it could be closed]. 
> There might also be cases where only core developers can make that call.
> ==> Proposal: Triagers responsibility to add more canned responses that cover 
> more of these cases.
> ==> Proposal: Triagers responsibility to improve upon 
> https://docs.blender.org/manual/en/dev/troubleshooting
>
> *** It is unclear if the current behavior is a bug, a known limitation or 
> works as designed (but not in a user friendly way) -- or is a request ***
> There are many cases where this is not easy to decide. For all of these 
> cases, it is generally already well covered by our existing triaging process 
> documents on how to act.
> Issue is more getting to the point where it is clear enough to make the call 
> (often though only core developers can make that)
> ==> Proposal: More communication amongst triagers, synergetic effects will 
> happen. For this, https://blender.chat/channel/blender-triagers was set up.
>
> For the cases where only core developers can make a call, this also led to 
> questioning the usefulness of the "Needs Developer to Reproduce" status. This 
> was rarely used and/or its meaning not clear. Instead, a status indicating 
> the handover of responsibilty from the triaging team to the module teams 
> would be needed. This should only be used appropriate triaging already took 
> place.
> ==> Proposal: Add a "Needs Information from Developer" status (or even 
> better: rename the existing "Needs Developer To Reproduce" status)
>
> Problem 2 - Classification
> 
> In practice, until now, the triagers did a lot of classification [setting a 
> task's subtype] in their daily work (and hopefully the majority of it was 
> actually "correct").
> According to https://wiki.blender.org/wiki/Process/A_Bugs_Life, this is a job 
> for the module owners and development coordinators though. This has also led 
> to confusion when triagers set something e.g. as TODO - because this would 
> add to the responsibility of a particular module without consent.
> ==> Proposal: Refrain from setting task subtype (unless absolutely obvious or 
> prior approval was given [esp. TODO])
>
> Problem 3 - report priority / schedule
> 
> It was decided to align the ordering of reports to be looked at.
> Since different strategies were used ("daily fresh reports first", "previous 
> day's reports first", ...), this led to an unbalanced impression of sharing 
> 'enjoyable' workload.
> So while it might still make sense to have an eye on fresh reports as well to 
> catch bad bugs early on (esp. close to release), older reports should be 
> looked at first
> ==> Proposal: Prioritize older reports more
>
>
> If you actually reached the end of this: thx for reading!
> ___
> 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

[Sybren A . Stüvel via Bf-committers]

On Tue, 17 Nov 2020 at 13:33, Brecht Van Lommel via Bf-committers
 wrote:
> 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

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".

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.

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

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.
___
Bf-committers mailing list
Bf-committers@blender.org
https://lists.blender.org/mailman/listinfo/bf-committers

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

[Sybren A . Stüvel via Bf-committers]

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] Support for 32-bit architectures

[Sybren A . Stüvel via Bf-committers]

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] Animation & Rigging meeting notes

[dr . Sybren A . Stüvel via Bf-committers]

Hey all,

Today's Animation & Rigging module meeting notes are available on
devtalk:
https://devtalk.blender.org/t/2020-10-29-animation-rigging-module/15933

Cheers,

Sybren

-- 
dr. Sybren A. Stüvel

Blender Software Developer

https://blender.org/
https://cloud.blender.org/

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

[Bf-committers] Quaternion Interpolation

[dr . Sybren A . Stüvel via Bf-committers]

Hello all,

Recently there was an email discussion between Brecht, Stefan Werner and
Mark Theriault from Tangent Animation, and me, about quaternion
interpolation and the effect on motion blur. I have summarised the
discussion so far, and want to invite anyone who's interested to join in:

https://devtalk.blender.org/t/quaternion-interpolation/15883

Cheers,

Sybren

-- 
dr. Sybren A. Stüvel

Blender Software Developer

https://blender.org/
https://cloud.blender.org/

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

[Bf-committers] Animation & Rigging Meeting

[dr . Sybren A . Stüvel via Bf-committers]

Hi all,

Yesterday we had another Animation & Rigging meeting. As usual, the
meeting notes are available on devtalk [1]. The next meeting will be in
two weeks.

[1] 
https://devtalk.blender.org/t/2020-10-15-animation-rigging-module/15773/2

Cheers,

Sybren


-- 
dr. Sybren A. Stüvel

Blender Software Developer

https://blender.org/
https://cloud.blender.org/

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

Re: [Bf-committers] Policies about patches modifying third-parties libraries.

[Sybren A . Stüvel via Bf-committers]

My mail got a response, and with that it was fairly easy to remove the
hack. The exact changes are linked from https://developer.blender.org/T80320

Sybren

On 31-08-2020 15:37, Sybren A. Stüvel via Bf-committers wrote:
> Hi,
>
> I agree with Bastien, and have sent an email to the USD Interest group,
> with a CC on
> https://lists.blender.org/pipermail/bf-usd/2020-August/14.html.
>
> Kind regards,
>
> Sybren
>
>
> On 25-08-2020 21:05, Bastien Montagne via Bf-committers wrote:
>> Hi,
>>
>> Under build_files/build_environment/patches we have a bunch of small
>> patches for the libraries we build using make deps. Most of them are
>> about fixing builds for some platform or architecture, which is a bit
>> annoying but acceptable imho.
>>
>> However, today I discovered that Blender cannot be built with vanilla
>> USD library, at all. The patch used on this library adds some new
>> function to its API, which (hack over hack) is not even declared in
>> its headers, but in Blender code itself.
>>
>> I would very much like to propose to strictly forbid such dirty
>> practices, which violate completely the very idea of libraries,
>> especially on OSs like linux, where distributions try very hard to
>> only use dynamically linked shared libraries.
>>
>> Any library that would need that kind of modifications should be put
>> in extern/, and explicitly built as part of Blender itself. Or at the
>> very least, we should explicitly maintain our own 'fork' of it, with
>> requests to the main repo/maintainers to integrate our changes or
>> otherwise propose a solution to the problem.
>>
>> But I do hope there are ways to avoid such ugly changes anyway?
>>
>> Cheers,
>> Bastien
>>
>>
>> ___
>> Bf-committers mailing list
>> Bf-committers@blender.org
>> https://lists.blender.org/mailman/listinfo/bf-committers

-- 
dr. Sybren A. Stüvel

Blender Software Developer

https://blender.org/
https://cloud.blender.org/

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

Re: [Bf-committers] Policies about patches modifying third-parties libraries.

[Sybren A . Stüvel via Bf-committers]

Hi,

I agree with Bastien, and have sent an email to the USD Interest group,
with a CC on
https://lists.blender.org/pipermail/bf-usd/2020-August/14.html.

Kind regards,

Sybren


On 25-08-2020 21:05, Bastien Montagne via Bf-committers wrote:
> Hi,
>
> Under build_files/build_environment/patches we have a bunch of small
> patches for the libraries we build using make deps. Most of them are
> about fixing builds for some platform or architecture, which is a bit
> annoying but acceptable imho.
>
> However, today I discovered that Blender cannot be built with vanilla
> USD library, at all. The patch used on this library adds some new
> function to its API, which (hack over hack) is not even declared in
> its headers, but in Blender code itself.
>
> I would very much like to propose to strictly forbid such dirty
> practices, which violate completely the very idea of libraries,
> especially on OSs like linux, where distributions try very hard to
> only use dynamically linked shared libraries.
>
> Any library that would need that kind of modifications should be put
> in extern/, and explicitly built as part of Blender itself. Or at the
> very least, we should explicitly maintain our own 'fork' of it, with
> requests to the main repo/maintainers to integrate our changes or
> otherwise propose a solution to the problem.
>
> But I do hope there are ways to avoid such ugly changes anyway?
>
> Cheers,
> Bastien
>
>
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> https://lists.blender.org/mailman/listinfo/bf-committers

-- 
dr. Sybren A. Stüvel

Blender Software Developer

https://blender.org/
https://cloud.blender.org/

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

Re: [Bf-committers] Bug reports: requiring "Worked in" field

[Sybren A . Stüvel via Bf-committers]

On 12-03-2020 12:16, Howard Trickey wrote:
> How far back in versions do you expect people to check?

I'd expect 2.79 to be old enough. There are still issues that originate
from the 2.8 transition, and knowing whether something worked or not in
2.79 can help pin it down.

> I imagine sometimes, even often, the answer is "never". E.g., some new
> code has been added and a user has run into a case where that new code
> crashes.
Sure, for issues with new features it doesn't make sense to go back to a
version that didn't even have that feature yet.
> Maybe an exception should be made for crashes?

For a crash in a feature that's been around for a while, I think it
still helps to know when that crash was introduced. Of course when that
crash is caused by a driver bug it wouldn't matter much, as older
versions of Blender will still use the same buggy driver.

What I'm aiming for most of all, is that it becomes a normal part of the
bug reporting culture. Just as attaching an example blend file is
becoming more standard, so should IMO be testing with older versions.

-- 
dr. Sybren A. Stüvel

Blender Software Developer

https://blender.org/
https://cloud.blender.org/

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

[Bf-committers] Bug reports: requiring "Worked in" field

[Sybren A . Stüvel via Bf-committers]

Hello list,

When investigating a bug report, it can be very helpful to know when an
issue was introduced. I had a little discussion with Dalai on
#blender-coders, and we decided to make a change in the bug reporting
template [1]. The "Worked" field, where people fill out what version of
Blender still worked properly for them, is now no longer optional.

[1] https://developer.blender.org/maniphest/task/edit/form/1/

Of course we take a human approach to this, and there will be valid
reasons why this version cannot be determined or is otherwise
irrelevant. For the majority of bugs, however, it can be very helpful if
the reporter checks with older versions of Blender.

I want to suggest the following before accepting/confirming a report:

  * We should ask the reporter to test with older versions of Blender
(if not done already), and
  * The example blend file should be openable with that version.

The latter point is to prevent cases like "this worked in 2.79, here is
a 2.83 file to reproduce the issue".

I'm confident that the ability to quickly see the correct behaviour and
the problematic behaviour will help in the speed at which we can resolve
issues.

Cheers,

Sybren


-- 
dr. Sybren A. Stüvel

Blender Software Developer

https://blender.org/
https://cloud.blender.org/

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

Re: [Bf-committers] Tracker curfew and developer.blender.org changes

[Sybren A . Stüvel]

Hi all,

On 23-12-19 20:09, Dalai Felinto wrote:
> As of today the Blender development team starts a period of tracker curfew:
> https://code.blender.org/?p=3861

Many open tasks have been tagged with the 'Tracker Curfew' project. What
are we supposed to do with this tag? Should they be removed at some
point? I can't find any description about this on this mailing list or
on the code blog post.

-- 
dr. Sybren A. Stüvel

Blender Software Developer

https://blender.org/
https://cloud.blender.org/

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

Re: [Bf-committers] USD library

[Sybren A . Stüvel]

Dear macOS platform maintainers,

This is a gentle reminder to build the USD library for macOS. If there
is any difficulty with this, please let me know.

Cheers,

Sybren


On 13-12-19 10:43, Sybren A. Stüvel wrote:
> Dear list,
>
> I just committed the USD exporter to master
> (ec62413f803ee506633f0e52d1e52b0980c0ed0d). To use it, of course people
> need the USD library built. This can be done with `make deps`, not yet
> with `install_deps.sh`.
>
> Platform maintainers, please build the USD library for your platform and
> commit to SVN. I think this only applies to Arto, because LazyDodo
> already did this for Windows and I already did this for Linux/CentOS.
>
> Cheers,
>
> Sybren
>
>
-- 
dr. Sybren A. Stüvel

Blender Software Developer

https://blender.org/
https://cloud.blender.org/

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

[Bf-committers] USD library

[Sybren A . Stüvel]

Dear list,

I just committed the USD exporter to master
(ec62413f803ee506633f0e52d1e52b0980c0ed0d). To use it, of course people
need the USD library built. This can be done with `make deps`, not yet
with `install_deps.sh`.

Platform maintainers, please build the USD library for your platform and
commit to SVN. I think this only applies to Arto, because LazyDodo
already did this for Windows and I already did this for Linux/CentOS.

Cheers,

Sybren


-- 
dr. Sybren A. Stüvel

Blender Software Developer

https://blender.org/
https://cloud.blender.org/

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

[Bf-committers] Rename of Animation module to Animation & Rigging

[Sybren A . Stüvel]

Hey all,

After a discussion between the Animation module members [1] last week
and a talk between Dalai and myself today, I have renamed the Animation
module to Animation & Rigging. Alexander Gavrilov has been working on
improving constraints to suit the needs of riggers, and constraints was
not explicitly part of any module. Furthermore, even "rigging" wasn't
mentioned at all as a topic on the Modules wiki page. These things are
now rectified.

I haven't gone through any of the open rigging-related tasks to assign
them to the project, but I do think that's a good idea to do at least
for new tasks. Apart from the original #animation tag, there are now
also #animation_rigging and #rigging tags that are associated with the
Animation & Rigging project.

As a next step we'll talk with a few riggers to see who's interested in
joining as a user member.

Cheers,

Sybren


[1] https://devtalk.blender.org/t/partial-animation-module-meeting/10817

-- 
dr. Sybren A. Stüvel

Blender Software Developer

https://blender.org/
https://cloud.blender.org/

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

[Bf-committers] TBB version inconsistencies

[Sybren A . Stüvel]

Dear platform maintainers,

I recently updated the TBB library for Linux (in the
linux_centos7_x86_64 dir on SVN). The version installed by 'make deps'
is 2019.9, but the version in linux_centos7_x86_64 was still at 2018.0,
which caused issues with USD.

Here are the versions currently built for the other platforms:

- darwin: 2018.0
- win64_vc14: 2018.0
- win64_vc15: 2019.9

Is the win64_vc14 directory still used? It's not mentioned on
https://wiki.blender.org/wiki/Building_Blender/Windows.

Could the Darwin maintainer update the TBB library?

To be clear: I didn't upgrade to a new version of TBB, 2019.9 was
already in versions.cmake.

Thanks,

Sybren


-- 
dr. Sybren A. Stüvel

Blender Software Developer

https://blender.org/
https://cloud.blender.org/

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

Re: [Bf-committers] Alembic upgrade from 1.7.8 to 1.7.12

[Sybren A . Stüvel]

I have committed the new Alembic libraries for Linux to
lib/linux_centos7_x86_64.

Sybren


On 20-11-19 10:26, Sybren A. Stüvel wrote:
> Dear platform maintainers,
>
> I've just bumped Alembic from 1.7.8 to 1.7.12. This is not a
> needs-to-be-updated-right-now update, but it does add some functionality
> people have been waiting for a long time :-)
>
> Some context: Alembic 1.7.12 introduces a 'DCC FPS' hint, allowing
> Blender to write the scene frame rate to the Alembic file. This will
> make it possible for importers and converters to properly deal with
> situations where 'frame number' is the only reference to time. It should
> prevent issues like described in T55288, where Blender wrote correct
> data to Alembic, but the importing software made bad assumptions because
> it hard-coded 24 FPS.
>
> Currently only the Alembic library is upgraded from 1.7.8 to 1.7.12.
> Writing this new DCC FPS hint will be done in a separate commit once the
> platform libraries have been updated.
>
> Cheers,
>
-- 
dr. Sybren A. Stüvel

Blender Software Developer

https://blender.org/
https://cloud.blender.org/

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

Re: [Bf-committers] Modules simplification (and members cleanup)

[Sybren A . Stüvel]

On 20-11-19 15:39, Julian Eisel wrote:
> One thing that Sybren pointed out is that we should have a very
> precise definition of the roles first. Let's make misunderstandings
> hard. Then we can come up with suiting names.

Yup. I see too many discussions go back and forth between defining names
for the roles and defining the roles themselves.

I think Blender would benefit from a bit more scientific approach to how
we name things and how we write things down. In a (well-written)
scientific paper, one would use clearly defined terminology, either as
defined in other papers or by including the definition in the paper
itself. This I think applies to Blender as wel. There are many places
where the terminology is unclear, from the definition of roles to terms
in the user interface (just to name one example, the word "tweak" is
used a lot in the UI, but, until recently, was not defined anywhere). If
we want to make Blender more welcoming to new developers, ensuring that
they can actually understand and speak the same language as established
developers seems like a good idea.

Don't get me wrong, I'm not saying we should all stop working and give
this full priority. I do feel that this could be gradually improved,
though, and should be an area that gets attention during code &
documentation reviews.

> 1) Member
> With the definition you just gave for that role it sounds like a
> reasonable one. Just one question: Aren't they responsible for making
> decisions too?

I think we should distinguish between "capable" and "responsible". AFAIK
module members are capable of making decisions, but the
owner/coordinator is the one with the final say in things, i.e.
responsible for the final outcome.

I agree with your other points :)

-- 
dr. Sybren A. Stüvel

Blender Software Developer

https://blender.org/
https://cloud.blender.org/

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

[Bf-committers] Alembic upgrade from 1.7.8 to 1.7.12

[Sybren A . Stüvel]

Dear platform maintainers,

I've just bumped Alembic from 1.7.8 to 1.7.12. This is not a
needs-to-be-updated-right-now update, but it does add some functionality
people have been waiting for a long time :-)

Some context: Alembic 1.7.12 introduces a 'DCC FPS' hint, allowing
Blender to write the scene frame rate to the Alembic file. This will
make it possible for importers and converters to properly deal with
situations where 'frame number' is the only reference to time. It should
prevent issues like described in T55288, where Blender wrote correct
data to Alembic, but the importing software made bad assumptions because
it hard-coded 24 FPS.

Currently only the Alembic library is upgraded from 1.7.8 to 1.7.12.
Writing this new DCC FPS hint will be done in a separate commit once the
platform libraries have been updated.

Cheers,

-- 
dr. Sybren A. Stüvel

Blender Software Developer

https://blender.org/
https://cloud.blender.org/

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

Re: [Bf-committers] Screenshots for release log 2.81

[Sybren A . Stüvel]

On 13-11-19 06:07, Nathan Craddock wrote:
> Most of the new features there would be best shown with a video or GIF though.

Please use video files (MP4/h.264 or WebM/VP9), GIF has a horrible
compression ratio for video (among other downsides).


-- 
dr. Sybren A. Stüvel

Blender Software Developer

https://blender.org/
https://cloud.blender.org/

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

Re: [Bf-committers] Moving to Python-3.8

[dr . Sybren A . Stüvel]

On 07/11/2019 16:51, Damien Coureau wrote:
> The "joke" does not come from there but from Autodesk and The Foundry.
> The VFX Platform is actually trying to cope with it in a realist way and 
> slowly push everyone to the tip of progress.
Do you know when the platform will move to Python 3.8?

On 07/11/2019 20:16, Mikhail Rachinskiy wrote:
> There are inconsistencies with other libraries too:
>
> OpenVDB
> VFX Platform 7.x
> Blender 5.1
>
> OpenEXR
> VFX Platform 2.4.x
> Blender 2.3.0

Are there any concrete reasons we stick to those particular versions? Or
is it just a matter of someone taking the time to update them?


Sybren


-- 
dr. Sybren A. Stüvel
Software Developer at Blender

https://blender.org/
https://cloud.blender.org/

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

Re: [Bf-committers] Moving to Python-3.8

[dr . Sybren A . Stüvel]

On 03/11/2019 03:19, Campbell Barton wrote:
> I see no reason to stick to Python-3.7x for Blender-2.82 release.

Me neither, looking forward to using assignment expressions 

Sybren

-- 
dr. Sybren A. Stüvel
Software Developer at Blender

https://blender.org/
https://cloud.blender.org/

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

[Bf-committers] Mesh normals & Alembic

[Sybren A . Stüvel]

Hey all,

I want to change how Blender imports/exports mesh normals from/to
Alembic files. If you're interested, please have a look at
developer.blender.org/T71246. Either give it a ♥ token if you like it,
or pitch in with a comment if you see problems with it.

Best,

-- 
dr. Sybren A. Stüvel

Blender Software Developer

https://blender.org/
https://cloud.blender.org/

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

Re: [Bf-committers] Should we change the splash image when theversion number changes?

[Sybren A . Stüvel]

On 12-10-19 02:42, Stephen Swaney wrote:
> For a development splash, let's just take the last release splash and overlay
> it with some yellow police tape and Under Construction signs.

I think a possible downside of having the daily builds marked too much
as "different" could be that it scares people of. If we want to make it
tempting to use daily builds (which helps us find & fix bugs sooner in
the release cycle) we should make it as non-scary as possible.

-- 
Sybren A. Stüvel

https://stuvelfoto.nl/
https://stuvel.eu/

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

[Bf-committers] Platform maintainers: new lib + options for FFmpeg

[Sybren A . Stüvel]

Dear platform maintainers,

I just pushed two commits to master that require some libraries to be
rebuilt.

- libvpx: is now forced to configure with --enable-vp8 --enable-vp9.
Without this, VP9 wasn't enabled on buildbot builds.
- libopus: was added to add Opus audio support to FFmpeg
- ffmpeg: is build with Opus audio support

The steps required are:

- Rerun 'make deps'
- When updating an existing build (rather than building from scratch),
running 'cmake -U FFMPEG_LIBRARIES .` may be required in the build
directory to ensure the FFMPEG_LIBRARIES variable is refreshed to
contain the opus library.

This is not urgent, but would be nice if it happens relatively soon.

Thanks,

Sybren


-- 
Sybren A. Stüvel

https://stuvelfoto.nl/
https://stuvel.eu/

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

Re: [Bf-committers] New Animation module user owners

[Sybren A . Stüvel]

On 25-09-19 23:27, Luciano A. Muñoz Sessarego wrote:
> Will we use the https://blender.chat/channel/animation to discuss (?)

The main place for discussion is
https://blender.chat/channel/blender-coders. I made
https://blender.chat/channel/animation-module for when we want to have a
less crowded space to discuss things.

> Do we have a list of targets yet, or do we need to come up with something?

It's on https://developer.blender.org/, click on Animation in the
right-hand column.

-- 
Sybren A. Stüvel

https://stuvelfoto.nl/
https://stuvel.eu/

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

[Bf-committers] New Animation module user owners

[Sybren A . Stüvel]

Hello all,

The Animation module team is expanding, adding Luciano 'Looch' Muñoz as
user owner. He is, obviously, a Blender-using animator, and well known
in the Blender community and active in the bug tracker, Blender Chat,
and Devtalk. He joins Hjalti Hjálmarsson (Blender Studio) and Jason
Schleifer (Amazon) in the Animation module user team.

Welcome on board Looch!

-- 
Sybren A. Stüvel

https://stuvelfoto.nl/
https://stuvel.eu/

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

Re: [Bf-committers] BF coordination meeting 2019.09.02 notes

[Sybren A . Stüvel]

On 02-09-19 21:40, Nathan 'jesterKing' Letwory wrote:
> * Feedback handling of bi-weekly meeting.

'bi-weekly' is an ambigious term [1]. Shall we use 'twice-a-week' or
'fortnightly' instead?


[1] https://en.wikipedia.org/wiki/Biweekly

-- 
Sybren A. Stüvel

https://stuvelfoto.nl/
https://stuvel.eu/

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

Re: [Bf-committers] BF coordination meeting notes - 2019.08.12

[Sybren A . Stüvel]

On 12-08-19 13:59, Brecht Van Lommel wrote:
> The idea would be to have a flow like this for example. I think it
> would help to get better quality reports, or to help users find
> solutions themselves in some cases.
> https://docs.google.com/document/d/1gxuBv6aeZjKgzMQmGYdaERKbd7VnllSa9s_ejl2hMGo/edit#bookmark=id.83ndneimph3m
>
> I'm not sure what kind of priority this should have as far as
> improvement development infrastructure goes. It just seems to me that
> tweaking the text in the submission form is at a point of diminishing
> returns.

One thing that I see more and more on Github bug report templates are
checkboxes where reporters declare that they have done a certain thing.
For example, instead of us telling them "please install the latest
drivers", there would be a checkbox that says "[ ] I have installed the
latest drivers", and users have to fill it in with a [*]. This makes it
visually easier for us to see what has (not) been done (assuming honesty
of the reporter), and I also quite like the reverse psychology. It's my
expectation that it's easier to discard a request ("please install...")
than it is to lie on a form ("I have installed...").

Another difference between the Github and Phabricator forms is that on
the former HTML comments are not part of the rendered output. This
allows them to have instructions in the form that are not seen any more
once the form has been submitted (but still there when editing). This
would cut down on the times we see things like "Based on the default
startup or an attached .blend file (as simple as possible)" in the reports.

Of course a more complete multi-step wizard would be better, but maybe
the above can already improve the quality of the reports.

-- 
Sybren A. Stüvel

https://stuvelfoto.nl/
https://stuvel.eu/

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

Re: [Bf-committers] Developer cmake configuration

[dr . Sybren A . Stüvel]

Hi Brecht,

On 05-08-19 15:30, Brecht Van Lommel wrote:
> I've just committed a CMake configuration for developers, which
> enables debugging options, tests and speeds up compilation in some
> cases. See:
> https://developer.blender.org/rB2d60a5464
Thanks, that looks interesting.
> If you're not using this because it's failing or slow or inconvenient,
> we'd like to hear about it so we can gather those issues and solve
> them.

I would recommend separating the "configure CMake" and "build Blender"
steps. For me "make developer" fails in that second step because it's
trying to use Make and I use Ninja. Or maybe the build tool is something
that could be detected and used automatically?

I can't comment on other aspects just yet, haven't tested the new
settings well enough.

-- 
Sybren A. Stüvel

https://stuvelfoto.nl/
https://stuvel.eu/

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

Re: [Bf-committers] Upgrade Python 3.7.0 to 3.7.4

[dr . Sybren A . Stüvel]

PS: This is not an urgent needs-to-be-done-on-Friday-afternoon update.
We could decide to defer updating the platform libs a bit and do more
library updates in one go? Then again, if then something breaks it's
harder to tell which library update caused it.


On 02-08-19 16:55, dr. Sybren A. Stüvel wrote:
> Dear platform maintainers,
>
> I've just modified versions.cmake and install_deps.sh to install the
> latest version of Python, namely 3.7.4. Please update the platform
> libraries accordingly.
>
> https://developer.blender.org/rB454daf9b6b87d008e66650927109511f1c1befd2
>
> Kind regards,
>
> Sybren
>
>
-- 
Sybren A. Stüvel

https://stuvelfoto.nl/
https://stuvel.eu/

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

[Bf-committers] Upgrade Python 3.7.0 to 3.7.4

[dr . Sybren A . Stüvel]

Dear platform maintainers,

I've just modified versions.cmake and install_deps.sh to install the
latest version of Python, namely 3.7.4. Please update the platform
libraries accordingly.

https://developer.blender.org/rB454daf9b6b87d008e66650927109511f1c1befd2

Kind regards,

Sybren


-- 
Sybren A. Stüvel

https://stuvelfoto.nl/
https://stuvel.eu/

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

Re: [Bf-committers] 3d connexion support

[dr . Sybren A . Stüvel]

Hi Samuel,

On 19-07-19 17:40, Samuel Huster wrote:
> I recently bought a spacemouse from 3d connexion, because it makes Navigation 
> far more efficient and faster in the 3d viewport. However, while i was trying 
> to use it in blender i found out that it doesn't work properly due to lack of 
> support from blender wich is described in more Detail here: 
> https://www.3dconnexion.de/forum/viewtopic.php?f=25=38146=06e9d87483b731f4de9ee81c7f592366
For us developers it's pretty much impossible to get hardware supported
without having the actual hardware. If someone can sponsor a willing and
able developer a Spacemouse, then that developer may be able to do it.
> Is there anyway to improve compatibility in the upcoming blender 2.80 release?
Nope, it's far too close to the release date to get new features into 2.80.

-- 
Sybren A. Stüvel

https://stuvelfoto.nl/
https://stuvel.eu/

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

Re: [Bf-committers] FTP access to download.b.o (was: Blender 2.80 Release Candidate - master frozen)

[dr . Sybren A . Stüvel]

Hey all,

Just breaking this out to a different thread.

On 19-07-19 16:36, Dan McGrath wrote:
> My recommendation is to immediately disable and remove FTP from our server,
> and find alternative and secure means for the developers to share files.

I agree with Dan. FTP is a old, insecure protocol, and we don't need
anonymous uploads at all. Platform maintainers can use their SSH key to
gain access to the file storage.

> I would also strong advise that one of the developers create a GPG key that
> is stored safely ofline, which can be used to officially sign the MD5/SHA
> checksum files

I would recommend using a Yubikey for this, stored in a safe at the
Blender Institute. Getting the right key is easy once it's poured into
hardware.

-- 
Sybren A. Stüvel

https://stuvelfoto.nl/
https://stuvel.eu/

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

Re: [Bf-committers] Blender developers meeting notes - 2019-07-15

[dr . Sybren A . Stüvel]

On 15-07-19 14:38, Brecht Van Lommel wrote:
> 2) Weekly Reports
My weekly report is at
https://wiki.blender.org/wiki/User:Sybren/Reports/2019#July_8-14

-- 
Sybren A. Stüvel

https://stuvelfoto.nl/
https://stuvel.eu/

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

Re: [Bf-committers] Understanding the dev process

[dr . Sybren A . Stüvel]

Hey Nathan,

On 04-07-19 15:37, Nathan Letwory wrote:
> I'm most interested in finding out how devs perceive the process: what goes
> well, and even more so what causes trouble.

I think that what could use improvement is the interaction between
non-regulars and regulars in the blender-developers chat channel. My
GSoC student has asked questions there, but got completely ignored, and
I've seen others getting no answer either. Maybe there is a bit too much
of a not-my-area-of-Blender mentality going on, and on the other hand it
would be silly if people were swamped with "I don't know" answers. In
such a case, for every individual dev silence is better than saying "I
don't know", but that's only good for the question-asker if the actual
answer follows pretty shortly.


On 05-07-19 04:20, Campbell Barton wrote:
> Perhaps we can assign promising patches to review each release cycle
> (as part of per module tasks - see T63725).

Would it be a good idea to start assigning "milestones" to patches? In
practice this is probably only possible when the patch is close to
acceptance, because only then the true impact of the patch is known.

> Who are we making Blender for?
> ==
>
> With 2.8x and the introduction of tools,
> it strikes me that artists at the Blender Institute are not using it much
> (just my impression, maybe this changes over time).

This is a good point. I know for a fact that the animators aren't using
the new tool system at all, because it doesn't make sense to them -- the
"tools" as introduced in 2.8 are conceptually incompatible with the
animation tools they need. Tools for them are things like the pose
library (+the pose thumbnails add-on), selection sets, the Blenrig
control panel, and tools in the dopesheet editor. The tabbed T-panel had
space for the tools they need, but that's been removed with the promise
of something better. Only, that "something better" hasn't arrived yet
and also hasn't even been presented yet.

Hjalti and Nacho want to join the Animation module team, and I'm talking
with an external animator to get an outside perspective too.

Cheers,

-- 
Sybren A. Stüvel

https://stuvelfoto.nl/
https://stuvel.eu/

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

Re: [Bf-committers] Potentially moving from IRC to Blender.Chat

[dr . Sybren A . Stüvel]

On 30-04-19 16:18, Ton Roosendaal wrote:
> - Are there good options to manage trolls and bans?

Yes. We can ban user accounts on Blender.chat, and it's also harder to
create a new account on Blender ID than it is on FreeNode (you need
email verification). If it turns out to be necessary we can also invest
some time into adding Captchas and blocking of IP ranges to Blender ID.

-- 
Sybren A. Stüvel

https://stuvelfoto.nl/
https://stuvel.eu/

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

[Bf-committers] BAM superseded by BAT

[dr . Sybren A . Stüvel]

Hey all,

Blender Asset Manager (BAM) has been used by the Blender Institute (and
others) succesfully for years. However, it is time for it to retire to
make way for the young and shiny Blender Asset Tracer (BAT). BAT has
been used during the production of Agent 327 and Spring, is bundled with
the Blender Cloud add-on, and sees active development.

You can find BAT at https://developer.blender.org/project/profile/79/

Best,

-- 
Sybren A. Stüvel

https://stuvelfoto.nl/
https://stuvel.eu/

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

[Bf-committers] Potentially moving from IRC to Blender.Chat

[dr . Sybren A . Stüvel]

Hello everybody,

Last week during the Homestretch Sprint at the Blender Institute we
discussed the visibility of Blender development. One of the things we
want to improve is the clarity of decision making and visibility of
discussions between developers. Since IRC is getting less and less known
to new developers, we thought we might move the blendercoders channel to
blender.chat (which is a web-based chat system).

Of course we first want to have a few weeks to try it out and see if we
really like it. So, head over to
https://blender.chat/channel/blender-coders, log in with your Blender ID
account, and chat away!

If you have any issues, please let me know in a private mail or via
blender.chat.

Just for clarity: we will only move away from IRC if there is
considerable support for this move.

Best,

-- 
Sybren A. Stüvel

https://stuvelfoto.nl/
https://stuvel.eu/

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

Re: [Bf-committers] hello, world... :)

[dr . Sybren A . Stüvel]

On 12-02-19 11:57, dr. Sybren A. Stüvel wrote:
> Furthermore, it allows static type checking with mypy <https://mypy.org/>. 

Oops, that should have been http://mypy-lang.org/


-- 
Sybren A. Stüvel

https://stuvelfoto.nl/
https://stuvel.eu/

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

Re: [Bf-committers] hello, world... :)

[dr . Sybren A . Stüvel]

On 08-02-19 02:23, Benjamin Humpherys wrote:
> Bonus points if you use type annotations in your docstrings. A lot of 
> existing Python code was initially written before PEP484 and so the docstring 
> type annotations are often incompatible with standard Python type checking. 

My preference would be to not use docstring type annotations, but
actually use type hints as described in PEP 484
<https://www.python.org/dev/peps/pep-0484> and PEP 526
<https://www.python.org/dev/peps/pep-0526>. That way it's actually
executed Python code so mistakes are caught sooner, and there aren't
already multiple ways of doing the same thing. Furthermore, it allows
static type checking with mypy <https://mypy.org/>. I'm actively using
mypy in other Blender Institute Python projects and it helps
considerably in catching mistakes early.

-- 
Sybren A. Stüvel

https://stuvelfoto.nl/
https://stuvel.eu/

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

Re: [Bf-committers] Netrender?

[Sybren A . Stüvel]

On 08/10/2018 23:14, Alexander Kampmann wrote:
> Maybe the alternatives you pointed to should be more visible, I could
> not find them when I googled.

Does that mean you're volunteering to do marketing & SEO work for us?

Sybren
(lead developer of Flamenco)

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

[Bf-committers] libssl on macOS

[dr . Sybren A . Stüvel]

Hey all,

Python's _ssl module on current master and blender2.8 nightly builds
seems to be linking to /usr/local/opt/openssl/lib/libssl.1.0.0.dylib.
This file isn't guaranteed to exist on macOS machines, and as a result
HTTPS requests won't work. This means that the Blender ID and Blender
Cloud add-ons are broken, and so is the Benchmark Client. That last one
is rather urgent, as we want to push the Open Data platform
(https://opendata.blender.org/) out of beta phase, and that means it
should see testing on macOS clients.

To test this, you can simply do `import _ssl` in Blender's Python
console; it should work on a fresh macOS install.

Arto, is this something you can look into? It's has been a problem for a
while (T56329 and T56275 are fairly recent examples, but I remember this
going wrong months ago too).

Cheers,

-- 
Sybren A. Stüvel

https://stuvelfoto.nl/
https://stuvel.eu/

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

Re: [Bf-committers] Library updates for Blender 2.8

[Sybren A . Stüvel]

On 23/07/2018 19:43, Brecht Van Lommel wrote:
> * Python 3.7.0 (or should we wait until there is a 3.7.1 or so with
> bugfixes?)

Let's go to 3.7.0, unless somebody already knows of actual bugs that'll
influence our use.

Sybren

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

Re: [Bf-committers] FM 2.8 Proposal : Fracturing, Cache, Rigidbody

[dr . Sybren A . Stüvel]

This is a response to
https://lists.blender.org/pipermail/bf-committers/2018-February/049157.html
(I removed it from my mail server, so I can't hit 'reply' directly)


On 26-02-2018 22:54, Brecht van Lommel wrote:

> Thanks for the explanation. Overall I agree with the approach.
>
> It would be very helpful if this kind of functionality was submitted for
> review and integration in smaller parts. For example:
> [...]
> * Add Alembic support to point caches for physics systems. (could even
> replace custom point cache format)

Alembic is stricly a write-once file format [1]. This means that we
cannot update a part of a file; say the file contains frame range 1-250,
we won't be able to re-simulate frames 150-250 and update the file for
that. It can only be "updated" by reading the old file, updating its
contents where necessary, and writing to another file. Furthermore, an
Alembic file cannot be read until it is properly written *and closed*.

With this info about Alembic, what do you think about using Alembic
files for such caches? I'm not yet all that familiar with the current
physics caching system, but I do know it creates a file for every frame,
making it trivial to update frames. Is this actually used, though? Or
are we always sequentially writing to the cache?

We could work around these limitations of Alembic by writing continuous
frame sequences to a single file (so if you simulate 1-100 and then
press ESC, it would write to sim-001-100.abc), which can then be read
when replaying those frames. Simulating other ranges would then save to
other Alembic files (e.g. sim-101-140.abc). This could potentially
produce many small files, though, or cause problems where objects exists
in one file but not the other. Then again, we could have code to merge
sequences of Alembic files.

If not Alembic, what would be a good cache file format? Ideally I'd like
to use something that's already proven technology, rather than thinking
up something ourselves.

[1]
https://groups.google.com/d/msg/alembic-discussion/X-2ue86pw5g/Z2fZpW1eAgAJ


-- 
Sybren A. Stüvel

https://stuvelfoto.nl/
https://stuvel.eu/

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

Re: [Bf-committers] Porting modifiers > 2.8: hook

[Sybren A . Stüvel]

On 08-05-18 07:26, Christian Hubert wrote:
> OK, my confusion comes from "modifier_get_vgroup_mesh" which is not 
> retrieving the deform verts as the mesh is null (this is true for simple 
> deform modifier too

That was by mistake, see
https://developer.blender.org/rB002dcd200178c602474c3794c3c21e3b212e6e25


-- 
Sybren A. Stüvel

https://stuvelfoto.nl/
https://stuvel.eu/

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

Re: [Bf-committers] Efficient generic data structures for Blender?

[Sybren A . Stüvel]

Hi Christian,

On 08-05-18 13:32, Christian Hubert wrote:
> I've not found generic (template) data structures in Blender code for now. I
> mean some equivalent to std::xxx libs. Does that exist?

Much of Blender's code is written in C, so there are no templates there.
We use the BLI_ghash_xxx functions for hash maps.


> For information, what I've done so far is the following:
>
> * Compared performance of std::map vs. .Net dictionaries : .Net is
> about 100x faster than std (the test populates the structure of 100
> integers ; 50ms for .Net vs. 5s for std, both in debug mode)

AFAIK std::map uses an ordered set as backing for the map, and not a
hash as BLI_ghash_xxx does. Not sure what .Net does.

> * Coded an equivalent in C++, which now works for dictionary<int,
> int>: the perf is the same as the native .Net
> * To do: need more work as it is bugged for more complex things (as
> dictionary<int, dictionary<int, bool>> crashes in my actual code due to
> memory conflicts)

I don't think it's necessary to create such data structures ourselves,
as there are many available implementations for C++ out there already
(and they are probably well tested too)
Cheers,

-- 
Sybren A. Stüvel

https://stuvelfoto.nl/
https://stuvel.eu/

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

Re: [Bf-committers] Porting modifiers > 2.8

[Sybren A . Stüvel]

On 06/05/2018 10:29, Christian Hubert wrote:
> I don't know if all are already ported. But if I can help, feel free to
> propose me one or two to work on (I'll give a look if I can be able to do it
> before accepting).

I'm keeping https://developer.blender.org/T54737 up to date. Currently
I'm working on the Mesh Deform modifier. Maybe pick Boolean,
Triangulate, or Hook?

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

Re: [Bf-committers] Compiling and running 2.8

[Sybren A . Stüvel]

On 03-05-18 17:14, Christian Hubert wrote:
> But I now have another problem: modifiers results seems to be inactivated. 
> This is the case for array or mirror and for the randomize modifier I've 
> ported in 2.8. The code is run through but nothing is visible on screen.

They only work with the CoW enabled, so start Blender with
`--enable-copy-on-write`.

-- 
Sybren A. Stüvel

https://stuvelfoto.nl/
https://stuvel.eu/

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

Re: [Bf-committers] Code proposal for new modifiers

[Sybren A . Stüvel]

On 02-05-18 12:50, Christian Hubert wrote:
> I was unsure but I've set yourself as reviewer and me as suscriber (but I 
> don't really know what "suscriber" means here).

'Subscriber' means that you'll get email notifications about changes to
the diff. As an author you're automatically subscribed.

> Concerning your work on temp-modifier-rm-cddm. Yes, I've seen that and I will 
> try to set future diffs from this branch. But I've encountered an issue with 
> 2.8: it compiles but crashes at first run steps (information here 
> https://devtalk.blender.org/t/accessing-to-2-8-branch/353/2). I've just "git 
> checkout blender2.8" but don't know if it is enough (I don't know git... my 
> bad...).
>
> What I propose is to fix this issue before porting other things in the branch 
> you mentioned (temp-modifier-rm-cddm), but I've no idea how to fix it for now.

I wouldn't know how stable 2.8 is on Windows currently,  maybe someone
else can comment on this?

> Should I "git checkout temp-modifier-rm-cddm"? Simply and only that?

That should be enough, yes, but since it's been merged in 2.8 you can
simply use the blender2.8 branch instead. That'll have newer fixes anyway.

-- 
Sybren A. Stüvel

https://stuvelfoto.nl/
https://stuvel.eu/

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

Re: [Bf-committers] Using bpy* types in a standalone script?

[Sybren A . Stüvel]

Hi Torsten,

You can build Blender as a Python module [1], then you can import it
into your script. As a bonus, you won't even have to pickle/unpickle, as
you can directly access the data you're intersted in.

If you don't want this for some reason, I would recommend writing your
data to a file format that is independent of Blender's data model (like
JSON or YAML).

[1] https://wiki.blender.org/index.php/User:Ideasman42/BlenderAsPyModule

Cheers,
Sybren

On 02-05-18 00:20, tm...@s.netic.de wrote:
> Hello,
>
> Can I import bpy etc. in an own script (that is not running inside blender) to
> make use
> of these types?
>
> The background is that I would like to export some object data from within 
> python
> using pickle.dumps() and import it in an own script to further process it 
> there.
>
> Exporting works, but when importing (in a standalone script, not inside 
> blender)
> then the
> used data types are unknown.
>
> I would like to export / import data this way because a python export then 
> contains
> all data in he known format.
>
> It would be great if somebody could confirm / disconfirm if the bpy internal
> types can be used or not.
>
>
> Here is how I export the data:
> import bpy
> import pickle
> import zlib
>
> c = bpy.context
> d = bpy.data
>
> cp = pickle.dumps([c, d])
> cz = zlib.compress(cp)
> fd = open("/home/tmohr/blender/dcopy/dump.pz", "wb")
> fd.write(cz)
> fd.close()
> print("Done")
>
>
> Here is how I try to import the data again:
> import zlib
> import pickle
> import pprint
> import sys
>
> sys.path.append("/opt/blender-2.79a-rc-linux-glibc219-x86_64/2.79/scripts/modules")
>
> import bpy
>
>
> fd = open(sys.argv[1], "rb")
> cz = fd.read()
> cp = zlib.decompress(cz)
> c = pickle.loads(cp)
>
> pp = pprint.PrettyPrinter(indent=4)
> pp.pprint(c)
>
>
>
>
> Thanks for any hints,
> Torsten
>
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> https://lists.blender.org/mailman/listinfo/bf-committers

-- 
Sybren A. Stüvel

https://stuvelfoto.nl/
https://stuvel.eu/

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

Re: [Bf-committers] Code proposal for new modifiers

[Sybren A . Stüvel]

Hi Christian,


On 30-04-18 08:59, Christian Hubert wrote:
> I've coded two modifiers. The purpose at the beginning was to learn about
> Blender code, but finally the result could be of some interest as I've
> posted about it on right click select and the score seems to be good
> (https://blender.community/c/rightclickselect/85bbbc/fan-screw-variant-modifier
>  and
> https://blender.community/c/rightclickselect/35bbbc/randomize-modifier-proposal).

Both modifiers look really nice :)

> So from that, I'm in pain to find my way: how to obtain an approval about
> this dev? Should I simply post a diff here
> https://developer.blender.org/differential/diff/create/ and "no more"?

Please post two diffs (one for each modifier, unless they share a lot of
common code) there, and send us a link in a reply to this email.
Discussions about code are easier to do in the diff than here on the
mailing list.

Please also be aware of the work I'm doing in the temp-modifier-rm-cddm
branch (also see D3155), which changes the interface for modifier code.
If you have questions about this, don't hesitate to ask here too.

Kind regards,
-- 

Sybren A. Stüvel

https://stuvelfoto.nl/
https://stuvel.eu/

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

Re: [Bf-committers] Blender 2.8: Moving modifiers away from DerivedMesh

[Sybren A . Stüvel]

Hey,


On 17-04-18 14:16, Sergey Sharybin wrote:
> One of the design decision for Blender 2.8 was to switch modifier stack
> from DerivedMesh to Mesh.
>
> Here is a rough plan and ideas how to do this:
> https://wiki.blender.org/index.php/Dev:2.8/Source/Modifiers

Just like the current code, that wiki doc makes the distinction between
"Deformation-only" and "Constructive". When working with Alembic
importing this turned out to be a limitation, as in an Alembic file
sometimes the mesh is deformed and sometimes it needs to be
reconstructed from scratch (this can change from frame to frame). In the
current code this distinction is exclusive, that is, a modifier is
either deforming or constructing, but AFAIK can't be both. I just want
to point out that in future code we may want to allow a modifier to do both.

-- 
Sybren A. Stüvel

https://stuvelfoto.nl/
https://stuvel.eu/

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

[Bf-committers] Pose library fix for 2.79b?

[Sybren A . Stüvel]

Hey guys,

Will it be possible to include 14e7ba0c8ac [1] in 2.79b? Joshua took a
look at the commit as well, and it has his blessing.

[1] https://developer.blender.org/rB14e7ba0c8ac7f229a1b025103a786f267dfb938

Cheers,

-- 
Sybren A. Stüvel

https://stuvelfoto.nl/
https://stuvel.eu/

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

Re: [Bf-committers] Downloading 4.0

[Sybren A . Stüvel]

On 07-03-18 20:44, Knapp wrote:
> It should be easy to find and clearly state what is going on and what is
> expected of the user.
> None of this is really the case right now.
> I know that people often don't read the fine print but these things could
> me made bold and clear. [...]
>
> So, someone needs to write what stage 2.8 is at and give the appropriate
> warning and instruction for bug testers at this stage.

Sounds good. Why not make a mock-up of a web page that shows your
design? It's easy to point out what's wrong. If you can help our web
devs (read: Pablo) by showing instead of describing your design, I'm
sure he'd be happy to look.

-- 
Sybren A. Stüvel

https://stuvelfoto.nl/
https://stuvel.eu/

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

Re: [Bf-committers] Downloading 4.0

[Sybren A . Stüvel]

On 07-03-18 00:08, Ricardo Nunes wrote:
> in my opinion the download page is fine it is two flicks of scroll
> wheel to get to the huge red "experimental section"
> But if something had to be improved I guess the "Full featured, Free and
> Open source, Be part of it" and 2.79/Agent could be narrower equating in
> less scrolling.
> But at the moment I don't think it is worth the time to fix the graphics
> and website code when that time could be used in 2.8

Making 2.8 test builds harder to find is, I think, also a little bit
intentional. People don't read. They don't see that 2.8 is not released
yet, they just follow the Eevee hype and then are stumped when things
aren't stable.

-- 
Sybren A. Stüvel

https://stuvelfoto.nl/
https://stuvel.eu/

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

Re: [Bf-committers] Blender Asset Manager bug fixes

[Sybren A . Stüvel]

Hi Isaac,

On 25/02/2018 00:58, Isaac Weaver wrote:

A while ago I filled out these two bug reports for BAM which are holding up
a project I'm working on


BAM is hard to maintain, as over the years the functionality has grown 
way beyond its initial design limitations. As a matter of fact, I hit 
limitations of BAM too, and started working on a new incarnation called 
Blender Asset Tracer, or BAT驪 for short. Currently it resides in a 
personal repository at https://gitlab.com/dr.sybren/blender-asset-tracer.


Last week I've ported reading, writing, and iterating data blocks from 
BAM to BAT. Next week I'll be working on tracing, filtering, and 
modifying paths to dependencies. That should give enough functionality 
to reproduce the "bam pack" command.


Development of BAT驪 is driven by choices explained in T54125. Anyone 
with a vested interest is invited to join the discussion.


Cheers,
Sybren

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

[Bf-committers] GSoC 2018 student requirements

[Sybren A . Stüvel]

Hey list,

Ton suggested to me at some point that we should only accept GSoC 
students who already have worked on Blender in the past (submitted 
patches that actually got a positive review, or who already are active 
Blender developers). I fully agree that this is a good idea, as GSoC is 
not about teaching students how the innards of Blender work, but to get 
a concrete result that is useful to Blender's users.


Shall we adopt this as official policy? Or have we already and did I 
simply miss it?


Cheers,

Sybren

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

Re: [Bf-committers] Blender analytic drawing tool

[Sybren A . Stüvel]

Hi Ounan Ding,

On 12/02/2018 08:14, Ounan Ding wrote:

Recently I found a paper about analytic drawing [1], and then I try to
prototype it in Blender as an add-on. Here is a video of the prototype
running:
https://youtu.be/Nz_3_yRUxv0


That looks potentially pretty cool.


I would like to know your opinion about this tool before I proceed:
Is it contrived? Is analytic drawing useful for modeling?


Well, this is a developers' mailing list. I think you ask the right 
questions, but to the wrong people. Having a couple of artists who would 
actually use your add-on is very valuable, both to get feedback while 
you're developing and to create less contrived examples to showcase your 
add-on.


You could ask around on the Blender Artists forum?

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

Re: [Bf-committers] Discourse forum testers needed

[Sybren A . Stüvel]

Hey,

On 03/02/2018 23:48, Dan McGrath wrote:

I opened up a beta of the discourse forum to the public at
https://devtalk.blender.org/ for people to poke around in.


Please take a look at 
https://github.com/discourse/discourse-oauth2-basic and support OAuth2 
authentication with Blender ID. That way it'll hook nicely into the 
already-existing authentication infra. Bart Veldhuizen is also looking 
into this for the Discourse-based Blender Artists site, so maybe us 
three can team up to get things to work?


Sybren

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

Re: [Bf-committers] 2.79a release - proposed list of commits

[Sybren A . Stüvel]

On 27/12/17 12:05, Bastien Montagne wrote:
> First part are commits we think should be included, please
> double-check yours though.
> [...] You may also suggest other commit of course, just keep in mind
> that we want only fixes

I would like to see this commit in 2.79a too. I think it's a farily safe
fix, but it has been in master only for a few days and over Christmas
holidays, so I'm not sure how many people actually used it.

commit b1a036861ddd08c314587666a028a59bfb049e54
Author: Martin Felke <martin.fe...@googlemail.com>
Date:   Wed Dec 20 10:30:39 2017 +0100

    Fix T53572: Alembic imports UV maps incorrectly



Cheers,

-- 
Sybren A. Stüvel

https://stuvelfoto.nl/
https://stuvel.eu/


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

[Bf-committers] 2.79a: Blender ID Add-on update

[Sybren A . Stüvel]

Hey all,

There have been some improvements in the Blender ID add-on since 2.79
has been released. It makes it more future-compatible with possible
server-side changes, fixes a bug, and most importantly, reduces
confusion and makes users happy. I think the changes are safe to run in
2.79.

The commits are:

commit 6cdbffbc229bf263fa4b9b82a6e33b591c32934c
Author: Sybren A. Stüvel <syb...@stuvel.eu>
Date:   Fri Dec 15 10:13:04 2017 +0100

    Updated Blender ID add-on to version 1.4.1
   
    - Improved error reporting when validating a token fails due to
connection
  errors.

commit ff687ae6813e83002882632429c1abdf64060d57
Author: Sybren A. Stüvel <syb...@stuvel.eu>
Date:   Tue Dec 5 10:47:16 2017 +0100

    Updated Blender ID add-on to version 1.4:
   
    - Added an extra date/time format for parsing the authentication token
  expiry date.
    - Always show the "Validate" button when the user is logged in. This
  actively checks the token with the server, whereas the "You are logged
  in" only bases that statement on locally-available information (there
  is a token and it hasn't expired yet).

Cheers,

-- 
Sybren A. Stüvel

https://stuvelfoto.nl/
https://stuvel.eu/

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

Re: [Bf-committers] Patch: OCIO Parse Colorspace From Filename

[Sybren A . Stüvel]

On 2017-12-11 11:39, Dalai Felinto wrote:

Aren't you mixing color space and lens deformation? Troy is referring to
the former, while you seem to be talking about the latter.


Yes, and that's on purpose, as it shows the danger of trying to extract 
semantics from file names.



That said, if you do use "_linear" as a suffix for your filenames, the
image will be opened as linear, although you may not want it in some rare
cases like yours. The patch could have this as an option for the file open
dialog, similar to how we do for multi-view, but in this case, on by
default.


I agree. IMO it should also be explicit that the file name matters when 
it comes to colour interpretation. I think an option "Guess colour space 
from filename" with a bit more explanation in the tooltip would suffice.


What would happen with AdobeRGB data in "planks_linear.jpg"? In other 
words, who wins when the filename and embedded profile are conficting?


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

Re: [Bf-committers] Patch: OCIO Parse Colorspace From Filename

[Sybren A . Stüvel]

On 2017-12-11 06:48, Troy Sobotka wrote:

With this patch, filenames such as rubber_srgb.png, treealbedo_linear.tiff,
facescan_acescg.tiff, etc. will all honour the colourspace if it is found
in the
given configuration.


What would this do when I have two versions of the same scene, one shot 
with a rectinilear lens and one with a fisheye lens, and save the images 
to scene_linear.png and scene_fisheye.png? Would this patch influence 
the colour space used for saving the images?


Sybren

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

Re: [Bf-committers] Blender Development Forum Proposal

[Sybren A . Stüvel]

On 21/11/17 17:52, Aaron Carlisle wrote:
> While discord has some nice benefits there is something
> to be said about just sticking with the software we already use.

I think that from a usability perspective this may be the wrong
reasoning. Of course it's nice that people who already use dev.b.o can
then use something they're familiar with. However, if we want to attract
more people, who are new to the Blender ecosystem, we should look at
what *they* are used to. In that sense I think Discord will be the more
familiar/popular of the two (based on personal experience; I've seen
Discord before and heard different people say they use it, but never
heard of Ponder).

-- 
Sybren A. Stüvel

https://stuvelfoto.nl/
https://stuvel.eu/

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

Re: [Bf-committers] Alembic Export Apply modifier

[Sybren A . Stüvel]

Hi Michael,


On 21/11/17 10:44, Michael DELAPORTE wrote:
> In the bpy.ops.alembic_export, there is an option to apply_subdiv but it 
> would be great to have a use_mesh_modifiers like in the OBJ exporter.

What would that do that the exporter doesn't do at this moment?

The decision to apply subdiv or not is rather unique, in that Alembic
actually supports a schema that indicates "this mesh should be
subdivided". You can thus choose to export the non-subdivided mesh, and
have it re-subdivided upon import. This makes the Alembic file much
smaller, and allows for fast subdivision methods like OpenSubDiv. All
other modifiers (when enabled for rendering) are applied before writing
the mesh to the Alembic file.

> And is there a reason for the alembic export to be located in the 
> bpy.ops.wm.alembic_export instead of bpy.ops.export_scene.abc like other 
> exporters?

Historical; this was part of the patch given to use by DwarfLabs [1]. My
guess is that they mimicked the Collada exporter, which is
bpy.ops.wm.collada_export [2].

[1] https://developer.blender.org/D1783
[2]
https://docs.blender.org/api/current/bpy.ops.wm.html#bpy.ops.wm.collada_export

Cheers,

-- 
Sybren A. Stüvel

https://stuvelfoto.nl/
https://stuvel.eu/

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

Re: [Bf-committers] GSoC mentor summit

[Sybren A . Stüvel]

On Wed, Oct 25, 2017 at 04:54:36PM +0200, Ton Roosendaal wrote:
> For example, Nils Thuerey did it for fluids. 
> It's not about a PhD having free time, it's combining the PhD work
> with Blender.

Yes, ok, that might work indeed. I did the same with my work on the
Game Engine.


-- 
Sybren A. Stüvel

https://cloud.blender.org/
https://stuvelfoto.nl/
https://stuvel.eu/


signature.asc
Description: PGP signature
___
Bf-committers mailing list
Bf-committers@blender.org
https://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] GSoC mentor summit

[Sybren A . Stüvel]

On 23/10/17 20:18, Ton Roosendaal wrote:
> Our main action point for a successful 2018 GSoC would be to have an active 
> campaign targeted at universities with strong CG education (to attract phd 
> students too).

As a former Ph.D. student: I sincerely doubt that any Ph.D. student
worth his salt has time to join the GSoC. I finished my Ph.D. with a big
surplus of vacation days that I would never be able to use, simply
because the progress of my research demanded all of my time. Would we
want to attract a Ph.D. student who claims to have months of free time
available?

-- 

Sybren A. Stüvel

https://stuvelfoto.nl/
https://stuvel.eu/

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

Re: [Bf-committers] Using wheels in blender addons

[Sybren A . Stüvel]

Is aiohttp really necessary? I mean, we already bundle the Requests
library, so doing HTTP calls is already possible.

As far as asyncio goes, I've used it for the Blender Cloud add-on, and
it worked alright. I'm still not 100% convinced it's The Way To Go for
Blender, it has its pros and cons. However, you could take a peek at the
source code [1] to see how I used Requests with asyncio.

[1] https://developer.blender.org/diffusion/BCA/

Cheers,

Sybren


On 09/10/17 22:12, Isaac Weaver wrote:
> I'm currently working on an addon that I would like to eventually get
> included in Blender and was wondering if​ it's ok to use python wheels. The
> guidelines say not to use binary files (
> https://wiki.blender.org/index.php/Dev:Doc/Process/Addons#Never_Do) but I'm
> wondering if that applies to wheels as well (I know the blender cloud addon
> uses a couple of wheels). Specifically, I'd like to include a wheel for
> aiohttp.
>
> Thanks,
>
> ~ Isaac
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> https://lists.blender.org/mailman/listinfo/bf-committers

-- 
Sybren A. Stüvel

https://stuvelfoto.nl/
https://stuvel.eu/

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

Re: [Bf-committers] Blender connecting to web (or cloud services)

[Sybren A . Stüvel]

Hey,

On 03/10/17 12:25, Francesco Siddi wrote:
> The Blender ID add-on requires explicit user actions in order to connect to 
> the Internet (the user has to enter credentials and press Login).

Same for the Blender Cloud add-on. No network connection unless
initiated by the user.

-- 
Sybren A. Stüvel

https://stuvelfoto.nl/
https://stuvel.eu/

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

Re: [Bf-committers] GCC compiler

[Sybren A . Stüvel]

On Sun, Sep 17, 2017 at 02:14:07PM -0300, Ivam Pretti wrote:
> Is it possible to compile blender with GCC or even devC++ or another
> them cmake and scons?

GCC is used by a lot of developers, so yes, it's certainly possible.

CMake just creates the Makefiles, and doesn't actually do any
compiling or linking.

Scons has been deprecated for a while now.

-- 
Sybren A. Stüvel

https://cloud.blender.org/
https://stuvelfoto.nl/
https://stuvel.eu/


signature.asc
Description: PGP signature
___
Bf-committers mailing list
Bf-committers@blender.org
https://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Please review mailing list configurations - Bf-committers Digest, Vol 158, Issue 1

[Sybren A . Stüvel]

Sergey, could this be due to the recent work on Proog?


On 2017-09-10 21:03, Jacob Merrill wrote:

yeah I have not been getting it either

On Sep 10, 2017 10:52 AM, "INTERLICHTSPIELHAUS" <
interlichtspielh...@gmail.com> wrote:


Aaron Carlisle wrote:
Hi, You can fix this by visiting
https://lists.blender.org/mailman/options/bf-committers

no i can't


i receive digest

and i want to receive digest

  , which is normally sent once a day


but somehow since there has been some mail server work done

  , the digest are not sent as they were before


the digest i received contains 83 mails starting somewhere in august




On Sun, Sep 10, 2017 at 1:18 PM, INTERLICHTSPIELHAUS < interlichtspielhaus
at gmail.com >
wrote: >* hi *> >* can someone review the configurations of the mailing
lists *> >* yesterday i received a digest mail of Bf-committers *> >* turns
out it contains 3 weeks worth of mails, *>* digest mails were sent every
day at noon*


On Sun, Sep 10, 2017 at 7:18 PM, INTERLICHTSPIELHAUS <
interlichtspielh...@gmail.com> wrote:


hi

can someone review the configurations of the mailing lists

yesterday i received a digest mail of Bf-committers

turns out it contains 3 weeks worth of mails,
digest mails were sent every day at noon



-- Forwarded message --
From: 
Date: Sat, Sep 9, 2017 at 3:37 PM
Subject: Bf-committers Digest, Vol 158, Issue 1
To: bf-committers@blender.org


Send Bf-committers mailing list submissions to
 bf-committers@blender.org

To subscribe or unsubscribe via the World Wide Web, visit
 https://lists.blender.org/mailman/listinfo/bf-committers
or, via email, send a message with subject or body 'help' to
 bf-committers-requ...@blender.org

You can reach the person managing the list at
 bf-committers-ow...@blender.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Bf-committers digest..."


Today's Topics:

1. Re: Audaspace 1.3 for Blender 2.8 (J?rg M?ller)
2. Re: Audaspace 1.3 for Blender 2.8 (Sergey Sharybin)
3. Re: Audaspace 1.3 for Blender 2.8 (Jeffrey)
4. Memory map (Ivam Pretti)
5. Re: Breaking fundamental functionality in Blender 2.79?
   (Aaron Carlisle)
6. Blender developers weekly meeting notes: 2017-08-20
   (Ton Roosendaal)
7. CMake version bump for blender2.8 (J?rg M?ller)
8.  Blender 2.8 planning notes 2017-08-21 (Bastien Montagne)
9. Blender developers meeting notes - 2017-08-27 (Ton Roosendaal)
   10. Failing addons/module load tests (Sergey Sharybin)
   11. Re: Failing addons/module load tests (Campbell Barton)
   12. Re: Failing addons/module load tests (Campbell Barton)
   13. Blender 2.8 planning notes 2017-08-28 (Campbell Barton)
   14. Weekly meetings and communication channels (Ton Roosendaal)
   15. Re: Weekly meetings and communication channels (Aaron Carlisle)
   16. is static analyzer working? (Tom M)
   17. Create a page for my addons (xavier loux)
   18. Revisions for 2.79 ReleaseCandidate 3 (Sybren A. St?vel)
   19. Re: Revisions for 2.79 ReleaseCandidate 3 (Jacob Merrill)
   20. Re: Revisions for 2.79 ReleaseCandidate 3 (Lukas Stockner)
   21. Re: Revisions for 2.79 ReleaseCandidate 3 (Jacob Merrill)
   22. Re: is static analyzer working? (Campbell Barton)
   23. Re: VSE devs? (Alberto Mardegan)
   24. Re: Weekly meetings and communication channels (Campbell Barton)
   25. Re: VSE devs? (OllyFunkster)
   26. Re: Weekly meetings and communication channels (Stefan Werner)
   27. Re: VSE devs? (Alberto Mardegan)
   28. Re: Weekly meetings and communication channels (Campbell Barton)
   29. Re: Failing addons/module load tests (Campbell Barton)
   30. Re: CMake version bump for blender2.8 (Dalai Felinto)
   31. Re: CMake version bump for blender2.8 (Bastien Montagne)
   32. Re: CMake version bump for blender2.8 (Campbell Barton)
   33. Re: CMake version bump for blender2.8 (Dalai Felinto)
   34. Re: CMake version bump for blender2.8 (Campbell Barton)
   35. Re: Weekly meetings and communication channels (Aaron Carlisle)
   36. with_system_glew / gles options on linux. (Ray Molenkamp)
   37. Blender 2.8, OpenGL 3.3, and newer versions and extensions
   (Dalai Felinto)
   38. Re: Weekly meetings and communication channels (Brecht Van Lommel)
   39. Re: with_system_glew / gles options on linux. (Brecht Van Lommel)
   40. Re: Weekly meetings and communication channels (Corey Richardson)
   41. Re: Weekly meetings and communication channels (Corey Richardson)
   42. Re: Weekly meetings and communication channels (Campbell Barton)
   43. File size attached in the bug tracker. (Nahuel Belich)
   44. make.bat make.exe name collision/confusion (Nicholas Rishel)
   45. Re: make.bat make.exe name collision/confusion (Ray Molenkamp)
   46. Re: with_system_glew / gles options on linux. (Brecht Van Lommel)
   47. Re: with_system_glew / gles 

Re: [Bf-committers] Blender Need an evaluation

[Sybren A . Stüvel]

quot;Set owner by active selection"
>   bl_idname = "object.setownerbyactive"
>   bl_description = "Set owner by active selection"
> 
>   def execute(self, context):
>   try:
>   bpy.context.scene["CollisionAndSocketOwner"] = 
> bpy.context.active_object.name
>   except:
>   pass
>   bpy.context.scene["CollisionAndSocketOwner"] = ""
>   return {'FINISHED'}
> 
> class ConvertToUECollisionButtonBox(bpy.types.Operator):
>   bl_label = "Convert to box (UBX)"
>   bl_idname = "object.converttoboxcollision"
>   bl_description = "Convert selected mesh(s) to Unreal collision ready 
> for export (Boxes type)"
> 
>   def execute(self, context):
>   ConvertMeshToUe4Collision("Box")
>   return {'FINISHED'}
> 
> 
> class ConvertToUECollisionButtonCapsule(bpy.types.Operator):
>   bl_label = "Convert to capsule (UCP)"
>   bl_idname = "object.converttocapsulecollision"
>   bl_description = "Convert selected mesh(s) to Unreal collision ready 
> for export (Capsules type)"
> 
>   def execute(self, context):
>   ConvertMeshToUe4Collision("Capsule")
>   return {'FINISHED'}
> 
> 
> class ConvertToUECollisionButtonSphere(bpy.types.Operator):
>   bl_label = "Convert to sphere (USP)"
>   bl_idname = "object.converttospherecollision"
>   bl_description = "Convert selected mesh(s) to Unreal collision ready 
> for export (Spheres type)"
> 
>   def execute(self, context):
>   ConvertMeshToUe4Collision("Sphere")
>   return {'FINISHED'}
> 
> 
> class ConvertToUECollisionButtonConvex(bpy.types.Operator):
>   bl_label = "Convert to convex shape (UCX)"
>   bl_idname = "object.converttoconvexcollision"
>   bl_description = "Convert selected mesh(s) to Unreal collision ready 
> for export (Convex shapes type)"
> 
>   def execute(self, context):
>   ConvertMeshToUe4Collision("Convex")
>   return {'FINISHED'}
> 
> 
> class ConvertToUESocketButton(bpy.types.Operator):
>   bl_label = "Convert to socket (SOCKET)"
>   bl_idname = "object.converttosocket"
>   bl_description = "Convert selected empty(s) to Unreal sockets ready for 
> export"
> 
>   def execute(self, context):
>   ConvertEmptyToUe4Socket()
>   return {'FINISHED'}
> 
> 
> class ExportForUnrealEngineButton(bpy.types.Operator):
>   bl_label = "Export for UnrealEngine 4"
>   bl_idname = "object.exportforunreal"
>   bl_description = "Export all objet intended for export in scene to fbx"
> 
>   def execute(self, context):
>   ChecksProp(bpy.context.scene)
>   ExportAllByList(FindAllObjetsByExportType("export_and_childs"))
>   ExportComplete(self)
>   return {'FINISHED'}
> 
> class CorrectBadPropertyButton(bpy.types.Operator):
>   bl_label = "Correct bad property"
>   bl_idname = "object.correctproperty"
>   bl_description = "Corrects bad properties"
> 
>   def execute(self, context):
>   CorrectBadProperty(self)
>   return {'FINISHED'}
> 
> 
> #[...]#
> 
> 
> def register():
>   bpy.utils.register_module(__name__)
>   bpy.types.Scene.my_prop = bpy.props.StringProperty(default="default 
> value")
>   initObjectProperties()
>   initSceneProperties()
> 
> 
> def unregister():
>   bpy.utils.unregister_module(__name__)
> 
> 
> if __name__ == "__main__":
>   register()

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


-- 
Sybren A. Stüvel

https://cloud.blender.org/
https://stuvelfoto.nl/
https://stuvel.eu/


signature.asc
Description: PGP signature
___
Bf-committers mailing list
Bf-committers@blender.org
https://lists.blender.org/mailman/listinfo/bf-committers

[Bf-committers] Revisions for 2.79 ReleaseCandidate 3

[Sybren A . Stüvel]

Hey list,

I've just fixed an Alembic crash that would be great to have in
RC3/release: 696f4dc85f7faa8bc21e2e48302c6b680a5bb09e

Cheers,

-- 
Sybren A. Stüvel

https://stuvelfoto.nl/
https://stuvel.eu/



signature.asc
Description: OpenPGP digital signature
___
Bf-committers mailing list
Bf-committers@blender.org
https://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Revisions for 2.79 ReleaseCandidate 2

[Sybren A . Stüvel]

I'd like to add 01ee88563b64e8f381bbbe9f54894ad27541f050 too. It's just
a clarification in the documentation, but still it'll be nice to have in
2.79 release.

Sybren


On 17/08/17 16:21, Sergey Sharybin wrote:
> Hi,
>
> We started gathering crucial fixes for 2.79 release. At the end of this
> email you'll see revisions we agreed on to put into release branch.
>
> We will be AHOYing tomorrow midday, CEST time.
>
> Please note that this list is about Blender revisions, addons revisions has
> their own thread in this list:
> https://lists.blender.org/pipermail/bf-committers/2017-August/048619.html
>
> List of revisions:
>
> 8ff2c140155 Fix T52250: Glitch in UI in the addon panel regression
> f5f6f9c9ac3 Fix broken API doc generation: Partially revert rBa372638a76e0
> c8a8589d4f1 Fix T52263: Crash When Splitting and Merging Areas with Header
> Text Set.
> ed4707be470 Fix width estimation for empty layouts in pie menus
> 90b3dba5151 Fix T52255: New Depsgraph - Constraint and Drivers not working
> together when the driver references itself
> a78b5962727 Fix T52260: Blender 2.79 Objects made duplicates real still
> refer armature proxy.
> 4fe1bf85afa Fix fixed width box layouts
> f2728939df3 Fix T52280: The Image node in Compositing can't read Z buffer
> of openEXR in 2.79
> 8c488cb97f0 Fix T52315: Crash on duplicating Scene without world.
> 5b6ead05bd2 Fix T52324: Metaball disappears when deleting first metaball
> object.
> 33ab011ae49 Tweak and extend POV syntax hilghting.
> e786ea6419c Fix T52334: images with non-color data should not change color
> space on save.
> 017b7ee273d DPI: add back option to control line width, tweak default width.
> d5d626df236 Fix T52344: Softbody on Text.
> 59a52fef6ce Pie menu's sub-rows ignore 'EXPAND' flag
> 31be0a6e52e Fix T52344: Softbody on Text.
> b6fda7fa43d Fix T52327: Entering/Exiting NLA Tweakmode disables Scene ->
> Only Keyframes from Selected Channels
> 4a1762f7698 iFix T52050: Empty VSE preview for scene strips with OpenGL
> preview + Rendered settings.
> b5cd89bab96 Fix width estimation for buttons with short labels in pie menus
> 4e6324dd59c Cycles: Guard memcpy to potentially re-allocating memory with
> lock
> 86eb8980d36 Cycles: Fixed broken camera motion blur when motion was not set
> to center on frame
> 091ae0ea714 Math Lib: add isect_seg_seg_v2_point_ex
> a4bcdf5fb1a Fix T52329: Boolean with aligned shapes failed
> d1752167a9f Fix T52278: 'Default' application template fails
> 696599edacf CMake: test build configuration support
> b53e35c655d Fix compilation error when building without Blender
> 6e7e081e3ea install_deps: disable PTex in our OIIO building for now, broken
> on newest systems.
> de3c1657132 Forgot to change magicnumber of OIIO built lib in previous
> commit...
> b6d7cdd3cee Fix T51701: Alembic cache screws up mesh.
> ac88a3942e4 Alembic import: fix crash when face color index is out of
> bounds.
> f20d7bed142 Alembic import: report object name in face color index out of
> bounds error
> 3d677d91900 Fix OSX duplicate path in Python's sys.path
> cdfeebd1393 Alembic: Renamed variable assigned_name → assigned_mat
> 45d7513f84b Fix T52240: Alembic Not Transferring Materials Per Frame
> 8cfb9b95359 Fixed Alembic unit test
>
>

-- 
Sybren A. Stüvel

https://stuvelfoto.nl/
https://stuvel.eu/

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

Re: [Bf-committers] importing multipule alembic files in python. possible bug?

[Sybren A . Stüvel]

Note that this topic is now tracked at
https://developer.blender.org/T52274. Let's post any replies there and
keep things in one place.

Sybren


On 27/07/17 12:42, Levon wrote:
> Not sure if this is a bug, or im not using correctly, so thought ild email
> here before submitting a bug report
>
>
> Trying to import a number of alembic files using the following python code
>
> import os
>
> directory = *directory with alembic files*
> files = os.listdir(directory)
> print (files)
> for file in files:
> bpy.ops.wm.alembic_import(filepath= directory + file )
>
> With files = ['alem1.abc', 'alem2.abc', 'alem3.abc', 'alem4.abc']
> each alembic file is just a duplicated Cube at a different location, and
> with a different name ( Cube.001, Cube.002 etc)
>
> What I get is only alem1.abc and alem4.abc being imported, however the
> console prints {'FINISHED'} for each file, 4 times.
>
>
> When i try the same script on a list of 30 larger alembic files, similarly,
> only the first and last files are imported.
>
> what I suspect is happening, the alembic importer doesn't block the blender
> interface, and trying to run the operator concurrently doesn't import the
> files
>
> Is there a better way of doing this? or is it a bug?
>
> Tested in blender Buildbot july 27th 5c963128ea2
>
> Thanks.
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> https://lists.blender.org/mailman/listinfo/bf-committers

-- 
Sybren A. Stüvel

https://stuvelfoto.nl/
https://stuvel.eu/

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

Re: [Bf-committers] importing multipule alembic files in python. possible bug?

[Sybren A . Stüvel]

Hi Levon,

Try passing as_background_job=False to the operator call. That'll import
the files sequentially, which should solve your issue.

Sybren


On 27/07/17 12:42, Levon wrote:
> Not sure if this is a bug, or im not using correctly, so thought ild email
> here before submitting a bug report
>
>
> Trying to import a number of alembic files using the following python code
>
> import os
>
> directory = *directory with alembic files*
> files = os.listdir(directory)
> print (files)
> for file in files:
> bpy.ops.wm.alembic_import(filepath= directory + file )
>
> With files = ['alem1.abc', 'alem2.abc', 'alem3.abc', 'alem4.abc']
> each alembic file is just a duplicated Cube at a different location, and
> with a different name ( Cube.001, Cube.002 etc)
>
> What I get is only alem1.abc and alem4.abc being imported, however the
> console prints {'FINISHED'} for each file, 4 times.
>
>
> When i try the same script on a list of 30 larger alembic files, similarly,
> only the first and last files are imported.
>
> what I suspect is happening, the alembic importer doesn't block the blender
> interface, and trying to run the operator concurrently doesn't import the
> files
>
> Is there a better way of doing this? or is it a bug?
>
> Tested in blender Buildbot july 27th 5c963128ea2
>
> Thanks.
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> https://lists.blender.org/mailman/listinfo/bf-committers

-- 
Sybren A. Stüvel

https://stuvelfoto.nl/
https://stuvel.eu/



signature.asc
Description: OpenPGP digital signature
___
Bf-committers mailing list
Bf-committers@blender.org
https://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Please merge your master work in blender2.8 immediately

[Sybren A . Stüvel]

Hi Gaia,

On 05/07/17 11:35, Gaia Clary wrote:
> I followed advise from IRC and documentation from git and i ended up 
> doing this:
>
> git checkout master
> git fetch
> git pull --rebase

git pull also does a fetch, so the first fetch isn't necessary, unless
you want to see what the pull is going to do before actually pulling.

> git checkout blender2.8
> git merge master

After merging you also have to commit, otherwise you'll loose your merge.

Of course after this don't forget to test & push.

> Then i tried again to merge master into blender2.8
> However all my recent changes in master still do not
> show up in blender2.8 regardless what i try.

You can use 'gitk' or 'git log --graph' to see what merge commit was
created.

Cheers,

-- 
Sybren A. Stüvel

https://stuvelfoto.nl/
https://stuvel.eu/




signature.asc
Description: OpenPGP digital signature
___
Bf-committers mailing list
Bf-committers@blender.org
https://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Newcomer

[Sybren A . Stüvel]

Hi Sarthak,

Welcome to this list :) A good place to start reading is 
https://wiki.blender.org/index.php/Dev:Contents, especially the column 
titled "Getting Started" contains heaps of useful info. Once you've read 
that and you still have more specific questions, don't hesitate to ask here.

Cheers,

Sybren


On 2017-07-02 11:22, Sarthak Gupta wrote:
> Hi all,
> I am Sarthak from India. I am currently doing B.E in Information
> Technology. I have just completed my first year in my college and know
> languages C, HTML, CSS, JS. The purpose of this mail is that I am just to
> getting started with open source, and I want little guidance to get started
> and start contributing with this amazing community.
> I chose this community because the idea of animation, simulation etc quite
> fascinated me and I think I will have an enjoyable experience with this
> community.
>
> As already mentioned, I am just getting started with open source because I
> heard from my seniors that open-source is a great way to grow and learn.
> Please guide me a little.
>
> Thanks :)
> Sarthak Gupta
> ___
> 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] Flamenco rendering in the cloud

[Sybren A . Stüvel]

Hi Philip.,

On Tue, Jun 27, 2017 at 05:40:57PM +0200, Philipp Hemmer wrote:
> I hope this is the right mailinglist. I haven't found one for
> flamenco itself. If it isn't please direct me to the correct list.

There is no mailing list for Flamenco. You can mail us directly at
cloudsupp...@blender.org if you want to discuss things with Francesco
and me, or come to IRC (#flamenco on Freenode).

> I would like to help to integrate AWS and other cloud services. This
> way it would be easy for a artist/studio to scale the rendering when
> needed. It should be as "easy" to create and configure worker
> instances in the cloud. Or did i get something wrong?

Currently Flamenco only supports render nodes that have direct access
to filesystem that is shared with your workstation. In other words,
Blender should be able to save to a place where the nodes can read the
files.

We have some ideas on how to extend this to render nodes at Google
Cloud or AWS nodes. If you want to help implementing such features,
that would be great. 

Cheers,
-- 
Sybren A. Stüvel

https://cloud.blender.org/
https://stuvelfoto.nl/
https://stuvel.eu/


signature.asc
Description: PGP signature
___
Bf-committers mailing list
Bf-committers@blender.org
https://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Compile from source

[Sybren A . Stüvel]

Hi Steve,

Sorry for the long wait. I don't know much about Open Shading Language
(OSL), that's why I haven't replied earlier. One way to work around
this is to simply disable OSL in your build (edit CMakeCache.txt).

Cheers,
Sybren

On Sat, May 13, 2017 at 04:53:43PM +0100, Post wrote:
> Dear Blender,
> 
> I am attempting to compile Blender from source using instructions posted 
> on 'Dev:Doc/Building Blender/Linux/Generic Distro/CMake'. I was/am 
> hoping to establish a dedicated console for running  and testing 
> Mechanical Blender even though, as I understand it, it is in a 
> pre-release stage. I have a full Blender package, which is fantastic, on 
> another system and want to try Mechanical as well.
> 
> Following instructions for this procedure as publish all was proceeding 
> well until I had a repeated glitch compiling the 'Open-Shading-language'.
> 
> Copied from terminal:
> 
> [ 71%] Building CXX object 
> src/liboslexec/CMakeFiles/oslexec.dir/llvm_instance.cpp.o
> In file included from /usr/include/c++/4.9/vector:64:0,
>   from /usr/include/boost/detail/container_fwd.hpp:93,
>   from /usr/include/boost/functional/hash/extensions.hpp:17,
>   from /usr/include/boost/functional/hash/hash.hpp:540,
>   from /usr/include/boost/functional/hash.hpp:6,
>   from /usr/include/boost/unordered/unordered_map.hpp:20,
>   from /usr/include/boost/unordered_map.hpp:16,
>   from 
> /home/skt/src/blender-deps/OpenShadingLanguage-1.7.5/src/liboslexec/llvm_instance.cpp:31:
> /usr/include/c++/4.9/bits/stl_vector.h: In instantiation of 'void 
> std::vector<_Tp, _Alloc>::_M_initialize_dispatch(_Integer, _Integer, 
> std::__true_type) [with _Integer = int; _Tp = llvm::Function*; _Alloc = 
> std::allocator<llvm::Function*>]':
> /usr/include/c++/4.9/bits/stl_vector.h:413:55:   required from 
> 'std::vector<_Tp, _Alloc>::vector(_InputIterator, _InputIterator, const 
> allocator_type&) [with _InputIterator = int; _Tp = llvm::Function*; 
> _Alloc = std::allocator<llvm::Function*>; std::vector<_Tp, 
> _Alloc>::allocator_type = std::allocator<llvm::Function*>]'
> /home/skt/src/blender-deps/OpenShadingLanguage-1.7.5/src/liboslexec/llvm_instance.cpp:1043:54:
>  
> required from here
> /usr/include/c++/4.9/bits/stl_vector.h:1252:59: error: invalid 
> conversion from 'int' to 'std::vector<llvm::Function*>::value_type {aka 
> llvm::Function*}' [-fpermissive]
>  _M_fill_initialize(static_cast(__n), __value);
> ^
> /usr/include/c++/4.9/bits/stl_vector.h:1298:7: note: initializing 
> argument 2 of 'void std::vector<_Tp, 
> _Alloc>::_M_fill_initialize(std::vector<_Tp, _Alloc>::size_type, const 
> value_type&) [with _Tp = llvm::Function*; _Alloc = 
> std::allocator<llvm::Function*>; std::vector<_Tp, _Alloc>::size_type = 
> unsigned int; std::vector<_Tp, _Alloc>::value_type = llvm::Function*]'
> _M_fill_initialize(size_type __n, const value_type& __value)
> ^
> src/liboslexec/CMakeFiles/oslexec.dir/build.make:800: recipe for target 
> 'src/liboslexec/CMakeFiles/oslexec.dir/llvm_instance.cpp.o' failed
> make[2]: *** [src/liboslexec/CMakeFiles/oslexec.dir/llvm_instance.cpp.o] 
> Error 1
> CMakeFiles/Makefile2:210: recipe for target 
> 'src/liboslexec/CMakeFiles/oslexec.dir/all' failed
> make[1]: *** [src/liboslexec/CMakeFiles/oslexec.dir/all] Error 2
> Makefile:137: recipe for target 'all' failed
> make: *** [all] Error 2
> ERROR! OpenShadingLanguage-1.7.5 failed to compile, exiting
> 
> 
> 
> This issue may be entirely due to an inadequate operating system, not 
> the most powerfull rig in the world nor a particularly good graphics 
> card. Operating system MX16 out of Antix out of Debian.
> Although, I can and have had Blender running on it quite happily.
> 
> Wondering if there is anything to be done other than report and if I 
> reload Blender from synaptic will I be able to re-compile it as 
> Mechanical in some way?
> 
> Many thanks
> 
> Steve
> 
> 
> 
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> https://lists.blender.org/mailman/listinfo/bf-committers

-- 
Sybren A. Stüvel

https://cloud.blender.org/
https://stuvelfoto.nl/
https://stuvel.eu/


signature.asc
Description: PGP signature
___
Bf-committers mailing list
Bf-committers@blender.org
https://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Weekly Blender developer meeting notes - 2017-05-21

[Sybren A . Stüvel]

On Mon, May 22, 2017 at 11:39:26AM +0200, Sergey Sharybin wrote:
> We are going to the latest stable version of 3.5.x series, which is
> 3.5.3.
> 
> We do NOT go 3.6.x for 2.79 release.

Yeah, that's what I figured, but Ton's mail got me confused ;-)

-- 
Sybren A. Stüvel

https://cloud.blender.org/
https://stuvelfoto.nl/
https://stuvel.eu/


signature.asc
Description: PGP signature
___
Bf-committers mailing list
Bf-committers@blender.org
https://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Weekly Blender developer meeting notes - 2017-05-21

[Sybren A . Stüvel]

On Sun, May 21, 2017 at 05:57:18PM +0200, Ton Roosendaal wrote:
> - Python library in Blender is getting updated to latest stable version.

The latest stable version is 3.6.1 -- is it correct that we're going
to 3.6 for 2.79?

-- 
Sybren A. Stüvel

https://cloud.blender.org/
https://stuvelfoto.nl/
https://stuvel.eu/


signature.asc
Description: PGP signature
___
Bf-committers mailing list
Bf-committers@blender.org
https://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Library update: include Alembic bin dir

[Sybren A . Stüvel]

Thanks.

On Sat, May 06, 2017 at 10:48:18PM +0200, Brecht Van Lommel wrote:
> macOS 10.9 libs updated now to include the Alembic binaries.
> 
> On Fri, Apr 28, 2017 at 12:13 PM, Sybren A. Stüvel <syb...@stuvel.eu> wrote:
> > Hello all,
> >
> > For the Alembic exporter unit tests I use the 'abcls' binary from
> > Alembic itself. All platform maintainers, please update the Alembic
> > directory in SVN so that it also includes Alembic's "bin" directory.
> >
> > LazyDodo has already done this for the Windows libs.
> >
> > I sincerely hope that this is a temporary thing; I'm not too happy
> > parsing the output of an external binary. Unfortunately, the Alembic
> > Python bindings are still only available for Python 2.x, and testing
> > from C is also not an option (since each test would be as big as a
> > full Blender debug build).
> >
> > Cheers,
> > --
> > Sybren A. Stüvel
> >
> > https://cloud.blender.org/
> > https://stuvelfoto.nl/
> > https://stuvel.eu/
> >
> > ___
> > 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

-- 
Sybren A. Stüvel

https://cloud.blender.org/
https://stuvelfoto.nl/
https://stuvel.eu/


signature.asc
Description: PGP signature
___
Bf-committers mailing list
Bf-committers@blender.org
https://lists.blender.org/mailman/listinfo/bf-committers

[Bf-committers] Library update: include Alembic bin dir

[Sybren A . Stüvel]

Hello all,

For the Alembic exporter unit tests I use the 'abcls' binary from
Alembic itself. All platform maintainers, please update the Alembic
directory in SVN so that it also includes Alembic's "bin" directory.

LazyDodo has already done this for the Windows libs.

I sincerely hope that this is a temporary thing; I'm not too happy
parsing the output of an external binary. Unfortunately, the Alembic
Python bindings are still only available for Python 2.x, and testing
from C is also not an option (since each test would be as big as a
full Blender debug build).

Cheers,
-- 
Sybren A. Stüvel

https://cloud.blender.org/
https://stuvelfoto.nl/
https://stuvel.eu/


signature.asc
Description: PGP signature
___
Bf-committers mailing list
Bf-committers@blender.org
https://lists.blender.org/mailman/listinfo/bf-committers