Re: [Bf-committers] Libraries update required

[Martijn Berger]

Hi brecht,


ill build the 10.6 libs.

Martijn

On Sat, Dec 3, 2016 at 4:25 PM, Brecht Van Lommel <
brechtvanlom...@pandora.be> wrote:

> I have updated the new macOS 10.9 libraries to these versions.
> https://developer.blender.org/rBL61756
>
> Do we need these updates for master? I don't have build scripts for
> the macOS 10.6 libraries, and don't intend to start maintaining them.
>
> On Thu, Dec 1, 2016 at 3:27 PM, 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
> >>
> >
> >
> >
> > --
> > 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] Promoting MSVC 2015 builds as official

[Martijn Berger]

I agree, let's do this ASAP.

On 2 Dec 2016 2:21 pm, "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?
>
> --
> 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] Proposal to switch both master and blender2.8 to c++11 be default.

[Martijn Berger]

This cost is a one time thing we will incur anyway.

Users should not really experience anything except maybe having blenders
choices line up with the python official version better.

The main benefit it having one environment in which to build 2.8 and if we
ever have to do a 2.7 we can do it in that environment as well.

C++11 / C11 have been the default mode for our main compilers for some
time. Apple actively warns with each invocation of the compiler that uses
libstdc++.
And even Debian is transitioning.

I get that there are always arguments for being conservative, but for the
MacOS platform i think it is better to switch and also reap the benefits of
better rebuild-able libraries.
For all platforms i think it would be to be consistent. We default to C++11
in the case of gcc 6 and above ( likely due to that compiler defaulting to
c+11 ) But for clang 3.6 and above this is not done. For any MSVC 2012 or
better this argument would also hold.


On Sun, Nov 20, 2016 at 9:58 PM, Sergey Sharybin <sergey@gmail.com>
wrote:

> So is it all for the locally-compiled Blender (meaning, both releases and
> buildbots stays the same as is)?
>
> Keep in mind, while it might be fine on Windows/OSX you'll have some major
> problems on Linux (users will lat least need to re-compile all
> dependencies). And sure enough they'll run into weird compilation / linking
> errors (shall i here note that the guy who proposes to bump something must
> become responsive for the users communication and figuring out their
> problems caused by the bump? ;)
>
> Still either i'm missing something, or so far the motivation behind such a
> change is because we can do it. What are the benefits for users? What is
> the problem you're solving here? Why to rush such a thing?
>
>
> On Sun, Nov 20, 2016 at 9:44 PM, Martijn Berger <martijn.ber...@gmail.com>
> wrote:
>
> > On Sun, Nov 20, 2016 at 9:00 PM, Mike Erwin <significant....@gmail.com>
> > wrote:
> >
> > > On Sun, Nov 20, 2016 at 8:45 AM, Martijn Berger <
> > martijn.ber...@gmail.com>
> > > wrote:
> > > >
> > > >
> > > > The only mayor downside i see is that we would effectively drop OS X
> > 10.8
> > > > and earlier.
> > > >
> > >
> > > Eek, dropping 10.6, 10.7 and 10.8 was not on our Blender 2.7x roadmap.
> > This
> > > would prevent 2.79 from running on lots of Macs that could handle it
> (GL
> > > 2.1 capable GPUs). Those same Macs are stuck with older GPUs so
> deciding
> > to
> > > drop them for Blender 2.8 was easier.
> > >
> > We never roadmapped dropping WIndows XP. That still has more users then
> > 10.7 and 10.8 combined judging form our google analytics.
> > 10.9 will soon be dropped from the official support roster by Apple.
> >
> > >
> > > Most people are running latest OS & Xcode and it is annoying to not be
> > able
> > > to type "make full" and run. By default I agree this should work. No
> > hoops!
> > >
> > It is not just about that. Most compilers and other packages are
> defaulting
> > to it. Compiling binary python stuff for use with the official blender
> > makes you jump through more hoops then most people can. Not many people
> > have a version of python compiled with msvc 2013 on windows when it is
> > officially deprecated and the official python release is with 2015. A
> > similar argument can be made for almost any package for python that
> > contains native code on MacOS they all use libc++ as that is the default.
> >
> > >
> > > Can we keep the ability to build for 10.6 thru 10.8 using an *older*
> > > Xcode/SDK? I keep a drive with 10.9 & older Xcode, but am not a build
> > > system guru.
> > >
> > Sure. release is not build on a machine that is kept up to date. It is
> > build on OS X 10.9 with code 6.3 and a clang version compiled by Jens.
> >
> > >
> > > For our next release we could have [Mac OS 10.6, 10.7, 10.8] and [Mac
> OS
> > > 10.9 & newer] downloads. That gives us a rough count how many people
> > > actually use the older system.
> >
> > Yes, we can also have windows XP and windows ME, 98 support. it is just a
> > question of adding some extra hands. If we care about user numbers we
> might
> > want to port to android soon.
> >
> >
> > >
> > > Mike Erwin
> > > musician, naturalist, pixel pusher, hacker extraordinaire
> > > ___
> > > 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

Re: [Bf-committers] Proposal to switch both master and blender2.8 to c++11 be default.

[Martijn Berger]

On Sun, Nov 20, 2016 at 9:00 PM, Mike Erwin <significant@gmail.com>
wrote:

> On Sun, Nov 20, 2016 at 8:45 AM, Martijn Berger <martijn.ber...@gmail.com>
> wrote:
> >
> >
> > The only mayor downside i see is that we would effectively drop OS X 10.8
> > and earlier.
> >
>
> Eek, dropping 10.6, 10.7 and 10.8 was not on our Blender 2.7x roadmap. This
> would prevent 2.79 from running on lots of Macs that could handle it (GL
> 2.1 capable GPUs). Those same Macs are stuck with older GPUs so deciding to
> drop them for Blender 2.8 was easier.
>
We never roadmapped dropping WIndows XP. That still has more users then
10.7 and 10.8 combined judging form our google analytics.
10.9 will soon be dropped from the official support roster by Apple.

>
> Most people are running latest OS & Xcode and it is annoying to not be able
> to type "make full" and run. By default I agree this should work. No hoops!
>
It is not just about that. Most compilers and other packages are defaulting
to it. Compiling binary python stuff for use with the official blender
makes you jump through more hoops then most people can. Not many people
have a version of python compiled with msvc 2013 on windows when it is
officially deprecated and the official python release is with 2015. A
similar argument can be made for almost any package for python that
contains native code on MacOS they all use libc++ as that is the default.

>
> Can we keep the ability to build for 10.6 thru 10.8 using an *older*
> Xcode/SDK? I keep a drive with 10.9 & older Xcode, but am not a build
> system guru.
>
Sure. release is not build on a machine that is kept up to date. It is
build on OS X 10.9 with code 6.3 and a clang version compiled by Jens.

>
> For our next release we could have [Mac OS 10.6, 10.7, 10.8] and [Mac OS
> 10.9 & newer] downloads. That gives us a rough count how many people
> actually use the older system.

Yes, we can also have windows XP and windows ME, 98 support. it is just a
question of adding some extra hands. If we care about user numbers we might
want to port to android soon.


>
> Mike Erwin
> musician, naturalist, pixel pusher, hacker extraordinaire
> ___
> 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] Proposal to switch both master and blender2.8 to c++11 be default.

[Martijn Berger]

Hi everyone,

We have had a discussion about c++11 for at least 2 years. We have decided
to allow c++11 features in 2.8, and this implies compiling in c++11 mode
with a supporting compiler. This email is not about that.

What i want to propose is to build master ( 2.7x ) in c++11 mode against
libraries that are in c++11 ABI ( on platforms that make this distinction.
That does not imply allowing c++11 only features or dropping the
possibility of being able to compile in c++03 mode.

Why would we want to do that ?

1) we are already sort of doing it on windows. MSVC does not really allow
you to disable its c++11 support.

2) Modern systems are defaulting to it. this should have nothing to do with
us except that it does. We have users trying to use python extensions with
blender that we ourselves do not ship. On MacOS the compiler and thus
things like homebrew compile against libc++ for some time now people who
try to compile extensions need to jump through a lot of hoops in order for
things to work.

3) It fits very well with preparing our build-system and libraries for the
future / Blender 2.8. We decided to go that way and while i agree we should
not make 2.7x depend on c++11 i think building it by default as c++11 does
not contradict that decision.

4) We could start to use llvm versions greater then 3.4 for release builds
as those need a c++11 compiler

I would like to move to msvc2015 for Windows and darwin/libc++/c++11 for
MacOS for 2.7x. and 2.8

The only mayor downside i see is that we would effectively drop OS X 10.8
and earlier.



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

Re: [Bf-committers] Fwd: Linker fails using Xcode

[Martijn Berger]

On Tue, Nov 15, 2016 at 5:01 PM, Gruber Aurel 
wrote:

> Hey Valentin
>
> I’m not an expert on this, but let me try with my 5 cents:
>
> - What precompiled libraries do you use? What happens if you use these
> darwin libraries:
> https://svn.blender.org/svnroot/bf-blender/trunk/lib/darwin
> instead of darwin-9.x.universal?
>
> I got that link from Brecht because I need c++11 features. But then you
> need to se WITH_CXX11 = on. I think.
>

That is correct.


>
> Hope that helps
>
> Aurel
>
> On 15 Nov 2016, at 16:54, Jens Verwiebe > wrote:
>
> Try adding -lc++ to the cmake_exe_linkerflags.
>
>
> Jens
>
>
> Am 15.11.2016 um 14:22 schrieb Aaron Carlisle:
> Hi Rueda,
>
> Email attachments get deleted on the mailing list,
> please paste the log to http://hastebin.com/
> and share the link here.
>
> In best regards,
>
> Aaron Carlisle
>
> On Mon, Nov 14, 2016 at 6:55 PM, Валентин Руэда  >
> wrote:
>
> Hello all,
>
> I'm trying to build blender on Os X (10.11.6) using Xcode.
> After I run cmake and change Standard library to libc++ it successfully
> compiles, but the linker fails
> I've tried different deployment targets.
>
> I'm wondering if I need to change any parameters in Cmake?
>
> Please find the build log attached
>
>
> --
> Best regards
> Valentin
>
>
>
> --
> Best regards
> Rueda Valentin
>
> ___
> 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
>
> --
>
> Jens Verwiebe
> Allerskehre 44 - 22309 Hamburg
>
> Tel.: +49 40 68 78 50
> mobile: +49 172 400 49 07
> mailto: i...@jensverwiebe.de
> web: http://www.jensverwiebe.de
>
> ___
> 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] not able to build environment

[Martijn Berger]

I can host a dump of the svn it works again.

Do you want the windows x64 visual studio 2013 binaries ?

Martijn

On Sat, Nov 5, 2016 at 1:34 PM, Nishant Varshney <
nishant26varsh...@gmail.com> wrote:

> How long will it take sir..because I am not able to build the environment
> and unable to contribute
>
>
>   Original Message
> From: brechtvanlom...@pandora.be
> Sent: November 5, 2016 5:56 PM
> To: bf-committers@blender.org
> Reply-to: bf-committers@blender.org
> Subject: Re: [Bf-committers] not able to build environment
>
> It seems it's the repository that got corrupted, someone will need to
> fix it before you can download it:
> https://developer.blender.org/T49777
>
> On Sat, Nov 5, 2016 at 12:51 PM, Nishant Varshney
>  wrote:
> > hello sir
> > sorry for the incomplete information.
> >
> > i had attached a picture earlier in my mail of the xml error that i had
> > faced.
> >
> > I am having an ASUS laptop.
> > windows 10 pro,version 1607,build 14393.
> > ram = 8gb
> > processor = i7
> > graphic card = nvidia gtx 950m
> >
> > the xml error i face when i was building environment by following this
> page
> >  " https://www.blender.org/manual/about/contribute/install/windows.html
> "
> > and while downloading the manual in folder c:\ blender_docs using
> tortoise
> > svn .
> >
> > " THE XML RESPONSE CONTAINS AN INVALID XML"
> > " MALFORMED XML: NO ELEMENT FOUND" .
> >
> > On Sat, Nov 5, 2016 at 4:14 PM, Piotr Arlukowicz <
> > pio...@polskikursblendera.pl> wrote:
> >
> >> Hey, Nishant,
> >> just a quick note: if you want some help, be so nice and provice more
> >> information, at least what computer you have, what windows, describe
> step
> >> by step your actions and at least provide the XML error you've got. This
> >> way you help us to help you.
> >>
> >> And there is also a page for bugreports, which are RECOMMENDED way of
> >> submittings bugs like this.
> >>
> >> Bug can be reported here: https://developer.blender.org/
> >>
> >> best regards
> >> Piotr
> >> Arlukowicz, BFCT
> >>
> >> *YT: /user/piotao?feature=guide*
> >>  *FB:* */polskikursblendera* *TW:*
> >> */piotao*
> >> *Blender Network:* *https://www.blendernetwork.org/piotr-arlukowicz
> >> *
> >> *Polski Kurs Blendera:* http://polskikursblendera.pl
> >>
> >>
> >>
> >>
> >>
> >> 2016-11-05 6:59 GMT+01:00 Nishant Varshney  >:
> >>
> >> > i am not able to build the environment in my windows pc help please
> >> >
> >> > when i install tortoise and do svn check out it fails with an error of
> >> xml
> >> >
> >> > ___
> >> > Bf-committers mailing list
> >> > Bf-committers@blender.org
> >> > https://lists.blender.org/mailman/listinfo/bf-committers
> >> >
> >> >
> >> ___
> >> Bf-committers mailing list
> >> Bf-committers@blender.org
> >> https://lists.blender.org/mailman/listinfo/bf-committers
> >>
> > ___
> > Bf-committers mailing list
> > Bf-committers@blender.org
> > https://lists.blender.org/mailman/listinfo/bf-committers
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> https://lists.blender.org/mailman/listinfo/bf-committers
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> https://lists.blender.org/mailman/listinfo/bf-committers
>
___
Bf-committers mailing list
Bf-committers@blender.org
https://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Mac OS 10.7+ for Blender 2.8

[Martijn Berger]

I think 10.6 was special in the sense that a significant number of people
lingered on that version.
10.9 and higher have been free upgrades and that seems to have moved a
significant number of people over.
Last time i checked our download stats 10.6 had more users then 10.7 and
10.8 combined.

Taking that into account I would be in favor of using 10.9 as minimal
version.

On Tue, Oct 4, 2016 at 10:59 PM, Brecht Van Lommel <
brechtvanlom...@pandora.be> wrote:

> Xcode 8 is currently showing this warning. So it's not clear how long
> Apple will even officially support building for 10.8.
>
> clang: warning: libstdc++ is deprecated; move to libc++ with a minimum
> deployment target of OS X 10.9
>
> Apple support for 10.9 ended last month, 10.8 a year before that, so
> those are not even getting security updates anymore. Firefox and
> Chrome have 10.9 as minimum requirement, and I think the same or
> higher is required for a lot of other major software. Blender 2.8
> would be released a year or more from now, so we would be the
> exception in still supporting 10.7.
>
> The one issue I personally found with 10.7 was an SDK bug that makes
> building Python 3.5 fail. I tried to solve it for a few hours but
> didn't find a solution yet. It's probably not a showstopper but if we
> decide to use 10.8 or higher I won't spend more time trying to fix it.
>
> I don't know of any other serious issues, though inevitably we'd
> encounter some in the future. Personally I wouldn't want to spend time
> debugging OpenGL issues on e.g. 10.7 or 10.8, but maybe you're up for
> it :)
>
>
> On Tue, Oct 4, 2016 at 2:27 PM, Mike Erwin 
> wrote:
> > Bringing this back up since it was mentioned in the C++11 libs
> discussion.
> >
> > Why are some people in favor of Mac OS 10.8 as a minimum requirement? I
> > agree that 10.7 sucks from a usability perspective, but I'm sure you have
> > better reasons.
> >
> > It would help the discussion to have a list of Macs that could run
> Blender
> > 2.8 (decent GPU) but can't run OS 10.8.
> >
> > -- Mike
> >
> > On Mon, May 16, 2016 at 2:32 PM, Mike Erwin 
> > wrote:
> >
> >> Mac OS 10.6 "Snow Leopard" needs to be dropped, since Apple implemented
> GL
> >> 3.2 starting with OS 10.7 "Lion". The rest of the Blender 2.7x line can
> >> still support Snow Leopard.
> >>
> >> Now that we can assume OS 10.7 or later, what does that give us?
> >>
> >> OpenGL 3.2 -- of course
> >> ARC -- automatic reference counting, no more retain/release
> >> Fullscreen mode -- already implemented, so we can remove the older
> method.
> >> I see comments about this working better in 10.9 because of improved
> >> multiple monitor handling.
> >>
> >> So no huge features for us besides OpenGL. But this does give us an
> >> opportunity to clean up some of the crusty old workarounds. Declare
> >> MAC_OS_X_VERSION_MIN_REQUIRED = 1070 and revisit everywhere this is
> >> checked.
> >>
> >> I'm not sure if anyone is actively working on GHOST or other
> Mac-specific
> >> stuff, but wanted to start this conversation early.
> >>
> >> Mike Erwin
> >> musician, naturalist, pixel pusher, hacker extraordinaire
> >>
> > ___
> > 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] Meeting in about 3 hours

[Martijn Berger]

Hi,

I could not agree more. Sunday afternoon is not ideal but to me this new
and improved thing is almost impossible.


On Sat, Jul 9, 2016 at 5:37 PM, Sergey Sharybin 
wrote:

> Hi,
>
> Personally i think Sundays were working much better -- more predictable
> schedule, more predicable who's attending those meetings.
>
> Only unfortunate is that it is hassle for Campbell since 16:00 in A-dam is
> like 2:00 in the night. We might try finding better time during Sunday
> perhaps?
>
> On Sat, Jul 9, 2016 at 3:49 PM, Ton Roosendaal  wrote:
>
> > Hi all,
> >
> > The thrice-monthly cycle starts again with a LA 10 AM meeting.
> > For your time, check https://blendercoders.xyz/
> >
> > I would like to review this schedule. And either confirm it, or decide on
> > another scheme this month.
> >
> > There is mixed experiences with the new meeting cycle. Several meetings
> > even never happened. I miss the continuity, each meeting now is like an
> > independent gathering of people - making the decision procedure fuzzy and
> > not facilitating progress much.
> >
> > The meetings were also split to reach out to people in American and Asian
> > timezones. I've only seen minimal results of that.
> >
> > In my opinion the old (Sunday 16h) schedule functioned much better. Even
> > though it's not a nice time for the Americas or Asia, at least you always
> > knew that there was a weekly review of topics, a weekly check on progress
> > and planning, a weekly minutes, and a weekly moment you could attend to
> > speak up.
> >
> > What do you guys think, any better idea? Back to Sundays?
> >
> > Thanks,
> >
> > -Ton-
> >
> > 
> > Ton Roosendaal  -  t...@blender.org   -   www.blender.org
> > Chairman Blender Foundation, Producer Blender Institute
> > Support us - join blender.cloud or Blender Dev Fund.
> >
> > ___
> > 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] Blender Developers Meeting Minutes - May 27th

[Martijn Berger]

Hi all,

I think it is fine to break OS X for a while if we make sure that:

- blender still builds on OS X and that we still build it, even if it is
totally broken when running just to prevent other things breaking
unintended
- you can force build a core only 3.2 on windows / linux and have some link
time magic to make sure at least the legacy OpenGL entry points cannot work
in that state

I do not think is to much about most developers now using OS X as their
primary platform as that we should be very careful with a platform our
users care about.

Martijn

On Fri, May 27, 2016 at 7:46 AM, Mike Erwin 
wrote:

