Re: [Bf-committers] MacOS developers welcome!

[Mike Erwin]

On Tue, May 28, 2019 at 8:44 AM Levi Bradford 
wrote:

> My iMac is reasonably fast for my purposes, but I’d like clarification on
> the required specifications. Is a i7 7700K with 32GB of RAM recent enough?
> Is it powerful enough?
>

Yes that is more than powerful enough! My early Blender dev work was done
on a PowerBook G4, and lots more on a 2012 MBP which I still use.


Also I'd like to help! Will have time after SIGGRAPH, and some new hardware
if all goes well.

Mike Erwin
musician, naturalist, pixel pusher, hacker extraordinaire
___
Bf-committers mailing list
Bf-committers@blender.org
https://lists.blender.org/mailman/listinfo/bf-committers

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

[Mike Erwin]

+1 on all points.

Unifying around MSVC 2017 would clean up our build instructions & benefit
from MS's latest bug fixes.

MacOS has been 64-bit only since 10.7 (Lion) so it won't affect any users
there.

While I appreciate vintage computers, and have lots of 32-bit systems
myself, I don't expect to run the latest software on them.

Mike Erwin
musician, naturalist, pixel pusher, hacker extraordinaire

On Fri, Jan 26, 2018 at 12:51 PM, Ray Molenkamp <r...@lazydodo.com> wrote:

> All,
>
> With 2.8 coming up I'd like to make some changes to the supported
> compilers for Blender. However since these are rather large changes
> I'd like to give everyone an opportunity to express any concerns.
>
> Issues:
>
> 1) Currently we support msvc 2013(vc12)/2015(vc14)/2017(vc14)
> for building, however we ship all our releases with msvc2013(vc12). This
> has
> lead to some interesting issues with python, since any binary addons the
> user
> might install with pip (or just manually copy in) will be using the vc14
> crt.
> It's rare to run into issues, but when it does it's an instant process
> termination
> (the crt does not deal meeting it's future/past self very well)
>
> Given python is our most important dependency I'd like to propose that any
> blender
> version we ship in the future (2.8+, 2.79x can keep doing what it's doing)
> matches
> the official python recommendation for that version [1] so we have maximum
> compatibility with any python addons
>
> 2) To support msvc 2017 we'll officially need a newer boost version, sadly
> support
> for the latest is only available in 1.66 and i have not tested yet if all
> our
> dependencies can actually build against it. However we have no failing
> tests when
> building blender with boost 1.60+2017. it is just a bit (212 warns) chatty
> with
> unknown compiler warnings, we could possibly repress these.
>
> 3) We recently added a switch in cmake to force the compiler to read all
> our code
> as utf-8 (since there were some users on other codepages that got compiler
> errors
> on some utf8 strings) this added 290 C4828 compiler warnings to a full
> blender build.
> not great. None of these originate in our code, they are dragged in though
> 3rd party
> headers.
>
> 10 in extern/bullet (we can probably fix these)
> 19 in lib/boost (this one is fixed in newer boost versions [2])
> 261 in lib/OpenCollada (we can easily send a pull upstream)
>
> however all of these are in comments, completely repressing C4828 might
> not be the
> worst thing here.
>
> 4) Libraries
>
> There's a library upgrade [3] coming up for OSL/LLVM/OIIO that just
> doesn't build on
> msvc2013.
>
> 5) Cuda
>
> Nvidia is notoriously slow with supporting newer msvc versions severely
> limiting the
> compiler versions we can use (cuda9 only supports 2017 RTM, and we're on
> update 5
> for msvc currently), to resolve this hostage situation I have created a
> small wrapper
> around nvrtc that's able to compile cycles [4], however nvidia doesn't
> allow nvrtc
> to create 32 bit cubins. which held me back from committing it.
>
> 6) 32 bit support
>
> I spend a fair amount of time building the blender deps in various
> formats, x86
> it starting to cost more and more time since a few of the projects just
> seem
> to test on linux, sometimes on windows/x64 but rarely on x86 leading to
> all kinds
> of obscure (usually sse) related build errors. This is starting to take up
> a
> significant amount of my time for only a small percentage of end users
> (last
> time I asked ~15% of the blender downloads were for 32 bit users) and by
> the
> time we release 2.8 this number will probably have dropped even further.
>
> Proposal:
>
> Officially drop msvc 2013 support for master/2.80 and make vs2017.5 the
> new standard.
>
> 1) Land D2913, I had been dragging my heels on this because of the
> breakage for x86
> but given brecht recently put out an email [5] saying we were going to
> drop support
> there's no reason not to apply this anymore.
>
> 2) Retire the 2013+2015 buildbots, and replace them with vs2017 based
> builds.
>
> 3) Block msvc2013 version in cmake
>
> 4) Remove the vc12 folders from svn
>
> 5) Silence the 'unknown compiler warning in our boost version'
>
> 6) Add C4828 to the ignored warning list.
>
> 7) Update the wiki build instructions.
>
> I can do most of these my self, but will probably need sergey to do no 2.
>
> Pushing my luck:
>
> Is it too soon to drop x86 support?
>
> Note that all of these changes are for master/2.80. any updates for 2.79
> a/b/c/etc
> will remain on msvc2013 with the current libraries.
>
> --Ray
>
> 

Re: [Bf-committers] Build blender for Arm architecture

[Mike Erwin]

Raspbian makes blender available through the package manager. I've run it
on a Pi 2 .. not perfect but it definitely works! Let us know what you
learn from this experience.

Mike Erwin
musician, naturalist, pixel pusher, hacker extraordinaire

On Tue, Aug 15, 2017 at 7:49 PM, Nkansah Rexford <nkansahrexf...@gmail.com>
wrote:

> I understand only 3 platforms are supported for blender now.
>
> As a learning experience, I wanna build blender for arm (specifically a Pi
> 3 model). I currently have the source code and builds all succeed fine!
>
> End goal is to build blender targeting arm architecture as a python module
> on my ubuntu box, then run the headless module on the Pi.
>
> Will appreciate pointers.
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> https://lists.blender.org/mailman/listinfo/bf-committers
>
___
Bf-committers mailing list
Bf-committers@blender.org
https://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Blender 2.8 planning notes 2017-07-24

[Mike Erwin]

On Mon, Jul 24, 2017 at 8:31 AM, Campbell Barton <ideasma...@gmail.com>
wrote:
>
>
> Meeting agrees we don't like to do planning behind closed-doors and to
> to move future meetings into #blendercoders
> So others can more easily be involved in 2.8x development.
>

Yes!!! An open development process is one of our greatest advantages.

Mike Erwin
musician, naturalist, pixel pusher, hacker extraordinaire
___
Bf-committers mailing list
Bf-committers@blender.org
https://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Does 2.8 deserve a different splash image already?

[Mike Erwin]

How about something with an "under construction" theme, like a 90s website.
A hint that it's pre-release.

On Thu, Jun 8, 2017 at 10:05 AM blendergit <blender...@gmail.com> wrote:

>
> Hi all,
>
> I'm only wanted to share a thought I have had during my long testing
> sessions.
>
> During the test, sometimes I have to run in parallel version 2.78 and
> version 2.80 and when you start dozens of times Blender is very annoying
> (and prone to make mistakes) to review the version number to check if you
> are running 2.78 or 2.80.
>
> I think we have done a lot of work in 2.8 and it deserves already a
> different image for splash window and start to get a visual hint of what
> version are you running.
>
> This is only an idea, maybe I'm totally wrong.
>
> Cheers,
> Antonio Vazquez
>
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> https://lists.blender.org/mailman/listinfo/bf-committers
>
-- 
Mike Erwin
musician, naturalist, pixel pusher, hacker extraordinaire
___
Bf-committers mailing list
Bf-committers@blender.org
https://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Welcome to core profile (Blender 2.8)

[Mike Erwin]

OpenGL ES 3.0 is closer to our new desktop requirements. For me at least,
Android / GLES has been low priority. Would rather make the desktop /
laptop experience better even if that excludes other devices.

Mike Erwin
musician, naturalist, pixel pusher, hacker extraordinaire

On Fri, May 12, 2017 at 4:49 AM, Dalai Felinto <dfeli...@gmail.com> wrote:

> > How hard would it be from here for a android build?
>
> No idea. The GSoC about android port of Blender and Blender Player
> never got the documentation public about the building process.
> That said, support for OpenGL ES 2.0 should be quite straighforward
> since it's mostly compatible to 3.x core profile last I heard.
> --
> blendernetwork.org/dalai-felinto
> www.dalaifelinto.com
>
>
> 2017-05-12 6:10 GMT+02:00 Jacob Merrill <blueprintrand...@gmail.com>:
> > How hard would it be from here for a android build?
> >
> > On Thu, May 11, 2017 at 3:33 PM, Mike Erwin <significant@gmail.com>
> > wrote:
> >
> >> Yay!!! So glad we finally made it to this point. Now all platforms
> are
> >> on the same modern GL version and we don't need hacky fallbacks.
> >>
> >> Suppose we can call this task done:
> >> https://developer.blender.org/T49012
> >> even though we still have implementation and cleanup ahead.
> >>
> >>
> >> Mike Erwin
> >> musician, naturalist, pixel pusher, hacker extraordinaire
> >>
> >> On Thu, May 11, 2017 at 11:14 AM, Julian Eisel <eiseljul...@gmail.com>
> >> wrote:
> >>
> >> > Hi,
> >> >
> >> > First off: Great news! Huge kudos to the people involved!
> >> >
> >> > Just to make it clear, the core profile refers to OpenGL 3.3.
> >> > There are effectively multiple core profiles, so better to be precise
> >> > which one we're talking about ;)
> >> >
> >> > Cheers,
> >> > - Julian -
> >> >
> >> > On 11 May 2017 at 17:05, Dalai Felinto <dfeli...@gmail.com> wrote:
> >> > > Dear all,
> >> > >
> >> > > As of now, Blender 2.8 builds only with core profile. That means:
> >> > >
> >> > > * No more toggling CMake flags when switching back and forth from
> >> master
> >> > to 2.8
> >> > > * No more crashes for Mesa and Apple users getting Blender from
> builder
> >> > bot
> >> > >
> >> > > On a related note, modifiers and dupli objects are still not
> supported
> >> > > by the new 2.8 viewport. However you can still use the blender
> >> > > internal with solid mode to see your data. This is mostly for things
> >> > > like alembic development, for example. Expect some caveats (screen
> >> > > effects such as Dof or Matcap won't work, edit mode will crash,
> ...).
> >> > >
> >> > > Thanks everyone for the amazing work.
> >> > >
> >> > > Dalai and Sergey
> >> > > ___
> >> > > 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] Welcome to core profile (Blender 2.8)

[Mike Erwin]

Yay!!! So glad we finally made it to this point. Now all platforms are
on the same modern GL version and we don't need hacky fallbacks.

Suppose we can call this task done:
https://developer.blender.org/T49012
even though we still have implementation and cleanup ahead.


Mike Erwin
musician, naturalist, pixel pusher, hacker extraordinaire

On Thu, May 11, 2017 at 11:14 AM, Julian Eisel <eiseljul...@gmail.com>
wrote:

> Hi,
>
> First off: Great news! Huge kudos to the people involved!
>
> Just to make it clear, the core profile refers to OpenGL 3.3.
> There are effectively multiple core profiles, so better to be precise
> which one we're talking about ;)
>
> Cheers,
> - Julian -
>
> On 11 May 2017 at 17:05, Dalai Felinto <dfeli...@gmail.com> wrote:
> > Dear all,
> >
> > As of now, Blender 2.8 builds only with core profile. That means:
> >
> > * No more toggling CMake flags when switching back and forth from master
> to 2.8
> > * No more crashes for Mesa and Apple users getting Blender from builder
> bot
> >
> > On a related note, modifiers and dupli objects are still not supported
> > by the new 2.8 viewport. However you can still use the blender
> > internal with solid mode to see your data. This is mostly for things
> > like alembic development, for example. Expect some caveats (screen
> > effects such as Dof or Matcap won't work, edit mode will crash, ...).
> >
> > Thanks everyone for the amazing work.
> >
> > Dalai and Sergey
> > ___
> > Bf-committers mailing list
> > Bf-committers@blender.org
> > https://lists.blender.org/mailman/listinfo/bf-committers
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> https://lists.blender.org/mailman/listinfo/bf-committers
>
___
Bf-committers mailing list
Bf-committers@blender.org
https://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Blender 2.8 planning notes 01/05/17

[Mike Erwin]

On Mon, May 1, 2017 at 12:01 PM, Bastien Montagne <montagn...@wanadoo.fr>
wrote:

> * drawmesh.c and drawobject.c: Those have most of the remaining calls,
> question here is, should I port them? If I have understood correctly,
> those files won't be used at all in near future, once we fully switch to
> drawmanager, correct? in that case, we can either remove the
> setlinestyle calls (with a comment that it needs dashed line), or just
> keep them around for now?
>

The simplest way is to keep those setlinestyle calls, but change the
setlinestyle function to do nothing under core profile. That way the calls
act like comments.

Mike Erwin
musician, naturalist, pixel pusher, hacker extraordinaire
___
Bf-committers mailing list
Bf-committers@blender.org
https://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Please add invert green channel option in Normal Map node

[Mike Erwin]

On Fri, Apr 14, 2017 at 10:47 AM, Adriano Oliveira <adriano.u...@gmail.com>
wrote:

> I just miss one little thing: An check box option to invert textures' green
> chennels in the Normal Map node.
>
> This is very important because Blender follow the OpenGL norms for Normal
> Map, but other softwares that may be integrated within a pipeline (like
> Unreal) uses DirectX norms.
>

Is this only needed during import & export, or something you would toggle
during the Blender session?

Mike Erwin
musician, naturalist, pixel pusher, hacker extraordinaire
___
Bf-committers mailing list
Bf-committers@blender.org
https://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Blender 2.8 gpu matrix API design questions

[Mike Erwin]

This patch rejects a fundamental change I've been trying to make -- that 2D
is different from 3D and deserves its own best implementation.

What I like about this patch:
- it makes our matrix API closer to old familiar OpenGL
- user code doesn't need to setup/teardown <-- best part
- code is shorter

That's about it!

If my fellow devs prefer this unified matrix stack (focused on 3D) then
let's use it. I can express these ideas about 2D graphics outside of
Blender.

Mike Erwin
musician, naturalist, pixel pusher, hacker extraordinaire

On Fri, Apr 14, 2017 at 9:03 AM, Dalai Felinto <dfeli...@gmail.com> wrote:
>
> Hi,
> While waiting for a reply I went ahead and implemented the following
patch:
> "GPU Matrix API: stick to a single 4x4 matrix stick for 2D and 3D" [1].
>
> With this we get the interface and viewport fully working in core profile
[2].
>
> Notes:
> 1) The text glitches are unrelated to the matrix situation.
> 2) Nothing changes if you build 2.8 with compatibility profile instead
> 3) For comparison, this is blender2.8 built with core profile without
> this patch [3] (--factory-startup) and [4] (special file in fullscreen
> and clay engine).
>
> [1] - https://developer.blender.org/D2626
> [2] - http://pasteall.org/pic/show.php?id=114662
> [3] - http://pasteall.org/pic/show.php?id=114663
> [4] - http://pasteall.org/pic/show.php?id=114664
>
> Cheers,
> Dalai
> --
> blendernetwork.org/dalai-felinto
> www.dalaifelinto.com
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> https://lists.blender.org/mailman/listinfo/bf-committers
___
Bf-committers mailing list
Bf-committers@blender.org
https://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Blender 2.8 OpenGL 3.3 planning notes 10/04/17

[Mike Erwin]

On Mon, Apr 10, 2017 at 6:34 AM, Luca Rood <d...@lucarood.com> wrote:

> Quick notes:
> - Dalai reminds everyone about the documents by Mike this weekend:
> "Blender GL/Vulkan status" [1] and "Blender OpenGL/Vulkan status 2" [2].
>
> [1] https://docs.google.com/document/d/1q_squazSfHhwYnpV3yO3SuNXWSCvDhV8
> 3OFCXkyMzcY/edit
> [2] https://docs.google.com/document/d/17xF5urqTkOZQYlXcgXMJURcI2pxt_
> qiwZdlLxoTG2oU/edit


To put these docs in context, here's the mail I sent to bf-viewport:

-- Forwarded message --
From: Mike Erwin <significant@gmail.com>
Date: Sun, Apr 9, 2017 at 11:46 PM
Subject: OpenGL status report
To: bf-viewp...@blender.org


Hi all,
I'm writing a status report for AMD, who (hopefully) will continue
supporting my work. It's not yet finished but I want to share it here
before bed and get feedback while I sleep :)

https://docs.google.com/document/d/17xF5urqTkOZQYlXcgXMJURcI2pxt_
qiwZdlLxoTG2oU/edit?usp=sharing

And here's an earlier draft report from January.

https://docs.google.com/document/d/1q_squazSfHhwYnpV3yO3SuNXWSCvDhV8
3OFCXkyMzcY/edit?usp=sharing

These focus mostly on the parts I directly work on, but I thought they'd be
of interest to other devs here. Especially since we're about to start a big
push toward OpenGL core profile.

Feel free to add comments/suggestions to these docs! I'm aiming to submit
this (April report, first link) on Monday, Tuesday at the latest.

Mike Erwin
musician, naturalist, pixel pusher, hacker extraordinaire
___
Bf-committers mailing list
Bf-committers@blender.org
https://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] REF: GSoC Import/Export Support

[Mike Erwin]

On Wed, Mar 29, 2017 at 5:05 PM, Benson Chepkwony  wrote:
>
> I have not seen any work that relates with the
> Blendergltf Import.
>

That's because glTF is a delivery format for final assets. Most of the time
you would want Blender & other content creation apps to export only, and
games to import only. Bidirectional workflows use interchange formats like
FBX or Collada, not glTF.

Importing glTF to Blender would be nice though! Export was simply more
important to tackle first, so that's what people have worked on.

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

Re: [Bf-committers] REF: GSoC Import/Export Support

[Mike Erwin]

Hi Benson, I can answer some of these questions.

The latest Blender glTF exporter can be found at
https://github.com/Kupoman/blendergltf. It's implemented in Python (same as
nearly all import/export code).

Right now glTF is mostly used for WebGL engines, but it should not be
limited to that. LibreOffice and a future version of MS Office can import
glTF assets. I expect other game engines & applications to add glTF once it
becomes more mainstream.

Read more about the glTF format at https://github.com/KhronosGroup/glTF.
It's JSON (not XML) with lots of binary data. The spec describes the object
model. Current spec is 1.0; 2.0 is nearly finished.

Import/export plugin will probably be invoked from the user interface. Just
a simple menu item.

Hope this helps!

Mike Erwin
musician, naturalist, pixel pusher, hacker extraordinaire

On Tue, Mar 28, 2017 at 11:30 AM, Benson Chepkwony <bchepk...@att.net>
wrote:

> Hi,
> Hay, I would like to ask a few regarding the Import/Export support for
> gITF file format project.
> 1. How is the current Import/Export implemented?
> 2. Does the Import/Export targets web applications only or non-web
> applications too?
> 3. What is the Import/Export pipeline made of?
> 4. Where is the best place to start on this project?
> 5. Is the gITF scene encoded with XML or DOM?
> 6. Is Import/Export process to be invoked from User Interface, Import
> Wizard or from a command line?
> 7. Is there any criteria that the Import/Export loader should be
> implemented?
>
> Thank you.
>
> Sincerely,
> Benson Chepkwony
>
> ___
> 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] [Bf-viewport] render-layers and clay-engine branches merged in blender2.8

[Mike Erwin]

Thanks for fixing these issues so quickly!

There *was* a very big reason to move development, but after testing the
latest blender2.8 on Mac, things are much better now. Ready for
reunification.

Mike Erwin
musician, naturalist, pixel pusher, hacker extraordinaire

On Fri, Feb 10, 2017 at 3:26 PM, Dalai Felinto <dfeli...@gmail.com> wrote:

> Hi,
>
> > a temp-blender2.8-stable branch (...)
>
> Can we get rid of it now? Blender2.8 has those issues solved already.
> There is no reason to move development away from it.
>
> Cheers,
> Dalai
> --
> blendernetwork.org/dalai-felinto
> www.dalaifelinto.com
>
>
> 2017-02-07 21:03 GMT+01:00 Mike Erwin <significant@gmail.com>:
> > A few things need to be fixed ASAP to make 2.8 usable:
> > - select objects in the (non-clay) viewport
> > - visual feedback during object transform (G, S, R)
> >
> > LucaRood made a temp-blender2.8-stable branch that excludes these merges
> so
> > other people can continue working. Any work there will be merged back
> into
> > blender2.8.
> >
> > FYI (everyone) the clay engine does not work on Mac or Mesa. Expect it to
> > crash! Windows or Linux with vendor drivers are the best platforms for
> > testing. Once we finish the GL upgrade to 3.3 core profile it will work
> > everywhere.
> >
> > Mike Erwin
> > musician, naturalist, pixel pusher, hacker extraordinaire
> >
> > On Tue, Feb 7, 2017 at 5:45 AM, Dalai Felinto <dfeli...@gmail.com>
> wrote:
> >
> >> Hi there,
> >> Just to inform the list that the viewport related branches were merged
> >> in blender2.8.
> >>
> >> Render-Layers:
> >> https://developer.blender.org/rBaeb8e81f2741aabc95d14bce7a83
> cef45481959c
> >>
> >> Clay-Engine:
> >> https://developer.blender.org/rB83adc544382689217e19564fd5f2
> dd62160956cb
> >>
> >> The branches still have todos, and help is welcome as usual. Refer to
> >> their respective commits for more details.
> >>
> >> Apart from that the merges were done "manually", squashing the
> >> branches into single commits.
> >>
> >> In other words, if you had a fork of one of those branches (as I know
> >> at least Alexander Romanov had), you will need to manually cherry-pick
> >> your work to be on top of blender2.8. Poke me on IRC (dfelinto at
> >> #blendercoders) if you need any assistance.
> >>
> >> All the best,
> >> Dalai
> >> --
> >> blendernetwork.org/dalai-felinto
> >> www.dalaifelinto.com
> >> ___
> >> Bf-viewport mailing list
> >> bf-viewp...@blender.org
> >> https://lists.blender.org/mailman/listinfo/bf-viewport
> >>
> > ___
> > 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] [Bf-viewport] render-layers and clay-engine branches merged in blender2.8

[Mike Erwin]

A few things need to be fixed ASAP to make 2.8 usable:
- select objects in the (non-clay) viewport
- visual feedback during object transform (G, S, R)

LucaRood made a temp-blender2.8-stable branch that excludes these merges so
other people can continue working. Any work there will be merged back into
blender2.8.

FYI (everyone) the clay engine does not work on Mac or Mesa. Expect it to
crash! Windows or Linux with vendor drivers are the best platforms for
testing. Once we finish the GL upgrade to 3.3 core profile it will work
everywhere.

Mike Erwin
musician, naturalist, pixel pusher, hacker extraordinaire

On Tue, Feb 7, 2017 at 5:45 AM, Dalai Felinto <dfeli...@gmail.com> wrote:

> Hi there,
> Just to inform the list that the viewport related branches were merged
> in blender2.8.
>
> Render-Layers:
> https://developer.blender.org/rBaeb8e81f2741aabc95d14bce7a83cef45481959c
>
> Clay-Engine:
> https://developer.blender.org/rB83adc544382689217e19564fd5f2dd62160956cb
>
> The branches still have todos, and help is welcome as usual. Refer to
> their respective commits for more details.
>
> Apart from that the merges were done "manually", squashing the
> branches into single commits.
>
> In other words, if you had a fork of one of those branches (as I know
> at least Alexander Romanov had), you will need to manually cherry-pick
> your work to be on top of blender2.8. Poke me on IRC (dfelinto at
> #blendercoders) if you need any assistance.
>
> All the best,
> Dalai
> --
> blendernetwork.org/dalai-felinto
> www.dalaifelinto.com
> ___
> Bf-viewport mailing list
> bf-viewp...@blender.org
> https://lists.blender.org/mailman/listinfo/bf-viewport
>
___
Bf-committers mailing list
Bf-committers@blender.org
https://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Viewport project - plan of action

[Mike Erwin]

On Sat, Dec 17, 2016 at 3:29 PM, Jacob Merrill <blueprintrand...@gmail.com>
wrote:

> The upbge team would like to work closer with the viewport team,
>
> maybe the upbge team can have a 2.8 ge branch in upbge git that pulls down
> from your branch?
>

panzergame keeps me up to date on UPBGE - blender2.8 merge issues. The
ongoing OpenGL upgrade in blender2.8 makes it rather tricky. Will be better
once that part is finished!


> panzergame has done quite a bit of drawing code mods in upbge
> maybe some of these commits can help the viewport team?
>

Yes! I follow UPBGE progress on Github and encourage other Blender viewport
devs to do the same.


> Will the game engine be using evee?


They'll most likely use the same or similar drawing code, right? Since
that's just a name of a thing that does not yet exist it's hard to make
predictions.

Mike Erwin
musician, naturalist, pixel pusher, hacker extraordinaire
___
Bf-committers mailing list
Bf-committers@blender.org
https://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Viewport project - plan of action

[Mike Erwin]

Jacob Merrill <blueprintrand...@gmail.com> wrote:

> will instancing and static draw call batching be planned for the realtime
> render?
>

Not sure to what extent we can do these, but high performance & low
overhead continue to be goals. This includes instancing & sharing draw
data. Remember that this is primarily for editing/creating. Game engines
have a natural performance advantage vs. an interactive viewport.

is forward+ rendering possible with a 3.2 glsl profile?
>
>
If so we'll have to use OpenCL for the light culling part. GLSL doesn't
provide compute shaders until version 4.3. Btw we're targeting GL 3.3 now,
a small step up from 3.2.

Mike Erwin
musician, naturalist, pixel pusher, hacker extraordinaire
___
Bf-committers mailing list
Bf-committers@blender.org
https://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Libraries update required

[Mike Erwin]

Just saw the fixes in master. Thanks!

To get "make full" working I still have to disable WITH_CODEC_QUICKTIME
(missing system headers) and WITH_CYCLES_OPENSUBDIV (link error).

Mike Erwin
musician, naturalist, pixel pusher, hacker extraordinaire

On Sat, Dec 3, 2016 at 11:50 PM, Mike Erwin <significant@gmail.com>
wrote:
>
> On Sat, Dec 3, 2016 at 10:25 AM, Brecht Van Lommel <
brechtvanlom...@pandora.be> wrote:
> >
> > I have updated the new macOS 10.9 libraries to these versions.
> > https://developer.blender.org/rBL61756
>
> I'm having trouble building with "make full" on latest Mac OS. "make
lite" builds & runs fine with the updated libs. Disabling build options
helps, but one of those options is Cycles which pulls in OIIO.
WITH_CYCLES_OPENSUBDIV also gives link errors.
>
> Is anyone else able to "make full" on Mac?
___
Bf-committers mailing list
Bf-committers@blender.org
https://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Libraries update required

[Mike Erwin]

On Sat, Dec 3, 2016 at 10:25 AM, Brecht Van Lommel <
brechtvanlom...@pandora.be> wrote:
>
> I have updated the new macOS 10.9 libraries to these versions.
> https://developer.blender.org/rBL61756

I'm having trouble building with "make full" on latest Mac OS. "make lite"
builds & runs fine with the updated libs. Disabling build options helps,
but one of those options is Cycles which pulls in OIIO.
WITH_CYCLES_OPENSUBDIV also gives link errors.

Is anyone else able to "make full" on Mac?

Mike Erwin



Undefined symbols for architecture x86_64:

  "_WebPConfigInitInternal", referenced from:


OpenImageIO::v1_6::webp_pvt::WebpOutput::open(std::__1::basic_string<char,
std::__1::char_traits, std::__1::allocator > const&,
OpenImageIO::v1_6::ImageSpec const&,
OpenImageIO::v1_6::ImageOutput::OpenMode) in
libOpenImageIO.a(webpoutput.cpp.o)

  "_WebPDecodeRGBA", referenced from:


OpenImageIO::v1_6::webp_pvt::WebpInput::open(std::__1::basic_string<char,
std::__1::char_traits, std::__1::allocator > const&,
OpenImageIO::v1_6::ImageSpec&) in libOpenImageIO.a(webpinput.cpp.o)

  "_WebPEncode", referenced from:

  OpenImageIO::v1_6::webp_pvt::WebpOutput::write_scanline(int, int,
OpenImageIO::v1_6::TypeDesc, void const*, long) in
libOpenImageIO.a(webpoutput.cpp.o)

  "_WebPGetDecoderVersion", referenced from:

  OpenImageIO::v1_6::webp_imageio_library_version() in
libOpenImageIO.a(webpinput.cpp.o)

  "_WebPGetInfo", referenced from:


OpenImageIO::v1_6::webp_pvt::WebpInput::open(std::__1::basic_string<char,
std::__1::char_traits, std::__1::allocator > const&,
OpenImageIO::v1_6::ImageSpec&) in libOpenImageIO.a(webpinput.cpp.o)

  "_WebPPictureFree", referenced from:

  OpenImageIO::v1_6::webp_pvt::WebpOutput::close() in
libOpenImageIO.a(webpoutput.cpp.o)

  "_WebPPictureImportRGB", referenced from:

  OpenImageIO::v1_6::webp_pvt::WebpOutput::write_scanline(int, int,
OpenImageIO::v1_6::TypeDesc, void const*, long) in
libOpenImageIO.a(webpoutput.cpp.o)

  "_WebPPictureImportRGBA", referenced from:

  OpenImageIO::v1_6::webp_pvt::WebpOutput::write_scanline(int, int,
OpenImageIO::v1_6::TypeDesc, void const*, long) in
libOpenImageIO.a(webpoutput.cpp.o)

  "_WebPPictureInitInternal", referenced from:


OpenImageIO::v1_6::webp_pvt::WebpOutput::open(std::__1::basic_string<char,
std::__1::char_traits, std::__1::allocator > const&,
OpenImageIO::v1_6::ImageSpec const&,
OpenImageIO::v1_6::ImageOutput::OpenMode) in
libOpenImageIO.a(webpoutput.cpp.o)
___
Bf-committers mailing list
Bf-committers@blender.org
https://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] GSoC-2017

[Mike Erwin]

On Thu, Dec 1, 2016 at 11:35 PM, Jacob Merrill <blueprintrand...@gmail.com>
wrote:
>
> The 2.8 project will also undoubtedly have sections that need work, so I
> would get on the viewport mail list, and also look into openGL/ glsl, and
> vulkan etc. (if you plan on working with the graphics pipeline)
> shadertoy.com is cool for this.


By the April / May application time, 2.8 will be further along and ready
for new people to join in!

Mike Erwin
musician, naturalist, pixel pusher, hacker extraordinaire
___
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.

[Mike Erwin]

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.

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!

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.

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.

Mike Erwin
musician, naturalist, pixel pusher, hacker extraordinaire
___
Bf-committers mailing list
Bf-committers@blender.org
https://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] UPBGE Discussion.

[Mike Erwin]

I'm in the "support external engines" camp but that does not mean we drop
BGE. I follow the UPBGE project on GitHub and they're doing really great
work. Look forward to further discussions on IRC and bf-viewport!

Mike Erwin
musician, naturalist, pixel pusher, hacker extraordinaire

On Mon, Nov 14, 2016 at 4:25 AM, Jorge Bernal <jbernalmarti...@gmail.com>
wrote:

> Hi,
>
> Let me introduce a bit more the purpose of this request for all people that
> don’t know what UPBGE is.
>
> During last BGE meeting, around one and half year ago, it was established,
> at least, 3 ways to follow regarding the blender game engine. To summarize,
> one of them was to adapt the blender code to embrace existing external
> engines (under this way are Armory, Panda, Godot, etc), another one was to
> create a new internal and tiny game engine (no one is working in this way
> at this moment) and the last one was to refactor the BGE progressively to
> reach a new up to date standard (UPBGE is a project that follows that last
> way).
>
> Then, taking into account, that the current workflow that we were
> conducting to modify the BGE (through developer.blender.org differential
> diff/patches) was so slow for a big refactor as this one it was done a new
> branch/fork in github (https://github.com/UPBGE/blender).
>
> During this last year a great effort has been put by UPBGE/BGE developers
> to refactor the code with that goal in mind. Now our purpose is to try
> backporting all the new changes and refactors into the 2.8 branch (or a
> parallel one) to bring the BGE to a new life (and successful one, we hope)
> life. :-)
>
> Here below there is a summarize of main modifications done to BGE (check
> release notes in https://doc.upbge.org/ for a deeper explanation):
>
>
>
> -  *Main Refactors*:
>
> oThe event system was totally reworked. Now there is a Device folder
> containing all device related code (keyboard, mouse and joysticks). With
> this refactor we can assure, at last, that the game engine won’t lose
> events even with low-very low fps anymore. Additionally, the joystick part
> follows the new database standard defined by steam to homogenize the
> joysticks nightmare.
>
> o   A new common launcher system was developed. It was done to reduce
> duplicated code between embedded player and external player.
>
> o   New FBO renderer using GPU_framebuffer / GPU_texture. Off screen
> rendering consists in render the scene directly to an off screen (FBO with
> color texture and depth texture) and at the frame end render the off screen
> to screen. Internally a lot of things are improved and simplified like the
> 2d filters, render textures and soft particles.
>
> o   Multitexture mode was removed to fulfil with new OpenGL 3.3 & on goal.
>
> o   Vertex Arrays + Display lists were removed too. At this moment, we have
> only VBOs. The VBOs were improved a lot to overpass the Vertex arrays +
> Display List performance.
>
> o   Refactor of Rasterizer OpenGL calls. The goal of this refactor is to
> reduce the opengl calls outside of Rasterize module.
>
> o   New 2D Filter python Proxy. The user can now access to the filters from
> the scene in python from a filter manager.
>
> o   Variable vertex memory size implemented. A new system with template
> vertex class is used internally. This system allows to reduce memory usage
> by reducing the number of UV layers used, in the same way the mesh
> transformations are optimized.
>
> o   Triangle rendering. All the meshes are rendered as triangle now.
>
> o   Lots and lots and lots of more tiny refactors and cleanups. You can
> check them in the release notes.
>
> - * New features implemented*:
>
> o   Geometry instancing
>
> o   Parallax mapping
>
> o   Subsurface Scattering
>
> o   Realtime Cubemaps (including reflection and refractions)
>
> o   Python components
>
> o   Mipmap per texture
>
> o   GLSL Text Highlighting
>
> o   New LOD system
>
> o   New movement Sensor and Joystick Vibration actuator logic bricks
>
> o   Joystick Sensor adapted to Xbox360 joystick standard.
>
> o   Constant material values
>
> o   Geometry shaders
>
> o   Ray sensor mask
>
> o   Update of bounding box in realtime
>
> o   New python console interpreter can be launched in-game
>
> o   Soft particles (also called Depth transparency)
>
> o   Static shadow rendering
>
> o   Sky background render
>
> o   Material Texture and lamp texture LOD bias
>
> o   Access to Vertex UV list
>
> o   Access to collision contact points
>
> o   Access to additional properties of material and texture in realtime
>
> o   ImageRender and ImageM

Re: [Bf-committers] Feature suggestion

[Mike Erwin]

rightclickselect.com is the best place to make feature requests. You'll get
good feedback from other users.

Mike Erwin
musician, naturalist, pixel pusher, hacker extraordinaire

On Wed, Nov 9, 2016 at 1:33 PM, Henrique Balduino Gonzaga <
henriqueb...@gmail.com> wrote:

> Hi. i am not sure if this is the right place to request a new feature, but
> the thing is that Blender could get a way to Snap intersecting "lines" just
> like Sketchup does.
>
> I´ll attach 3 images to clarify
>
> This is so easy to do on Sketchup, and i can´t find an easy way to do it in
> blender
>
> ___
> 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] temp-blender2.8 branch

[Mike Erwin]

There's a new temp-blender2.8 branch that diverges just before the bad
commit. We can work here until the main blender2.8 branch is repaired.
--Mike

On Thu, Oct 20, 2016 at 4:13 PM, Mike Erwin <significant@gmail.com>
wrote:

> Hi devs,
> I pushed a bad commit to blender2.8 so please avoid working there until
> this is resolved. Info about the commit and its revert are below. Even
> though the files are restored, their git blame history is kaput. We're
> considering resetting this branch to before the bad commit, but will leave
> that to our git experts.
>
> A thousand apologies for the inconvenience! Feel free to git blame me in
> person next week.
>
> Mike Erwin
> musician, naturalist, pixel (and bad commit) pusher, hacker extraordinaire
>
> -- Forwarded message --
> From: Mike Erwin <nore...@developer.blender.org>
> Date: Thu, Oct 20, 2016 at 3:16 PM
> Subject: [developer.blender.org] [Updated] rB7a0377e22ba8: OpenGL: draw
> lamp objects with new imm mode
> To: significant@gmail.com
>
>
> Mike Erwin (merwin) added a reverting commit: rBfb80477ee1b8: Revert
> "OpenGL: draw lamp objects with new imm mode".
>
> *BRANCHES*
> blender2.8
>
> *USERS*
> merwin (Author, Auditor)
>
> *COMMIT*
> https://developer.blender.org/rB7a0377e22ba8
>
>
___
Bf-committers mailing list
Bf-committers@blender.org
https://lists.blender.org/mailman/listinfo/bf-committers

[Bf-committers] Fwd: [developer.blender.org] [Updated] rB7a0377e22ba8: OpenGL: draw lamp objects with new imm mode

[Mike Erwin]

Hi devs,
I pushed a bad commit to blender2.8 so please avoid working there until
this is resolved. Info about the commit and its revert are below. Even
though the files are restored, their git blame history is kaput. We're
considering resetting this branch to before the bad commit, but will leave
that to our git experts.

A thousand apologies for the inconvenience! Feel free to git blame me in
person next week.

Mike Erwin
musician, naturalist, pixel (and bad commit) pusher, hacker extraordinaire

-- Forwarded message --
From: Mike Erwin <nore...@developer.blender.org>
Date: Thu, Oct 20, 2016 at 3:16 PM
Subject: [developer.blender.org] [Updated] rB7a0377e22ba8: OpenGL: draw
lamp objects with new imm mode
To: significant@gmail.com


Mike Erwin (merwin) added a reverting commit: rBfb80477ee1b8: Revert
"OpenGL: draw lamp objects with new imm mode".

*BRANCHES*
blender2.8

*USERS*
merwin (Author, Auditor)

*COMMIT*
https://developer.blender.org/rB7a0377e22ba8
___
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

[Mike Erwin]

Realized something today:
Increasing Blender 2.8's system requirements to Mac OS 10.9 lets us target
OpenGL 3.3 instead of 3.2! Mac OS 10.7 & 10.8 were the only reasons to stay
at 3.2. Hardware (GPU) requirements stay exactly the same.

What does 3.3 offer over 3.2? (* = exciting, fits into our plans)
* instanced arrays
* more efficient occlusion queries
* 10_10_10_2 vertex attributes (perfect for normals)
- 10_10_10_2 textures
- sampler objects

Complete list here:
https://www.opengl.org/wiki/History_of_OpenGL#OpenGL_3.3_.282010.29

The differences between 3.2 and 3.3 are not major, but setting our minimum
to 3.3 means we can guarantee these features will be there at runtime. No
need for extension checks or fallbacks.

Let's bump OpenGL to 3.3 and GLSL to #version 330.
Unless someone objects, I'll update the development docs & tasks & code to
reflect this.


Mike Erwin
musician, naturalist, pixel pusher, hacker extraordinaire

On Sat, Oct 8, 2016 at 10:34 AM, Jens Verwiebe <i...@jensverwiebe.de> wrote:
>
> Just FYI: Older macs can run 10.9/10/11 too jst with the bootloader trick.
>
> It warps 64 bit efi calls to 32bit efi in for example MacPro 1.1.
>
> I have exaclty done this on an 1.1 from 2006 running Yosemite ( 10.11 )
now.
>
> A demon assures consecutive updates do not ruin the bootloader exchange.
>
> Its very easy to use, see Mac Rumors forums.
>
> Jens
>
>
> Am 08.10.2016 um 16:02 schrieb Brecht Van Lommel:
> > Ok, let's do macOS 10.9 minimum then.
> >
> > I'm about ready to commit the libraries, if anyone likes to review see
> > here. Otherwise I'll just go ahead and commit things in the next few
> > days.
> > https://developer.blender.org/D2283
> >
> > On Wed, Oct 5, 2016 at 3:27 AM, Mike Erwin <significant@gmail.com>
wrote:
> >> Ok, I've had a chance to read your points and dig up the hardware
facts.
> >>
> >> I was concerned about the people that are stuck on 10.7 because their
> >> computer can't support 10.8, and didn't want us to leave them behind
> >> without a very good reason. Other people/projects/companies abandoning
it
> >> are not good reasons. But...
> >>
> >> The only Mac than could run Blender 2.8 but not OS 10.8 is the first
Mac
> >> Pro (Aug 2006 - Jan 2008), and only with an upgraded GPU. iMacs,
MacBooks
> >> Pro, everything else of that era is stuck with an old GPU and won't be
> >> supported anyway.
> >>
> >> So now we know exactly who we'll be disappointing! Mac Pro owners
(early
> >> adopter or second-hand) that don't have a newer Mac to run Blender on.
> >> Seems like a very small segment...
> >>
> >> Any newer Mac running 10.6.8 or later can upgrade to 10.9 free of
charge.
> >> Nobody is "stuck" on 10.8 by hardware. They might choose to run 10.8 or
> >> (god forbid) 10.7 but we have no obligation to support their choice.
> >>
> >> After gathering these facts I am also in favor of making Mac OS 10.9
the
> >> new minimum.
> >>
> >> Mike Erwin
> >> musician, naturalist, pixel pusher, hacker extraordinaire
> >>
> >> On Tue, Oct 4, 2016 at 5:29 PM, Martijn Berger <
martijn.ber...@gmail.com>
> >> wrote:
> >>
> >>> 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
>

Re: [Bf-committers] Making C++11 required for blender2.8 branch

[Mike Erwin]

Approach B then, no exceptions!

Not personally a fan of exceptions. Much prefer code that is designed with
few or no opportunities to fail at runtime. Document possible failure cases
and make it the caller's responsibility.

Is anybody here talking about converting all C and C++ code to C++11? I
thought we were just talking about the C++ parts & raising the library /
compiler requirements.

C is not "old" and C++ is not "new". Both languages are great. Both
languages also have a history with plenty of old techniques and habits that
are not helpful in modern software development.

I abandoned C++ for several years and chose C99 for my own projects, until
catching up with C++11 ~2 years ago. Between C++98 and C++11 obviously go
with 11. There's no reason to choose between C99 and C++11 though. Both are
modern languages with good compiler support across platforms.

Mike Erwin
musician, naturalist, pixel pusher, hacker extraordinaire

On Thu, Oct 6, 2016 at 9:57 AM, Ichthyostega <p...@ichthyostega.de> wrote:

> On 04.10.2016 11:15, Sergey Sharybin wrote:
> > I would like to propose to switch to C++11 in blender2.8 branch. Such a
> bump
> > was already discussed in the past, but i want to give it a real pus
> forward
> > now.
>
> On 04.10.2016 16:43, Sergey Sharybin wrote:
> > let's state the obvious: Blender's core is and will be a pure C.
>
>
>
> Hi Sergey,
>
> after reading this thread, it looks like the "elephant in the room"
> has not been mentioned. Regarding C++ this is the use of exceptions.
>
> Exceptions are one of the most beneficial features of modern C++
> BUT only if you go whole circle, and that means to use RAII *everywhere*.
> I have seen several times, that when you really go that path, the code size
> shrinks to about one third, the code becomes a thousand times more clean
> and
> readable and a lot of painstaking long-standing quality issues just resolve
> into thin air. This is a huge productivity boost, and in comparison, the
> good
> old C-style of resource management is just a huge waste of developer
> effort.
>
> BUT, as said, this only works if you're able to go that path totally.
>
> And I have seen numerous instances, where people switched half-heartedly
> and where not able to let go with the "good" old C habits. In that case,
> exceptions are a dangerous poison, and have the potential to kill a code
> base.
> You'll soon find every place littered with cascades of try-catch blocks and
> you'll be haunted by occasional random segfaults, which are near
> impossible to diagnose or fix.
>
>
> Thus I'd recommend to use either one of the following, and never mix
> things up.
>
> Approach-A:
>  - do *all* error handling with exceptions
>  - disallow the use of raw pointers. Wrap *every* resource into a RAII
> object
>  - disallow the use of try-catch blocks. In code review, request a proper
>justification for every single catch.
>
> Approach-B:
>  - disallow the use of exceptions entirely
>  - disallow the use of smart-pointers, since they are pointless now and
>might lure people into a programming style which can be dangerous and
>simply does not work with such a setup.
>
>
> Since we all know the existing code base of blender and our existing
> developer resources, the second approach looks more viable.
>
> -- Ichthyo
>
>
>
> ___
> 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] OS X has been renamed to macOS

