Re: [Bf-committers] OpenSubdiv version bump to 3.0.5

[Ray Molenkamp]

The windows libs have been upgraded to v3.0.5 , this is I think the first time 
we've used my

buildscripts to make osd libs, so if any issues popup bug me!

--Ray


On 8/9/2016 9:33 AM, Mai Lavelle wrote:
> Hello everyone,
>
> Looks like we will need to bump OSD to version 3.0.5 for a few bug fixes.
> There might be some performance improvements from this as well.
>
> Thanks,
> Mai
> ___
> 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] Cannot launch Blender 2.78, missing dll

[Ray Molenkamp]

I saw your post on BA as well, neither place is great for a lot of back and 
forth while trouble shooting,

please open up a ticket on developer.blender.org with the issue and I'll see 
what I can do about

sorting this out.

--Ray


On 9/29/2016 9:59, Hadrien Brissaud wrote:
> Hi all,
>
> just grabbed the 2.78 msi for win64 and installed it, but can't launch - I
> get an error message saying there's a sdl2.dll missing. The .zip version
> works fine though.
>
> Hadrien
> ___
> 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] Promoting MSVC 2015 builds as official

[Ray Molenkamp]

Sounds good to me!

--Ray



On 12/2/2016 6:21, Sergey Sharybin wrote:
> Hey everyone,
>
> We've got MSVC 2015 libraries and buildbot for quite some time now. While
> there are some compilation errors time to time on buildbot, they don't seem
> to be MSVC 2015 specific at all.
>
> Is there any reason NOT to make MSVC 2015 a default one for Blender? This
> will include:
>
> - Removing MSVC 2013 builders from buildbot. As a benefit users wouldn't be
> confused whether they should go with 2013 or 2015 builds.
> - Moving focus to MSVC 2015 libraries, which will save us time form
> maintaining and testing MSVC 2013 libraries.
> - If nobody from community steps up for the 2013 libraries maintenance
> those libraries will fade out naturally as it happened when we switched
> from 2008 to 2013.
>
> Any thoughts?
>

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

Re: [Bf-committers] Libraries update required

[Ray Molenkamp]

All (2013/2015/x86/x64) windows libraries have been updated, one thing to note

though is that all sse support in oiio had to be disabled, due to some 
incompatibilities

between the oiio simd headers and msvc.


If there's any issues, drop me a line or bug me on irc.


--Ray


On 12/1/2016 7:27 AM, Sergey Sharybin wrote:
> Eh, sure enough i forgot something.
>
> Please ALSO update Python from 3.5.1 to 3.5.2. This brings fixes to asyncio
> module which is now used more and more in various addons.
>
> On Thu, Dec 1, 2016 at 3:24 PM, Sergey Sharybin 
> wrote:
>
>> Hey everyone,
>>
>> Here is a request for platform maintainers to perform the following
>> libraries update:
>>
>> - Update OIIO from 1.6.9 to 1.7.8 (will solve T49250)
>> - Update OSL from 1.7.3 to 1.7.5 (recompilarion is needed since OIIO
>> update, so can update to latest version as well)
>> - Update FFmpeg from 2.1.5 to 3.2.1 (we were hitting weird bugs in the
>> studio with 2.1.5)
>> - Update OSD from 3.0.1 to 3.1.0 (brings new fixes/improvements for
>> face-farying data)
>>
>> That's it for now, just let me know in IRC how this goes.
>>
>> --
>> With best regards, Sergey Sharybin
>>
>
>

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

Re: [Bf-committers] Building the unit tests using VS2015

[Ray Molenkamp]

Gratian,

The cycles unit tests are currently broken on windows, for various reasons
I'm working on getting this corrected, but consensus has not been reached
on how to properly do it. You can track progress here:

https://developer.blender.org/D2367

not mentioned in this diff, but you also need python 3+ in the path before
running the tests.

Funny you talk about finding optimizer bugs, would you mind taking a peek at
https://developer.blender.org/T50176 , I haven't had time to isolate the
misbehaving code, (tried but problem went away) or look at the generated 
assembly.
but given 2015/x86/release is the only configuration this bug shows up at, it 
sure
does feel like an optimizer bug.

--Ray

On 12/4/2016 4:06 AM, Gratian Lup wrote:
> Hello,
>
> I'm a developer on the Visual C++ optimizer and was looking into adding
> Blender into our new test suite that contains dozens of popular/large
> open-source applications. This is meant to catch more bugs before releasing
> the product - it's a win both for us and the projects, which should have a
> much easier time upgrading.
>
> I followed the instructions to build Blender and it builds fine with VS2015
> Update 3, until I enable the unit tests using -WITH_GTEST in Cmake. There
> are a few unit tests that fail to build with linking problems. For example:
>
> o cycles_render_graph_finalize_test:
> error LNK2019: unresolved external symbol _TIFFSetErrorHandler referenced
> in function "public: __thiscall
> OpenImageIO::v1_7::TIFFInput::TIFFInput(void)" (??0TIFFInput@v1_7
> @OpenImageIO@@QAE@XZ)
>
> o BLI_string_test:
> error LNK2019: unresolved external symbol "__declspec(dllimport) public:
> __thiscall std::basic_ostream
>> ::basic_ostream . . .
> The only way to avoid these problem was to disable WITH_CYCLES in Cmake, so
> that those test projects are not created in the first place.
>
> Is this a known problem? I used the master branch with the latest prebuilt
> libs for x86. The remaining tests build and run without problems, hopefully
> they will be useful to catch potential optimizer bugs.
>
> Thanks,
> Gratian Lup
> Visual C++ optimizer team
> ___
> 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] Missing libraries building 2.80 branch with MSVC2015

[Ray Molenkamp]

We've updated a few libraries last week to new versions, these changes have been
accounted for in master but have not yet made it into the 2.8 branch.  If you 
need
to build 2.8 at this point in time, you're required to check out the libs 
before these
changes got committed, you can do this by running the following command in your
libs folder

svn up -r 61756

Greetings,
Ray

On 12/10/2016 7:32 AM, Blendergit wrote:
> Hi,
>
> I’m having problems building the 2.8 branch. I have found two issues (I have 
> my local svn libraries copy updated):
>
>
> ErrorProblem with archive_read_open_file(): Failed to open 
> 'C:/MyBlender/BlenderDEV/blender280/../lib/win64_vc14/release/python35_numpy_1.11.tar.gz'
>  
> ErrorLNK1104cannot open file 
> 'C:\MyBlender\BlenderDEV\blender280\..\lib\win64_vc14\ffmpeg\lib\avcodec-55.lib'
>  
>
> When I compile master branch, all works fine. I have checked and these 
> libraries are missing in SVN master repository, so it looks a change in make 
> file for library version change.
>
> Is this a missing library problem or I must disable NUMPY and FFMPEG for 2.8 
> branch?
>
> Best Regards,
> Antonio Vazquez
> ___
> 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] OpenSubdiv update required

[Ray Molenkamp]

Updated the windows libs, tested all variants except 2015/x86 which currently

has unrelated (T50176) issues that break cycles.

--Ray

On 1/24/2017 3:52 AM, Sergey Sharybin wrote:
> Hi,
>
> Was investigating crash of microdisplacement in Cycles with recent builds.
> It appears to be a bug in OpenSubdiv 3.1.0. There is an available fix for
> that [1] which was included into OpenSubdiv 3.1.1 release.
>
> Platform maintainers, please update your OpenSubdiv libraries.
>
> I've already took care of Linux and poked buildbot and verified the new
> builds do not crash anymore.
>
> Thanks,
>
> [1]
> https://github.com/PixarAnimationStudios/OpenSubdiv/commit/e80d4bedcfc96566ee1e75875a52ca8836758350
>

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

Re: [Bf-committers] Library update needed: OpenImageIO version 1.7.13

[Ray Molenkamp]

Windows libs have been updated.

--Ray


On 4/3/2017 4:24 AM, Sergey Sharybin wrote:
> Hi everyone,
>
> I would like platform maintainers to update OpenImageIO library to version
> 1.7.13 (from current 1.7.8).
>
> This is needed to address bug reports T50968 and T50850.
>

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

Re: [Bf-committers] Library update: Alembic moved to 1.7.1

[Ray Molenkamp]

Windows libs have been updated

--Ray


On 4/4/2017 5:01 AM, Sybren A. Stüvel wrote:
> Hello all,
>
> I've just pushed an update to master which updates install_deps.sh to
> install Alembic version 1.7.1 (previously we used 1.6.0). This
> provides us with a slightly nicer API so that I don't have to use
> const_cast<> to work around the old API limitations in upcoming code.
> For more info, see:
>
> https://github.com/alembic/alembic/issues/110
> https://github.com/alembic/alembic/issues/114
>
> All platform maintainers, please update your build system to use
> Alembic 1.7.1.
>
> Cheers,
>
>
> ___
> 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] Update to OpenCollada 1.6.47

[Ray Molenkamp]

The windows libs are done.

--Ray


On 5/10/2017 8:11 AM, Gaia Clary wrote:
> Dear Platform maintainers
>
> Recently i have posted 2 change requests to the openCollada project:
>
> * Fixing the scons build on linux (requested by Hackerman)
> * Improved error handling (reporting errors instead of terminating Blender)
>
> Both changes have been accepted and are available now in the OpenCollada 
> repository.
> Note: The last time we updated OpenCollada in Blender was about 2 years ago.
>
> Because of this i propose to update to OpenCollada - 1.6.47:
>
> https://github.com/KhronosGroup/OpenCOLLADA/releases/tag/v1.6.47
>
> or if that suits better, use the commit number:
>
>  22b1f4ff026881b4d2804d397730286ab7e3d090
>
> from here:
>
>  https://github.com/KhronosGroup/OpenCOLLADA/commits/master
>
> Please be so kind and report any remaining issues with building the 
> libraries.
> If you know a fix for your find, you can forward the fix to OpenCollada
> project or tell me about it. Then i will take care :)
>
> thanks,
> cheers,
> Gaia
>
> ___
> 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] Library update needed: OpenColorIO version from master

[Ray Molenkamp]

The windows libs were completed yesterday.

--Ray


On 5/15/2017 8:33 AM, Sergey Sharybin wrote:
> Hi,
>
> I would like platform maintainers to update OpenColorIO latest master
> verison of to 6de9710 since this is required to fix interpolation issues
> reported in T51217.
>

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

Re: [Bf-committers] Update Python library to 3.5.3

[Ray Molenkamp]

The msvc libs took a bit, but they are done!

--Ray


On 5/18/2017 8:13 AM, Bastien Montagne wrote:
> Hi platform maintainers,
>
> I’d like to request update of our python library to 3.5.3 (we are 
> currently at 3.5.2).
>
> This fixes https://developer.blender.org/T51415. While not being 
> critical issue at all, Blender 2.79 will likely be around for many 
> months, and we only intend to move to py 3.6 for Blender2.8, so better 
> fix as many issues as possible in 2.79. ;)
>
> Thanks,
> Bastien
>
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> https://lists.blender.org/mailman/listinfo/bf-committers

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

[Bf-committers] Library update needed: OpenImageIO version 1.7.15

[Ray Molenkamp]

Hi everyone,

As mentioned in the weekly notes, I would like platform maintainers to update 
OpenImageIO library to version 1.7.15 (from current 1.7.13).

This will fix a number of regressions introduced in earlier versions where we 
had to turn off SSE2 for MSVC builds. And fix a rather large performance 
problem (again for MSVC only) found by Stefan Werner.

--Ray

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

Re: [Bf-committers] Library update needed: OpenImageIO version 1.7.15

[Ray Molenkamp]

All windows libs have been updated, I also refreshed OSL given it was using 
OIIO's headers.

--Ray


On 6/4/2017 9:40 AM, Ray Molenkamp wrote:
> Hi everyone,
>
> As mentioned in the weekly notes, I would like platform maintainers to update 
> OpenImageIO library to version 1.7.15 (from current 1.7.13).
>
> This will fix a number of regressions introduced in earlier versions where we 
> had to turn off SSE2 for MSVC builds. And fix a rather large performance 
> problem (again for MSVC only) found by Stefan Werner.
>
> --Ray
>
> ___
> 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] Update to OpenCollada 1.6.51

[Ray Molenkamp]

The windows libraries have been updated

--Ray


On 6/7/2017 3:50 AM, Sergey Sharybin wrote:
> Hi,
>
> Linux release environment has been updated.
>
> On Wed, Jun 7, 2017 at 11:26 AM, Gaia Clary 
> wrote:
>
>> Dear Platform maintainers
>>
>> 2 days ago Jens Verwiebe has found an issue with building Blender
>> on Linux with Clang. It was due to an error in one of the
>> Collada include files. The issue has already been fixed in a
>> subsequent OpenCollada release.
>>
>> Because of this i propose to update to OpenCollada - 1.6.51:
>>
>> https://github.com/KhronosGroup/OpenCOLLADA/releases/tag/v1.6.51
>>
>> or if that suits better, use the commit number:
>>
>>   0c2cdc17c22cf42050e4d42154bed2176363549c
>>
>> The OpenCollada commits can be found here:
>>
>>   https://github.com/KhronosGroup/OpenCOLLADA/commits/master
>>
>> Please be so kind and report any remaining issues with building the
>> libraries or building blender with the libraries. If you know a fix
>> for your find, you either can forward the fix to OpenCollada project
>> or tell me about it. Then i will take care :)
>>
>> thanks,
>> cheers,
>> Gaia
>>
>> ___
>> Bf-committers mailing list
>> Bf-committers@blender.org
>> https://lists.blender.org/mailman/listinfo/bf-committers
>> ___
>> Bf-committers mailing list
>> Bf-committers@blender.org
>> https://lists.blender.org/mailman/listinfo/bf-committers
>>
>
>

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

Re: [Bf-committers] Blender 2.79 tetsbuild1 AHOY

[Ray Molenkamp]

Windows builds are at the regular spot, the win32 transfer got interrupted and 
i had to upload it with a different filename, sorry about that.

I have one failing alembic test [1] on both win32 and win64 but that doesn't 
seem like a showstopper , still it be nice if we could resolve this before we 
do any more releases.

--Ray

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


On 6/9/2017 9:22 AM, Sergey Sharybin wrote:
> Hi,
>
> We are ready for first testbuild in the 2.79 series!
>
> Information for platform maintainers:
>
> - Build from the master branch, SHA e0bc5b533cbac09b2aa0ea391082440f4b3b553e
> - Use latest locales and addons revisions for this build.
>
> Suggested name: blender-2.79-testbuild1- Make sure all the
> libraries are up to date, according to [1].
>
> Thanks for your time and let me know when the builds are up.
>
> [1] https://wiki.blender.org/index.php/Dev:Doc/Building_
> Blender#Library_Versions
>

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

Re: [Bf-committers] Blender dependencies scripts in main repo

[Ray Molenkamp]

I have no objections, will this replace install_deps.sh? I have suggested 
merging all platforms
before but got push back due to install_deps wanting to use as much apt-get as 
possible to
keep the time needed to fetch the dependencies down.

I'm not sure making it easily available though make has my preference,  I can 
support other
platform maintainers building libs on windows, but I would lack the time to do 
this for a wider
user base. 

--Ray

On 7/24/2017 5:59 PM, Brecht Van Lommel wrote:
> Hi all,
>
> I would like to get the scripts used to build library dependencies on Windows 
> and macOS committed to the main Blender repository. Currently these scripts 
> are on GitHub:
> https://github.com/LazyDodo/blender_dependencies
> https://github.com/brechtvl/blender_dependencies/tree/apple
>
> They could go into build_files/dependencies, and be invoked through "make 
> dependencies".
>
> There are some code style differences, and various cleanups could be done as 
> well. But I would like to know if others agree this is the right way to go, 
> before spending time on making a branch / code review. Any 
> objections/concerns about this?
>
> I've also ported the scripts to Linux, which wasn't a big step from macOS. 
> I'd love to have a unified system for all platforms to generate a static 
> release binary from scratch, but that's a more complicated discussion.
>
> Thanks,
> Brecht.

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

Re: [Bf-committers] Blender dependencies scripts in main repo

[Ray Molenkamp]

On 7/25/2017 3:38 AM, Sergey Sharybin wrote:
>
>> I would like to have the files in the main Blender repo so that when adding
>> or upgrading a library, a single commit documents all the changes, and can
>> be submitted to differential. It also means we can reuse existing cmake
>> code, which is more painful if we use a submodule.
>>
> I don't see why submitting a patch to differencial is important. It is much
> more important to mail this mailing list when you need something. This is
> the only reliable way to guarantee all platform maintainers and maintainers
> of our build instructions on Wiki will pick things up and  sign under that
> they made a build.

I don't think we're gonna have a single commit for a lib upgrade anyhow, 
there's a bunch of
externals that do not test on windows regularly , (oiio had it's fair share of 
issues in the last
year for instance) if someone updates a lib version, odds are i have to make 
some patches
to actually make it build.  That being said, I'd still prefer doing that than 
all platform devs
having their own build scripts to maintain.

--Ray


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

Re: [Bf-committers] Blender 2.79 Release Candidate 1 AHOY!

[Ray Molenkamp]

The windows builds are done.

--Ray

On 8/1/2017 11:34 AM, Bastien Montagne wrote:
> Hi,
>
> We've switched to bcon5 today which means two things:
>
> 1. Only crucial fixes are allowed in the master branch
> 2. We're doing RC1 builds
>
> Information for platform maintainers:
>
> - Branch: blender-v2.79-release
> - Branch hash: 5e9132b3b7d43785ec0f4d944159acc1c815c7c9
> - Locale hash: 86bad5bdd62b2ae4db1c9027a9cc3e378c3e564c
> - Addons hash: 9d3a25cac02a56afa898e930e6f4dfa270fd4c28
>
> Suggested name: blender-2.78-rc1-
>
> Please note Git is considered frozen for until all the builds are up 
> (approx ~24hrs from now on). No commits are allowed to the master branch 
> for until unfreeze message is sent t this ML (expect this tomorrow 
> afternoon-ish).
>
> Thanks everyone for the work! :)
>
> P.S. Tagging will happen after it's clear we don't do re-AHOY.
>
> PPS: First release for me, hope I did not forget anything...
>
> Bastien Montagne
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> https://lists.blender.org/mailman/listinfo/bf-committers

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

[Bf-committers] with_system_glew / gles options on linux.

[Ray Molenkamp]

Not my regular platform, but I tend to help out the odd user with linux 
building errors, and this
one comes up rather frequently

In our cmakelist.txt we have an exception for linux that sets

option(WITH_SYSTEM_GLEW "Use GLEW OpenGL wrapper library provided by the 
operating system" ON)
option(WITH_SYSTEM_GLES "Use OpenGL ES library provided by the operating 
system"   ON)

compared to all other platforms where it is off.

I couldn't find a justification for it, but why are these options (unlike all 
other
WITH_SYSTEM_* options even on linux ) ON by default? Especially glew seems to be
problematic, even more so for blender 2.8 where we can't figure out if it's 
glew 1 or 2
at compile time so there's a runtime check in the final binary that'll prevent 
code
compiled against 1.x from running.

We ship with a known good copy in our source tree, why not use it by default?

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

Re: [Bf-committers] make.bat make.exe name collision/confusion

[Ray Molenkamp]

Make.bat was called that long before I started maintaining it, so I have no
historic knowledge on how that came to be.

The 'Using the Command line' section already explains how to open a proper
cmd.exe command prompt. The wiki instructions work well *IF* you follow them
to the letter, over the years I have helped out many many people building
blender, and the most common mistake is people not reading or deciding "I can
skip this bit, it doesn't look important" and there's no amount of
documentation that'll work to fix that behavior.

If we're gonna rename it, I'd probably prefer Build.cmd over make_vs.bat but
honestly given we do not support mingw or cygwin builds, we might as well
just check for windows in the GNUmakefile and error out if we figure out it
is running on windows.

--Ray



On 9/2/2017 2:10 PM, Nicholas Rishel wrote:
> The current Building Blender on Windows
>  wiki
> page recommends using the convenience batch file "make" to build Blender.
> When running make from Git Bash (and I suspect other versions of bash for
> Windows) the commands as presented will default to make.exe if it's in the
> PATH and appear to run as expected. This is likely to cause confusion for
> new developers reviewing this document.
>
> The problem above is probably best solved in the wiki with a quick edit;
> the reason I'm mailing here is to see if there is a particular reason the
> file uses the name "make" other than it's similarity in function to
> makefiles. I suspect it's a convenience for other scripts which usually
> rely on make but no particular reason is given in the git logs.
>
> If there isn't a strong reason to keep the name as is it would reduce
> confusion if make.bat were renamed to make_vs.bat or similar so that bash
> on Windows doesn't appear to be running it while actually running bash.exe.
> ___
> 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] Blender 2.79 Release Candidate 2 AHOY