> Hi all,
>
> On the OpenGL topic, my main question is whether anyone working on Blender
> 2.8 needs Mac support in the next few months. Eventually we'll have
> everything working cross platform with GL 3.2 core profile. But to get
> started on that we can use 3.2 compatibility profile which works on Windows
> and Linux but not Mac.
>
> Git master and current/future Blender 2.7x releases will not be affected.
> Just the blender2.8 branch which is the hub for future work.
>
> A few months!? It's not just immediate mode drawing commands that need
> replacement. Display lists also go away. Much built-in state and functions
> are replaced by GLSL. In other words there's lots to do! And capable people
> here that are itching to make progress.
>
> After the meeting I locally bumped GL to 3.2 on Windows, upgraded built-in
> shaders and code generator to GLSL 1.5, and scrapped some legacy code. If
> nobody objects, that can all go into blender2.8 and not a sub-branch.
>
> Mike Erwin
> musician, naturalist, pixel pusher, hacker extraordinaire
>
> On Thu, May 26, 2016 at 9:19 PM, Campbell Barton 
> wrote:
>
> > Hi, only a few topics to report on,
> > some discussion about OpenGL that we better move to the mailing list.
> >
> > 1) Current Projects
> >
> > - Mike Erwin proposes to switch to OpenGL 3.2 minimum requirement in
> > the 2.8x branch.
> >   While meeting generally agrees on this, it breaks building on OSX
> > for as long as we still use immediate mode,
> >   so better move discussion to mailing list, since we better take care
> > breaking platform support for too long on branches intended for
> > everyone to collaborate on.
> >
> > - Kevin Dietrich is working on Alembic,
> >   http://blenderartists.org/forum/showthread.php?399763
> >
> > 2) GSOC Updates
> >
> > - Thomas has Bindless Textures and Single Channel textures in master
> >
> >
> https://wiki.blender.org/index.php/User:DingTo/GSoC_2016/Weekly_Reports/Preparations
> > ___
> > 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] Cmake OS X Broken?

[Martijn Berger]

Yes this can happen,

Newer Xcode on 10.10 ships only a 10.11 sysroot for example.

On Tue, Mar 8, 2016 at 5:21 AM, Campbell Barton 
wrote:

> After some further investigation (details below), it seems the error
> is caused by a mismatch between the OSX version and the SDK version.
>
> Is this something that's normally used/supported on OSX?
>
> 
>
> The error was that `uname -r` outputs, (15.2.0). which causes the SDK
> to be set to 10.11, where Jonathan has 10.10 of the SDK. See [0].
>
> Would be good if we could avoid having this list of hard-coded OSX
> versions.
> I think its come up before, this makes OSX unusable for bisecting
> since you won't be able to build older versions.
>
> LLVM's compiler-rt for example, uses:
>
>   xcodebuild -version -sdk macosx Path
>
> see source [1].
>
> [0]:
> https://developer.blender.org/diffusion/B/browse/master/CMakeLists.txt;02cabdac5a9097a70587211565768e8990f36798$519
> [1]:
> https://github.com/llvm-mirror/compiler-rt/blob/master/cmake/config-ix.cmake#L253
>
> On Tue, Mar 8, 2016 at 2:44 PM, Jonathan Williamson
>  wrote:
> > Hey OS X devs,
> >
> > It would seem configuring and generating CMake build files is currently
> broken? It seems to be having trouble detecting the correct SDK version,
> forcing the `CMAKE_OSX_SYSROOT` always to 10.11, even if 10.10 is the
> highest installed.
> >
> > I spent a while on IRC with Campbell and jaggzt to no avail. It was also
> mentioned that OS X Build bot has not successfully built since March 5th,
> at 05:03:58.
> >
> > Even manually setting the SDK versions and deploy targets in the
> CMakeCache.txt fails.
> >
> > Is anyone else having trouble building with CMake on OS X?
> > ___
> > Bf-committers mailing list
> > Bf-committers@blender.org
> > http://lists.blender.org/mailman/listinfo/bf-committers
>
>
>
> --
> - Campbell
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

[Bf-committers] Windows XP support has been dropped.

[Martijn Berger]

We implicitly dropped Windows XP when switching to python 3.5.
Python has the so called PEP system and PEP 11 "Removing support for little
used platforms" defines the support for windows XP to be over at the same
time Microsoft stopped supporting it. Since python 3.5 released after XP
died it does not support XP.

While it might be possible to backport python 3.5 to windows XP i think
that we should not do this.

So blender 2.77 will not run on XP. The 32 bit release requires Vista or
newer and the 64 bit release Windows 7 SP1 or newer.
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Building blender on OS X problem

[Martijn Berger]

Hi,

What version os OS X are you running and what version of Xcode are you
using to build ?

On Mon, Feb 8, 2016 at 12:44 PM, Doeke Wartena 
wrote:

> I try to build blender following this documentation:
>
> http://wiki.blender.org/index.php/Dev:Doc/Building_Blender/Mac
>
> I'm stuck at the building blender part. I do get a blender.app file but
> there is a cross in it (macs way to tell it can't be executed).
>
> [image: enter image description here] 
>
> I try to build with terminal and not with xcode.
>
> The last lines in the terminal log are:
>
> [100%] Building C object
> source/creator/CMakeFiles/blender.dir/buildinfo.c.o[100%] Linking CXX
> executable ../../bin/blender.app/Contents/MacOS/blender
> ld: archive has no table of contents file
> '../../lib/libbf_editor_space_api.a' for architecture x86_64
> clang: error: linker command failed with exit code 1 (use -v to see
> invocation)
> make[2]: *** [bin/blender.app/Contents/MacOS/blender] Error 1
> make[1]: *** [source/creator/CMakeFiles/blender.dir/all] Error 2
> make: *** [all] Error 2
>
> Please someone help.
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Blender support for shader mdoel 6.0

[Martijn Berger]

HI Nadir,

I would expect some version of cuda 7.5 or 8.0 to offer sm_60 support (
which i presume is pascal ? ).  There are some plans for falling back onto
PTX when precompiled kernels do not match the requested feature-set of the
available hardware.  But due to the size and complexity of our kernel that
needs a bit of extra work as ptxas will likely chew on those files for a
non trivial time rendering blender unresponsive, which we need to handle
before adding ptx fallback kernel support.

If you have the possibility of enabling us to test with a version of the
cuda toolkit that can generate the needed binaries feel free to contact
Thomas. Sergey or myself directly.

Martijn

On Mon, Feb 8, 2016 at 7:56 AM, Nadir Cazi  wrote:

> Hi,
>
>We are facing an error in our internal testing while rendering using
> Blender, with our latest chip running Shader Model 6.0.
> >> "cuda binary kernal for this graphics card  compute capability 6.0 not
> found"
>
>We see app creates context, checks for sm version, and then destroys
> the context and quits.
>
> Does Blender NOT support shader model 6.0? If so, are there any
> immediate plans to support it?
>
>
> Thanks and regards,
> Nadir Cazi,
> SW-GPU,
> Nvidia Graphics
>
>
>
> P.S.: Exact steps to reproduce error:
> 1. Launch Blender app, double click to open.
> 2. Click on file > Open > select any project by traversing to the path it
> is saved.
> 3. Go to File > User Preference > System, select CUDA under "Compute
> Device".
> 4. Close User Preference.
> 5. Click on the Render option (small camera icon) toward the right view.
> 6. There should be a "Device" drop-down option, which is defaulted to
> "CPU", change that to "GPU Compute".
> 7. Render the active scene by clicking the render option, which is the
> button with the small camera with the word "Render" next to it. It's the
> first button from the "Render" pane.
>
> Observations:
> 1. Failed with error "cuda binary kernal for this graphics card compute
> capability 6.0 not found" error after clicking on render button
>
>
> ---
> This email message is for the sole use of the intended recipient(s) and
> may contain
> confidential information.  Any unauthorized review, use, disclosure or
> distribution
> is prohibited.  If you are not the intended recipient, please contact the
> sender by
> reply email and destroy all copies of the original message.
>
> ---
>
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>
>
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] OSX 32bit builds

[Martijn Berger]

Hi Sergey,

I would think that since apple only produced a very limited number of
machines that x64 based and not x86-64 capable the cost of keeping this
working could be better spend on other things.


Martijn

On Fri, Jan 29, 2016 at 9:39 AM, Sergey Sharybin 
wrote:

> Hey everyone,
>
> For quite some time now building of 32bit binaries for OSX is no longer
> happening [1].
>
> Additionally;
>
> - We don't do official releases for 32bit OSX for quite some time now
> - OSL and OpenCollada are already simply disabled in the buildbot
>
> So does it make sense to keep trying to keep those builds up and running or
> i can just bring the slave down and we all go 64bit OSX form now on?
>
> [1]
>
> https://builder.blender.org/builders/mac_i386_10_6_cmake/builds/71/steps/compile/logs/stdio
>
> --
> With best regards, Sergey Sharybin
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Windows XP support

[Martijn Berger]

Hi Mike,

I am pretty sure it either works or can be made to work pretty easy.

Martijn

On Fri, Jan 29, 2016 at 10:39 PM, Mike Erwin 
wrote:

> On Fri, Jan 29, 2016 at 3:14 PM, Sebastian A. Brachi <
> sebastianbra...@gmail.com> wrote:
>
> > >
> > > What newer APIs do we want to use but are being held back by XP?
> > >
> >
> > What about Python 3.5, which doesn't support XP anymore?
> >
> > As specified in PEP 11, a Python release only supports a Windows platform
> > > while Microsoft considers the platform under extended support. This
> means
> > > that Python 3.5 supports Windows Vista and newer. If you require
> Windows
> > XP
> > > support then please install Python 3.4.
> >
> > https://docs.python.org/3/using/windows.html
> >
>
> If Python stops working that's a BIG reason to move on. If unsupported
> means "works, but don't expect support"... it's not as urgent.
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Windows XP support

[Martijn Berger]

HI Mike,

We could switch to PSAPI version 2 when targeting vista or above.
I am sure there are others as just this one could have been handled without 
creating the **_xp variants of the toolchain.
For me personally I think switching to mdvc 2015 is more important ( I know 
vc140_xp exists but lets not go there )
and I do not run XP or Vista anymore and I do not know any other blender dev 
that does. 
Claiming real support based on that is a bit of a false promise.

> On 29 Jan 2016, at 21:00, Mike Erwin <significant@gmail.com> wrote:
> 
> What newer APIs do we want to use but are being held back by XP? I know the
> jump from Win 2000 to XP was because of the RawInput API for keyboard and
> 3D mice. I'm not making the case for keeping XP support forever, just want
> a clear case for dropping it now instead of during 2.8.
> 
> Thomas Dinges <blen...@dingto.org> wrote:
> 
>> Additionally, with the OpenGL 2.1 bump in 2.77, I bet a lot of these
>> ancient systems, combined with Intel GMA cards will fail anyway. So what
>> is the point?
>> 
> 
> Martijn Berger <martijn.ber...@gmail.com> wrote:
> 
>> ... and usually hardware to match.
> 
> 
> Combined with a crappy GPU, accept failure! But you can run many decent
> GPUs under XP.
> 
> Windows 7 with latest service pack is a great target for 2.8. And MSVC 2015
> as soon as possible! (It can still build for XP :))
> 
> Mike Erwin
> musician, naturalist, pixel pusher, hacker extraordinaire
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers

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

Re: [Bf-committers] MinGW support

[Martijn Berger]

On Sun, Dec 27, 2015 at 12:25 AM, Yousef Harfoush  wrote:

> > supporting a proper development environment requires installing visual
> > studio/Windows SDK anyway, so it sort of defeats the purpose of having an
> > "independent" compiler.
> ms is released a c++ environment without the VS IDE, it is not that big
> requirement.
>
> > Only positive thing from MinGW side as far as I know is faster cycles,
> but
> > it's been a while since I tested this. It may be better now with 2013
> > compiler?
>
> but is it not worth 40% render time reduction to support mingw, i mean
> that's is like 2 years of optimizing cycles, isn't it, i think it's better
> to drop vc12 in favor of mingw.
>
> I think the future is more likely to be clang on all platforms. To me
mingw has not been really supported for at least 3 years now, as to me a
supported platform is one that receives actual support from a developer.
For me and I think also for Anthony mingw is one of those perpetual todo
items. There are more important things to do first and that seems to stay
that way.

It is not like mingw is going to be broken an if you feel strongly about it
I would try and contribute but I do not see us gathering the resources
needed for proper support in the short term.



>
> Regards
> Yousef Harfoush
> ba...@msn.com
>
>
>
> > Date: Sat, 26 Dec 2015 21:30:18 +0100
> > From: kal...@gmail.com
> > To: bf-committers@blender.org
> > Subject: Re: [Bf-committers] MinGW support
> >
> > Hi,
> >
> > Status with openmp as far as I know is fine. The problem with MinGW is
> that
> > supporting a proper development environment requires installing visual
> > studio/Windows SDK anyway, so it sort of defeats the purpose of having an
> > "independent" compiler.
> >
> > * MSVC is needed to compile CUDA binaries
> > * MSVC is needed to run a debug build, since python is lined against the
> > debug libraries of microsoft, not MinGW.
> > * Debugging threads is not so well/natively supported (since pthread
> > library of MinGW is built on top of win32 library)
> >
> > Only positive thing from MinGW side as far as I know is faster cycles,
> but
> > it's been a while since I tested this. It may be better now with 2013
> > compiler?
> > I wouldn't want to spend any more time maintaining this, so if anyone
> wants
> > to take over (supposing we decide it is even worth it) be my guest.
> >
> > On 26 December 2015 at 19:47, Sergey Sharybin 
> wrote:
> >
> > > We can not advertise some sort of franken-compiler as an officially
> > > supported. Either the issues are solved in upstream or we don't
> consider
> > > compiler officially supported.
> > >
> > > On Sat, Dec 26, 2015 at 11:44 PM, Yousef Harfoush 
> wrote:
> > >
> > > > > Date: Sat, 26 Dec 2015 23:08:42 +0500
> > > > > From: sergey@gmail.com
> > > > > To: bf-committers@blender.org
> > > > > Subject: Re: [Bf-committers] MinGW support
> > > > >
> > > > > If we're going to keep supporting MinGW it should be latest
> official
> > > > > version. I remember we were having major issues with some system
> > > > libraries
> > > > > (mainly threading and OpenMP), so it makes sense to re-evaluate if
> > > those
> > > > > issues are solved form MinGW side before trying to support all the
> > > > > libraries we need.
> > > >
> > > > i use mingw 4.72 with added openmp libs from here:
> > > > http://tdm-gcc.tdragon.net/download
> > > > and threading works properly no crashes, at least in my workflow.
> > > >
> > > >
> > > > Regards
> > > > Yousef Harfoush
> > > > ba...@msn.com
> > > >
> > > >
> > > >
> > > >
> > > > >
> > > > > On Sat, Dec 26, 2015 at 10:38 PM, alekulyn 
> wrote:
> > > > >
> > > > > > I talked to psyfi over IRC around half a year ago and told him
> I'd
> > > like
> > > > > > to help with this.  There have been several complications along
> the
> > > > way,
> > > > > > such as which MinGW version we should use, rumors that clang was
> > > coming
> > > > > > into the picture, and general inactivity regarding anything
> MinGW.
> > > > > >
> > > > > > As for which MinGW version to use, my conversation with psyfi was
> > > > mainly
> > > > > > about adding libraries to the mingw64_gcc49 branch he started.
> To
> > > that
> > > > > > end, I did compile some libraries with MinGW-W64 GCC 4.9, but I
> must
> > > > > > have deleted them some time ago.
> > > > > >
> > > > > > Anyway, like I told psyfi, I'm willing to help with this.  Just
> need
> > > to
> > > > > > know which MinGW version to use.
> > > > > >
> > > > > > On 12/26/2015 5:12 PM, Sergey Sharybin wrote:
> > > > > > > Hey everyone,
> > > > > > >
> > > > > > > There are some missing precompiled libraries (sndfile,
> opensubdiv,
> > > > OSL)
> > > > > > and
> > > > > > > some misng libraries update (python, SDL, OpenAL)  for MinGW.
> > > > > > >
> > > > > > > This makes MinGW builds quite diverged from the official builds
> > > > > > feature-set
> > > > > > > and lib-version wise, 

Re: [Bf-committers] Weekly Blender developer minutes - 13 December 2015

[Martijn Berger]

Hi Mat,

The official build is build using cmake with the settings as set in
build_files/cmake/config/blender_full.cmake

Martijn

On Sun, Dec 13, 2015 at 7:50 PM, matmenu  wrote:

> Hi Ton,
>
> Thank you for keeping Scons for one release more. At the moment, on
> windows, the home-made cmake build give very different results from the
> buildbot/official ones. No Ocean modifier, etc... while the Scons builds
> give a build with the exact same functionality and build parameters as
> the official ones. Please make sure the windows cmake configuration is
> the exact same as the official/buildbot ones to help us switch.
>
> Regards,
> Mat
>
>
> Am 13/12/2015 um 16:28 schrieb Ton Roosendaal:
> > Hi all,
> >
> > Again a short meeting today in irc.freenode.net #blendercoders!
> >
> > 1) Blender 2.77 targets
> >
> > - Project page did not change much:
> > http://wiki.blender.org/index.php/Dev:Doc/Projects
> >
> > - Brecht van Lommel posted OpenGL 2.1 recode tasks for volunteers to
> pick up:
> > http://lists.blender.org/pipermail/bf-viewport/2015-December/75.html
> >
> > - Kevin Dietrich picked up Smoke Volume GLSL code.
> >
> > - Joshua Leung committed his GPencil work for 2.77
> > http://wiki.blender.org/index.php/Dev:Ref/Release_Notes/2.77/GPencil
> >
> >
> > 2) Other projects
> >
> > - Proposal: drop Scons for when we move to 2.8 (branches) but keep it
> for the 2.7x series.
> >
> > Thanks,
> >
> > -Ton-
> >
> > 
> > Ton Roosendaal  -  t...@blender.org   -   www.blender.org
> > Chairman Blender Foundation - Producer Blender Institute
> > Entrepotdok 57A  -  1018AD Amsterdam  -  The Netherlands
> >
> >
> >
> > ___
> > Bf-committers mailing list
> > Bf-committers@blender.org
> > http://lists.blender.org/mailman/listinfo/bf-committers
>
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Weekly Blender developer minutes - 13 December 2015

[Martijn Berger]

Hi Jacob,

I am in the process of getting  visual studio 2015 libraries done.
Till that is done please use visual studio 2013 with update 4 or 5.



On Sun, Dec 13, 2015 at 7:53 PM, Jacob Merrill 
wrote:

> Thank you kind Dev-gods , I was wondering which to get  visual studio 13,
> or the current one,
>
> I tried the current version but I could not get the IDE to work.
> On Dec 13, 2015 10:50 AM, "matmenu"  wrote:
>
> > Hi Ton,
> >
> > Thank you for keeping Scons for one release more. At the moment, on
> > windows, the home-made cmake build give very different results from the
> > buildbot/official ones. No Ocean modifier, etc... while the Scons builds
> > give a build with the exact same functionality and build parameters as
> > the official ones. Please make sure the windows cmake configuration is
> > the exact same as the official/buildbot ones to help us switch.
> >
> > Regards,
> > Mat
> >
> >
> > Am 13/12/2015 um 16:28 schrieb Ton Roosendaal:
> > > Hi all,
> > >
> > > Again a short meeting today in irc.freenode.net #blendercoders!
> > >
> > > 1) Blender 2.77 targets
> > >
> > > - Project page did not change much:
> > > http://wiki.blender.org/index.php/Dev:Doc/Projects
> > >
> > > - Brecht van Lommel posted OpenGL 2.1 recode tasks for volunteers to
> > pick up:
> > >
> http://lists.blender.org/pipermail/bf-viewport/2015-December/75.html
> > >
> > > - Kevin Dietrich picked up Smoke Volume GLSL code.
> > >
> > > - Joshua Leung committed his GPencil work for 2.77
> > > http://wiki.blender.org/index.php/Dev:Ref/Release_Notes/2.77/GPencil
> > >
> > >
> > > 2) Other projects
> > >
> > > - Proposal: drop Scons for when we move to 2.8 (branches) but keep it
> > for the 2.7x series.
> > >
> > > Thanks,
> > >
> > > -Ton-
> > >
> > > 
> > > Ton Roosendaal  -  t...@blender.org   -   www.blender.org
> > > Chairman Blender Foundation - Producer Blender Institute
> > > Entrepotdok 57A  -  1018AD Amsterdam  -  The Netherlands
> > >
> > >
> > >
> > > ___
> > > Bf-committers mailing list
> > > Bf-committers@blender.org
> > > http://lists.blender.org/mailman/listinfo/bf-committers
> >
> > ___
> > Bf-committers mailing list
> > Bf-committers@blender.org
> > http://lists.blender.org/mailman/listinfo/bf-committers
> >
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Blender developers meeting notes, November 29, 2015

[Martijn Berger]

BGL already almost has a mechanism for doing this the calls. The legacy
calls are already separated out just the mechanism for enabling / disabling
this has still to be decided.

Ill try and make a proposal to add some call to bgl itself to hide them or
warn or something.