[Mike Erwin]

I'll continue calling it Mac OS major.minor, so don't let me near the
manual :) It's a consequence of "switching" in the Mac OS 8.1 days. 8.6 is
still my favorite.

You mean files/folders in the blender source tree?

Mike Erwin
musician, naturalist, pixel pusher, hacker extraordinaire

On Tue, Oct 4, 2016 at 10:54 AM, Aaron Carlisle <carlisle@gmail.com>
wrote:

> Hi,
>
> In case anyone missed it apple decided to yet again changed their name for
> their OS.
> In the past, it has been called Mac OS (now used to reference old pre-2001
> versions)
> and also OS X which has recently been changed to macOS.
>
> What this means is that we should try to convert to using that name.
> This means changing the manual, blender.org and folders/files.
> The folders/files can wait and happen more slowly, however,
> today I will start renaming the other stuff.
>
> Thanks,
>
> Aaron Carlisle
> ___
> 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] Making C++11 required for blender2.8 branch

[Mike Erwin]

On Tue, Oct 4, 2016 at 5:15 AM, Sergey Sharybin 
wrote:
>
> == Windows ==
>
> MSVC 2013 already supports quite enough of C++11, so nothing will be
> changed here
>

Would prefer moving to MSVC 2015. It costs the same ($0), compiles faster,
and knows what constexpr means. Seems better in every way.


> == OSX ==
>
> OSX will need to be bumped to at least version 10.7, hopefully we can bring
> it up to 10.8. To my knowledge, OpenGL/viewport work will require such bump
> to 10.7 due to drivers.
>

Right, OpenGL progress requires 10.7 or newer. I already set this as the
minimum version in blender2.8 (checked at launch time) but have not done
much to take advantage of new features in the bumped OS version. Wrote more
about this in another email thread.


> ...

- Create a new folder in
> https://svn.blender.org/svnroot/bf-blender/trunk/lib/ for OSX C++11
> libraries. Not sure darwin-9 is really relevant name nowadays.
>

It's not. Mac OS 10.7 is Darwin 11 so we can target that at least. Or
higher if we decide. I say leave darwin-9 libs alone to keep Blender 2.7x
(and computer historians) happy. The new libs can be pure x86-64.
___
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

[Mike Erwin]

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 <significant@gmail.com>
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

Re: [Bf-committers] Making C++11 required for blender2.8 branch

[Mike Erwin]

On Tue, Oct 4, 2016 at 6:51 AM, Sergey Sharybin 
wrote:

> So for the allowed parts defeinitely goes:
>
> - Range based loops
> - Function bindings
> - In Cycles we use scoped lock, so should allow using that but with a
> restriction that Blender-side code should stick to BLI for the threading.
> - Audaspace uses shared/uniq pointers to my knowledge, so kinda also need
> to be allowed. But again: for Blender we need to stick to a strict
> ownership of data.
>

+1 for range-based loops. So much easier to write, read, and think about.

I've never used function bindings but you explained the need in your first
post.

+10 for proper ownership of data!


> Things i'm against:
>
> - Using shared/uniq pointers all over the place. Get the proper ownership
> model!
> - Using auto, it's not hard to watch your types and using auto makes code
> much more tricky to follow
> - Threading related things should be forbidden in Blender side. Use BLI for
> that. Single scheduler for the win!
> - TLS. It's usually not coming for free. Even worse, will be much less
> predictable across the compilers.
> - No garbage collection!
>

I like auto but am happy to use it in my own projects, not Blender.

But C++11 threading / async / concurrency is so nice! As long as BLI offers
similar perks... does it? I get the point about single scheduler.

Things i can be convinced for:
>
> - Initializer lists
> - Enum classes
>

I've found these incredibly helpful in other projects. Bordering on
essential. I would put constexpr and move semantics in the same
"essentials" bucket.


> - Static assert. I'm using it in Cycles, wouldn't mind if it's used more.
>

Also helpful but in fewer situations.

Why a limited subset? I'm guessing it's for sanity reasons and not compiler
support, as all major platforms have caught up. I worked with a person that
just discovered lambdas and was using them in every possible situation...
but if a particular C++11 feature is right for the job why not allow it?

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

Re: [Bf-committers] Calling all volunteers! Replace OpenGL immediatemode in Blender 2.8

[Mike Erwin]

On Tue, Oct 4, 2016 at 5:10 AM, Blendergit <blender...@gmail.com> wrote:
>
> What about python opengl wrapper (bgl)? any plan?
>

The plan is to provide a Python version of immediate mode, batched drawing,
matrix stacks, etc. similar to capabilities in the C API. Plus a way to
grab a plate / surface to draw on. I scheduled Python for December since
I'll be busy with Vulkan in November. Between now and then we can gather
requirements for the Python API.


> We have now some add-ons in official 2.78 release using opengl drawing,
> and sure they will need fixes to use new opengl 3.2.
>

Which add-ons, so I can see which parts of bgl they use?


Mike Erwin
musician, naturalist, pixel pusher, hacker extraordinaire
___
Bf-committers mailing list
Bf-committers@blender.org
https://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] blender2.8 not building under current Debian Testing (due to new libglew2.0 ?)

[Mike Erwin]

My mistake. Should be fixed now.

Mike Erwin
musician, naturalist, pixel pusher, hacker extraordinaire

On Sun, Oct 2, 2016 at 2:11 PM, Bastien Montagne <montagn...@wanadoo.fr>
wrote:

> Title says it pretty much all actually… Here is the error message:
>
> /home/i74700deb64/blender/__work__/src/source/blender/gpu/intern/gpu_extensions.c:
> In function ‘gpu_extensions_init’:
> /home/i74700deb64/blender/__work__/src/source/blender/gpu/intern/gpu_extensions.c:143:4:
> error: ‘ARB_draw_elements_base_vertex’ undeclared (first use in this
> function)
>BLI_assert(GLEW_VERSION_3_2 || (GLEW_VERSION_3_0 &&
> ARB_draw_elements_base_vertex));
>  ^
>
> Thanks,
> Bastien
>
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> https://lists.blender.org/mailman/listinfo/bf-committers
>
___
Bf-committers mailing list
Bf-committers@blender.org
https://lists.blender.org/mailman/listinfo/bf-committers

[Bf-committers] Calling all volunteers! Replace OpenGL immediate mode in Blender 2.8

[Mike Erwin]

Hi folks,
Subject line says it all. Read what needs to be done and how to get
involved:

https://docs.google.com/document/d/1zVB-MAvUhqckDF5Q59nkko9x8MVsRK1JuPmnhsPl9Bc/edit?usp=sharing

Mike Erwin
musician, naturalist, pixel pusher, hacker extraordinaire
___
Bf-committers mailing list
Bf-committers@blender.org
https://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Blender developers meeting, 2016 08 21

[Mike Erwin]

Ton Roosendaal <t...@blender.org> wrote:
> - There's a first testbuild available:
> http://download.blender.org/release/Blender2.78/
> Known issues with testbuild:
>   * OS X version seems to crash on start with Ndof. Not ready yet.

Just fixed the Mac NDOF crash:
https://developer.blender.org/rB28cf9cfd15ac

Recent 3D mouse drivers worked fine so this issue hid for months. For best
results use the latest 3Dconnexion driver. But latest is only supported on
Mac OS 10.9+. We go all the way back to Mac OS 10.6 so have to deal with
older driver versions.

Mike Erwin
musician, naturalist, pixel pusher, hacker extraordinaire
___
Bf-committers mailing list
Bf-committers@blender.org
https://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] New committer -- Ray Molenkamp!

[Mike Erwin]

Welcome bzztploink, glad to have you around for the Windows work! Now I can
bug you less about getting the latest Visual Studio to do this or that.

Mike Erwin
musician, naturalist, pixel pusher, hacker extraordinaire

On Mon, Jul 18, 2016 at 10:04 AM, Sergey Sharybin <sergey@gmail.com>
wrote:

> Hi,
>
> Please welcome Ray Molenkamp who is also known as LazyDodo in the tracker
> and bzztploink in IRC.
>
> He helped us a lot with Windows platform maintenance. All the further work
> he can now commit directly to Git and SVN.
>
> Welcome aboard!
>
> --
> 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] Link error for debug builds on MSVC 2015

[Mike Erwin]

Same here using the latest win64_vc14 from SVN.

As a local workaround, I'm copying release libs & renaming to what the
build script expects. Missing so far...

python35_d.lib
OpenImageIO_d.lib
OpenImageIO_Util_d.lib

IlmImf-2_2_d.lib   <--- there is an IlmImf-2_2_d_d.lib

IlmImf and IlmImfUtil just needed a simple rename, so I fixed those in SVN.

The build still fails after that due to mixing of runtimes (my
not-so-clever lib rename scheme). So please someone provide these missing
debug libs!

Mike Erwin
musician, naturalist, pixel pusher, hacker extraordinaire

On Sat, Jun 11, 2016 at 3:01 PM, Aaron Carlisle <carlisle@gmail.com>
wrote:

> Debug builds fails because of a python linking issue (missing file)
>
> LINK : fatal error LNK1104: cannot open file
>
> 'C:\Users\Aaron\BlenderDev\blender-git\blender\..\lib\win64_vc14\python\lib\python35_d.lib'
>
> I checked for that files and it is missing.
> ___
> 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] some Blender 2.8 system design docs

[Mike Erwin]

Here are some design docs I've been working on. They tend toward the
technical, but all are focused on improving the user and developer
experiences. Everything here is about interactive drawing. Mostly in the 3D
viewport but since OpenGL is used for all of Blender's UI much more than
the viewport is affected.


hardware support
<https://docs.google.com/document/d/1H2AjV-dZJuaxM24FChYoa9TY1doZEFavMHe_MyM9GqE/edit?usp=sharing>
What will Blender 2.8 run on?

drawing objects in the 3D view
<https://docs.google.com/document/d/1dDZVdIA41NqYnLcln9nTVAIYlB7oPuTGtncGLiK6uPs/edit?usp=sharing>
This is focused on 3D view interactions, how we can leverage people's
hardware to make their experience smooth & responsive. This doc covers the
"how"; "what" we are drawing with this system is the most interesting part,
and is covered briefly in the following *very rough* draft:
looking at objects
<https://docs.google.com/document/d/1vqohxI_WQKnHCFusQM98Cl8lmIWSz0a2qmrAGJ3nRoY/edit?usp=sharing>

GPU contexts
<https://docs.google.com/document/d/10xdiHIU-LHBBahJdSaMubERnfi4TB1Pb1F5-9gqwHZs/edit?usp=sharing>
The transition from "legacy" OpenGL 2.1 and how we can get from here to
"modern" GL 3.2 core profile. Establishing that base is a major goal for
Blender 2.8, and will open up so many cool techniques and streamline future
development.

Gawain
<https://docs.google.com/document/d/1rRaFqjRaElGZydeGqKTMq3N2_Ysyhii5MWmro9Q8Mr0/edit?usp=sharing>
A library to handle low-level GPU details, and give us useful machinery
that modern GL and Vulkan do not provide.


Please add your comments, suggestions, questions to these docs. I'm also
very interested to hear how other people's projects fit together. If
anything here aligns with your project, or clashes with it, respond here so
we can work it out.

You may have seen some of these docs before, but I'm always updating based
on feedback so please give them another scan.

My short term plan is to keep writing more words, responding to feedback,
and modifying those words until we agree on the general plan. Then we can
divide the plan into tasks and get back to coding full time! Which, at
least for me, is easier than writing :)

Mike Erwin
musician, naturalist, pixel pusher, hacker extraordinaire
___
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

[Mike Erwin]

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 <ideasma...@gmail.com>
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] Mac OS 10.7+ for Blender 2.8

[Mike Erwin]

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

Re: [Bf-committers] Blender 2.8 and OpenGL version

[Mike Erwin]

My impression is that mesh data will be the same, Cycles materials will be
the same, (new) real-time materials will be similar to Cycles materials to
the extent that similarity makes sense. Should not have to relearn the
tools or APIs when switching between real-time and offline rendering
approaches.

Blender Internal materials will be de-emphasized or dropped.

I don't know enough about particles to comment there.

I'm writing up some Viewport 2.8 ideas / docs / designs and will share
these very soon. Initially it will be "what merwin thinks", but should give
us something to talk about and eventually arrive at "what Blender folks
think".

Mike Erwin
musician, naturalist, pixel pusher, hacker extraordinaire

On Mon, Apr 18, 2016 at 11:54 PM, Owen Hogarth II <gurenc...@gmail.com>
wrote:

> HI guys
>
> I read this and the notes from a few of the more recent coder meetings and
> I had a few questions. I noticed that the new 3.2 renderer will break
> backwards compatibility with previous versions of the particle system.
>
> I have been doing some work with the node system in blender for a project,
> just basically accessing the nodes via the python script to export the mesh
> data, materials, etc
>
> With the talk of a totally new node system as well, will that mean a
> rewrite of the node's api, would that also break backwards compatibility as
> well if I was doing a lot of work with the current api?
>
> Best
> Owen
>
> On Mon, Apr 18, 2016 at 3:55 AM, Blendergit <blender...@gmail.com> wrote:
>
> > Yes, the ID is not related to OpenGL...and I like your idea. The object
> ID
> > could be:
> >
> > Object ID = Blender file GUID + Sequential Number
> >
> > This would be great...and of course a python function like
> > getObjectbyGUID(int).
> >
> > The change to 2.8 and all recode is the moment to think in this task. The
> > point is to get an immutable id.
> >
> > Antonio
> >
> > From: Piotr Arlukowicz
> > Sent: Sunday, April 17, 2016 6:20 PM
> > To: bf-blender developers
> > Subject: Re: [Bf-committers] Blender 2.8 and OpenGL version
> >
> > It is not necessarily connected to openGL, but having an unique random ID
> > stored in each Blend file upon creation/first-save will be also
> beneficial
> > and very welcomed. It could be even a date since epoch - anything - which
> > could help distinguish files copied and changed from files created from
> > scratch.
> >
> > pio
> >
> > ​Piotr
> > ​ Arlukowicz, BFCT​
> >
> > ​*YT: /user/piotao?feature=guide*
> > *FB:* */polskikursblendera* *TW:*
> > */piotao*
> > *Blender Network:* *https://www.blendernetwork.org/piotr-arlukowicz
> > <https://www.blendernetwork.org/piotr-arlukowicz>*
> > *Polski Kurs Blendera:* http://polskikursblendera.pl
> >
> >
> >
> >
> > 2016-04-17 12:10 GMT-04:00 Blendergit <blender...@gmail.com>:
> >
> > > Hi Mike,
> > >
> > > Thanks for the answers
> > >
> > > If we remove things like a simple draw_line and need VBO and shaders,
> any
> > > simple add-on gets complex. Maybe a library with primitives (line,
> > polygon,
> > > set color,...) could help a lot and create a standard API.
> > >
> > > And about matrix, are we going to use GLM?
> > >
> > > PS: Something really useful for Python (not related to OpenGL) is to
> have
> > > a IMMUTABLE object identifier.
> > >
> > > Add an identifier would be as simple as add 1 to any arbitrary number.
> > > It's not necessary keep a sequence...the problem is if you link
> > files...you
> > > can get conflicts, so the best idea could be use something like GUIDs.
> > >
> > > In database design, the unique identifier must keep equal all the time,
> > > and in Blender you must get objects by name, and this name can change,
> > so a
> > > lot of functions would be possible if we add a simple integer immutable
> > > value for each object.
> > >
> > > Maybe, now you have already this, but I have never seen this
> identifier.
> > >
> > > Antonio
> > >
> > > From: Mike Erwin
> > > Sent: Sunday, April 17, 2016 5:56 PM
> > > To: bf-blender developers
> > > Subject: Re: [Bf-committers] Blender 2.8 and OpenGL version
> > >
> > > Hi Antonio,
> > > Yes to 1) and 2) for sure. 3) I have not thought of deeply, but it
> seems
> > to
> > > follow from 1 and 2. The underlying context will be GL 3.2 core.
> > >
> > > Becau