[Ray Molenkamp]

windows builds are ready.

--Ray


On 9/11/2017 4:50 AM, Bastien Montagne wrote:
> Hi,
>
> We are ready for the 2.79 final release!
>
> Information for platform maintainers:
>
> - Build from the blender-2.79-release branch,
> SHA 5bd8ac9abfa2fa5db8ddfef393fc2c4dc82ba22d
> - Addons revision: f1c6cfa21594e7c8b7a43cd1e0653d8a812929c6
> - Locale revision: 1bbc9bdabe4ed26c164aef8a43ef39657dc23cfb
>
> Keep naming consistent with currently uploaded rc2. Make sure you're using 
> tagged libraries and not latest trunk libraries.
>
> As usual, tagging (as well as API docs and fixlist updates) will happen once 
> all builds are up and we are sure we do not need to re-ahoy.
>
> Thanks for your time and let me know when the builds are up.
>
> Cheers,
> Bastien
> ___
> 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] Blender 2.79 Release Candidate 2 AHOY

[Ray Molenkamp]

Why is the .zip file advertised as 'portable' on the download page ?
We write to the users profile folder for settings and any 3rd party
add-ons that get installed by the user. Which is exactly what portable
applications are not supposed to do [1]

'standalone' instead of portable will probably be better.
 
Also it being hidden behind the 'macOS, GNU/Linux, and other platforms'
drop down is making the 32 bit builds (and zip versions) harder to find
for end users (people on irc were already complaining about not being
able to find things).

The website looks great, but can we give some thought on how end users
will actually use the website?

--Ray

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

On 9/12/2017 5:54 AM, Ton Roosendaal wrote:
> Hi,
>
> Pablo is wrapping up the blender.org pages now, official release (as in on 
> blender frontpage) is within an hour!
> Thanks,
>
> -Ton-
>
> 
> Ton Roosendaal  -  t...@blender.org   -   www.blender.org
> Chairman Blender Foundation, Director Blender Institute
> Entrepotdok 57A, 1018 AD, Amsterdam, the Netherlands
>
>> On 12 Sep 2017, at 12:40, Bastien Montagne  wrote:
>>
>> Builds have been published, git repositories have been tagged,
>> py API doc has been updated, as well as bugfixes list... [1]
>>
>> Thanks a lot everybody, now we may focus on 2.8! xD
>>
>> Cheers,
>> Bastien
>>
>> [1] 
>> https://wiki.blender.org/index.php/Dev:Ref/Release_Notes/2.79/Bug_Fixes#Release
>>
>>
>> Le 11/09/2017 à 21:46, Sergey Sharybin a écrit :
>>> Hi,
>>>
>>> All the builds are up at their final destination.
>>>
>>> We need to give some hours to let mirrors to sync, then we can modify the
>>> download page. Release candidate builds will be removed once download page
>>> is updated.
>>>
>>> On Mon, Sep 11, 2017 at 5:04 PM, Ray Molenkamp  wrote:
>>>
>>>> windows builds are ready.
>>>>
>>>> --Ray
>>>>
>>>>
>>>> On 9/11/2017 4:50 AM, Bastien Montagne wrote:
>>>>> Hi,
>>>>>
>>>>> We are ready for the 2.79 final release!
>>>>>
>>>>> Information for platform maintainers:
>>>>>
>>>>> - Build from the blender-2.79-release branch,
>>>>> SHA 5bd8ac9abfa2fa5db8ddfef393fc2c4dc82ba22d
>>>>> - Addons revision: f1c6cfa21594e7c8b7a43cd1e0653d8a812929c6
>>>>> - Locale revision: 1bbc9bdabe4ed26c164aef8a43ef39657dc23cfb
>>>>>
>>>>> Keep naming consistent with currently uploaded rc2. Make sure you're
>>>> using tagged libraries and not latest trunk libraries.
>>>>> As usual, tagging (as well as API docs and fixlist updates) will happen
>>>> once all builds are up and we are sure we do not need to re-ahoy.
>>>>> Thanks for your time and let me know when the builds are up.
>>>>>
>>>>> Cheers,
>>>>> Bastien
>>>>> ___
>>>>> Bf-committers mailing list
>>>>> Bf-committers@blender.org
>>>>> https://lists.blender.org/mailman/listinfo/bf-committers
>>>> ___
>>>> Bf-committers mailing list
>>>> Bf-committers@blender.org
>>>> https://lists.blender.org/mailman/listinfo/bf-committers
>>>>
>>>
>> ___
>> Bf-committers mailing list
>> Bf-committers@blender.org
>> https://lists.blender.org/mailman/listinfo/bf-committers
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> https://lists.blender.org/mailman/listinfo/bf-committers

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

[Bf-committers] Libsndfile version mismatches

[Ray Molenkamp]

While tracking down T52756, I stumbled on some version mismatches in our
versions of libsndfile.

Windows vc12 x86/x64 1.0.25
Windows vc14 x86/x64 1.0.26 (which has a seeking bug)
Linux x64/x86 1.0.25
Mac OS x64 1.0.24

https://wiki.blender.org/index.php/Dev:Doc/Building_Blender isn't listing
any specific version for libsndfile, given there's a bunch of CVE's fixed
since 1.0.24, should we just straighten out all platforms on the latest
version (1.0.28)?

Second,libsndfile is one of the few libs we link dynamically on windows (and
nobody seems to remember why), if we're gonna straighten out the lib versions
on this, anyone mind if I switch this to static libs like most of our other
externals?

--Ray



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

Re: [Bf-committers] Blender 2.79 Release Candidate 2 AHOY

[Ray Molenkamp]

Allright! Good to know it was given some thought, that being said, I still had 
to talk some users into finding  the .zip  distribution. Clicking 
'MacOS/linux/other' apparently

isn't *that* intuitive. Also my 32 bit Ubuntu just got served a 64 bit build, 
so I still feel some

tweaking can be done here.

--Ray


On 9/18/2017 2:41 AM, Julian Eisel wrote:
> Just a quick update on Ray's concerns (we already discussed them in IRC):
>
> Term 'portable' was replaced by '.zip'.
> Re hiding of other platforms, the platform is automatically detected.
> So if you're running 32bit Linux, the big download button should
> download Blender for 32bit Linux.
> I'd say there was definitely some thought on how end users actually use it! ;)
>
> On 12 September 2017 at 22:48, Ray Molenkamp  wrote:
>> Why is the .zip file advertised as 'portable' on the download page ?
>> We write to the users profile folder for settings and any 3rd party
>> add-ons that get installed by the user. Which is exactly what portable
>> applications are not supposed to do [1]
>>
>> 'standalone' instead of portable will probably be better.
>>
>> Also it being hidden behind the 'macOS, GNU/Linux, and other platforms'
>> drop down is making the 32 bit builds (and zip versions) harder to find
>> for end users (people on irc were already complaining about not being
>> able to find things).
>>
>> The website looks great, but can we give some thought on how end users
>> will actually use the website?
>>
>> --Ray
>>
>> [1] https://en.wikipedia.org/wiki/Portable_application
>>
>> On 9/12/2017 5:54 AM, Ton Roosendaal wrote:
>>> Hi,
>>>
>>> Pablo is wrapping up the blender.org pages now, official release (as in on 
>>> blender frontpage) is within an hour!
>>> Thanks,
>>>
>>> -Ton-
>>>
>>> 
>>> Ton Roosendaal  -  t...@blender.org   -   www.blender.org
>>> Chairman Blender Foundation, Director Blender Institute
>>> Entrepotdok 57A, 1018 AD, Amsterdam, the Netherlands
>>>
>>>> On 12 Sep 2017, at 12:40, Bastien Montagne  wrote:
>>>>
>>>> Builds have been published, git repositories have been tagged,
>>>> py API doc has been updated, as well as bugfixes list... [1]
>>>>
>>>> Thanks a lot everybody, now we may focus on 2.8! xD
>>>>
>>>> Cheers,
>>>> Bastien
>>>>
>>>> [1] 
>>>> https://wiki.blender.org/index.php/Dev:Ref/Release_Notes/2.79/Bug_Fixes#Release
>>>>
>>>>
>>>> Le 11/09/2017 à 21:46, Sergey Sharybin a écrit :
>>>>> Hi,
>>>>>
>>>>> All the builds are up at their final destination.
>>>>>
>>>>> We need to give some hours to let mirrors to sync, then we can modify the
>>>>> download page. Release candidate builds will be removed once download page
>>>>> is updated.
>>>>>
>>>>> On Mon, Sep 11, 2017 at 5:04 PM, Ray Molenkamp  wrote:
>>>>>
>>>>>> windows builds are ready.
>>>>>>
>>>>>> --Ray
>>>>>>
>>>>>>
>>>>>> On 9/11/2017 4:50 AM, Bastien Montagne wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> We are ready for the 2.79 final release!
>>>>>>>
>>>>>>> Information for platform maintainers:
>>>>>>>
>>>>>>> - Build from the blender-2.79-release branch,
>>>>>>> SHA 5bd8ac9abfa2fa5db8ddfef393fc2c4dc82ba22d
>>>>>>> - Addons revision: f1c6cfa21594e7c8b7a43cd1e0653d8a812929c6
>>>>>>> - Locale revision: 1bbc9bdabe4ed26c164aef8a43ef39657dc23cfb
>>>>>>>
>>>>>>> Keep naming consistent with currently uploaded rc2. Make sure you're
>>>>>> using tagged libraries and not latest trunk libraries.
>>>>>>> As usual, tagging (as well as API docs and fixlist updates) will happen
>>>>>> once all builds are up and we are sure we do not need to re-ahoy.
>>>>>>> Thanks for your time and let me know when the builds are up.
>>>>>>>
>>>>>>> Cheers,
>>>>>>> Bastien
>>>>>>> ___
>>>>>>> Bf-committers mailing list
>>>>>>> Bf-committers@blender.org
>>>>>>> https://lists.blender.org/mailman/listinfo/bf-committers
>>>>>> ___
>>>>>> Bf-committers mailing list
>>>>>> Bf-committers@blender.org
>>>>>> https://lists.blender.org/mailman/listinfo/bf-committers
>>>>>>
>>>> ___
>>>> Bf-committers mailing list
>>>> Bf-committers@blender.org
>>>> https://lists.blender.org/mailman/listinfo/bf-committers
>>> ___
>>> Bf-committers mailing list
>>> Bf-committers@blender.org
>>> https://lists.blender.org/mailman/listinfo/bf-committers
>> ___
>> Bf-committers mailing list
>> Bf-committers@blender.org
>> https://lists.blender.org/mailman/listinfo/bf-committers
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> https://lists.blender.org/mailman/listinfo/bf-committers

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

[Bf-committers] Library update: libsndfile 1.0.28

[Ray Molenkamp]

Hello all,

I've just pushed an update to the cmake dependencies builder (mac/windows)
to update the previously untracked library libsndfile to 1.0.28.

The reason for this is that between the various supported platforms
we used 3 different versions, some of them with rather nasty bugs.

So to straighten that out, I request all platform maintainers to standardize
on libsndfile 1.0.28.

I have added it to the list of tracked libraries on:

https://wiki.blender.org/index.php?title=Dev:Doc/Building_Blender

Also there was some talk about turning this to a static library on windows
and can report back that it will will have to remain a dynamic library,
given building it static with mingw it will introduce an undesirable
dependency on libgcc.

Cheers,
Ray

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

Re: [Bf-committers] Library update: Python 3.6.2

[Ray Molenkamp]

The windows libs are done.

One point to note, both the windows and mac platform devs have left the 3.5 
libs in


I decided to leave 3.5/3.6 side by side for a few weeks so
branches that lag a little behind can still build without us having to talk 
them though
checking out an older revision of the libs. So any one working in a branch


On 9/19/2017 3:44 AM, Campbell Barton wrote:
> Hi, after 2.79 released we planned to bump Python to 3.6.
> Could platform maintainers update Python builds to 3.6.2 in the next
> week or two, we can switch.
>
> Scripts should not need updating, I've been using Python3.6 since late
> 2016 with Blender and it works fine.
>
> Some features in Py3.6 we can take advantage of are noted here:
> https://developer.blender.org/T47811
>

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

Re: [Bf-committers] Library update: Python 3.6.2

[Ray Molenkamp]

pressed send too soon, oh well..

The windows libs are done.

One point to note, both the windows and mac platform devs have left the 3.5 
libs in
svn (side by side with 3.6) so branches that lag a little behind can still build
without us having to talk them though checking out an older revision of the 
libs.
this will however not be a permenent solution, I plan to remove 3.5 from svn in 
about
4 weeks. So anyone working in a branch this is your notice to start migrating.

--Ray


On 9/19/2017 3:44 AM, Campbell Barton wrote:
> Hi, after 2.79 released we planned to bump Python to 3.6.
> Could platform maintainers update Python builds to 3.6.2 in the next
> week or two, we can switch.
>
> Scripts should not need updating, I've been using Python3.6 since late
> 2016 with Blender and it works fine.
>
> Some features in Py3.6 we can take advantage of are noted here:
> https://developer.blender.org/T47811
>

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

Re: [Bf-committers] Library update: Python 3.6.2

[Ray Molenkamp]

Windows has been updated to 2.18.4 as well , while i was looking in 
site-packages
I noticed while our python build is pip enabled we do not ship the pip scripts 
in
site-packages, the user manually has to run 'python -m ensurepip' to get them.
should we ship them by default?

--Ray


On 9/21/2017 9:41 AM, Arto Kitula wrote:
> macOS libs updated to include requests 2.18.4 on python3.6
>  
>
>> On 21 Sep 2017, at 17.28, Sergey Sharybin  wrote:
>>
>> Hi,
>>
>> Just a quick update.
>>
>> There was already some code to deal with newer requests library version, so
>> just added extra dependencies which are needed for latest requests. So the
>> status on Linux is: we are ready to switch to Python 3.6, which will also
>> mean we'll switch to latest requests and numpy versions.
>>
>> On Thu, Sep 21, 2017 at 4:58 PM, Arto Kitula  wrote:
>>
>>> Hi!
>>>
>>> Check e0f68e5d229f, dependency build system for requests is working for
>>> macOS, Ray will update windows side of things there, if any needed. No
>>> binaries, no wheels, just all dependencies.
>>>
>>> So I’m ok for latest requests, and already ready to push updated stuff to
>>> svn site-packages, waiting for Ray to confirm windows side of things. Then
>>> we need report from linux side =)
>>>
>>>
 On 21 Sep 2017, at 14.41, Sergey Sharybin  wrote:

 Hi,

 Linux build evironment was updated to Python 3.6.2 and numpu 1.13.1.

 There are issues with requests, mainly caused by the package being splint
 into multiple ones, so now CMake should be installing
>>> requests,certifi,idna
 and some charset packages as well. Proposal is:

 - Keep requests as-is for now
 - Switch all platform to new Python
 - De-duplicate and cleanup mess around site-packages for Windows/macOS
 - Do requests update

 This way we avoid too many variables changed at a time, which should help
 avoiding something going wrong.

 On Thu, Sep 21, 2017 at 1:09 PM, Bastien Montagne >>>
 wrote:

> Updated install_deps for python 3.6.2 and numpy 1.13.1.
>
>
> Le 19/09/2017 à 11:44, Campbell Barton a écrit :
>
>> Hi, after 2.79 released we planned to bump Python to 3.6.
>> Could platform maintainers update Python builds to 3.6.2 in the next
>> week or two, we can switch.
>>
>> Scripts should not need updating, I've been using Python3.6 since late
>> 2016 with Blender and it works fine.
>>
>> Some features in Py3.6 we can take advantage of are noted here:
>> https://developer.blender.org/T47811
>>
>>
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> https://lists.blender.org/mailman/listinfo/bf-committers
>


 --
 With best regards, Sergey Sharybin
 ___
 Bf-committers mailing list
 Bf-committers@blender.org
 https://lists.blender.org/mailman/listinfo/bf-committers
>>> --
>>> Arto Kitula
>>> arto.kit...@gmail.com
>>>
>>>
>>>
>>>
>>> ___
>>> Bf-committers mailing list
>>> Bf-committers@blender.org
>>> https://lists.blender.org/mailman/listinfo/bf-committers
>>>
>>
>>
>> -- 
>> With best regards, Sergey Sharybin
>> ___
>> Bf-committers mailing list
>> Bf-committers@blender.org
>> https://lists.blender.org/mailman/listinfo/bf-committers

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

Re: [Bf-committers] wintab.h

[Ray Molenkamp]

This file should be in the libraries you checked out  from svn, validate that 
you did the checkout and that it succeeded successfully.

--Ray


On 10/29/2017 9:00 PM, 不知疲倦的鱼 wrote:
> Hello, I am compiling blender source code follow the steps of 
> "https://wiki.blender.org/index.php/Dev:Doc/Building_Blender"but the process 
> are interrupted, and compiler give a message that could not found "wintab.h". 
>  I search anywhere of my PC's
> system directory, there is NOT any file called"wintab.h", how to resolve this 
> problem?  Should I need to install some librarys ?
> or simply got a wintab.h and put it into MSVC's include dir ? please help me, 
> thanks.
> ___
> 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] Patch: OCIO Parse Colorspace From Filename

[Ray Molenkamp]

Most of the things asked can be done from an add on, with no core changes 
needed,
I quickly whipped one up (tested only on windows). not the prettiest code 
around but
it shows the concept can work.

Also it saves a ton of clicks by only having to open a single texture in a set, 
and it'll do
its best to figure out the related textures.

https://github.com/LazyDodo/MultiInput

--Ray

On 12/10/2017 10:48 PM, Troy Sobotka wrote:
> Greets.
>
> In response to the thread regarding the tedium of manual setting of colour
> spaces,
> I've created this patch that leverages OpenColorIO's
> parseColorSpaceFromString
> functionality.
>
> 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.
>
> https://developer.blender.org/differential/diff/9682/
>
> With respect,
> TJS
> ___
> 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] End of CUDA support for older cards and 32 bit

[Ray Molenkamp]

not for gpu rendering with cycles, however given it's an opengl 4.2 card the ui 
and eeve should run happily with it.

--Ray