On Sun, Nov 29, 2015 at 7:23 PM, Antony Riakiotakis <kal...@gmail.com>
wrote:

> When we switch to core profile, legacy GL calls will not be supported
> at all from the driver. To solve this, Martijn proposed to have a
> deprecation mode for a few versions that would prohibit use of
> deprecated functions from python (probably error out when accessing
> them with a warning).
>
>
> On 29/11/2015, Dalai Felinto <dfeli...@gmail.com> wrote:
> > Hi,
> > A small question regarding the OpenGL project:
> >
> >  > "Work now progresses on removing 'immediate mode' calls (glBegin,
> > glEnd), and on defining how to use shaders everywhere"
> >
> > How does that affect Python addons? Can immediate mode still be used via
> > bgl? Or it's not recommended (not guaranteed to work in all OSs)?
> >
> > Thanks,
> > Dalai
> > On Nov 29, 2015 14:02, "Ton Roosendaal" <t...@blender.org> wrote:
> >
> >> Hi all,
> >>
> >> Here are the (short) notes of today's meeting in irc.freenode.net
> >> #blendercoders
> >>
> >> 1) Work on 2.77
> >>
> >> - Project page with planning:
> >>   http://wiki.blender.org/index.php/Dev:Doc/Projects
> >> (As agreed on, 2.77 has not been scheduled yet)
> >>
> >> - Bastien Montagne reports good progress on library referencing
> >> improvements:
> >>
> >>
> http://code.blender.org/2015/11/test-build-live-reloading-relocating-of-libraries/
> >> (Might go to 2.77 if testing goes well)
> >>
> >> 2) Other projects and 2.8 preparations
> >>
> >> - Migrating to OpenGL 2.1 has started.
> >>
> >> - We're now officially on 2.1 minimal! Meaning that the old 'extension'
> >> (compatibility) API calls
> >> are gone. Work now progresses on removing 'immediate mode' calls
> >> (glBegin,
> >> glEnd), and on defining
> >> how to use shaders everywhere.
> >>
> >> - Mike Erwin will write (today!) a wiki page - to log and report on
> >> OpenGL
> >> work, also as dashboard to
> >> give people insight what they can do to help. Code upgrading is fun work
> >> for which a lot of people
> >> can contribute. Check the wiki project page later today for the correct
> >> page link.
> >>
> >> - If you want to get involved: join the coders IRC channel, or the
> >> viewport list:
> >> http://lists.blender.org/mailman/listinfo/bf-viewport
> >>
> >> - After the meeting, a group discussed key aspects of the work ahead...
> >> viewport team members so-far:
> >> Mike Erwin, Antony Ryakiotakis, Brecht van Lommel, Inez Almeida, Martijn
> >> Berger. Thomas Dinges is
> >> available to help. Jason Wilkins is inactive currently but welcome to
> >> join!
> >>
> >> Laters,
> >>
> >> -Ton-
> >>
> >> 
> >> Ton Roosendaal  -  t...@blender.org   -   www.blender.org
> >> Chairman Blender Foundation - Producer Blender Institute
> >> Entrepotdok 57A  -  1018AD Amsterdam  -  The Netherlands
> >>
> >>
> >>
> >> ___
> >> Bf-committers mailing list
> >> Bf-committers@blender.org
> >> http://lists.blender.org/mailman/listinfo/bf-committers
> >>
> > ___
> > Bf-committers mailing list
> > Bf-committers@blender.org
> > http://lists.blender.org/mailman/listinfo/bf-committers
> >
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] proposal: OpenGL cleanup in master

[Martijn Berger]

Mesa supports opengl 3.3 in software. -> http://mesamatrix.net/

I think we should even consider just taking SandyBridge intel as baseline
-> http://www.g-truc.net/post-0729.html.

I agree with Brechts reasoning here and think we should do this now and in
master.





On Sun, Nov 22, 2015 at 11:13 AM, Bastien Montagne 
wrote:

> I’m not much an OGL guy, but fully support the proposal as well, think
> past attempts have shown trying to keep at all cost compatibility with
> very old standards just end up making evolution to modern ones
> impossible… Having a nine years old version as ground mandatory basis
> sounds totally reasonable. And afaik, MESA software is at least 100%
> implemented for OGL 3.3?
>
> Le 22/11/2015 03:11, Thomas Dinges a écrit :
> > I fully support this proposal, it's time to get work done and stop
> > worrying about ancient hardware.
> >
> > Am 22.11.2015 um 01:40 schrieb Mike Erwin:
> >> Cool, glad for the enthusiasm!
> >>
> >> It might affect a few users on Windows or Linux, but all Mac OS 10.5 and
> >> newer systems have GL 2.1 built in. Old low-end Macs might fall back to
> >> software rendering for certain features but won't throw an error or
> catch
> >> on fire.
> >>
> >> That set of Radeons Brecht listed support up to GL 3.3 so should all
> work
> >> in Blender 2.8 too! I'm not as familiar with nVidia's stuff.
> >>
> >> Mike Erwin
> >> musician, naturalist, pixel pusher, hacker extraordinaire
> >>
> >> On Sat, Nov 21, 2015 at 4:55 PM, Antony Riakiotakis 
> >> wrote:
> >>
> >>> Yes, let's do it for 2.77. We are supposed to be able to break
> >>> compatibility now since we are transitioning to 2.8. I know people are
> >>> reluctant to drop compatibility because of the flak from a few users
> >>> with old hardware but we won't be able to do anything if we keep
> >>> postponing changes here.
> >>>
> >>> I suggest we make official final decision tomorrow in meeting. I hope
> >>> there is no more time needed to consider things here, this has been
> >>> discussed again and again during the last year and most people agree
> >>> with the change.
> >>>
> >>> Then it's GHOST patch time and finally everyone can start refactoring
> >>> code with shaders for fancy UI and display stuff :).
> > ___
> > Bf-committers mailing list
> > Bf-committers@blender.org
> > http://lists.blender.org/mailman/listinfo/bf-committers
> >
>
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Introduction and CMake refactoring

[Martijn Berger]

Hi  Steve,

Welcome,

You may or may not be aware that we want to work towards making CMake
feature complete versus our Scons buildsystem in order to facilitate
dropping Scons.

You talk about modernizing but what versions of CMake would this raise our
requirement to?

Martijn



On Sun, Nov 8, 2015 at 11:54 PM, Stephen Kelly  wrote:

> Hello,
>
> Today I was on IRC just before the weekly meeting and discussed some issues
> regarding the CMake buildsystem. We worked together on creating the issue
>
>  https://developer.blender.org/T46725
>
> Campbell Barton helped me out with a contributor account to allow me to
> push
> to blender-staging to implement it. I'll work together with Campbell on the
> specifics of the task, and longer-term perhaps work on modernising the
> CMake
> buildsystem in a larger way. If you have any questions about T46725, feel
> free to ask. I am subscribed to the mailing list.
>
> For the last 4 years I've been working in mostly personal time on upstream
> CMake, shifting it towards interfaces which are target scoped (eg commands
> like target_include_directories) instead of directory scoped (eg, commands
> like include_directories, which affect all targets in a directory), and
> implementing usage-requirements to make it easier to define and maintain
> buildsystems with many dependent targets.
>
> For the last 6 years, I've been the maintainer of the Qt model-view
> framework and the Qt CMake integration. I've touched many parts of Qt
> through my previous job where I worked as a Qt consultant. For some years
> prior to and during that time I was also active in KDE, in particular
> KDEPIM
> and kdelibs (now KDE Frameworks).
>
> I'm very familiar with git, mailing lists, reviews, cmake and C++ (and
> python, like everyone :) ), but I have quite some learning to do regarding
> phabricator, opengl, and 3d modelling generally, so those are the topics
> I'm
> likely to be asking about on IRC.
>
> I've been interested in blender for some time because I would like to learn
> more about 3d. I expect the buildsystem work will give me the excuse to
> explore the codebase, and then I hope to dig into the interesting features
> of blender.
>
>  https://developer.blender.org/p/steveire/
>
> Hello!
>
> Steve.
>
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Some Ideas for a Blender Plugin System

[Martijn Berger]

Hi all,

If we want to go for speed.

On Thu, Nov 5, 2015 at 3:16 PM, François T. 
wrote:

> - Cython does not have as much performance as pure C/C++
>

While this is true even making the RNA api accessible through cython would
be a step up compared to current situation


> - Python is still the best choice for prototyping and pipeline stuff
> - C/C++ API can be used for better performance without having the nightmare
> to dive into Blender core code to just add one modifier
>

Main problem I see here is that keeping such an API stable is a non trivial
job

>
> Most of the modifier we are developping in Maya are first done in Python,
> but then it is port to C++ for performance matter. Same approach would be
> nice in Blender.
>


>
> And in some cases like sharing code for importer/exporter in alembic, fbx
> would be more easier if it was done as a plugin rather than being embeded
> in our blender build
>

As we discussed on the blender conference I think your Alembic work might
actually be useful by attempting to port it to our existing RNA C++-API and
see what work needs to be done on that API in that way.
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Installer for Windows is not signed

[Martijn Berger]

No they where never signed. The issue is getting a cert. Once we have that
singing is trivial.
On 16 Oct 2015 03:11, "Mike Erwin"  wrote:

> Weren't other recent releases signed though? It is kind of unnerving when
> Windows pops up a "Do you trust this Unknown Developer?" alert during
> installation.
>
> Mike Erwin
> musician, naturalist, pixel pusher, hacker extraordinaire
>
> On Thu, Oct 15, 2015 at 7:34 PM, Aaron Carlisle <
> carlisle.aaro...@gmail.com>
> wrote:
>
> > Yes Blender is a safe program
> >
> > On Thu, Oct 15, 2015 at 10:07 AM, Yury Baranov 
> > wrote:
> >
> > > Hi. I just mentioned that installer is not signed by developer. Is it
> OK?
> > > ___
> > > Bf-committers mailing list
> > > Bf-committers@blender.org
> > > http://lists.blender.org/mailman/listinfo/bf-committers
> > >
> > ___
> > Bf-committers mailing list
> > Bf-committers@blender.org
> > http://lists.blender.org/mailman/listinfo/bf-committers
> >
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] mac OSX 10.10.5 and Xcode 7 cmake fix

[Martijn Berger]

I think this aggressive updating policy on Apple's part could be a real
problem for us.

uname -r on OS X 10.10.5 does give 14.5
and xcode 7 is released. I do not really get the "The patch moves
requirenment for a new CMake from 14.0 to 14.5" comment though

Martijn

On Mon, Sep 21, 2015 at 11:28 AM, Campbell Barton 
wrote:

> On Mon, Sep 21, 2015 at 6:46 PM, Sergey Sharybin 
> wrote:
> > Levon, is the OSX and new XCode officially released or they're still on
> the
> > beta state?
> >
> > In any case, the patch lacks two things:
> >
> > - SCons needs support of new XCode as well
> > - The patch moves requirenment for a new CMake from 14.0 to 14.5
> >
> > Campbell, don't think we really looked into making XCode detection
> smarter
> > in CMake. It's probably possible, but to me patch is good enough (apart
> > form two points raised above).
>
> CMake already does this detection, LLVM AFAICS isn't hard coding the
> paths with its CMake files, we can likely avoid it as well.
>
> > I would be conservative here storngly suggest not doing more global
> changes
> > here unless it's done by someone who actually uses the platform, ready to
> > solve regressions and so on.
>
> Yep, this goes without saying. Martijn would need to double check its
> working properly before applying.
>
> > On Mon, Sep 21, 2015 at 1:49 PM, Campbell Barton 
> > wrote:
> >
> >> This is problematic (not your patch, that its checking for exact OSX
> >> versions in the first place).
> >>
> >> This means you can't build older Blender versions on a new system,
> >> which is needed for bisecting.
> >> At least not easily, without manually editing the CMakeLists.txt file
> each
> >> step.
> >>
> >> Did anyone look into using CMake's ability to detect the SDK on OSX?
> >>
> >> It looks like this is supported:
> >>
> >> -
> >>
> https://github.com/Kitware/CMake/blob/master/Modules/Platform/Darwin-Initialize.cmake#L72
> >> - http://www.cmake.org/cmake/help/v3.3/variable/CMAKE_OSX_SYSROOT.html
> >>
> >> Of course the patch can be applied, but would prefer if this
> >> workaround could be avoided altogether.
> >>
> >> On Mon, Sep 21, 2015 at 4:52 PM, Levon  wrote:
> >> > Overnight my computer auto updated to OSX 10.10.5 (from 10.10.4) and
> to
> >> > Xcode 7.0. even though auto updates were turned off.
> >> >
> >> > OSX 10.10.5 and xcode 7.0 introduce a new SDK version of 10.11 which
> >> > src/blender/CMakeLists.txt is not aware of.
> >> >
> >> >
> >> > Fortunately uname -r reports the system as 14.5 now.
> >> >
> >> > patch to fix it.
> >> >
> >> > https://developer.blender.org/differential/diff/5081/
> >> >
> >> > Levon
> >> > ___
> >> > Bf-committers mailing list
> >> > Bf-committers@blender.org
> >> > http://lists.blender.org/mailman/listinfo/bf-committers
> >>
> >>
> >>
> >> --
> >> - Campbell
> >> ___
> >> Bf-committers mailing list
> >> Bf-committers@blender.org
> >> http://lists.blender.org/mailman/listinfo/bf-committers
> >>
> >
> >
> >
> > --
> > With best regards, Sergey Sharybin
> > ___
> > Bf-committers mailing list
> > Bf-committers@blender.org
> > http://lists.blender.org/mailman/listinfo/bf-committers
>
>
>
> --
> - Campbell
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Lack of coordination and communication in Blender development

[Martijn Berger]

Hi Kai,

As far as I am aware nothing has happened behind closed doors so far.
Everyone is trying to give input of wildly varying levels of quality.
It would be good if you could put together a (partial) proposal or at least
a list of things you think you need (based on current limitations?) in
order to successfully integrate the fracture modifier.

The 2.8 process has only just begun and it seems early to be wanting
guarantees to be heard or making assertions that the core team is not
listening.
I would suggest to any and all people wanting to influence what happens
next, make a good (partial) proposal or at least try and describe the
current limitation you feel should be addressed.

Martijn

On Sat, Aug 15, 2015 at 8:20 PM, Kai Kostack kaikost...@gmx.net wrote:

 Hello Marc,

 I appreciate your answer but we're aware of what you're explaining. We
 have a more fundamental problem.

 Currently there is a redesign of various Blender internals ongoing. Design
 decisions will be made that are crucial for our modifier to meet all
 required coding conventions. Our workarounds have been criticized as bad
 by core developers earlier. However, those hacks have been necessary until
 now because it couldn't be solved otherwise due to bad Blender design.

 So, now that there is the chance to fix those issues in depth we would
 like to monitor that design decision making process and comment early on on
 it to make sure, they don't oversee some requirements that will be
 important for us in the future.

 At the moment it looks like everything important happens behind closed
 doors.

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

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

Re: [Bf-committers] Is MSVC2008 still to be supported?

[Martijn Berger]

On Mon, Jun 22, 2015 at 1:50 AM, Campbell Barton ideasma...@gmail.com
wrote:

 Does this mean we still support MSVC2012?


If you build all the libs blender still compiles with this as far as I am
aware


 Does it use the same libs as MSVC2013?


No ABI is not the same


 Seems we already dropped 2008.
 http://lists.blender.org/pipermail/bf-committers/2014-June/043807.html
 https://developer.blender.org/D715


Yes, thx for finding that.. that is what i referred to when saying I think
some people actually started cleaning up work-arounds for ancient MSVC


 However its not great to have to trawl old messages to know about
 supported compilers.


Yes, that is my fault. I will look at wiki.


 Added a section in the wiki for this (OSX needs versions filled in)


 http://wiki.blender.org/index.php/Dev:Doc/Building_Blender#Compiler_Versions



I think we should also consider dropping GCC 4.2 on apple as it would
quality as the lowest common denominator and Apple seems to peruse a pretty
aggressive upgrade campaign with OS X yearly releases.


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

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

Re: [Bf-committers] Is MSVC2008 still to be supported?

[Martijn Berger]

Hi Campbell,

I think some people actually started cleaning up work-arounds for ancient
MSVC 's not sure if 2008 still builds.
I think of all pre 2012 versions as ancient and to broken to want to
support. Whole reason for doing MSVC 2013 work was to move up the lowest
common denominator for everyone.

I would like to propose officially abandoning 2005, 2008, 2010 versions of
MSVC.

Martijn




On Sat, Jun 20, 2015 at 12:56 PM, Campbell Barton ideasma...@gmail.com
wrote:

 Hi, I was under the impression MSVC2008 was dropped (committed removal
 of some MSVC version checks).
 But looks like there wasn't official decision here?

 Is the intention to keep supporting MSVC2008?
 Is anyone using it for development?

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

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

Re: [Bf-committers] Building with OpenVDB and OSL: a Boost case

[Martijn Berger]

Hi Kevin,

I want to do a coordinated effort to upgrade the windows and OS X libraries
after 2.75 is out the door.
In addition to openvdb, Alembic might need to be included, also updates to
llvm, boost, osl, oiio, and maybe other might be in order.
(OpenSubDiv and PTex I am now sure about (for ptex we use OIIO i think ?))

I am fine with bumping boost to 1.57 for windows / OS X but I am not sure
about linux.
For Linux It seems to me that it is to new and that we should try to keep
boost 1.48 minimal requirement if we can.
If that is unfeasible we should bump no higher then 1.54 for linux as then
we have debian and ubuntu stable to consider.

Martijn





