Today the Blender manual and its translations migrated from Subversion to
Git.
See the blog post for more information:
https://code.blender.org/2023/05/sunsetting-subversion/
See the new contributing instructions here:
https://docs.blender.org/manual/en/dev/contribute/index.html
On Linux and
Hi all,
The new projects.blender.org is now online. See this blog post for
important information on how to switch over:
https://code.blender.org/2023/02/new-blender-development-infrastructure/
For developers and module members, please read the following topic
carefully. Here we will also gather
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
If you're creating proprietary software that you're going to distribute to
others, then as a general rule you can not include GPL code in that.
There's various details and debate around when exactly this applies, but
the case you give seems quite clear-cut.
Note that the Cycles code is Apache
There is not going to be an OpenGL fallback once Metal is stable. Eevee
next and the viewport compositor will require Metal, it's not just about
performance.
On Thu, Jan 5, 2023 at 5:18 PM Chuck Ocheret via Bf-committers <
bf-committers@blender.org> wrote:
> It seems to me that supporting Metal
> towards option a.
>
> --Ray
>
>
>
> On 2023-01-05 8:26 a.m., Brecht Van Lommel via Bf-committers wrote:
> > I think it's reasonable to do the bump now, instead of 3 months from now
> > when we definitely have to do it. And doing it together with the VFX
> >
I think it's reasonable to do the bump now, instead of 3 months from now
when we definitely have to do it. And doing it together with the VFX
platform updates and new Linux minimum requirements makes some sense.
It's always unfortunate to leave behind hardware, but even macOS 10.15 is
already EOL
Hi all,
Blender 3.5 will have new minimum required versions for Linux
distributions, following the VFX platform 2023. See here for details:
https://wiki.blender.org/wiki/Reference/Release_Notes/3.5#Compatibility
https://developer.blender.org/T102440
The buildbot infrastructure changes are
This is normal, many DNA changes are automatically handled and do not
require the file version to be changed..
On Sat, Jul 9, 2022 at 9:49 PM Holger Machens via Bf-committers
wrote:
>
> Hey guys,
>
>
>
> not sure if that was intended, but the DNA file version didn't change
> with the 3.2.1
There are definite trade-offs, but a few things:
* Linux distribution packages are not expected to follow the VFX platform.
They have always deviated in the library versions compared to our own
builds, including the Python version.
* Upgrading to the latest Python version is not the only way to
For reference there is more discussion about this in the two tasks:
2021: https://developer.blender.org/T83246
2020: https://developer.blender.org/T68774
My preference is still to track the full VFX platform, including the Python
version. However I know I'm in the minority on this, and I'm not
You appear to still be a member of the Documentation and Translations
projects, which gives you commit rights to those subversion repositories.
The credentials for subversion are your developer.blender.org username and
password. If you forgot your developer.blender.org password you should be
able
sed.
>
>
> Still investigating how to add launchers correctly to Steam on BETA
> branches.
> Not really obvious and I can easily mess up all the other branches
> and the current live default app if not careful.
> I can work on this once Ray is happy with it.
>
> Thanks !
&
Maybe we can think of better names for Steam? "autotest" and "vdev" are not
terminology for users. I would try to match the buildbot:
* Daily Build - Alpha
* Daily Build - 2.93 LTS - Candidate
* Daily Build - 2.83 LTS - Candidate
I'm also not sure what that launcher option is for? If it's for
No, there are no such plans.
On Thu, Jun 24, 2021 at 8:47 AM Ryan Inch via Bf-committers <
bf-committers@blender.org> wrote:
> @ The core developers considering this repository idea.
> With this new online add-on repository you are proposing, you have
> talked about unifying add-on distribution,
On Sat, Jun 19, 2021 at 8:13 AM Ryan Inch via Bf-committers <
bf-committers@blender.org> wrote:
> If the bundled add-ons were moved out of Blender and into an online
> repository each user would have to explicitly search for and download
> them instead of having them ready to be used out of the
There are certainly challenges implementing such a system, though it's been
done many times in other applications. It's too early to go into such
details, it's not clear this will even happen or when.
On Thu, Jun 17, 2021 at 10:14 PM Dan McGrath
wrote:
> Hi,
>
> For an official online
-----
> > Dalai Felinto -da...@blender.org -www.blender.org
> > Blender Development Coordinator
> > Buikslotermeerplein 161, 1025 ET Amsterdam, the Netherlands
> >
> >
> > Op vr 11 jun. 2021 om 15:11 schreef Brecht Van Lommel via Bf
not where I see things going long
term.
On Fri, Jun 11, 2021 at 3:11 PM Brecht Van Lommel
wrote:
> Personally, I wouldn't change this.
>
> Add-ons authors are credited in the add-on preferences, where you go to
> enable the add-on. The fact that they are bundled rather than inst
Personally, I wouldn't change this.
Add-ons authors are credited in the add-on preferences, where you go to
enable the add-on. The fact that they are bundled rather than installed
from an online repository (which is what we should do eventually) makes
little practical difference I think.
For the
A big reason for choosing Phabricator at the time was because it was
designed for larger projects. That means being able to organize tasks and
code reviews into projects and subprojects, even if they all apply to the
same code repository. Moving tasks between projects, assigning tasks to
multiple
Hi,
There is a draft for the next VFX reference platform up now. Since we had
some issues with the last one, it would be good to give feedback if
necessary.
https://vfxplatform.com/
https://groups.google.com/g/vfx-platform-discuss/c/bnyJ2X1SwAw/m/bA_hW2MpBQAJ
Python was upgraded to 3.9, which
Hi,
For help with add-on development, devtalk.blender.org is the better place
to ask for help. I see you already opened a discussion topic there.
https://devtalk.blender.org/t/about-drag-and-drop-textures/16819
Regards,
Brecht.
On Wed, Dec 30, 2020, 04:31 Adult Engineering via Bf-committers <
nup was automated the commit should not be added. ie a commit
> > "Cleanup: clang-tidy some-check" could still very much be a manual
> > cleanup of the warns exposed by clang-tidy and suspect to unintentional
> > functional changes.
> >
> > --Ray
> >
&g
Hi Ankit,
Please go through code review for all commits, unless you are a module
owner or admin that is the policy.
Note that there are guidelines in the file itself. We could document it in
the wiki too, but I'm not sure it's needed. Perhaps the wording can be
clarified? Suggestions are
There are two parts to this. I think upgrading to the 2021 reference
platform as proposed in the task is an easy decision. There are no real
downsides that I know of. We might as well keep up with recent versions of
libraries like OpenVDB, OpenColorIO and OpenEXR, the new versions provide
real
n.
> >
> > So while I'm still not so keen to depend on unmaintained code.
> > +1 to include this as an optional library.
> >
> > [0] https://build.opensuse.org/package/show/openSUSE:Factory/libharu
> > [1] https://packages.debian.org/stable/source/libharu
> >
> > On T
I think we should only use extern/ if the alternative is not possible for
some reason, and I'm not aware of any. So following that libharu would go
to the svn libraries.
Personally I don't really see a significant advantage in bundling it as a
separate executable. It helps in some ways, but then
I'm not sure there exists a simple utility to convert SVG to PDF that we
could include, if we want to go that way?
Inkscape uses Cairo for PDF writing, that could be a more actively
maintained alternative.
https://www.cairographics.org/
It has also been proposed to be added to handle Wayland
On Tue, Nov 17, 2020 at 2:40 PM Sybren A. Stüvel via Bf-committers <
bf-committers@blender.org> wrote:
> I'm assuming you mean D9577 with "this specific case", as that's where
> this discussion started before I moved it to this list, and that
> you're talking about a problem that 32-bit Linux
Developers are already welcome to document their features in the manual, I
don't think this is any different?
You do have to be aware that the manual tracks the release branch while it
exists, not master.
Moving the manual to git and using branching would make that easier,
there's a task for
wrote:
> On Mon, 16 Nov 2020 at 17:58, Brecht Van Lommel via Bf-committers
> wrote:
> > The difference is between:
> > * Providing active support for a processor architecture
> > * Rejecting or fixing code that only builds on a specific processor
> > architecture
>
I can see how this would solve a real problem and improves usability when
exporting assets to Godot.
Note that USD explicitly chose not to use UUIDs. But I can see how this
makes more sense for simpler pipleines that don't follow more strict naming
conventions or fix up names afterwards.
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
ANARI was brought up in the latest rendering meeting. Blender is not
actively involved in it.
https://devtalk.blender.org/t/2020-11-3-blender-rendering-meeting/16020
ANARAI is not designed to do what you describe though. It is a rendering
API, that would sit between a tool like Blender or
be to add 'edges' that is vertex to vertex connections that
> do not modify the surface but represent physical interaction.
>
>
>
> On 02.11.20 19:07, Brecht Van Lommel via Bf-committers wrote:
> > The paper shows how to make SDF collision more accurate by using the SDF
> > dire
The paper shows how to make SDF collision more accurate by using the SDF
directly rather than sampling it. We have triangle mesh based collision in
Blender, which in a state-of-the-art implementation would avoid those
problems already.
The point of switching to SDFs would be performance, at the
The most important thing for cloth is that you can get it to give good
results in real world cases, and the cloth simulation changes were based on
work done for Agent 327.
https://www.youtube.com/watch?v=jU6-cI-z8HA
In practice you use smaller time steps and the fast-moving cube will get
collided
It's not clear to me that being triangle based only is a good thing about
dynamic topology. It would be better if it preserved ngons and only
triangulated parts of the mesh where actual changes are being made. And
also did not lose vertex colors and UV maps.
Maybe it's possible to use MVert and
Hi everyone,
This week we are doing another bug sprint, which will now be a regular part
of the release cycle. For more details, see the blog post:
https://code.blender.org/2020/07/bug-sprints/
Developers working for the Blender Institute will work the entire week of
July 13 to 17 exclusively on
Details about planned version numbers are here:
https://code.blender.org/2020/05/long-term-support-pilot/
https://code.blender.org/2020/02/release-planning-2020-2025/
On Thu, Jun 11, 2020 at 7:34 PM Chad Fraleigh via Bf-committers
wrote:
>
> Is the semantic versioning style migration (e.g. 3.x
Hi Recep,
Thanks for the overview, AssetKit being a small well-written library
is good. However there would be a significant amount of work involved
in integrating it in Blender. Not just in getting the implementation
to work, but also in refining both AssetKit itself and the Blender
integration
The release notes about Optix denoising are here.
https://wiki.blender.org/wiki/Reference/Release_Notes/2.82/Cycles#Denoising
https://wiki.blender.org/wiki/Reference/Release_Notes/2.83/Cycles#OptiX_Viewport_Denoising
Note there are specific requirements for graphics cards, driver versions,
and
Blender supports matcaps and cavity for visualizing fine details when
sculpting, which is a pretty similar use case.
So I would recommend trying those and checking how the feature you propose
to add are different or how they might be integrated.
On Thu, Mar 12, 2020 at 1:14 PM Lorenzo Lastilla
There is documentation on BMesh here:
https://wiki.blender.org/wiki/Source/Modeling/BMesh/Design
In a nutshell, a mesh representation like BMesh with more connectivity
information is much easier to to write modelling tools for. On the other
hand it's less memory efficient, so we mainly use it for
There's a few possible solutions:
* Enable WITH_CYCLES_NATIVE_ONLY and disable
WITH_LIBMV_SCHUR_SPECIALIZATIONS
* If it's running out of memory building a particular module, you can
disable that module in CMake (e.g. WITH_MOD_FLUID, ...). It would be
interesting to know which one.
* As a last
glTF notes were moved to the Import & Export page, there's definitely
nothing wrong with the content.
It's enabled by default and belongs at the same level as Alembic and USD as
a core part of Blender.
On Wed, Feb 19, 2020 at 9:52 PM Julien Duroure
wrote:
> Hello,
>
> I have 2
ariable in platform_win32.cmake
> temporarily back to 1_68. Sorry about that...
>
> Brecht, mind taking it from here ?
>
> Greetings
> -Ray
>
>
> On 2020-01-20 4:59 a.m., Brecht Van Lommel wrote:
> > Hi platform maintainers,
> >
> > The library version
Hi platform maintainers,
The library versions for OpenEXR, OpenVDB, Blosc and Boost have been
upgraded. Please rebuild precompiled libraries for your platforms. We want
to include these in 2.82 still. Due to dependencies, all these libraries
must be rebuilt:
OpenEXR
OpenImageIO
OSL
OpenVDB
Blosc
Hi all,
I've updated the workboard for the 2.82 release, so we can get an overview
of what remains to be done.
https://developer.blender.org/project/board/89/
Bug triagers and other developers, please mark any important regressions or
critical bugs with the 2.82 milestone. There are only a few
On Mon, Nov 11, 2019 at 6:29 PM Dalai Felinto wrote:
> * Tomorrow 12/11 would be nice to have a final call on whether there are
> any show stoppers.
>
> * If someone knows of known regressions/big issues that we won't fix in
> time, please tag it as 2.81 or contact Dalai Felinto or Nathan
The buildbot can probably be fixed by updating the lib folder name in
build_files/utils/make_update.py.
On Fri, Nov 8, 2019 at 5:16 PM Ray Molenkamp wrote:
> So... that broke the windows build bot, if anyone with access
> to the windows bot could check out the libs that be great!
>
> --Ray
>
>
The main downside would be deviating from the VFX reference platform:
https://developer.blender.org/T68774
But using a year old Python version has downsides too, so either choice
seems reasonable.
On Sun, Nov 3, 2019 at 9:52 AM dr. Sybren A. Stüvel
wrote:
> On 03/11/2019 03:19, Campbell Barton
There were 2 mailing list topics about it, and it was mentioned in meeting
notes 5 times. The wiki page explains it in detail, there was a
code.blender.org blog post and developer.blender.org front page links to
information about it.
I also find it worrying that some active devs were unaware of
* Announcement email sent
* source/tools now has blender-v2.81-release
* Autoclose on release branch hopefully fixed, but it might not
retroactively close tasks that were fixed already.
We accidentally had a merge of master into the release branch. I reverted
that now, but we should add code on
Hey all,
We have now entered the next phase of the release cycle.
For more details on how the new overlapping release cycles work, see here:
https://wiki.blender.org/wiki/Process/Release_Cycle
In short, Blender 2.81 now continues in the blender-v2.81-release branch,
for bug fixing only. Blender
We could consider adding a new splash at the start of the release cycle,
instead of at the end. It makes some sense for a specific Blender version
to always have the same splash.
On Fri, Oct 11, 2019 at 5:29 PM Dalai Felinto wrote:
> Hi Antonio,
>
> What you propose is not really solving the
I would consider sharing assets without a .json file to be part of the MVP.
We have to get the storage right from the start, changing it after is
difficult.
There can be a manual "Refresh" button if needed, but I think it's
important that any information outside the .blend file is only a cache
Hi all,
Some changes have been made to developer.blender.org.
## arc patch
For code review, "arc patch" will now automatically set the appropriate
author for all differentials, and exclude unnecessary fields.
Note that you still need to inspect the code changes, commit message and
run
for consistency.
Performance improvements for sculpt mesh drawing, to skip parts of the mesh
outside the viewport and better use multiple CPU cores when editing many
vertices. (Brecht Van Lommel)
Projects Under Development
=
* Ray Molenkamp experimented with using the TBB allocator
Realistically, we can't guarantee the entire API to be stable. Any
change to operators, user interface, modifiers, nodes or settings can
affect add-ons. Not being able to make these types of changes would
severely restrict which end user features can go in 2.81, that
wouldn't work.
For example,
See here:
https://wiki.blender.org/wiki/Reference/Release_Notes/2.81/Eevee
On Fri, Aug 16, 2019 at 9:29 PM Adriano Oliveira wrote:
>
> Hi developers,
>
> Any reason way Eevee transparency blend modes ADD and MULTIPLY were removed
> in 2.81?
> From my point of view, they are very important.
>
>
in Blender.
> The design module was represented by William and Brecht.
>
> Participants: Brecht Van Lommel, Dalai Felinto, William Reynish
> August 13th, 2019
>
> A lot of the points here apply to the other modules as well. But since
> the design module spread throughout all Bl
McGrath wrote:
>
> Hi,
>
> On Mon, Aug 12, 2019 at 8:00 AM 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 ca
On Tue, Aug 6, 2019 at 12:37 PM dr. Sybren A. Stüvel wrote:
> 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
On Mon, Aug 12, 2019 at 1:37 PM Dalai Felinto wrote:
> Bug report wizard
> ==
> * Find a balance between users using Help > Report a bug from Blender,
> and have them filling all the required information
> * Proposal is to have a wizard-like report system where users only
> type one
SCHEDULE
This is missing a cut-off date for major new features or risky
changes, which should more than one month before the release date.
There is no way we can for example merge Mantaflow at the end of
September and then release a month later. This is important
information for developers
Hi everyone,
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
We recommended developers to use this. Tools like address sanitizer
help you to catch bugs while
Hi all,
Blender 2.80 was the last release where we officially support 32 bit
Windows and Linux builds. For Blender 2.81 there will be only 64 bit
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
editor
> 34ad6da4a06ef46cd19945f61cc5f968538546a8 Fix T67450: Crash undoing
> edit-mode lattice resolution
> 4fe0fafb875581e4a116db17da6a032fd1749f65 Fix T67548: Camera
> background-image ignores shift
> 453586be06a129eec7498fe7ecac9f7c555e34e6 Fix T67849: Offset after
> "Ho
Hi all,
We are ready for the final release build for Blender 2.80.
Information for platform maintainers:
- Build from the blender-v2.80-release branch, SHA
f6cb5f54494e40f0d217c7a1520a14896bd19120
- Addons revision: 4410bd0a9f82aba3422e737f0fae4a916cf6c0c1
- Locale revision:
BlenderKit: fix search ordering - was accidentaly upside down.
cc1f86f Update Online Manual Links
6027fe0 Addon: Discombobulator: Fixed Doodads Menu section broken
fb464b0 Addon: BSurfaces: Fixed select active Annotation
On Mon, Jul 29, 2019 at 11:19 AM Brecht Van Lommel
wrote:
>
>
Something went wrong with the formatting of this mail, it's best to
use plain text when sending to mailing lists.
5fdd75d68328 BlenderKit: fix T67565, unregistration could go wrong in combo
ba7e0de9774f magic_uv: fix load reload failure: T67572
Bugs with add-on unregistration I don't consider
Hi all,
Here are the notes from today's developer meeting. Next meeting is
Monday, 5 August 18:00 CEST / 16:00 UTC, in #blender-coders on
blender.chat.
1) Development
* Blender 2.80 is now planned to be released tomorrow on July 30, we
aim to add the last commits and make the builds today. See
Hi all,
Please reply here with commits that should be ported over to the
release branch for 2.80. We plan to cherry-pick the commits at 16:00
CEST today and then make the builds. This is the current list, but I
haven't gone through the logs yet in detail.
Blender:
none
Addons:
92830c7
I'd like to review and finish various Cycles patches, listed on the
module page here. The ones I've marked as most important are UDIM,
OpenImageDenoise and procedural texture summer of code. I'm quite
confident these could be in 2.81, since they're not that far from
finished. Hopefully we can get
Hi all,
We are ready for the third Release Candidate for the Blender 2.80 release.
Information for platform maintainers:
- Build from the blender-v2.80-release branch, SHA
507ffee6e1f4a2b2795c7c93cd3f37f4df748ee9
- Addons revision: f3ee44380d01ab69b2b007409e7d6a9ec143beb2
- Locale revision:
All these commits are in the blender-v2.80-release branch now.
One more was added:
02c5c09 Bevel modifier: let it work on wire edges when vertex_only.
On Wed, Jul 24, 2019 at 1:05 PM Brecht Van Lommel
wrote:
>
> Hi everyone,
>
> Due to a critical bug in 2.80 RC2 that was cau
Hi everyone,
Due to a critical bug in 2.80 RC2 that was causing crashes in
sculpting and texture paint, we are going to do another release
candidate. We intend RC3 to be identical to the final release, which
would then be targetted for Tuesday next week.
We intended to do an ahoy for the RC3
Hi all,
Here are the notes from today's developer meeting. Next meeting is
Monday, 29 July 10:00 CEST / 8:00 UTC, in #blender-coders on
blender.chat.
1) Development
The Blender 2.80 release is planned for this week, assuming no
unexpected surprises. On Wednesday we'll decide which bug fixes to
at 5:04 PM Brecht Van Lommel
wrote:
>
> To be clear, there is no virus in the Blender release folder. The
> checksums for the release builds match what the was reported by those
> who made the releases.
>
> What happened is that someone put something on the public Blender ftp
>
d over
> non secure (HTTPS) means directly from us, let alone files that have been
> altered from an infection.
>
>
> Cheers,
>
> Dan
>
> On Fri, Jul 19, 2019 at 10:06 AM Brecht Van Lommel <
> brechtvanlom...@gmail.com> wrote:
>
> > Hey all,
> >
> > Re
, 2019 at 6:40 PM Brecht Van Lommel
wrote:
>
> Hey all,
>
> We're planning to do the ahoy for the release candidate 2 tomorrow
> July 18, around 16:00 CEST.
>
> That's when all the critical fixes should be in, let me know if
> there's something that's not going to mak
Hi all,
We are ready for the second Release Candidate for the Blender 2.80 release.
Information for platform maintainers:
- Build from the blender-v2.80-release branch, SHA
38d4483c6a51d70744d5e146dc87f5da8558448d
- Addons revision: 979298511916b25ec97bb22feb1c06cc9fbc86dd
- Locale revision:
Hey all,
We're planning to do the ahoy for the release candidate 2 tomorrow
July 18, around 16:00 CEST.
That's when all the critical fixes should be in, let me know if
there's something that's not going to make it in time.
Thanks,
Brecht.
On Thu, Jul 11, 2019 at 7:37 PM Brecht Van Lommel
Hi all,
Here are the notes from today's developer meeting. Next meeting is
Monday, 22 July 18:00 CEST / 16:00 UTC, in #blender-coders on
blender.chat.
1) Development
* The release candidate was released last week.
https://www.blender.org/download/
https://www.blender.org/download/releases/2-80/
t 10 days, so I hope any dev can merge the diff
> before the release date.
>
> Thanks :)
>
> Julien
>
>
> On Thu, Jul 11, 2019 at 7:38 PM Brecht Van Lommel
> wrote:
>
> > Hey everyone,
> >
> > We had some additional issues to solve. The release ca
Hey everyone,
We had some additional issues to solve. The release candidate builds
are ready now, but we'll wait until tomorrow (July 12) to make them
available and update blender.org.
Thanks,
Brecht.
On Wed, Jul 10, 2019 at 5:22 PM Brecht Van Lommel
wrote:
>
> Hi everyone,
>
> We
Hi everyone,
We have entered the 2.80 release candidate phase now. That means
master will be mostly frozen, only important bugfixes should go in.
Please ensure commits are reviewed by another developer, and don't
make risky changes.
Sergey will do the branching & tagging, after which platform
I think the main issue recently was that for the first half of the 2.8
project, many changes were made without well-defined use cases and
design, and much code was left incomplete or broken. This left the
second half of the project with the difficult task of solving much
technical debt, with
pping with BVH seems to be efficient, but currently it calls the
> `dist_squared_to_projected_aabb` function which is heavy because it projects
> the edge of each node tested.
>
> For snapping with BVH, the ideal would be to use a spherical bvh which is
> currently not supported on Blend
There was earlier discussion on this here.
https://developer.blender.org/D2795
My understanding is that the old code would remain for faces. So if
this does not completely replace the snapping BVH, how does this
reduce memory usage or simplify the code? Wouldn't it do the opposite?
What about
for the release, where
there will be a single Blender.app to install, that is code signed and
notarized. (Arto Kitula, Brecht Van Lommel)
3) Weekly Reports
* Bastien:
https://wiki.blender.org/wiki/User:Mont29/Foundation/2019#Week_301_-_06.2F15_to_06.2F21
* Brecht: https://wiki.blender.org/wiki/User:Brecht
Hi all,
Here are the notes from today's developer meeting. Next meeting is
Monday, 24 June 18:00 CEST / 10:00 UTC, in #blender-coders on
blender.chat.
1) Development
* We will aim for a 2.80 release candidate around July 11, 3 weeks
from now. After the release candidate only important bug fixes
use Eevee for LookDev
shading. (Brecht Van Lommel)
3) Weekly Reports
* Bastien:
https://wiki.blender.org/wiki/User:Mont29/Foundation/2019#Week_299_-_06.2F01_to_06.2F07
* Brecht: https://wiki.blender.org/wiki/User:Brecht/Reports/2019#June_3_-_7
* Campbell:
https://download.blender.org/ftp/ideasm
Hi all,
Blender developers will start updating the manual this week, a task to
organize that is here:
https://developer.blender.org/T65710
If you're a developer working for the Blender Foundation, please pick
a chapter or two and start updating it. Aim to spend up to about a
week on it in the
that had lagging issues. To solve this we had to make macOS 10.11 the
minimum version that Blender can run on, though we already only
officially supported 10.12 and up. (Tomoaki Kawada, Brecht Van Lommel)
* Cycles memory usage for instances is now back to what it was in
2.79. This optimization was moved
Hi all,
Mainly we can use help with fixing graphics and input devices issues
on macOS. The list of macOS bugs is here:
https://developer.blender.org/project/board/20/
These are some of the more important ones:
https://developer.blender.org/T63685
https://developer.blender.org/T62565
No, there's no roadmap for specific shading features like that.
On Mon, May 27, 2019, 21:01 Jacob Merrill
wrote:
> Is there a roadmap for particle data node to work in eevee?
>
> What about object info location on volumes?
>
> On Mon, May 27, 2019, 10:37 AM Brecht Van Lommel &
Hi all,
Here are the notes from today's developer meeting. Next meeting is
Monday, 3 June 10:00 CEST / 8:00 UTC, in #blender-coders on
blender.chat.
1) Development
* The Blender 2.80 user interface is now frozen, so that there is a
stable base for creating documentation and tutorials. Settings
1 - 100 of 880 matches
Mail list logo