On 1/24/2018 11:32 AM, Knapp wrote:
> So 2.80 will not support the 580?
>
> On Mon, Jan 22, 2018 at 4:38 PM, Brecht Van Lommel <
> brechtvanlom...@pandora.be> wrote:
>
>> Hi all,
>>
>> Cycles will soon stop supporting GPU rendering on NVIDIA graphics cards
>> with compute capability 2.0 and 2.1. This includes the NVIDIA GTX 480 and
>> 580, see here for a full list:
>> https://developer.nvidia.com/cuda-gpus
>>
>> We have postponed this as long as practical, but now have to switch to CUDA
>> 9 to support new graphics card generations. Unfortunately this new CUDA
>> version also dropped support for older graphics cards.
>>
>> CUDA rendering will also no longer be available in 32 bit builds, due to
>> parts of the new CUDA toolkit only working on 64 bit.
>>
>> For Blender 2.79a nothing will change yet, but afterwards the code,
>> buildbot and further releases will be updated. Blender's viewport and
>> Cycles CPU rendering will continue to work.
>>
>> Thanks,
>> Brecht.
>> ___
>> Bf-committers mailing list
>> Bf-committers@blender.org
>> https://lists.blender.org/mailman/listinfo/bf-committers
>>
>
>

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

[Bf-committers] Changes to Windows Compiler Support.

[Ray Molenkamp]

All,

With 2.8 coming up I'd like to make some changes to the supported
compilers for Blender. However since these are rather large changes
I'd like to give everyone an opportunity to express any concerns.

Issues:

1) Currently we support msvc 2013(vc12)/2015(vc14)/2017(vc14)
for building, however we ship all our releases with msvc2013(vc12). This has
lead to some interesting issues with python, since any binary addons the user
might install with pip (or just manually copy in) will be using the vc14 crt.
It's rare to run into issues, but when it does it's an instant process 
termination
(the crt does not deal meeting it's future/past self very well)

Given python is our most important dependency I'd like to propose that any 
blender
version we ship in the future (2.8+, 2.79x can keep doing what it's doing) 
matches
the official python recommendation for that version [1] so we have maximum 
compatibility with any python addons

2) To support msvc 2017 we'll officially need a newer boost version, sadly 
support
for the latest is only available in 1.66 and i have not tested yet if all our
dependencies can actually build against it. However we have no failing tests 
when
building blender with boost 1.60+2017. it is just a bit (212 warns) chatty with
unknown compiler warnings, we could possibly repress these.

3) We recently added a switch in cmake to force the compiler to read all our 
code
as utf-8 (since there were some users on other codepages that got compiler 
errors
on some utf8 strings) this added 290 C4828 compiler warnings to a full blender 
build.
not great. None of these originate in our code, they are dragged in though 3rd 
party
headers.

10 in extern/bullet (we can probably fix these)
19 in lib/boost (this one is fixed in newer boost versions [2])
261 in lib/OpenCollada (we can easily send a pull upstream)

however all of these are in comments, completely repressing C4828 might not be 
the
worst thing here.

4) Libraries

There's a library upgrade [3] coming up for OSL/LLVM/OIIO that just doesn't 
build on
msvc2013.

5) Cuda

Nvidia is notoriously slow with supporting newer msvc versions severely 
limiting the
compiler versions we can use (cuda9 only supports 2017 RTM, and we're on update 
5
for msvc currently), to resolve this hostage situation I have created a small 
wrapper
around nvrtc that's able to compile cycles [4], however nvidia doesn't allow 
nvrtc
to create 32 bit cubins. which held me back from committing it.

6) 32 bit support

I spend a fair amount of time building the blender deps in various formats, x86
it starting to cost more and more time since a few of the projects just seem
to test on linux, sometimes on windows/x64 but rarely on x86 leading to all 
kinds
of obscure (usually sse) related build errors. This is starting to take up a
significant amount of my time for only a small percentage of end users (last
time I asked ~15% of the blender downloads were for 32 bit users) and by the
time we release 2.8 this number will probably have dropped even further. 

Proposal:

Officially drop msvc 2013 support for master/2.80 and make vs2017.5 the new 
standard.

1) Land D2913, I had been dragging my heels on this because of the breakage for 
x86
but given brecht recently put out an email [5] saying we were going to drop 
support
there's no reason not to apply this anymore.

2) Retire the 2013+2015 buildbots, and replace them with vs2017 based builds.

3) Block msvc2013 version in cmake

4) Remove the vc12 folders from svn

5) Silence the 'unknown compiler warning in our boost version'

6) Add C4828 to the ignored warning list.

7) Update the wiki build instructions.

I can do most of these my self, but will probably need sergey to do no 2.

Pushing my luck:

Is it too soon to drop x86 support?

Note that all of these changes are for master/2.80. any updates for 2.79 
a/b/c/etc
will remain on msvc2013 with the current libraries.

--Ray

[1] https://wiki.python.org/moin/WindowsCompilers
[2] 
https://github.com/boostorg/format/commit/045c6f15b9f6ef654642906f458d26b584b0b4c9
[3] https://developer.blender.org/D2915
[4] https://developer.blender.org/D2913
[5] https://lists.blender.org/pipermail/bf-committers/2018-January/049029.html

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

Re: [Bf-committers] Changes to Windows Compiler Support.

[Ray Molenkamp]

if you bunch up all releases since 2014, yes that does seems to imply 36% are 
still on 32 bit.

however if you split it out per version it paints a 'slightly' different picture

https://imgur.com/a/ZG0Gb

with only 13.2% of 32 bit users for 2.79 and in a rather steep decline from 
previous versions.

--Ray


using this data looking at just the latest blender (2.79) limiting it to


On 1/27/2018 9:39 AM, Dan McGrath wrote:
> Hi,
>
>> 6) 32 bit support
>>
>> I spend a fair amount of time building the blender deps in various
> formats, x86
>> it starting to cost more and more time since a few of the projects just
> seem
>> to test on linux, sometimes on windows/x64 but rarely on x86 leading to
> all kinds
>> of obscure (usually sse) related build errors. This is starting to take
> up a
>> significant amount of my time for only a small percentage of end users
> (last
>> time I asked ~15% of the blender downloads were for 32 bit users) and by
> the
>> time we release 2.8 this number will probably have dropped even further.
> Out of curiosity, I parsed all of our download.blender.org logs since near
> the end of 2014, right up until today and stored them in an sqlite3
> database for people to check. You can download the file at:
>
>   https://download.blender.org/ftp/dan/admin/blender_logs.sqlite.bz2
>
> I specifically limited the list to 200 status files and only valid
> filenames. The schema is:
>
> sqlite> .schema
> CREATE TABLE logs (log_date date NOT NULL, url text NOT NULL, filename text
> NOT NULL, blender_version varchar(10) NULL, bits integer);
> CREATE INDEX idx_bits on logs(bits);
> CREATE INDEX idx_filename on logs(filename);
> CREATE INDEX idx_url on logs(url);
> sqlite> select * from logs limit 3;
> 26/Mar/2014|/release/Blender2.49b/blender-2.49b-windows.exe|blender-2.49b-windows.exe|2.49b|0
> 26/Mar/2014|/release/Blender2.70/blender-2.70-OSX_10.6-x86_64.zip|blender-2.70-OSX_10.6-x86_64.zip|2.70|64
> 26/Mar/2014|/release/Blender2.69/blender-2.69-windows32.exe|blender-2.69-windows32.exe|2.69|32
> sqlite> select count(*) from logs;
> 304113
> sqlite> select count(*) from logs where bits = 32;
> 101756
> sqlite> select count(*) from logs where bits = 64;
> 175647
>
> (bits = 0 is for unknown bit size)
>
> Anyway, for those who were maybe interested, have fun!
>
>
> Cheers,
>
> Dan McGrath
> ___
> 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] Changes to Windows Compiler Support.

[Ray Molenkamp]

the website does a rather excellent job at giving people the proper download 
for their platform, i'm pretty sure those are legitimate 32 bit users.

--Ray


On 1/27/2018 12:18 PM, Knapp wrote:
> using this data looking at just the latest blender (2.79) limiting it to
>
> I wonder how many of those 13% clicked on the wrong thing through ignorance
> or just being distracted.
>

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

Re: [Bf-committers] Blender 2.79a Release AHOY

[Ray Molenkamp]

Windows builds are done, please validate the md5's before using the files

--Ray


On 2/21/2018 9:08 AM, Sergey Sharybin wrote:
> Hi,
>
> We are ready for2.79a release!
>
> Information for platform maintainers:
>
> - Build from the blender-2.79a-release branch, SHA
> 8928d99270ff0dcafe23605221f271308e33f297
> - Addons revision: bd60e89fa04fc037377db48694770f283eb3cafd
> - Locale revision: 1bbc9bdabe4ed26c164aef8a43ef39657dc23cfb
> - Libraries SVN tag: blender-2.79a-release
>
> Suggested name: blender-2.79a-
>
> Make sure you're using 2.79a tag for libraries.
>
> Put builds to usual location and let me know when they are ready.
>
> Tagging will happen soon after all builds are ready.
>

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

[Bf-committers] 2.8 bugs

[Ray Molenkamp]

Hey,

Is there anything we can do to make the text on 
https://builder.blender.org/download/ regarding 2.8 bugs
stand out a little more.

This text is currently under some brightly color buttons in all black.

--
Note on Blender 2.8 builds
Currently we are aware of many issues in 2.8 and actively working to fix them.
Since replying to reports takes time, we have decided to limit bug reports to 
module team members
--

some people took it as, 'you can only report bugs to module members', others 
didn't seem to read it at all
anyhow there's a steady stream on 2.8 tickets coming into the tracker. it be 
nice if that volume went down
a tiny bit.

it might also help to remind people on

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

not to report 2.8 bugs just yet.

--Ray

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

Re: [Bf-committers] Downloading 4.0

[Ray Molenkamp]

4.0? You mean 2.8? On the download page scroll down to 'experimental' and it 
should take you to the right place.

--Ray


On 3/6/2018 7:58 AM, Knapp wrote:
> Hello all!
> I was trying to install 4.0 but what I have found is that it is really hard
> to find it so that I can install it and test it. Having been involved with
> Blender for over 15 years I could solve this problem but how many new
> testers are being blocked by the hurdles that you must overcome to find the
> test version?
>
> IMOHO when you click on the home page-> Downloads
> then there should be a button that says install unstable test version or at
> least a link to a page explaining about how to do it. Would not hurt if
> that page also had a bit about how to find bugs and how to submit a good
> bug report.
>
> Thanks!

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

Re: [Bf-committers] Downloading 4.0

[Ray Molenkamp]

There is such a text on the nightly builds download page, it tells people 
downloading
builds NOT to file bugs on 2.8, people file anyway, which puts extra load on 
the people triaging
the tracker. Giving 2.8 more exposure at this point in time will just further 
increase that load.

--Ray
On 3/7/2018 12:44 PM, Knapp wrote:
> So, someone needs to write what stage 2.8 is at and give the appropriate
> warning and instruction for bug testers at this stage.
>

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

Re: [Bf-committers] Blender 2.79b Release AHOY

[Ray Molenkamp]

The windows builds are done and uploaded.

--Ray


On 3/22/2018 9:03 AM, Sergey Sharybin wrote:
> Clarification:
>
> Libraries SVN tag: blender-2.79a-release
>
> Sorry for the confusion!
>
> On Thu, Mar 22, 2018 at 3:58 PM, Sergey Sharybin 
> wrote:
>
>> Hi,
>>
>> We are ready for 2.79b corrective release!
>> Only crucial bug fixes and regression were fixed there. Details can be
>> seen [1]
>>
>> Information for platform maintainers:
>>
>> - Build from the blender-2.79b-release branch, SHA
>> f4dc9f9d68bddaa206b692e1d077d1a1f2bb1528
>> - Addons revision: 2609a1018e469dde627cfe2147ef993ee9c90f8f
>> - Locale revision: 1bbc9bdabe4ed26c164aef8a43ef39657dc23cfb
>> - Libraries SVN tag: blender-2.79b-release
>>
>> Suggested name: blender-2.79b-. Keep the same register and
>> everything as 'a' release.
>>
>> Make sure you're using 2.79a tag for libraries, and same CUDA verison as
>> for 2.79a release.
>>
>> Put builds to usual location and let me know when they are ready.
>>
>> Tagging will happen soon after all builds are ready.
>>
>> [1] https://developer.blender.org/T54255
>>
>> --
>> With best regards, Sergey Sharybin
>>
>
>

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

Re: [Bf-committers] Blender 2.79b Release AHOY

[Ray Molenkamp]

the ftp server seems determined to keep deleting my md5.txt file (someone 
please look at this?)

but here they are just to be safe

4365E022748E5FBC694D0C2981446EE6  blender-2.79b-windows32.msi
7518551D8D82D39D087DD6A5FDC4F9FF  blender-2.79b-windows32.zip
C496DAF71511246BC84A97A94939C15D  blender-2.79b-windows64.msi
FB904EE151E1B9C4D942E96B3259CD5C  blender-2.79b-windows64.zip

--Ray


On 3/22/2018 10:59 AM, Ray Molenkamp wrote:
> The windows builds are done and uploaded.
>
> --Ray
>
>
> On 3/22/2018 9:03 AM, Sergey Sharybin wrote:
>> Clarification:
>>
>> Libraries SVN tag: blender-2.79a-release
>>
>> Sorry for the confusion!
>>
>> On Thu, Mar 22, 2018 at 3:58 PM, Sergey Sharybin 
>> wrote:
>>
>>> Hi,
>>>
>>> We are ready for 2.79b corrective release!
>>> Only crucial bug fixes and regression were fixed there. Details can be
>>> seen [1]
>>>
>>> Information for platform maintainers:
>>>
>>> - Build from the blender-2.79b-release branch, SHA
>>> f4dc9f9d68bddaa206b692e1d077d1a1f2bb1528
>>> - Addons revision: 2609a1018e469dde627cfe2147ef993ee9c90f8f
>>> - Locale revision: 1bbc9bdabe4ed26c164aef8a43ef39657dc23cfb
>>> - Libraries SVN tag: blender-2.79b-release
>>>
>>> Suggested name: blender-2.79b-. Keep the same register and
>>> everything as 'a' release.
>>>
>>> Make sure you're using 2.79a tag for libraries, and same CUDA verison as
>>> for 2.79a release.
>>>
>>> Put builds to usual location and let me know when they are ready.
>>>
>>> Tagging will happen soon after all builds are ready.
>>>
>>> [1] https://developer.blender.org/T54255
>>>
>>> --
>>> With best regards, Sergey Sharybin
>>>
>>
> ___
> 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] MSBuild problems with ZERO_CHECK project

[Ray Molenkamp]

Given lite builds, perhaps it can't find nvcc? check your cmakecache.txt to see 
if it's pointing to the right executable.

if that doesn't do the trick, change the logging level of the msbuild commands 
inside make.bat from minimal to diagnostic and see if that sheds more light on 
the actual error.

--Ray


On 4/7/2018 9:22 AM, The Simple Carnival wrote:
> Hello --
>
> I recently reinstalled Windows and am trying to compile Blender 2.78c, which 
> I was able to do with my previous Windows installation. I suspect there is a 
> CMake issue, but I'm not sure exactly how to address it.
>
> I'm running into problems when trying to create the Blender Release version. 
> (I can create the Lite version without problems.) Specifically, I'll use the 
> following command...
>
> c:\blender-git\blender>make release
>
> ...and then I will quickly receive this error:
>
> The system cannot find the path specified.
> C:\Program Files 
> (x86)\MSBuild\Microsoft.Cpp\v4.0\V120\Microsoft.CppCommon.targets(170,5): 
> error MSB6006: "cmd.exe" exited with code 3. 
> [C:\blender-git\build_windows_Release_x64_vc12_Release\ZERO_CHECK.vcxproj]
>
> Line 170 in the Microsoft.CppCommon.targets file is this:
>
>     
>   Sources ="@(CustomBuild)"
>   BuildSuffix ="$(_BuildSuffix)"
>
>   TrackerLogDirectory ="%(CustomBuild.TrackerLogDirectory)"
>   MinimalRebuildFromTracking ="%(CustomBuild.MinimalRebuildFromTracking)"
>
>   TLogReadFiles ="@(CustomBuildTLogReadFiles)"
>   TLogWriteFiles ="@(CustomBuildTLogWriteFiles)"
>   TrackFileAccess ="$(TrackFileAccess)"
>   ToolArchitecture ="$(CustomBuildToolArchitecture)"
>   TrackerFrameworkPath ="$(CustomBuildTrackerFrameworkPath)"
>   TrackerSdkPath ="$(CustomBuildTrackerSdkPath)"
>
>   AcceptableNonZeroExitCodes ="%(CustomBuild.AcceptableNonZeroExitCodes)"
>   >
>     
>
>
> One of those paths is apparently bad, but I'm not sure which...nor have I 
> been able to figure out how to print that information from MSBuild.
>
> I temporarily replaced the entire target where that CustomBuild appears with 
> some junk code:
>
>   
>       
>   
>
> I can't see the message text in the console window, but I was at least able 
> to build the Blender release version successfully.
>
> Although this "fix" worked, it's obviously not addressing the root problem. 
> Any ideas on what's going on here, and how I can get my Blender build files 
> to compile without this workaround?
>
> Thanks!
>
> Jeff Boller
> http://www.sundriftproductions.com
>
>
> ___
> 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] Building Blender

[Ray Molenkamp]

follow the wiki, use regular svn. also just to be sure, you are trying to check 
out the libs for a 32bit build with msvc2015/2017.
if that's what your plan was, that's alright,however if you were planning to 
build a 64 bit build (recommended) check out win64_vc14
instead of windows_vc14. the libs are a couple of gigabytes and having to do it 
twice is sometimes problematic for people on
metered connections, so be sure to pick the right ones.

--Ray

On 4/29/2018 7:19 AM, John Emmas wrote:
> On 29/04/2018 11:41, John Emmas wrote:
>>
>> I uninstalled SVN a long time ago so I guess I'll need to find it again.
>>
>
> Okay...  I realised why SVN isn't installed here any more (it's because 
> TortoiseGit can also handle SVN repos).
>
> So I tried cloning, like so:-
>
>     git.exe svn clone 
> "https://svn.blender.org/svnroot/bf-blender/trunk/lib/windows_vc14"; 
> "F:\Test\lib\windows_vc14" -T trunk -b branches -t tags
>
> and I see these messages:-
>
>     Initialized empty Git repository in F:/Test/lib/windows_vc14/.git/
>     Using higher level of URL: 
> https://svn.blender.org/svnroot/bf-blender/trunk/lib/windows_vc14 => 
> https://svn.blender.org/svnroot/bf-blender
>     W: Ignoring error from SVN, path probably does not exist: (160013): 
> Filesystem has no item: File not found: revision 100, path 
> '/trunk/lib/windows_vc14'
>     W: Do not be alarmed at the above message git-svn is just searching 
> aggressively for old history.
>     This may take a while on large repositories
>
> For a few minutes it seems as if things are happening but eventually it fails 
> to fetch anything from 'trunk/lib/windows_vc14', giving me this error:-
>
>     Can't create session: Unable to connect to a repository at URL 
> 'https://svn.blender.org/svnroot/bf-blender'
>     : Error running context: Software caused connection abort at 
> /mingw32/share/perl5/site_perl/Git/SVN.pm line 184.
>
> Any ideas anyone..?
>
> John
>
> ___
> 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] Building Blender

[Ray Molenkamp]

Sometimes the svn server randomly quits, i've never heard about it randomly 
stalling though, i'd probably interrupt the process at this point.

to recover run 'svn cleanup' and 'svn update' to continue from the point it got 
lost.

--Ray


On 4/29/2018 12:05 PM, John Emmas wrote:
> On 29/04/2018 15:27, Ray Molenkamp wrote:
>> the libs are a couple of gigabytes and having to do it twice is sometimes 
>> problematic
>>
>
> Thanks Ray,
>
> This might seem like a dumb question but can the subversion modules be 
> downloaded incrementally somehow?  I installed a proper copy of subversion 
> and began my download.  It downloaded about 1.2GB and then just stopped... ;-(
>
> Nothing's downloaded for the past 15 minutes so I might need to try again 
> tomorrow.
>
> John
> ___
> 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] Building Blender