On Mon, Jun 15, 2015 at 4:09 AM, Kévin Dietrich kevin.dietr...@mailoo.org
wrote:



 Hi all,

 I mail here because it can affect anyone who builds Blender, not just
 the Cycles freaks ;)

 As a reminder, OpenVDB is making use of, and relies on libraries making
 use of, C++ built-in run-time type information (RTTI). On the other
 hand, LLVM (used by OSL) has a home brew version and does not want to
 hear about the built-in one by default.

 The most straightforward way to address this is by building LLVM with
 RTTI enabled, and build OSL accordingly.

 But that's maybe not a possibility (because of a lot of reasons), so
 RTTI usage in VDB will need to be taken care of. By compiling Cycles
 with both VDB and OSL it appears that most RTTI symbols that give issues
 are in everyone's favorite library: Boost (I have version 1.54 here).
 There's also one in TBB, but it can be avoided by disabling the use
 exceptions there.

 Although patching OpenVDB so it compiles fine with RTTI disabled is a
 no-brainer (~10 changes), we will need to upgrade boost to at least
 version 1.57. Which should also comprise the fix for the Windows compile
 issue raised by Antony.

 I've just installed it, and as far as I can tell, it seems to work fine
 (_YMMV_). I've forked the openvdb repository, so to test things out you
 can get my changes from there (https://github.com/diekev/openvdb [1]) in
 the 'cycles_fixes' branch (it will also contain fixes for implicit float
 conversions happening in the library, which make Cycles grumpy). So if
 we go with boost 1.57, or above, and everything goes fine on all
 platforms, I'll make a pull request.

 That's it from me for the moment,
 Cheers,
 Kévin.


 Links:
 --
 [1] https://github.com/diekev/openvdb
 ___
 Bf-committers mailing list
 Bf-committers@blender.org
 http://lists.blender.org/mailman/listinfo/bf-committers

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

Re: [Bf-committers] Building with OpenVDB and OSL: a Boost case

[Martijn Berger]

Hi,


On Mon, Jun 15, 2015 at 4:09 AM, Kévin Dietrich kevin.dietr...@mailoo.org
wrote:



 Although patching OpenVDB so it compiles fine with RTTI disabled is a
 no-brainer (~10 changes), we will need to upgrade boost to at least
 version 1.57. Which should also comprise the fix for the Windows compile
 issue raised by Antony.


I think we should try to upstream this change so other can also benefit
from it and we will not have to maintain a patch set for OpenVDB

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

Re: [Bf-committers] Blender performance measuring instrumentation improvement proposal

[Martijn Berger]

Hi Sergey,

I agree that the overall timer + playback has limited use cases compared to
proper full instrumentation of all parts of blender.
But I don't really suggest it does.

What things would be good to be able to make this thing do in order to
extract better information?

Martijn

On Wed, Jun 10, 2015 at 1:38 PM, Sergey Sharybin sergey@gmail.com
wrote:

 I didn't say it's difficult, i only mentioned that it is to be thought much
 more careful defining which exact information is useful for us and how to
 gather it.

 On Wed, Jun 10, 2015 at 1:25 PM, Campbell Barton ideasma...@gmail.com
 wrote:

  Hi Martijn, think its fine to have more comprehensive performance tests
  (which can include extending, bpy.ops.wm.redraw_timer or add related
  operators to give more comprehensive info).
 
  This seems like 2 separate projects,
 
  - ability to perform tests and collect feedback.
  - extend existing performance tests.
 
  Second needs review of each kind of test added, but that can be done
  on case-by-case basis, to see whats really useful to measure.
 
 
  Ability to execute operators directly from command line is handy,
  uploaded patch.
  https://developer.blender.org/D1347
  ___
  Bf-committers mailing list
  Bf-committers@blender.org
  http://lists.blender.org/mailman/listinfo/bf-committers
 



 --
 With best regards, Sergey Sharybin
 ___
 Bf-committers mailing list
 Bf-committers@blender.org
 http://lists.blender.org/mailman/listinfo/bf-committers

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

Re: [Bf-committers] Blender performance measuring instrumentation improvement proposal

[Martijn Berger]

Hi Sergey,

On Wed, Jun 10, 2015 at 12:47 PM, Sergey Sharybin sergey@gmail.com
wrote:

 It doesn't seem to be so much an improvement to be honest, such a test will
 be more or less about nothing. It shouldn't be full testing, it should be
 per-area time measuring. For example, we could speedup viewport opengl
 display but accidentally slowdown dependency graph and having just an
 aggregated number will tell you simply nothing.


Yes this could be an issue. But I still think it is also useful to measure
the whole application performance.


 it is also important to setup a strictly controlled environment for such
 tests if we want the numbers to mean anything. Otherwise we'll end up with
 folks reporting speed regressions in blender while it might be just new
 antivirus application being installed on their desktop.


This argument could be made about all possible ways to do this. The numbers
produced by some random user and posted on a forum somewhere have little
meaning always no matter how you look at it.


 Surely if we'll have such an environment setup then it'll be handy, but the
 proposal for it needs much more work i'm afraid.



What exactly you think is difficult?
Unlocking the max fps or making interface frames map to animation frames on
a 1 to 1 basis ?
It could maybe help if you could provide additional technical oriented
feedback to that?



 On Wed, Jun 10, 2015 at 12:09 PM, Martijn Berger martijn.ber...@gmail.com
 
 wrote:

  Hello everyone,
 
 
  Blender is evolving at a rather nice pace currently but I feel we could
 use
  better measurements to guide its the performance aspect of this a bit
  better.
 
  Some 3d games (like quake) have a feature called “timedemo” this
 basically
  runs the game as fast as the hardware will let it run. I tried doing
  something similar in blender and found a number of little things that
 maybe
  could be tweaked to make this possible.
 
  Overview of how this would work:
 
  The user runs the command:
 
  “blender --factory-startup --python-expr=import bpy;
  bpy.ops.debug_timer(type='FULLTEST', report=True); sys.exit(0);
  demo_scene.blend”
 
  The following happens:
 
 
 1.
 
 Blender starts and loads demo_scene.blend
 2.
 
 Blender executes the python expression passed to it
 3.
 
 debug_timer() is invoked:
 1.
 
Move animation counter to the start of the range
2.
 
unlock max fps ( if vsync is disabled this allows very high
framerates)
3.
 
Gets an accurate time measurement
4.
 
Run the animation and render 1 OpenGL frame per frame of animation
5.
 
At the end of the range, capture time again
6.
 
Print this time ( to stdout ?)
4.
 
 sys.exit(0), exit blender
 
 
  What we need for this to work:
 
 
 1.
 
 implement bpy.ops.debug_timer()
 2.
 
 Allow higher then 120 fps for animation playback
 3.
 
 Not sure, if we allow gl frames to be locked to blender animation
 frames
 4. (optional) implement ‘python-expr’ command line argument
 
 
 
  I might have missed stuff but the purpose of this message is to inform
 and
  discus the possibility as well as map out the bits and pieces that need
 to
  be done in order to get this functionality.
 
  I think something like this could also be instrumental in achieving high
  performance in the viewport project.
 
 
  Martijn
  ___
  Bf-committers mailing list
  Bf-committers@blender.org
  http://lists.blender.org/mailman/listinfo/bf-committers
 



 --
 With best regards, Sergey Sharybin
 ___
 Bf-committers mailing list
 Bf-committers@blender.org
 http://lists.blender.org/mailman/listinfo/bf-committers

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

[Bf-committers] Blender performance measuring instrumentation improvement proposal

[Martijn Berger]

Hello everyone,


Blender is evolving at a rather nice pace currently but I feel we could use
better measurements to guide its the performance aspect of this a bit
better.

Some 3d games (like quake) have a feature called “timedemo” this basically
runs the game as fast as the hardware will let it run. I tried doing
something similar in blender and found a number of little things that maybe
could be tweaked to make this possible.

Overview of how this would work:

The user runs the command:

“blender --factory-startup --python-expr=import bpy;
bpy.ops.debug_timer(type='FULLTEST', report=True); sys.exit(0);
demo_scene.blend”

The following happens:


   1.

   Blender starts and loads demo_scene.blend
   2.

   Blender executes the python expression passed to it
   3.

   debug_timer() is invoked:
   1.

  Move animation counter to the start of the range
  2.

  unlock max fps ( if vsync is disabled this allows very high
  framerates)
  3.

  Gets an accurate time measurement
  4.

  Run the animation and render 1 OpenGL frame per frame of animation
  5.

  At the end of the range, capture time again
  6.

  Print this time ( to stdout ?)
  4.

   sys.exit(0), exit blender


What we need for this to work:


   1.

   implement bpy.ops.debug_timer()
   2.

   Allow higher then 120 fps for animation playback
   3.

   Not sure, if we allow gl frames to be locked to blender animation frames
   4. (optional) implement ‘python-expr’ command line argument



I might have missed stuff but the purpose of this message is to inform and
discus the possibility as well as map out the bits and pieces that need to
be done in order to get this functionality.

I think something like this could also be instrumental in achieving high
performance in the viewport project.


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

Re: [Bf-committers] Is Python.exe provided, too?

[Martijn Berger]

Hi,

http://wiki.blender.org/index.php/Dev:Doc/Projects lists it as a release
target, so the answer is Yes.


kr,

Martijn

On Mon, Jun 1, 2015 at 6:25 AM, PerfectionCat sindra1961reb...@yahoo.co.jp
wrote:

 Hi, Devs.

 Python.exe seems to be included in a latest daily build version, but is it
 contributed in the following version?

 Best Regards.
 PerfectionCat
 ___
 Bf-committers mailing list
 Bf-committers@blender.org
 http://lists.blender.org/mailman/listinfo/bf-committers

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

[Bf-committers] [Windows] Reminder to update svn

[Martijn Berger]

Hi everyone,

Due to shipping python.exe the layout of the tar.gz containing the python
bits for the windows platform have changed.

Please update your SVN libraries if you are building blender on windows.

Martijn

P.S. Please excuse me for having to ask this as a first question in
response to any queries abuit windows building for the next few weeks. :)
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Proposal: Building blender using docker.io

[Martijn Berger]

Hi Jeroen,

I think that any and all things that make blender more easy / more
accessible to any group of people could be potentially helpful.
And that container / *a controlled environment* is a great things when
trying to get a better build process, that is also why the linux build of
blender is already build this way.
I think we should not restrict ourselves to  insert popular
containerization solution here , lets call it docker for now.
https://chimeracoder.github.io/docker-without-docker/#1 is a good
presentation about how (un)special docker is in this regard.
I think if you ask Sergey he can provide you with a tarball of the current
chroot used to build..
You could just add some docker sprinkles to it and have some of your goals
achieved.

Regards,

Martijn









On Tue, Apr 28, 2015 at 9:49 AM, Jeroen Bakker j.bak...@atmind.nl wrote:

 Hi all,

 I am using install_deps.sh to build blender on Linux systems. It is
 always a tedious work to get Blender compiling again when we upgrade an
 external library. I have solved this trick before using docker.io. the
 last week I started experimenting on using docker.io for compiling
 blender. I succeeded on an ubuntu 14.04 and 15.04 host.

 For now I created a proposal for this. My goal is to get more control
 over the software versions. Help developers to stick to their task (what
 is developing code). Make it easier for newbies to create their building
 environment.

 For more details please read the proposal at:
 http://wiki.blender.org/index.php/User:Jbakker/Blender_docker

 in order to get this project going:
 * ok if this is a valid target.
 * write documentation about using docker.io for compiling blender.
 * write scripts (Dockerfile) to recreate blender docker images
 * register these images in a public registry (so other users do not need
 to compile the images themself, but can download them)
 *  support from the community in testing.

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

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

Re: [Bf-committers] Latest release build 2.74 Installer seen as virus by Webroot SecureAnywhere

[Martijn Berger]

Hi Matthew,

I have looked up the file on
https://www.virustotal.com/nl/file/a526eca395adb4b82495aac2d2a59f43d13a265bc710cdbc4732a2f64a8c1191/analysis/
.
It looks like a false positive. I will triple check the build machine but
think it extremely unlikely that it got infected somehow.


Martijn

On Tue, Apr 7, 2015 at 4:18 AM, Matthew Gayton matthew.gay...@gmail.com
wrote:

 I downloaded the blender-2.74-883663a-win64 archive, and extracted to my
 desktop. No problem; I even ran a manual scan just to be sure and
 SecureAnywhere found nothing.

 On Mon, Apr 6, 2015 at 5:38 PM, Dalai Felinto dfeli...@gmail.com wrote:

  Out of curiosity, do you have the same issue with a build from
  builder.blender.org or only when the installer is involved?
  On Apr 6, 2015 17:58, Matthew Gayton matthew.gay...@gmail.com wrote:
 
   Greetings,
  
   My apologies in advance if I am sending this to the wrong area, but as
 it
   isn't really a bug I figure I would try here first.
  
   I have been using Blender for years and updating with the Windows 64
   release build as they are posted. However, this current one, 2.74
  installer
   for Win 64 systems is seen as a virus, with SecureAnywhere stating that
  it
   has found *W32.Adware.Somoto* and immediately quarantining the
  executable.
   I am downloading from https://www.blender.org/
  
   Just though someone there should know.
  
   -Matthew
   ___
   Bf-committers mailing list
   Bf-committers@blender.org
   http://lists.blender.org/mailman/listinfo/bf-committers
  
  ___
  Bf-committers mailing list
  Bf-committers@blender.org
  http://lists.blender.org/mailman/listinfo/bf-committers
 
 ___
 Bf-committers mailing list
 Bf-committers@blender.org
 http://lists.blender.org/mailman/listinfo/bf-committers

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

Re: [Bf-committers] Latest release build 2.74 Installer seen as virus by Webroot SecureAnywhere

[Martijn Berger]

These are the md5sums of the files as I have uploaded them.

248e9c295d386d408598d3561c64e0fc  blender-2.74-windows32.exe
97e942c28d27cc0812971b750900e017  blender-2.74-windows32.zip
c938183a62b7efdf03054b6431b8c4ae  blender-2.74-windows64.exe
72d9a1b54aee9d5034a47235675809be  blender-2.74-windows64.zip


Martijn

On Tue, Apr 7, 2015 at 11:58 AM, Martijn Berger martijn.ber...@gmail.com
wrote:

 Hi Matthew,

 I have looked up the file on
 https://www.virustotal.com/nl/file/a526eca395adb4b82495aac2d2a59f43d13a265bc710cdbc4732a2f64a8c1191/analysis/
 .
 It looks like a false positive. I will triple check the build machine but
 think it extremely unlikely that it got infected somehow.


 Martijn

 On Tue, Apr 7, 2015 at 4:18 AM, Matthew Gayton matthew.gay...@gmail.com
 wrote:

 I downloaded the blender-2.74-883663a-win64 archive, and extracted to my
 desktop. No problem; I even ran a manual scan just to be sure and
 SecureAnywhere found nothing.

 On Mon, Apr 6, 2015 at 5:38 PM, Dalai Felinto dfeli...@gmail.com wrote:

  Out of curiosity, do you have the same issue with a build from
  builder.blender.org or only when the installer is involved?
  On Apr 6, 2015 17:58, Matthew Gayton matthew.gay...@gmail.com
 wrote:
 
   Greetings,
  
   My apologies in advance if I am sending this to the wrong area, but
 as it
   isn't really a bug I figure I would try here first.
  
   I have been using Blender for years and updating with the Windows 64
   release build as they are posted. However, this current one, 2.74
  installer
   for Win 64 systems is seen as a virus, with SecureAnywhere stating
 that
  it
   has found *W32.Adware.Somoto* and immediately quarantining the
  executable.
   I am downloading from https://www.blender.org/
  
   Just though someone there should know.
  
   -Matthew
   ___
   Bf-committers mailing list
   Bf-committers@blender.org
   http://lists.blender.org/mailman/listinfo/bf-committers
  
  ___
  Bf-committers mailing list
  Bf-committers@blender.org
  http://lists.blender.org/mailman/listinfo/bf-committers
 
 ___
 Bf-committers mailing list
 Bf-committers@blender.org
 http://lists.blender.org/mailman/listinfo/bf-committers



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

Re: [Bf-committers] Building with openexr broken on windows 7?

[Martijn Berger]

Hi Gaia,

Most likely cmake is not correctly updating the vcxproj files.
I would try and run cmake from a fresh build directory and see if that
helps.

Martijn



On Fri, Feb 6, 2015 at 1:21 PM, Gaia gaia.cl...@machinimatrix.org wrote:

 hi.

 Since a couple of days i get this warning when i press Configure in
 the cmake tool (windows 7 64 bit):

  http://www.pasteall.org/56525

 And yes i have updated the libs from svn at lib/win64_vc12

 When i go ahead and build, i get a link error later (could not find the
 openexr libraries). Right now i can build blender when i disable

  WITH_IMAGE_OPENEXR

 Do i have to install the openexr libraries separately or is this a
 broken build?

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

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

Re: [Bf-committers] OpenEXR and OpenImageIO library bump

[Martijn Berger]

Hi Anthony,

I did test both scons and cmake and they worked however tortoise svn seems
to not always agree with me.
Ill fix this asap.

Martijn

P.S. Next time please pm me on irc so I see this sooner.

On Tue, Feb 3, 2015 at 3:25 PM, Antony Riakiotakis kal...@gmail.com wrote:

 Can someone build OSL against new OpenEXR? Looks like it's referenced
 from it as well.

 Also please make sure that blender compiles with updated libraries
 before committing - ideally both cmake and scons should be tested.

 On 31 January 2015 at 13:48, Sergey Sharybin sergey@gmail.com wrote:
  Upgraded libraries for linux. Didn't do anything special for ptex tho,
 that
  would need to have dedicate investigation anyway.
 
  On Fri, Jan 30, 2015 at 8:15 PM, Martijn Berger 
 martijn.ber...@gmail.com
  wrote:
 
  Hi everyone.
 
  I would like to propose bumping OpenEXR to 2.2 and OpenImage IO to
 1.4.16.
 
 
  OpenImageIO had a number of stability and compilation fixes particularly
  for msvc 2013 . newer and older versions of boost and static PTEX
  compilation.
 
  full changelog here -
   https://raw.githubusercontent.com/OpenImageIO/oiio/RB-1.4/CHANGES
 
 
  OpenEXR 2.2 has faster PIZ compression and 2 new algorithms for lossy
  compression by Dreamworks.
 
  In the case of OpenImageIO it is really a minor bump and there seem to
 be
  no issues based on my own testing on windows and linux.
  In the case of OpenEXR it is a minor version bump but I think having
  maximal file reading compatibility is worth the effort it takes to
 bump. (
  which is also not much based on my personal testing ).
 
  Attached is a patch for install_deps.sh that builds these versions.
 
  ___
  Bf-committers mailing list
  Bf-committers@blender.org
  http://lists.blender.org/mailman/listinfo/bf-committers
 
 
 
 
  --
  With best regards, Sergey Sharybin
  ___
  Bf-committers mailing list
  Bf-committers@blender.org
  http://lists.blender.org/mailman/listinfo/bf-committers
 ___
 Bf-committers mailing list
 Bf-committers@blender.org
 http://lists.blender.org/mailman/listinfo/bf-committers

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

[Bf-committers] OpenEXR and OpenImageIO library bump

[Martijn Berger]

Hi everyone.

I would like to propose bumping OpenEXR to 2.2 and OpenImage IO to 1.4.16.


OpenImageIO had a number of stability and compilation fixes particularly
for msvc 2013 . newer and older versions of boost and static PTEX
compilation.

full changelog here -
 https://raw.githubusercontent.com/OpenImageIO/oiio/RB-1.4/CHANGES


OpenEXR 2.2 has faster PIZ compression and 2 new algorithms for lossy
compression by Dreamworks.

In the case of OpenImageIO it is really a minor bump and there seem to be
no issues based on my own testing on windows and linux.
In the case of OpenEXR it is a minor version bump but I think having
maximal file reading compatibility is worth the effort it takes to bump. (
which is also not much based on my personal testing ).

Attached is a patch for install_deps.sh that builds these versions.
diff --git a/build_files/build_environment/install_deps.sh b/build_files/build_environment/install_deps.sh
index e4e360a..c22d534 100755
--- a/build_files/build_environment/install_deps.sh
+++ b/build_files/build_environment/install_deps.sh
@@ -209,14 +209,14 @@ OCIO_VERSION_MIN=1.0
 OCIO_FORCE_REBUILD=false
 OCIO_SKIP=false
 
-OPENEXR_VERSION=2.1.0
+OPENEXR_VERSION=2.2.0
 OPENEXR_VERSION_MIN=2.0.1
-ILMBASE_VERSION=2.1.0
+ILMBASE_VERSION=2.2.0
 OPENEXR_FORCE_REBUILD=false
 OPENEXR_SKIP=false
 _with_built_openexr=false
 
-OIIO_VERSION=1.4.11
+OIIO_VERSION=1.4.16
 OIIO_VERSION_MIN=1.4.0
 OIIO_FORCE_REBUILD=false
 OIIO_SKIP=false