Re: [Bf-committers] Blender 2.8 and OpenGL version

[Mike Erwin]

Hi Antonio,
Yes to 1) and 2) for sure. 3) I have not thought of deeply, but it seems to
follow from 1 and 2. The underlying context will be GL 3.2 core.

Because we'll be targeting OpenGL 3.2 core profile, lots of older but
convenient functions / techniques will not be available. Matrix stack,
batch rendering, etc. So we'll be replacing those as needed, coming up with
some (hopefully) nice abstractions that fit exactly what we need. What
would be helpful from a Python GL point of view?

Mike Erwin
musician, naturalist, pixel pusher, hacker extraordinaire

On Sun, Apr 17, 2016 at 11:30 AM, Blendergit <blender...@gmail.com> wrote:

> Hi,
>
> Only to be sure about Blender 2.8 and OpenGL version.
>
> 1) Blender 2.8 will be >= OpenGL 3.2.
> 2) All Blender code using old OpenGL version must be migrated (if the
> module is not removed or recoded).
> 3) All add-ons using OpenGL must be updated to >= OpenGL 3.2.
>
> I need to be sure about that because I have several popular add-ons using
> OpenGL and some ideas to improve grease pencil, so OpenGL 3.2provides a
> wide new range of tools.
>
> Thanks,
> Antonio Vazquez
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> https://lists.blender.org/mailman/listinfo/bf-committers
>
___
Bf-committers mailing list
Bf-committers@blender.org
https://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] GSoC: Morphing shaders

[Mike Erwin]

Hey Álvaro,
Your project sounds cool but I don't know how it would fit into Blender
from the brief description. Reminds me of things people are doing with
Animation Nodes. Or Shader Toy outside of Blender-land. Can someone here
who is into animation give more feedback?

Mike Erwin
musician, naturalist, pixel pusher, hacker extraordinaire

On Wed, Mar 23, 2016 at 3:12 PM, <alvaro.ri...@est.fib.upc.edu> wrote:

> Hello,
>
> My name is Álvaro Ricón. I am working on the Computer
> Engineering/Science final project, at the "Facultad d'Informàtica de
> Barcelona (Universitat Politècnica de Catalunya)".
>
> The project I'm conducting, with the supervision of the teacher Àlvar
> Vinacua, is entitled "GPU Morphing". The idea is to study and develop
> mesh-morphing algorithms which harnesses the power and parallelism of
> current graphic processors. As the main goal of my work I decide to
> develop a set of morphing shaders to perform this transform at
> runtime, without needing user interaction.
>
> The mesh morphing I'm trying to get is an automatic transition between
> any pair of meshes. In order to be able to do this I would use every
> kind of shaders I need, from vertex to tessellation, even compute
> ones. In fact, I'm currently developing compute shaders to implement
> the first step: spherical parameterization.
>
> I plan to finish my project at the end of May, and I would like to
> port all my work to Blender in the following months, at Google Summer
> of Code.
>
> It could be a fast-computed animation tool. The vey first idea was to
> use it on videogames (Blender Game Engine?), due to its potential
> realtime computation, saving memory of useless pre-calculated
> animations for any kind of transformations the game demands, which it
> would make possible to be a lot. What do you think about about it? It
> is feasible to present as a proposal for GSoC? If it isn't, can I just
> work on implementing more shader capabilities to Blender code?
>
> Hope you like the idea, and if you have any doubt do not hesitate to
> contact me. Thank you in advance. Best regards,
>
> Álvaro
> ___
> 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 32bit opengl driver problem

[Mike Erwin]

Ivam, try installing or updating the driver for your graphics card. Get it
from nVidia, AMD or Intel's website depending on what hardware you have.

Mike Erwin
musician, naturalist, pixel pusher, hacker extraordinaire

On Thu, Mar 24, 2016 at 3:24 PM, Ivam Pretti <ivamprett...@gmail.com> wrote:

> Hi Sergey, it says that there is no opengl 2.1 driver.
>
> Ivam Pretti
> PS: I dont know if is this way that answer in this mal list. sorry!
>
> Message: 11
> Date: Tue, 22 Mar 2016 16:00:35 -0300
> From: Ivam Pretti <ivamprett...@gmail.com>
> Subject: [Bf-committers] Windows 32bit opengl driver problem
> To: bf-committers@blender.org
> Message-ID:
> <
> cak1-cz9rsgir2bdd-ucgwcjfdvgsxmowb_xrrxkomikr+_l...@mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
> Hi there, is just me or there is something wrong with the 2.77 32bit zip
> version?
>
> It doesnt open, I tried in two diferent computers with two different
> versions of windows.
>
>
> --
>
> Message: 12
> Date: Wed, 23 Mar 2016 01:03:52 +0500
> From: Sergey Sharybin <sergey@gmail.com>
> Subject: Re: [Bf-committers] Windows 32bit opengl driver problem
> To: bf-blender developers <bf-committers@blender.org>
> Message-ID:
> <
> caertv25kac4dfbx2dwnauuqq324ze2rebukcqdijv51zbpn...@mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
> Hi,
>
> Do you have any error message displayed or printed to the console?
>
> On Wed, Mar 23, 2016 at 12:00 AM, Ivam Pretti <ivamprett...@gmail.com>
> wrote:
>
> > Hi there, is just me or there is something wrong with the 2.77 32bit zip
> > version?
> >
> > It doesnt open, I tried in two diferent computers with two different
> > versions of windows.
> > ___
> > 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] [GSoC] OpenGL 2D Drawing API

[Mike Erwin]

Have you had a chance to revise based on comments? Looking through
Blender's current UI drawing code will also help define where this new API
would help. That's what will be recoded, so see what drawing features it
needs.

Mike Erwin
musician, naturalist, pixel pusher, hacker extraordinaire

On Tue, Mar 22, 2016 at 10:14 PM, Chris Stankus <cdstan...@gmail.com> wrote:

> Hey,
>
> I've submitted a draft proposal and figured I should also share it on the
> mailing list for comment, it's available here:
>
>
> https://docs.google.com/document/d/1wd7e2I9wMVzP1m0d50uoi50ZlmzwEwfkIXQjpEc6Hwg/edit?usp=sharing
>
> On Sun, Mar 20, 2016 at 5:59 PM, Mike Erwin <significant@gmail.com>
> wrote:
>
>> Hi Chris, welcome!
>>
>> I wrote that caveat about prior work, but not the original project idea.
>> Really it's "ongoing work" which is mostly focused on 3D, and that 2D
>> should share some inner workings instead of totally diverging. One of the
>> technical goals for Blender 2.8 is a GPU API that the rest of our code can
>> call into, that is performant, correct and easier to use. You could
>> call this an abstraction layer but we're not trying to wrap all of OpenGL
>> -- just the parts we want to use.
>>
>> Anyone working on a clean 2D UI drawing API should be aware of how that
>> would fit into and affect the overall GPU API. Which is exactly what
>> mentors are for! Put together a proposal early then we can give more
>> specific feedback. You can revise it up to the deadline.
>>
>> Also you should check out non-Blender prior work such as Quartz, Skia,
>> NV_path_rendering. Our 2D API doesn't need to be as complete as those since
>> it's for our internal use.
>>
>> OpenGL 3.2 core profile is our target for future work, so focus on that.
>>
>> On Sunday, March 20, 2016, Chris Stankus <cdstan...@gmail.com> wrote:
>>
>>> Hello,
>>>
>>> I'm interested in working on the OpenGL 2D Drawing API for Google Summer
>>> of
>>> Code. I am proficient in C and have experience with OpenGL. The idea
>>> description mentions that prior work has been been done on abstracting
>>> OpenGL calls and I am interested in knowing what has been done prior so
>>> my
>>> proposal can be more concrete.
>>>
>>> Thanks,
>>> Chris Stankus
>>> ___
>>> Bf-committers mailing list
>>> Bf-committers@blender.org
>>> http://lists.blender.org/mailman/listinfo/bf-committers
>>>
>>
>>
>> --
>> Mike Erwin
>> musician, naturalist, pixel pusher, hacker extraordinaire
>>
>
>
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] [GSoC] OpenGL 2D Drawing API

[Mike Erwin]

Hi Chris, welcome!

I wrote that caveat about prior work, but not the original project idea.
Really it's "ongoing work" which is mostly focused on 3D, and that 2D
should share some inner workings instead of totally diverging. One of the
technical goals for Blender 2.8 is a GPU API that the rest of our code can
call into, that is performant, correct and easier to use. You could
call this an abstraction layer but we're not trying to wrap all of OpenGL
-- just the parts we want to use.

Anyone working on a clean 2D UI drawing API should be aware of how that
would fit into and affect the overall GPU API. Which is exactly what
mentors are for! Put together a proposal early then we can give more
specific feedback. You can revise it up to the deadline.

Also you should check out non-Blender prior work such as Quartz, Skia,
NV_path_rendering. Our 2D API doesn't need to be as complete as those since
it's for our internal use.

OpenGL 3.2 core profile is our target for future work, so focus on that.

On Sunday, March 20, 2016, Chris Stankus <cdstan...@gmail.com> wrote:

> Hello,
>
> I'm interested in working on the OpenGL 2D Drawing API for Google Summer of
> Code. I am proficient in C and have experience with OpenGL. The idea
> description mentions that prior work has been been done on abstracting
> OpenGL calls and I am interested in knowing what has been done prior so my
> proposal can be more concrete.
>
> Thanks,
> Chris Stankus
> ___
> Bf-committers mailing list
> Bf-committers@blender.org <javascript:;>
> http://lists.blender.org/mailman/listinfo/bf-committers
>


-- 
Mike Erwin
musician, naturalist, pixel pusher, hacker extraordinaire
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Google Summer of Code

[Mike Erwin]

Hey Campbell,

Was thinking mostly of the Viewport FX project branches for reference, plus
these more recent ones for continued development.

https://developer.blender.org/diffusion/B/history/temp_viewport_fx_merge/
https://developer.blender.org/diffusion/B/history/GPU_data_request/

Anyone working on a clean 2D UI drawing API should be aware of how that
would fit into and affect the overall GPU API. Which is exactly what
mentors are for! As described by Ton, this does sound like a good summer
project.

Also interested students should check out non-Blender prior work such as
Quartz, Skia, NV_path_rendering.

Mike Erwin
musician, naturalist, pixel pusher, hacker extraordinaire

On Sun, Mar 13, 2016 at 10:38 PM, Campbell Barton <ideasma...@gmail.com>
wrote:

> On Sat, Mar 12, 2016 at 6:52 AM, Mike Erwin <significant@gmail.com>
> wrote:
> > Hi Marcel,
> >
> > Here is some info about our plans for the 3D Viewport:
> >
> > http://wiki.blender.org/index.php/Dev:2.8/
> > http://wiki.blender.org/index.php/Dev:2.8/Viewport
> > http://wiki.blender.org/index.php/Dev:2.8/Source/OpenGL
> >
> > I don't actually think creating a new OpenGL drawing API from scratch is
> a
> > good GSoC project. There's a lot of previous and current work on that
> topic
> > by a number of developers. *Helping us refine and finish* what is already
> > started is a better approach. Blender 2.8 needs plenty of GL work in
> > general, so having an extra person for the summer is going to be great!
>
> Could you link to branches which are candidates for continued development?
> I've checked on some of the branches and its not clear which are only
> useful as a reference (because they're years old), and which we should
> base new developments on.
>
> > Mike Erwin
> > musician, naturalist, pixel pusher, hacker extraordinaire
> >
> > On Fri, Mar 11, 2016 at 7:36 AM, Marcel Santana Santos <m...@cin.ufpe.br
> >
> > wrote:
> >
> >> Hi everyone,
> >>
> >> My name is Marcel, I am a Brazilian student of Computer Engineering at
> >> Federal University of Pernambuco. Here I am a researcher at a group
> which
> >> deals with graphics computer, computer vision and related areas. I have
> >> worked on several projects of these areas in partnership with industry.
> >>
> >> I am very interested in participating of Google Summer of Code with the
> >> Blender project. And I am motivated by two topics: Create an OpenGL
> drawing
> >> API or Normal Editing Tools.
> >>
> >> Could some mentor talk about these topics or send a reference, so I can
> >> understand the specificities of each one and prepare a draft?
> >>
> >> Br,
> >>
> >> --
> >>
> >> Marcel Santana Santos
> >> Undergraduate of Computer Engineering 2013.2 - CIn/ UFPE
> >>
> >> Voxar Labs Researcher (http://www.cin.ufpe.br/~voxarlabs
> >> <http://www.cin.ufpe.br/~voxarlabs>)
> >> Teacher Assistant of Linear Algebra for Computing (
> www.cin.ufpe.br/~ma531)
> >> Teacher Assistant of Graphics Processing (www.cin.ufpe.br/~if680)
> >> ___
> >> 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
>
>
>
> --
> - 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] Google Summer of Code

[Mike Erwin]

Hi Marcel,

Here is some info about our plans for the 3D Viewport:

http://wiki.blender.org/index.php/Dev:2.8/
http://wiki.blender.org/index.php/Dev:2.8/Viewport
http://wiki.blender.org/index.php/Dev:2.8/Source/OpenGL

I don't actually think creating a new OpenGL drawing API from scratch is a
good GSoC project. There's a lot of previous and current work on that topic
by a number of developers. *Helping us refine and finish* what is already
started is a better approach. Blender 2.8 needs plenty of GL work in
general, so having an extra person for the summer is going to be great!

Mike Erwin
musician, naturalist, pixel pusher, hacker extraordinaire

On Fri, Mar 11, 2016 at 7:36 AM, Marcel Santana Santos <m...@cin.ufpe.br>
wrote:

> Hi everyone,
>
> My name is Marcel, I am a Brazilian student of Computer Engineering at
> Federal University of Pernambuco. Here I am a researcher at a group which
> deals with graphics computer, computer vision and related areas. I have
> worked on several projects of these areas in partnership with industry.
>
> I am very interested in participating of Google Summer of Code with the
> Blender project. And I am motivated by two topics: Create an OpenGL drawing
> API or Normal Editing Tools.
>
> Could some mentor talk about these topics or send a reference, so I can
> understand the specificities of each one and prepare a draft?
>
> Br,
>
> --
>
> Marcel Santana Santos
> Undergraduate of Computer Engineering 2013.2 - CIn/ UFPE
>
> Voxar Labs Researcher (http://www.cin.ufpe.br/~voxarlabs
> <http://www.cin.ufpe.br/~voxarlabs>)
> Teacher Assistant of Linear Algebra for Computing (www.cin.ufpe.br/~ma531)
> Teacher Assistant of Graphics Processing (www.cin.ufpe.br/~if680)
> ___
> 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] Participating in GSOC

[Mike Erwin]

Hi Daniel,

Welcome!

It depends on what model laptop you have. Anything Intel HD 4000 or newer
is capable for Blender work, same is true for any AMD APU.

For example on the 2012 MacBook Pro switching to the Intel HD 4000 gives
about half the performance of the built-in nVidia GPU, but nothing is
broken or blocked.

Mike Erwin
musician, naturalist, pixel pusher, hacker extraordinaire

On Fri, Mar 4, 2016 at 12:35 PM, Daniel McNeela <daniel.mcne...@gmail.com>
wrote:

> Hi Everyone,
>
> My name is Daniel McNeela, and I'm a rising senior at the University of
> California, Berkeley studying applied mathematics and computer science. I
> used Blender frequently in middle school and high school to learn about 3d
> graphics and animation, so I'm excited to learn more about its development.
>
> I have a couple of questions about contributing for anyone who's
> knowledgeable about the project.
>
> 1. I don't currently have access to a desktop machine, and I use my laptop
> for the majority of my coding work. As such, I don't have a dedicated
> graphics card, and I don't know if this will lead to issues with actually
> running Blender for testing purposes. Would this likely be a great
> impediment to contributing?
>
> 2. For projects, would you suggest I stick to the ones outlined on the
> project ideas page, or are proposals for other ideas welcomed as well?
>
> Thanks for your help,
>
> Daniel
> ___
> 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] NULL-like bgl.Buffer and related

[Mike Erwin]

I'm not sure about the Python interface, but a zero offset for
glVertexAttribPointer means "from the beginning", not "no offset". So None
does not make sense here. Offset could be made 0 by default since that's a
pretty common case.

Since Blender uses VBOs mostly and is moving more toward that direction
this should be an unsigned integer offset in the API. The old
interpretation of a main-memory pointer will be going away.

Mike Erwin
musician, naturalist, pixel pusher, hacker extraordinaire

On Mon, Feb 29, 2016 at 2:26 AM, Quentin Wenger <ma...@protonmail.ch> wrote:

> Hi,
>
> [not sure this best belongs to bf-committers or bf-python...]
>
> I am currently developping an addon making heavy use of OpenGL/bgl (and
> BTW gpu.offscreen, which seems to do exactly what I was lacking for in
> terms of Framebuffers... thanks Dalai & reviewers!).
>
> Still there is one only thing that seems not to work for me:
> bgl.glVertexAttribPointer. Reason for that is, I would use (void*)0 (or
> NULL maybe) as the last parameter in equivalent OpenGL/C code, that last
> parameter representing an offset in the buffer, which seems not to be
> possible currently with bgl.Buffer.
>
> So I thought I'd need to implement a kind of special bgl.Buffer (maybe
> stored as a variable in bgl or even, static in bgl.Buffer) internally
> mapping to (void*)0 or NULL. But then I realized it could sometimes be
> helpful to specify other offsets, say (void*)4, etc.
>
> At this point I decided it would be better to ask more people before
> diving in the code. ;-)
>
> So, what do you think about that? Do you know about a workaround in bgl?
> Is the implementation of special bgl.Buffer a possibility?
>
> Note that I do have a temporary workaround -
> OpenGL.GL.glVertexAttribPointer(..., ctypes.c_void_p(None)) in the middle
> of bgl code - but that's not very nice, uses external package, etc.
> Moreover, without such as special bgl.Buffer or any similar alternative the
> function bgl.glVertexAttribPointer simply is mostly useless.
>
> Thanks,
> Quentin
> ___
> 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] New glLineWidth Policy

[Mike Erwin]

Brecht Van Lommel <brechtvanlom...@pandora.be> wrote:

> Mike Erwin <significant@gmail.com> wrote:
> > For 2.77 what is left to fix? If it's a small set I say fix those and
> keep
> > the change. (but of course I would say that) It gets us closer to clean
> GL
> > usage.
>
> But it also breaks addon backwards compatibility, which I don't think
> is intentional for 2.77?
>