[Ray Molenkamp]

-Sorry for the late response, I'm currently traveling so connectivity is spotty 
at best.

you should be able to make a build with 2015 given 3 conditions are met

1) you have msvc 2015 update 3 or higher

2 You have a full set of our libs in the right place

3) you run 'make full 2015 x64' in the blender source folder.

--Ray


On 4/30/2018 7:09 AM, John Emmas wrote:
> I (almost) managed to build Blender with VS2015 at my first attempt !!
>
> The main problem is that when compiling some of the modules, I see this 
> output :-
>
>       #error "Cannot find pointer size"
>
> which is coming from this section in 'atomic_ops_utils.h' :-
>
>   #if defined(__SIZEOF_POINTER__)
>   #  define LG_SIZEOF_PTR __SIZEOF_POINTER__
>   #elif defined(UINTPTR_MAX)
>   #  if (UINTPTR_MAX == 0x)
>   #    define LG_SIZEOF_PTR 4
>   #  elif (UINTPTR_MAX == 0x)
>   #    define LG_SIZEOF_PTR 8
>   #  endif
>   #elif defined(__WORDSIZE)  /* Fallback for older glibc and cpp */
>   #  if (__WORDSIZE == 32)
>   #    define LG_SIZEOF_PTR 4
>   #  elif (__WORDSIZE == 64)
>   #    define LG_SIZEOF_PTR 8
>   #  endif
>   #endif
>
>   #ifndef LG_SIZEOF_PTR
>   #  error "Cannot find pointer size"
>   #endif
>
> So I'm guessing that neither __SIZEOF_POINTER__ nor UNITPTR_MAX nor 
> __WORDSIZE are defined anywhere.  Could this be a missing #include maybe?  I 
> assume other devs are building Blender successfully with VS2015?
>
> John
> ___
> 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] Building Blender

[Ray Molenkamp]

Two options here

1) You could have used our make.bat like I previously suggested which would 
have done this step for you.

2) You could also have done this step manually as documented in the 'Building 
from within the Visual Studio IDE'
section of our build instructions [1].

we like to make building blender as easy as possible on windows, we pointed you 
to both of these resources
to in previous emails, but if you are not going to listen to advise, building 
is indeed going to be harder than it
needs to be.

[1] https://wiki.blender.org/index.php/Dev:Doc/Building_Blender/Windows

--Ray

On 5/1/2018 8:04 AM, John Emmas wrote:
> Oops, I just noticed this from my previous post...
>
>>
>>  (if you built with CMake: 'install' target may have not been built)
>>
>
> After building everything, was I supposed to run an installer of some sort?  
> I simply copied all the built EXE's and DLL's into a common folder and hoped 
> for the best.!
>
> John
> ___
> 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] Compiling and running 2.8

[Ray Molenkamp]

You re-used a master build folder for 2.8, given some of our defaults in cmake 
have changed

you can't do that. delete your build folder and you'll be fine.

--Ray


On 5/2/2018 7:55 AM, Christian Hubert wrote:
> Hi,
>
>  
>
> I'm trying to setup my dev env for Blender 2.8 but I fail to do it (355
> errors).
>
>  
>
> The output is the following, building the INSTALL project (beginning of the
> output) :
>
>  
>
> 1>-- Build started: Project: ZERO_CHECK, Configuration: Debug x64 --
>
> 1>Checking Build System
>
> 1>CMake is re-running because
> E:/blender-git-28/build_windows_Full_x64_vc15_Release/CMakeFiles/generate.st
> amp is out-of-date.
>
> 1>  the file 'E:/blender-git-28/blender/CMakeLists.txt'
>
> 1>  is newer than
> 'E:/blender-git-28/build_windows_Full_x64_vc15_Release/CMakeFiles/generate.s
> tamp.depend'
>
> 1>  result='-1'
>
> 1>CMake Error at CMakeLists.txt:584 (message):
>
> 1>  WITH_AUDASPACE requires WITH_CXX11
>
> 1>
>
> 1>
>
> 1>-- Configuring incomplete, errors occurred!
>
> 1>See also
> "E:/blender-git-28/build_windows_Full_x64_vc15_Release/CMakeFiles/CMakeOutpu
> t.log".
>
> 1>CMake Configure step failed.  Build files cannot be regenerated correctly.
> Attempting to stop IDE build.
>
> 1>G:\Programs\Microsoft Visual
> Studio\2017\Professional\Common7\IDE\VC\VCTargets\Microsoft.CppCommon.target
> s(171,5): error MSB6006: "cmd.exe" exited with code -1073741819.
>
> 1>Done building project "ZERO_CHECK.vcxproj" -- FAILED.
>
>  
>
> What I've done :
>
>  
>
> cd C:\blender-git-28
>
> git clone git://git.blender.org/blender.git
>
> cd blender
>
> git submodule update --init --recursive
>
> git submodule foreach git checkout master
>
> git submodule foreach git pull --rebase origin master
>
> cd C:\blender-git-28
>
> svn checkout https://svn.blender.org/svnroot/bf-blender/trunk/lib/win64_vc14
> lib/win64_vc14
> cd C:\blender-git\blender
> make full 2017
>
>  
>
> and
>
>  
>
> git checkout blender2.8
>
>  
>
>  
>
> What am I missing?
>
>  
>
> Kind regards
>
> Christian
>
>  
>
>  
>
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> https://lists.blender.org/mailman/listinfo/bf-committers

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

[Bf-committers] devtalk.

[Ray Molenkamp]

All,

As I understood devtalk was setup as a dev 2 dev support site, I'm kinda
confused we invited end users to 'join the conversation' on it now, as
they are putting feature requests all over the place, last night the
blender development forum was 80+% feature requests on the first page.
kinda ruining the signal to noise ratio. Since then someone came by and
moved them all to the code-quest section. Also a banner has been put up
mentioning the site is not for feature requests. but still, users do what
user do...

While I do see value in gathering user-feedback, it's not very hard to
imagine that the line between feedback and feature requests is arbitrary
at the best of times.

Especially with all the changes currently in 2.8, it's also easy to see
ahead of time that the discussion would be 'heated' at times, devtalk
pretty much coasted by with little to no moderation.

Given the response so far, it's clear users are screaming for an outlet
to share their ideas/opinions/and feature requests.

The question is, was devtalk really the best venue for this experiment?
couldn't we just have spun up another discourse instance?

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

Re: [Bf-committers] devtalk.

[Ray Molenkamp]

I think this is a case of what was envisioned and what is actually
happening on devtalk currently being a tiny bit out of whack.

Devs getting feedback on specific topics is great! a wall of
'Hey devs, lets vote! left or right mouse button!',  'when is
feature X finially finished?' and 'lets change blenders version
number!' not quite as much.

--Ray


On 6/1/2018 2:29 PM, Brecht Van Lommel wrote:
> I think it can work if we make it so developers start topics to request
> feedback on features they are working on. For example one topic for
> shortcut key changes, one for collections, etc. Then we can strictly
> moderate it, close topics when a project is done and keep the number of
> topics under control to avoid overpowering the other posts.
>
> If we let everyone make topics about whatever it's always going to be
> difficult to manage, regardless if we do it on devtalk or another forum.
>
> On Fri, Jun 1, 2018 at 8:10 PM, Ray Molenkamp  wrote:
>
>> All,
>>
>> As I understood devtalk was setup as a dev 2 dev support site, I'm kinda
>> confused we invited end users to 'join the conversation' on it now, as
>> they are putting feature requests all over the place, last night the
>> blender development forum was 80+% feature requests on the first page.
>> kinda ruining the signal to noise ratio. Since then someone came by and
>> moved them all to the code-quest section. Also a banner has been put up
>> mentioning the site is not for feature requests. but still, users do what
>> user do...
>>
>> While I do see value in gathering user-feedback, it's not very hard to
>> imagine that the line between feedback and feature requests is arbitrary
>> at the best of times.
>>
>> Especially with all the changes currently in 2.8, it's also easy to see
>> ahead of time that the discussion would be 'heated' at times, devtalk
>> pretty much coasted by with little to no moderation.
>>
>> Given the response so far, it's clear users are screaming for an outlet
>> to share their ideas/opinions/and feature requests.
>>
>> The question is, was devtalk really the best venue for this experiment?
>> couldn't we just have spun up another discourse instance?
>>
>> --Ray
>> ___
>> Bf-committers mailing list
>> Bf-committers@blender.org
>> https://lists.blender.org/mailman/listinfo/bf-committers
>>
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> https://lists.blender.org/mailman/listinfo/bf-committers

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

[Bf-committers] 2.8 bugs on the tracker.

[Ray Molenkamp]

All,

Since the tracker has now been opened for 2.8 crashes tickets have been
coming in steadily, I'm unsure how to triage these though, previously
it was easy, just the studio tickets were allowed and they placed them
on the 2.8 work board them selves.

Is tagging the end user tickets with just blender 2.8 enough or do they
need to be placed on some work-board as well?

Also the quality of the tickets is sometimes... not great... T55704 for
instance. I can't seem to repro it,odds are it's hardware dependent however
none of the system information has been included, and the broken version
is just listed as '2.8'

T55705 is a clear duplicate of T55696, so users don't tend to search
before posting.