@@ -485,9 +485,7 @@ BOOST_SOURCE=( http://sourceforge.net/projects/boost/files/boost/$BOOST_VERSION
 
 OCIO_SOURCE=( https://github.com/imageworks/OpenColorIO/tarball/v$OCIO_VERSION; )
 
-#OPENEXR_SOURCE=( http://download.savannah.nongnu.org/releases/openexr/openexr-$OPENEXR_VERSION.tar.gz; )
-OPENEXR_SOURCE=( https://github.com/mont29/openexr.git; )
-OPENEXR_REPO_UID=2787aa1cf652d244ed45ae124eb1553f6cff11ee
+OPENEXR_SOURCE=( http://download.savannah.nongnu.org/releases/openexr/openexr-$OPENEXR_VERSION.tar.gz; )
 ILMBASE_SOURCE=( http://download.savannah.nongnu.org/releases/openexr/ilmbase-$ILMBASE_VERSION.tar.gz; )
 
 #OIIO_SOURCE=( https://github.com/OpenImageIO/oiio/archive/Release-$OIIO_VERSION.tar.gz; )
@@ -1092,25 +1090,14 @@ compile_OPENEXR() {
   INFO Downloading OpenEXR-$OPENEXR_VERSION
   mkdir -p $SRC
 
-#  download OPENEXR_SOURCE[@] $_src.tar.gz
+  download OPENEXR_SOURCE[@] $_src.tar.gz
 
-#  INFO Unpacking OpenEXR-$OPENEXR_VERSION
-#  tar -C $SRC --transform s,(.*/?)openexr[^/]*(.*),\1OpenEXR-$OPENEXR_VERSION\2,x \
-#  -xf $_src.tar.gz
-
-  git clone ${OPENEXR_SOURCE[0]} $_src
+  INFO Unpacking OpenEXR-$OPENEXR_VERSION
+  tar -C $SRC -xf $_src.tar.gz
 
 fi
 
 cd $_src
-
-# XXX For now, always update from latest repo...
-git pull origin master
-
-# Stick to same rev as windows' libs...
-git checkout $OPENEXR_REPO_UID
-git reset --hard
-
 # Always refresh the whole build!
 if [ -d build ]; then
   rm -rf build
@@ -1130,7 +1117,7 @@ compile_OPENEXR() {
   cflags=-fPIC
 fi
 
-cmake $cmake_d -D CMAKE_CXX_FLAGS=$cflags -D CMAKE_EXE_LINKER_FLAGS=-lgcc_s -lgcc ../OpenEXR
+cmake $cmake_d -D CMAKE_CXX_FLAGS=$cflags -D CMAKE_EXE_LINKER_FLAGS=-lgcc_s -lgcc ../
 
 make -j$THREADS  make install
 
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Proposal: Up blender requirements to OpenGL 2.1

[Martijn Berger]

Hi everyone,

This is a great idea and should be effected as soon as possible ( 2.74 ).
As in practice blender does not run really well on graphics hardware that
is more then 10 years old anyway.
We can save ourselves a lot of bug reports and headaches by just adding a
check for this and warning users when we find less then OpenGL 2.1.
I am all for trying to keep blender accessible to a as large as possible
group of users.
But I think it is safe to say that anyone should have access to OpenGL 2.1
capable hardware as this translates to 10-11 year old hardware.





On Tue, Dec 30, 2014 at 4:49 PM, Antony Riakiotakis kal...@gmail.com
wrote:

 Hello again,

 The times of fixed function OpenGL pipeline have been very fun and
 happy, with coders trying to ingeniously hack the fixed function
 parameters to do the things they wanted.

 But I believe we are getting to the point where fixed function OpenGL
 starts holding us back. We already require GLSL support for some of
 the fancier features of blender, but probably it's time to feel free
 to consider shaders as the primary display mechanism if we want to,
 without needing to code fallbacks to a fixed function alternative.

 Especially anything that requires mixing multiple textures (such as
 texture painting with masks or brush overlays) or attributes in a non
 standard way is difficult without shaders.

 This is scheduled to happen as part of the viewport refactor, but
 having the hardware requirements there will enable us to do more
 improvements now.

 The proposal is not about throw away every legacy path next release,
 rather than assuming that users will need to have access to newer
 hardware from now on if they wish to access core features. Shader
 availability can be tested to avoid crashes but no alternative
 rendering path should be provided for those not meeting the
 requirements.
 ___
 Bf-committers mailing list
 Bf-committers@blender.org
 http://lists.blender.org/mailman/listinfo/bf-committers

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

Re: [Bf-committers] CUDA Toolkit Update (Windows + Linux)

[Martijn Berger]

Hi Thomas,

This is of course already taken care of ( the installing cuda part)
I experimented with the fatbin and I am not sure it is actually that
useful.. Adding a sm5x ptx and loading that if all else fails does seem
useful but that is not the same as fatbin.


Martijn


On Tue, Dec 2, 2014 at 10:20 AM, Thomas Dinges blen...@dingto.org wrote:

 As 2.73 will be mainly a maintenance release, I would ask you to update
 the Toolkit on the Buildbots (Linux and Windows), so we can enable the
 sm_52 kernel.
 Further changes (like fatbin) can go to 2.74.

 I would appreciate it Sergey and Martijn. :)

 Thanks,
 Thomas

 Am 23.11.2014 um 08:42 schrieb Thomas Dinges blen...@dingto.org:

  Fixing SSS would of course be the best solution, but I think that is
  more a long term project.
  I think for now we should just build the extra sm_52 kernel. Although I
  like your last suggestion as well (build fatbin and let users of sm5x
  optimize themselves).
 
  Some further food for fought:
  * We only support sm_20 and above (Geforce 400 series), which was
  released in 2010. I think 4-8 GB RAM was pretty standard back then
 already.
  * We could save some kernel compilation time for 32bit Blender, by
  dropping CUDA support there. I don't think that GPU rendering + 32bit
  environment is common. And again, we only have to look back to 2010.
  64bit CPUs + OS were common back then already.
 
  Am 20.11.2014 um 09:55 schrieb Sergey Sharybin:
  Technically it's easy. The only thing which is worrying is we'll have 12
  kernels to be compiled now.
 
  Just to mention, fatbin is not gonna to help really. The thing here is
 ptx
  is really fast to compile, it's optimization to a specific arch takes
 loads
  of ram and time, So if we ship ptx with just ptx that'd mean users would
  need to have 8 gig to be able to get optimized code (which then being
  cached btw). it's not that nice at all.
 
  We can also look into making SSS more or less stable on GPU, or just
  declare GPUs not being feature-full. CMJ i don't think would give any
  issues btw.
 
  Another idea could be optimizing sm_20-sm_35 in the fatbin, users of
 sm_50,
  sm_52 would optimize on first render. They probably have enough ram for
  this :) A bit cruel i know, just throwing ideas for brainstorm of how to
  improve the situation.
 
  P.S. i don't mean we shouldn't switch to fatbin, that'd help making
 blender
  users to early users of new GPUs.
 
  On Thu, Nov 20, 2014 at 3:41 AM, Thomas Dinges blen...@dingto.org
 wrote:
 
  Hey,
  in order to support Geforce 9xx cards optimally, we should update the
  CUDA Toolkit (Release  Buildbot) and compile native sm_52 kernels.
 
  Sergey, Martijn, can you please update the buildbots?
  https://developer.nvidia.com/cuda-downloads-geforce-gtx9xx
  This version is equal to the 6.5.14 we use atm, but adds support for
  sm_52. So it should be a smooth and safe update.
 
  There is no version for Mac, but I think the 9xx cards are not
 available
  yet for Mac anyway.
 
  Thanks,
  Thomas
  ___
  Bf-committers mailing list
  Bf-committers@blender.org
  http://lists.blender.org/mailman/listinfo/bf-committers
 
 
 
 
  ___
  Bf-committers mailing list
  Bf-committers@blender.org
  http://lists.blender.org/mailman/listinfo/bf-committers

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

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

[Bf-committers] Windows platform things to do before 2.73

[Martijn Berger]

Hi everyone,

I would like to propose

- actually checking the OpenGL context when starting up blender.
   - fatal error when less then the required OpenGL 1.4 is found.
   - warning when less then OpenGL 2.1 is found (Nvidia  NV30 released in
2003)

 There are some technical issue with giving the fatal error as it might
be best to use an OS dependent dialog box explaining that blender cannot
run on windows at least.
 Mac OS X is unaffected as all versions we support guarantee at least
this capability.

 On windows at least this would make sure the bugs reported by people
using GDI driven OpenGL 1.1 will not happen. Also it would get our users
who still use blender on an pentium 3 with windows XP the ability to adjust
to the fact that it might not always continue to work with the latest and
greatest.

- getting rid of the launcher.
  On windows we have a binary launcher that exists only to set an OPENMP
related environment variable.
  I would like to get rid of this again in favour of setting it in the
short-cut or setting the variable globally during install.
  Also we could and should check for this in the System Info.


Both of these issues touch on the issue of giving the user feedback about
his or her system configuration / hardware / settings and how they might
negatively impact blenders performance. I would like feedback on how to
handle these.

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

Re: [Bf-committers] Windows platform things to do before 2.73

[Martijn Berger]

Hi Antony,

For the record. I would plan 2 options during installing,
1) set globally
2) set in shortcut

And if it is not set correctly blender might warn about this ( not sure how
that would work from UI perspective though ).



On Tue, Nov 25, 2014 at 3:15 PM, Antony Riakiotakis kal...@gmail.com
wrote:

 I'm not sure if setting the OpenMP variable system wide is a nicer solution
 than what we have, but +1 from me on warning about crappy OpenGL.

 On 25 November 2014 at 14:49, Martijn Berger martijn.ber...@gmail.com
 wrote:

  Hi everyone,
 
  I would like to propose
 
  - actually checking the OpenGL context when starting up blender.
 - fatal error when less then the required OpenGL 1.4 is found.
 - warning when less then OpenGL 2.1 is found (Nvidia  NV30 released in
  2003)
 
   There are some technical issue with giving the fatal error as it
 might
  be best to use an OS dependent dialog box explaining that blender cannot
  run on windows at least.
   Mac OS X is unaffected as all versions we support guarantee at least
  this capability.
 
   On windows at least this would make sure the bugs reported by people
  using GDI driven OpenGL 1.1 will not happen. Also it would get our users
  who still use blender on an pentium 3 with windows XP the ability to
 adjust
  to the fact that it might not always continue to work with the latest and
  greatest.
 
  - getting rid of the launcher.
On windows we have a binary launcher that exists only to set an OPENMP
  related environment variable.
I would like to get rid of this again in favour of setting it in the
  short-cut or setting the variable globally during install.
Also we could and should check for this in the System Info.
 
 
  Both of these issues touch on the issue of giving the user feedback about
  his or her system configuration / hardware / settings and how they might
  negatively impact blenders performance. I would like feedback on how to
  handle these.
 
  Martijn
  ___
  Bf-committers mailing list
  Bf-committers@blender.org
  http://lists.blender.org/mailman/listinfo/bf-committers
 
 ___
 Bf-committers mailing list
 Bf-committers@blender.org
 http://lists.blender.org/mailman/listinfo/bf-committers

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

Re: [Bf-committers] Windows platform things to do before 2.73

[Martijn Berger]

Hi Thomas,

The shortcut idea might be the best, even though there is no guarantee
that the user actually starts Blender via that. - this is why we need a
good way to give a user feedback to some system / configuration issue that
is impacting his/her blender experience. But how do we do that part ?

Martijn

On Tue, Nov 25, 2014 at 3:32 PM, Thomas Dinges blen...@dingto.org wrote:

 Hi Martijn,

 - I am fine with the OpenGL error / warning, that is a good idea and
 hopefully saves us some Blender does not run reports.

 - Getting rid of the launcher is a good idea, but I don't think we
 should set a global environment variable.
 The shortcut idea might be the best, even though there is no guarantee
 that the user actually starts Blender via that.

 Thomas

 Am 25.11.2014 um 14:49 schrieb Martijn Berger:
  Hi everyone,
 
  I would like to propose
 
  - actually checking the OpenGL context when starting up blender.
  - fatal error when less then the required OpenGL 1.4 is found.
  - warning when less then OpenGL 2.1 is found (Nvidia  NV30 released
 in
  2003)
 
There are some technical issue with giving the fatal error as it
 might
  be best to use an OS dependent dialog box explaining that blender cannot
  run on windows at least.
Mac OS X is unaffected as all versions we support guarantee at
 least
  this capability.
 
On windows at least this would make sure the bugs reported by
 people
  using GDI driven OpenGL 1.1 will not happen. Also it would get our users
  who still use blender on an pentium 3 with windows XP the ability to
 adjust
  to the fact that it might not always continue to work with the latest and
  greatest.
 
  - getting rid of the launcher.
 On windows we have a binary launcher that exists only to set an OPENMP
  related environment variable.
 I would like to get rid of this again in favour of setting it in the
  short-cut or setting the variable globally during install.
 Also we could and should check for this in the System Info.
 
 
  Both of these issues touch on the issue of giving the user feedback about
  his or her system configuration / hardware / settings and how they might
  negatively impact blenders performance. I would like feedback on how to
  handle these.
 
  Martijn
  ___
  Bf-committers mailing list
  Bf-committers@blender.org
  http://lists.blender.org/mailman/listinfo/bf-committers

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

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

Re: [Bf-committers] Compilation try to install 2.72 directly in /usr/local/

[Martijn Berger]

Hi,

We did have a change in this area recently. In short we want to install to
the directory used for compilation when using make install.
Unfortunately this change hit people with an already in place CMakeCache,
there is nothing we can do about this. You can either clear your
CMAKE_INSTALL_PREFIX and rerun cmake or set it to `pwd`/bin .
I am sorry this change impacted you.

Martijn

P.S. When running cmake for the first time (empty cache) this scenario is
handled.

P.P.S. This change is needed as it allows us to use CPack to generate
installers that require *relative* path's in the INSTALL() command.

On Mon, Nov 17, 2014 at 12:30 PM, Kévin Dietrich kevin.dietr...@mailoo.org
wrote:



 Le 2014-11-17 11:58, Julien Duroure a écrit :

  Hi all,
 
  After a git update yesterday (last update was 2 weeks ago), my make
  install failed because trying of writing 2.72 directory directly in
  /usr/local/, that needs root privileges.
 
  Here is my script used to update my build [1].
 
  I know that there was some change last days about building
 configuration. I
  don't know if this is linked to these modifications.
 
  Other problem : It seems that addons contrib are not included in my
 builds.
  Any ideas ? Git repository of contrib is not a submodule ?
 
  Thanks !
 
  [1] : http://www.pasteall.org/55205
  [1]

 Hi,

 That also happened to me yesterday I think, don't know what's the cause,
 but in the meantime you can set CMAKE_INSTALL_PREFIX to whatever dir you
 used to build in, e.g.:

 CMAKE_INSTALL_PREFIX=/home/ju/Programmes/blender/git/build_linux/bin

 Either put that in your script or directly edit the CMakeCache.txt in
 build_linux/

 Hope that helps :)


 Links:
 --
 [1] http://www.pasteall.org/55205
 ___
 Bf-committers mailing list
 Bf-committers@blender.org
 http://lists.blender.org/mailman/listinfo/bf-committers

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

Re: [Bf-committers] Trying to build the PACKAGE.vcxproj using VS 2013

[Martijn Berger]

Hi Tom,

The package target is actually intended to build a package ( defaults to an
NSIS based installer for blender).
It might need the Nullsoft scriptable installer (NSIS) in the PATH variable
so it can find it.  I am in the process of making this thing actually work
an would very much like to help you get it working.
It might in this context be advisable for you to get onto irc.freenode /
#blendercoder so we can have a lower latency higher fidelity conversation
about this.

Martijn

On Mon, Nov 17, 2014 at 3:50 PM, Tom Dominique 
tom.domini...@gerbertechnology.com wrote:

 Hello Martijn,

 I will update the blender source and regenerate the solution as you have
 stated. I reason I was trying to build using the PACKAGE target, I was
 trying to have something that the testing team could load this package (
 installation of blender and setting the proper registry entries, etc...)
 and test. If this is not what PACKAGE was intended for, please point me in
 the correct direction.

 Thanks,

 Tom

 -Original Message-
 From: bf-committers-boun...@blender.org
 [mailto:bf-committers-boun...@blender.org] On Behalf Of Martijn Berger
 Sent: Saturday, November 15, 2014 2:51 AM
 To: bf-blender developers
 Subject: Re: [Bf-committers] Trying to build the PACKAGE.vcxproj using VS
 2013

 Hi Tom,

 I am having trouble reproducing this, I have made extensive changes to the
 cmake buildsystem over the last week and would recommend updating the
 blender source and regenerating the solution and retrying it.
 For me both the NSIS and the WIX packers work and so does building the
 PACKAGE target. The package target is not really needed to do blender
 development and did not work properly prior to my changes anyway.

 Martijn

 On Fri, Nov 14, 2014 at 9:10 PM, Tom Dominique 
 tom.domini...@gerbertechnology.com wrote:

  Hello Everyone,
 
 
 
  I am new to Blender and I am trying to build using VS2013. I am using
  Cmake 3.0.2, NSIS 3.0b and git. I am able to create a blender.sln and
  I am able to build almost all of the 135 projects that were created.
  The only project I can not build is the one I believe I need, and that
  is PACKAGE.vcxproj. I have attached my error message that I am
  receiving. Any help would greatly be appreciated.
 
 
 
  Thanks,
 
 
 
  Tom
 
 
 
  1-- Build started: Project: PACKAGE, Configuration: Release x64
  1--
 
  1  CPack: Create package using NSIS
 
  1  CPack: Install projects
 
  1  CPack: - Install project: Blender
 
  1  CMake Error at
  c:/BlenderDEV/BuildPath/source/creator/cmake_install.cmake:41 (message):
 
  1ABSOLUTE path INSTALL DESTINATION forbidden (by caller):
 
  1c:/BlenderDEV/BuildPath/bin/Release/2.72/scripts
 
  1  Call Stack (most recent call first):
 
  1c:/BlenderDEV/BuildPath/cmake_install.cmake:35 (include)
 
  1
 
  1
 
  1EXEC : CPack error : Error when generating package: Blender
 
  1C:\Program Files
 
 (x86)\MSBuild\Microsoft.Cpp\v4.0\V120\Microsoft.CppCommon.targets(132,5):
  error MSB3073: The command setlocal
 
  1C:\Program Files
 
 (x86)\MSBuild\Microsoft.Cpp\v4.0\V120\Microsoft.CppCommon.targets(132,5):
  error MSB3073: cd c:\BlenderDEV\BuildPath
 
  1C:\Program Files
 
 (x86)\MSBuild\Microsoft.Cpp\v4.0\V120\Microsoft.CppCommon.targets(132,5):
  error MSB3073: if %errorlevel% neq 0 goto :cmEnd
 
  1C:\Program Files
 
 (x86)\MSBuild\Microsoft.Cpp\v4.0\V120\Microsoft.CppCommon.targets(132,5):
  error MSB3073: c:
 
  1C:\Program Files
 
 (x86)\MSBuild\Microsoft.Cpp\v4.0\V120\Microsoft.CppCommon.targets(132,5):
  error MSB3073: if %errorlevel% neq 0 goto :cmEnd
 
  1C:\Program Files
 
 (x86)\MSBuild\Microsoft.Cpp\v4.0\V120\Microsoft.CppCommon.targets(132,5):
  error MSB3073: C:\Program Files (x86)\CMake\bin\cpack.exe -C Release
  --config ./CPackConfig.cmake
 
  1C:\Program Files
 
 (x86)\MSBuild\Microsoft.Cpp\v4.0\V120\Microsoft.CppCommon.targets(132,5):
  error MSB3073: if %errorlevel% neq 0 goto :cmEnd
 
  1C:\Program Files
 
 (x86)\MSBuild\Microsoft.Cpp\v4.0\V120\Microsoft.CppCommon.targets(132,5):
  error MSB3073: :cmEnd
 
  1C:\Program Files
 
 (x86)\MSBuild\Microsoft.Cpp\v4.0\V120\Microsoft.CppCommon.targets(132,5):
  error MSB3073: endlocal  call :cmErrorLevel %errorlevel%  goto
  :cmDone
 
  1C:\Program Files
 
 (x86)\MSBuild\Microsoft.Cpp\v4.0\V120\Microsoft.CppCommon.targets(132,5):
  error MSB3073: :cmErrorLevel
 
  1C:\Program Files
 
 (x86)\MSBuild\Microsoft.Cpp\v4.0\V120\Microsoft.CppCommon.targets(132,5):
  error MSB3073: exit /b %1
 
  1C:\Program Files
 
 (x86)\MSBuild\Microsoft.Cpp\v4.0\V120\Microsoft.CppCommon.targets(132,5):
  error MSB3073: :cmDone
 
  1C:\Program Files
 
 (x86)\MSBuild\Microsoft.Cpp\v4.0\V120\Microsoft.CppCommon.targets(132,5):
  error MSB3073: if %errorlevel% neq 0 goto :VCEnd
 
  1C:\Program Files
 
 (x86)\MSBuild\Microsoft.Cpp\v4.0\V120\Microsoft.CppCommon.targets(132,5):
  error MSB3073: :VCEnd exited with code 1.
 
  == Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped

Re: [Bf-committers] Trying to build the PACKAGE.vcxproj using VS 2013

[Martijn Berger]

Hi Tom,

I am having trouble reproducing this, I have made extensive changes to the
cmake buildsystem over the last week and would recommend updating the
blender source and regenerating the solution and retrying it.
For me both the NSIS and the WIX packers work and so does building the
PACKAGE target. The package target is not really needed to do blender
development and did not work properly prior to my changes anyway.

Martijn

On Fri, Nov 14, 2014 at 9:10 PM, Tom Dominique 
tom.domini...@gerbertechnology.com wrote:

 Hello Everyone,



 I am new to Blender and I am trying to build using VS2013. I am using
  Cmake 3.0.2, NSIS 3.0b and git. I am able to create a blender.sln and I am
 able to build almost all of the 135 projects that were created. The only
 project I can not build is the one I believe I need, and that is
 PACKAGE.vcxproj. I have attached my error message that I am receiving. Any
 help would greatly be appreciated.



 Thanks,



 Tom



 1-- Build started: Project: PACKAGE, Configuration: Release x64 --

 1  CPack: Create package using NSIS

 1  CPack: Install projects

 1  CPack: - Install project: Blender

 1  CMake Error at
 c:/BlenderDEV/BuildPath/source/creator/cmake_install.cmake:41 (message):

 1ABSOLUTE path INSTALL DESTINATION forbidden (by caller):

 1c:/BlenderDEV/BuildPath/bin/Release/2.72/scripts

 1  Call Stack (most recent call first):

 1c:/BlenderDEV/BuildPath/cmake_install.cmake:35 (include)

 1

 1

 1EXEC : CPack error : Error when generating package: Blender

 1C:\Program Files
 (x86)\MSBuild\Microsoft.Cpp\v4.0\V120\Microsoft.CppCommon.targets(132,5):
 error MSB3073: The command setlocal

 1C:\Program Files
 (x86)\MSBuild\Microsoft.Cpp\v4.0\V120\Microsoft.CppCommon.targets(132,5):
 error MSB3073: cd c:\BlenderDEV\BuildPath

 1C:\Program Files
 (x86)\MSBuild\Microsoft.Cpp\v4.0\V120\Microsoft.CppCommon.targets(132,5):
 error MSB3073: if %errorlevel% neq 0 goto :cmEnd

 1C:\Program Files
 (x86)\MSBuild\Microsoft.Cpp\v4.0\V120\Microsoft.CppCommon.targets(132,5):
 error MSB3073: c:

 1C:\Program Files
 (x86)\MSBuild\Microsoft.Cpp\v4.0\V120\Microsoft.CppCommon.targets(132,5):
 error MSB3073: if %errorlevel% neq 0 goto :cmEnd

 1C:\Program Files
 (x86)\MSBuild\Microsoft.Cpp\v4.0\V120\Microsoft.CppCommon.targets(132,5):
 error MSB3073: C:\Program Files (x86)\CMake\bin\cpack.exe -C Release
 --config ./CPackConfig.cmake

 1C:\Program Files
 (x86)\MSBuild\Microsoft.Cpp\v4.0\V120\Microsoft.CppCommon.targets(132,5):
 error MSB3073: if %errorlevel% neq 0 goto :cmEnd

 1C:\Program Files
 (x86)\MSBuild\Microsoft.Cpp\v4.0\V120\Microsoft.CppCommon.targets(132,5):
 error MSB3073: :cmEnd

 1C:\Program Files
 (x86)\MSBuild\Microsoft.Cpp\v4.0\V120\Microsoft.CppCommon.targets(132,5):
 error MSB3073: endlocal  call :cmErrorLevel %errorlevel%  goto :cmDone

 1C:\Program Files
 (x86)\MSBuild\Microsoft.Cpp\v4.0\V120\Microsoft.CppCommon.targets(132,5):
 error MSB3073: :cmErrorLevel

 1C:\Program Files
 (x86)\MSBuild\Microsoft.Cpp\v4.0\V120\Microsoft.CppCommon.targets(132,5):
 error MSB3073: exit /b %1

 1C:\Program Files
 (x86)\MSBuild\Microsoft.Cpp\v4.0\V120\Microsoft.CppCommon.targets(132,5):
 error MSB3073: :cmDone

 1C:\Program Files
 (x86)\MSBuild\Microsoft.Cpp\v4.0\V120\Microsoft.CppCommon.targets(132,5):
 error MSB3073: if %errorlevel% neq 0 goto :VCEnd

 1C:\Program Files
 (x86)\MSBuild\Microsoft.Cpp\v4.0\V120\Microsoft.CppCommon.targets(132,5):
 error MSB3073: :VCEnd exited with code 1.

 == Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==
 ___
 Bf-committers mailing list
 Bf-committers@blender.org
 http://lists.blender.org/mailman/listinfo/bf-committers

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

Re: [Bf-committers] SDL library upgrade

[Martijn Berger]

Hi,

In general I do not think we should be to dogmatic in terms of library
versions across platforms. Run-time loading is however a cool solution and
I guess it fits really well for SDL.
Blender has been ready for this for some time thanks to Campbell but I am
unsure if we are actively using the improvements SDL2 brings like joystick
hot-plugging etc.

Quick questions:
What is the state of the wrangler ?

Other then that it seems a very doable and worthwhile goal (for the next
release ?)


Martijn



On Thu, Nov 13, 2014 at 2:24 PM, Sergey Sharybin sergey@gmail.com
wrote:

 Hi,

 This is actually coming from a conversation with Martijn about switching to
 SDL-2.0 on Windows, but we need to make everyone informed.

 So basically the need of upgrade on Windows is caused by some issues
 happening with SDL-1.2 (which is currently used for all platforms) on
 Windows 8. So switching to SDL-2.0 would make more windows users happy with
 blender.

 But we need to keep libraries in sync for the release, which means OSX and
 Linux maintainers would need to do modifications to the release environment
 and libraries. It shouldn't be hard, because SDL-2.0 was out for quite some
 time now and Blender itself is totally ready for it.

 So the proposal would be:

 - Martijn takes care of SDL-2.0 on Windows. If needed Sergey helps him.
 - Jens would need to take care of OSX
 - Sergey takes care of Linux builds, for this we'll need to finish the SDL
 wrangler patch (which makes SDL libraries load on runtime and if library is
 not found Blender still works, just doesn't allow to use SDL for sound and
 joystick).

 What does it mean for artists? Well, for OSX and Windows they wouldnt' see
 any difference (apart from some some solved issues). Neither those who runs
 existing builds, nor those who compiles blender themselves.

 For Linux users it'll mean in order to use SDL (sound and joystick) SDL2 is
 to be installed. If this library is not installed, blender WILL run, just
 wouldn't let use SDL functionality. This doesn't seem difficult to install
 if needed, even for current Debian stable (which tends to be quite old)
 there's an official backport for SDL2.

 --
 With best regards, Sergey Sharybin
 ___
 Bf-committers mailing list
 Bf-committers@blender.org
 http://lists.blender.org/mailman/listinfo/bf-committers

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

Re: [Bf-committers] Propose to reduce default feature set (*nix dev builds)

[Martijn Berger]

Hi,

@Terry, I would like to point out that most developers I know already build
with a very very reduced feature set anyway.
Blender in general is ridiculously difficult to build if only as a result
of its large number of dependencies and things like boost/C++ ABI stuff
adding to that.

I think OpenEXR and Ilmbase libs should maybe not be disabled by default as
it is the highest fidelity output format and not *that* bad compared with
the rest of the list.

I would disable by default:

   - WITH_OPENCOLLADA
   - WITH_OPENCOLORIO
   - WITH_CYCLES_OSL
   - WITH_CODEC_FFMPEG
   - WITH_SDL
   - WITH_NDOF
   - WITH_BUILDINFO
   - WITH_GAMEENGINE
   - WITH_JACK
   - WITH_IMAGE_REDCODE
   - WITH_IMAGE_PSD

Maybe it would be good to also have the opposite WITH_FULL_RELEASE_BUILD
that just enables all this and is not cached ?

Martijn

On Thu, Nov 13, 2014 at 2:05 PM, AIBlender aiblen...@gmail.com wrote:

 On 13/11/14 11:31, Campbell Barton wrote:
  This is mainly for Linux/BSD developers (releases remain unchanged).
 
  Its getting increasingly difficult to build Blender on Linux, (LLVM,
  ffmpeg, OpenCollada...)  these issue's can't always be fixed on our
  side.
 
  With newer developers a failed build with a cryptic error message
  (guys in #blendercoders can't even help with), is quite off putting..
 
  Proposing a limited feature-set by default with CMake (again official
  builds from blender.org are unchanged)
 
  https://developer.blender.org/T42569
 

 Hi,

 This is a bad idea, the whole point on dev builds is for us to spot
 problems, if you start turning off features just so things can compile
 that is sweeping issues under the carpet.  If it's getting hard to build
 that means you need to work on build instructions/build system.  And if
 its an upstream issue, communication needs to go upstream.  Being
 demotivated if not a reason to start turning off fundamental features.

 After all ffmpeg and opencollada would not really be seen as option
 features (by a lot of people), and the same can be said of llvm, and
 they certainly are not optional when we need to spot bug/issues.  I mean
 what is next stop supporting Linux because its harder to build.  Well
 you could just as easily make that argument for the entire windows build
 system.  It's more often than not the one with problems, so we should
 obviously throw it in the canal yes? Obviously that would not be done.

 *marches off all huffy like*

 Terry Wallwork


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

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

Re: [Bf-committers] Vendor Approval Issue

[Martijn Berger]

Hi everyone.

I think this is a great idea.

I would like to propose the following steps.

1) We put in place the infrastructure
2) We use a self signed certificate ( blender foundation CA ) to sign our
buildbot builds and installers.
3) We buy / beg an official certificate to the signing.

This would allow us to delay spending the money till we can actually use
the certificate. There are no real hurdles to just doing this but lets
prove it works first.

Martijn


On Fri, Nov 7, 2014 at 1:39 AM, Dan McGrath danmcgrath...@gmail.com wrote:

 Hey Ton,

 Well, the cert is just like any other SSL/x.509 certificate you would get,
 except the properties of the certificate allow (limit) it to be used
 specifically for signing code. You can get certs that can be set to only be
 used for email, signing or encryption etc. The thing that makes this use of
 the certificate unique (compared to regular SSL certificates) is that you
 use special tools on Windows to sign binary files (as opposed to installing
 in a web server like we do with SSL). Although given the special purpose of
 making your software look reputable and legitimate, they (the industry) of
 course demand a premium for the cost of generating these certificates (ie:
 they charge you up the wazoo!). Like our EV certificates, I believe they
 also go through extra identity checks before they just hand one of these
 certificates over to you.

 Comodo (our certificate provider) offers these certificates as well if you
 are interested (Starting at $166.95/year):



 https://www.comodo.com/business-security/code-signing-certificates/code-signing.php

 With one of those, you should be able to follow the steps in the Microsoft
 url I pasted earlier to do code signing. I believe you could even generate
 your own self signed CA cert and create one of these code signing
 certificates to test the tools, but such a certificate would not be trusted
 of course, and would only be useful to practice the workflow.


 Dan


 On Thu, Nov 6, 2014 at 12:37 PM, Ton Roosendaal t...@blender.org wrote:

  Hi,
 
  I don't mind paying a bit, for as long it's an undisputed, official cert
  recommended by Microsoft.
 
  -Ton-
 
  
  Ton Roosendaal  -  t...@blender.org   -   www.blender.org
  Chairman Blender Foundation - Producer Blender Institute
  Entrepotdok 57A  -  1018AD Amsterdam  -  The Netherlands
 
 
 
  On 6 Nov, 2014, at 15:51, Dan McGrath wrote:
 
   It sounds like Microsoft calls this athenticode. I don't have any
   personal experience with it myself, but I did find this url at
  Microsoft's
   website that might be of use to those looking into this:
  
http://msdn.microsoft.com/en-us/library/ie/ms537359(v=vs.85).aspx
  
   Dan
  
   On Thu, Nov 6, 2014 at 9:12 AM, Ton Roosendaal t...@blender.org
 wrote:
  
   Hi all,
  
   For OS X we sign the binary using our Apple developer account.
   It seems there's a similar system for Windows exes too.
   Please advice!
  
   (See mail below).
  
   -Ton-
  
   
   Ton Roosendaal  -  t...@blender.org   -   www.blender.org
   Chairman Blender Foundation - Producer Blender Institute
   Entrepotdok 57A  -  1018AD Amsterdam  -  The Netherlands
  
  
  
   Begin forwarded message:
  
   Subject: Vendor Approval Issue
   Date: 6 November, 2014 14:17:11 CET
   To: foundat...@blender.org
  
   Hi
  
   I have a  generic issue that needs addressing so I have contacted
   this email address in the hope that you can redirect it
   appropriately.
  
   I use Comodo Internet Security Premium which includes a Defense
   Plus element for monitoring running processes. Whilst I have
   approved Blender as a process it refuses to recognise the Vendor as
   the .exe file is not signed and has no developer information so it
   will not allow me to add it to the approved list and keeps flagging
   it every time I launch Blender.
  
   I am bringing this to your attention as it is annoying and I am
   sure other users are experiencing the same issue and it could be
   easily resolved but that can only be done by the development team.
  
   Trusted Vendors can sign up here to be whitelisted:
  
   http://internetsecurity.comodo.com/trustedvendor/signup.php
  
   Many thanks
  
   Mark
  
  
   ___
   Bf-committers mailing list
   Bf-committers@blender.org
   http://lists.blender.org/mailman/listinfo/bf-committers
  
   ___
   Bf-committers mailing list
   Bf-committers@blender.org
   http://lists.blender.org/mailman/listinfo/bf-committers
 
  ___
  Bf-committers mailing list
  Bf-committers@blender.org
  http://lists.blender.org/mailman/listinfo/bf-committers
 
 ___
 Bf-committers mailing list
 Bf-committers@blender.org
 

Re: [Bf-committers] Vendor Approval Issue

[Martijn Berger]

Hi Sergey-,

You mind making a Blender Institute CA if we don't have one.
Ill send you a certificate signing request for a code signing certificate.
So I can make the proof of concept happen.

Martijn




On Sun, Nov 9, 2014 at 4:31 PM, Sergey Sharybin sergey@gmail.com
wrote:

 Sounds like a plan to me.

 Do we have volunteers to implement this? :)

 On Sun, Nov 9, 2014 at 8:29 PM, Martijn Berger martijn.ber...@gmail.com
 wrote:

  Hi everyone.
 
  I think this is a great idea.
 
  I would like to propose the following steps.
 
  1) We put in place the infrastructure
  2) We use a self signed certificate ( blender foundation CA ) to sign our
  buildbot builds and installers.
  3) We buy / beg an official certificate to the signing.
 
  This would allow us to delay spending the money till we can actually use
  the certificate. There are no real hurdles to just doing this but lets
  prove it works first.
 
  Martijn
 
 
  On Fri, Nov 7, 2014 at 1:39 AM, Dan McGrath danmcgrath...@gmail.com
  wrote:
 
   Hey Ton,
  
   Well, the cert is just like any other SSL/x.509 certificate you would
  get,
   except the properties of the certificate allow (limit) it to be used
   specifically for signing code. You can get certs that can be set to
 only
  be
   used for email, signing or encryption etc. The thing that makes this
 use
  of
   the certificate unique (compared to regular SSL certificates) is that
 you
   use special tools on Windows to sign binary files (as opposed to
  installing
   in a web server like we do with SSL). Although given the special
 purpose
  of
   making your software look reputable and legitimate, they (the industry)
  of
   course demand a premium for the cost of generating these certificates
  (ie:
   they charge you up the wazoo!). Like our EV certificates, I believe
 they
   also go through extra identity checks before they just hand one of
 these
   certificates over to you.
  
   Comodo (our certificate provider) offers these certificates as well if
  you
   are interested (Starting at $166.95/year):
  
  
  
  
 
 https://www.comodo.com/business-security/code-signing-certificates/code-signing.php
  
   With one of those, you should be able to follow the steps in the
  Microsoft
   url I pasted earlier to do code signing. I believe you could even
  generate
   your own self signed CA cert and create one of these code signing
   certificates to test the tools, but such a certificate would not be
  trusted
   of course, and would only be useful to practice the workflow.
  
  
   Dan
  
  
   On Thu, Nov 6, 2014 at 12:37 PM, Ton Roosendaal t...@blender.org
 wrote:
  
Hi,
   
I don't mind paying a bit, for as long it's an undisputed, official
  cert
recommended by Microsoft.
   
-Ton-
   

Ton Roosendaal  -  t...@blender.org   -   www.blender.org
Chairman Blender Foundation - Producer Blender Institute
Entrepotdok 57A  -  1018AD Amsterdam  -  The Netherlands
   
   
   
On 6 Nov, 2014, at 15:51, Dan McGrath wrote:
   
 It sounds like Microsoft calls this athenticode. I don't have any
 personal experience with it myself, but I did find this url at
Microsoft's
 website that might be of use to those looking into this:

  http://msdn.microsoft.com/en-us/library/ie/ms537359(v=vs.85).aspx

 Dan

 On Thu, Nov 6, 2014 at 9:12 AM, Ton Roosendaal t...@blender.org
   wrote:

 Hi all,

 For OS X we sign the binary using our Apple developer account.
 It seems there's a similar system for Windows exes too.
 Please advice!

 (See mail below).

 -Ton-

 
 Ton Roosendaal  -  t...@blender.org   -   www.blender.org
 Chairman Blender Foundation - Producer Blender Institute
 Entrepotdok 57A  -  1018AD Amsterdam  -  The Netherlands



 Begin forwarded message:

 Subject: Vendor Approval Issue
 Date: 6 November, 2014 14:17:11 CET
 To: foundat...@blender.org

 Hi

 I have a  generic issue that needs addressing so I have contacted
 this email address in the hope that you can redirect it
 appropriately.

 I use Comodo Internet Security Premium which includes a Defense
 Plus element for monitoring running processes. Whilst I have
 approved Blender as a process it refuses to recognise the Vendor
 as
 the .exe file is not signed and has no developer information so
 it
 will not allow me to add it to the approved list and keeps
 flagging
 it every time I launch Blender.

 I am bringing this to your attention as it is annoying and I am
 sure other users are experiencing the same issue and it could be
 easily resolved but that can only be done by the development
 team.

 Trusted Vendors can sign up here to be whitelisted:

 http://internetsecurity.comodo.com

Re: [Bf-committers] Fwd: Vendor Approval Issue

[Martijn Berger]

Hi all,

Technically this is not a challenge. The main difficulty is getting our
hands on a key that we can use to sign in a way that is trusted by default.
This usually costs a few hundred euro's a year for a cert. There seems to
be a free way to get this done -
https://www.certum.eu/certum/cert,offer_en_open_source_cs.xml as a
possibility.
I will look into this but really would like feedback from people who have
already done this or know of open source projects that currently do sign
their installer and exe's

Martijn

On Thu, Nov 6, 2014 at 3:12 PM, Ton Roosendaal t...@blender.org wrote:

 Hi all,

 For OS X we sign the binary using our Apple developer account.
 It seems there's a similar system for Windows exes too.
 Please advice!

 (See mail below).

 -Ton-

 
 Ton Roosendaal  -  t...@blender.org   -   www.blender.org
 Chairman Blender Foundation - Producer Blender Institute
 Entrepotdok 57A  -  1018AD Amsterdam  -  The Netherlands



 Begin forwarded message:

  Subject: Vendor Approval Issue
  Date: 6 November, 2014 14:17:11 CET
  To: foundat...@blender.org
 
  Hi
 
  I have a  generic issue that needs addressing so I have contacted
  this email address in the hope that you can redirect it
  appropriately.
 
  I use Comodo Internet Security Premium which includes a Defense
  Plus element for monitoring running processes. Whilst I have
  approved Blender as a process it refuses to recognise the Vendor as
  the .exe file is not signed and has no developer information so it
  will not allow me to add it to the approved list and keeps flagging
  it every time I launch Blender.
 
  I am bringing this to your attention as it is annoying and I am
  sure other users are experiencing the same issue and it could be
  easily resolved but that can only be done by the development team.
 
  Trusted Vendors can sign up here to be whitelisted:
 
  http://internetsecurity.comodo.com/trustedvendor/signup.php
 
  Many thanks
 
  Mark
 

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

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

Re: [Bf-committers] Cycles as Default Engine

[Martijn Berger]

It is only the default setting, most existing blender users will not ever
notice any change as they are likely to have a startup file that is tuned
to their liking.
This mostly applies to users who are new to blender. In that category there
are 2 groups for both of which I think you could argue that cycles is a
better default.

New to 3d software in general users. I would think this group is rather
young and likely to find or be pointed to online tutorials. While their
objective for starting blender might vary wildly I would still think that
given the fact that the tutorial making people are not crazy and following
the general trend the chances that they want to invest in learning cycles
to start with versus learning internal ( yes you do need to learn stuff
there) are so skewed in favour of cycles that it being the default makes
sense.

Migrating users from other software packages. Here I think the default is
less important as in most packages I know advanced users will have to
change a few settings anyway. I would expect this group to find the setting
soon enough and figure out how to save these preferences. Still you could
very well argue that some of these people might try Blender because of
cycles and that that group is likely bigger then the people who leave other
software to test this awesome new render engine called Internal in
blender.

In the end both engines no matter how cool they are are not perfect and
guiding this discussion towards an if cycles can only do x,y,z it could
become the default is obscuring the real issue.
None of us can really see through the eyes of a true new user any more and
we actually need that perspective to actually serve the group that this is
likely to impact the most.

I think the argument Brecht raises on consistency is a very valid and
important argument for cycles as a default for both classes of new users.
And while I think the arguments about in and exporters are important to I
really feel even without addressing that cycles is likely the better
default.


On Mon, Oct 6, 2014 at 1:19 AM, Brecht Van Lommel 
brechtvanlom...@pandora.be wrote:

 Yes, ID passes do not work with motion blur and depth of field, and the
 only solution is deep compositing, just like it would be for Blender
 Internal if it actually supported these features.

 The thing is that you can list many missing features in Blender Internal as
 well. No depth of field, no 3D motion blur, no proper indirect light or
 HDRI environment lighting, no diffuse glossy interactions, no emission from
 volumes.

 And even more inconsistency problems like no SSS or hair curves in
 reflections, render passes not working for node materials, wrong
 transparent shadows from material nodes, no hair curve shadows with lights
 other than spots, wrong fresnel and specular transparency, hair shading
 that you have to light with separate lamps to get decent results, volume
 stepping artifacts that are impossible to get rid of, very difficult to do
 motion blur and depth of field with transparent objects, no way to texture
 various settings, no correct light falloff, broken bump mapping in
 reflections, no correct area lights, and so on.

 I'm not trying to say one is better than the other here, Blender Internal
 certainly has more flexibility in some areas. But if the question is, do
 feature X and Y work together properly, then the answer is yes *much* more
 often in Cycles than it is in Blender Internal, and in fact I like to think
 that this is the case when comparing Cycles to most other renderers as
 well.
 Hi Daniel, of course I know you can change that on the menu, what I'm
 saying is that BI is a feature complete render engine (maybe not the best
 quality ever but it's complete), Cycles is not complete, one more example:

 The render passes in cycles are most of the time unusable, try to get an
 object ID or a material ID pass from an object with motion blur for
 example. Some of the 'features' are on the UI but they are actually not
 usable for production. In my opinion if you have a 'feature' that is
 unusable is better to remove that feature from the UI until it's ready. I
 started rendering a shot in cycles thinking that I could have material and
 object passes with motion blur and I realize that these options are not
 usable at all and I had to fake these passes in other ways.

 All I'm saying is... Yes, I'm looking forward to have Cycles as the main
 engine BUT only when it's fully featured and not having inconsistency
 problems as the ones I mention. Also it has more limitations from an artist
 point of view to tweak the lighting and managing the light in comparison
 with the BI. Even Arnold render fakes many things but in cycles is trying
 to achieve realistic rendering results which is fine but not really
 allowing the artist sometimes to adjust settings in a non-realistic way
 (example: shadow color on the rendering).
 ___
 Bf-committers mailing list
 

Re: [Bf-committers] Blender developers meeting, October 5, 2014

[Martijn Berger]

2.5) Check again if this is not a duplicate.

Both this step and assigning will become easier the more you practice.

But even just verifying bugs ( trying to redo the bug based on the
description ) and then if needed just adding all the missing details is
very very helpful.

On Mon, Oct 6, 2014 at 5:59 AM, Tom M letter...@gmail.com wrote:

 Triage is

 0) Decide if it is a bug or is really a feature request
 1) Making sure all of the information needed to reproduce the bug is
 present (platform, simplified test file, stacktrace, etc.)
 2) Attempt to verify the bug
 3) Assigning the bug to a developer with the relevant expertise

 LetterRip

 On Sun, Oct 5, 2014 at 4:11 PM, Joel Godin joelgo...@ymail.com wrote:

  Done bug reports, done building, would like to help on Triage and
  eventually Patches/reviews (soon as I learn how to use GIT).What is the
  process for triage?  Just commenting on bugs if you find it is real or
 not
  on your platform?
 
 
   On Sunday, October 5, 2014 11:54 AM, Ton Roosendaal 
 t...@blender.org
  wrote:
 
 
   Hi all,
 
  Here are the notes from today's meeting in irc.freenode.net
 #blendercoders
 
  1) Release review
 
  - The 2.72 release is now official! We even have a release log on
  blender.org:
http://www.blender.org/features/2-72/
Special thanks to Marco Ardito!
 
  - Still open to do credit list (I will do), and a readable list of
  relevant bugs (for users of 2.71 to know).
 
  2) Targets for 2.72
 
  - The current planning:
http://wiki.blender.org/index.php/Dev:Doc/Projects
 
  - Fracture modifier: has its own branch:
 
 http://git.blender.org/gitweb/gitweb.cgi/blender.git/shortlog/refs/heads/fracture_modifier
 
  - Thomas Dinges reminds everyone about his proposal to make Cycles as
  default.
He'd need help to finish the missing bits for it.
 
  3) Other projects
 
  - Four of our frequent coders have gathered in the studio of Blender
  Institute now.
Read the first report - the discussions on the targets we'll be working
  on:
http://gooseberry.blender.org/development-targets-for-gooseberry/
 
  - We need more help with patch review and bug tracker triaging... maybe
  inspire people via a Development Fund grant?
 
  Thanks,
 
  -Ton-
 
  
  Ton Roosendaal  -  t...@blender.org  -  www.blender.org
  Chairman Blender Foundation - Producer Blender Institute
  Entrepotdok 57A  -  1018AD Amsterdam  -  The Netherlands
 
 
 
  ___
  Bf-committers mailing list
  Bf-committers@blender.org
  http://lists.blender.org/mailman/listinfo/bf-committers
 
 
 
  ___
  Bf-committers mailing list
  Bf-committers@blender.org
  http://lists.blender.org/mailman/listinfo/bf-committers
 
 ___
 Bf-committers mailing list
 Bf-committers@blender.org
 http://lists.blender.org/mailman/listinfo/bf-committers

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

Re: [Bf-committers] OpenMP issues with msvc2013 builds

[Martijn Berger]

On Thu, Aug 7, 2014 at 9:27 AM, Sergey Sharybin sergey@gmail.com
wrote:

 I'm not that huge fan of modifying dll, because it could backfare for those
 who builds blender themselves. But if windows folks are fine with this --
 so be it.

 But it is very cool. Although I understand and kind of agree with you that
we should not patch the files.
Patching the memory could work though.


 But tha't's separate topic, let's get into it after we know how we'll deal
 with openmp in upcoming 2.72.

A launcher is 100% doable will work and give the best experience. It is not
pretty but to be
honest the rest of the blender directory with dll's and text etc on windows
also does not look pretty.
Lets do it !


 --
 With best regards, Sergey Sharybin
 ___
 Bf-committers mailing list
 Bf-committers@blender.org
 http://lists.blender.org/mailman/listinfo/bf-committers

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

Re: [Bf-committers] OpenMP issues with msvc2013 builds

[Martijn Berger]

Hi Campbell,

I last compiled with intel c++ a few month's ago and without OSL / Collada.
In general it works but as with any change it will again probably expose
lots of little issues once people actually use builds intensively.

Main issue is the compiler is not free to use for windows not even for open
source projects. ( the linux toolchain is free for open source ).



On Wed, Aug 6, 2014 at 12:43 PM, Campbell Barton ideasma...@gmail.com
wrote:

 On Wed, Aug 6, 2014 at 6:23 PM, Sergey Sharybin sergey@gmail.com
 wrote:
  Hi,
 
  We've spent quite a while trying to solve the upcoming stream of reports
  about high CPU usage with builds made with msvs2013 in certain
 situations.
  Root of the issue goes to the change made to OMP inplementation back to
  msvc2010 days -- they've forced threads to spin for a while after they
 did
  a work. This is a know issue in the library and nobody actually gonna to
  fix it [1].
 
  There's one woekaround to solve the issue which is to set OMP_WAIT_POLICY
  environment variable to PASSIVE. Unfortunately, since openmp is a dynamic
  library and can't be linked statically at all we can't modify environment
  variables from within blender using putenv(), this is to be done
  externally, before blender.exe starts.
 
  Here's the list of possible solutions:
 
  - Declare msvc full of crap, switch to intel compilers

 Did anyone try Intel-c/c++ on Windows?

 A while back I got Blender building on Linux with Intel's compiler, it
 needed a few tweaks in CMake but wasn't really a big deal to get
 running.
 ___
 Bf-committers mailing list
 Bf-committers@blender.org
 http://lists.blender.org/mailman/listinfo/bf-committers

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

Re: [Bf-committers] OpenMP issues with msvc2013 builds

[Martijn Berger]

Excellent plan Bastien.
From a semantic standpoint combining different threading strategies and or
support libraries within one project is really far from ideal.
For this to work we would need to write some kind of document or declare
some already implemented part of code the official way to do this.

Yes the code would be more verbose compared to openmp but also more
explicit and likely better to control versus the current zoo of tricks in
order to exploit parallelism.




On Wed, Aug 6, 2014 at 2:15 PM, Bastien Montagne montagn...@wanadoo.fr
wrote:

 We could also choose to drop OMP in our code (not all at once, but
 gradually replacing it with real threading), since it’s also a pile of
 crap on OSX currently afaik?

 Assuming our BLI_task 'lib' is ready for massive use (iirc Martijn
 already had that in mind)…

 Or is there some serious issues with this approach (aside the slightly
 more verbose [complicated?] code)?

 Le 06/08/2014 13:26, Sergey Sharybin a écrit :
  Switching to icc wouldn't happen any time soon anyway, so afraid we'll
 need
  to have some shorter-term solution anyway... The question only is what
  exactly we'll choose.
 
  P.S. And yeah, there's nothing more permanent as a temporary solution..
 
 
  On Wed, Aug 6, 2014 at 4:48 PM, Martijn Berger martijn.ber...@gmail.com
 
  wrote:
 
  Hi Campbell,
 
  I last compiled with intel c++ a few month's ago and without OSL /
 Collada.
  In general it works but as with any change it will again probably expose
  lots of little issues once people actually use builds intensively.
 
  Main issue is the compiler is not free to use for windows not even for
 open
  source projects. ( the linux toolchain is free for open source ).
 
 
 
  On Wed, Aug 6, 2014 at 12:43 PM, Campbell Barton ideasma...@gmail.com
  wrote:
 
  On Wed, Aug 6, 2014 at 6:23 PM, Sergey Sharybin sergey@gmail.com
  wrote:
  Hi,
 
  We've spent quite a while trying to solve the upcoming stream of
  reports
  about high CPU usage with builds made with msvs2013 in certain
  situations.
  Root of the issue goes to the change made to OMP inplementation back
 to
  msvc2010 days -- they've forced threads to spin for a while after they
  did
  a work. This is a know issue in the library and nobody actually gonna
  to
  fix it [1].
 
  There's one woekaround to solve the issue which is to set
  OMP_WAIT_POLICY
  environment variable to PASSIVE. Unfortunately, since openmp is a
  dynamic
  library and can't be linked statically at all we can't modify
  environment
  variables from within blender using putenv(), this is to be done
  externally, before blender.exe starts.
 
  Here's the list of possible solutions:
 
  - Declare msvc full of crap, switch to intel compilers
  Did anyone try Intel-c/c++ on Windows?
 
  A while back I got Blender building on Linux with Intel's compiler, it
  needed a few tweaks in CMake but wasn't really a big deal to get
  running.
  ___
  Bf-committers mailing list
  Bf-committers@blender.org
  http://lists.blender.org/mailman/listinfo/bf-committers
 
  ___
  Bf-committers mailing list
  Bf-committers@blender.org
  http://lists.blender.org/mailman/listinfo/bf-committers
 
 
 

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

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

Re: [Bf-committers] OpenMP issues with msvc2013 builds

[Martijn Berger]

On Wed, Aug 6, 2014 at 5:55 PM, Campbell Barton ideasma...@gmail.com
wrote:

 Theres been some issues with OpenMP, but am wary of kicking out entire
 technology just because we can't set an environment variable? (ok, of
 course theres more to it - but seems a weak reasoning still).


I would not want that to be the reason. And it is not easily kicked out
anyway. MS should fix this and until then we should just add a launcher in
my opinion.

You are right these are 2 separate issues.

But in my mind there does exist an issue that with multiple technologies to
create threads you can easily create situations that are non optimal and
even decremental to performance.
We have a lot of places where we use a lot of threading / parallelising
systems in a lot of different ways. This is partly due to 3rd party libs
all doing their own thing.
But the other part is us just adding a bit of OpenMP there building a task
scheduler into that, adding some static threads there etc etc etc.
The argument I made is not specifically targeted at OpenMP. But rather at
the whole zoo of solutions we have everywhere and the fact that we seem
open to adding yet more.
Any threading is hard but reading and maintaining code that does it in a
100 different ways that all might interplay in weird and undefined ways
depending on platform and implementation is even harder.
CPU's do not seem to be getting faster but rather more parallel and we need
at least consider trying to find a good way how to handle that. To me when
we would make the whole of blender more task oriented that would amplify
this potentially. Besides I love thinking about these kinds of issues and
the technical discussion they result in.
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] OpenMP issues with msvc2013 builds

[Martijn Berger]

On Wed, Aug 6, 2014 at 10:33 PM, Chad Fraleigh ch...@triularity.org wrote:

 It's not ideal, and would be coded to each specific vcompXXX.dll (and
 patched/updated versions).

 However, assuming the location of that flag is a fixed offset from the dll
 image, the general idea might be:

  - Call GetModuleHandle() for each supported target (i.e. vcomp120.dll,
 vcomp120d.dll), until one is found.

  - Calculate the address of the flag from the module base.

  - Calculate the address of the code where it does the OMP_WAIT_POLICY
 active/passive checks and verify a few of the static opcode bytes (either
 verbatim, or with a checksum/hash).

We can most likely also just look at specific dll version and see if we
know it.


  - Get the address that code references for the flag, and if it matches the
 earlier calculation, then consider it validated, and change the flag at
 that address.

  - If no supported dll's were found, or couldn't be verified, output a
 warning to stderr about bad performance.


Looks good on paper. It is good to realize that we re-distribute vcomp and
thus have pretty good control over what version we use.
Main problem is that someone needs to actually try this by implementing it
:)





  -Chad

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

Re: [Bf-committers] Towards C++11

[Martijn Berger]

I agree with Lukas in that if we are going to use C++11 that should not
imply just sprinkling features over the code that are wrapped in some C++98
forward compatible macro construct.

For C++11 usage I think however that we do need to:
 - list the things we want to use (std::bind, std::thread) and how they are
supported in our target compilers / platforms.
 - figure out what parts of blender and supporting 3rd party libraries can
be build in c++11 mode.
 - Agree on what (sub)set of features (both language and library) we can
safely use.

I am not sure if we should make a wiki page or a dev.b.o ticket to help
guide this process and provide all stakeholders insight in what this
language upgrade will entail.




On Fri, Jun 13, 2014 at 10:19 AM, Lukas Tönne lukas.toe...@gmail.com
wrote:

 I don't think using fallback implementations or stubs for C++11 features
 would work, it just shouldn't be necessary. For a function attribute like
 override it could work, but what about more crucial features like
 std::bind? These could not be replaced by a stub without breaking the code,
 you'd have to use an alternative implementation, e.g. boost.

 So if we allow C++11 it would have to be supported by all relevant
 compilers as well.

 Afaik we can enable it selectively for now, e.g. only use it in depsgraph,
 cycles, etc.. This way we avoid compiler issues from parts like Bullet
 which may not be quite ready for C++11 (it has a bit stricter syntax rules
 for some features and gives a bunch of non-critical warnings).


 On Wed, Jun 11, 2014 at 10:10 AM, Sergey Sharybin sergey@gmail.com
 wrote:

  It's more clear now, but i'm really skeptical about the proposal.
  Especially about stuff which has where possible. Where needed or
 where
  helps is what i meant. I wouldn't want to start
  just-another-wave-of-cleanup in blender which would start using c++11
  just because it's possible.
 
  Would rather first use really crucial stuff (like bindings in depsgraph
  project). In this particular example i'm not sure how you'll smooth the
  transition.
 
  P.S. Message got too long, zapping loads of the history.
 
  On Wed, Jun 11, 2014 at 1:45 PM, Konrad Wilhelm 
  konrad.wilhelm.kle...@gmail.com wrote:
 
   Hi Sergey,
  
   no no I'm not voting for some library or emulation to use. I voted for
   smooth transitioning to C++11 with the help of automation and clever
  macro
   definition. Let me quickly sketch out the things one would have to do
 to
   implement my idea...
  
   I just picked one feature from C++11, namely the override specifier,
 to
   show that it is safe to implement even if not everybody switches to
  C++11.
  
   Just add something like this to some top-level CMakeLists.txt file:
  
 # Test if C++11 override specifier is supported by current
 compiler.
 # (See http://en.cppreference.com/w/cpp/language/override)
 check_cxx_source_compiles(
 struct A { virtual void foo() {} };
 struct B : A { void foo() override {} };
 int main(int argc, char * argv[]) { B b; return 0; }
   HAVE_CXX11_OVERRIDE_SPECIFIER)
 if(HAVE_CXX11_OVERRIDE_SPECIFIER)
message(STATUS Using C++11 override specifier where
 possible.)
set(CMAKE_CXX_FLAGS ${CMAKE_CXX_FLAGS}
   -DHAVE_CXX11_OVERRIDE_SPECIFIER)
 endif(HAVE_CXX11_OVERRIDE_SPECIFIER)
  
   Then in a global header file, use the HAVE_CXX11_OVERRIDE_SPECIFIER to
   define a macro that can be used instead of override directly:
  
 #ifdef HAVE_CXX11_OVERRIDE_SPECIFIER
 #  define BF_OVERRIDE override
 #else
 #  define BF_OVERRIDE
 #endif
  
   With just these two modifications in place, one can use BF_OVERRIDE in
   places where one would normally use the override keyword directly. It
   does no harm but adds a maintainability value to the code.
  
   To automate the process of using BF_OVERRIDE in places where it makes
   sense, I voted for using the clang-modernize tool. You run the tool and
  it
   changes your code, not more but not less. It does no emulation nor puts
  it
   a library in your code.
  
   Besides the override specifier the clang-modernize tool can also be
  used
   to replace auto_ptr with unique_ptr, and more, which seems to be what
 you
   were looking for.
  
   Here's a list of transformations, clang-modernize can apply to your
  source
   code:
  
 - Make use of override specifier where possible
 - Make use of range-based for loops where possible
 - Pass parameters by value where possible
 - Replace std::auto_ptr (deprecated) by std::unique_ptr
 (EXPERIMENTAL)
 - Use of 'auto' type specifier
 - Make use of nullptr keyword where possible
  
   Let me emphasize that this is not a library approach. It is just a
 smart
   tool that helps transitioning to C++11.
  
   I hope, this clarifies my idea.
  
   - Konrad
  
  
  --
  With best regards, Sergey Sharybin
  ___
  Bf-committers mailing list
  

Re: [Bf-committers] Blender 2.71 needs VC2013-Redistributable on Windows

[Martijn Berger]

Hi I can confirm the RC build is in some way bad when compared to todays
buildbot (build on the same machine with the same settings).

I will investigate.




On Fri, Jun 13, 2014 at 6:10 PM, blen...@dingto.org blen...@dingto.org
wrote:

 Is there an error message? Maybe intall Service Pack 3 for XP.

 - Reply message -
 Von: Remigiusz Fiedler mig...@gmx.net
 An: bf-blender developers bf-committers@blender.org
 Betreff: [Bf-committers] Blender 2.71 needs VC2013-Redistributable on
 Windows
 Datum: Fr., Jun. 13, 2014 17:13


 this is strange, but even with VC2013-Redistributable installed I am
 not able to run 2.71 builds on Windows XP SP2, in opposite to 2.70a
 and olders.

 A hint from someone succeeded would be great :)

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

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

Re: [Bf-committers] Towards C++11

[Martijn Berger]

@Campbell I am pretty sure give how hard Apple is pushing out new releases
and given how many people upgrade that we can just assume an llvm/clang
3.0+  feature set for c++11.

I think we should also do this analysis for C99 support and C11 support.
There are some other projects out there that use C++11 features (clang is
one) and they have made comprehensive analysis of what features they can
and do use.