Of course not :)  At this point this is the big unknown, since it's
impossible to review all addon code. Addons must go through the Python
interface right? Just thinking there might be a way to guarantee initial
width of 1.0 for addons only.

Up to now there have been multiple fixes based on bug reports from
> users. If we rely on just bug reports then there's likely more corner
> cases that are still broken. If we keep these commits then I think
> someone should go over all GL_LINE drawing and verify that it's
> properly setting the line widths.


Sign me up for that. A second or third pair of eyes would help too.

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

Re: [Bf-committers] New glLineWidth Policy

[Mike Erwin]

For 2.77 what is left to fix? If it's a small set I say fix those and keep
the change. (but of course I would say that) It gets us closer to clean GL
usage.


I agree that plenty of state should have a default value. Blending
(disabled), line smooth (disabled), line stipple (disabled) etc. And
polygon mode (filled, not outline)! Because these are only changed in
special cases.

Point size and line width are specified pretty much every time you want to
draw, so I think maintaining a default value is counterproductive there.
Really it's a fuzzy boundary (a wide antialiased line?) separating what
should or shouldn't have a default value.

The GPU_data_request branch has a declarative state-tied-to-drawing API
that was a joy to use. Basically you start with a LineDrawState object
which starts with defaults, change what you want, then pass it to the draw
command. That style API is cleaner in C++ but the C version implemented
worked fine. You know exactly what will be drawn and can't mess it up,
totally independent of what was drawn before. It minimized calls to GL &
worked for nested drawing too.


On an admin / phabricator note, I've never gotten emails about the concern
raised or new posts on that concern. Severin told me about it on IRC. Is
there some button or setting I overlooked?

Mike Erwin
musician, naturalist, pixel pusher, hacker extraordinaire

On Thu, Feb 18, 2016 at 4:34 PM, Brecht Van Lommel <
brechtvanlom...@pandora.be> wrote:

> I replied to the commit, but basically my opinion is that if we can't
> be reasonably sure that we can fix all issues before 2.77, then we
> should just revert these commits now.
>
> I think explicitly specifying the line width is fine, but then let's
> design a line drawing API such that you can't possibly make the
> mistake of forgetting to specify the line width, by making it a
> parameter to the line drawing API function(s). As long as we are
> refactoring OpenGL code I prefer code to follow the convention that
> OpenGL state should always revert to the default state as specified in
> GPU_state_init(), specifically because it's difficult to understand
> and track all the hidden assumptions in the existing code. Even if we
> fix all cases in Blender we might break addons that do custom OpenGL
> drawing.
>
> I think that's a general principle we should follow, not just for line
> widths but for most OpenGL state. Think about line stipple, line
> smooth, do we also want to disable those everywhere before drawing
> lines? We are already assuming OpenGL is in the default state for most
> things, I don't think line width should be the exception.
>
>
> On Thu, Feb 18, 2016 at 9:44 PM, Campbell Barton <ideasma...@gmail.com>
> wrote:
> > Hi, think its OK to keep this policy change.
> >
> > Even though its been a bit of a hassle to clear up all the
> > line-width's the past few weeks.
> > Before this - we would run into occasional bugs where the state wasn't
> > properly reset.
> > Finding out which function left the state unset could be quite
> > involved ... especially with a lot of nested calls in the drawing
> > code, where its not always clear at what point the state should be
> > reset.
> >
> > Even though the number of calls to glLineWidth may be higher,
> > (since previous code assumed width of 1 everywhere),
> > the driver *should* check if the width is the same as the previous,
> > and exit-early
> > (verified with Mesa and NVidia's drivers).
> >
> > On Fri, Feb 19, 2016 at 6:32 AM, Mike Erwin <significant@gmail.com>
> wrote:
> >> Hey Julian, thanks for bringing this up for discussion. The intentions
> of
> >> that recent change were twofold, and you summed up the difference
> between
> >> the new and old policy perfectly.
> >>
> >> First intention was to reduce GL state changes -- which you say might
> not
> >> be reduced. And more importantly to make each bit of line-drawing code
> >> responsible for its own line width. To me it's way more paranoid for
> each
> >> site to reset it back to 1.0 just in case some other unrelated draw call
> >> forgets to set its own line width. Specifying state at the draw call
> site
> >> is also more Vulkan-friendly, whenever we get to that.
> >>
> >> I did a similar change set with point size a week or two before and it
> >> seemed to work really well. Lines are drawn in many more places (and
> more
> >> ways) so some things were not caught and updated to the new policy.
> >>
> >> So yes, let's review whether or not the new policy is a good one.
> Naturally
> >> I'm on Team Yes!
> >>
> >> Mike Erwin
> >> musicia

Re: [Bf-committers] New glLineWidth Policy

[Mike Erwin]

Hey Julian, thanks for bringing this up for discussion. The intentions of
that recent change were twofold, and you summed up the difference between
the new and old policy perfectly.

First intention was to reduce GL state changes -- which you say might not
be reduced. And more importantly to make each bit of line-drawing code
responsible for its own line width. To me it's way more paranoid for each
site to reset it back to 1.0 just in case some other unrelated draw call
forgets to set its own line width. Specifying state at the draw call site
is also more Vulkan-friendly, whenever we get to that.

I did a similar change set with point size a week or two before and it
seemed to work really well. Lines are drawn in many more places (and more
ways) so some things were not caught and updated to the new policy.

So yes, let's review whether or not the new policy is a good one. Naturally
I'm on Team Yes!

Mike Erwin
musician, naturalist, pixel pusher, hacker extraordinaire

On Thu, Feb 18, 2016 at 1:53 PM, Julian Eisel <eiseljul...@gmail.com> wrote:

> Hey there,
>
> We talked about this in IRC before, but I'd like to get a final
> conclusion on this topic and give other devs the chance to raise their
> voice.
>
> In a recent commit [1] we changed our policy for glLineWidth calls.
> Previously, convention was to always reset to default (1.0) after
> drawing with non-default width. New convention is to always ensure
> line width is set to correct value before drawing lines (so there
> basically is no default state anymore).
>
> The changed policy caused quite a few regressions, which we can fix of
> course - issue is finding them. The main reasons I'm not sure about
> this however, are in the following:
> Although it might look like state changes were reduced, I'm afraid
> we'll end up with more state changes than before, since we do much
> more line draw calls than glLineWidth calls to change to non-default
> (>400 vs <100). Campbell made the point that we shouldn't need to be
> too paranoid, adding glLineWidth all over, but I guess a fair amount
> of paranoia would actually be needed since it's often hard to predict
> all possible previous line-width states. And not to forget, when
> adding code with changed line-width you also had to check possible
> following draw calls.
> Another point Campbell made, is that old policy would be hard to
> follow for nested draw calls. Although I agree it's a valid point, we
> managed to do it all the time, so it's obviously doable (Sergey added
> we should avoid nested draw calls anyway).
>
> So IMHO, this is too much hassle, and output isn't guaranteed to be worth
> it...
> All that said, I could live with the new convention of course, but
> let's review it first again :)
>
> [1] https://developer.blender.org/rBSe25ba162c0b
>
> Cheers,
> - Julian -
> ___
> 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] glTF Exporter

[Mike Erwin]

Are there enough missing parts to make a good GSoC project?

Mike Erwin
musician, naturalist, pixel pusher, hacker extraordinaire

On Sat, Feb 13, 2016 at 11:22 PM, Campbell Barton <ideasma...@gmail.com>
wrote:

> On Sun, Feb 14, 2016 at 7:56 AM, Daniel Stokes <kupom...@gmail.com> wrote:
> > Greetings bf-committers,
> >
> > Since there was some interested in glTF support in Blender, I have moved
> > the glTF exporting functionality out of the Real Time Engine addon, and
> > made it available as its own addon. Since the exporting was meant for
> > serving a specific purpose, it does not have any options other than a
> > filepath. It is also missing support for animations and missing some
> > options around textures and materials. However, for anyone looking to
> play
> > around with glTF, this could be useful. The output of the exporter passes
> > the validator supplied by Khronos.
> >
> > The link:
> > https://github.com/Kupoman/io_scene_gltf
> >
> > I would like to mention that Mitchell Stokes did most of the initial
> > implementation of the glTF exporting.
> >
> > Cheers,
> > Daniel Stokes
>
> Hi Daniel, good to see this get its own repo, but found the add-on is
> split between 2 locations.
> This means forking to make a few edits is quite a lot more complicated
> (seems like both repos need to be forked, then manually update the
> submodule).
>
> Also for git history, bisecting... etc, splitting history for a 2-file
> Python module between 2 repos seems more trouble then its worth.
>
> Any chance this could be made a single repo?
>
> --
> - 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] The future of FBX and/or other formats in Blender

[Mike Erwin]

Timur Ariman <timur_ari...@yahoo.de> wrote:
>
> After or if possible during integration of the fileformat into Blender,
> adding big game engine developers for implementing the same interchange
> format
> should be a given!
>

Keith Boshoff <wahoo...@gmail.com> wrote:

> As much as using a proper, open interchange format would be fantastic, it's
> just about useless if no other apps actually use the format.
>
> I'm speaking from a Unity perspective and the chances of them including
> other mesh formats in the near future are slim to none (Though I'm still
> going to nag them about it). I'm pretty sure the same is true for Unreal,
> Crytek, Lumberyard and definitely Stingray.
>

Why assume that other project's developers have no interest in open
formats? I'll talk to some Epic folks tomorrow and see how interested they
are in accepting glTF data (alongside FBX). Maybe start simple with
StaticMesh import and build from there.

To get other people on board, what are the benefits? I'll focus on glTF
since I know nothing about the other formats mentioned:
- not controlled by a 3rd party
- simpler format / easier to implement correctly
- robust export from Blender (in the near future)
- what else?

Also keep in mind glTF is an export format, not an interchange format like
Collada & FBX. It's ideal for moving *finished* 3D work from Blender to a
game engine. It will be a good alternative to FBX for many tasks.

Mike Erwin
musician, naturalist, pixel pusher, hacker extraordinaire
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Request for Collada Importers/Exporters

[Mike Erwin]

Juan Linietsky <redu...@gmail.com> wrote:

> Julian, I'm only proposing a way to solve the following problems:
>
> 1) Not having an alternative to FBX
> 2) Not having a fully working Collada exporter that supports the same as
> the FBX. You can test mine any time, try exporting a complex scene from
> Blender with skeletal animations, blend shapes, multiple actions, etc.
> 3) Not having a fully working Collada importer. You can test mine any time
> and see how it imports Blender, OpenCollada, XSI, Lightwave, etc. with all
> the above mentioned features.
> 4) Not having the huge bloat that represents using OpenCollada in Blender.
>
>
I no longer use Collada but am very excited about solutions to 1 and 4
above. They benefit all Blenderheads. For those who *do* use Collada, we
might as well get it right (the 2 & 3 part).

Mike Erwin
musician, naturalist, pixel pusher, hacker extraordinaire
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Blender developers meeting notes - February 9, 2016

[Mike Erwin]

Missed the first few minutes of today's meeting, wanted to clarify point 1).

The migration to OpenGL 2.1 is in some sense complete. Lots of code was
updated to reflect the new 2.1 baseline. There are fewer checks for
functionality & fewer workarounds which should result in tiny speedups
throughout. And (my favorite) ARB shaders for smoke were replaced by a
*better* implementation in GLSL.

Not everything is GLSL and VBOs yet, but those are not required for GL 2.1
compliance. Still plenty to do for 2.78 :)

Mike Erwin
musician, naturalist, pixel pusher, hacker extraordinaire

On Tue, Feb 9, 2016 at 1:37 PM, Jonathan Williamson <jonat...@cgcookie.com>
wrote:

> Hey all,
>
> Here are the notes from today's meeting in irc.freenode.net <
> http://irc.freenode.net/> #blendercoders
>
>
> 1) Targets for 2.77
>
> - Agreed to move to BCon4; bug fix commits only now.
> - OpenGL migration from 1.4 to 2.1 is only unclear task left for 2.77
>
>
> 2) Other projects
>
> - Regarding the 2.8 development branch, suggestions made to wait until
> point of no return, only creating it once we really need it
>
> - Bastian discusses future of FBX in Blender via mailing list:
> http://lists.blender.org/pipermail/bf-gamedev/2016-February/000583.html
>
> - Suggestions made for adding a Dev Fund banner to the Windows Installer,
> helping to bring more focus to the dev fund. JuicyFruit will
>
> - Discussions around this years GSOC came up, touching on what went wrong
> last year and how to improve the application for this year. The main point
> from Google was a better defined Ideas page
>
> - Nothing to add for 2.8 yet, planning proposals need to be written still
> for code.blender.org
>
> - Ton asks how everyone likes the new meeting schedule. Most people like
> it, although it’s a bit confusing, and some miss the weekly Sunday
> meetings. However, it's more accessible for non-Euro devs.
>
>
> Cheers,
> Jonathan
> ___
> 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

[Mike Erwin]

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

Re: [Bf-committers] Windows XP support

[Mike Erwin]

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

Re: [Bf-committers] Next dev meeting in about 13h from now

[Mike Erwin]

Thanks, Aaron! But that clock says the meeting is 6 PM 27th Jan Wednesday
when it's actually 6pm today the 26th. (EST time zone). Unless I'm crazy,
which I could possibly be.

Mike Erwin
musician, naturalist, pixel pusher, hacker extraordinaire

On Tue, Jan 26, 2016 at 10:56 AM, Aaron Carlisle <carlisle.aaro...@gmail.com
> wrote:

> The easiest way to see what time the meeting,
> is by going to https://blendercoders.xyz/
>
> On Tue, Jan 26, 2016 at 4:44 AM, Ton Roosendaal <t...@blender.org> wrote:
>
> > Hi all,
> >
> > Check your clocks! In roughly 13 hours it is 10 AM in Sydney, and 27th of
> > January.
> > That means afternoon for the Americans on the 26th of January.
> >
> > Just ask google (if logged in) "What time is 10 AM Sydney here"
> >
> > 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] enable 3D mouse for official builds

[Mike Erwin]

Hi devs,
During the switch to CMake, 3D mouse support was disabled by default on Mac
& Linux. Just want to make sure this is enabled for the 2.77 release.

Windows -- no dependencies
Mac -- no dependencies
Linux -- requires libspnav to build

I'm not very familiar with the install-deps script, which is why I'm
bringing this up instead of just fixing it!

Mike Erwin
musician, naturalist, pixel pusher, hacker extraordinaire
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] GLSL for Mac

[Mike Erwin]

Hi Marcelo,

GLSL 1.2 (#version 120) correlates to OpenGL 2.1, the lowest version we
support and the *highest* we support on Mac until the next version of
Blender.

I thought EXT_gpu_shader4 would let you use uint but lemme check...

https://www.opengl.org/registry/specs/EXT/gpu_shader4.txt

* Full signed integer and unsigned integer support in the OpenGL
  Shading Language:

  - Integers are defined as 32 bit values using two's complement.
  - Unsigned integers and vectors thereof are added.


Which to me means it should work! Maybe it doesn't have the uint keword
yet. Try something like this in the shader:

#if __VERSION__ < 130
#define uint unsigned int
#endif

Mike Erwin
musician, naturalist, pixel pusher, hacker extraordinaire

On Tue, Jan 19, 2016 at 2:14 PM, CGLabs <cgl...@mail.com> wrote:

> Hello,
>
> I am trying to use a modified “gpu_shader_material.glsl” which has
> variables defined as uint types.
> The GLSL version that Blender is picking up is 120:
>
> #version 120
> #extension GL_ARB_draw_instanced: enable
> #extension GL_EXT_gpu_shader4: enable
> #define GPU_NVIDIA
> …
> …
> …
>
> I am getting syntax error for uint when the OpenGL runtime complies the
> dynamic source code.
> I am assuming that 120 correlates to OpenGL 1.20 and it seams that uint is
> not supported.
>
> Even more odd is that is I replace all uint by unsigned int it GLGS
> compiler is “happy” and works (despite the fact that OpenGL 1.20 states
> unsigned as reserved word).
>
> Does anyone know what is going on with GLSL’s  uint ?
>
> My machine: MacBook PRO with NVIDIA GeForce GT 750M 2048 MB
>
> Regards,
> Marcelo Varanda
>
>
> ___
> 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] Leftover todos, derivedmesh refactoring + ideas on viewport, pie menus

[Mike Erwin]

Thanks for the brain dump, Psy-fi! Hope you like what we do with this
between now & your eventual return.

Mike Erwin
musician, naturalist, pixel pusher, hacker extraordinaire

On Sat, Jan 9, 2016 at 12:37 PM, Knapp <magick.c...@gmail.com> wrote:

> I love pie menus! I will miss your work! Sure hope someone else takes it
> up.
> Best,
> Douglas
>
> On Sat, Jan 9, 2016 at 4:07 PM, Antony Riakiotakis <kal...@gmail.com>
> wrote:
>
> > Hi all,
> >
> > I will not be coding anymore for the near and mid-term for blender so I
> > will post the status for a few work in progress things that I had been
> > doing and post a few ideas I had on the viewport in case others might
> want
> > to take them up. You can see it as a proposal if you like.
> > To avoid polluting everyone's emails with a wall of text, I've added a
> wiki
> > page:
> >
> > http://wiki.blender.org/index.php/User:Psy-Fi/TODO
> >
> > That's all, have fun everyone!
> > ___
> > Bf-committers mailing list
> > Bf-committers@blender.org
> > http://lists.blender.org/mailman/listinfo/bf-committers
> >
>
>
>
> --
> Douglas E Knapp, MSAOM, LAc.
> ___
> 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 - new meeting schedule for 2016

[Mike Erwin]

Thanks, Nick! Added that to my main calendar. So we're not doing Sundays
anymore? The January meetings fall on a Saturday, Monday, Tuesday here
(Eastern US).

And the first meeting should wrap up just in time for day 2 of:
http://synchrony.untergrund.net/timetable/

Mike Erwin
musician, naturalist, pixel pusher, hacker extraordinaire

On Wed, Dec 30, 2015 at 3:13 PM, Nicholas Rishel <rishel.n...@gmail.com>
wrote:

> Since the new schedule isn't as predictable as weekly on a Sunday I spun up
> a quick Google Calendar
> <
> https://calendar.google.com/calendar/embed?src=cqqj4ohm2oaeceenhmghbf28t8%40group.calendar.google.com=America/New_York
> >
>
>
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

[Bf-committers] Visual C++ without Visual Studio

[Mike Erwin]

FYI Microsoft is going to start releasing build tools without bundling the
entire Visual Studio, like they used to do with the Windows 7 SDK. Now that
Visual Studio Community is free it won't make a huge difference. But for
people that just want to build from source (or for build bots) this is good
news!

http://blogs.msdn.com/b/vcblog/archive/2015/11/02/announcing-visual-c-build-tools-2015-standalone-c-tools-for-build-environments.aspx

It's pre-release now but should be usable by the time we transition to MSVC
2015.

Mike Erwin
musician, naturalist, pixel pusher, hacker extraordinaire
___
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

[Mike Erwin]

On Sun, Nov 29, 2015 at 3:54 PM, Brecht Van Lommel <
brechtvanlom...@pandora.be> wrote:

> Here is the OpenGL wiki page:
> http://wiki.blender.org/index.php/Dev:2.8/Source/OpenGL


Excellent write-up. I added some sections and will add more after a good
night's sleep and the "day job" is over.

Mike Erwin
musician, naturalist, pixel pusher, hacker extraordinaire
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Updated requirements for Blender

[Mike Erwin]

Hi Thomas,
For the Mac requirements OS 10.6 should* work now and for the rest of the
Blender 2.7x line. Blender 2.8 will require OS 10.7 but let's hope those
people have upgraded to 10.8 or 10.9 by now, for their sake.

-- Mike

*should means GHOST doesn't use newer APIs last time I checked.
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

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