T55706 is a less clear duplicate of T52523 (and T55706 has a not so useful
title, so even if they did search it wouldn't have been found)

I think we need to offer some better guidance here. maybe have pablo
do a video version of :

https://wiki.blender.org/wiki/Process/Bug_Reports

He seems to reach *A LOT* of people with his videos (just an idea,
don't feel pressured into this pablo)  

I'll happily triage as long as my spare time allows for it, but the
quality of the tickets *has* to improve or this will turn into a
rather tedious task that nobody will have any interest in doing.
 
--Ray



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

Re: [Bf-committers] 2.8 bugs on the tracker.

[Ray Molenkamp]

On 7/2/2018 8:03 PM, Ray Molenkamp wrote:
> T55706 is a less clear duplicate of T52523 (and T55706 has a not so useful
> title, so even if they did search it wouldn't have been found)
sorry got my tickets mixed up here, it's a duplicate of T55695.
--Ray
___
Bf-committers mailing list
Bf-committers@blender.org
https://lists.blender.org/mailman/listinfo/bf-committers

[Bf-committers] End of MSVC 2013 support.

[Ray Molenkamp]

I just removed msvc2013 support from make.bat, msvc2017 is now the preferred 
compiler
on windows.

Before I remove the vc12 libs from svn, do we want to tag them for historical 
purposes?
(They have a newer python/numpy/requests/libjpeg than the tagged 2.79 libs)

Also now that msvc2013 is out of the way, I'm open for doing some library 
upgrades,
module owners feel to request them via this mailing list.

If there's any issues feel free to poke me.

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

[Ray Molenkamp]

There's quite a few libraries we build for the various platforms
(57 by the last count) and it's not always clear who the module
owner is and who is supposed to ask for newer versions of certain
libs. 

I took a quick survey of the versions we use and the latest versions
available. (based on build_files\build_environment\cmake\versions.cmake)

https://docs.google.com/spreadsheets/d/e/2PACX-1vRnu75FDmw8NvbJiH9hjrGNBvrwXU9ocWWMCWZY0ISwcfLOnL7Ep1z67Y5FpN_TaI0QRwbPR2KmrQie/pubhtml?gid=0&single=true

(or in case the email ruins the long link: https://tinyurl.com/y9st4fyt )

There are several libs with known CVE's, personally I would prefer
to upgrade those to the latest versions (most seem low risk upgrades)
but for everything else I really have no strong opinion.

Any module owner that wants edit rights, please poke me (email/irc) and
I'll get you an editable link.

--Ray


On 7/23/2018 11:43 AM, Brecht Van Lommel wrote:
> Hi all,
>
> It's been a while since we updated libraries, and with the upgrade to
> Visual Studio 2017 this has now become easier on Windows as well. Since the
> platform maintainers have time now to do updates, let's try to get this in
> motion.
>
> Some of the latest library versions need C++11, I also propose we require
> C++11 in master. This mostly involves removing the WITH_CXX1 option and
> code cleanups for STL data types compatibility.
>
> For libraries, these are the ones I know of. Let us know if any other
> library updates are needed.
>
> * OSL, LLVM, OIIO: so we no longer need a really old LLVM version.
> https://developer.blender.org/D3398
> https://developer.blender.org/D2915
>
> * OpenVDB 5.1.0: so we can read files written by other applications that
> have OpenVDB 5.x.
>
> * Python 3.7.0 (or should we wait until there is a 3.7.1 or so with
> bugfixes?)
>
> * OpenSubdiv: this will need to include a number of Sergey's bugfixes, the
> revision needed is not known (or doesn't exist) yet.
>
> Thanks,
> Brecht.
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> https://lists.blender.org/mailman/listinfo/bf-committers

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

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

[Ray Molenkamp]

Currently we're only shipping idiff since the unit tests need it, we could add 
the other tools
however since we build for blender they are all statically linked, so just 
oiiotool would be
12 megs, while the whole set of binaries would be 45. not sure we want to add 
this much
dead weight to the libs?

--Ray

On 7/24/2018 12:36 AM, Stefan Werner wrote:
> While not directly applicable to Blender, would it be any trouble to include 
> oiiotool.exe in the Windows binaries? There was just someone asking for 
> binaries on the oiio mailing list:
> http://lists.openimageio.org/pipermail/oiio-dev-openimageio.org/2018-July/001254.html
>  
> <http://lists.openimageio.org/pipermail/oiio-dev-openimageio.org/2018-July/001254.html>
>
> -Stefan
>
>> On 23. Jul 2018, at 21:53, Ray Molenkamp  wrote:
>>
>> There's quite a few libraries we build for the various platforms
>> (57 by the last count) and it's not always clear who the module
>> owner is and who is supposed to ask for newer versions of certain
>> libs. 
>>
>> I took a quick survey of the versions we use and the latest versions
>> available. (based on build_files\build_environment\cmake\versions.cmake)
>>
>> https://docs.google.com/spreadsheets/d/e/2PACX-1vRnu75FDmw8NvbJiH9hjrGNBvrwXU9ocWWMCWZY0ISwcfLOnL7Ep1z67Y5FpN_TaI0QRwbPR2KmrQie/pubhtml?gid=0&single=true
>>
>> (or in case the email ruins the long link: https://tinyurl.com/y9st4fyt )
>>
>> There are several libs with known CVE's, personally I would prefer
>> to upgrade those to the latest versions (most seem low risk upgrades)
>> but for everything else I really have no strong opinion.
>>
>> Any module owner that wants edit rights, please poke me (email/irc) and
>> I'll get you an editable link.
>>
>> --Ray
>>
>>
>> On 7/23/2018 11:43 AM, Brecht Van Lommel wrote:
>>> Hi all,
>>>
>>> It's been a while since we updated libraries, and with the upgrade to
>>> Visual Studio 2017 this has now become easier on Windows as well. Since the
>>> platform maintainers have time now to do updates, let's try to get this in
>>> motion.
>>>
>>> Some of the latest library versions need C++11, I also propose we require
>>> C++11 in master. This mostly involves removing the WITH_CXX1 option and
>>> code cleanups for STL data types compatibility.
>>>
>>> For libraries, these are the ones I know of. Let us know if any other
>>> library updates are needed.
>>>
>>> * OSL, LLVM, OIIO: so we no longer need a really old LLVM version.
>>> https://developer.blender.org/D3398
>>> https://developer.blender.org/D2915
>>>
>>> * OpenVDB 5.1.0: so we can read files written by other applications that
>>> have OpenVDB 5.x.
>>>
>>> * Python 3.7.0 (or should we wait until there is a 3.7.1 or so with
>>> bugfixes?)
>>>
>>> * OpenSubdiv: this will need to include a number of Sergey's bugfixes, the
>>> revision needed is not known (or doesn't exist) yet.
>>>
>>> Thanks,
>>> Brecht.
>>> ___
>>> Bf-committers mailing list
>>> Bf-committers@blender.org
>>> https://lists.blender.org/mailman/listinfo/bf-committers
>> ___
>> Bf-committers mailing list
>> Bf-committers@blender.org
>> https://lists.blender.org/mailman/listinfo/bf-committers
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> https://lists.blender.org/mailman/listinfo/bf-committers

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

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

[Ray Molenkamp]

see inline comments


On 7/26/2018 10:21 AM, Brecht Van Lommel wrote:
> I think it would be great to have all these libraries updated, especially
> the ones with CVEs.
>
> * Blosc: definitely need to upgrade one to fix GCC build issues
I  marked the upgrade to latest, the minimum we need is 1.8.1 which already 2+ 
years old
seems silly to upgrade to an already ancient version.

> * clew/cuew: I wonder if we even need OpenCL/CUDA support in OpenSubdiv,
> maybe OpenGL is enough..
unsure, sergey would probably know better here, cuda will be problematic either 
way
with the fighting between nvcc and the msvc compiler version that it may or may 
not
like.  it's currently disabled because of that and I don't think anyone noticed?

> * flexbison/schroendinger/lapack: seems fine to remove
Marked for removal
> * openjpeg: don't think there is a good reason to have it in extern/
> anymore, would be happy to see patch to remove it from there
I have brought this up in the past, and sergey seemed very passionate about 
keeping
it there.


>
> I guess most of these are relatively easy with a tweak to versions.cmake,
> not sure how difficult it is on Linux.
Relativity easy , we just need to pay attention to that when we change a lib we 
also
need to rebuild the libs upstream from it even if their version hasn't changed
(we've run into some weird oiio issues in the past due to a libpng upgrade)

just follow this 'easy' chart and it'll be fine!

http://www.lazydodo.com/tmp/blender_externals.png

--Ray
>
> On Mon, Jul 23, 2018 at 9:54 PM Ray Molenkamp  wrote:
>
>> There's quite a few libraries we build for the various platforms
>> (57 by the last count) and it's not always clear who the module
>> owner is and who is supposed to ask for newer versions of certain
>> libs.
>>
>> I took a quick survey of the versions we use and the latest versions
>> available. (based on build_files\build_environment\cmake\versions.cmake)
>>
>>
>> https://docs.google.com/spreadsheets/d/e/2PACX-1vRnu75FDmw8NvbJiH9hjrGNBvrwXU9ocWWMCWZY0ISwcfLOnL7Ep1z67Y5FpN_TaI0QRwbPR2KmrQie/pubhtml?gid=0&single=true
>>
>> (or in case the email ruins the long link: https://tinyurl.com/y9st4fyt )
>>
>> There are several libs with known CVE's, personally I would prefer
>> to upgrade those to the latest versions (most seem low risk upgrades)
>> but for everything else I really have no strong opinion.
>>
>> Any module owner that wants edit rights, please poke me (email/irc) and
>> I'll get you an editable link.
>>
>> --Ray
>>
>>
>> On 7/23/2018 11:43 AM, Brecht Van Lommel wrote:
>>> Hi all,
>>>
>>> It's been a while since we updated libraries, and with the upgrade to
>>> Visual Studio 2017 this has now become easier on Windows as well. Since
>> the
>>> platform maintainers have time now to do updates, let's try to get this
>> in
>>> motion.
>>>
>>> Some of the latest library versions need C++11, I also propose we require
>>> C++11 in master. This mostly involves removing the WITH_CXX1 option and
>>> code cleanups for STL data types compatibility.
>>>
>>> For libraries, these are the ones I know of. Let us know if any other
>>> library updates are needed.
>>>
>>> * OSL, LLVM, OIIO: so we no longer need a really old LLVM version.
>>> https://developer.blender.org/D3398
>>> https://developer.blender.org/D2915
>>>
>>> * OpenVDB 5.1.0: so we can read files written by other applications that
>>> have OpenVDB 5.x.
>>>
>>> * Python 3.7.0 (or should we wait until there is a 3.7.1 or so with
>>> bugfixes?)
>>>
>>> * OpenSubdiv: this will need to include a number of Sergey's bugfixes,
>> the
>>> revision needed is not known (or doesn't exist) yet.
>>>
>>> Thanks,
>>> Brecht.
>>> ___
>>> Bf-committers mailing list
>>> Bf-committers@blender.org
>>> https://lists.blender.org/mailman/listinfo/bf-committers
>> ___
>> Bf-committers mailing list
>> Bf-committers@blender.org
>> https://lists.blender.org/mailman/listinfo/bf-committers
>>
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> https://lists.blender.org/mailman/listinfo/bf-committers

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

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

[Ray Molenkamp]

We'll get going on this then, there's one lib I'd like some clarification on
arto requested boost 1.66 on irc, not a problem on windows (I'd welcome an
updated version, but do not require it), but how are the linux guys feeling
about bumping the boost version?

--Ray


On 8/8/2018 9:54 AM, Brecht Van Lommel wrote:
> Hi all,
>
> Regarding how to get this moving further, I had a quick talk with Sergey.
> To avoid the Linux part being a bottleneck, I suggest to update the Windows
> and macOS libraries as soon as they are ready, and commit the build
> environment CMake changes alongside them. It's not a big deal if the
> platform versions are out of sync for a bit, and Sergey can do the
> corresponding updates for Linux when he has time.
>
> So Ray and Arto can just coordinate committing these changes amongst
> themselves. If any C/C++ code needs to change we can use #ifdef's, which we
> want anyway in case Linux users are compiling against different library
> versions.
>
> Thanks,
> Brecht.
>
> On Sat, Aug 4, 2018 at 9:01 PM Bastien Montagne 
> wrote:
>
>> Don’t think we are in urgent hurry here, we can give it a few more weeks
>> and see whether 3.7.1 emerges in time for us (would say dead line for
>> libs update would be end of September?)
>>
>>
>> On 03/08/2018 10:57, Sergey Sharybin wrote:
>>> One thing which is raising my attention in 3.7.1 release log is:
>>>
>>> - Fixed a performance regression for reading streams with tarfile.
>>>
>>> Also, 3.7.1 is planned to be released soon-ish? Their original plan
>>> actually mentions July, not sure what is the updated planning. Are we
>>> really in a hurry for this update?
>>>
>>> On Fri, Aug 3, 2018 at 10:46 AM Sybren A. Stüvel 
>> wrote:
 On 23/07/2018 19:43, Brecht Van Lommel wrote:
> * Python 3.7.0 (or should we wait until there is a 3.7.1 or so with
> bugfixes?)
 Let's go to 3.7.0, unless somebody already knows of actual bugs that'll
 influence our use.

 Sybren

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

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

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

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

[Ray Molenkamp]

On 8/8/2018 1:01 PM, bju...@ymail.com wrote:
>  Blosc is currently blocking a full build using recent versions of gcc on 
> Linux. Upgrading by two revisions (to 1.8.1 I believe ) addresses the issue 
> directly.
It's currently tagged for an update to 1.14.3

> This issue may have been what kicked off the library update review? 
It's really not, the review had been on the schedule for quite a while now, but 
an ancient compiler on windows was blocking some of the updates.
> It would be a pity if it was the last to be updated.
It will be don't worry.

--Ray
> I am away from my build machine so please forgive me if the change has 
> already been made.
>
> Justin Jones
>
> On August 8, 2018 9:54:58 AM MDT, Brecht Van Lommel 
>  wrote:
>> Hi all,
>>
>> Regarding how to get this moving further, I had a quick talk with
>> Sergey.
>> To avoid the Linux part being a bottleneck, I suggest to update the
>> Windows
>> and macOS libraries as soon as they are ready, and commit the build
>> environment CMake changes alongside them. It's not a big deal if the
>> platform versions are out of sync for a bit, and Sergey can do the
>> corresponding updates for Linux when he has time.
>>
>> So Ray and Arto can just coordinate committing these changes amongst
>> themselves. If any C/C++ code needs to change we can use #ifdef's,
>> which we
>> want anyway in case Linux users are compiling against different library
>> versions.
>>
>> Thanks,
>> Brecht.
>>
>> On Sat, Aug 4, 2018 at 9:01 PM Bastien Montagne 
>> wrote:
>>
>>> Don’t think we are in urgent hurry here, we can give it a few more
>> weeks
>>> and see whether 3.7.1 emerges in time for us (would say dead line for
>>> libs update would be end of September?)
>>>
>>>
>>> On 03/08/2018 10:57, Sergey Sharybin wrote:
 One thing which is raising my attention in 3.7.1 release log is:

 - Fixed a performance regression for reading streams with tarfile.

 Also, 3.7.1 is planned to be released soon-ish? Their original plan
 actually mentions July, not sure what is the updated planning. Are
>> we
 really in a hurry for this update?

 On Fri, Aug 3, 2018 at 10:46 AM Sybren A. Stüvel 
>>> wrote:
> On 23/07/2018 19:43, Brecht Van Lommel wrote:
>> * Python 3.7.0 (or should we wait until there is a 3.7.1 or so
>> with
>> bugfixes?)
> Let's go to 3.7.0, unless somebody already knows of actual bugs
>> that'll
> influence our use.
>
> Sybren
>
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> https://lists.blender.org/mailman/listinfo/bf-committers
>
>>> ___
>>> Bf-committers mailing list
>>> Bf-committers@blender.org
>>> https://lists.blender.org/mailman/listinfo/bf-committers
>>>
>> ___
>> Bf-committers mailing list
>> Bf-committers@blender.org
>> https://lists.blender.org/mailman/listinfo/bf-committers
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> https://lists.blender.org/mailman/listinfo/bf-committers

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

Re: [Bf-committers] Blender Compile Error

[Ray Molenkamp]

pasteall.org is kinda  terrible for windows build logs though, since it eats 
all the forward slashes,
so you'd better use any of the other paste sites out there for those

--Ray

On 8/11/2018 2:32 PM, Sergey Sharybin wrote:
> Hi,
>
> Don't think you can attach pictures in this mailing list. It is also more
> helpful to see error messages as plain text (that how they are reported in
> the first place ;).
>
> Anyway, to share text snippets, screenshots, .blend files you can use
> pasteall.org. Or, alternatively, plain-text only hastebin.com. Send link
> here and we will have a look.
>
> That being said, i did not see visual studio ever installed incorrectly,
> unless you pull you computer power plug out for the socket during install :)
>
> On Sat, Aug 11, 2018 at 9:28 PM Ágoston Princz 
> wrote:
>
>> Hi Blender Developers
>>
>> I'm not sure that is the right place to send message like this.
>> If it is the case, please tell me where to ask about compile errors.
>>
>> Other case: I had that error message (attached picture).
>> Is it possible that Visual Studio Community Version was installed
>> incorrectly?
>>
>> Thansk a lot!
>>
>> --
>> Ágoston Princz
>> ___
>> Bf-committers mailing list
>> Bf-committers@blender.org
>> https://lists.blender.org/mailman/listinfo/bf-committers
>>
>

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

[Bf-committers] git warning?

[Ray Molenkamp]

All,

Not sure who to poke for this, but since a few days when committing through git 
push

git it now spits back a python related warning/error

k:\BlenderGit\blender>git push
Counting objects: 6, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (6/6), done.
Writing objects: 100% (6/6), 696 bytes | 696.00 KiB/s, done.
Total 6 (delta 5), reused 0 (delta 0)
remote: env: python2: No such file or directory
To git.blender.org:blender.git
   b6b6eab6ae9..2349273ade5  master -> master

The commits still go through, anyhow, someone should probably look at that?

--Ray





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

[Bf-committers] Windows lib update / merge issues to 2.8

[Ray Molenkamp]

All,

I just finished the windows lib update and kicked the 2.79 build bots, all 
seems OK.
There were a couple of cmake changes needed to adjust for some version changes 
here
and there, however I was unable to merge master to 2.8 due to some merge 
conflicts
in unrelated commits. Once master merges 2.8 should also build without problems

If there's any issues or problems, let me know and I'll resolve them.

--Ray

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

Re: [Bf-committers] Bf-committers Digest, Vol 395, Issue 1

[Ray Molenkamp]

One of the cmake defaults changed for windows, but it won't apply that change 
to already existing projects.

you can do one of two things, you either blow away your build folder and it'll 
set it right for you, or set WITH_SYSTEM_OPENJPEG to on
in cmake-gui. (or edit cmakecache.txt, or run cmake -DWITH_SYSTEM_OPENJPEG=On)

--Ray

On 8/29/2018 2:44 PM, Erick Blender wrote:
> On Tue, Aug 28, 2018 at 1:00 PM  wrote:
>
> Hi Ray
>
> Since the last svn update i m having hard building Blender2.8. Here is the
> full log -> http://pasteall.org/1123286
>
> Thank you in advance :)
>
> Message: 2
>> Date: Mon, 27 Aug 2018 20:25:20 -0600
>> From: Ray Molenkamp 
>> To: bf-blender developers 
>> Subject: [Bf-committers] Windows lib update / merge issues to 2.8
>> Message-ID: <32c56e07-59c0-beeb-c442-fc3dcc896...@lazydodo.com>
>> Content-Type: text/plain; charset=utf-8
>>
>> All,
>>
>> I just finished the windows lib update and kicked the 2.79 build bots, all
>> seems OK.
>> There were a couple of cmake changes needed to adjust for some version
>> changes here
>> and there, however I was unable to merge master to 2.8 due to some merge
>> conflicts
>> in unrelated commits. Once master merges 2.8 should also build without
>> problems
>>
>> If there's any issues or problems, let me know and I'll resolve them.
>>
>> --Ray
>>
>>
>>
>> --
>>
>> Subject: Digest Footer
>>
>> ___
>> Bf-committers mailing list
>> Bf-committers@blender.org
>> https://lists.blender.org/mailman/listinfo/bf-committers
>>
>>
>> --
>>
>> End of Bf-committers Digest, Vol 395, Issue 1
>> *
>>
> ___
> 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] hair_object Branch

[Ray Molenkamp]

The libraries for master/2.8 have been updated to newer versions, to build 
older branches
you'll need to check out libraries from around the same time the last commit 
happened
in that branch, rev62101 will probably do it for you.

--Ray

On 9/9/2018 5:36 AM, Erick Blender wrote:
> Hello Lukas,
>
> I was trying to build your branch in windows 7 gtx 550ti, i m getting build
> errors, here is a complete log file http://pasteall.org/1206714
> Is there some extra lib that you have and they are not in Blender 2.8?
>
>
> Thanks for your answers :)
> ___
> 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] OpenEXR cmake broken Re: Blender developers meeting notes - 2018-09-10

[Ray Molenkamp]

We are aware, The external dependencies build-scripts are using the autotools 
build for linux/mac for
this exact reason, for windows that was not an option, there we use the github 
hash 
0ac2ea34c8f3134148a5df4052e40f155b76f6fb which has 'somewhat' working cmake 
support,
still kinda wonky, but workable.

--Ray


On 9/10/2018 4:01 PM, bju...@ymail.com wrote:
> According to OpenEXR devs ( and my experience as well ) the cmake build of 
> OpenEXR 2.3 is broken for Linux ( possibly windows as well).
>
> OpenEXR devs are aware and noted on Aug 10 they are looking into it.
>
>
> Excerpt below copied from  
> http://lists.nongnu.org/archive/html/openexr-devel/2018-08/msg2.html  
>
> Justin Jones
>
> --
>
> El 10/08/18 a las 17:38, Francois Chardavoine escribió:
>> Just in time for Siggraph, we're excited to announce that OpenEXR 2.3
>> has been released and is available for download.
>>
> Congratulations.  Now for the sad part:
>
> CMake build is completely broken on Linux at least ( Windows probably
> too ).  IlmBase compiles the tables only and exits without compiling
> anything else.
> Building with bootstrap/configure works on Linux for IlmBase.
>
> CMake build is also broken for OpenEXR.  In that case, it does not find
> IlmBase even when -DILMBASE_PACKAGE_PREFIX is used.  Result: half.h,
> ImathInt64.h, etc cannot be found and nothing gets built.
> Building with bootstrap/configure works on Linux for OpenEXR.
>
> ___
> 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] Blender developers meeting notes - 2018-09-17

[Ray Molenkamp]

you can find the current patch at https://developer.blender.org/D3576

--Ray


On 9/17/2018 1:32 PM, Dalai Felinto wrote:
> Hi,
>
>> The Crashpad patch now works for all platforms. Interested developers are 
>> encouraged
> to test it (...)
>
> Link please? What kind of testing we are looking for? What do you mean by
> good usability?
>
> Thanks,
> Dalai
>
> On Mon, 17 Sep 2018 at 13:52 Brecht Van Lommel 
> wrote:
>
>> Hi all,
>>
>> Here are the notes from today's developer meeting. Next meeting is Monday,
>> 24 September 10:00 CEST (8:00 UTC).
>>
>> 1) New Developers
>>
>> * Welcome to the newest developer at the Blender Institute, Jacques Lucke!
>> He's known for creating Animation Nodes, and will be working on node
>> goodness in Blender. First though is getting used to the Blender C code
>> while helping finish 2.8.
>> * Welcome also to Tobias Johansson, who will be working at the Blender
>> Institute on the Blender Cloud!
>>
>> 2) Blender 2.8
>>
>> * Work continues towards the beta, lots of bugfixes and small improvements
>> this week.
>> * Various tools were updated, including poly build, smooth, randomize and
>> bisect.
>> * Grease pencil received UI tweaks and two important bugfixes related to
>> performance and "exploding" stroke thickness.
>> * The 3D viewport now draws wireframe outlines in ortho mode again.
>> * The Crashpad patch now works for all platforms. Interested developers are
>> encouraged to test it and make sure it has good usability, it would be
>> useful to help stabilizing 2.8.
>>
>> Weekly Reports:
>> * Bastien:
>>
>> https://wiki.blender.org/wiki/User:Mont29/Foundation/2018#Week_261_-_09.2F08_to_09.2F14
>> * Brecht:
>> https://wiki.blender.org/wiki/User:Brecht/Reports/2018#September_10_-_14
>> 
>> * Campbell:
>>
>> http://download.blender.org/ftp/ideasman42/donelist/2018.html#week-291-september-10
>> <
>> http://download.blender.org/ftp/ideasman42/donelist/2018.html#week-288-august-20
>> * Clément:
>>
>> https://wiki.blender.org/wiki/User:Hypersomniac/Foundation/2018#Week_88_:_10th_-_16th_Sept
>> * Sergey:
>>
>> https://wiki.blender.org/wiki/User:Hypersomniac/Foundation/2018#Week_88_:_10th_-_16th_Sept
>>
>> <
>> https://wiki.blender.org/wiki/User:Sergey/Foundation/2018#Week_352:_27th_August_-_2nd_September
>> 3) Other Projects
>>
>> * Library upgrades are now complete for all platforms. install_deps.sh on
>> Linux is still failing on some distributions due to OpenEXR, fix is
>> incoming.
>> ___
>> 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] Metal GPU support

[Ray Molenkamp]

I'm going to assume RA was build with multiple back-ends in mind, the blender 
code-base however is an old old code-base, and wasn't really designed to use 
anything other than openGL.
Although we have cleaned it up quite a bit, there are still loads of openGL 
calls and opengl-isms sprinkled all over the code base.  Before you can add a 
backend you'd have to deal with the cleanup first.

I started a cleanup a couple of months ago to wrap these calls from GL* calls 
to GPU* calls but due to the speed 2.8 was progressing at this point it was 
difficult to keep up with the daily changes, or not interfere too much with the 
eeve progress so put it on hold for a while.

To facilitate this cleanup there's the WITH_OPENGL cmake option which will 
limit the visibility of the opengl headers to pretty much just the BF_GPU 
module so any code that shouldn't be making any opengl calls will give a nice 
compiler error.

This thread may be of interest to you

https://devtalk.blender.org/t/alternative-rendering-backends/830/13

--Ray

On 12/4/2018 12:14 PM, Stuart Carnie wrote:
> Hi Blender 3D developers:
>
> Given the deprecation and poor support of OpenGL on Apple platforms, I am
> curious if there is any interest in my desire to develop Metal GPU support
> for Blender 3D?
>
> I recently implemented Metal support for RetroArch (a cross-platform
> emulator front end). Some of the highlights of RA:
>
> * supports multiple GPU back ends, including GL, Metal, Vulkan, DirectX and
> other esoteric APIs
> * a complex, shader pipeline for post-processing using a unified shader
> system of glsl shaders, some in excess of 20 passes (
> https://github.com/libretro/slang-shaders). These are cross compiled to
> target APIs such as Metal, Vulkan or DirectX using glslang and SPIRV-cross.
>
> I've had a bit of a peek at the blender 2.8 branch and imagine the place to
> start would be the GPU folder. I suspect, given the abstractions, there has
> already been some thought into multiple-GPU support and wonder if there is
> any public information on this?
>
> Cheers,
>
> Stuart
>
> *Stuart Carnie*
> ___
> 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] Metal GPU support

[Ray Molenkamp]

It's up for debate really, I'd prefer not having to maintain 5 different 
versions of all shaders , also there is a fair amount of dynamic glsl being 
generated by blender. so having something that'll take glsl and outputs 
'whatever we want' would be nice.

glslang[1] with spirvcross[2] looked interesting but I haven't spend any time 
with it, so that may or may not be a terrible idea.

--Ray

[1] https://github.com/KhronosGroup/glslang

[2] https://github.com/KhronosGroup/SPIRV-Cross


On 12/4/2018 2:10 PM, Stuart Carnie wrote:
> Ray:
>
> Thank you for the reply. It sounds like there is an interest in supporting
> multiple back-ends, which is exciting.
>
> With regards to the cleanup, it sounds like the current goal is to replace
> any GL calls with GPU_* calls outside the GPU folders. I'd be happy to
> contribute to that cleanup.
>
> Is the desire to support multiple back ends natively, with their own set of
> shaders or to take an approach similar to RA or bgfx (
> https://bkaradzic.github.io/bgfx/overview.html) and use a unified shader
> model. The former is simpler for consumers of the GPU_* APIs, as they only
> need to provide a single set of shaders, but it does mean that offline
> compilation and other optimizations may be limited.
>
> I will also take a look at the thread you shared.
>
> Cheers,
>
> *Stuart Carnie*
>
>
> On Tue, Dec 4, 2018 at 1:14 PM Ray Molenkamp  wrote:
>
>> I'm going to assume RA was build with multiple back-ends in mind, the
>> blender code-base however is an old old code-base, and wasn't really
>> designed to use anything other than openGL.
>> Although we have cleaned it up quite a bit, there are still loads of
>> openGL calls and opengl-isms sprinkled all over the code base.  Before you
>> can add a backend you'd have to deal with the cleanup first.
>>
>> I started a cleanup a couple of months ago to wrap these calls from GL*
>> calls to GPU* calls but due to the speed 2.8 was progressing at this point
>> it was difficult to keep up with the daily changes, or not interfere too
>> much with the eeve progress so put it on hold for a while.
>>
>> To facilitate this cleanup there's the WITH_OPENGL cmake option which will
>> limit the visibility of the opengl headers to pretty much just the BF_GPU
>> module so any code that shouldn't be making any opengl calls will give a
>> nice compiler error.
>>
>> This thread may be of interest to you
>>
>> https://devtalk.blender.org/t/alternative-rendering-backends/830/13
>>
>> --Ray
>>
>> On 12/4/2018 12:14 PM, Stuart Carnie wrote:
>>> Hi Blender 3D developers:
>>>
>>> Given the deprecation and poor support of OpenGL on Apple platforms, I am
>>> curious if there is any interest in my desire to develop Metal GPU
>> support
>>> for Blender 3D?
>>>
>>> I recently implemented Metal support for RetroArch (a cross-platform
>>> emulator front end). Some of the highlights of RA:
>>>
>>> * supports multiple GPU back ends, including GL, Metal, Vulkan, DirectX
>> and
>>> other esoteric APIs
>>> * a complex, shader pipeline for post-processing using a unified shader
>>> system of glsl shaders, some in excess of 20 passes (
>>> https://github.com/libretro/slang-shaders). These are cross compiled to
>>> target APIs such as Metal, Vulkan or DirectX using glslang and
>> SPIRV-cross.
>>> I've had a bit of a peek at the blender 2.8 branch and imagine the place
>> to
>>> start would be the GPU folder. I suspect, given the abstractions, there
>> has
>>> already been some thought into multiple-GPU support and wonder if there
>> is
>>> any public information on this?
>>>
>>> Cheers,
>>>
>>> Stuart
>>>
>>> *Stuart Carnie*
>>> ___
>>> Bf-committers mailing list
>>> Bf-committers@blender.org
>>> https://lists.blender.org/mailman/listinfo/bf-committers
>> ___
>> Bf-committers mailing list
>> Bf-committers@blender.org
>> https://lists.blender.org/mailman/listinfo/bf-committers
>>
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> https://lists.blender.org/mailman/listinfo/bf-committers
___
Bf-committers mailing list
Bf-committers@blender.org
https://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Update openCollada to 1.6.68

[Ray Molenkamp]

done for windows

--Ray

On 12/5/2018 2:54 AM, Gaia Clary wrote:
> Hi, Platform maintainers :)
>
> Please update the subversion repository libraries to OpenCollada 1.6-68
> This allows us to add support for importing Animation clips.
>
> The Release sources recommended by OpenCollada can be found here:
>
> https://s3-us-west-2.amazonaws.com/opencollada-promotion-artifacts/OpenCOLLADA_v1.6.68.zip
>
> Or if you prefer to go with the git repository, the tagged revision is here:
>
>    https://github.com/KhronosGroup/OpenCOLLADA/tree/v1.6.68
>
> The git hash is 6031fa956e1da4bbdd910af3a8f9e924ef0fca7a
>
> Please tell me if anything around the library build needs improvement. I then 
> will forward this to the opencollada people :)
>
> cheers,
> Gaia
> ___
> 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] Error after Updates to developer/git/svn/buildbot

[Ray Molenkamp]

Same issue here,

anonymous usage seems to work

git clone git://git.blender.org/blender.git

works, however authenticated users

git clone g...@git.blender.org:blender.git

fail with the error mentioned earlier

--Ray


On 2/2/2019 10:30 AM, Howard Trickey wrote:
> Happens for me too. git pull from origin/master of blender repository
>
>
> On Sat, Feb 2, 2019 at 12:14 PM Sergey Sharybin 
> wrote:
>
>> Hi,
>>
>>> util.mkdir(p, 0750)
>> AFAIK, this should be 0o750 for Python3. The code seems to be from
>> gitsosis, which we use from an upstream.
>>
>> What is more weird is that for me `git pull` works fine. Does this still
>> happen for you? Which exact repo causes the issue?
>>
>> On Sat, Feb 2, 2019 at 5:15 PM blendergit  wrote:
>>
>>> Hi,
>>>
>>> Not sure if you have completed the update, but today when I try to run
>>> “git pull”, I get this:
>>>
>>> $ git pull
>>> Traceback (most recent call last):
>>>   File "/usr/local/bin/gitosis-serve", line 11, in 
>>> load_entry_point('gitosis==0.2', 'console_scripts',
>> 'gitosis-serve')()
>>>   File
>> "/usr/local/lib/python3.6/site-packages/pkg_resources/__init__.py",
>>> line   487, in load_entry_point
>>> return get_distribution(dist).load_entry_point(group, name)
>>>   File
>> "/usr/local/lib/python3.6/site-packages/pkg_resources/__init__.py",
>>> line   2728, in load_entry_point
>>> return ep.load()
>>>   File
>> "/usr/local/lib/python3.6/site-packages/pkg_resources/__init__.py",
>>> line   2346, in load
>>> return self.resolve()
>>>   File
>> "/usr/local/lib/python3.6/site-packages/pkg_resources/__init__.py",
>>> line   2352, in resolve
>>> module = __import__(self.module_name, fromlist=['__name__'], level=0)
>>>   File "/usr/local/lib/python3.6/site-packages/gitosis/serve.py", line
>> 142
>>> util.mkdir(p, 0750)
>>>  ^
>>> SyntaxError: invalid token
>>> fatal: Could not read from remote repository.
>>>
>>> Please make sure you have the correct access rights
>>> and the repository exists.
>>>
>>> I’m running on Windows 10.
>>>
>>> Regards,
>>> Antonio Vázquez
>>>
>>> De: Dan McGrath
>>> Enviado: sábado, 2 de febrero de 2019 12:45
>>> Para: bf-blender developers
>>> Asunto: [Bf-committers] Updates to developer/git/svn/buildbot
>>>
>>> Hi,
>>>
>>> Just a heads up that today I upgraded the following sites to the latest
>>> 2019Q1 ports in FreeBSD:
>>>
>>>   - developer.blender.org
>>>   - git.blender.org
>>>   - svn.blender.org
>>>   - builder.blender.org
>>>
>>> As well, the Phabricator (developer.b.o) PHP was upgraded from PHP 5.6 to
>>> 7.2. Overall the site seems nice and zippy when doing cached pages, but
>>> otherwise, keep an eye out for horrible stuff!
>>>
>>> Also, if it's good, nice! But if it breaks, it wasn't me that touched
>>> anything, and is all Sergey Sharybin's fault! ><
>>>
>>> At some point the host will go down for a FreeBSD upgrade from 11 to 12.
>>> Probably on Monday or so, I will let you know here.
>>>
>>>
>>> Cheers,
>>>
>>> Dan
>>> ___
>>> Bf-committers mailing list
>>> Bf-committers@blender.org
>>> https://lists.blender.org/mailman/listinfo/bf-committers
>>>
>>> ___
>>> Bf-committers mailing list
>>> Bf-committers@blender.org
>>> https://lists.blender.org/mailman/listinfo/bf-committers
>>>
>>
>> --
>> With best regards, Sergey Sharybin
>> ___
>> Bf-committers mailing list
>> Bf-committers@blender.org
>> https://lists.blender.org/mailman/listinfo/bf-committers
>>
> ___
> 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] Blender 2.79 Nightly builds using different Python versions

[Ray Molenkamp]

https://svn.blender.org/svnroot/bf-blender/tags/

--Ray

On 3/15/2019 11:20 AM, Jacob Merrill wrote:
> it would be slick though to saved the SVN timestamp / revision for old
> releases somewhere.
>
>
___
Bf-committers mailing list
Bf-committers@blender.org
https://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Can not build blender 2.7 branch

[Ray Molenkamp]

Should build now.

--Ray

On 4/9/2019 11:20 AM, wodec wrote:
> System Information
> Operating system: windows 10
> Graphics card: Nvidia Geforce GTX 1050Ti
>
> Short description of error
> Can not build blender 2.7 branch, (windows VS2017 and Cmake 3.14.1 ), compile 
> error (C2220)
>
>
>
> ---
> Diese E-Mail wurde von Avast Antivirus-Software auf Viren geprüft.
> https://www.avast.com/antivirus
>
> ___
> 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] clang-format in master

[Ray Molenkamp]

vc 2017 ships with clang-format 6.0.0, 2019 ships with 7.0.0
judging from the 6.0.0 release notes[1] this should have worked?

Also I don't remember ever seeing that error.

We ship 6.0.1 with our libs, what you can try is, go into

Tools->Options->Text Editor->C/C++->Formatting->General

Near the bottom of that list should be an option to browse
to a custom clang-format, pick the one from the libs folder
(win64_vc14/llvm/bin/clang-format)

does that re-solve the issue for you?

--Ray

[1] 
https://releases.llvm.org/6.0.0/tools/clang/docs/ReleaseNotes.html#clang-format



On 4/18/2019 9:28 AM, Harley Acheson wrote:
> Campbell,
>
> When using Microsoft Visual Studio (Enterprise 2017 15.7.3), it does
> automatically pick up
> that clang is in force. It brings up a dialog box saying that "a
> clang-format file was found
> in your codebase."
>
> However, doing any operations at all it shows that "an Error occurred while
> formatting with
> ClangFormat" with specifics of "YAML:81:21: error: unknown key
> 'IndentPPDirectives'
>
> I read somewhere that "IndentPPDirectives" is relatively new (with LLVM6)
> so perhaps I need
> to update something. No panic here though as I am not in danger of needing
> to submit anything
> right away.
>
> Yes, I can submit this as a bug if preferred.
>
> Cheers, Harley
> ___
> 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] Potentially moving from IRC to Blender.Chat

[Ray Molenkamp]

On 5/1/2019 5:18 AM, Pablo Vazquez wrote:
> You still need to create an account on freenode to chat in blendercoders.

You don't, we temporary turned that on a while ago when a botnet was
wreaking havoc on freenode, but in general that option is off and any
user registered or not can join and talk in #blendercoders

--Ray

On 5/1/2019 5:18 AM, Pablo Vazquez wrote:
>> - is wasting space when not logged in (It can be changed to "condensed
>> mode" but only when logged in it apears)
>>
> Compact view can be set to default if enough people agree.
>
>
>> - is slow: [1]
>>
> The version live in production now was right before an improvement that
> speeds up the load/opening of rooms quite substantially, we just need to
> update the docker image.
> https://github.com/RocketChat/Rocket.Chat/pull/13417#issue-251549810
>
>
>> - is big: 4.3 MB for a simple chat app [2]
>>
> I'd trade a couple of MBs for built-in attachments, screen-sharing, video
> conferencing, audio message, email notifications, etc.
>
>
>> - is increasing the barrier to entry. Previously you could just use the
>> freenode web service to chat. Now you need to register for an account
>>
> You still need to create an account on freenode to chat in blendercoders.
> All you need in blender.chat is a Blender ID account which most Blender
> users have made for sites like devtalk, cloud, fund or network.
>
>
>> - has no mobile app for my phone version
>>
> It's available on Android and iOS.
>
>
>> - rocket.chat has 1.9k open issues on github, while IRC is battle-tested
>>
> Maybe you don't know how GitHub issues work? It's a bunch of tasks with
> labels. 355 of those are marked as bugs, some as design, some as feature
> proposals from 2015.
>
>
>> Also consider that there are people with slow phones/slow connections.
>> People who want better UI can always use riot.im, irccloud or any similar
>> service.
>>
> We looked into matrix when we started blender.chat over a year ago and it
> just didn't feel mature enough. Riot looks a lot better now than it did a
> year ago, I wouldn't mind giving it a try if there is people willing to
> help setting it up (rocket chat is literally just pulling a docker image).
> I personally don't mind if it's rocket chat or riot or whatever, I just
> like how much more accessible these apps make it to more people (there's a
> reason why people use Slack, Discord, etc.).
>
> Blender forums used phpBB, but we moved to Discourse.
> blender.org with Typo3 was fine, we moved to Wordpress.
> Remember projects.blender.org? we moved to Phabricator.
> We went from CVS to SVN to git.
>
> Moving *some* communication channels from IRC to something more media
> friendly for a 3D software shouldn't be so shocking.
> ___
> 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] Libraries update: OpenSubdiv 3.4 RC2

[Ray Molenkamp]

Windows libs has been updated.

--Ray

On 6/27/2019 7:46 AM, Sergey Sharybin wrote:
> Hi,
>
> This is a request for platform maintainers to update OpenSubdiv library to
> 3.4 RC2. All the needed changes are done to versions.cmake.
>
> The update is needed to bring fixes for non-manifold and non-regular
> meshes, which allows us to solve several reports in the tracker.
>
> Unfortunately, the final release is not yet available, but there no much
> changes is expected and we'd better do such rather intrusive changes as
> early as possible.
>
___
Bf-committers mailing list
Bf-committers@blender.org
https://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Blender 2.80 Release Candidate 1 AHOY

[Ray Molenkamp]

I hit a snag building win32, it's trying to build cubins and
failing at it, I have a vague memory of cubins being disabled
for 32 bit builds? Is this still the case?

--Ray
On 7/10/2019 10:24 AM, Sergey Sharybin wrote:
> Correction for the git branch: blender-v2.80-release
>
> Sorry for the noise and confusion.
>
> On Wed, Jul 10, 2019 at 6:16 PM Sergey Sharybin 
> wrote:
>
>> Hi,
>>
>> We are ready for the first Release Candidate for Blender 2.80 release.
>>
>> Information for platform maintainers:
>>
>> - Build from the blender-2.80-release branch, SHA
>> 3fe0c32fae20be4146bfa20fe64f56f5716a132b
>> - Addons revision: f54338c63ba36cbbe83161c0b3d4d2b1aa01c4a9
>> - Locale revision: 38e501b4d7a37d2db0f48d47bdb07c57f3fb9a0d
>> - Libraries SVN tag: blender-2.80-release
>>
>> Suggested name: blender-2.80rc1-.
>>
>> Put builds to usual location and let me know when they are ready.
>> Tagging will happen soon after all builds are ready.
>>
>> Thanks everybody for the hard work!
>>
>> --
>> With best regards, Sergey Sharybin
>>
>
___
Bf-committers mailing list
Bf-committers@blender.org
https://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Blender 2.80 Release Candidate 1 AHOY

[Ray Molenkamp]

After a small consult with sergey, cubins are indeed off for X86
and WITH_CYCLES_CUDA_BINARIES has been manually turned off for
win32 for now.

I struggled with ftp from behind nat, but I think both builds made
it, in-case they didn't I left sergey a link to a  copy on my webhosting.

MD5 for both builds:

E8D4B54EBEFC2ACF93C76560E4A26851  blender-2.80rc1-windows32.zip
F4BA141E119583C5DB520565FF71DA5D  blender-2.80rc1-windows64.zip

Tests:

Win32 fails bmesh_boolean which is a known (T65143) and accepted issue
Win64 had a 100% pass rate.

However

@deadpin on chat correctly pointed out that the object_modifier_array
test while passing really shouldn't (this is for both win64 and win32)

49: Read blend: 
K:/BlenderGit/blender/../lib/tests/modifier_stack/array_test.blend
49:
49: Error: text block not found run_tests.
49:
49: Blender quit
[HANDLER_OUTPUT]
 49/103 Test  #49: object_modifier_array ...
   Passed    4.74 sec
[HANDLER_VERBOSE_OUTPUT]

--Ray

On 7/10/2019 12:30 PM, Ray Molenkamp wrote:
> I hit a snag building win32, it's trying to build cubins and
> failing at it, I have a vague memory of cubins being disabled
> for 32 bit builds? Is this still the case?
>
> --Ray
> On 7/10/2019 10:24 AM, Sergey Sharybin wrote:
>> Correction for the git branch: blender-v2.80-release
>>
>> Sorry for the noise and confusion.
>>
>> On Wed, Jul 10, 2019 at 6:16 PM Sergey Sharybin 
>> wrote:
>>
>>> Hi,
>>>
>>> We are ready for the first Release Candidate for Blender 2.80 release.
>>>
>>> Information for platform maintainers:
>>>
>>> - Build from the blender-2.80-release branch, SHA
>>> 3fe0c32fae20be4146bfa20fe64f56f5716a132b
>>> - Addons revision: f54338c63ba36cbbe83161c0b3d4d2b1aa01c4a9
>>> - Locale revision: 38e501b4d7a37d2db0f48d47bdb07c57f3fb9a0d
>>> - Libraries SVN tag: blender-2.80-release
>>>
>>> Suggested name: blender-2.80rc1-.
>>>
>>> Put builds to usual location and let me know when they are ready.
>>> Tagging will happen soon after all builds are ready.
>>>
>>> Thanks everybody for the hard work!
>>>
>>> --
>>> With best regards, Sergey Sharybin
>>>
> ___
> 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] Blender 2.80 Release Candidate 2 AHOY

[Ray Molenkamp]

Windows builds are uploaded

26FDFFEB04530C3D2C049DB0EFF7AC27 blender-2.80rc2-windows32.zip
93E91393E031734DD338E240A1C9E5E6 blender-2.80rc2-windows64.zip

Testing situation is identical to rc1.

--Ray


On 7/18/2019 8:58 AM, Brecht Van Lommel wrote:
> Hi all,
>
> We are ready for the second Release Candidate for the Blender 2.80 release.
>
> Information for platform maintainers:
>
> - Build from the blender-v2.80-release branch, SHA
> 38d4483c6a51d70744d5e146dc87f5da8558448d
> - Addons revision: 979298511916b25ec97bb22feb1c06cc9fbc86dd
> - Locale revision: 6625026f62f492dd677f5f29c68b9d70c96fb34b
> - Libraries SVN tag: blender-2.80-release
>
> Suggested name: blender-2.80rc2-.
>
> Put builds to the usual location and let me know when they are ready.
> Tagging will happen soon after all builds are ready.
>
> Thanks,
> Brecht.
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> https://lists.blender.org/mailman/listinfo/bf-committers
___
Bf-committers mailing list
Bf-committers@blender.org
https://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Blender 2.80 Release Candidate 3 AHOY

[Ray Molenkamp]

Windows builds are done, Dan pointed out we really shouldn't be using MD5 
anymore
so here's the SHA-512 hashes for the files.

blender-2.80rc3-windows64.zip 
4A38C0B1B06E9D658FC178DB0CEFD51D0536056DDC5115863EB6A94D8FF7C0930C5E73EF9F2261F8FDBAAD3568FB5EAAC42F156E6B548B9B4173F4A3B1203A5F
blender-2.80rc3-windows32.zip 
8F86B13CF59ADDDE8B2BED9A4BAB2A43C491BA8E3486CE0B2F4024917BA71C1AE08B6103255F11F17BDFDFF48EBD53D475A595E1599882E25DCB2F130EC2686D

tests results are identical to the earlier RC's

--Ray


On 2019-07-24 8:47 a.m., Brecht Van Lommel wrote:
> 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: 63f65770e67f38db29f76ac910dd87bd9841b919
> - Libraries SVN tag: blender-2.80-release
>
> Suggested name: blender-2.80rc3-.
>
> Tagging will happen soon after all builds are ready.
>
> Thanks,
> Brecht.
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> https://lists.blender.org/mailman/listinfo/bf-committers
___
Bf-committers mailing list
Bf-committers@blender.org
https://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Blender 2.8x - support and core development goals

[Ray Molenkamp]

Being a windows platform dev this could pretty much be a list called
'things nobody will get exited about' but here's my plans/wish-list
regardless

If I get nothing else, I hope it's this one (2.81):

I think the most important one for stability is having working automated
crash reporting, being able to see the top 10 reasons why people lose work
and proactively fix them should go a long way in improving the end-user
experience.

I Have the client side code for win/linux is in a workable state,
arto will have to take another look at the mac side since I'm pretty
sure I broke that when I merged it from 2.7 to master. Nathan is
looking into the server side of things. (D3576)

Nice to haves (not attached to a release target):

1) I'd like to see the unit tests run nightly on BF infrastructure
(I currently run them nightly on azure, but we cannot run the opengl based
tests on there) but this is something the people at the institute need to work 
on.
(Already on the list in T66306)

2) Cycles unit tests:
Currently the cycles unit tests only test the kernel most appropriate for the
host it runs on, small differences errors between architectures have been
slipping though our test suite. All render tests should run on all kernels
we build. If nobody picks this up I'll have stab at it.
(not yet on the list in T66306, but probably should be there)

Developer experience (not attached to a release target)

1) I'm planning some small tweaks to the build helper scripts on windows
to give developers some features that have been asking for like being
able to specify an absolute path for the build folder. I'm open for
other suggestions/improvements here.

2) Enable JMC for compilers that support it

JMC [1] drastically cuts down the time you spend stepping though boiler plate 
C++
code in the debugger, once master gets unfrozen I'll enable this for debug 
builds
on VS2019.

3) Developer profile.

Not my work, but i'd like to see brechts D5149 land sooner than later, just to 
get
rid of some of the annoyances like buildinfo being on for developers by default
leading to constant rebuilds which leads to less productive developers. (D5149)

4) Rewrite the build instructions for windows.

The wiki could use a refresher, some things can be clarified better, other 
things
can be skipped all together since the build scripts take care of it now-days.

I have been dragging my heels on this.

Libs 2.81:

I'm mostly following here, If you want/need a dep update for your module speak 
up!

1) Python, I heard talk about a python version bump a while ago (but never saw 
the
official request to bump it), also I have to repackage python on windows so
`make format` can use it and we longer have to rely on a system python being
installed, so these things will probably go together.
(not yet on any list I'm aware of)

2) USD will need to be scripted and packaged if sybren wants to get USD into 
2.81, I have
this partially done already, but USD on windows is having an 'unhappy time', 
officially the
windows support is experimental so our success may vary on this. The code 
builds and links
but doesn't work due some plugin registration issues inside USD. I haven't 
found  the time
to debug this yet. (not yet on any list I'm aware of)

3) Removal of 32 bit support.

Finally! (T67184)

Libs Longer term:

I've heard from multiple devs that dealing with deps is a pain, they just 
randomly sprinkle
includes and linker commands until the errors go way, that's a great use of 
their time.

While moving all of blender to a modern target based cmake style may be out of 
reach,
I think we can do this for the deps integration without causing too much 
trouble.
(not yet on any list i'm aware of)

--Ray


[1] 
https://devblogs.microsoft.com/cppblog/announcing-jmc-stepping-in-visual-studio/

On 2019-07-26 12:00 a.m., Dalai Felinto wrote:
> Dear developers,
>
> Which areas would you like to focus on in the next few months? Which
> code improvements, performance, stability, new features in those areas
> would you work on first [1]?
>
> Finally which bigger new features are you confident would make it in
> the 2.81 release, and which are the ones that might happen? These are
> particularly important so we can allocate more time for code review
> early in the release cycle and work together to assess their
> feasibility.
>
> That should empower us to set priorities and keep our ongoing
> development on track. The original goal of a more strict 2-3 month
> release cycle is still on the table, and it is up to us to set dates
> the deliverables. As long as we are working in the right priorities,
> and strive for quality, which specific features land in 2.81 are
> secondary.
>
> I'm away for Siggraph (28-1) so there is no need to rush to reply to this.
>
> [1] - Please update the module page to reflect this -
> https://wiki.blender.org/wiki/Modules /
> https://developer.blender.org/T63725
>
> Best regards,
> Dalai
> ___
> B

Re: [Bf-committers] Blender 2.80 Release AHOY

[Ray Molenkamp]

Windows builds are done,

SHA-512 hashes

blender-2.80-windows32.zip 
904FC1682638BA0A28C1F82E050F8C11D9B8AEC4F398FFC692613D3BF09C6AF755E84C2406330F30284EEF64A8BB0E932EC11FB844D7AEA136F1B0434F8B8769
blender-2.80-windows32.msi 
3E0A50EE85AC1B2365711279E94458F24D13DC7E5A62D7657948C608E5806509D4C9CCBA88CB89C5BB7BD9A84E7CDE90C35925C623D53B3554190727263EFA71
blender-2.80-windows64.zip 
C94DEB183589D123A3D4DE34DE7D935CF44386D404E9D907780FF22BE580A2C1865BE4709F9D6AA7B76D0212231FEF817605908DAB66F9CC1FF4778E6A0C5C6A
blender-2.80-windows64.msi 
A5D69E9BC853DDA4A1965D149CBF5CD617DF806DDC8AF4E851B253578CA2B7921629EA1ED1345143C60479992F9DDA1C3A50C88F999AB9C8420BCCF0B0FC2E95

--Ray

On 2019-07-29 8:53 a.m., Brecht Van Lommel wrote:
> 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: a467f38d0c668083ee3774eb1e9491793ff30d05
> - Libraries SVN tag: blender-2.80-release
>
> Suggested name: blender-2.80-.
>
> Tagging will happen soon after all builds are ready.
>
> Thanks,
> Brecht.
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> https://lists.blender.org/mailman/listinfo/bf-committers
___
Bf-committers mailing list
Bf-committers@blender.org
https://lists.blender.org/mailman/listinfo/bf-committers

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

[Ray Molenkamp]

All,

Took a bit, but the windows libs have been updated, couple of note worthy 
things:

First: After a brief consult with sybren, the site packages have been
updated to the following versions:

IDNA 2.8
CHARDET  3.0.4
URLLIB3  1.25.3
CERTIFI  2019.6.16
REQUESTS 2.22.0
NUMPY    1.17.0

Second : To support running 'make format' without having to be depended
on a system python being installed on windows, the packaging for python
had to be significantly changed. There now is a runnable python in the
lib folder rather than tarballs. 

All tests are still passing, so I'm not expecting a whole lot of problems
however if any do show-up because of this change, please let me know asap.

Third: I left the old python packaging in SVN for now so it will not
disturb any branches dependent on the old packaging method, however,
these old versions will be removed in the future, so be sure to merge
master sooner rather than later if you are working in a branch.

Greetings,
Ray
On 2019-08-02 8:55 a.m., 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
>
>
___
Bf-committers mailing list
Bf-committers@blender.org
https://lists.blender.org/mailman/listinfo/bf-committers

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

[Ray Molenkamp]

On 2019-11-08 1:37 a.m., dr. Sybren A. Stüvel wrote:

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

I don't think we have official rules about this but
the un-official one I have been using for years is:

Module owners what rely on a dependency can integrate
newer versions and ask for an update of a dep once they
are done on bf-c and the platform devs will take care
of the rest. Previous examples [1][2][3]

That being said the integration *has* to be done by the
module teams, the platform devs just don't/can't know
every single implementation detail of the 30-40 deps we
rely on.

Sometimes we get patches that include lib building
support (like embree) which is appreciated but by no means
required, odds are the platform devs for a platform
are better and quicker at scripting deps than a dev
that has never developed on said platform.

So the barrier for lib updates is a low as I can make it
all you have to do is test the new version works, and ask.

Given we are formalizing lots of things, perhaps now
that module teams are more established we should
assign responsibly for the deps they require to them?

--Ray

[1] https://lists.blender.org/pipermail/bf-committers/2018-December/049691.html
[2] https://lists.blender.org/pipermail/bf-committers/2019-June/050006.html
[3] https://lists.blender.org/pipermail/bf-committers/2019-August/050119.html
___
Bf-committers mailing list
Bf-committers@blender.org
https://lists.blender.org/mailman/listinfo/bf-committers

[Bf-committers] Windows lib changes

[Ray Molenkamp]

All,

Since the beginning of time we have always used a
weird mix of using the static C runtime for some
parts of blender while using the dynamic runtime
for others.

No-one exactly remembers how this came to be, but
what was clear that mixing runtimes is 'not great'
and that it eventually would cause issues, which
it recently did [1]

Today I'm cleaning it up and switching blender
over to the dynamic runtime on windows.

Now sadly this requires a whole new library set
so if you are building blender on windows you may
have some hiccups and unfortunately a large download.

Ideally you'd run 'make update' *twice* and it will
sort it self out. (Once to get the updated make.bat
that knows about the new libs, and a second time to
actually grab them)

However there are some side cases where people
did not follow our building guide and/or systems
where cmake just behaved oddly, so here is a list of
oddities you may run into and how to resolve them.

1) I get a build error along the lines of:

Windows requires pre-compiled libs at: 
'c:/blender-git/blender/../lib/win64_vc15'.
Please run make update in the blender source folder to obtain them.

Solution:

Do what it says, if "make update" does not work for you, see 2

2) I checked out the libraries my self, I don't have SVN
in my path and/or "make update" does not work for me.

It happens, not everybody is following our building
instructions [2] for various reasons, and some environments
just don't seem to play nice with our scripts.

Solution:

You can check out the new set of libraries manually from

https://svn.blender.org/svnroot/bf-blender/trunk/lib/win64_vc15

just make sure they and up in the next to the win64_vc14 folder
you currently have and it should work.

3) I have a linker error mentioning a RuntimeLibrary mismatch

These generally come in the form of:

'RuntimeLibrary': value 'MTd_StaticRelease' doesn't match value 
'MDd_DynamicRelease' in [somefile]

This seems to be coming from CMake not always picking
up on changes in the platform settings.

Solution:

Remove your build folder and start a fresh build

4) MSVC 2015

MSVC2015 has been superseded by 2 newer versions both
available for free, 2015 support will be dialed back
to the same level as 32 bit support. We don't test it
nor supply libraries for it anymore, however if you
have your own set of libraries and have patches that
help with vs2015 specific issues you are always
welcome to submit those.

Solution: Update to vs2017 or vs2019

5) I have a branch that has not merged this change yet.

That's OK, the static vc14 libraries will be available
for some time. However no further updates will be done
to them.

Special acknowledgments:

Thanks to @Harleya and @deadpin on chat for helping test
so we could have an as smooth as possible transition to
the new libs.

[1] https://developer.blender.org/D5387#122165
[2] https://wiki.blender.org/wiki/Building_Blender/Windows

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

Re: [Bf-committers] Windows lib changes

[Ray Molenkamp]

So... that broke the windows build bot, if anyone with access
to the windows bot could check out the libs that be great!
 
 --Ray

On 2019-11-08 9:02 a.m., Ray Molenkamp wrote:
> All,
>
> Since the beginning of time we have always used a
> weird mix of using the static C runtime for some
> parts of blender while using the dynamic runtime
> for others.
>
> No-one exactly remembers how this came to be, but
> what was clear that mixing runtimes is 'not great'
> and that it eventually would cause issues, which
> it recently did [1]
>
> Today I'm cleaning it up and switching blender
> over to the dynamic runtime on windows.
>
> Now sadly this requires a whole new library set
> so if you are building blender on windows you may
> have some hiccups and unfortunately a large download.
>
> Ideally you'd run 'make update' *twice* and it will
> sort it self out. (Once to get the updated make.bat
> that knows about the new libs, and a second time to
> actually grab them)
>
> However there are some side cases where people
> did not follow our building guide and/or systems
> where cmake just behaved oddly, so here is a list of
> oddities you may run into and how to resolve them.
>
> 1) I get a build error along the lines of:
>
> Windows requires pre-compiled libs at: 
> 'c:/blender-git/blender/../lib/win64_vc15'.
> Please run make update in the blender source folder to obtain them.
>
> Solution:
>
> Do what it says, if "make update" does not work for you, see 2
>
> 2) I checked out the libraries my self, I don't have SVN
> in my path and/or "make update" does not work for me.
>
> It happens, not everybody is following our building
> instructions [2] for various reasons, and some environments
> just don't seem to play nice with our scripts.
>
> Solution:
>
> You can check out the new set of libraries manually from
>
> https://svn.blender.org/svnroot/bf-blender/trunk/lib/win64_vc15
>
> just make sure they and up in the next to the win64_vc14 folder
> you currently have and it should work.
>
> 3) I have a linker error mentioning a RuntimeLibrary mismatch
>
> These generally come in the form of:
>
> 'RuntimeLibrary': value 'MTd_StaticRelease' doesn't match value 
> 'MDd_DynamicRelease' in [somefile]
>
> This seems to be coming from CMake not always picking
> up on changes in the platform settings.
>
> Solution:
>
> Remove your build folder and start a fresh build
>
> 4) MSVC 2015
>
> MSVC2015 has been superseded by 2 newer versions both
> available for free, 2015 support will be dialed back
> to the same level as 32 bit support. We don't test it
> nor supply libraries for it anymore, however if you
> have your own set of libraries and have patches that
> help with vs2015 specific issues you are always
> welcome to submit those.
>
> Solution: Update to vs2017 or vs2019
>
> 5) I have a branch that has not merged this change yet.
>
> That's OK, the static vc14 libraries will be available
> for some time. However no further updates will be done
> to them.
>
> Special acknowledgments:
>
> Thanks to @Harleya and @deadpin on chat for helping test
> so we could have an as smooth as possible transition to
> the new libs.
>
> [1] https://developer.blender.org/D5387#122165
> [2] https://wiki.blender.org/wiki/Building_Blender/Windows
>
> ___
> 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] Windows lib changes

[Ray Molenkamp]

fixed make_update.py ! however the mac and windows buildbots seem to have gone 
awol so can't test.

--Ray

On 2019-11-08 4:26 p.m., Brecht Van Lommel wrote:
> 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
>>
>> On 2019-11-08 9:02 a.m., Ray Molenkamp wrote:
>>> All,
>>>
>>> Since the beginning of time we have always used a
>>> weird mix of using the static C runtime for some
>>> parts of blender while using the dynamic runtime
>>> for others.
>>>
>>> No-one exactly remembers how this came to be, but
>>> what was clear that mixing runtimes is 'not great'
>>> and that it eventually would cause issues, which
>>> it recently did [1]
>>>
>>> Today I'm cleaning it up and switching blender
>>> over to the dynamic runtime on windows.
>>>
>>> Now sadly this requires a whole new library set
>>> so if you are building blender on windows you may
>>> have some hiccups and unfortunately a large download.
>>>
>>> Ideally you'd run 'make update' *twice* and it will
>>> sort it self out. (Once to get the updated make.bat
>>> that knows about the new libs, and a second time to
>>> actually grab them)
>>>
>>> However there are some side cases where people
>>> did not follow our building guide and/or systems
>>> where cmake just behaved oddly, so here is a list of
>>> oddities you may run into and how to resolve them.
>>>
>>> 1) I get a build error along the lines of:
>>>
>>> Windows requires pre-compiled libs at:
>> 'c:/blender-git/blender/../lib/win64_vc15'.
>>> Please run make update in the blender source folder to obtain them.
>>>
>>> Solution:
>>>
>>> Do what it says, if "make update" does not work for you, see 2
>>>
>>> 2) I checked out the libraries my self, I don't have SVN
>>> in my path and/or "make update" does not work for me.
>>>
>>> It happens, not everybody is following our building
>>> instructions [2] for various reasons, and some environments
>>> just don't seem to play nice with our scripts.
>>>
>>> Solution:
>>>
>>> You can check out the new set of libraries manually from
>>>
>>> https://svn.blender.org/svnroot/bf-blender/trunk/lib/win64_vc15
>>>
>>> just make sure they and up in the next to the win64_vc14 folder
>>> you currently have and it should work.
>>>
>>> 3) I have a linker error mentioning a RuntimeLibrary mismatch
>>>
>>> These generally come in the form of:
>>>
>>> 'RuntimeLibrary': value 'MTd_StaticRelease' doesn't match value
>> 'MDd_DynamicRelease' in [somefile]
>>> This seems to be coming from CMake not always picking
>>> up on changes in the platform settings.
>>>
>>> Solution:
>>>
>>> Remove your build folder and start a fresh build
>>>
>>> 4) MSVC 2015
>>>
>>> MSVC2015 has been superseded by 2 newer versions both
>>> available for free, 2015 support will be dialed back
>>> to the same level as 32 bit support. We don't test it
>>> nor supply libraries for it anymore, however if you
>>> have your own set of libraries and have patches that
>>> help with vs2015 specific issues you are always
>>> welcome to submit those.
>>>
>>> Solution: Update to vs2017 or vs2019
>>>
>>> 5) I have a branch that has not merged this change yet.
>>>
>>> That's OK, the static vc14 libraries will be available
>>> for some time. However no further updates will be done
>>> to them.
>>>
>>> Special acknowledgments:
>>>
>>> Thanks to @Harleya and @deadpin on chat for helping test
>>> so we could have an as smooth as possible transition to
>>> the new libs.
>>>
>>> [1] https://developer.blender.org/D5387#122165
>>> [2] https://wiki.blender.org/wiki/Building_Blender/Windows
>>>
>>> ___
>>> Bf-committers mailing list
>>> Bf-committers@blender.org
>>> https://lists.blender.org/mailman/listinfo/bf-committers
>> ___
>> Bf-committers mailing list
>> Bf-committers@blender.org
>> https://lists.blender.org/mailman/listinfo/bf-committers
>>
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> https://lists.blender.org/mailman/listinfo/bf-committers
___
Bf-committers mailing list
Bf-committers@blender.org
https://lists.blender.org/mailman/listinfo/bf-committers

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

[Ray Molenkamp]

Windows libs are done!

--Ray

On 2019-11-20 2:26 a.m., 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,
>
___
Bf-committers mailing list
Bf-committers@blender.org
https://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] TBB version inconsistencies

[Ray Molenkamp]

I mentioned the bump of the TBB Version in D6218 [1] however
this should have been communicated better to the other platform
teams. 

As for win64_vc14 it is no longer maintained, the reason I kept it
in svn for a little while longer is twofold

1) so people still on/building 2.80/81 based branches that have
not merged master in a while can still build without issues.

2) cycles standalone still uses it, I have not had time yet to
do the work/testing required there.

--Ray

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



On 2019-12-05 4:38 a.m., Sybren A. Stüvel wrote:
> 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
>
>
___
Bf-committers mailing list
Bf-committers@blender.org
https://lists.blender.org/mailman/listinfo/bf-committers

[Bf-committers] Mantaflow landing and unit tests.

[Ray Molenkamp]

All,

Hate to be a heckler for running the unit tests, but please:

When you land and/or review something big, RUN THE UNIT TESTS!

When the monster 10 patch mantaflow patch landed, it broke
6 cycles unit tests on all platforms, 5 with different renders
than the reference images and one full on blender crash [1]

bda4a284d20164fec2433f7c40f49fc903319400 [2] fixed the render
differences and turned the crash into a render difference [3]

Unrelated side note: whats with the less than helpful
commit message on this commit? it may as well have been
committed with the message 'something fluid' or 'Tuesday'
would have just as enlightening for other developers.

To summarize:

- The person submitting the patches has not run the tests
- The reviewers have not run the tests
- Less than optimal commit messages
- 18!! days after landing, there is still a failing test

Holiday season or not: I think we can and should do better than this

--Ray

[1] https://i.imgur.com/LE3baOg.png
[2] https://developer.blender.org/rBbda4a284d20164fec2433f7c40f49fc903319400
[3] https://i.imgur.com/5we0hEv.png


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

Re: [Bf-committers] Mantaflow landing and unit tests.

[Ray Molenkamp]

There's a couple of things we can look at:

We can take human element out of it, running the tests on a proposed patch
can and probably should be done automatically. I heard there were plans for
this, I hope they materialize sooner rather than later. I think this is one of 
Nathans projects

We are running the tests now on a nightly basis which is great, however
nobody seems to be looking at the results otherwise we would have figured
out the tests were failing 3 weeks ago and either disabled the test or fixed
the problem. I kinda feel that looking at the tests on a daily basis should
be on someones daily morning checklist, perhaps Nathan and/or Dalai can find
someone for this task?

as for commit messages, we have good guidance there [1], having people try a
little harder will probably go a long way there.

--Ray

[1] https://wiki.blender.org/wiki/Style_Guide/Commit_Messages



On 2020-01-02 7:04 p.m., Sebastián Barschkis wrote:
> Hi Ray,
>
> you’re right, the Cycles tests need to be updated. They need to make use of 
> the new fluid modifier.
> Sergey pointed this out to me right after (within 12h) I landed the commits, 
> i.e. the issue is known.
>
> So yes, blame it on me, I overlooked this part. I will look into this as soon 
> as possible.
>
> I agree that this is not ideal. But apart from better commit messages, how 
> can we do better at this time?
>
> Happy new year and best wishes,
> Sebastián
>
>> On 2. Jan 2020, at 22:31, Ray Molenkamp  wrote:
>>
>> All,
>>
>> Hate to be a heckler for running the unit tests, but please:
>>
>> When you land and/or review something big, RUN THE UNIT TESTS!
>>
>> When the monster 10 patch mantaflow patch landed, it broke
>> 6 cycles unit tests on all platforms, 5 with different renders
>> than the reference images and one full on blender crash [1]
>>
>> bda4a284d20164fec2433f7c40f49fc903319400 [2] fixed the render
>> differences and turned the crash into a render difference [3]
>>
>> Unrelated side note: whats with the less than helpful
>> commit message on this commit? it may as well have been
>> committed with the message 'something fluid' or 'Tuesday'
>> would have just as enlightening for other developers.
>>
>> To summarize:
>>
>> - The person submitting the patches has not run the tests
>> - The reviewers have not run the tests
>> - Less than optimal commit messages
>> - 18!! days after landing, there is still a failing test
>>
>> Holiday season or not: I think we can and should do better than this
>>
>> --Ray
>>
>> [1] https://i.imgur.com/LE3baOg.png
>> [2] https://developer.blender.org/rBbda4a284d20164fec2433f7c40f49fc903319400
>> [3] https://i.imgur.com/5we0hEv.png
>>
>>
>> ___
>> Bf-committers mailing list
>> Bf-committers@blender.org
>> https://lists.blender.org/mailman/listinfo/bf-committers
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> https://lists.blender.org/mailman/listinfo/bf-committers
___
Bf-committers mailing list
Bf-committers@blender.org
https://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Mantaflow landing and unit tests.

[Ray Molenkamp]

> One cruel thing i can think about is to force everyone to pay more
> attention is to prevent new build from being uploaded if regression tests
> are failing. We'll hear very quickly from users that there are no new
> builds on buildbot.
Cruel or not, It'll cost less resources to deal with
a single well defined test case, rather than triaging
and managing an unknown number of tickets that may
come from the same issue. I don't mind this idea *at all*

--Ray

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

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

[Ray Molenkamp]

I took a quick survey, most of the libs are either not applicable to us (QT 
related stuff) or at the preferred version already

however some of them are lagging behind a bit (or a lot in case of openVDB) and 
one of them is a little ahead of the VFX platform

Behind:
OpenEXR    VFX:2.4.x    Blender:2.3.0
OpenSubdiv VFX:3.4.x    Blender:3.4.0 RC2
OpenVDB    VFX:7.x  Blender:5.1.0
Boost  VFX:1.7  Blender:1.68

Ahead:
Intel TBB  VFX:2019_U6  Blender:2019_U9

Is the plan to get at-least the lagging ones up to the VFX versions for 2.83?

--Ray


On 2020-01-10 10:03 a.m., Ton Roosendaal wrote:

> Hi everyone,
>
> Blender has always been an early adopter of new libraries. We moved to Python 
> 3 ten years ago already. Unfortunately that made Blender incompatible with 
> the Python 2.7 infrastructure in many studios. But the industry is catching 
> up! Python 3.7 is now the reference standard.
>
> To give studios enough time and confidence to check out on Blender, I propose 
> to respect the VFX Platform versions for the entire year of 2020. That 
> implies we will be very conservative with upgrading libraries, for example 
> Python will stick to 3.7 this year for official releases.
>
> I've checked it with the core team and administrators, and they're OK - 
> provided this won't hold back essential improvements for our users.
>
> Check the reference platform here:
> https://vfxplatform.com/
>
> Thanks,
>
> -Ton-
> --
> Ton Roosendaal - t...@blender.org - www.blender.org
> Chairman Blender Foundation, Director Blender Institute
> Buikslotermeerplein 161, 1025 ET Amsterdam, the Netherlands
>
>
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> https://lists.blender.org/mailman/listinfo/bf-committers
___
Bf-committers mailing list
Bf-committers@blender.org
https://lists.blender.org/mailman/listinfo/bf-committers

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

[Ray Molenkamp]

That's me hence i'm asking if i should update these libs or not :)

--Ray

On 2020-01-10 10:54 a.m., Ton Roosendaal wrote:
> Hi,
>
> To my knowledge these differences are minor and won't be a showstopper for 
> studio pipelines.
> I will leave it to the platform maintainers though :)
>
> -Ton-
> --
> Ton Roosendaal - t...@blender.org - www.blender.org
> Chairman Blender Foundation, Director Blender Institute
> Buikslotermeerplein 161, 1025 ET Amsterdam, the Netherlands
>
>
> On 10/01/2020 18:30, Ray Molenkamp wrote:
>> I took a quick survey, most of the libs are either not applicable to us (QT 
>> related stuff) or at the preferred version already
>>
>> however some of them are lagging behind a bit (or a lot in case of openVDB) 
>> and one of them is a little ahead of the VFX platform
>>
>> Behind:
>> OpenEXR    VFX:2.4.x    Blender:2.3.0
>> OpenSubdiv VFX:3.4.x    Blender:3.4.0 RC2
>> OpenVDB    VFX:7.x  Blender:5.1.0
>> Boost  VFX:1.7  Blender:1.68
>>
>> Ahead:
>> Intel TBB  VFX:2019_U6  Blender:2019_U9
>>
>> Is the plan to get at-least the lagging ones up to the VFX versions for 2.83?
>>
>> --Ray
>>
>>
>> On 2020-01-10 10:03 a.m., Ton Roosendaal wrote:
>>
>>> Hi everyone,
>>>
>>> Blender has always been an early adopter of new libraries. We moved to 
>>> Python 3 ten years ago already. Unfortunately that made Blender 
>>> incompatible with the Python 2.7 infrastructure in many studios. But the 
>>> industry is catching up! Python 3.7 is now the reference standard.
>>>
>>> To give studios enough time and confidence to check out on Blender, I 
>>> propose to respect the VFX Platform versions for the entire year of 2020. 
>>> That implies we will be very conservative with upgrading libraries, for 
>>> example Python will stick to 3.7 this year for official releases.
>>>
>>> I've checked it with the core team and administrators, and they're OK - 
>>> provided this won't hold back essential improvements for our users.
>>>
>>> Check the reference platform here:
>>> https://vfxplatform.com/
>>>
>>> Thanks,
>>>
>>> -Ton-
>>> --
>>> Ton Roosendaal - t...@blender.org - www.blender.org
>>> Chairman Blender Foundation, Director Blender Institute
>>> Buikslotermeerplein 161, 1025 ET Amsterdam, the Netherlands
>>>
>>>
>>> ___
>>> Bf-committers mailing list
>>> Bf-committers@blender.org
>>> https://lists.blender.org/mailman/listinfo/bf-committers
>> ___
>> Bf-committers mailing list
>> Bf-committers@blender.org
>> https://lists.blender.org/mailman/listinfo/bf-committers
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> https://lists.blender.org/mailman/listinfo/bf-committers
___
Bf-committers mailing list
Bf-committers@blender.org
https://lists.blender.org/mailman/listinfo/bf-committers

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

[Ray Molenkamp]

tbbmalloc proxy was failing on win10 on earlier versions of TBB, I forgot the 
exact
version that fixed the issue [1] seems to imply it was 2019_U1, I bumped it to
2019_U9 just because it was current at the time, U6 will probably work, however
I'm currently more interested in bumping the deps we have, rather than rolling 
back the
one that is slightly ahead, given at-least one of them fixes some CVE's 
(openEXR).

However as a platform dev I'm mostly following in the libs department, if 
someone
tells me we need lib X version Y, I'll will go out of my way to make it happen
however these are not my libs, and I cannot be responsible for keeping an eye 
on the
version that get released or the integration into blender whenever there is a
code incompatible update.

Issue is nobody seems to be taking responsibility for the libs, hence they lag 
or
only get updated cause the new version solves build issues I have. Ideally we'd
assign each and  every one of the 30+ libs we have to a module, and the module
owners request updates to them. They don't have to worry about specific 
build-flags
for mac/linux/windows platform devs are quicker and better at it however if your
module depends on a external dependency keep an eye on it!

Can dalai organize anything in this department? doesn't have to be my idea
but we have to do a better/more structured job at managing these deps.

--Ray

On 2020-01-11 8:05 p.m., Stephen Swaney wrote:
> Following the VFX Platofrm for a year is reasonable.
> The problem with doing it long-term is they are handicapped by their
> reliance on Qt, something we thankfully don't suffer from.
>
> Upgrading our dependent libs is a good thing (at least in theory!).
>
> I seem to recall seeing a bunch of bugs related to Intel TBB on Windows
> which makes rolling back to U6 from U9 a bit scary.  Although, newer is not
> always better.  Ray would be a better person to comment on this since he is
> in it up to his ears.
>
> S.
>
> On Fri, Jan 10, 2020 at 1:03 PM Ray Molenkamp  wrote:
>
>> That's me hence i'm asking if i should update these libs or not :)
>>
>> --Ray
>>
>> On 2020-01-10 10:54 a.m., Ton Roosendaal wrote:
>>> Hi,
>>>
>>> To my knowledge these differences are minor and won't be a showstopper
>> for studio pipelines.
>>> I will leave it to the platform maintainers though :)
>>>
>>> -Ton-
>>> --
>>> Ton Roosendaal - t...@blender.org - www.blender.org
>>> Chairman Blender Foundation, Director Blender Institute
>>> Buikslotermeerplein 161, 1025 ET Amsterdam, the Netherlands
>>>
>>>
>>> On 10/01/2020 18:30, Ray Molenkamp wrote:
>>>> I took a quick survey, most of the libs are either not applicable to us
>> (QT related stuff) or at the preferred version already
>>>> however some of them are lagging behind a bit (or a lot in case of
>> openVDB) and one of them is a little ahead of the VFX platform
>>>> Behind:
>>>> OpenEXRVFX:2.4.xBlender:2.3.0
>>>> OpenSubdiv VFX:3.4.xBlender:3.4.0 RC2
>>>> OpenVDBVFX:7.x  Blender:5.1.0
>>>> Boost  VFX:1.7  Blender:1.68
>>>>
>>>> Ahead:
>>>> Intel TBB  VFX:2019_U6  Blender:2019_U9
>>>>
>>>> Is the plan to get at-least the lagging ones up to the VFX versions for
>> 2.83?
>>>> --Ray
>>>>
>>>>
>>>> On 2020-01-10 10:03 a.m., Ton Roosendaal wrote:
>>>>
>>>>> Hi everyone,
>>>>>
>>>>> Blender has always been an early adopter of new libraries. We moved to
>> Python 3 ten years ago already. Unfortunately that made Blender
>> incompatible with the Python 2.7 infrastructure in many studios. But the
>> industry is catching up! Python 3.7 is now the reference standard.
>>>>> To give studios enough time and confidence to check out on Blender, I
>> propose to respect the VFX Platform versions for the entire year of 2020.
>> That implies we will be very conservative with upgrading libraries, for
>> example Python will stick to 3.7 this year for official releases.
>>>>> I've checked it with the core team and administrators, and they're OK
>> - provided this won't hold back essential improvements for our users.
>>>>> Check the reference platform here:
>>>>> https://vfxplatform.com/
>>>>>
>>>>> Thanks,
>>>>>
>>>>> -Ton-
>>>>> ---

Re: [Bf-committers] Blender server upgrades

[Ray Molenkamp]

not sure what changed but phab is either no longer or real slow picking up on 
git commits

--Ray

On 2020-01-17 1:01 p.m., Dan McGrath wrote:
> Hi,
>
> Just a heads up that I will be attempting to upgrade some of the FreeBSD
> servers and packages tonight, so there will be reboots.
>
> So, go out, enjoy your Friday night, and get off the internet so I can poke
> at things :) o/
>
>
> Cheers,
>
> Dan McGrath
> ___
> 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] Library upgrades for VFX reference platform 2020 / Windows Lib update

[Ray Molenkamp]

Windows SVN libs have been updated for the 2.82 tag
and the changes in the platform_win32 file in the
2.82 release branch have been done as well. 2.82
is in a good spot, however...

Due to boost being included the upload has taken
most of my night so I'm not even going to dare
to start the merge to trunk at this point.

This does mean that if someone merges 2.82 to
master (which they will likely do), the master
windows build will be broken until someone does
the svn libs merge. If that happens I apologize
and if you need to get things done, please edit
the BOOST_POSTFIX variable 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 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
> Boost
> USD
> Alembic
> OpenColorIO
>
> Please commit to the blender-2.82-release svn tag, which is automatically
> checked out when running "make update" from the blender-v2.82-release
> Blender branch. Then we can merge those changes in trunk, I can help with
> that if needed.
>
> I will commit the macOS libraries.
>
> Thanks,
> Brecht.
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> https://lists.blender.org/mailman/listinfo/bf-committers
___
Bf-committers mailing list
Bf-committers@blender.org
https://lists.blender.org/mailman/listinfo/bf-committers

[Bf-committers] OSL / LLVM / Freetype library updates.

[Ray Molenkamp]

Fellow Platform devs,

Due to various issues in several of the dependencies some of them
have been bumped to new versions.

OSL 1.10.9 / LLVM 9.0.1 - D6744
FreeType 2.10.1 - D6645

Please update these libraries for *Master only*, 2.82 will ship
with the old versions!

You may see SVN commits from me for other dependencies (oidn, libxml)
these are just windows build fixes in the current versions, no versions
are changed, no action is required for the linux/mac platforms.

Greetings,
Ray

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

Re: [Bf-committers] Dev Fund - Communication guidelines

[Ray Molenkamp]

Could you clarify this a tiny bit? Cause it kinda sounds like are want to 
publish the email addresses of anyone in d.b.o project ?

the 300+ volunteers in the moderators project may not take kindly on that

--Ray

On 2020-02-12 10:34 a.m., Ton Roosendaal wrote:
> Hi everyone,
>
> 3. For the future (Phabricator/Git)
>
> - Show email addresses from project members (to visitors who are logged in)
>
>
> Thanks,
>
> -Ton-
> --
> Ton Roosendaal - t...@blender.org - www.blender.org
> Chairman Blender Foundation, Director Blender Institute
> Buikslotermeerplein 161, 1025 ET Amsterdam, the Netherlands
>
>
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> https://lists.blender.org/mailman/listinfo/bf-committers
___
Bf-committers mailing list
Bf-committers@blender.org
https://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Dev Fund - Communication guidelines

[Ray Molenkamp]

Yeah I think the confusion comes from how phab organizes groups which it has 
given the unfortunate name 'projects'

for instance the moderators project : 
https://developer.blender.org/project/members/1/

It be 'real bad' to publish the personal information of these people without 
their consent, hence the ask for clarification.

Good to see it was just a misunderstanding!

Greetings,
Ray

On 2020-02-13 2:03 a.m., Ton Roosendaal wrote:
> Hi,
>
> I mean with project members the people with commit access. It's not 
> publishing everyone's email address, it's about being able to verify 
> someone's identity.
>
> If you prefer to separate your Blender work from your private work, create a 
> dedicated email address for communication with the Blender project, but the 
> default is to be approachable and visible.
>
> Same rule applies here in Mailman btw! If you email the list, the address you 
> receive replies with is visible here.
>
> Exceptions can apply, we can check on that individually. But being visible 
> and open as contributor to Blender is important to gain trust levels for 
> future contributors who work for studios/companies. I prefer them to be 
> visible in that role as well.
>
> This (or other guidelines) can be put in a future CLA as well. Another 
> discussion for later.
>
> -Ton-
> --
> Ton Roosendaal - t...@blender.org - www.blender.org
> Chairman Blender Foundation, Director Blender Institute
> Buikslotermeerplein 161, 1025 ET Amsterdam, the Netherlands
>
>
> On 12/02/2020 20:06, Ray Molenkamp wrote:
>> Could you clarify this a tiny bit? Cause it kinda sounds like are want to 
>> publish the email addresses of anyone in d.b.o project ?
>>
>> the 300+ volunteers in the moderators project may not take kindly on that
>>
>> --Ray
>>
>> On 2020-02-12 10:34 a.m., Ton Roosendaal wrote:
>>> Hi everyone,
>>>
>>> 3. For the future (Phabricator/Git)
>>>
>>> - Show email addresses from project members (to visitors who are logged in)
>>>
>>>
>>> Thanks,
>>>
>>> -Ton-
>>> --
>>> Ton Roosendaal - t...@blender.org - www.blender.org
>>> Chairman Blender Foundation, Director Blender Institute
>>> Buikslotermeerplein 161, 1025 ET Amsterdam, the Netherlands
>>>
>>>
>>> ___
>>> Bf-committers mailing list
>>> Bf-committers@blender.org
>>> https://lists.blender.org/mailman/listinfo/bf-committers
>> ___
>> Bf-committers mailing list
>> Bf-committers@blender.org
>> https://lists.blender.org/mailman/listinfo/bf-committers
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> https://lists.blender.org/mailman/listinfo/bf-committers
___
Bf-committers mailing list
Bf-committers@blender.org
https://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Embree library update to 3.8.0

[Ray Molenkamp]

Windows is done!

Tracking ticket in : https://developer.blender.org/T73819

--Ray

On 2020-02-14 11:19 a.m., Stefan Werner wrote:
> Hello platform maintainers,
>
> I updated the Embree version for `make deps` and install_deps.sh to 3.8.0.
> Please update the binaries when you get a chance.
>
> Currently, there is no code in Blender that requires this new version yet. 
> Once updated binaries for all the platforms are available, I will check in 
> features that require the newer Embree library (D6575).
>
> -Stefan
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> https://lists.blender.org/mailman/listinfo/bf-committers
___
Bf-committers mailing list
Bf-committers@blender.org
https://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Future Releases with VR?

[Ray Molenkamp via Bf-committers]

UPBGE is a blender fork we do not maintain, so any questions
you have on UPBGE you'll have to sort out with the people who
work on it.

Their community page [1] has several options of contacting them.

Greetings,
Ray

[1] https://upbge.org/community.html
 

On 2020-04-10 12:58 a.m., Armani Bless via Bf-committers wrote:
> Hello I know UPBGE is fairly new but I want to start a new game with a
> python game engine. Will UPBGE be looking forward in developing in VR?
> Maybe sometime in the next few years? I will be creating a hybrid game of a
> VR and a real-time war strategy game. First I will developed the war
> strategy game(ETA 1-2 years) then implement the VR spectrum.
> I will love to hear your thoughts of the future of the company?
>
> Also how can I donate 💸? I want to donate a little every month.
> ___
> 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] Policies about patches modifying third-parties libraries.

[Ray Molenkamp via Bf-committers]

While i agree with "you should be able to build blender even with stock/system 
libraries"

I however do not think that the bar for "oh we'll just add it to /extern" 
should be as low as it appears to be. I'd be very much in favor of *NOT* adding 
a behemoth like USD to `/extern` (~75 megs, twice the size `/extern` currently, 
more than all the code in `/source` combined!) and ballooning an already high 
blender build time just to support a single IO format. 

Surely this can be worked out with upstream USD?

--Ray

On 2020-08-25 1:05 p.m., 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
___
Bf-committers mailing list
Bf-committers@blender.org
https://lists.blender.org/mailman/listinfo/bf-committers