There are some things we can use anyway like noexcept provided we use it
like the QT people use it so the code does not require a c++11 compiler but
you do get some benefit from compiling with one (
http://qt-project.org/doc/qt-5/qtglobal.html#Q_DECL_NOEXCEPT)

I think getting a sort of caniuse.com  for c/c++ language features on the
wiki would be good way forward.






On Sat, Jun 7, 2014 at 11:11 AM, Campbell Barton ideasma...@gmail.com
wrote:

 General +1 to take advantage of C++11 where appropriate,
 AFAICS OSX needs some investigation?, otherwise we're close to being
 able to support it.


 @Tom M: I'm not concerned with static checking tools, mainly because
 using C++11 in a few places won't suddenly make static checkers fail
 on the rest of our code, eventually they will get updated too.

 Coverity has support:
 https://communities.coverity.com/docs/DOC-1571
 clang-static-analyser didn't work well for me last I checked with C++,
 but it might have improved in last year or so.


 @Ichthyo: Not being able to build Blender on older Linux isnt such a
 big deal since Blender can still run on them, if its important they
 can get a new compiler (I did this on a CentOS server, compiling a
 newer GCC/Clang isnt that big of a deal).


 @Jeffrey H: C++11 doesn't raise hardware requirements.

 On Sat, Jun 7, 2014 at 3:18 PM, Jeffrey H italic.rendezv...@gmail.com
 wrote:
  What about older hardware? I don't know much about C++11, but I would
  imagine it takes advantage of newer processor instruction sets and I know
  new compilers do the same. Would Blender still run on, say, an old
 Pentium
  4? The reason I ask is simply because a large number of users use Blender
  because it's able to run on the proverbial toaster, where Maya and other
  programs cannot. Is this actually an issue or am I just making stuff up?
 
 
  On Fri, Jun 6, 2014 at 11:39 AM, Ichthyostega p...@ichthyostega.de
 wrote:
 
  Am 06.06.2014 17:54, schrieb Sergey Sharybin:
   Why it might be useful?
 
   C++11 brings some neat syntax and STD library extensions.
 
  ..plus the benefit you can get from using functors / closures wisely.
 
 
 
  Downside is that we have to cut off some platforms / compilers.
 
  Basically we need GCC = 4.7 and Clang = 3.0
 
  And anything below that will not be supported anymore.
  Like RedHat Enterprise Linux. :-P
 
 
  Sounds like something for Blender 2.8.x
 
  --Ichthyo
 
 
 
 
 
  ___
  Bf-committers mailing list
  Bf-committers@blender.org
  http://lists.blender.org/mailman/listinfo/bf-committers
 
 
 
 
  --
  Jeffrey Italic_ Hoover
  ___
  Bf-committers mailing list
  Bf-committers@blender.org
  http://lists.blender.org/mailman/listinfo/bf-committers



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

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

Re: [Bf-committers] Remove Windows MSVC2012 libs?

[Martijn Berger]

Hi,

Nope as long as 2013 and 2008 stay. I think 2012 is unmaintained / unloved
anyway.


On Tue, Jun 3, 2014 at 1:26 AM, Campbell Barton ideasma...@gmail.com
wrote:

 Any issues with removing these from svn:

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

 Neither CMake/SCons reference these and we never officially supported.

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

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

Re: [Bf-committers] Buildbot MSVC 2013

[Martijn Berger]

Hi,

I agree that is would be very welcome to have you continue to do the builds
if you want to do them.
I need to write up some of the things we / you need in order to get Cuda
5.0 working in an environment without msvc 2008.
So feel free to poke me on that.





On Mon, Apr 14, 2014 at 8:34 AM, Sergey Sharybin sergey@gmail.comwrote:

 Hi,

 Earlier we do this is better. Would give more time to find all possible
 issues and so.


 On Mon, Apr 14, 2014 at 1:35 AM, Jeffrey H italic.rendezv...@gmail.com
 wrote:

  Hello, developers.
 
  Seeing as Ton has designated MSVC 2013 to be used for the official 2.71
  builds, when should we make the switch on buildbot? If/when we do switch,
  will I continue to offer my computer with the updated builder or hand it
  off to someone else? I'm more than willing to continue, but if it's
 easier
  and more reliable to leave it to someone else, that's fine with me.
 
  Also a heads-up for the near future. I will be moving back (again) for
  summer, so my system will be down for a couple days starting midnight,
 May
  17 UTC. I plan to be back online when I walk in the door. As always, if
 you
  have any questions or concerns, please email me; I am also in IRC
  (#blender, #blendercoders).
 
  --
  Jeffrey Italic_ Hoover
  ___
  Bf-committers mailing list
  Bf-committers@blender.org
  http://lists.blender.org/mailman/listinfo/bf-committers
 



 --
 With best regards, Sergey Sharybin
 ___
 Bf-committers mailing list
 Bf-committers@blender.org
 http://lists.blender.org/mailman/listinfo/bf-committers

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

Re: [Bf-committers] Buildbot MSVC 2013

[Martijn Berger]

Hi Jeffrey,

In cuda 5.5 and 6.0 there is a regression with texture memory handling that
costs us significant performance I think.
Cuda 5.0 requires msvc 2008 or 2010 to run but since we only use nvcc to
compile a kernel and do dynamic runtime loading of libucda you can just use
the 2008 install you have to keep cuda 5.0 working.

On my system I use the windows 7.0 sdk with updates and a few registry
tweaks to convince the cuda installer I have msvc 2010 installed. This
allows nvcc to use cl.exe from the sdk as a stage 1 compiler yielding a
working toolchain. (
http://wiki.blender.org/index.php/User:Juicyfruit/Cuda_windows)

For Maxwell cards we will also need to use cuda 6.0 or higher so the total
setup might be getting complicated moving forward and I think we should
evaluate with brecht if / how we can move forward to newer cuda. As far as
I know he is also in contact with nvidia about this problem.

I have a very busy week ahead of me but during eastern I might get around
to writing down + testing an exact set of steps to reproduce my environment.

Martijn




On Mon, Apr 14, 2014 at 9:04 AM, Jeffrey H italic.rendezv...@gmail.comwrote:

 Martijn,

 That would be fantastic if you could document how you configured your
 builders.

 Out of curiosity, what is the status of CUDA 5.5? I know we just updated to
 5.0 to support newer cards and kernels, but I haven't seen any discussion
 on using 5.5 yet. I'm already using 5.0 as per Brecht's request.


 On Sun, Apr 13, 2014 at 11:45 PM, Martijn Berger
 martijn.ber...@gmail.comwrote:

  Hi,
 
  I agree that is would be very welcome to have you continue to do the
 builds
  if you want to do them.
  I need to write up some of the things we / you need in order to get Cuda
  5.0 working in an environment without msvc 2008.
  So feel free to poke me on that.
 
 
 
 
 
  On Mon, Apr 14, 2014 at 8:34 AM, Sergey Sharybin sergey@gmail.com
  wrote:
 
   Hi,
  
   Earlier we do this is better. Would give more time to find all possible
   issues and so.
  
  
   On Mon, Apr 14, 2014 at 1:35 AM, Jeffrey H 
 italic.rendezv...@gmail.com
   wrote:
  
Hello, developers.
   
Seeing as Ton has designated MSVC 2013 to be used for the official
 2.71
builds, when should we make the switch on buildbot? If/when we do
  switch,
will I continue to offer my computer with the updated builder or hand
  it
off to someone else? I'm more than willing to continue, but if it's
   easier
and more reliable to leave it to someone else, that's fine with me.
   
Also a heads-up for the near future. I will be moving back (again)
 for
summer, so my system will be down for a couple days starting
 midnight,
   May
17 UTC. I plan to be back online when I walk in the door. As always,
 if
   you
have any questions or concerns, please email me; I am also in IRC
(#blender, #blendercoders).
   
--
Jeffrey Italic_ Hoover
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers
   
  
  
  
   --
   With best regards, Sergey Sharybin
   ___
   Bf-committers mailing list
   Bf-committers@blender.org
   http://lists.blender.org/mailman/listinfo/bf-committers
  
  ___
  Bf-committers mailing list
  Bf-committers@blender.org
  http://lists.blender.org/mailman/listinfo/bf-committers
 



 --
 Jeffrey Italic_ Hoover
 ___
 Bf-committers mailing list
 Bf-committers@blender.org
 http://lists.blender.org/mailman/listinfo/bf-committers

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

Re: [Bf-committers] Revisions for the 2.70a release

[Martijn Berger]

Hi everyone,

About the back-porting of patches. Is there a good reason we do not have a
'2.70-stable' branch on which we can back-port all these.
Now that we have git i think that is would not cost us much and that we
stand much to gain from implementing this.






On Tue, Mar 25, 2014 at 4:53 PM, Sergey Sharybin sergey@gmail.comwrote:

 Hey,

 Still don't really think doing 2.71 a correction release is a good idea,
 too much quite WIP things in the code atm anyway. So thinking of rather
 doing 'a' release.

 Here's the page with the revisions which i consider to be back ported to
 the 'a' release:

 http://wiki.blender.org/index.php/Dev:Ref/Release_Notes/2.70/Bug_Fixes#Fixes_since_2.70_release

 Please don't modify it directly, rather poke me to add/remove stuff in
 there.

 --
 With best regards, Sergey Sharybin
 ___
 Bf-committers mailing list
 Bf-committers@blender.org
 http://lists.blender.org/mailman/listinfo/bf-committers

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

Re: [Bf-committers] Revisions for the 2.70a release

[Martijn Berger]

Hi Sergey,

I am no expert by my understanding has always been that a tag is meant to
refer to a commit. And that a branch is somehow different from this and is
more like a line of commits. Is it possible to make test-builds of  2.70(a)
as it is no envisioned or does it only exist in the form of the wiki page
that holds a list of candidates to be back-ported ?
It might be a semantic discussion but I would like to just be able to
checkout 2.70 + all fixes and make a test build of it. And in the future
maybe even do back-porting of fixes even if mainline has moved on.

thx for your patience in explaining all this.

Martijn



On Tue, Mar 25, 2014 at 6:07 PM, Sergey Sharybin sergey@gmail.comwrote:

 We've got an annotated tag which isn't really different from the branch
 you're suggesting to have.


 On Tue, Mar 25, 2014 at 10:59 PM, Martijn Berger
 martijn.ber...@gmail.comwrote:

  Hi everyone,
 
  About the back-porting of patches. Is there a good reason we do not have
 a
  '2.70-stable' branch on which we can back-port all these.
  Now that we have git i think that is would not cost us much and that we
  stand much to gain from implementing this.
 
 
 
 
 
 
  On Tue, Mar 25, 2014 at 4:53 PM, Sergey Sharybin sergey@gmail.com
  wrote:
 
   Hey,
  
   Still don't really think doing 2.71 a correction release is a good
 idea,
   too much quite WIP things in the code atm anyway. So thinking of rather
   doing 'a' release.
  
   Here's the page with the revisions which i consider to be back ported
 to
   the 'a' release:
  
  
 
 http://wiki.blender.org/index.php/Dev:Ref/Release_Notes/2.70/Bug_Fixes#Fixes_since_2.70_release
  
   Please don't modify it directly, rather poke me to add/remove stuff in
   there.
  
   --
   With best regards, Sergey Sharybin
   ___
   Bf-committers mailing list
   Bf-committers@blender.org
   http://lists.blender.org/mailman/listinfo/bf-committers
  
  ___
  Bf-committers mailing list
  Bf-committers@blender.org
  http://lists.blender.org/mailman/listinfo/bf-committers
 



 --
 With best regards, Sergey Sharybin
 ___
 Bf-committers mailing list
 Bf-committers@blender.org
 http://lists.blender.org/mailman/listinfo/bf-committers

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

Re: [Bf-committers] Blender compiled but cannot run

[Martijn Berger]

As far as I know tinyxml and yaml are included and compiled into the libs
where they are needed. There is no need for a separate library for either
of them.
And sample rate is no longer needed as far as I know.

So there are no current plans to add either of those.



On Fri, Mar 14, 2014 at 1:39 AM, Yousef Hurfoush ba...@msn.com wrote:

 it look like theses libs are missing from vc12 svn:
 samplerate
 tinyxml
 yaml

 will they added soon?

 thank you.

 Regards
 Yousef Harfoush
 ba...@msn.com


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

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

Re: [Bf-committers] Import, research on speed improvements

[Martijn Berger]

Hi all,

Just a side note:
You should be careful to compare blenders obj importer to something awesome
that you have written yourself. There is one thing that can be done to
speed it up greatly but that breaks entities that are split ( started and
finished elsewhere ).
Blenders obj importer needs to build a list now and make sure it got
everything before it can do the actual object import. If you convert this
to a generator you save a ton of memory and get a dramatic speedup. All
normal obj files will load but some exotics won't. It is little things
like this that make the importer slow also besides being written in python.
And it is little things like this that will take a couple of orders of
magnitude of your speedups if you implement an obj importer that has exact
feature parity.



On Mon, Mar 10, 2014 at 8:05 AM, Fredrik hansson 
fredrikhansson_12...@yahoo.com wrote:

 you can always do as i did and grab some of the stanford models they don't
 have uvs/normals but works anyway,
 the xyzrgb_dragon one is 574mb or so and takes 27seconds to load for me or
 7seconds if the file is in the file cache.

 can't say how long blender takes to do the same as it runs out of memory
 and crashes after a few minutes(32bit build)
 it did manage to do the parsing step however 82seconds.
 note that these numbere would be smaller if i was at home haven't got a
 ssd here at work.

 as to Dan's question what i do here is not to thread every line but
 instead load say 1mb of the file at a time split that up
 into sections of1-numcores of lines,  that i then parse and stitch
 together in the original order since i know what order the chunks are.

 the main speedup i found however is to just load the entire file or parts
 of the file into memory and then parse.
 loading the entire thing is if im not mistaken the fastest but uses way to
 much memory while if i load 1mb at a time,
 i actually use less memory than the file size in the end (338mb for the
 xyzrgb dragon)


 // Fredrik




 On Monday, March 10, 2014 5:50 AM, metalliandy 
 metalliandy...@googlemail.com wrote:

 I'm sure I can get something to you, mate. Be aware that the files are
 often 900mb+ though

 I will upload something tomorrow.

 Cheers,

 -Andy

 On 10/03/2014 03:12, Sebastian A. Brachi wrote:
  Andy, could you provide a link to an example to do some benchmarks?
  I'd prefer to work with real user cases than a super-subdivided suzzane.
 
 
  On Sun, Mar 9, 2014 at 8:42 PM, metalliandy
  metalliandy...@googlemail.comwrote:
 
  I have been praying for a faster obj loader for years!
  I use massive objs on a regular basis (up to 900mb) so this would be
  amazing. IMHO all I/O plugins should be done in C/C++ as python just
  doesn't have the speed.
  FWIW, Blender takes about 30mins to export a 31.5m poly mesh while
  ZBrush takes around 2 mins for the same mesh.
 
  Cheers,
 
  -Andy
  On 09/03/2014 19:21, Fredrik hansson wrote:
  hi,
  i
 have recently written a obj loader myself just for fun. now i did
 try
  to
  optimize it quite a bit by making it multithreaded and a few other
  things.
  i have put it up on https://github.com/FredrikHson/fast_obj_loader
  now
 granted this is a much simpler example than doing everything that
  blender does
  with pushing it into blenders internal structure and all that.
  anyway tried it + blenders current importer.
  some stats
  blender total 17.8 sec.
  8.6sec. parse time
 
  mine:
  sigle threaded 0.6seonds
  multi threaded 0.26sec
 
 this is on a 36mb obj file on a ssd drive with 8threads.
 
  so yes it could probably benefit from being done in c/c++ the question
  is still if its worth the trouble
  i personally never import anything much heavier than that 36mb file
  myself due to
  slow viewport/manipulation speeds after actually getting the file into
  blender and 18seconds is
  a bit annoying but i don't do it that often that its really much of an
  issue.
  what is much worse imo is export speeds ( i often forget export
 selected
  only) when dealing with
  dense subsurfed meshes.
 
  // Fredrik
 
 
 
 
 
  On Saturday, March 8, 2014 3:30 AM, Sebastian A. Brachi 
  sebastianbra...@gmail.com wrote:
  Hi Paul,
  I'm pretty satisfied with the performance of my importers right now,
 and
  specially compared to max-script.
  Turned out the major bottleneck was from UV data, since I wasn't using
  foreach_set which is a much efficient method than adding uv data in a
  loop.
  check
 
 
 http://blenderartists.org/forum/showthread.php?321210-Importing-UV-coordinates
  This is for video game data that usually isn't very heavy though
  (although
  I'm also importing whole levels with hundreds of assets, all in ~40
  seconds),
  and also not using an efficient method for unpacking half-floats (used
 a
  lot in video games for uvs).
 
  As I said before, I heard users complaining .obj importer performance
 vs
  zbrush's for example in 500 mb data (sculpts mainly).
  There might be room for improvement 

Re: [Bf-committers] numpy for 2.70

[Martijn Berger]

I have tried compiling numpy but it seems you need either gcc/gfortran when
building for mingw or intel's compiler when building for msvc build python.
There is a version available online that works at:
http://www.lfd.uci.edu/~gohlke/pythonlibs/#numpy.
But there is also a problem. This version is build against the Intel's MKL
(http://software.intel.com/en-us/intel-mkl) a non free but very high
performance math library.
For me the easiest solution would by bundling this version but we it seems
we can not as that would constitute a GPL violation.

It seems we have 3 options.
  - we don't bundle numpy on windows
  - we bundle this numpy and we might violate the GPL
  - we get a copy of Intel's Fortran compiler so we can build and maintain
a version of numpy for use with blender that does not violate the GPL.

I am not a layer and not a numpy specialist, any conclusions drawn above
are the result of my best understanding of our situation


On Mon, Feb 24, 2014 at 1:16 AM, Campbell Barton ideasma...@gmail.comwrote:

 A while ago it was agreed that blender would bundle numpy, with very
 positive response from some script authors and general agreement,

 See meeting minutes:
 http://lists.blender.org/pipermail/bf-committers/2013-April/039809.html

 Previous discussions on the topic:
 http://lists.blender.org/pipermail/bf-committers/2012-November/038215.html
 http://lists.blender.org/pipermail/bf-committers/2012-April/036428.html


 We setup scons and cmake to bundle numpy with Python, and now the 2.70
 Linux build bundles numpy 1.80, but (unless I'm mistaken). OSX and
 ms-windows still don't include numpy.

 If there are no blocking issues - (we can't get numpy to compile for eg...)
 I think its a reasonable target to have numpy bundled on all platforms
 for 2.70, not just for Linux.

 Added tracker tickets for this so this isn't overlooked.
 https://developer.blender.org/T38791
 https://developer.blender.org/T38792

 Maintaining platform deps is often done by volunteers, so if you don't
 have time for it, say so and someone else can try to fill in the gaps.

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

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

Re: [Bf-committers] State of Visual Studio 201X... Warning: may contain chaotic content ...

[Martijn Berger]

Hi Jürgen,

You can also use CUDA 5.0 with windows 7.1 SDK to build cubins and build
rest of blender with MSVC 2013.
The buildbot for MSVC 2013 already does this. I should add cmake support
for it and it is a work around but one that works very well and reliably
for me.

Best Regards,

Martijn



On Mon, Feb 17, 2014 at 6:54 PM, Jürgen Herrmann shadow...@me.com wrote:

 Hey there,



 I had some time to look into blender code recently and found some
 disturbing
 problems with both VS2012 and VS 2013.

 With Visual Studio 2013 released I would like to drop support for 2012 and
 take the transition to VS 2013 directly because of the much better
 C99/C++11
 support.

 I think we should bundle resources on one migration project instead of
 porting to two different versions of VC.



 But (there is always a But ;):



 Unfortunately Nvidia seems to be unable to release a Cuda toolkit with
 Compiler support for VC12. That's driving me crazy. Cuda 6 RC does not
 support VS2013 and I am not sure when they get this done.

 IMHO there are multiple possibilities how to handle this:



 1.)Port to MSVC 2013 and port Cycles' kernel to C++/AMP (I bet this can
 be done)

 a.   Pro: Makes us independent from NVidia Cuda and OpenCL fuzz

 b.  Pro: Updates to VS are easier because we won't have to wait for
 NVidia

 c.   Contra: Generates a lot of work (one time work load)

 d.  Contra: Another Cycles kernel that has to be maintained

 2.)Port to VS2012/Cuda 5.5 and postpone our effords on VS2013 until we
 get a working compiler from NVidia

 a.   Pro: Majority of work is done, we'll just have to tie everything
 together and fix some problems

 b.  Contra: We'll end up waiting for NVidia until we can make a
 transition to a newer VS version

 c.   We may have to stick to this version of VS literally forever
 like
 we did with VS2008

 3.)We stick to VS2008 / Cuda 5.0

 a.   Pro: Nothing to do, just go on as is.

 b.  Contra: No possibility to use newer technology

 c.   Contra: Binaries might have compatibility issues with future
 versions of Windows (9+)

 4.)Any other ideas?



 I'd like to hear an official decision before I get started just to avoid a
 waste of resources and time.



 Best regards,



 Jürgen

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

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