[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 <kal...@gmail.com>
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 :).
>
> On 21/11/2015, Brecht Van Lommel <brechtvanlom...@pandora.be> wrote:
> > As I understand it, with OpenGL 2.1  the minimum requirements would be
> > effectively:
> >
> > * NVidia Geforce FX, Gerforce 6 and newer (released in 2003)
> > * AMD Radeon R600+, Radeon HD, and newer (released in 2006)
> > * Intel HD graphics or newer (released in 2010), some older cards
> > might still work on OS X and Linux
> >
> > Mainly users with older Intel GMA graphics would be affected. That
> > sounds reasonable to me but we are raising the hardware bar for
> > Blender 2.77 then, right?
> >
> > I totally support doing this in master. Doing OpenGL refactoring in
> > big branches hasn't worked well in the past, better to do it
> > incrementally. I can help with some refactoring and code review.
> >
> > On Sat, Nov 21, 2015 at 8:44 AM, Antony Riakiotakis <kal...@gmail.com>
> > wrote:
> >> You have my sword. And my axe. And my bow.
> >> I could trickle some free time on this, though not terribly much
> >> unfortunately.
> >>
> >> I definitely vote to do this on master/or current full dev branch (2.8
> >> branch?) when that changes. The previous approach of dumping chunks of
> >> code in a big branch that will code-rot as soon as time or energy
> >> dries out just does not work for such a big project in my opinion. We
> >> need an approach that will let us work on this incrementally.
> >>
> >> We should communicate well, with screams, on the street to
> >> unsuspecting pedestrians and on the net to unsuspecting surfers, posts
> >> on blender.org, in the manual and with ugly message boxes with bright
> >> flashing red letters (OK, I admit that might be pushing it a little
> >> bit), especially for the windows and mac people, that system
> >> requirements are now raised to 2.1, and add the relevant checks and
> >> warnings in GHOST to ensure that people who try to use blender without
> >> it, cannot do so anymore. Current approach on Windows is just spawning
> >> a warning messagebox. We can leave that in but also quit blender in
> >> case it does not meet our requirements, and also expand to a similar
> >> approach for other OSs.
> >>
> >> On 21/11/2015, Mike Erwin <significant@gmail.com> wrote:
> >>> Hi devs,
> >>>
> >>> I was responding to something in bf-viewport but could use a wider set
> >>> of
> >>> people to either agree or put a stop to this madness before it's too
> >>> late.
> >>> :)
> >>>
> >>> I'd like to start basic GL cleanup in master ASAP. By this I mean set
> GL
> >>> 2.1 as a baseline and convert all code that uses obsolete extensions to
> >>> the
> >>> functions/enums provided by GL itself. Much of this is simply deleting
> >>> ARB
> >>> or EXT, and removing checks for GL features that are guaranteed in 2.1.
> >>> No
> >>> new features, no major rewriting, just get the code up to spec and
> ready
> >>> to
> >>> branch for the bigger GL 3.2 upgrade.
> >>>
> >>> Staged migration of OpenGL:
> >>> now --> GL 2.1 (all platforms, soon)
> >>> --> 3.2 compatibility profile (Windows & Linux)
> >>> --> 3.2 core profile (all platforms, in tim

[Bf-committers] proposal: OpenGL cleanup in master

[Mike Erwin]

Hi devs,

I was responding to something in bf-viewport but could use a wider set of
people to either agree or put a stop to this madness before it's too late.
:)

I'd like to start basic GL cleanup in master ASAP. By this I mean set GL
2.1 as a baseline and convert all code that uses obsolete extensions to the
functions/enums provided by GL itself. Much of this is simply deleting ARB
or EXT, and removing checks for GL features that are guaranteed in 2.1. No
new features, no major rewriting, just get the code up to spec and ready to
branch for the bigger GL 3.2 upgrade.

Staged migration of OpenGL:
now --> GL 2.1 (all platforms, soon)
--> 3.2 compatibility profile (Windows & Linux)
--> 3.2 core profile (all platforms, in time for Blender 2.8)

That final transition will be the most work. The first transition can be
done NOW and doesn't involve any design really -- just a plan of what to
remove/convert. Dropping support for GL 1.4, 1.5 and 2.0 in one swoop will
let us clean up a lot of legacy crap without raising the hardware bar.

Is anyone opposed to this? Anyone eager to help?

Mike Erwin
musician, naturalist, pixel pusher, hacker extraordinaire
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Opensubdiv and catmull-clark again

[Mike Erwin]

Hi guys,
I'm actively working on OpenSubdiv, especially getting it running on more
systems (Intel gfx on Windows, Mac). GLSL compute works on the latest
version of OSD (official Blender release doesn't use this yet). Similar
performance to Transform Feedback. The other problems you mention... yep
those are still problems.

Thanks for pointing out #2 -- I knew it looked odd but didn't make the
connection to low-poly normals. Can you give a link to the bug tracker?

From my understanding, OpenSubdiv will become *the* subsurf implementation
in Blender, and the old system will go away. But first we need to fix these
problems.

Mike Erwin
musician, naturalist, pixel pusher, hacker extraordinaire

On Thu, Nov 5, 2015 at 7:52 AM, Yury Baranov <cucumbe...@gmail.com> wrote:

> Opensubdiv is unusable ATM in fact. Problems are:
> 1. Unable to apply Subsurf with OSD enabled. Result is identical to Subsurf
> without OSD check.
> 2. Shading is wrong (bug is in the bugtracker already). OSD takes normals
> for shading from lowpoly instead of computing new normals.
> 3. No UV subdivision.
> 4. GLSL Compute is not working for me.
> OK, the feature is too new and too raw to use it in production. But OSD is
> based on Catmull-Clark algo, which is already used in the Subsurf modifier,
> OSD is just speeding mesh calculation up. The problem is, OSD and
> Catmull-Clark subdiv models look different, it not supposed to happen IMHO.
>
> 2015-11-05 15:33 GMT+03:00 Nahuel Belich <casillapfo...@yahoo.com.ar>:
>
> > intersting, in that case, as a modeler i would prefer the open subv
> > result, however i didnt model that much using it, the performance its
> much
> > much better, but the shading its "weird" or not accurate on most cases.
> . .
> >  i need to test it more to shape an opinion
> > PasteAll.org - opensubdiv.jpg
> > |   |
> > |   |   |   |   |   |
> > | PasteAll.org - opensubdiv.jpgPasteAll.org - opensubdiv.jpg
> > opensubdiv.jpg ~0.11mb..ish. 916 px. 1335 px. |< << hi PasteAll.org is
> > brought to you by the monkeys of GraphicAll.org -  |
> > |  |
> > | Ver en www.pasteall.org | Vista previa por Yahoo |
> > |  |
> > |   |
> >
> >
> >
> >
> >
> >  El Jueves, 5 de noviembre, 2015 5:09:30, Yury Baranov <
> > cucumbe...@gmail.com> escribió:
> >
> >
> >  Hi. I just mentioned that Blender's subdivision surface is acting a
> little
> > bit different than opensubdiv. It's noticable when using creases on
> > geometry like this: http://puu.sh/la3Xw/3c06b8b687.png
> > Blender's catmull-clark subdivs: http://puu.sh/la3ZJ/a5f8ce2ddf.png
> > Opensubdiv: http://puu.sh/la40E/529b72bec5.png
> >
> > Looks like Blender's Catmull-Clark subdivs are not Catmull-Clark
> subdivs...
> > ___
> > 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] Opensubdiv and catmull-clark again

[Mike Erwin]

Hi Sergey!

I wasn't suggesting the latest OSD should have been rushed into 2.76. But
definitely for the next update. I've upgraded Blender to OSD 3.0.3 locally
and it fixes GLSL compute for both AMD and Intel on Windows. Adaptive
subdivision doesn't seem to work on Intel chips -- on Windows or Mac --
even with Pixar's example programs. No crash or errors; the surface just
doesn't appear on screen. Non-adaptive works fine.

How soon can we bump the libs to 3.0.3? I have a few changes to the
Blender-OSD glue. Can those go into master or would you prefer a new branch
for the stuff I'll be working on?

No ideas yet for the normals but I will investigate. As you know we're
moving to GLSL 1.5 soon so rewriting is going to happen anyway.

Mike Erwin
musician, naturalist, pixel pusher, hacker extraordinaire

On Thu, Nov 5, 2015 at 11:22 PM, Sergey Sharybin <sergey@gmail.com>
wrote:

> Yury,
>
> For the original mail: OpenSubdiv and Blender original CCGSubSurf are using
> different approaches to the patch topology construction, but both of them
> technically are Catmull-Clark subdivisions. There's no correct or wrong
> crease here, it's just different and behaves better in one situation or
> another. We'll switch to OpenSubdiv completely once all the issues are
> solved.
>
> For the followup mail: you're pointing out all the TODOs and limitations
> mentioned in the original release page [1]. Don't see much reason to
> discuss them here, we'll need to work on this still. With a project size of
> OpenSubdiv and the tight release schedule we had so far you can't really
> have everything to be ideally supported from the first commit. It'll all
> come eventually.
>
> Mike,
>
> GLSL Compute is disabled for AMD devices because original OSD library we
> used for the 2.76-rc1 had a bug on AMD hardware. It was fixed later at rc2
> or rc3 from the OpenSubdiv side, but we can't bump library versions at the
> RC stage (bumping it will mean we're allowing to use hardware which was
> known to be buggy without too much tests done first).
>
> For the shading, here's the bug report [2]. I didn't find a way to evaluate
> limit surface on the GPU when using non-adaptive subdivisions and i didn't
> really heard back from Pixar about how it could be done. Wold need to ask
> the guys again. But OpenSubdiv 3.0 is quite fresh so far and perhaps
> non-adaptive case is not high priority for them yet.
>
> Perhaps we can do some other trickery to get better normals, but that'd
> requite having tessellation control and evaluation shaders which was quite
> hard to do with current OpenGL state we've got. It didn't quite work for me
> when trying to sue it as an #extension for glsl 1.3 and mumping glsl to 1.4
> and higher would mean re-writting all the existing shaders (due to removed
> of loads of deprecated stuff in it, i.e. gl_Normal). Maybe you can have
> some other ideas here tho.
>
> [1]
> http://wiki.blender.org/index.php/Dev:Ref/Release_Notes/2.76/OpenSubdiv
> [2] https://developer.blender.org/T45707
>
>
>
> On Thu, Nov 5, 2015 at 10:02 PM, Mike Erwin <significant@gmail.com>
> wrote:
>
> > Hi guys,
> > I'm actively working on OpenSubdiv, especially getting it running on more
> > systems (Intel gfx on Windows, Mac). GLSL compute works on the latest
> > version of OSD (official Blender release doesn't use this yet). Similar
> > performance to Transform Feedback. The other problems you mention... yep
> > those are still problems.
> >
> > Thanks for pointing out #2 -- I knew it looked odd but didn't make the
> > connection to low-poly normals. Can you give a link to the bug tracker?
> >
> > From my understanding, OpenSubdiv will become *the* subsurf
> implementation
> > in Blender, and the old system will go away. But first we need to fix
> these
> > problems.
> >
> > Mike Erwin
> > musician, naturalist, pixel pusher, hacker extraordinaire
> >
> > On Thu, Nov 5, 2015 at 7:52 AM, Yury Baranov <cucumbe...@gmail.com>
> wrote:
> >
> > > Opensubdiv is unusable ATM in fact. Problems are:
> > > 1. Unable to apply Subsurf with OSD enabled. Result is identical to
> > Subsurf
> > > without OSD check.
> > > 2. Shading is wrong (bug is in the bugtracker already). OSD takes
> normals
> > > for shading from lowpoly instead of computing new normals.
> > > 3. No UV subdivision.
> > > 4. GLSL Compute is not working for me.
> > > OK, the feature is too new and too raw to use it in production. But OSD
> > is
> > > based on Catmull-Clark algo, which is already used in the Subsurf
> > modifier,
> > > OSD is just speeding mesh calculation up. The problem is, OS

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

[Mike Erwin]

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 <cucumbe...@gmail.com>
> 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

Re: [Bf-committers] building with opensubdiv using mingw

[Mike Erwin]

With Visual Studio now free (as in beer) for small teams and open source
projects, that takes away one major reason to keep using MinGW. Yes Visual
Studio is a much larger beast than any command-line compiler, but it's
pretty nice to use.

Mike Erwin
musician, naturalist, pixel pusher, hacker extraordinaire

On Wed, Sep 23, 2015 at 4:07 AM, Campbell Barton <ideasma...@gmail.com>
wrote:

> MinGW has been in (semi) broken state for some months now, since some
> libraries are missing.
>
> This is noted on the build page:
>
> http://wiki.blender.org/index.php/Dev:Doc/Building_Blender/Windows/MinGW/CMake
>
> On Wed, Sep 23, 2015 at 4:24 PM, Sergey Sharybin <sergey@gmail.com>
> wrote:
> > There's currently no precompiled OpenSubdiv libraries for mingw.
> >
> > As for the future -- i don't really think we'll keep maintaining mingw
> > libraries. This is because mingw was proven to have obscure issues which
> > makes blender builds unstable. Think we'd be moving to clang rather than
> > keeping trying to use mingw.
> >
> > But that's my vision of the situation, maybe Antony (who was the main guy
> > maintaining mingw builds) has different input here.
> >
> > On Wed, Sep 23, 2015 at 8:34 AM, Yousef Harfoush <ba...@msn.com> wrote:
> >
> >> hi
> >>
> >> i tried to build opensubdiv with scons and mingw but it seems that the
> >> libraries are not found in the mingw lib folder, is it supported on this
> >> compiler? if not will it be? thank you.
> >>
> >>
> >> Regards
> >> Yousef Harfoush
> >> ba...@msn.com
> >>
> >>
> >> ___
> >> 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] building with opensubdiv using mingw

[Mike Erwin]

Ok Sergey and Cezary, you've given good reasons to keep MinGW as a working
alternative on Windows. GCC vs Clang produce similar performance on Linux
(with GCC a little bit better). That's the only platform I've used that
supports both compilers out of the box, so haven't compared on other
platforms. Has anyone tried Clang on Windows?

Also good point about Microsoft being slower at language standards.
Switched to VS 2015 for that very reason.

Mike Erwin
musician, naturalist, pixel pusher, hacker extraordinaire

On Wed, Sep 23, 2015 at 6:07 PM, Cezary Kopias <cezary.kop...@gmail.com>
wrote:

> I`m using mingw on a daily basis in my amateur 'production'
> (some things don't work but its nothing that I am using) ...
>
> ...its the same story every time:
> 1. its faster (cycles cpu render, booleans = linux speed)
> 2. its compact and portable.
>
> We have now OpenSubD... next is OpenVDB, Ptex...
> and after that i will consider a good comeback of mingw.
>
> P.S. I know nothing of clang but maybe could be a good substitute
>
> On 23 September 2015 at 21:15, Sergey Sharybin <sergey@gmail.com>
> wrote:
> > This is true, but it's not all truth :)
> >
> > For a long time gcc even from mingw was producing much better assembly
> than
> > msvc. Even today msvc requires some annoying poking around with all sort
> of
> > weird and wonderful workarounds forbetter performance. Plus it's a bit
> slow
> > about all the language extensions and such. From this point of view clang
> > seems interesting to test.
> >
> > On Wed, Sep 23, 2015 at 11:36 PM, Mike Erwin <significant@gmail.com>
> > wrote:
> >
> >> With Visual Studio now free (as in beer) for small teams and open source
> >> projects, that takes away one major reason to keep using MinGW. Yes
> Visual
> >> Studio is a much larger beast than any command-line compiler, but it's
> >> pretty nice to use.
> >>
> >> Mike Erwin
> >> musician, naturalist, pixel pusher, hacker extraordinaire
> >>
> >> On Wed, Sep 23, 2015 at 4:07 AM, Campbell Barton <ideasma...@gmail.com>
> >> wrote:
> >>
> >> > MinGW has been in (semi) broken state for some months now, since some
> >> > libraries are missing.
> >> >
> >> > This is noted on the build page:
> >> >
> >> >
> >>
> http://wiki.blender.org/index.php/Dev:Doc/Building_Blender/Windows/MinGW/CMake
> >> >
> >> > On Wed, Sep 23, 2015 at 4:24 PM, Sergey Sharybin <
> sergey@gmail.com>
> >> > wrote:
> >> > > There's currently no precompiled OpenSubdiv libraries for mingw.
> >> > >
> >> > > As for the future -- i don't really think we'll keep maintaining
> mingw
> >> > > libraries. This is because mingw was proven to have obscure issues
> >> which
> >> > > makes blender builds unstable. Think we'd be moving to clang rather
> >> than
> >> > > keeping trying to use mingw.
> >> > >
> >> > > But that's my vision of the situation, maybe Antony (who was the
> main
> >> guy
> >> > > maintaining mingw builds) has different input here.
> >> > >
> >> > > On Wed, Sep 23, 2015 at 8:34 AM, Yousef Harfoush <ba...@msn.com>
> >> wrote:
> >> > >
> >> > >> hi
> >> > >>
> >> > >> i tried to build opensubdiv with scons and mingw but it seems that
> the
> >> > >> libraries are not found in the mingw lib folder, is it supported on
> >> this
> >> > >> compiler? if not will it be? thank you.
> >> > >>
> >> > >>
> >> > >> Regards
> >> > >> Yousef Harfoush
> >> > >> ba...@msn.com
> >> > >>
> >> > >>
> >> > >> ___
> >> > >> 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
> >>
> >
> >
> >
> > --
> > 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

Re: [Bf-committers] New Blender Developer

[Mike Erwin]

Hi Joshua,
You probably want to sign up for the bf-viewport mailing list too. Not a
lot of traffic there at the moment, but it's the home for 3D viewport &
OpenGL & soon Vulkan discussions.

Mike Erwin
musician, naturalist, pixel pusher, hacker extraordinaire

On Mon, Aug 31, 2015 at 2:45 PM, <kernel-...@apermund.net> wrote:

> Hi everybody,
>
> I just recently started emailing the mailing list, but I have been hacking
> with Blender since early 2012, so I'm familiar with the code base. I never
> joined the mailing list or contributed code due to time constraints with
> other projects, but I would be glad to help in any way possible now if
> there's any module/project that might benefit from an extra dev or just a
> bug janitor. I am a somewhat experienced C/C++ programmer with OpenGL/GLSL,
> Linux, and X Windows programming experience among other tools/APIs. I also
> am familiarizing myself with Vulkan (still in development), the new API and
> standards that will eventually replace OpenGL. I hope I can help.
>
> Best Regards,
> Joshua Lotfi
> ___
> 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

[Mike Erwin]

On Sat, Aug 15, 2015 at 3:15 PM, Jacob Merrill blueprintrand...@gmail.com
 wrote:

 I think step 1 in any proposal for change,

 we need a new 'map'/flow diagram of the current system,

 any proposed change would be a editied version of this map,


Reminds me of the blender 2.03 book :) But that was a map of the externals,
not internals.


 I have steadily been trying to digest commits, and understand
 what everything does, could steps be taken to refactor blender
 to make it be more approachable for coders in their blender infancy?


This is more about diving into the code. Which is a separate issue but
worth talking about.

I don't think making code more beginner friendly should be a goal. A
beginner is just someone who's not an expert yet. Good refactoring makes it
better for any coder, not just new people.

could there be 1 day a month we set aside to helping new developers get
 into the flow of commiting?


Most years we have GSoC for this, which allows a more hands-on introduction
for a few new coders. I was new to blender's code and development work flow
5 years ago. By now I'm really comfortable with the parts I care about. The
key to getting started is pick one area and learn as much as you can about
it. Who wrote this? Who else works on it regularly? Are any parts of this
code dead/obsolete, so you can skip those and focus on the live parts?
That's any code base really, not just blender's.

Understanding the code as it exists today isn't easy. It's big and has a
history. Keeping up with new commits isn't easy since there's so much
activity. It's possible though, and I've never gotten the impression that
anyone is actively making things harder for new people.


Mike Erwin
musician, naturalist, pixel pusher, hacker extraordinaire
___
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

[Mike Erwin]

Kai makes a good point.

Sometimes I'll see something new and think cool, but why is today the
first time I'm hearing about this?!? So I understand the impression of
things happening behind closed doors. When is the best time to share an
idea though? The second it's thought up or after working out the details?
At this point why not code it up to test how well the idea works? And once
the code is done, why bother presenting it as an idea or design? It
works, it's done!

From the inside this seems like getting things done. From the outside it
seems like working behind closed doors. I'm really bad about this myself :)
but catch myself getting annoyed when other people do the exact same
things. I don't think anyone is *hiding* their work though. Just following
habits of not being actively open.

Even if an area will be owned by one or a few people, it's important to
have designs out in the open so everyone knows what's going on. Earlier is
better. Lots of comments surrounding any design will be nonsense -- or input
of wildly varying levels of quality as Martijn put it more politely. But
I'd rather sift through noise than seem to be working in secret. And it's
also important to document things that were *considered* but not chosen as
part of the final design. Broader documentation of decision-making
processes will reduce surprises and hopefully eliminate the impression that
core developers ignore the needs and ideas of others.

What is the proper forum for proposals and other design docs?
code.blender.org? wiki pages for work in progress? I see posts on
blenderartists and Twitter and G+, which seem unofficial but also reach
an audience that might not follow the mailing lists or hang out on IRC.

Great, now I suddenly have the urge to document my own stuff.

Mike Erwin
musician, naturalist, pixel pusher, hacker extraordinaire
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Blender 2.8 - the Workflow release

[Mike Erwin]

Great initiative! And I think floating perfectly describes our current
situation.

This trooper is energized for 2.8 and can focus on:
- viewport, OpenGL, GLSL performance
- GLSL authoring (shaders as content)
- platform specific/GHOST work
- anything involving Blender -- Unreal Engine

C++11 everywhere in 3.0? :D

Mike Erwin
musician, naturalist, pixel pusher, hacker extraordinaire

On Mon, Jul 20, 2015 at 9:49 AM, Ton Roosendaal t...@blender.org wrote:

 Hi all,

 (also posted on http://code.blender.org)
 This is a proposal for work focus on blender.org for the coming year.

 I've written this because we keep missing bigger development targets - we
 don't have enough time for larger projects. Instead too much time goes to
 releases, bug fixing, reviews, maintenance and support topics. The bug and
 patch tracker duties are keeping the best of our developers away from their
 own targets.  As a result we then don't have time for design docs, for
 planning, logs and in-depth sessions with the module teams, and have no
 time for the artists who are involved to make sure we're well aligned and
 know what to do. I think everyone has noticed that we're floating too much,
 things are not clear. Where are we heading? Who does what, and how do we
 decide on things?

 So - it's time to act and gather the troops to refocus and get back
 energy, to maximize involvement from everyone who's active in blender.org
 and make sure Blender can survive for many more years.

 - Blender 2.8 - Workflow release -

 Just like for 2.5, the proposal would be to take a bigger leap to a bigger
 release by not releasing for a year. The 2.76 release then would be the
 last 'real' version we do until 2.80 somewhere in 2016.

 Obviously, for the crucial fixes and smaller (stable) features we can do
 update releases 2.77, 2.78 and 2.79.

 Topics to finish for 2.8 could be:

 - UI work: wrap up Python configurability project, make Workflow based
 configuring possible
   Proof of concept: the stripped Blender 101 for high school kids.
 - Viewport project, including a PBR quality engine/editor that could
 replace BI and GE render.
 - A better designed integration of physics simulation in Blender
 - Invite the GE team to rethink game logic editing, to use viewport and
 new physics
 - Don't add the half finished Gooseberry targets but take the time needed
 to code it well:
 Particle nodes, hair nodes, simulation nodes, modifier nodes...
 - Asset managing and browsing, linking, references, external files in
 general.
 - Integration in non Blender pipelines.

 Practical considerations:

 - Move development to special 2.8 branch(es)
 - Module teams are empowered to cleanup quite radically and get rid of
 legacy code.
 - The 2.8 series is allowed to be not 100% compatible with 2.7x. (Physics,
 particles, games).
 - Spend time on organizing ourselves better, agreed designs should lead to
 more empowerment.

 And some core principles to agree on:

 - We reconfirm and where needed update the 2.5 spec docs.
 - Stick to existing Blender data structures and code design for as much as
 possible.
 - Make Blender ready to survive until 2020, but...
 ... start collecting the list of bigger redesign issues we need to for
 a 3.0 project
 - Bring back the fun in Blender coding! :)

 The code.blender.org article for the roadmap of 2014-2015 is still valid
 in my opinion. We just need to take a break of 9-12 months now, to make it
 work for real.
 Blender 2.8 Workflow Sprint

 In the coming months we can discuss and review the plans and make sure
 we're 100% aligned on the 2.8 targets and for other work during the coming
 years. We should also meet and have good feedback sessions on it. So I
 propose to use the Blender Conference in October as a deadline, and
 organize a workshop in the week before.

 - Four days of workshops and design sessions, in the week before Blender
 Conference.
 - Travel and hotel covered for by BF (and Dev Fund, or a new fund raiser?)
 - We should try to get someone from every (active, involved) module team
 on board. Also key user/contributors have to be on board. But it's also
 more efficient to keep it compact.
 - Proposal: we do this invitation-only: First we invite the 5 most active
 contributors of past years. Together they then invite persons more, until
 we have 12 (?) people.
 - Sprint sessions can be in parallel too - UI, Viewport, Physics, etc.
 Let's make it public as good as possible.
 - The Sprint results get presented and reviewed during further on sessions
 during the Blender Conference.

 Seven years ago, back in 2008, we also took a break of over a year, to get
 the 2.5 project started up. It was a very exciting period where a lot of
 new things were possible and could happen, even though we didn't finish
 everything... it gave us quite a solid foundation to build on, attracting a
 lot of new developers and great features.
 I realize we have to realistic now, not everything will possible. But we
 also

Re: [Bf-committers] Blender 2.8 - the Workflow release

[Mike Erwin]

Thanks Lukas for the google doc! It's a good read and glimpse into how
software dev issues can become production issues.

Mike Erwin
musician, naturalist, pixel pusher, hacker extraordinaire

On Mon, Jul 20, 2015 at 12:53 PM, Lukas Tönne lukas.toe...@gmail.com
wrote:

 I've started writing about the development and the problems we encountered
 during the Cosmos Laundromat/Gooseberry production. These documents could
 be a good primer for devs who haven't done any development in a studio
 environment like the Blender Institute (like myself before this project).

 First is a general wiki doc summarizing all the major development and
 research topics. Only the section on hair systems is fleshed out atm, the
 rest will be added soon. The document is meant to give an overview and
 links to scientific papers for future reference, so each topic is handled
 only briefly.


 http://wiki.blender.org/index.php/Org:Institute/Open_projects/Gooseberry/SummaryLukas

 Out of all these diverse topics, the library linking system and its
 implications for pipeline and asset management have been a serious
 challenge. IMO the solutions we developed during the production, although
 they made the movie possible, are still not satisfying. Because this has
 been a problem in virtually every movie production since the invention of
 open movies, i thought it would help to start at the root and write a
 detailed examination. The following document is an attempt to build up the
 complete picture from the basics (how movie production works) up to the
 existing situation in Blender and beyond. The proposal the end is not final
 (!), finding a solid solution will require all the brains we can get.


 https://docs.google.com/document/d/1M_sjvt65ytN7VxDSZzvu3xwUImO8BYfuVbZ527Rqxp4/edit?usp=sharing

 Please excuse the shoddy formatting and unfinished state, i thought it
 better to release them early than let them collect dust.

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

[Mike Erwin]

On Wed, Jan 21, 2015 at 8:23 AM, brita britalme...@gmail.com wrote:

 Upgrading the minimum to 2.1 does not mean that Blender does not use higher
 OpenGL features.
 It can always query for the ogl version and use the available features,
 resulting, for example, in more performance.
 There is no need of a separate build.


Should we strictly use extensions for anything newer? That would have
almost the same effect as using a higher version while making it more clear
what we support.

The question is if versions older than 2.1 can be dropped in order for
 developers not having to loose their time coding fallback methods for
 (very!) older versions.


Yes yes yes! Or not forget/neglect to code a fallback for something I
*assume* is available on a random user's system. Check for 2.1+ at startup
and so many assumptions are verified. The much smaller number of useful GL
extensions is easier to remember to check.

Mike Erwin
musician, naturalist, pixel pusher, hacker extraordinaire
___
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

[Mike Erwin]

On Sun, Jan 18, 2015 at 11:16 AM, h...@jupama.org wrote:

 This topic leads me to two questions:

 - upgrade to OpenGL 2.1: the OpenGL is currently at version 4.5.  Is it
 impossible to maintain the same version in blender?


This would severely limit blender's audience. Only Windows  Linux running
proprietary vendor drivers on *new* graphics cards are able to run GL 4.5.
The laptop I'm using right now says GL 4.4 even with the latest drivers!
2.1 has been around long enough that it is essentially universal. Yes we'll
miss out on some nice capabilities. We have been using features from later
versions of GL but not always in a consistent way. Part of the project is
eye candy, part is improved performance, and just as important is setting a
higher baseline and making the code consistent and safe.

- and my endless quest of finding out the relation between OpenGL, GLSL,
 GHOST.  Does GHOST uses the OpenGL libraries directly? or does it call
 GLSL.


GHOST sets up OpenGL contexts in platform-specific ways. Other than that
GHOST does not use GL or GLSL for its own purposes.


 Thanks for your time.

 Regards

 Hewi


Mike Erwin
musician, naturalist, pixel pusher, hacker extraordinaire
___
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

[Mike Erwin]

Here's a snippet from what I'm working on, since checking for GL version
was brought up in meeting. I like the float version better, but here's both:

#if 0

*bool* versionAtLeast(*int* major, *int* minor)

  {

  *int* actual_major, actual_minor;

  *const* *char** version_str = (*const* *char**)glGetString(GL_VERSION);

  *if* (sscanf(version_str, %d.%d, actual_major, actual_minor) != 2)

 *return* *false*;

  printf(version %d.%d\n, actual_major, actual_minor);

  *return* actual_major  major || (actual_major == major  actual_minor
= minor);

  }

#else

*bool* versionAtLeast(*float* desired_version)

  {

  *float* actual_version;

  *const* *char** version_str = (*const* *char**)glGetString(GL_VERSION);

  *if* (sscanf(version_str, %f, actual_version) != 1)

 *return* *false*;

  printf(version %.1f\n, actual_version);

  *return* actual_version = desired_version;

  }

#endif


*void* showOpenGLInfo()

  {

  puts(--- OpenGL version ---);

// if (versionAtLeast(2,1))

  *if* (versionAtLeast(2.1))

 puts(GL version ok);

   *else*

 puts(GL version TOO LOW);


  printf(GLSL %s\n, (*char**) glGetString(GL_SHADING_LANGUAGE_VERSION));


  puts((*char**) glGetString(GL_VENDOR));

  puts((*char**) glGetString(GL_RENDERER));


  puts(--- OpenGL extensions ---);

  *char** multiple = (*char**) glGetString(GL_EXTENSIONS);

  *char** single;

  *while* (single = strsep(multiple, ), strlen(single))

  puts(single);


  // query unchanging limits *once* at startup

  GLint value;

  glGetIntegerv(GL_MAX_ELEMENTS_VERTICES, value);

  printf(GL_MAX_ELEMENTS_VERTICES: %d\n, value);

  glGetIntegerv(GL_MAX_ELEMENTS_INDICES, value);

  printf(GL_MAX_ELEMENTS_INDICES: %d\n, value);

  glGetIntegerv(GL_MAX_TEXTURE_SIZE, value);

  printf(GL_MAX_TEXTURE_SIZE: %d\n, value);


// puts(--- renderer info ---);

// long info;

// CGLGetParameter( contextObj, kCGLCPGPUVertexProcessing, info );

// printf(vertex processing in %s\n, info ? GPU : software);

// CGLGetParameter( contextObj, kCGLCPGPUFragmentProcessing, info );

// printf(fragment processing in %s\n, info ? GPU : software);

  }

In next release, before making 2.1 mandatory, we could check and do
*something* if the target system isn't up to snuff. Message in the info
header?. Pop up a message box?


Mike Erwin
musician, naturalist, pixel pusher, hacker extraordinaire

On Wed, Dec 31, 2014 at 6:07 AM, John James kiso...@gmail.com wrote:

 Is it possible to make an installation check of future requirements and
 display a strong warning (that is not easily bypassed by just clicking
 Next) that there is a plan to make them obsolete. This will enable users
 to prepare beforehand and also give them possibility to object. If 50% are
 still using the old features should they be faced with the fact No new
 updates for You!? I am for the use of the latest features of the hardware
 when they are present by the way :)

 2014-12-31 11:55 GMT+02:00 Martijn Berger martijn.ber...@gmail.com:

  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

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

[Mike Erwin]

Hear, hear!

Setting OpenGL 2.1 as a foundation gives us a large feature set
to work with, reducing our reliance on extensions that might or might
not be available at run time. For example VBOs and GLSL 1.2 are
*guaranteed* to be there so we won't need conditional checks or
ARB suffixes for those functions/enums.

When would be an appropriate time to require 2.1? As in refuse
to run if less than this?

I have a growing list of still-nice-to-have extensions that have not
been adopted into core OpenGL as of 2.1. Half the list is on this
machine and the rest on Windows -- I'll put together a full post on
this topic soon.

Mike Erwin
musician, naturalist, pixel pusher, hacker extraordinaire

On Tue, Dec 30, 2014 at 10:49 AM, 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] Should the grease pencil tab be renamed?

[Mike Erwin]

Maybe annotate? The word utilities could mean so many things, a bit too
generic.

Mike Erwin
musician, naturalist, pixel pusher, hacker extraordinaire


On Tue, Jun 17, 2014 at 3:20 AM, David McSween 3pointe...@gmail.com wrote:

 What a great suggestion. Would this be a more logical place for some addons
 ui?
 On 17 Jun 2014 17:06, gandalf3 zzyx...@gmail.com wrote:

  The grease pencil tool has an entire tab on the tool shelf named after
  itself, however this tab contains (currently one) other tool (the
  measure tool). I also noticed that the measure tool is in the same
  panel/collapsible section as the grease pencil tool, though they seem
  like pretty separate tools IMO.
  After tabs were added, it took me some time to figure out where the
  measure tool was.
 
  Should the grease pencil tab be renamed to something more generic, like
  utilities or something?
  This would allow the addition of more unrelated yet similar tools later.
 
  --
  -gandalf3
 
  ___
  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] [Bf-blender-cvs] [c777f69] master: Fix T39663: Blender crashes when trying to triangulate uv unwrapped mesh.

[Mike Erwin]

Thanks! That one bit me already.

Mike Erwin
musician, naturalist, pixel pusher, hacker extraordinaire


On Wed, Apr 9, 2014 at 4:21 PM, Campbell Barton ideasma...@gmail.comwrote:

 This isnt needed for 2.70a, the error is from
 4614c63d5dcbf10a16e74235c452fe69ad0cddee

 On Thu, Apr 10, 2014 at 6:17 AM, Bastien Montagne
 nore...@git.blender.org wrote:
  Commit: c777f691ad427260fb39c8d191d3041169e557dd
  Author: Bastien Montagne
  Date:   Wed Apr 9 22:15:25 2014 +0200
  https://developer.blender.org/rBc777f691ad427260fb39c8d191d3041169e557dd
 
  Fix T39663: Blender crashes when trying to triangulate uv unwrapped mesh.
 
  A dummy arg inversion! This is to be included in 2.70a!
 
  ===
 
  M   source/blender/bmesh/intern/bmesh_core.c
 
  ===
 
  diff --git a/source/blender/bmesh/intern/bmesh_core.c
 b/source/blender/bmesh/intern/bmesh_core.c
  index faa0e94..bd86f49 100644
  --- a/source/blender/bmesh/intern/bmesh_core.c
  +++ b/source/blender/bmesh/intern/bmesh_core.c
  @@ -1260,7 +1260,7 @@ static BMFace *bm_face_create__sfme(BMesh *bm,
 BMFace *f_example)
  f-totbounds = 1;
   #endif
 
  -   BM_elem_attrs_copy(bm, bm, f, f_example);
  +   BM_elem_attrs_copy(bm, bm, f_example, f);
 
  return f;
   }
 
  ___
  Bf-blender-cvs mailing list
  bf-blender-...@blender.org
  http://lists.blender.org/mailman/listinfo/bf-blender-cvs



 --
 - 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] 3DxWare note on download page

[Mike Erwin]

3DxWare 10 is now the default Mac driver from 3Dconnexion, so I think it's
safe to remove the warning on our download page.

Would anyone be opposed if I removed support for the old driver? The
new/current driver runs on Mac OS 10.6+ so we wouldn't be leaving anyone
behind that we haven't already. Linux  Windows would be unaffected.

Mike Erwin
musician, naturalist, pixel pusher, hacker extraordinaire
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] OSX Mavericks 10.9 (mostly) success

[Mike Erwin]

(sorry if this is a repeat post, I got a bounce alert from the list server
a few days ago)

Jake,
Thanks for taking initiative on this! Looks like we're in pretty good shape
when 10.9 ships. I'll look into the 3Dconnexion build issue soon -- I'd
forgotten about it since I always have their driver installed.

Yeah, it's weird that -weak_framework stopped working (was fine with gcc 
friends) but there are other ways to do what we need. Will send an update
when it's building fine with  without the driver.

Mike Erwin
musician, naturalist, pixel pusher, hacker extraordinaire
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Where did OpenGL dither go?

[Mike Erwin]

Yes, dither is still supported, but our implementation might not be
noticeable in full color RGB modes. It should be more obvious with a 16-bit
color buffer, but I don't have blender dev set up here to try that. This is
part of one of the few fixed-function parts of hardware these days, where
floating point fragment values are reduced to fixed point (of whatever bit
depth) in the framebuffer. You could always do a custom dither in the frag
shader to make the background color ramp look more natural -- roughen it
up to make it seem more smooth. Most displays do their own dithering on top
of all this, to make 8bpc signals look decent on (typically) 6bpc panels.
Maybe that's why the full-color dither doesn't try very hard to look good.

Mike Erwin
musician, naturalist, pixel pusher, hacker extraordinaire


On Fri, Jun 7, 2013 at 1:14 AM, Mike Erwin significant@gmail.comwrote:

 Hey guys,
 I'll ask tomorrow at work, for the Mac ATI at least. What is it supposed
 to look like relative to the picture you posted?
 --Mike

 On Thursday, June 6, 2013, Ton Roosendaal wrote:

 Hi,

 Yes of course that's it... 12 or 16 bits color displays had it. A decade
 ago!
 In the SGI days, many systems did double-buffer by halving the color
 space to 2x12 bits, dithered too.

 Nevertheless, for 24 bits true color it would look nicer too :)

 -Ton-

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



 On 6 Jun, 2013, at 14:10, Brecht Van Lommel wrote:

  I can't find good info on it either, maybe it was only ever used for
  OpenGL color index mode or displays with less than 8 bits per color
  channel?
 
  The dither implementation is not specified by the OpenGL
  specification, and it's valid to not do any dithering at all.
 
  On Thu, Jun 6, 2013 at 12:58 PM, Ton Roosendaal t...@blender.org
 wrote:
  Hi all,
 
  Someone pointed me at the banding, visible in shaded 3d viewports with
 greyscales.
  None of the systems I tried (mac nvidia, mac ati, linux nvidia) shows
 any dither in the viewport... and there's nothing in the code pointing at
 being disabled.
 
  I checked it with a print in the graded backdrop drawing:
  printf(dither is %d\n, glIsEnabled(GL_DITHER));
 
  And it says it's on.
 
  Screenie, with expanded color range to see the banding:
  http://www.pasteall.org/pic/52953
 
  Shouldn't it show a nice stipple pattern? I recall this, but more like
 from 10 years ago or so :)
 
  Googling about it didn't give me info about this feature being dropped
 in drivers nowadays.
 
  -Ton-



 --
 Mike Erwin
 musician, naturalist, pixel pusher, hacker extraordinaire

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

Re: [Bf-committers] Where did OpenGL dither go?

[Mike Erwin]

Hey guys,
I'll ask tomorrow at work, for the Mac ATI at least. What is it supposed to
look like relative to the picture you posted?
--Mike

On Thursday, June 6, 2013, Ton Roosendaal wrote:

 Hi,

 Yes of course that's it... 12 or 16 bits color displays had it. A decade
 ago!
 In the SGI days, many systems did double-buffer by halving the color space
 to 2x12 bits, dithered too.

 Nevertheless, for 24 bits true color it would look nicer too :)

 -Ton-

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



 On 6 Jun, 2013, at 14:10, Brecht Van Lommel wrote:

  I can't find good info on it either, maybe it was only ever used for
  OpenGL color index mode or displays with less than 8 bits per color
  channel?
 
  The dither implementation is not specified by the OpenGL
  specification, and it's valid to not do any dithering at all.
 
  On Thu, Jun 6, 2013 at 12:58 PM, Ton Roosendaal 
  t...@blender.orgjavascript:;
 wrote:
  Hi all,
 
  Someone pointed me at the banding, visible in shaded 3d viewports with
 greyscales.
  None of the systems I tried (mac nvidia, mac ati, linux nvidia) shows
 any dither in the viewport... and there's nothing in the code pointing at
 being disabled.
 
  I checked it with a print in the graded backdrop drawing:
  printf(dither is %d\n, glIsEnabled(GL_DITHER));
 
  And it says it's on.
 
  Screenie, with expanded color range to see the banding:
  http://www.pasteall.org/pic/52953
 
  Shouldn't it show a nice stipple pattern? I recall this, but more like
 from 10 years ago or so :)
 
  Googling about it didn't give me info about this feature being dropped
 in drivers nowadays.
 
  -Ton-



-- 
Mike Erwin
musician, naturalist, pixel pusher, hacker extraordinaire
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Basic touch support for Windows/Linux

[Mike Erwin]

Those are PAN subtypes of WM_GESTURE. In older API we see mouse wheel
events, maybe with modifier keys (somebody correct me if wrong). Pinch 
rotate are other subtypes, so if panning works, the others are just as easy
to add.

But if we can get good smooth deltas from legacy mouse wheel events, that's
probably closer to what you had in mind!

On Wednesday, February 6, 2013, Ton Roosendaal wrote:

 Hi Mike,

 I don't understand - this basic version of touch is just to support
 2-finger swipes. Real gestures (pinch, rotate, etc) is another topic.

 -Ton-

 
 Ton Roosendaal  Blender Foundation   t...@blender.org javascript:;
 www.blender.org
 Blender Institute   Entrepotdok 57A  1018AD Amsterdam   The Netherlands

 On 6 Feb, 2013, at 4:04, Mike Erwin wrote:

  Hey Ton  all,
 
  I spent the past two weekends working on this for Windows actually,
  inspired by your Mac trackpad goodness! The code came together fine,
 but...
  never gets called on the hardware I have. Tested on Wacom Intuos5 and
  Logitech T650 under Windows 7. From what I understand, the WM_GESTURE
  message (which we can turn into GHOST events) can not be generated by
  3rd-party hardware vendors, until Microsoft sorts it out. It supposedly
  works with touchscreens, but I don't have one to test. Wacom has a touch
  API for their stuff, but I can't find any more info for the T650.
 
  Another issue is that the Windows touch/gesture APIs are for Win7 and up,
  so if anyone knows a good way to include those but still be able to
  build/run on WinXP, please share it.
 
  I'll post the short code segment if someone can get it to work.
 
  Mike Erwin
  musician, naturalist, pixel pusher, hacker extraordinaire
 
 
  On Tue, Feb 5, 2013 at 11:42 AM, Ton Roosendaal 
  t...@blender.orgjavascript:;
 wrote:
 
  Hi,
 
  On macs, 2-finger swipes (trackpads, tablets) now get handled nicely. It
  sends trackpad events from Ghost to blender, to work as smooth as MMB
  view manipulations.
 
  On Blender side code is all fine, but I need someone in Windows and
 Linux
  to get the Ghost code sending out the right events for it. (Instead of
  scrollwheel events, to send trackpad).
 
  It should have been done in bcon3, I know - but it's probably just 2-3
  lines in ghost to send the events! And needs tests :)
 
  -Ton-
 
  
  Ton Roosendaal  Blender Foundation   t...@blender.org javascript:;
 www.blender.org
  Blender Institute   Entrepotdok 57A  1018AD Amsterdam   The Netherlands
 
  ___
  Bf-committers mailing list
  Bf-committers@blender.org javascript:;
  http://lists.blender.org/mailman/listinfo/bf-committers
 
  ___
  Bf-committers mailing list
  Bf-committers@blender.org javascript:;
  http://lists.blender.org/mailman/listinfo/bf-committers

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



-- 
Mike Erwin
musician, naturalist, pixel pusher, hacker extraordinaire
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Basic touch support for Windows/Linux

[Mike Erwin]

Hey Ton  all,

I spent the past two weekends working on this for Windows actually,
inspired by your Mac trackpad goodness! The code came together fine, but...
never gets called on the hardware I have. Tested on Wacom Intuos5 and
Logitech T650 under Windows 7. From what I understand, the WM_GESTURE
message (which we can turn into GHOST events) can not be generated by
3rd-party hardware vendors, until Microsoft sorts it out. It supposedly
works with touchscreens, but I don't have one to test. Wacom has a touch
API for their stuff, but I can't find any more info for the T650.

Another issue is that the Windows touch/gesture APIs are for Win7 and up,
so if anyone knows a good way to include those but still be able to
build/run on WinXP, please share it.

I'll post the short code segment if someone can get it to work.

Mike Erwin
musician, naturalist, pixel pusher, hacker extraordinaire


On Tue, Feb 5, 2013 at 11:42 AM, Ton Roosendaal t...@blender.org wrote:

 Hi,

 On macs, 2-finger swipes (trackpads, tablets) now get handled nicely. It
 sends trackpad events from Ghost to blender, to work as smooth as MMB
 view manipulations.

 On Blender side code is all fine, but I need someone in Windows and Linux
 to get the Ghost code sending out the right events for it. (Instead of
 scrollwheel events, to send trackpad).

 It should have been done in bcon3, I know - but it's probably just 2-3
 lines in ghost to send the events! And needs tests :)

 -Ton-

 
 Ton Roosendaal  Blender Foundation   t...@blender.orgwww.blender.org
 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

Re: [Bf-committers] Basic touch support for Windows/Linux

[Mike Erwin]

Yes, I can send something about 9 hours from now (no internet at home!). Win8
might like it better than 7, but it's supposed to work on both.

On Tuesday, February 5, 2013, Dalai Felinto wrote:

 Hi Mike,

 Do you have a patch I could use to test here?
 I have a trackpad that I use in the OSX, but my laptop has Windows8 in the
 bootcamp, so it may work.

 --
 Dalai

 2013/2/5 Mike Erwin significant@gmail.com javascript:;

  Hey Ton  all,
 
  I spent the past two weekends working on this for Windows actually,
  inspired by your Mac trackpad goodness! The code came together fine,
 but...
  never gets called on the hardware I have. Tested on Wacom Intuos5 and
  Logitech T650 under Windows 7. From what I understand, the WM_GESTURE
  message (which we can turn into GHOST events) can not be generated by
  3rd-party hardware vendors, until Microsoft sorts it out. It supposedly
  works with touchscreens, but I don't have one to test. Wacom has a touch
  API for their stuff, but I can't find any more info for the T650.
 
  Another issue is that the Windows touch/gesture APIs are for Win7 and up,
  so if anyone knows a good way to include those but still be able to
  build/run on WinXP, please share it.
 
  I'll post the short code segment if someone can get it to work.
 
  Mike Erwin
  musician, naturalist, pixel pusher, hacker extraordinaire
 
 
  On Tue, Feb 5, 2013 at 11:42 AM, Ton Roosendaal 
  t...@blender.orgjavascript:;
 wrote:
 
   Hi,
  
   On macs, 2-finger swipes (trackpads, tablets) now get handled nicely.
 It
   sends trackpad events from Ghost to blender, to work as smooth as MMB
   view manipulations.
  
   On Blender side code is all fine, but I need someone in Windows and
 Linux
   to get the Ghost code sending out the right events for it. (Instead of
   scrollwheel events, to send trackpad).
  
   It should have been done in bcon3, I know - but it's probably just 2-3
   lines in ghost to send the events! And needs tests :)
  
   -Ton-
  
  
 
   Ton Roosendaal  Blender Foundation   t...@blender.org javascript:;
  www.blender.org
   Blender Institute   Entrepotdok 57A  1018AD Amsterdam   The Netherlands
  
   ___
   Bf-committers mailing list
   Bf-committers@blender.org javascript:;
   http://lists.blender.org/mailman/listinfo/bf-committers
  
  ___
  Bf-committers mailing list
  Bf-committers@blender.org javascript:;
  http://lists.blender.org/mailman/listinfo/bf-committers
 
 ___
 Bf-committers mailing list
 Bf-committers@blender.org javascript:;
 http://lists.blender.org/mailman/listinfo/bf-committers



-- 
Mike Erwin
musician, naturalist, pixel pusher, hacker extraordinaire
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Mac Trackpad

[Mike Erwin]

Wow, this is fun on a MacBook Pro. Thanks for working on this, Ton!

Mike Erwin
musician, naturalist, pixel pusher, hacker extraordinaire


On Thu, Jan 3, 2013 at 3:55 AM, Ton Roosendaal t...@blender.org wrote:

 Hi,

 Glad to hear this works :)

 The 2-finger swipes are in the keymap editor called Mouse - trackpad -
 move.
 It is set to rotate in default, with SHIFT for translate and CTRL for zoom.

 You can map that to other settings easily.

 Also note that I'll add a user option to reverse pan and rotate swiping
 direction.

 -Ton-

 
 Ton Roosendaal  Blender Foundation   t...@blender.orgwww.blender.org
 Blender Institute   Entrepotdok 57A  1018AD Amsterdam   The Netherlands

 On 2 Jan, 2013, at 21:41, Johnny Matthews wrote:

  I just got a chance to try the new Mac trackpad changes, and I have to
 say,
  sculpting with one hand on the wacom and the other on the magic trackpad
 is
  awesome!!! One suggestion since 2 finger scroll is rotation, is it
 possible
  to make 3 finger scroll affect translation?
 
  Johnny Matthews (guitargeek)
  johnny.matth...@gmail.com
  http://pedalboardplanner.com
 
  http://twitter.com/pedalboardplan
  ___
  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] [Bf-blender-cvs] SVN commit: /data/svn/bf-blender [53006] trunk/blender/source/blender/ editors/space_view3d/view3d_ops.c: workaround for ndof events showing in view3d menu items.

[Mike Erwin]

Hey Campbell,
This change disables 3D mouse motion and most of the buttons in the 3D
view. Is there a part 2 coming that restores functionality? Are you
talking about these showing in the input settings / keymap editor, or some
place else?

Mike Erwin
musician, naturalist, pixel pusher, hacker extraordinaire
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Default .blend cube

[Mike Erwin]

On Sat, Nov 3, 2012 at 12:27 AM, Jason Wilkins
jason.a.wilk...@gmail.com wrote:
 If somebody were to redo the .blend, please see if you can fix the gap
 between the top info bar and the window title bar.


Yes, please! I thought it was just me...

Mike Erwin
musician, naturalist, pixel pusher, hacker extraordinaire
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] ndof patch

[Mike Erwin]

Sergey Sharybin sergey@gmail.com wrote:
 Made tests and review here. Works cool. From code POV could only see some
 possible cosmetic changes.

 Mike, could you see anything bad with the patch? If not -- LGTM.

No, the patch looks fine to me. (Existing) zoom+orbit is good pretty
much only for object-centered tasks, and overall this is much more
flexible. Thanks, Fredrik! Feel free to commit, Sergey.
Polishing can come later, it's the behavior/UX that matters.

-- Mike

 On Wed, Aug 15, 2012 at 9:23 AM, Sergey Sharybin sergey@gmail.comwrote:

 Hi,

 Would check the patch today.


 On Tue, Aug 14, 2012 at 8:25 PM, Mike Erwin significant@gmail.comwrote:

 Awesome! I'll take a look at this after work. The lack of
 auto-rotation-pivot (based on what's on screen) made me hesitate to
 add free-form pan  rotate before.

 Mike Erwin
 musician, naturalist, pixel pusher, hacker extraordinaire


 On Tue, Aug 14, 2012 at 11:53 AM, Fredrik hansson
 fredrikhansson_12...@yahoo.com wrote:
  copy pasted from the patch notes:
  i wasn't really happy with how the ndof integration was done so i made
 some changes.
 
  the new behavior of it is that you can rotate and pan the view at the
 same time.
  i
   also added a new option to the ndof menu letting you pick
  turntable/trackball independently of the mouse viewport navigation
  style.
  and another option to change the rotation sensitivity separate
   from the panning since the scale of the scene might need you to change
  the translation speed much higher but the rotation should always work
  the same.
  holding shift + moving the ndof does just as before locking it to
 panning
  holding ctrl + moving will lock it to only rotation
  and holding no keys while moving will do both at the same time.
 
 
 
 http://projects.blender.org/tracker/index.php?func=detailaid=32326group_id=9atid=127
  ___
  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




 --
 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] build error

[Mike Erwin]

On Wed, Jun 13, 2012 at 3:43 PM, William Hamblen 
b...@turnaroundproductions.org wrote:

 As a novice in this I guess I should ask, how difficult is it to upgrade,
 or is it even possible to upgrade, to a newer gcc version in my current
 build environment.


It's close enough to impossible to not want to do it. Apple has moved away
from gcc in favor of clang/llvm. I've noticed the word ceres pop up in
build failures on Mac and Windows the past few days, so they must be doing
some fancy stuff requiring the latest and greatest compilers. Thanks
Campbell for the WITH_BF_LIBMV workaround.

Mike Erwin
musician, naturalist, pixel pusher, hacker extraordinaire
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] New Style Rule? (OpenGL Related)

[Mike Erwin]

Hey Jason,

I agree that glBlah, gl_blah, GLblah, and GL_BLAH look too much like
official OpenGL/GLSL and should be avoided or renamed to avoid
confusion. Not so sure about tacking _gl at the end of anything
related. For the support functions  types you'll be building this
summer, absolutely. A function that abstracts OpenGL calls could be
named draw_something_gl, and that makes sense. Functions that call
draw_something_gl but don't use the OpenGL API directly should not
have a _gl suffix. Functions  types should have to earn this suffix,
so to speak.

For variable names, no thanks! For clarity I try to use the GL types
(GLfloat, etc.) even though they're just simple typedefs. But I name
that GLfloat variable whatever makes sense in context to what's around
it.

Mike Erwin
musician, naturalist, pixel pusher, hacker extraordinaire


On Sun, May 6, 2012 at 2:11 AM, Jason Wilkins jason.a.wilk...@gmail.com wrote:
 Yes, there are two different points here:

 First, Existing identifiers that are named glBlahBlah should be
 renamed to blah_blah_gl so that their is no confusion.

 Second, an identifier that is GL related but is currently named
 blah_blah should be renamed blah_blah_gl.

 I agree that this should not be done simply so that a tool is easier
 to write.  I was going to try and reiterate my justifications, but
 honestly this just satisfies my own personal desire for consistency
 :-)

 Besides, an argument could be made that regular expressions are a
 dumb, but useful tool, and following a convention that allows you to
 use them fearlessly is probably a good thing.

 On Sat, May 5, 2012 at 9:09 AM, Campbell Barton ideasma...@gmail.com wrote:
 If I understand correctly youd like to reduce confusion so
 glBlahBlah isnt confused with SomeBlenderStruct.glBlahBlah, instead
 using different convention of SomeBlenderStruct.gl_blah_blah

 While Im not wary of changing code simply so some regex tools can
 parse it easier, I think this is reasonable to avoid confusion, IMHO
 it makes it more readable for humans too :)

 In fact for our C and python code we have loose convention of camel
 case for types and underscores for members/attributes, so this is in
 keeping with our current style guide even.

 On Sat, May 5, 2012 at 2:57 PM, Jason Wilkins jason.a.wilk...@gmail.com 
 wrote:
 I'd like to propose that if an identifier is used with OpenGL, and it
 holds or implements something that is directly OpenGL related, that
 its name should follow a convention that clearly marks it as OpenGL
 related but is not mistakable for a proper OpenGL token.

 I would suggest the _suffix style.  For example:

 GLint texture_id_gl;

 What would be wrong would be:

 int gl_texture_id; /* Is this a GLSL token?? */

 A real example in Blender is a variable named 'glxVersionMajor'.  My
 suggestion would be version_major_glx (depending on what other
 variables in GHOST look like).

 My justification is two fold.

 1) Although humans with lots of GL experience can tell a fake OpenGL
 symbol from the thousands (literally) of real ones, novices and
 automated tools cannot be certain.

 2) The _suffix style appears to be the only set of tokens that OpenGL
 *has not already used* /sigh.

 On side note, I'm sure there are many variables containing OpenGL
 values that are difficult to find because they do not follow any
 convention, so they aren't even fake :-) (That is a reference to not
 even wrong).  Although there are only about 20 fake tokens now,
 there may be hundreds of not even fake variables.  I see these are
 low priority however, but I will probably rename them as I re-factor
 OpenGL code this summer.

 So, as a general question, what pitfalls do I need to look out for as
 if I rename things in Blender?

 The one thing I can think of is that I should be careful of DNA
 structures.   Another is I should avoid areas where large merge
 conflicts may occur.  Anything else?

 Sorry if this seems trivial, but it is usually the trivial things that
 you get in the most trouble for since everybody has an opinion :-)

 I am currently putting together a Blender OpenGL Programming Policy
 and Style Guide, and I'd like to reach a consensus on what will be in
 it before I get to the end of SoC and you all find out that I've
 implemented it all behind your backs :-)
 ___
 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 mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

[Bf-committers] new Linux install = svn woes

[Mike Erwin]

Hi all,

I just set up Linux Mint Debian, and get this error while attempting
to grab the latest bits:

merwin@dozer ~/blender/svn/trunk $ svn co
https://svn.blender.org/svnroot/bf-blender/trunk/blender .
WARNING: gnome-keyring:: couldn't connect to:
/tmp/keyring-M3FISK/pkcs11: No such file or directory
svn: OPTIONS of
'https://svn.blender.org/svnroot/bf-blender/trunk/blender':
Certificate verification error: signed using insecure algorithm
(https://svn.blender.org)

Any clues? Had no such problem with Xubuntu, but it died this weekend
after an upgrade.

Mike Erwin
musician, naturalist, pixel pusher, hacker extraordinaire
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Blender problem with libspnav

[Mike Erwin]

Should be fixed in revision 45951. Thanks for catching this!

Mike Erwin
musician, naturalist, pixel pusher, hacker extraordinaire


On Thu, Apr 19, 2012 at 10:09 AM, Richard Shaw hobbes1...@gmail.com wrote:
 Ok, looks like I broke something else I need your help with!

 I recently had the Fedora Blender maintainer add libspnav as a build
 dependency. Now when someone tries to start Blender but is not running
 or does not have spacenavd installed, Blender fails to start[1].

 I'm thinking Blender should handle this situation gracefully...

 Thanks,
 Richard

 [1] https://bugzilla.redhat.com/show_bug.cgi?id=812354#c10
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers