Re: [Bf-committers] move prebuilt libs from svn to git?

[Jacob Merrill via Bf-committers]

What about p2p?

Can we have users seed lib downloads?

On Fri, Jun 17, 2022, 9:11 AM Dan McGrath via Bf-committers <
bf-committers@blender.org> wrote:

> Hi,
>
> Really, I would need to see a capture from both sides to dig into it. I
> need to see what is being sent, and what is received on each side. There
> could be some weird firewall stuff happening that is causing fragmentation
> or blocking TCP options, or window scaling issues, etc.
>
> As for the default settings for tortoisesvn, the connection stuff I was
> referring to was about TCP/IP behaviour, rather than an application
> setting. Either way, I need to see what is actually happening. The fact
> that I can pull 5-8MB/sec (~40mbit) from Canada and not have a single
> interruption is telling. Granted, the host only has around 100 or 200mbit
> allocated, iirc. Multiply that by a few dozen people and you have a
> problem.
>
> For a simpler test, maybe try a large svn check, perhaps some old FreeBSD
> ports svn repo if you can find one, something also in .NL, and see how it
> goes, just to help eliminate your PC/firewall. Worst case scenario, you can
> also poke me in chat and we can try some server side and client side
> captures.
>
> TBH though, 1gig uplink just isn't a whole lot to serve our user base ;)
>
> On Fri, Jun 17, 2022 at 11:45 AM Tom M  wrote:
>
> > On Fri, Jun 17, 2022 at 5:20 AM Dan McGrath 
> > wrote:
> > >
> > > Hi Tom,
> > >
> > > Long time no see :)
> > >
> > > I did some tests from home and found that, aside from slow speeds, I
> was
> > able to checkout at least 5 or 6 gig of the bf-blender repo without error
> > or having to retransmit.
> >
> > Yeah, looks like I was mistaking really slow download of the larger
> > (.7 GB) libraries as freezing.  I was averaging about .3 MB/s.  I used
> > a different SVN client and saw that it was indeed downloading (the
> > sliksvn doesn't provide any feedback on files in progress, only once a
> > file completes) - It was taking about 40 minutes for each of the
> > larger files.  It did complete eventually after about 5 hours.
> >
> > > I took the liberty of packet capturing the stream from my PC's POV, and
> > placed them in the ftp download area[1], if you care to take a look.
> > >
> > > The gist is that I was able to get around 5MB/sec for at least 5G of
> the
> > checkout, before I cancelled it.
> > >
> > Interesting, I usually get up to 3 MB/s download here normally from
> > other sources, but was typically getting .3 MB/s, with occasional
> > bursts of higher speed to a max of .8 MB/s when it wasn't downloading
> > the large files.
> >
> > > Now, my IP is a bit of a special case, so I am wondering if you are
> just
> > hitting the server so hard with http requests in separate sockets, or
> > something extreme, that is causing the system to block you for a period
> of
> > time. For comparison, my PC only had about 4 sockets open to the server
> for
> > the transfer. I would be curious to know if you are doing pipelining, or
> > sending each request in a separate connection.
> > >
> > Whatever the sliksvn and tortoisesvn defaults are, I'd assume they are
> > setup for typical usage.
> >
> > > If you can, the next time it happens, see if you are unable to visit
> > Phabricator or resume the svn checkout process. It may not be a firewall
> > issue, but without seeing some packet captures, I wouldn't be able to
> > really guess. Ideally, try to capture a few packets, until failure. At
> the
> > very least, you will need to snap 20b+20b=40b for IP+TCP headers, but I
> > would suggest a tad higher, maybe 64b.
> > >
> > > Cheers,
> > >
> > > Dan
> > >
> > > [1] - https://download.blender.org/ftp/dan/svn-checkout/
> > >
> > >
> > >
> > > On Thu, Jun 16, 2022 at 2:43 PM Tom M via Bf-committers <
> > bf-committers@blender.org> wrote:
> > >>
> > >> When checking out the libraries from SVN following the directions on
> > >>
> > >> https://wiki.blender.org/wiki/Building_Blender/Windows
> > >>
> > >> The svn checkout of the libraries fails with significant frequency,
> > >>
> > >> if you google you might stumble across using make svnfix
> > >>
> > >>
> https://www.mail-archive.com/bf-blender-cvs@blender.org/msg151996.html
> > >>
> > >> Even after using it, I'm still having to do Ctrl C, and then make
> > >> svnfix repeatedly (it downloads some files, than randomly freezes,
> > >> sometimes after 20-50 files, sometimes after 100's of files).
> > >>
> > >> Git doesn't seem to have any problems, though.
> > >>
> > >> So might we consider migrating the libs to git, rather than using SVN?
> > >>
> > >> LetterRip
> > >> ___
> > >> Bf-committers mailing list
> > >> Bf-committers@blender.org
> > >> List details, subscription details or unsubscribe:
> > >> https://lists.blender.org/mailman/listinfo/bf-committers
> > >
> > >
> > >
> > > --
> > > Cheers,
> > > Danny
> > >
> > > --
> > > Danny McGrath - 

Re: [Bf-committers] Handling of user data.

[Jacob Merrill via Bf-committers]

What about popping up the outliner / orphan data window in quit, and
showing exclamation icon somewhere if there is a orphan

On Mon, May 16, 2022, 9:15 AM Harley Acheson via Bf-committers <
bf-committers@blender.org> wrote:

> I’d love to have someone flesh out this “warning on quit” idea, because I
> can’t imagine it actually
> working in practice.  Mostly because of confusion on what “saving” really
> means. Users should
> rightfully only consider that “saving their data” does exactly that, not
> that some of their data might
> differ and have to be “saved” in different ways.
>
> As its simplest, imagine that you have no unsaved changes in your file (you
> just did a File/Save)
> yet there is orphaned data at the time you select “Quit”.  What exactly
> does the warning say?
> “You have unlinked data that will be lost”?  How do you communicate to the
> user what they should
> do now?  Is there a way to offer to do it for them somehow, or is this
> warning going to just have an
> “Ignore” and “Cancel” button? Text that says “please mark anything you want
> to keep by marking
> the data with ‘fake user’”? That will not help a typical person being
> caught out by this
>
> Now imagine there are both unsaved changes and orphan data at the point of
> “quit”.  We now
> have to warn about unsaved changes that can be “saved” and there are other
> things that should
> be “saved” in a different way before you “save” so that they are actually
> “saved”. So we have a
> button to cancel, one to save the unsaved changes while ignoring orphan
> data, and what else
> is on the dialog?
>
> I'm not sure there is sufficient lipstick that can be put on this pig.
>
> Harley
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> List details, subscription details or unsubscribe:
> https://lists.blender.org/mailman/listinfo/bf-committers
>
___
Bf-committers mailing list
Bf-committers@blender.org
List details, subscription details or unsubscribe:
https://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Blender's math

[Jacob Merrill via Bf-committers]

lighting / shading has quite a bit to do with simulated light transport

inverse square falloff / vector.reflect() check the mathutils lib

tree structures are used to accelerate calculations like bvhtree, for ray
triangle intersection tests for things like cycles or even game physics,

geometry nodes are an amazing place to view / prototype math - so are eevee
shader nodes / cycles.


On Sat, Jan 22, 2022 at 7:16 AM Ivano Da Milano via Bf-committers <
bf-committers@blender.org> wrote:

> Hello everyone.
> Quick question, if you can help: what's the math behind Blender? I'm told
> analytic geometry and linear algebra, am I missing something or is it just
> like that? I mean the whole Blender, so 2/3D graphics, audio and video,
> nodes, animations, etc
>
> Note I'm looking for coarse definitions, like "calculus", or "analisys", or
> ...
>
> Thanks for any help.
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> List details, subscription details or unsubscribe:
> https://lists.blender.org/mailman/listinfo/bf-committers
>
___
Bf-committers mailing list
Bf-committers@blender.org
List details, subscription details or unsubscribe:
https://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] where to put a new modifier

[Jacob Merrill via Bf-committers]

I think* the plan is to make geometry nodes able to do all modifiers + new
ones

On Sat, Dec 4, 2021 at 6:23 PM bjornmose via Bf-committers <
bf-committers@blender.org> wrote:

> Hi all,
>
> Some years have passed since I coded something for blender. However.
>
> I'd like to refactor the soft body module. AFAIK it is preferred to do
> new things in C++. So I'd like to do so.
>
> After checking out the code and building on Lunix - system  a brief
> inspection of the code showed:
>
> There is no C++ prototype template for plugging in a new modifier.
>
> So I would kindly ask for a hint where to start with a new modifier.
>
> bjornmose
>
>
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> List details, subscription details or unsubscribe:
> https://lists.blender.org/mailman/listinfo/bf-committers
>
___
Bf-committers mailing list
Bf-committers@blender.org
List details, subscription details or unsubscribe:
https://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Blender 3.1 Preliminary Dates

[Jacob Merrill via Bf-committers]

Metal backend for cycles is a huge deal with the new m1 MAX having 64 gig
shared ram.

should render ultra fast as everything is able to fit in core.

On Tue, Nov 2, 2021 at 8:46 AM Bastien Montagne via Bf-committers <
bf-committers@blender.org> wrote:

> Hi Dalai,
>
> Since BCon2 is a fairly soft limit, and we do not plan to add that many
> new features in 3.1 (besides incremental improvements), I personally do
> not see a problem with it happening on 29th December?
>
> End of the year is always a fairly low-activity moment anyway, would be
> nice if this encouraged all modules to commit to master in first half of
> December, instead of the day before BCon2. ;)
>
> Cheers,
> Bastien
>
> On 11/2/21 4:35 PM, Dalai Felinto via Bf-committers wrote:
> > Hi,
> > I've updated the 3.1 project page [1] with a proposal for the Bcon dates:
> >
> > * Bcon1, New features and changes, October 27, 2021
> > * Bcon2, Improve and stabilize, December 29, 2021
> > * Bcon3, Bug fixing only, January 26, 2021
> > * Bcon4, Prepare release, March 2, 2021
> > * Bcon5, Release, March 9, 2021
> >
> > I basically added the corresponding weeks [2] based on when Bcon1
> started.
> > I'm not happy with Bcon2 happening during the Christmas holidays, and
> would
> > love to hear what the modules think.
> >
> > Note: I personally won't be around for the Bcon2 and the Bcon4 dates.
> >
> > [1] - https://developer.blender.org/project/view/135/
> > [2] - https://wiki.blender.org/wiki/Process/Release_Cycle
> >
> > Best regards,
> > -Dalai-
> > 
> > Dalai Felinto - da...@blender.org - www.blender.org
> > Blender Development Coordinator
> > Buikslotermeerplein 161, 1025 ET Amsterdam, the Netherlands
> > ___
> > Bf-committers mailing list
> > Bf-committers@blender.org
> > List details, subscription details or unsubscribe:
> > https://lists.blender.org/mailman/listinfo/bf-committers
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> List details, subscription details or unsubscribe:
> https://lists.blender.org/mailman/listinfo/bf-committers
>
___
Bf-committers mailing list
Bf-committers@blender.org
List details, subscription details or unsubscribe:
https://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Proxy Removal for Blender 3.0

[Jacob Merrill via Bf-committers]

can we get the current eevee shader string?

compile a shader to get drawn in the main loop?

with this  I can override the drawing of a object for sure.

On Thu, Sep 23, 2021 at 1:07 AM Hadrien Brissaud via Bf-committers <
bf-committers@blender.org> wrote:

> Fair enough, I just wanted to make sure we were talking about the same
> thing. I haven't tested drivers in linked materials since a few months, so
> if it does work I'm a happy man. I'm glad I can make use of those in
> upcoming projects. Thanks for all the clarification, have a good day,
>
> Hadrien
>
> On Thu, 23 Sept 2021 at 09:53, Bastien Montagne via Bf-committers <
> bf-committers@blender.org> wrote:
>
> > Hmmm, assigning a local copy of the material to an overridde object is
> > same issue basically (being complicated to get working), you either have
> > to override also the obdata, since by default materials are assigned to
> > obdata (meshes and the like), or change that later setting to assign
> > materials to objects (in your library file)... But this is tricky to get
> > working, order in which things get evaluated in RNA code also matters
> > etc. Mine field.
> >
> > The drivers on material properties should work though, since a few weeks?
> >
> > Cheers,
> > Bastien
> >
> > On 9/22/21 7:20 PM, Hadrien Brissaud wrote:
> > > Alright, good to see this is known already. For clarity's sake, by
> > > "overriding material" I didn't mean changing individual node
> > > properties and connections and such, but linking a completely
> > > different material on the object (usually a copy of the linked one). I
> > > didn't actually expect overrides to the node tree topology/properties
> > > to be supported, that sounds awfully complex. It is probably simpler
> > > to approach "material variations on linked assets" through drivers
> > > between the object's custom properties and its material, which so far
> > > doesn't work either -this is something that I tried during production
> > > and eventually resorted to local materials because those drivers would
> > > fail upon linking the character.
> > >
> > > Thanks for your reply, have a good evening
> > >
> > > Hadrien
> > >
> > >
> > > On Wed, 22 Sept 2021 at 10:43, Bastien Montagne via Bf-committers
> > > mailto:bf-committers@blender.org>> wrote:
> > >
> > > Hi Hadrien,
> > >
> > > Thanks for the feedback. Yes overrides of materials are still very
> > > unreliable, this is due to how materials are weirdly related to
> both
> > > Object and ObData IDs... not to mention that there is currently
> > > almost
> > > nothing overridable in materials anyway, so you would need to rely
> on
> > > tricks (drivers and custom properties) to get some properties
> > > editable etc.
> > >
> > > Time was lacking to address this issue for 3.0, it is a known TODO
> > > for
> > > the near future, together with some other annoying limitations.
> > >
> > > All development on liboverrides happens in master currently, no
> > > branch
> > > to try out.
> > >
> > > Cheers,
> > > Bastien
> > >
> > > On 9/21/21 7:15 PM, Hadrien Brissaud wrote:
> > > > Hi Bastien,
> > > >
> > > > as a user I am generally happy with overrides (thanks!!), except
> > > when
> > > > I need to override a material. Last I tested the behaviour was
> > > rather
> > > > unpredictable : an override was -seemingly- created, but on file
> > > > reload it would revert to the linked material instead, and the
> > > > override button was inoperative (greyed out). I will give this a
> > > round
> > > > of testing with latest master tonight, unless there is a specific
> > > > branch I should check out ? I'm a bit out of the loop.
> > > >
> > > > Cheers,
> > > >
> > > > Hadrien
> > > >
> > > > On Tue, 21 Sept 2021 at 16:32, Bastien Montagne via Bf-committers
> > > > mailto:bf-committers@blender.org>
> > >  > > >> wrote:
> > > >
> > > > Hi fellow users & developers
> > > >
> > > > Now that library overrides gained maturity and are production
> > > > ready in
> > > > the 'character animation' case (where they replace the old
> > > 'proxy'
> > > > system), it is time to think about removing those proxies.
> > > >
> > > > Plan is to commit in the coming days the following changes:
> > > >   - Add auto-conversion of proxies into library overrides on
> > > file
> > > > load;
> > > >   - Remove the 'make proxy' operator.
> > > >
> > > > For the time being, an option (OFF by default) will be added
> > > to the
> > > > 'Experimental' part of the User Preferences to skip
> converting
> > > > existing
> > > > proxies on file load. That way it is still possible to force
> > > keeping
> > > > proxies if absolutely 

Re: [Bf-committers] New developer coordinator: Thomas Dinges

[Jacob Merrill via Bf-committers]

Welcome Ding!

maybe we can find a way to pull in some of these good blender forks ;D


On Tue, Sep 14, 2021 at 7:40 AM Piotr Arłukowicz via Bf-committers <
bf-committers@blender.org> wrote:

> Congratulations!!!
>
> Perfect person and perfect welcome message! :) Long live BLENDER
>
>
> pio
>
> *Piotr Arłukowicz*, PhD, (BFCT 2013-2020)
> *UG MFI*, *II*, room *4.26*, ph +4858.523.3538,
> PL: *https://inf.ug.edu.pl/~piotao* 
>
>
> wt., 14 wrz 2021 o 16:01 Ton Roosendaal via Bf-committers <
> bf-committers@blender.org> napisał(a):
>
> > Hi everyone,
> >
> > Starting November 1st officially, Thomas Dinges will join the team as
> > full-time developer community coordinator. In that role he will work
> > alongside Dalai Felinto, with as main focus to assist all module teams
> > where needed. He will help with docs, on-boarding, planning,
> > communication, recruitment, project coordination, and so on.
> >
> > Thomas is a regular in blender's chat channels, devtalk, the developer
> > site, on twitter and here on the mailing lists. Good communication is
> > essential for that role! To set an example, here's his heartfelt
> > 'welcome back' video.
> >
> > https://www.youtube.com/watch?v=Lm6_tgNsfjw
> >
> > Great to see you again Thomas!
> >
> > -Ton-
> >
> > --
> > Ton Roosendaal - t...@blender.org - www.blender.org
> > Chairman Blender Foundation, CEO Blender Institute / Studio
> > Buikslotermeerplein 161, 1025 ET Amsterdam, the Netherlands
> >
> >
> > ___
> > Bf-committers mailing list
> > Bf-committers@blender.org
> > List details, subscription details or unsubscribe:
> > https://lists.blender.org/mailman/listinfo/bf-committers
> >
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> List details, subscription details or unsubscribe:
> https://lists.blender.org/mailman/listinfo/bf-committers
>
___
Bf-committers mailing list
Bf-committers@blender.org
List details, subscription details or unsubscribe:
https://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Blender developer week notes - 2021.07.05

[Jacob Merrill via Bf-committers]

I feel like a bit of a broken record - but in geo nodes, we don't have the
ability to transform a vector into localspace for a object, or back to
world space using the object matrix.

in py

local_vec3_out = bpy_object.matrix_world.inverted() @ vec_3_in_world_point


world_vec3_out = bpy_object.matrix_world @ vec_3_in_local_position

(this is important for a number of operations*)





On Mon, Jul 5, 2021 at 11:33 AM Dalai Felinto via Bf-committers <
bf-committers@blender.org> wrote:

> Hi all,
>
> Here are the compiled notes for this week's development. For the complete
> report with modules and projects updates, links and images read it on:
> https://devtalk.blender.org/t/5-july-2021/19404
>
> Announcements
> =
> Asset Browser Workshop Outcomes [1]
>
> Modules and Projects
> 
> Geometry Nodes - the current design challenge is to figure out the best way
> to access the attributes inside the nodetree:
>
> * Thoughts and Use Cases for Passing Attribute Columns [2]
> * Attributes Sockets and Geometry Nodes 2.0 [Proposal] [3]
> * Fields and Anonymous Attributes [Proposal] [4]
>
> [1] - https://code.blender.org/2021/06/asset-browser-workshop-outcomes/
> [2] -
>
> https://devtalk.blender.org/t/thoughts-and-use-cases-for-passing-attribute-columns/19411
> [3] -
>
> https://devtalk.blender.org/t/attributes-sockets-and-geometry-nodes-2-0-proposal/19459
> [4] -
>
> https://devtalk.blender.org/t/fields-and-anonymous-attributes-proposal/19450
>
> -Dalai-
> 
> Dalai Felinto - da...@blender.org - www.blender.org
> Blender Development Coordinator
> Buikslotermeerplein 161, 1025 ET Amsterdam, the Netherlands
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> List details, subscription details or unsubscribe:
> https://lists.blender.org/mailman/listinfo/bf-committers
>
___
Bf-committers mailing list
Bf-committers@blender.org
List details, subscription details or unsubscribe:
https://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Buildbot Update - June 18, 2021

[Jacob Merrill via Bf-committers]

Thanks for all you do!


On Fri, Jun 18, 2021 at 8:09 AM James Monteath via Bf-committers <
bf-committers@blender.org> wrote:

> Hi all,
>
> Buildbot has been updated.
> https://builder.blender.org/admin/#/builders
>
> Notable changes on the Wiki.
> https://wiki.blender.org/wiki/Infrastructure/BuildBot#Notable_Changes
>
> --
> James Monteath - ja...@blender.org - www.blender.org
> Blender DevOps Engineer
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> List details, subscription details or unsubscribe:
> https://lists.blender.org/mailman/listinfo/bf-committers
>
___
Bf-committers mailing list
Bf-committers@blender.org
List details, subscription details or unsubscribe:
https://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Release planning update - Blender 3.0 later

[Jacob Merrill via Bf-committers]

First off I want to say thank you.


I have been using EEVEE render for realtime / teaching physics and coding
and the progress is amazing,
but there are 2 things that need priority for the release or at least to be
placed on the roadmap.

there has been talk about open subdivision living 'after the stack' on the
GPU - but also being available as a modifier (slower - but compatible)

I believe the same concept should apply to GPU armature skinning - or
slower but 'stack compatible' - armature modifier

also - https://developer.blender.org/T88331 - alpha hash has some issues
for realtime that are easily amended . ---
___
Bf-committers mailing list
Bf-committers@blender.org
List details, subscription details or unsubscribe:
https://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Are there any small patches I could try out?

[Jacob Merrill via Bf-committers]

I would take something you may want to work on
like eevee, or depsgraph, or cycles, and take time and understand how it
works,
and then look at right_click_select and try implementing stuff,

even if it never gets submitted it's a good practice to start thumbing
through the code
some of these may be pretty easy.

https://blender.community/c/rightclickselect/

blender.chat 
also go to #blender-coders and hang around (quietly) and solve stuff if you
can.
I am too noisy :(


if you liked the old bge
https://github.com/UPBGE/upbge


On Wed, Mar 31, 2021 at 3:24 PM Toni Alatalo via Bf-committers <
bf-committers@blender.org> wrote:

> bleh sorry, too bad no undo in email, just noticed that you had checked
> that already.
>
> I don't have suggestions beyond that .. maybe you can test making some very
> simple changes to some part of the functionality you know, maybe add some
> menu entry just as a test etc.
>
> It's true that fixing actual bugs easily requires quite a lot of knowledge
> about the codebase etc.
>
> On Thu, Apr 1, 2021 at 1:21 AM Toni Alatalo  wrote:
>
> > Hi - there is a tag for that in the tracker, which collects potential
> > tasks nicely:
> > https://developer.blender.org/tag/good_first_issue/
> >
> > It was made I think a few years ago but seems to be nicely active with
> > updates from yesterday etc.
> >
> > -Toni
> >
> > On Wed, Mar 31, 2021 at 5:34 PM Hyunseo Cho via Bf-committers <
> > bf-committers@blender.org> wrote:
> >
> >> Hi!
> >>
> >> I'm completely new to Blender development but have some coding
> experience.
> >> I have also managed to build Blender on my device and have been looking
> >> over the source code. I would like to get started with a small, quick
> >> patch
> >> (aka Janitor work) just to get used to the process- but even the bugs
> >> listed in "good first issues" seem difficult for me at this point. Are
> >> there any suggestions for something I could try?
> >>
> >> Thanks,
> >> Hyunseo (Ashley) Cho
> >> ___
> >> 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] Proposal: Export extensions for better integration with game engines.

[Jacob Merrill via Bf-committers]

Upbge fork has object property's restored, and they are used on UPBGE in
game,

You could use this as a basis, it's kept in sync with blender master.

Upbge.org

On Thu, Mar 4, 2021, 3:46 PM Juan Linietsky via Bf-committers <
bf-committers@blender.org> wrote:

> We can probably pull request this functionality into Blender ourselves, or
> at least generate a detailed proposal but for this I would like to see if
> Blender contributors can agree that this is something wanted and how it
> would be wanted.
>
> Best
>
> Juan
>
>
> On Thu, Mar 4, 2021 at 8:43 PM Juan Linietsky  wrote:
>
> > As I mentioned before, the problem with using properties, even if hidden,
> > is that having this information persistent serves no purpose.
> > I understand that Blender can save it (with an option), but there is no
> > point in generating this information at any other time than saving the
> > exported scene..
> >
> > This is why, the Ideal API use case for this is every exporter calling
> > some sort of new internal function that asks export metadata plugins to
> > generate this information, at export time and during the export process.
> >
> > I am a bit unfamiliar nowadays with Blender internals, but I can ask
> other
> > Godot contributors to create a more specific proposal for this.
> >
> > Juan
> >
> >
> > On Thu, Mar 4, 2021 at 6:33 PM Toni Alatalo  wrote:
> >
> >> Fair points, thanks. BTW if there is an issue on the web or something
> for
> >> this, am happy to study more there and maybe have extended discussions,
> >> don't want to flood the list with learning the basics about this.
> >>
> >> I was thinking, that if you need additional meta-data, you could maybe
> >> have hidden custom properties, if they are for the export code only, and
> >> not meant to be user facing. I don't know if Blender supports hiding
> custom
> >> props nor whether I'd make sense. Maybe would work for the UUIDs for
> >> example.
> >>
> >> Now when you say that it's at export time, and with data that already
> >> exists in Blender, I fail to see why an exporter can't do what you want
> >> then.
> >>
> >> So what is it that you are proposing exactly? Some kind of additional
> API
> >> to Blender that would support getting info nicely for exporters?
> >>
> >> Exporters already are 'metadata export plugins' and can do whatever is
> >> necessary AFAIK. Of course if there is something missing in the API that
> >> exporters need it's possible to add.
> >>
> >> Anyway I think those were my points and I go silent here now to not spam
> >> with clueless questions :)
> >>
> >> -Toni
> >>
> >>
> >>
> >> On Thu, Mar 4, 2021 at 11:24 PM Juan Linietsky 
> wrote:
> >>
> >>> So how is this not custom properties?
> 
> >>>
> >>> I don't think custom properties are the best for this use-case
> scenario,
> >>> for the following reasons:
> >>>
> >>> * You need to generate this data *on export*. As an example, if you
> >>> edited the material nodes in Blender, you would only want to generate a
> >>> target engine shader at the time you are exporting the file, as this
> can be
> >>> a costly process. Doing it at any other time is unnecessary and
> inefficient.
> >>> * Custom properties are meant to be *user-facing*, there is zero
> >>> benefit in users seeing data meant *for the exporter*.
> >>> * Again remember, the use of this is to take data that *already exists
> >>> in blender* (not that was created by the user) and send it to a game
> >>> engine. It's a different use case (and hence, feature).
> >>>
> >>> Juan
> >>>
> >>>
> >>> On Thu, Mar 4, 2021 at 3:53 PM Toni Alatalo via Bf-committers <
> >>> bf-committers@blender.org> wrote:
> >>>
>  So how is this not custom properties?
> 
> 
> https://docs.blender.org/manual/en/latest/files/data_blocks.html#custom-properties
> 
>  On Thu, Mar 4, 2021 at 8:05 PM Juan Linietsky via Bf-committers <
>  bf-committers@blender.org> wrote:
> 
>  > Hi Everyone!
>  >
>  >Most exporters are working fantastic nowadays in Blender, so on
> the
>  > Godot Engine side, we are trying to figure how better to improve our
>  > experience to users when going back and forth between Blender and
>  Godot.
>  >
>  >So, this proposal consists on a very (pre-discussed) list of
>  topics that
>  > we would be glad to work together in ensuring Blender can support
>  these
>  > somehow (which should hopefully happen with minimal effort).
>  >
>  >The main topic is the ability for Blender to have a "Metadata
>  Export"
>  > plugin. This means, that at the time of export,and for each object
>  exported
>  > (node, material, skeleton, mesh, etc) Blender should be able to ask
>  for
>  > "metadata" to the export plugins. Export plugins can then return
>  generic
>  > metadata (Strings or what you believe is best) to embed in exported
>  scenes.
>  >
>  >   Here are use cases where these type of plugins would 

Re: [Bf-committers] No Monday or Tuesday meetings for the time being

[Jacob Merrill via Bf-committers]

Some effort needs to be made to fix rocketchats history jumping, and bad
mention jumping etc.

It makes it a bit hard to even get caught up on chats one misses.

On Tue, Mar 2, 2021, 11:11 PM Ryan Inch via Bf-committers <
bf-committers@blender.org> wrote:

> It seems to me that you are still having drop in pseudo-meetings on
> Mondays, just not advertising them.
> I understand that if something doesn't work it needs to be reevaluated
> and changed, but the meetings are an important outreach to the community
> and a chance for developers to bring up issues (both internal devs and
> community devs) that need wider discussion (such as GSoC).
>
> If having a meeting at a specific time is too restrictive then perhaps
> Mondays should become an official (and advertised) "meeting day" and
> then anyone can chime in throughout the day, new developers can be
> announced, issues brought up, etc...  This should help encourage
> participation from the community.  And perhaps a Google Doc (or
> equivalent) could be maintained as a list of issues/points to be
> considered during the day (open to the community to add issue/point
> suggestions) and updated as the day progresses.
>
> Hopefully this shows that weekly meetings are still valued by the
> community and can be improved so that they are valuable for everyone to
> attend.
>
> Thank you for your consideration.
> Ryan
>
> On 2021-02-09 06:00 AM, bf-committers-requ...@blender.org wrote:
> > Send Bf-committers mailing list submissions to
> >   bf-committers@blender.org
> >
> > To subscribe or unsubscribe via the World Wide Web, visit
> >   https://lists.blender.org/mailman/listinfo/bf-committers
> > or, via email, send a message with subject or body 'help' to
> >   bf-committers-requ...@blender.org
> >
> > You can reach the person managing the list at
> >   bf-committers-ow...@blender.org
> >
> > When replying, please edit your Subject line so it is more specific
> > than "Re: Contents of Bf-committers digest..."
> >
> >
> > Today's Topics:
> >
> > 1. No Monday or Tuesday meetings for the time being (Dalai Felinto)
> > 2. Re: No Monday or Tuesday meetings for the time being
> >(Ray Molenkamp)
> >
> >
> > --
> >
> > Message: 1
> > Date: Mon, 8 Feb 2021 17:33:28 +0100
> > From: Dalai Felinto 
> > To: bf-blender developers 
> > Subject: [Bf-committers] No Monday or Tuesday meetings for the time
> >   being
> > Message-ID:
> >h7...@mail.gmail.com>
> > Content-Type: text/plain; charset="UTF-8"
> >
> > Hi,
> > The Monday (developers) and the Tuesday (modules) meetings are currently
> on
> > hold. The Monday one has very little quorum and is rarely useful.
> >
> > The Tuesday talks (module meetings) are quite a joy actually and I will
> > miss talking to the modules owners 1:1. But they have always being more
> > like a  healthy check then a permanent solution. What we need instead is
> to
> > make sure the modules are properly structured and can operate
> autonomously.
> > But this is a separate topic.
> >
> > I have a new idea on how to do the weekly communication of the ongoing
> > module and projects:
> >
> > * We keep the weekly online page in devtalk for the weekly notes [1].
> > * Developers keep adding their weekly reports there.
> > * Everyone adds relevant announcements there
> > * [new] Modules and projects then add their notes there as well,
> > asynchronously.
> > * [new] At the end of Mondays I do a final pass in the page and post it
> > here.
> >
> > [1] - https://devtalk.blender.org/t/15-february-2021-upcoming/17475.
> >
> > Any feedback is welcome.
> >
> > Best regards,
> > -Dalai-
> > 
> > Dalai Felinto - da...@blender.org - www.blender.org
> > Blender Development Coordinator
> > Buikslotermeerplein 161, 1025 ET Amsterdam, the Netherlands
> >
> >
> > --
> >
> > Message: 2
> > Date: Mon, 8 Feb 2021 09:45:11 -0700
> > From: Ray Molenkamp 
> > To: bf-committers@blender.org
> > Subject: Re: [Bf-committers] No Monday or Tuesday meetings for the
> >   time being
> > Message-ID: <036450a5-c108-c588-0766-e60cc14d4...@lazydodo.com>
> > Content-Type: text/plain; charset=utf-8
> >
> > That seems somewhat strange and out of the blue (at least for me), the
> lack of reasoning for putting them on hold especially for the Tuesday ones
> you seem fond of is concerning, what am i missing here?
> >
> > --Ray
> >
> > On 2021-02-08 9:33 a.m., Dalai Felinto via Bf-committers wrote:
> >> Hi,
> >> The Monday (developers) and the Tuesday (modules) meetings are
> currently on
> >> hold. The Monday one has very little quorum and is rarely useful.
> >>
> >> The Tuesday talks (module meetings) are quite a joy actually and I will
> >> miss talking to the modules owners 1:1. But they have always being more
> >> like a  healthy check then a permanent solution. What we need 

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

[Jacob Merrill via Bf-committers]

Is there any concern for animation speedups in the long term or short term?

CPU armature skinning is very very slow for playblasts,
everything else is top notch.
___
Bf-committers mailing list
Bf-committers@blender.org
https://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Science visualisation: Blender + ANARI

[Jacob Merrill via Bf-committers]

A network could be represented by vertex at each neuron, and edges
connecting them
the data itself would not render as it has no faces, instead particles
could be instanced to represent each neuron,
and I think animation node systems could be abused to make particles flow
from instance to instance.

On Thu, Nov 5, 2020 at 4:53 AM Brecht Van Lommel via Bf-committers <
bf-committers@blender.org> wrote:

> ANARI was brought up in the latest rendering meeting. Blender is not
> actively involved in it.
> https://devtalk.blender.org/t/2020-11-3-blender-rendering-meeting/16020
>
> ANARAI is not designed to do what you describe though. It is a rendering
> API, that would sit between a tool like Blender or Paraview, and a renderer
> like Cycles or OSPRay. Similar to Hydra or the RenderMan Interface. It
> would not be used for importing a neural model into Blender.
>
>
> On Thu, Nov 5, 2020 at 11:11 AM Mateusz Grzeliński via Bf-committers <
> bf-committers@blender.org> wrote:
>
> > Hello,
> >
> > I am in the middle of researching possibilities of
> > visualization and interaction with neural networks (graph based
> > structures) in 3d environment, just a project connected with studies.
> >
> > I came upon quite new project called ANARI - Analytic Rendering
> > Interface for Data Visualization. Long story short, it is meant to be a
> > bridge connecting data and visualization in standarized ways:
> >
> > data -> ANARI -> any visualization tool
> >
> > So in my case:
> >
> > neural model -> ANARI -> Blender
> >
> > The ANARI project (owned by Khronos group) is still under development
> > thus kept private.
> > Recently Ton announced that Blender is a member of Khronos group. I am
> > not asking for access, that would be a lot to ask, but still I wonder
> > if anyone from Blender participates in development of ANARI? Any plans
> > or thoughts about it?
> >
> > Blender seems to be used quite often in science vis and ANARI seems to
> > be next big thing.
> >
> > As ANARI is still kept private I will probably need to use different
> > toolchain for my project :( Now I can appreciate open nature of
> > Blender.
> >
> > Regards,
> > Mateusz Grzeliński
> >
> > Those are pretty much the only public resources about ANARI:
> > * ANARI overview: https://www.khronos.org/anari
> > * ANRI Q webinar (recording and presentation):
> >
> >
> https://www.khronos.org/blog/want-to-learn-how-graphics-vendors-will-use-the-anari-api-to-enable-rendering-technologies-anari-webinar-qa
> >
> >
> > ___
> > 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 developer meeting notes - 2020.7.20

[Jacob Merrill via Bf-committers]

I was wondering about the AOV patch for eevee
this is a very nice feature and it appears near completion,

could this be put at the bottom of a workboard?

On Mon, Jul 20, 2020 at 10:13 AM Dalai Felinto via Bf-committers <
bf-committers@blender.org> wrote:

> Hi all,
>
> Here are the notes from today's developer meeting. Next meeting is Monday,
> 27 July 11:00 CEST / 9:00 UTC, in #blender-coders on blender.chat.
>
> For the complete report read it on:
> https://devtalk.blender.org/t/20-july-2020/14364
>
> ---
>
> Blender 2.90 bcon3 still scheduled for July 22.
> * There will be no splashscreen ready for bcon3/beta.
> * List of targets is updated (some were marked as done because they were
> postponed or non blocking (particle nodes, Cycles sampling patch)).
>
> Patches that are blocking for bcon3 and need final review and to be
> committed:
>  * Multires modifier layout - D8187
>  * VR scene inspection add-on updates - T78997
>
> Patches that need final review/committed or postponed:
> * EEVEE: GLSL refactor/cleanup - D8306
> * Modifier option to preserve and interpolate custom normals - D6935
> * Use consistent layout for custom operator UI - D8326
>
> Features with undefined status:
> * Add Object Tool
>
> Antonio Vazquez to decide on the SVG I/O feature - it won’t be complete to
> 2.90 so it is either postponed or released in a known weak state.
>
> Dalai Felinto to organize the 2.90 workboard to make the release status
> more clear - there are too many tasks on the backlog. Some of the TODO
> tasks are bugs, so not bcon3 blocking features.
>
> Julian Eisel suggests bcon3 may need to be postponed, but to be seen based
> on the pending tasks in the workboard once it is organized.
>
>
> -Dalai-
> 
> Dalai Felinto - da...@blender.org - www.blender.org
> Blender Development Coordinator
> ___
> 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 developer meeting notes - 2020.7.20

[Jacob Merrill via Bf-committers]

realized I forgot to link to the patch -
https://developer.blender.org/D7010


On Mon, Jul 20, 2020 at 10:16 AM Jacob Merrill 
wrote:

> I was wondering about the AOV patch for eevee
> this is a very nice feature and it appears near completion,
>
> could this be put at the bottom of a workboard?
>
> On Mon, Jul 20, 2020 at 10:13 AM Dalai Felinto via Bf-committers <
> bf-committers@blender.org> wrote:
>
>> Hi all,
>>
>> Here are the notes from today's developer meeting. Next meeting is Monday,
>> 27 July 11:00 CEST / 9:00 UTC, in #blender-coders on blender.chat.
>>
>> For the complete report read it on:
>> https://devtalk.blender.org/t/20-july-2020/14364
>>
>> ---
>>
>> Blender 2.90 bcon3 still scheduled for July 22.
>> * There will be no splashscreen ready for bcon3/beta.
>> * List of targets is updated (some were marked as done because they were
>> postponed or non blocking (particle nodes, Cycles sampling patch)).
>>
>> Patches that are blocking for bcon3 and need final review and to be
>> committed:
>>  * Multires modifier layout - D8187
>>  * VR scene inspection add-on updates - T78997
>>
>> Patches that need final review/committed or postponed:
>> * EEVEE: GLSL refactor/cleanup - D8306
>> * Modifier option to preserve and interpolate custom normals - D6935
>> * Use consistent layout for custom operator UI - D8326
>>
>> Features with undefined status:
>> * Add Object Tool
>>
>> Antonio Vazquez to decide on the SVG I/O feature - it won’t be complete to
>> 2.90 so it is either postponed or released in a known weak state.
>>
>> Dalai Felinto to organize the 2.90 workboard to make the release status
>> more clear - there are too many tasks on the backlog. Some of the TODO
>> tasks are bugs, so not bcon3 blocking features.
>>
>> Julian Eisel suggests bcon3 may need to be postponed, but to be seen based
>> on the pending tasks in the workboard once it is organized.
>>
>>
>> -Dalai-
>> 
>> Dalai Felinto - da...@blender.org - www.blender.org
>> Blender Development Coordinator
>> ___
>> 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 developer meeting notes - 2020.3.23

[Jacob Merrill via Bf-committers]

Thank you !

amazing work everyone !

On Mon, Mar 23, 2020 at 8:26 AM Dalai Felinto via Bf-committers <
bf-committers@blender.org> wrote:

> Hi,
>
> > Could we have a list of these?
>
> I was referring to:
> - Volume object
> - Undo
> - Multires
> - VR
>
>
> -Dalai-
> 
> Dalai Felinto - da...@blender.org - www.blender.org
> Blender Development Coordinator
>
> Em seg., 23 de mar. de 2020 às 16:14, Jacob Merrill via Bf-committers
>  escreveu:
> >
> > * All the main projects were merged in time for bcon2
> >
> > could we have a list of these?
> >
> > On Mon, Mar 23, 2020 at 3:30 AM Dalai Felinto via Bf-committers <
> > bf-committers@blender.org> wrote:
> >
> > > Hi all,
> > >
> > > Here are the notes from today's developer meeting. Next meeting is
> > > Monday, 30 March 18:00 CEST / 10:00 UTC, in #blender-coders on
> > > blender.chat.
> > >
> > > For the complete report read it on:
> > > https://devtalk.blender.org/t/23-march-2020/12237
> > >
> > > Announcements
> > > 
> > > * Central European Summer Time starts on Sunday, March 30th. Next
> > > development meeting is at 18h CEST (16h CEST).
> > >
> > > Blender 2.83
> > > ==
> > > * All the main projects were merged in time for bcon2.
> > > * The dates moved a week ahead. New dates are:
> > >- bcon3: 15 April
> > >- bcon4: 13 May
> > >- Release: 20 May
> > > * Developers to create devtalk.blender.org threads for user feedback
> > > on the new features.
> > >
> > > Google Summer of Code
> > > ===
> > > * The calendar didn’t change, so students still have until the March
> > > 31st to send their proposals.
> > > * If a student needs feedback create a thread on devtalk under GSoC
> > > and poke developers this week still.
> > >
> > > -Dalai-
> > > 
> > > Dalai Felinto - da...@blender.org - www.blender.org
> > > Blender Development Coordinator
> > > ___
> > > Bf-committers mailing list
> > > Bf-committers@blender.org
> > > https://lists.blender.org/mailman/listinfo/bf-committers
> > >
> > ___
> > Bf-committers mailing list
> > Bf-committers@blender.org
> > https://lists.blender.org/mailman/listinfo/bf-committers
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> https://lists.blender.org/mailman/listinfo/bf-committers
>
___
Bf-committers mailing list
Bf-committers@blender.org
https://lists.blender.org/mailman/listinfo/bf-committers

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

[Jacob Merrill via Bf-committers]

* All the main projects were merged in time for bcon2

could we have a list of these?

On Mon, Mar 23, 2020 at 3:30 AM Dalai Felinto via Bf-committers <
bf-committers@blender.org> wrote:

> Hi all,
>
> Here are the notes from today's developer meeting. Next meeting is
> Monday, 30 March 18:00 CEST / 10:00 UTC, in #blender-coders on
> blender.chat.
>
> For the complete report read it on:
> https://devtalk.blender.org/t/23-march-2020/12237
>
> Announcements
> 
> * Central European Summer Time starts on Sunday, March 30th. Next
> development meeting is at 18h CEST (16h CEST).
>
> Blender 2.83
> ==
> * All the main projects were merged in time for bcon2.
> * The dates moved a week ahead. New dates are:
>- bcon3: 15 April
>- bcon4: 13 May
>- Release: 20 May
> * Developers to create devtalk.blender.org threads for user feedback
> on the new features.
>
> Google Summer of Code
> ===
> * The calendar didn’t change, so students still have until the March
> 31st to send their proposals.
> * If a student needs feedback create a thread on devtalk under GSoC
> and poke developers this week still.
>
> -Dalai-
> 
> Dalai Felinto - da...@blender.org - www.blender.org
> Blender Development Coordinator
> ___
> 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] Taking a break to recover!

[Jacob Merrill via Bf-committers]

Get Well Soon Ton,

https://www.google.com/url?sa=i=https%3A%2F%2Fgiphy.com%2Fgifs%2Fdisney-big-hero-6-baymax-hiro-Lb3vIJjaSIQWA=AOvVaw0DmIk2yT5EjFW2z4jrLJd9=1583507557928000=images=vfe=0CAIQjRxqFwoTCJC9zL7Pg-gCFQAdABAD

Best Regards,
Jacob Merrill


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

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

[Jacob Merrill]

>
> what about accelerating picking, (BVHTREE stuff) - and accelerating
> writing data - (SIMD stuff)


 from what I understand
"lowest level tree" faces own sub faces, each subdivision level adds
another layer of depth to the quadtree.

'picking' the low level faces then automatically scrapes the next level and
beyond and puts it in a bucket with it's distance from the pick point
already computed.

Kdtree returns points in order of distance, I am not sure about bvhtree -
but having the quadtree do this could make it fast no?


when a 'stroke' happens it can roll through this data in order per "low
level face" and apply equations to the data (sculpt etc) and bail each time
the distance is too far
so initially we are not comparing the point vs every other point, instead
we are comparing the sculpt point only to the lowest level faces.
___
Bf-committers mailing list
Bf-committers@blender.org
https://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Blender 2.82 bcon2

[Jacob Merrill]

is there a expected integration of everything nodes in the next release
after this one?

what about RTX features for eevee?

thanks all,
great work!


On Mon, Dec 16, 2019 at 8:17 AM Dalai Felinto  wrote:

> Hi everyone,
> We are now officially in 2.82 bcon2 [1].
>
> "Work to improve, optimize and fix bugs in new and existing features. Only
> smaller and less risky changes should be made in this phase."
>
> Many features made in the last minute. While it is exciting to see, this is
> far from ideal. Not only this adds extra stress to our team (kudos for the
> reviewers), it also leads to less tested features. They are also
> severely under-documented.
>
> Some of this is due to legacy projects that have been dragging for too long
> and organized in huge patch changes. Moving forward I hope we can give the
> projects a more manageable structure [2]. We are trying this with VR
> (postponed by the way), and the USD project [3] (just in). Things working
> well I would like to roll this out to the other new and existing projects.
>
> That aside, great work everyone. Blender 2.82 bcon3 starts in January 9,
> 2020. Good testing/polishing/bug hunting everyone.
>
> [1] https://wiki.blender.org/wiki/Process/Release_Cycle
> [2] https://wiki.blender.org/wiki/User:Dfelinto/Drafts/Projects
> [3] https://developer.blender.org/T72204
>
> Regards,
> Dalai
> ___
> 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] Modules simplification (and members cleanup)

[Jacob Merrill]

I would be interested in being a non-dev module member for the viewport /
eevee

On Wed, Nov 20, 2019 at 7:15 AM Sybren A. Stüvel  wrote:

> On 20-11-19 15:39, Julian Eisel wrote:
> > One thing that Sybren pointed out is that we should have a very
> > precise definition of the roles first. Let's make misunderstandings
> > hard. Then we can come up with suiting names.
>
> Yup. I see too many discussions go back and forth between defining names
> for the roles and defining the roles themselves.
>
> I think Blender would benefit from a bit more scientific approach to how
> we name things and how we write things down. In a (well-written)
> scientific paper, one would use clearly defined terminology, either as
> defined in other papers or by including the definition in the paper
> itself. This I think applies to Blender as wel. There are many places
> where the terminology is unclear, from the definition of roles to terms
> in the user interface (just to name one example, the word "tweak" is
> used a lot in the UI, but, until recently, was not defined anywhere). If
> we want to make Blender more welcoming to new developers, ensuring that
> they can actually understand and speak the same language as established
> developers seems like a good idea.
>
> Don't get me wrong, I'm not saying we should all stop working and give
> this full priority. I do feel that this could be gradually improved,
> though, and should be an area that gets attention during code &
> documentation reviews.
>
> > 1) Member
> > With the definition you just gave for that role it sounds like a
> > reasonable one. Just one question: Aren't they responsible for making
> > decisions too?
>
> I think we should distinguish between "capable" and "responsible". AFAIK
> module members are capable of making decisions, but the
> owner/coordinator is the one with the final say in things, i.e.
> responsible for the final outcome.
>
> I agree with your other points :)
>
> --
> dr. Sybren A. Stüvel
>
> Blender Software Developer
>
> https://blender.org/
> https://cloud.blender.org/
>
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> https://lists.blender.org/mailman/listinfo/bf-committers
>
___
Bf-committers mailing list
Bf-committers@blender.org
https://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Blender Developer Meeting Notes 18 November 2019

[Jacob Merrill]

What release do you think hypersomniacs batching optimizations will land in?

On Mon, Nov 18, 2019 at 8:24 AM Dalai Felinto  wrote:

> The full report with the weekly report links is:
> https://devtalk.blender.org/t/18-november-2019/10470
>
> Em seg., 18 de nov. de 2019 às 10:37, Nathan 'jesterKing' Letwory <
> nat...@blender.org> escreveu:
>
> > Notes for meeting of Monday, 18 November 10:00 CET / 9:00 UTC on
> > #blender-coders on blender.chat.
> >
> > Blender 2.81
> > 
> >
> > * Remaining non-showstopper bugs moved from 2.81 to 2.82
> >   workboard.
> > * Note to all devs: no commits to blender-v2.81-release branch,
> >   unless for a scheduled critical bug.
> > * Landing of splash, tagging and Ahoy on Wednesday November 20th.
> >   Release will happen later in the afternoon.
> > * Windows builds will be created on the buildbot, including
> >   signing. MacOS builds will be signed still out-of-buildbot.
> >
> > Blender 2.82
> > 
> >
> > * Proposals and patches for new features should be submitted and
> >   handled by December 12th, 2019.
> > * MantaFlow and LANPR are in good shape, but need still help to
> >   get through the review process so that patches can land.
> > * Undo speed-up (re-)using depsgraph progressing.
> > * Library overrides get improvements.
> > * Assets may get some partial patches applied.
> > * GPencil improvements.
> > * Sculpting improvements.
> > * Integrate rest of buildbot release building features
> >   (codesigning, notarization).
> >
> > Changes And New Features
> > 
> >
> > Blender 2.81
> > 
> >
> > * A dozen fixes.
> >
> > Blender 2.82
> > 
> >
> > * Add TBB allocator support on Windows. (Ray Molenkamp)
> > * GPencil MultiStroke Modifier that creates multiple strokes
> >   around original stroke. (Yiming Wu, Antonio Vazquez)
> >
> > Have a good week!
> >
> > /Nathan Letwory
> > ___
> > 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] BConf VR Meeting Notes

[Jacob Merrill]

one interesting thing would be to be able to 'open' a shader node graph as
a pop up over a object / collapse it

same with logic nodes etc later.

I think the concept of 'compartments' inside objects could control most of
the ui.

like a shelf could hold tools,  and the tools could be adjusted using
widgets inside nested folders in the object.
one nice thing about this is you could have 10 versions of 1 tool in a
drawer, almost like brushes.


On Fri, Nov 1, 2019 at 10:44 AM Dalai Felinto  wrote:

> Hi Adriano,
>
> The VR project has little overlap with the EEVEE stereo requirements.
>
> The only place they share some common requirements, is in regard to fisheye
> support in the viewport. For EEVEE panorama/fisheye we need to map the
> mouse with the pointer in the projected image. For VR we need something
> similar to map 3d controllers to sculpting, drawing, ...
>
> Regards,
> Dalai
>
> Em sex, 1 de nov de 2019 às 10:01, Adriano Oliveira <
> adriano.u...@gmail.com>
> escreveu:
>
> > Great news!
> >
> > Will this in some way addres an aproach to allow Eevee to export stereo
> > panoramas/cubes with screen space effects support?
> >
> > In raster renders this is usually accomplished by composing a lot of thin
> > render slices. That can be done by an addon, but I think it would be more
> > optmimizad in blender code.
> >
> > This can help:
> > https://developers.google.com/vr/jump/rendering-ods-content.pdf
> >
> > *Adriano A. Oliveira*
> >
> >
> > <
> >
> https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail
> > >
> > Livre
> > de vírus. www.avast.com
> > <
> >
> https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail
> > >.
> > <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
> >
> > Em ter, 29 de out de 2019 às 08:21, Julian Eisel 
> > escreveu:
> >
> > > Hi all,
> > >
> > > we had a VR meeting during the conference, here are the notable bits.
> > >
> > > Attendees
> > > 
> > > * Dalai Felinto (Blender Foundation)
> > > * Damien Coureau (Ubisoft)
> > > * Daniel Martinez Lara (Pepe School Land & MPX)
> > > * Julian Eisel (Blender Institute)
> > > * Julien Blervaque (Ubisoft)
> > > * Sebastian König (blendFX)
> > > * Simeon Conzendorf (blendFX)
> > > * William Reynish (Blender Foundation)
> > >
> > > General Requirements
> > > =
> > > * There will have to be some experimenting with different approaches
> > > to XR UIs. People and studios also have very different needs for XR
> > > experiences.
> > > * Just how we define the regular 2D UIs in Python, XR UIs should be
> > > defined in Python as well. That allows extending and specializing the
> > > UIs for custom needs. The Ubisoft team is especially keen on this.
> > > * Blender should bundle a good default XR UI for common usage,
> > > established through experimentation of the core VR team and other
> > > collaborators.
> > > * With the gizmo, operator and drawing APIs, the BPY already has many
> > > of the needed bits. There's still lots of stuff we'd have to figure
> > > out and add to it though.
> > >
> > > Next Steps
> > > 
> > > * The team agrees on building the VR UI around specific use-cases.
> > > * The GSoC patch [1] should be merged with the first basic use-case
> > > working (scene inspection, see below)
> > > * We'll start with the following use-cases (roughly in that order):
> > >1. Scene Introspection - VR viewport with initial/simple navigation
> > >2. Sculpting & Grease Pencil drawing in VR
> > >3. Set arrangement/layout - Support adding primitives, transforming
> > > objects and some related gizmos
> > >4. Complete immersive toolset (aka MARUI)
> > >5. VR Storyboarding - Support changing cameras, time and animation
> > > timing within the VR session
> > >6. Set dressing - Support adding particles, assets, ...
> > > * Besides the first use-case, the involved "Blender core developers"
> > > will only try to provide the frameworks needed to implement the other
> > > use-cases. These can then be picked up by contributors (e.g. the
> > > Ubisoft, MARUI or MPX teams).
> > > * The project will be organized as usual in Blender, with a landing
> > > page on developer.blender.org, clearly stated priorities and
> > > milestones, and visible ways for contributors to get involved.
> > >
> > > Future
> > > =
> > > * We also want to support AR/MR based use-cases.
> > > * Collaborative sessions form other important use-cases: multiple
> > > people with multiple headsets work together in the same XR viewport.
> > > This is a rather complicated use-case to get supported, but it would
> > > be immensely useful.
> > >
> > >
> > > [1] - https://developer.blender.org/D5537
> > >
> > > Cheers,
> > > - Julian -
> > > ___
> > > Bf-committers mailing list
> > > Bf-committers@blender.org
> > > https://lists.blender.org/mailman/listinfo/bf-committers
> > >
> > 

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

[Jacob Merrill]

perhaps a progress bar? when it 'fills' bcon5?

overlaid over last splash?
(bcon1 = 0% -> bcon2-> 20% etc)

On Tue, Oct 15, 2019 at 10:34 AM Chad Fraleigh  wrote:

>
> On 10/11/2019 5:42 PM, Stephen Swaney wrote:
> > We should *definitely* keep the new splash reveal at the very end, both
> for the
> > excitement and the ritual.
> >
> > For a development splash, let's just take the last release splash and
> overlay
> > it with some yellow police tape and Under Construction signs.
>
> I was thinking of something similar.. it would be the previous splash
> with an "under construction" overlay (e.g. scaffolding, paint cans,
> tools, etc), but have small portion(s) of it masked out with the new
> splash peeking through. So it keeps its context (i.e. it is specific to
> between those releases), but isn't a full spoiler (more of an enticing
> preview).
>
> And, of course, the construction overlay itself could be updated and
> evolve over time.
>
>
> -Chad
> ___
> 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] New Animation module user owners

[Jacob Merrill]

what is your blender.chat handle?

On Wed, Sep 25, 2019 at 2:28 PM Luciano A. Muñoz Sessarego <
luci...@pintamonos.cl> wrote:

> Hi!,
> Thank you for allowing me to be part of the future of blender, I'll help to
> the best of my abilities I hope we can help drive the future of animation
> in blender to make it the most efficient, focused and powerful tool that we
> can make.
>
> A few questions:
> Will we use the https://blender.chat/channel/animation to discuss (?)
> Do we have a list of targets yet, or do we need to come up with something?
>
> Best,
>
> Luciano A. Muñoz Sessarego
>
> Web: www.pintamonos.cl
>
> Email: luci...@pintamonos.cl
>
> Vimeo: www.vimeo.com/lucianomunoz
>
> Gumroad: https://gumroad.com/lucianomunoz
>
> Imdb: https://www.imdb.com/name/nm8355386/
>
> Linkedin: http://www.linkedin.com/in/lucianomunoz
>
> Instagram: https://www.instagram.com/lucianomunoz
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> https://lists.blender.org/mailman/listinfo/bf-committers
>
___
Bf-committers mailing list
Bf-committers@blender.org
https://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Blender 2.80 Release Candidate - master frozen

[Jacob Merrill]

I have been testing eevee at each dev cycle and I can do almost anything !

it's really amazing.


last few gripes in eevee nodes- pointness ? - particle info node - location

thank you blender ninjas!

On Wed, Jul 10, 2019 at 8:23 AM Brecht Van Lommel 
wrote:

> Hi everyone,
>
> We have entered the 2.80 release candidate phase now. That means
> master will be mostly frozen, only important bugfixes should go in.
> Please ensure commits are reviewed by another developer, and don't
> make risky changes.
>
> Sergey will do the branching & tagging, after which platform
> maintainers can make the release candidate builds. If all goes well
> these builds go up on blender.org tomorrow, July 11.
>
> The final release is then planned for July 18, depending if any
> critical issues come up that require more time. After this master will
> be open for the 2.81 release cycle.
>
> Thanks,
> Brecht.
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> https://lists.blender.org/mailman/listinfo/bf-committers
>
___
Bf-committers mailing list
Bf-committers@blender.org
https://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Understanding the dev process

[Jacob Merrill]

It would be nice if The game engine concerns would be addressed during the
development of 2. 8 instead of after.

Also is there any plan to integrate multiple users to a single blender
scene? (multi-player blender?)
5g means huge changes could stream instantly almost no?

On Fri, Jul 5, 2019, 10:18 PM Nathan Letwory  wrote:

> Hi Pablo (and all the others who already chipped in),
>
> Your writing is very much on topic. Bias is what I'm looking for, the
> request
> was formulated about perception of process!
>
> I think some valid points are being raised. We definitely should continue
> this
> discussion, and my hope is that we will see all sides of it in the coming
> days.
>
> For now I'll keep it to encouraging everybody to speak their mind. All good
> criticism, concerns, but also positive points, are welcome.
>
> Next week or so will be time for more contemplation on all input.
>
> /Nathan
>
> la 6. heinäk. 2019 klo 7.07 Pablo Dobarro 
> kirjoitti:
>
> > Hi!
> >
> > Maybe I'm going off-topic and I'm probably a little bit biased...
> >
> > I think the main problem in the development process of some areas of
> > Blender is feature incoherence. I feel like some times there are
> > discussions, design proposals and commits implementing new advanced
> > features on areas where the most basic functionality for an artist is
> still
> > not right. The sculpt/paint module and the tool system are heavily
> affected
> > by this.
> >
> > This is a tricky problem to solve. We can't really expect artists to make
> > useful bug reports about brushes or tools behaving incorrectly. For most
> of
> > them, it would be nearly impossible to formulate the problem pointing at
> > the exact technical detail for a developer to fix it. These kinds of
> issues
> > are really obvious for an artist who has been working with these tools
> for
> > years, but developers may think that the tool is working at it should.
> This
> > communication problem often ends in misleading bug reports, proposals and
> > discussions going nowhere while trying to fix the wrong thing.
> >
> > The thing is: in some cases, those issues can be fixed by changing just a
> > few lines, so we can expect artists with a coding background to fix them.
> > But there are a lot of cases where a whole redesign of an area is
> required
> > just to fix one those issues (that is essentially the problem of the
> sculpt
> > branch). Some users are creating non-commercial addons to bypass these
> > limitations by recreating entire systems through the Python API instead
> of
> > contributing it to Blender, probably because they consider that a task
> for
> > a core developer.
> >
> > I think we should be extra careful about this when doing big refactors or
> > creating new modules. In my opinion, the core team should focus more on
> > designing the new systems in a way that makes the life of new
> contributors
> > easier (who can probably take care of this) instead of making a final
> > product with a planned set of features. We should put a little more
> effort
> > to make sure the foundations are right from and artist perspective
> >
> > Currently, some of those issues so bad that, in my opinion, they should
> > not be considered as a feature request. They should probably be handled
> as
> > a high priority bug, blocking a release. They make the experience of some
> > areas much worse than Blender crashing every 10 minutes. This ends up
> > hurting the opinion artists have about Blender and all the technical work
> > that is behind it.
> >
> > As an example, the Grease Pencil team spent a lot of time designing and
> > tweaking the behavior of each brush, and that clearly shows. The result
> is
> > so impressive that it almost feels like a pixel-based drawing software.
> An
> > artist is not going to care about modifiers, effects or animation
> features
> > if they feel that the brush engine is broken just by doing one brush
> stroke.
> >
> > If we only focus on long term interesting technical projects and bug
> > fixing, Blender will be able to paint PBR materials across multiple
> UDIMs,
> > while using the current brush engine on a 2D view that does not rotate or
> > flip. In my opinion, we should not touch a single line of the 3D texture
> > projection code until the 2D view and the default brushes are absolutely
> > perfect to a level they can be used for serious illustration work.
> Probably
> > the sweet spot is in the middle of these two points of view.
> >
> > Pablo
> >
> > El jue., 4 jul. 2019 a las 15:38, Nathan Letwory (<
> jesterk...@letwory.net>)
> > escribió:
> >
> >> Hey all,
> >>
> >> As you all may know by now I've been asked to help coordinate and manage
> >> the Blender development.
> >>
> >> To get a better understanding of what these days is going on, and to
> >> prevent me from just acting through my personal preferences, I'd like to
> >> hear from the blender developer community how they see the current dev
> >> process.
> >>
> >> I'm most 

Re: [Bf-committers] Blender developers meeting notes - 2019-05-27

[Jacob Merrill]

Thank you for your quick reply,
And thank you for blender!

On Mon, May 27, 2019, 12:09 PM Brecht Van Lommel 
wrote:

> No, there's no roadmap for specific shading features like that.
>
> On Mon, May 27, 2019, 21:01 Jacob Merrill 
> wrote:
>
> > Is there a roadmap for particle data node to work in eevee?
> >
> > What about object info location on volumes?
> >
> > On Mon, May 27, 2019, 10:37 AM Brecht Van Lommel <
> > brechtvanlom...@gmail.com>
> > wrote:
> >
> > > Hi all,
> > >
> > > Here are the notes from today's developer meeting. Next meeting is
> > > Monday, 3 June 10:00 CEST / 8:00 UTC, in #blender-coders on
> > > blender.chat.
> > >
> > > 1) Development
> > >
> > > * The Blender 2.80 user interface is now frozen, so that there is a
> > > stable base for creating documentation and tutorials. Settings will
> > > stay in the same place and screenshots should remain valid for the
> > > final 2.80 release. A handful of menu entries may be added, or a
> > > tooltip might be improved, but nothing that would break documentation.
> > > * The Python API will also remain compatible, so add-ons working now
> > > should continue working in the final 2.80 release.
> > > * Developers start updating the user manual next week. Campbell will
> > > map out the work to be done and organize it.
> > > * The Summer of Code coding period has started. Ray Molenkamp has
> > > volunteered to create daily Windows builds of all branches for
> > > testing, though of course it will take a while before there will be
> > > anything testable in most branches.
> > > * Regression tests are now passing on all 64 bit platforms, only on 32
> > > bit some issues remain. Developers should run tests before committing
> > > changes.
> > >
> > > 2) New Features and Changes
> > >
> > > About 110 bugs have been fixed in the last week.
> > >
> > > * Sequencer: smarter cache invalidation makes interactive moving of
> > > strips and tweaking strip properties much smoother. (Richard Antalík)
> > > * Particles: optimization for generating millions of particles on
> > > computers with many cores. (Juan Gea)
> > > * COLLADA: support for exporting with a different global axis
> > > rotation. (Gaia Clary)
> > > * Transform tool is back in the 3D viewport toolbar, the other gizmo
> > > settings remain unchanged for those who prefer to enable transform
> > > gizmos independent of tools. (Campbell Barton)
> > > * Mesh editing overlays have been tweaked to have more contrast
> > > regardless of the material and lighting used. (Clément Foucault)
> > > * Workbench studio light presets have been changed to add more
> > > contrast. (Clément Foucault, William Reynish)
> > > * Many small user interface layout tweaks. (William Reynish)
> > >
> > > 3) Weekly Reports
> > >
> > > * Bastien:
> > >
> >
> https://wiki.blender.org/wiki/User:Mont29/Foundation/2019#Week_297_-_05.2F18_to_05.2F24
> > > * Brecht:
> > > https://wiki.blender.org/wiki/User:Brecht/Reports/2019#May_20_-_24
> > > * Campbell:
> > >
> >
> https://download.blender.org/ftp/ideasman42/donelist/2019.html#week-327-may-20
> > > * Clément:
> > >
> >
> https://wiki.blender.org/wiki/User:Hypersomniac/Foundation/2019#Week_123_:_20th_-_26th_May
> > > * Dalai:
> > > https://wiki.blender.org/wiki/User:Dfelinto/Reports/2019#May_20_-_24
> > > * Jacques:
> > >
> >
> https://wiki.blender.org/wiki/User:Sergey/Foundation/2019#Week_387:_20th_-_26th_May
> > > * Jeroen:
> > >
> >
> https://wiki.blender.org/wiki/User:Jbakker/reports/2019#Week_201921:_2019.2F05.2F20_-_2019.2F05.2F26
> > > * Philipp:
> > >
> >
> https://wiki.blender.org/wiki/User:PhilippOeser/Foundation/2019#Calendar_Week_21_.2815hrs.29
> > > * Sergey:
> > >
> >
> https://wiki.blender.org/wiki/User:Sergey/Foundation/2019#Week_387:_20th_-_26th_May
> > > ___
> > > Bf-committers mailing list
> > > Bf-committers@blender.org
> > > https://lists.blender.org/mailman/listinfo/bf-committers
> > >
> > ___
> > Bf-committers mailing list
> > Bf-committers@blender.org
> > https://lists.blender.org/mailman/listinfo/bf-committers
> >
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> https://lists.blender.org/mailman/listinfo/bf-committers
>
___
Bf-committers mailing list
Bf-committers@blender.org
https://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Blender developers meeting notes - 2019-05-27

[Jacob Merrill]

Is there a roadmap for particle data node to work in eevee?

What about object info location on volumes?

On Mon, May 27, 2019, 10:37 AM Brecht Van Lommel 
wrote:

> Hi all,
>
> Here are the notes from today's developer meeting. Next meeting is
> Monday, 3 June 10:00 CEST / 8:00 UTC, in #blender-coders on
> blender.chat.
>
> 1) Development
>
> * The Blender 2.80 user interface is now frozen, so that there is a
> stable base for creating documentation and tutorials. Settings will
> stay in the same place and screenshots should remain valid for the
> final 2.80 release. A handful of menu entries may be added, or a
> tooltip might be improved, but nothing that would break documentation.
> * The Python API will also remain compatible, so add-ons working now
> should continue working in the final 2.80 release.
> * Developers start updating the user manual next week. Campbell will
> map out the work to be done and organize it.
> * The Summer of Code coding period has started. Ray Molenkamp has
> volunteered to create daily Windows builds of all branches for
> testing, though of course it will take a while before there will be
> anything testable in most branches.
> * Regression tests are now passing on all 64 bit platforms, only on 32
> bit some issues remain. Developers should run tests before committing
> changes.
>
> 2) New Features and Changes
>
> About 110 bugs have been fixed in the last week.
>
> * Sequencer: smarter cache invalidation makes interactive moving of
> strips and tweaking strip properties much smoother. (Richard Antalík)
> * Particles: optimization for generating millions of particles on
> computers with many cores. (Juan Gea)
> * COLLADA: support for exporting with a different global axis
> rotation. (Gaia Clary)
> * Transform tool is back in the 3D viewport toolbar, the other gizmo
> settings remain unchanged for those who prefer to enable transform
> gizmos independent of tools. (Campbell Barton)
> * Mesh editing overlays have been tweaked to have more contrast
> regardless of the material and lighting used. (Clément Foucault)
> * Workbench studio light presets have been changed to add more
> contrast. (Clément Foucault, William Reynish)
> * Many small user interface layout tweaks. (William Reynish)
>
> 3) Weekly Reports
>
> * Bastien:
> https://wiki.blender.org/wiki/User:Mont29/Foundation/2019#Week_297_-_05.2F18_to_05.2F24
> * Brecht:
> https://wiki.blender.org/wiki/User:Brecht/Reports/2019#May_20_-_24
> * Campbell:
> https://download.blender.org/ftp/ideasman42/donelist/2019.html#week-327-may-20
> * Clément:
> https://wiki.blender.org/wiki/User:Hypersomniac/Foundation/2019#Week_123_:_20th_-_26th_May
> * Dalai:
> https://wiki.blender.org/wiki/User:Dfelinto/Reports/2019#May_20_-_24
> * Jacques:
> https://wiki.blender.org/wiki/User:Sergey/Foundation/2019#Week_387:_20th_-_26th_May
> * Jeroen:
> https://wiki.blender.org/wiki/User:Jbakker/reports/2019#Week_201921:_2019.2F05.2F20_-_2019.2F05.2F26
> * Philipp:
> https://wiki.blender.org/wiki/User:PhilippOeser/Foundation/2019#Calendar_Week_21_.2815hrs.29
> * Sergey:
> https://wiki.blender.org/wiki/User:Sergey/Foundation/2019#Week_387:_20th_-_26th_May
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> https://lists.blender.org/mailman/listinfo/bf-committers
>
___
Bf-committers mailing list
Bf-committers@blender.org
https://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Blender developers meeting notes - 2019-05-06

[Jacob Merrill]

does the object info / location node now work in eevee cycles?

I have a build about 2 weeks old or more and it's not working.


On Mon, May 13, 2019 at 10:12 AM Brecht Van Lommel <
brechtvanlom...@gmail.com> wrote:

> Hi all,
>
> Here are the notes from last week's developer meeting.
>
> 1) Development
>
> Following the 2.80 release plan, we should stop doing significant user
> interface and Python API changes next week. After that the focus will be on
> bugfixing and documentation. Developers should focus on finishing user
> interface and API changes as soon as possible.
> https://code.blender.org/2019/04/2-80-release-plan/
>
> 2) New Features and Changes
>
> Animation
>
> * Pose mode mirroring for the transform tool was added, similar to other
> modes that already supported it. This works in either absolute mode to
> ensure the bone position and rotation is exactly the same on both sides, or
> relative mode to apply the same relative transformation to both sides.
> (Sebastian Parborg)
> * Armature and lattice deform is now multithreaded. (Alexander Gavrilov)
>
> Sequencer
>
> * Sequencer scene strip performance for has been much improved, and
> available settings have changed. For wireframe solid display type, it will
> now use the workbench render settings from the scene used in the strip.
> Optionally this can be overridden with the workbench render settings from
> the scene containing the strips. (Jeroen Bakker)
>
> Viewport
>
> * Anti-aliasing settings for the workbench render engine have been changed
> to match the viewport. Viewport Render now uses faster anti-aliasing by
> default for quick playblasts. (Jeroen Bakker).
> * Eevee now supports viewport preview of background alpha. (Clément
> Foucault)
> * Lookdev HDR preview balls now have a configurable size in the
> preferences. (George Vogiatzis)
> * Sculpt mode support for displaying multiple materials. (Clément Foucault)
>
> User Interface
>
> * Clicking in empty space to deselect now works in all editors, not just
> the 3D viewport. (Bastien Montagne)
> * Proportional editing is now a toggle in all modes, with additional
> settings depending on the mode in the popover next to it. (Campbell Barton)
> * Remove Doubles was renamed to Merge by Distance, and is part of the Merge
> menu. (William Reynish)
> * Industry standard keymap: many tweaks based on user feedback.  (William
> Reynish)
> * New and updated icons. (Andrzej Ambroż)
> * UV sculpt tools are now integrated into the new tool system. (Campbell
> Barton)
> * Annotate is now available in sculpt and paint modes.  (William Reynish)
> * Outliner visual tweaks to make it look less busy. (Harley Acheson)
> * On macOS, shortcuts in menus now use icons for modifier keys.  (Harley
> Acheson)
> * The tool settings user interface has been tweaked further. The properties
> editor now always shows tool settings for the 3D viewport, while other
> editors like the image editor show them in their own sidebar. (Campbell
> Barton)
>
> Grease Pencil
>
> * Add stroke color to materials popover, API additions to check annotations
> and create/remove grease pencil settings on a material. (Antonio Vazquez)
> * New video about textured brushes. Brushes available for download on
> cloud.blender.org. (Daniel Martinez Lara)
> https://youtu.be/kpY-WVQUxYw
> https://cloud.blender.org/p/gallery/5ccfe64353b85e279cf72acd
>
> 3) Weekly Reports
>
> * Bastien:
>
> https://wiki.blender.org/wiki/User:Mont29/Foundation/2019#Week_294_-_04.2F27_to_05.2F03
> * Brecht:
> https://wiki.blender.org/wiki/User:Brecht/Reports/2019#April_29_-_May_3
> * Campbell:
>
> https://download.blender.org/ftp/ideasman42/donelist/2019.html#week-324-april-29
> * Clément:
>
> https://wiki.blender.org/wiki/User:Hypersomniac/Foundation/2019#Week_120_:_29th_-_5th_May
> * Dalai:
> https://wiki.blender.org/wiki/User:Dfelinto/Reports/2019#April_29_-_May_4
> * Jacques:
>
> https://wiki.blender.org/wiki/User:JacquesLucke/Reports/2019#Week_31:_April_29_-_03
> * Jeroen:
>
> https://wiki.blender.org/wiki/User:Jbakker/reports/2019#Week_201918:_2019.2F04.2F29_-_2019.2F05.2F05
> * Philipp:
>
> https://wiki.blender.org/wiki/User:PhilippOeser/Foundation/2019#Calendar_Week_18_.2815hrs.29
> * Sebastian: https://wiki.blender.org/wiki/User:Zeddb#April_29_-_May_3
> * Sergey: https://wiki.blender.org/wiki/User:Sergey/Foundation/2019
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> https://lists.blender.org/mailman/listinfo/bf-committers
>
___
Bf-committers mailing list
Bf-committers@blender.org
https://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Blender developers meeting notes - 2019-04-01

[Jacob Merrill]

what about adding 'pointiness' to the bake options in cycles (so you don't
have to set it up yourself?)


On Mon, Apr 1, 2019 at 10:48 AM Jacob Merrill 
wrote:

> is there any plan to impliment the pointiness node in eevee2.8?
> (it may already be done I have not checked this weeks build)
>
> On Mon, Apr 1, 2019 at 9:52 AM Brecht Van Lommel <
> brechtvanlom...@gmail.com> wrote:
>
>> Hi all,
>>
>> Here are the notes from today's developer meeting. Next meeting is Monday,
>> 15 April 18:00 CET / 17:00 UTC.
>>
>> 1) News
>>
>> * Next week developers gather in Amsterdam for the Homestretch Workshop.
>> There will be no IRC meeting then, but many face-to-face meetings.
>> * The Spring open movie will be released on April 4. This project has been
>> very important in testing 2.80 in production, and will come with tutorials
>> on how 2.80 was used on cloud.blender.org.
>>
>> 2) New Features and Changes
>>
>> About 90 bugs were fixed last week.
>>
>> * Eevee: added support for undeformed texture coordinates, and coordinates
>> from another object. (Clément Foucault)
>> * Grease pencil: much improved soft eraser tool. (Antonio Vazquez)
>> * UI: better display of report messages in the status bar. (Nathan
>> Craddock)
>> * UI: better muted node visualization, greying out the entire node.
>> (Robert
>> Guetzkow)
>> * UI: support for default active button in popups and file browser, to
>> quickly confirm operations. (Campbell Barton)
>> * The `view3d.select_or_deselect_all` operator has been removed, replaced
>> by a `deselect` property on `view3d.select`. Keymaps will need to be
>> updated to account for this.
>>
>> 3) Development
>> * Additional bugs in the tracker have been marked as high priority to
>> indicate issues that we *must* fix before the 2.80 release. To developers:
>> if you're aware of more such bugs, please mark them as high priority.
>> (Brecht Van Lommel)
>> * Low level details on the new function nodes system are now in the wiki.
>> (Jacques Lucke)
>> https://wiki.blender.org/wiki/Source/Nodes/InitialFunctionsSystem
>>
>> 4) Weekly Reports
>> * Bastien:
>>
>> https://wiki.blender.org/wiki/User:Mont29/Foundation/2019#Week_289_-_03.2F23_to_03.2F29
>> * Brecht:
>> https://wiki.blender.org/wiki/User:Brecht/Reports/2019#March_25_-_29
>> * Campbell:
>> https://download.blender.org/ftp/ideasman42/donelist/2019.html
>> * Clément:
>>
>> https://wiki.blender.org/wiki/User:Hypersomniac/Foundation/2019#Week_115_:_18th_-_24th_Mar
>> * Jacques:
>>
>> https://wiki.blender.org/wiki/User:JacquesLucke/Reports/2019#Week_26:_March_25_-_29
>> * Jeroen:
>>
>> https://wiki.blender.org/wiki/User:Jbakker/reports/2019#Week_201913:_2019.2F03.2F25_-_2019.2F03.2F31
>> * Philipp:
>>
>> https://wiki.blender.org/wiki/User:PhilippOeser/Foundation/2019#Calendar_Week_13_.2815hrs.29
>> * Sebastian: https://wiki.blender.org/wiki/User:Zeddb#March_25_-_March_29
>> * Sergey:
>>
>> https://wiki.blender.org/wiki/User:Sergey/Foundation/2019#Week_379:_25th_-_31st_March
>> ___
>> Bf-committers mailing list
>> Bf-committers@blender.org
>> https://lists.blender.org/mailman/listinfo/bf-committers
>>
>
___
Bf-committers mailing list
Bf-committers@blender.org
https://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Blender developers meeting notes - 2019-04-01

[Jacob Merrill]

is there any plan to impliment the pointiness node in eevee2.8?
(it may already be done I have not checked this weeks build)

On Mon, Apr 1, 2019 at 9:52 AM Brecht Van Lommel 
wrote:

> Hi all,
>
> Here are the notes from today's developer meeting. Next meeting is Monday,
> 15 April 18:00 CET / 17:00 UTC.
>
> 1) News
>
> * Next week developers gather in Amsterdam for the Homestretch Workshop.
> There will be no IRC meeting then, but many face-to-face meetings.
> * The Spring open movie will be released on April 4. This project has been
> very important in testing 2.80 in production, and will come with tutorials
> on how 2.80 was used on cloud.blender.org.
>
> 2) New Features and Changes
>
> About 90 bugs were fixed last week.
>
> * Eevee: added support for undeformed texture coordinates, and coordinates
> from another object. (Clément Foucault)
> * Grease pencil: much improved soft eraser tool. (Antonio Vazquez)
> * UI: better display of report messages in the status bar. (Nathan
> Craddock)
> * UI: better muted node visualization, greying out the entire node. (Robert
> Guetzkow)
> * UI: support for default active button in popups and file browser, to
> quickly confirm operations. (Campbell Barton)
> * The `view3d.select_or_deselect_all` operator has been removed, replaced
> by a `deselect` property on `view3d.select`. Keymaps will need to be
> updated to account for this.
>
> 3) Development
> * Additional bugs in the tracker have been marked as high priority to
> indicate issues that we *must* fix before the 2.80 release. To developers:
> if you're aware of more such bugs, please mark them as high priority.
> (Brecht Van Lommel)
> * Low level details on the new function nodes system are now in the wiki.
> (Jacques Lucke)
> https://wiki.blender.org/wiki/Source/Nodes/InitialFunctionsSystem
>
> 4) Weekly Reports
> * Bastien:
>
> https://wiki.blender.org/wiki/User:Mont29/Foundation/2019#Week_289_-_03.2F23_to_03.2F29
> * Brecht:
> https://wiki.blender.org/wiki/User:Brecht/Reports/2019#March_25_-_29
> * Campbell: https://download.blender.org/ftp/ideasman42/donelist/2019.html
> * Clément:
>
> https://wiki.blender.org/wiki/User:Hypersomniac/Foundation/2019#Week_115_:_18th_-_24th_Mar
> * Jacques:
>
> https://wiki.blender.org/wiki/User:JacquesLucke/Reports/2019#Week_26:_March_25_-_29
> * Jeroen:
>
> https://wiki.blender.org/wiki/User:Jbakker/reports/2019#Week_201913:_2019.2F03.2F25_-_2019.2F03.2F31
> * Philipp:
>
> https://wiki.blender.org/wiki/User:PhilippOeser/Foundation/2019#Calendar_Week_13_.2815hrs.29
> * Sebastian: https://wiki.blender.org/wiki/User:Zeddb#March_25_-_March_29
> * Sergey:
>
> https://wiki.blender.org/wiki/User:Sergey/Foundation/2019#Week_379:_25th_-_31st_March
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> https://lists.blender.org/mailman/listinfo/bf-committers
>
___
Bf-committers mailing list
Bf-committers@blender.org
https://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Blender 2.79 Nightly builds using different Python versions

[Jacob Merrill]

it sounds like quite a bit more work to have multiple SVN for multiple
branches.


it would be slick though to saved the SVN timestamp / revision for old
releases somewhere.

even upbge is based on the same SVN (we have a upbge eevee branch that
stays current w/master)



On Fri, Mar 15, 2019 at 10:11 AM Brecht Van Lommel <
brechtvanlom...@gmail.com> wrote:

> There is no 2.79c planned currently.
>
> The main issue here is naming. The changes in this branch are not just
> bugfixes on top if 2.79, there are also new features and a few
> compatibility breaking changes. We can't undo those, users of that branch
> are already relying on them.
>
> In the future we should two things different (that I have argued for
> before):
> * Increase Blender version immediately at the start of the release cycle,
> not at the end.
> * Avoid long release cycles like for 2.80, so there is no need to add new
> features in both branches.
>
>
> On Fri, Mar 15, 2019 at 5:30 PM Brian Savery 
> wrote:
>
> > First of all, not sure if a 2.79C build is planned.  But we've noticed
> > something odd recently.  Namely, that nightly builds of 2.79 use python
> > version 3.7.0, whereas the "released" 2.79b build uses 3.5.3
> >
> > Not a big deal, it's python right?  Well except there are plenty of
> addons
> > that use C-Extensions for python.  On certain platforms (windows
> > particularly) a python C-Extension is not forward compatible (unless you
> > use some particular limited feature set).  So addon users get errors when
> > trying to use "2.79" versions of addons that use c-extensions.
> >
> > Furthermore, I would claim from a release management standpoint, if
> you're
> > calling something a 2.79 build of Blender, it should not be switching
> > python versions.  Basic api compatibility.  I'm assuming the reason this
> > was done was that you're using the same build machines for 2.80 which
> uses
> > python 3.7, but it is possible to run multiple versions of python on one
> > machine.  Can this be fixed please?
> >
> > Brian
> > ___
> > 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] Sculpt Mode development

[Jacob Merrill]

I as thinking something like this could be used for anything
(pbvhtree) if you can query a point + radius

it would almost be handy to have some sort of threaded py command with a
pool to do this.
(so that can circumvent gil yet write equations in py)

(sculpt / paint vertex / paint weight / texture paint )


On Tue, Mar 12, 2019 at 11:18 AM Brecht Van Lommel <
brechtvanlom...@gmail.com> wrote:

> Hi Pablo,
>
> I've now given you commit rights, see private mail for details.
>
> As you are working in this branch, I suggest to carefully keep track of
> performance and memory usage, because they can be difficult to gain back
> after making many changes. I also recommend to focus on fewer really
> finished features over many prototypes, as untangling that for review and
> merging can be difficult.
>
>
> Some quick feedback from reading the proposal.
>
> Voxel Remesh solves most of dyntopo problems without any performance
> > penalty.
>
>
> Would be good to clarify which problems, or why there is no performance
> penalty?
>
> My guess is you're saying this remesh is for users to fix poor topology
> created by dyntopo, and that it runs relatively fast even for high poly
> meshes?
>
> Static Remesher - OpenVDB Voxel Remesh
>
>
> There is no need to tie this to other uses of OpenVDB in Blender, or to
> rewrite it if those come along. Just write a remeshing functions that uses
> the OpenVDB library, separate from other code.
>
> PBVH vertex paint stores colors in the mesh vertices in a way that is
> > possible to use the sculpt mode code to paint.
>
>
> This needs a better name, vertex paint already uses the PBVH and it doesn't
> explain what it means to users.
>
> For me, the main question here is how this works on a UI design level. What
> it means for modes and tools, how you combine sculpt and paint while
> keeping the UI clear.
>
> It would also be good to clarify the data design issue. From what I
> understand you want to store colors per vertex instead of per face corner,
> and that's where backwards compatibility breaks? We probably need to keep
> both per vertex and per face corner attributes storage support, but my
> guess is that only supporting per vertex for paint modes would be
> acceptable.
>
> > Node Brush
>
> The types of brushes that work ok with nodes are likely to be easy to
> implement anyway, and easier to optimize and debug then. For built-in
> brushes I think it's wrong to add this extra level of abstraction.
>
> The main potential here I see is for users to create their own brushes, but
> I did not yet see compelling examples of new possibilities. I see a risk
> here of adding complexity with little practical benefit.
>
> > New Sculpt data structure
>
> A requirement for this data structure is also to have low memory usage and
> be efficient to draw, and to some extent making the editing more complex is
> acceptable to accommodate that I think. Though the current code is
> certainly not optimal, replacing it needs very careful design.
>
> Regards,
> Brecht.
>
>
> On Mon, Mar 11, 2019 at 2:25 PM Pablo Dobarro 
> wrote:
>
> > Hi all,
> >
> >
> > I am Pablo Dobarro. I've been working with Zacharias Reinhardt, Julien
> > Kaspar and Lukas Walzer for the last months to write a proposal to
> improve
> > sculpt and vertex paint mode. We have a document that details our main
> > goals, as well as a short/mid term planning and the current status of the
> > patches.
> >
> >
> >
> https://docs.google.com/presentation/d/1fmjdtajPzeD3ixpGIvseKMRsAzhmKC4etIE8YqacwLk/edit?usp=sharing
> >
> > We are aware that the current master branch is in feature freeze state,
> so
> > we would like to have a new branch to start developing sculpt/vertex
> paint
> > mode and have more polished patches ready to review after 2.80 is out.
> Some
> > of those patches (like tweaking the behavior of some brushes) will break
> > the compatibility, and they will need a lot of iterations and feedback
> from
> > the community to get them right. Having this in a separate branch will
> make
> > easier for us to provide test builds and to test the integration of the
> new
> > features.
> >
> > In the future, we would like to see a Sculpt Quest to happen, to help us
> > tackle the bigger features and design goals of the proposal. We know that
> > it is not realistic at this moment, but we would want to advance as much
> > work as possible before that happens. A possible Sculpt Quest is
> something
> > we need to discuss in detail with the Blender Foundation, after we made
> > progress with the separate sculpting branch.
> >
> > Could someone create a new branch and give us commit rights to start
> > working on this project?
> >
> > Best regards,
> > Pablo
> > ___
> > Bf-committers mailing list
> > Bf-committers@blender.org
> > https://lists.blender.org/mailman/listinfo/bf-committers
> >
> ___
> Bf-committers mailing list
> Bf-committers@blender.org

Re: [Bf-committers] Blender developers meeting notes - 2019-02-04

[Jacob Merrill]

https://github.com/lordloki/UPBGE-EEVEE

why not just expand on youles port of bge over to eevee ?

it's working, BPY works, and most of the old cuft is already dropped?

side note - this could still export a EXE

he has animations, add object, and most of the basic logic working already?
he also wants to help maintain it,

https://www.youtube.com/watch?v=snOdr4A9kqI

On Tue, Feb 5, 2019 at 6:13 AM Brecht Van Lommel 
wrote:

> The interactive mode project indeed has not been very active lately,
> there's no news on it at the moment.
>
> Note however that the interactive mode is explicitly not intended to be a
> game engine, it's about a physics sandbox and logic nodes. There is no
> current plan to add back a game engine.
>
>
> On Mon, Feb 4, 2019 at 6:43 PM Jacob Merrill 
> wrote:
>
> > Still no game engine work Taking place?
> >
> > Where are Benoit's updates?
> >
> > On Mon, Feb 4, 2019, 9:40 AM Sergey Sharybin  wrote:
> >
> > > Hi all,
> > >
> > > Here are the notes from today's developer meeting. Next meeting is
> > Monday,
> > > 11 February 10:00 CET / 09:00 UTC.
> > >
> > > 1) New Features and Changes
> > >
> > > * About 105 bugs were fixed last week, total number of closed reports
> is
> > > 222,
> > > * Bevel: better corner shapes for inner arc miters. (Howard Trickey)
> > > * Workbench support for material transparency. (Clément Foucault)
> > >
> > > 2) Development
> > >
> > > * Jeroen Bakker starts work at the Blender Institute this week,
> welcome!
> > He
> > > will first focus on Cycles OpenCL optimizations, funded by AMD.
> > > * Bug tracker priority names have been changed to make their meaning
> more
> > > clear. We also encourage developers to set High priority more often so
> > > important bugs do not get buried.
> > > * Richard Antalik is working on a sequencer prefetch patch, which needs
> > > design and code review: https://developer.blender.org/D3934
> > >
> > > 3) Google Summer of Code
> > >
> > > * This is a period for organizations to apply.
> > > * The list of ideas needs update with the deadline of February 6:
> > > https://wiki.blender.org/wiki/GSoC/Ideas_Suggestions
> > >
> > > 4) Weekly Reports
> > > * Bastien:
> > >
> > >
> >
> https://wiki.blender.org/wiki/User:Mont29/Foundation/2019#Week_281_-_01.2F26_to_02.2F01
> > > * Brecht: https://wiki.blender.org/wiki/User:Brecht/Reports/2019
> > > * Campbell:
> > >
> > >
> >
> https://download.blender.org/ftp/ideasman42/donelist/2019.html#week-310-january-28
> > > * Clément:
> > >
> > >
> >
> https://wiki.blender.org/wiki/User:Hypersomniac/Foundation/2019#Week_108_:_28th_-_3rd_Feb
> > > * Dalai:
> > >
> > >
> >
> https://wiki.blender.org/wiki/User:Dfelinto/Reports/2019#January_28_-_February_1
> > > * Jacques:
> > >
> > >
> >
> https://wiki.blender.org/wiki/User:JacquesLucke/Reports/2019#Week_18:_January_28_-_01
> > > * Jeroen:
> > >
> > >
> >
> https://wiki.blender.org/wiki/User:Jbakker/reports/2019#Week_201905:_2019.2F02.2F01_-_2019.2F02.2F03
> > > * Philipp:
> > >
> > >
> >
> https://wiki.blender.org/wiki/User:PhilippOeser/Foundation/2019#Calendar_Week_5_.28Jan_28th_-_Feb_1st.29
> > > * Sebastian:
> https://wiki.blender.org/wiki/User:Zeddb#January_28_-_Feb_1
> > > * Sergey:
> > >
> > >
> >
> https://wiki.blender.org/wiki/User:Sergey/Foundation/2019#Week_371:_28th_January_-_3rd_February
> > >
> > > --
> > > With best regards, Sergey Sharybin
> > > ___
> > > Bf-committers mailing list
> > > Bf-committers@blender.org
> > > https://lists.blender.org/mailman/listinfo/bf-committers
> > >
> > ___
> > Bf-committers mailing list
> > Bf-committers@blender.org
> > https://lists.blender.org/mailman/listinfo/bf-committers
> >
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> https://lists.blender.org/mailman/listinfo/bf-committers
>
___
Bf-committers mailing list
Bf-committers@blender.org
https://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Blender developers meeting notes - 2019-02-04

[Jacob Merrill]

Still no game engine work Taking place?

Where are Benoit's updates?

On Mon, Feb 4, 2019, 9:40 AM Sergey Sharybin  Hi all,
>
> Here are the notes from today's developer meeting. Next meeting is Monday,
> 11 February 10:00 CET / 09:00 UTC.
>
> 1) New Features and Changes
>
> * About 105 bugs were fixed last week, total number of closed reports is
> 222,
> * Bevel: better corner shapes for inner arc miters. (Howard Trickey)
> * Workbench support for material transparency. (Clément Foucault)
>
> 2) Development
>
> * Jeroen Bakker starts work at the Blender Institute this week, welcome! He
> will first focus on Cycles OpenCL optimizations, funded by AMD.
> * Bug tracker priority names have been changed to make their meaning more
> clear. We also encourage developers to set High priority more often so
> important bugs do not get buried.
> * Richard Antalik is working on a sequencer prefetch patch, which needs
> design and code review: https://developer.blender.org/D3934
>
> 3) Google Summer of Code
>
> * This is a period for organizations to apply.
> * The list of ideas needs update with the deadline of February 6:
> https://wiki.blender.org/wiki/GSoC/Ideas_Suggestions
>
> 4) Weekly Reports
> * Bastien:
>
> https://wiki.blender.org/wiki/User:Mont29/Foundation/2019#Week_281_-_01.2F26_to_02.2F01
> * Brecht: https://wiki.blender.org/wiki/User:Brecht/Reports/2019
> * Campbell:
>
> https://download.blender.org/ftp/ideasman42/donelist/2019.html#week-310-january-28
> * Clément:
>
> https://wiki.blender.org/wiki/User:Hypersomniac/Foundation/2019#Week_108_:_28th_-_3rd_Feb
> * Dalai:
>
> https://wiki.blender.org/wiki/User:Dfelinto/Reports/2019#January_28_-_February_1
> * Jacques:
>
> https://wiki.blender.org/wiki/User:JacquesLucke/Reports/2019#Week_18:_January_28_-_01
> * Jeroen:
>
> https://wiki.blender.org/wiki/User:Jbakker/reports/2019#Week_201905:_2019.2F02.2F01_-_2019.2F02.2F03
> * Philipp:
>
> https://wiki.blender.org/wiki/User:PhilippOeser/Foundation/2019#Calendar_Week_5_.28Jan_28th_-_Feb_1st.29
> * Sebastian: https://wiki.blender.org/wiki/User:Zeddb#January_28_-_Feb_1
> * Sergey:
>
> https://wiki.blender.org/wiki/User:Sergey/Foundation/2019#Week_371:_28th_January_-_3rd_February
>
> --
> 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] GSoC Idea: Improving Automatic UV Unwrapping

[Jacob Merrill]

I think a function that would be slick, is something that figures out where
a brush spills over a seem, and then take the section that 'overhangs' the
island, and transform it to the other side of the seam, (if enabled) so
seams would not really matter as much.

of course with really nice bake tools, we can unwrap the model seamless
with overlaps, and then bake over to a proper unwrapped mesh and seams are
not a issue at all.



On Sun, Jan 27, 2019 at 8:23 AM Philip Holzmann  wrote:

> In case you are looking for ideas to add to the GSoC ideas list:
> Here's a self-contained project somebody could work on.
>
> "Improving Automatic UV Unwrapping"
>
>
> Benefits: Higher quality automatic UV unwrapping saves artist time,
> especially for prototypes and sculpts.
>
> Description:
> Implement an algorithm that generates a UV projection with a relatively
> high quality.
> Blender already has some forms of automatic UV unwrapping, for example
> the "Smart UV Project" script.
> Possible improvements could include (i. e. downsides of the current
> implementation):
> - Work efficiently, even with high poly models
> - Do not generate tiny UV islands (i. e. those consisting of only one or
> two faces. They could be merged with another island in most cases.)
> - Generate preferably rectangular islands, break up big islands. This
> will improve the UV packing results.
>
> Requirements: Python. C may also be required for performance reasons.
>
> Difficulty: Medium?
>
> Possible mentors: ???
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> https://lists.blender.org/mailman/listinfo/bf-committers
>
___
Bf-committers mailing list
Bf-committers@blender.org
https://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Blender developers meeting notes - 2018-11-19

[Jacob Merrill]

Great work everyone!

I really love eevee volumetrics,

I was just wondering how interactive mode was coming along?

also will stars make a re-appearance ?
I miss that feature but I feel it could be done really well with
volumetrics now.

On Mon, Nov 19, 2018 at 10:00 AM Brecht Van Lommel <
brechtvanlom...@gmail.com> wrote:

> Hi all,
>
> Here are the notes from today's developer meeting. Next meeting is Monday,
> 26 November 18:00 CET (17:00 UTC).
>
> 1) New features and changes
>
> * Left click select was modified to be more compatible with the tool
> system. This will continue to be improved to address various usability
> issues.
> * New popover for collection visibility in 3D viewport header.
> * New Eevee features:
> ** New light threshold value, needed to support light culling in the
> future.
> ** Glossy reflection filter quality and clamping settings.
> ** Irradiance smoothing setting, to smooth interpolation between irradiance
> volume cells.
> * Physics system editing and playback should work a lot more reliable now
> in 2.8.
> * Most of the themes were removed as they are outdated. There is a call for
> the community to provide updates and replacements:
> https://devtalk.blender.org/t/call-for-content-themes/3174
> 
> https://www.youtube.com/watch?v=CvsSk0S6B5A
>
> 2) Blender 2.8 beta
>
> The meeting spent a long time reviewing the status of 2.8 in the context of
> the upcoming beta release. There are still some loose ends remaining,
> though we are getting closer. We will evaluate the status again next
> Monday.
>
> Some topics that came up:
> * Motion tracking UI changes broke too much, will be reverted to the old
> 2.7 toolbar until there is a better replacement for it.
> * Decision about notifiers/message bus: restore notifiers, and remove them
> one-by-one once the message bus becomes aware of those. This closes a lot
> of missing update issues.
> * Particle edit mode needs to have drawing code updated, to do proper hair
> shading and to support weights visualization.
> * Python API is going well, though a couple of areas which needs more love:
> multi-object-edit and tools integration
> * OpenSubdiv needs to be enabled by default. Not a stopper for Beta, but
> still some work to be done afterward.
>
> 3) Next week plans
>
> * Bastien works on Python API and bug fixing.
> * Brecht works on industry compatible keymap and left click keymap
> improvements.
> * Campbell works on improving tool system and keymaps.
> * Clément continues viewport and Eevee work.
> * Dalai works on local view and visibility.
> * Jacques works on background images and Python API.
> * Pablo works on release notes on blender.org.
> * Philipp works on bug tracker.
> * Sergey works on studio issues, physics and OpenSubdiv.
>
> 4) Weekly reports
>
> * Bastien:
>
> https://wiki.blender.org/wiki/User:Mont29/Foundation/2018#Week_270_-_11.2F10_to_11.2F16
> * Brecht:
> https://wiki.blender.org/wiki/User:Brecht/Reports/2018#November_12_-_17
> * Campbell:
>
> https://download.blender.org/ftp/ideasman42/donelist/2018.html#week-300-november-12
> * Clément:
>
> https://wiki.blender.org/wiki/User:Hypersomniac/Foundation/2018#Week_96_:_5th_-_11th_Nov
> * Dalai:
> https://wiki.blender.org/wiki/User:Dfelinto/Reports/2018#November_12_-_16
> * Jacques:
>
> https://wiki.blender.org/wiki/User:JacquesLucke/Reports/2018#Week_9:_November_12-16
> * Philipp:
>
> https://wiki.blender.org/wiki/User:PhilippOeser/Foundation/2018#Week_46_.28Nov_12th_-_Nov_16th.29
> * Sergey:
>
> https://wiki.blender.org/wiki/User:Sergey/Foundation/2018#Week_361:_12th_-_18th_November
> 5) Other projects
>
> * Blender XR (VR/AR user interface for Blender) wants to join the team and
> work on releases.
> https://www.marui-plugin.com/blender-xr/
> ___
> 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] glTF2.0 importer/exporter addon

[Jacob Merrill]

Will this be supported/backported in 2.79x?

2. Can meshes be programically created (vertex index / materials /uv etc?)
Without creating a blender mesh and exported?

If so the game engine could export kx_meshProxy and blender could reimport
them (for procedural content or in game created content)

On Nov 10, 2018 6:01 AM, "Norbert Nopper"  wrote:

Hello everybody,

for long term development and maintenance, we will have daily changes
and fixes in the [2] repository. If we have a major and/or critical
update, we also want to provide and integrate it into future versions of
Blender.

Regards Norbert



Am 10.11.2018 um 09:57 schrieb Julien Duroure:
> Dear all,
>
> I just submitted glTF2.0 importer / exporter addon in dev.b.org
>  [1].

> This addon from KhronosGroup is currently on development, here are
> current statut [2] with latest developments.
> As discussed with Ton, Brecht & Bastien during bcon, we'd like to have
> this addon directly included into Blender for 2.80 beta.
> Please review the code, and come back to me/us if you have any questions.
> As discussed, this addon is still in development and when included
> into blender, we will need commit access to be able to maintain it.
>
> Cheers,
>
> Julien
>
> [1]: https://developer.blender.org/T57763
> [2]: https://github.com/KhronosGroup/glTF-Blender-IO
>
> --
> Julien DUROURE
> http://julienduroure.com
>

-- 

*UX3D GmbH*
GPU Software Solutions

Norbert Nopper
Managing Director
Görresstrasse 17
80798 Munich, Germany

T: +49 (0)89 215 44 258 2
F: +49 (0)89 215 44 258 8
nop...@ux3d.io 
www.ux3d.io


___
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] FM 2.8 Proposal : Fracturing, Cache, Rigidbody

[Jacob Merrill]

what about caching a volume ?

use round / position to get the volume adress that ownes the thing

this way we have a fixed size array of lists of chunks each space ownes?

On Tue, Jun 12, 2018, 10:29 AM Brecht Van Lommel 
wrote:

> For baking we normally simulate all frames, and even when we don't the cost
> of merging two Alembic files is probably acceptable. However for caching
> while doing animation playback this is not the case. We can simulate some
> frames, play back the frames simulated so far, and then continue simulating
> more frames. So that makes a single Alembic file not a great fit.
>
> I think the main motivation to use Alembic is that the data structures are
> more complicated than we had before, and our custom point cache format is
> quite basic. Previously we just had to store vertex position/velocity/..
> for every frame. With fracture we need to store the fractured mesh and its
> topology, as well as the transforms per island. As I understand such
> islands can be dynamically fractured off, so the mesh topology and active
> islands can change over time. Combine that with the requirement of fast
> random access for a given frame, things get quite complicated.
>
> So I'm not sure what the right solution is to be honest. For fast random
> read/write something like this could work:
> * For every frame, write a point cache file in the same format we already
> use. This would contain an array of island index, island transform, and any
> other time varying data about active islands.
> * In a separate file, store list of islands, their topology and any other
> static data. When reading a frame, we'd read just the active islands. When
> new islands are created during the sim, we could append to this file.
>
> It would be better if we could a standard file format though, but which
> ones support appending? Alternatively we could just say, fracture modifiers
> is not something that works realtime anyway, so if we have to accept the
> overhead of rewriting the same Alembic file many times it might not be that
> bad.
>
>
> On Tue, Jun 12, 2018 at 6:00 PM dr. Sybren A. Stüvel 
> wrote:
>
> > This is a response to
> >
> https://lists.blender.org/pipermail/bf-committers/2018-February/049157.html
> > (I removed it from my mail server, so I can't hit 'reply' directly)
> >
> >
> > On 26-02-2018 22:54, Brecht van Lommel wrote:
> >
> > > Thanks for the explanation. Overall I agree with the approach.
> > >
> > > It would be very helpful if this kind of functionality was submitted
> for
> > > review and integration in smaller parts. For example:
> > > [...]
> > > * Add Alembic support to point caches for physics systems. (could even
> > > replace custom point cache format)
> >
> > Alembic is stricly a write-once file format [1]. This means that we
> > cannot update a part of a file; say the file contains frame range 1-250,
> > we won't be able to re-simulate frames 150-250 and update the file for
> > that. It can only be "updated" by reading the old file, updating its
> > contents where necessary, and writing to another file. Furthermore, an
> > Alembic file cannot be read until it is properly written *and closed*.
> >
> > With this info about Alembic, what do you think about using Alembic
> > files for such caches? I'm not yet all that familiar with the current
> > physics caching system, but I do know it creates a file for every frame,
> > making it trivial to update frames. Is this actually used, though? Or
> > are we always sequentially writing to the cache?
> >
> > We could work around these limitations of Alembic by writing continuous
> > frame sequences to a single file (so if you simulate 1-100 and then
> > press ESC, it would write to sim-001-100.abc), which can then be read
> > when replaying those frames. Simulating other ranges would then save to
> > other Alembic files (e.g. sim-101-140.abc). This could potentially
> > produce many small files, though, or cause problems where objects exists
> > in one file but not the other. Then again, we could have code to merge
> > sequences of Alembic files.
> >
> > If not Alembic, what would be a good cache file format? Ideally I'd like
> > to use something that's already proven technology, rather than thinking
> > up something ourselves.
> >
> > [1]
> >
> https://groups.google.com/d/msg/alembic-discussion/X-2ue86pw5g/Z2fZpW1eAgAJ
> >
> >
> > --
> > Sybren A. Stüvel
> >
> > https://stuvelfoto.nl/
> > https://stuvel.eu/
> >
> > ___
> > Bf-committers mailing list
> > Bf-committers@blender.org
> > https://lists.blender.org/mailman/listinfo/bf-committers
> >
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> https://lists.blender.org/mailman/listinfo/bf-committers
>
___
Bf-committers mailing list
Bf-committers@blender.org
https://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Blender developers meeting notes - 2018-06-11

[Jacob Merrill]

Still no lightfields or prebaked light probes?

why not make eevee realtime eh?

On Mon, Jun 11, 2018, 9:34 AM Dalai Felinto  wrote:

> Hi all,
>
> Here are the notes from today's 17 UTC (18 CET) meeting in
> irc.freenode.net
> #blendercoders. Reminder: meetings are on Mondays, next meeting is 18th
> June 09 UTC (10 CET).
>
> 1) Blender 2.8
>
> * There is a call for content for MatCaps:
>  - https://devtalk.blender.org/t/call-for-content-matcaps/737
>
> * The bug tracker needs to be re-open. There is no decision to when do it,
> but we will try to come up with a plan to present in the meeting.
>
> * Also as per previous discussions we don't want to move 2.8 to master
> before we re-open the tracker. An attack plan for that will be elaborated
> during the bug tracker plans.
>
> * Grease pencil patch will be reviewed this week by Campbell Barton and
> Sergey Sharybin. Antonio Vazquez updated it to be up to date with the
> branch.
>
> 2) Other projects
>
> * Ray Molenkamp reminds that the buildbot needs upgrade, so we can
> officially drop msvc2013 support. The linux buildbot also needs upgrade.
> Sergey Sharybin is looking at it.
>
> * Campbell Barton confirms that we are still on track to the original
> deadline (June 15th, make the old wiki read-only).
>
> * Blender is on Annecy festival with a booth during the entire week. Drop
> by to say hi.
>
> 3) Code quest links:
>
> * Weekly meeting notes - 2018-06-08
>  - https://lists.blender.org/pipermail/bf-committers/2018-June/049467.html
>
> * Tasks done last week:
>  -
>
> https://wiki.blender.org/index.php/Dev:2.8/Source/CodeQuest/WeeklyReports#Week_9_.2804.2F06_-_08.2F06.29
>
> * Code quest workboard:
>  - https://developer.blender.org/project/board/80/
>
> * Videos:
>  - 2.8 against 2.7
>  - https://www.youtube.com/watch?v=7pctJzQP7vs
>
>  - EEVEE Hair Improvements
>  - https://www.youtube.com/watch?v=YHs9u3P_X1I
>
>  - Custom MatCaps
>  - https://www.youtube.com/watch?v=NPCxUKrUzfM
>
>  - Week 9 Round-up
>  - https://www.youtube.com/watch?v=0A6x2e5qRYE
>
> Regards,
> 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 developers meeting notes - 2018-06-04

[Jacob Merrill]

could gracefully handeling multiprocessor module be a priority?
(like launching a instance of py distributed with blender?)

currently it just pops open another instance of blender which is not so
handy.

On Mon, Jun 4, 2018, 1:35 AM Dalai Felinto  wrote:

> Hi all,
>
> Here are the notes from today's 09 UTC (10 CET) meeting in
> irc.freenode.net
> #blendercoders. Reminder: meetings are on Mondays, next meeting is 11th
> June 17 UTC (18 CET).
>
> 1) Blender 2.8
>
> * Antonio Vazquez is preparing a blog post for the upcoming merge.
>
> * He will update the patch today, since all the changes suggested by the
> last of review were already addressed in the branch.
>
> * Copy-on-write is no longer optional and we now have a single
> copy-on-write-aware editing context. That makes most of the operators to
> work out of the box. We still need to go over the task force list and make
> sure tagging is happening properly though.
>
> * The temporary task force status page got a visual remodeling:
> http://stats.dalaifelinto.com/
> Date of the data will come next. But now we have analytics support (~50
> visitors day).
>
> * The multi-object task force is being on a semi-official halt. Reviewing
> patches takes more time than we can afford during the code quest. But they
> will be given the proper attention after July 15.
>
> 2) Google Summer of Code / Other projects
>
> * No Google Summer of Code student had any topic to bring up.
>
> * Wiki migration: deadline to move existent wiki to read-only mode is June
> 15. Meeting derailed in a discussion regarding how much data we can keep of
> the old one, and if it will be only html, or also page sources. The
> migration team will discuss this further and present a solution.
>
> 3) Code quest links:
>
> * Weekly meeting notes - 2018-06-01
>  - https://lists.blender.org/pipermail/bf-committers/2018-June/049454.html
>
> * Tasks done last week:
>  -
>
> https://wiki.blender.org/index.php/Dev:2.8/Source/CodeQuest/WeeklyReports#Week_8_.2828.2F05_-_01.2F06.29
>
> * Code quest workboard:
>  - https://developer.blender.org/project/board/80/
>
> * Videos:
>  - Viewport Look Dev
>  - https://www.youtube.com/watch?v=Hz5wD6cHtuk
>
>  - New Shortcuts + LookDev Updates
>  - https://www.youtube.com/watch?v=TK3tgfPZ9SQ
>
>  - Single Column Layout
>  - https://www.youtube.com/watch?v=_WBqTeLcsxU
>
>  - WIREFRAMES
>  - https://www.youtube.com/watch?v=pcOk-SYxllg
>
>  - Week 8 Round-up
>  - https://www.youtube.com/watch?v=NMj-an79Now
>
> Regards,
> 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] Code quest: updated data design

[Jacob Merrill]

can a NPR workspace be created?

some sort of toon shader with realtime outlines?
(for the classic comic line work rendering style)

this is very important to people making games and movies.


On Fri, Apr 20, 2018, 7:46 AM Brecht Van Lommel 
wrote:

> Hi all,
>
> Here's an updated data design for Blender 2.8 as agreed in the Code Quest
> meetings:
> https://wiki.blender.org/index.php/Dev:2.8/Source/DataDesign
>
> It's intended to explain how the new features like view layers,
> collections, workspaces and overrides are intended to fit together on a
> high level. Note that not all of this has been implemented at this point.
> If anything is unclear or seems wrong, let me know.
>
> Thanks,
> Brecht.
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> https://lists.blender.org/mailman/listinfo/bf-committers
>
___
Bf-committers mailing list
Bf-committers@blender.org
https://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] How can I tailor and optimizing the Blender architecture for BIM

[Jacob Merrill]

checout upbge and it's optimizations like static mesh batching,
physics mouseover select based on physics layer and lightning optimizations.

then look into forward+ light cuts using a bvhtree for performance later if
lighting is to be used,

the game engine is very well suited for realtime simulations

https://github.com/UPBGE

placing the building materials in a layer that's collision mask does not
collide with it's own layer is useful for physics and for large open areas
and 1000s of objects, a loading grid can prevent scenegraph bloat.



On Mar 19, 2018 3:03 AM, "Feng_Duan 段锋"  wrote:

> Hi, all:
> Our team worked in BIM for 5 years. Now we want to change the 3D framework
> of our software. The old framework , of which the performance is can't
> satisfied our need. Blender is very suit for our propose. But we are not
> professional in Blender.
>
> Could you prefer to advice or Instruct our developers to tailor and
> optimize the Blender architecture so that Blender can use the development
> needs of BIM software.
>
> Contract me if you prefer to.
>
> Thanks
>
> feng
>
> ___
> 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 game transition

[Jacob Merrill]

I recently used ue4 engine for a paid project,
and I used blueprints, Looking back at old logic system,
it is much easier to use. but limited.

what I purpose is this,
I think that we should keep the logic bricks,
but there needs to be a few changes made.

1. logic substeps [ 0 - 10 or more]
similar to 'run first' but with 10 steps, so that events can happen in a
order.

2. sensor positive pulse is actually data [not just 'on']
I purpose that instead the flag for proccessing a controller is a tuple of
the data from the sensor.

3. Sensor Set Actuator
linking a sensor to a actuator sends it all of its target properties.
[ie ray sends ray.hitObject , ray.hitPosition, ray.hitDistance etc]
this way these properties can be used as input values in a actuator.

4.control mapping sensor -- when it fires it compares input string vs a
dictionary, if the string is on the dictionary, the key is used to put the
data on the output list linked to that key.
('WKEY') : ('Forward', index)
this list is then sorted by the index value, and doubles are stripped and
the index. creating ('Forward','Right') from [ ('Forward',0),('Right',3)]

(now we can easily create keybinding screens that generate input dictionary)

python users can take active input vs a dictionary to output a state, or
filtrr for inputs ie.
if 'Forward' in input:

and logic users can do
inputMap = str(Input)

and filter using the string
if Move == "('Forward')"--and-[walk state]


with these changes, we get the best of blueprints and logic bricks and none
of the drawbacks.



On Mar 19, 2018 5:28 AM, "yul brynner"  wrote:

> Hi, as suggested by hackerman, I share my thought/plans draft for
> interactive mode:
>
>
> Interactive mode ideas/proposals:
>
> These ideas doesn't include logic changes because I don't know UI code. If
> developers wants to change logic,
> this should be done before what I propose.
>
> So as far I understand, the bge loop works like that:
>
> - First logic, animations, and physics are updated
> - Then render is done
>
> I propose to progressively insert depsgraph DEG_id_tag_update (python API
> + new functions to replace old ones):
> - in the first step of the pipe
> - just after the the first step of the pipe BUT before render
>
> to have the ability to use blender power (like modifiers update in
> realtime I guess) inside BGE.
>
> I think this will allow to remove a lot of BGE code (which is currently
> not so important), and this would allow the volounteer
> core coders to use the code they are familiar with.
>
> BGE can remain coded in C++ (which is a big advantage imo because new
> coders can learn it more "easily")
>
> and stay a separate "small" entity beside Blender, but using directly
> Blender code.
> The fact BGE remain a "separate" entity doesn't prevent that we can use
> directly Blender code and
> have something which is however very tied to Blender.
>
> The advantage to keep a separate entity is that once we have a module
> owner (not me because I'm too newb and I don't want to be
> the leader of anything), we can work on a "small" pipeline, which is much
> more easy than to work on entire Blender code I guess.
> And we can work with more freedom if we keep a separate entity.
>
> About custom classes for BGE, like KX_GameObject, this can be kept imo for
> now. KX_GameObject is just an Object with custom attributes and functions.
> For example, in my branch, when I want to update KX_GameObject matrix, I
> use "KX_GameObject's Object->obmat". KX_GameObject is just the container of
> Object.
> But KX_GameObject currently contains other attributes and functions which
> are currently needed to make BGE code work. So we can't use directly Object
> in a first time. Keeping in ming that the goal is to reuse maximum of
> Blender code directly, maybe we could avoid to use KX_GameObject and use
> directly Object,
> but more important changes have to be done before.
>
> To make the BGE code more tied to Blender code, I propose to first:
>
> - Write a new KX_GameObject API with Blender code.
> . This API just needs 2 functions: Add and Remove object
> . This API should use BKE_object functions (I guess) and depsgraph
> DEG_id_tag (I guess too)
> to say to the BGE viewlayer's depsgraph that a new Object has been
> added/removed.
> . The function to update depsgraph (BKE_scene_graph_update_tagged(eval_ctx,
> depsgraph, bmain, scene, view_layer);)
> is called just before render in my branch. Then a complete eevee's render
> loop is runned (DEG_OBJECT_ITER is runned to populate the render
> cache with the needed objects, then the scene is drawn, then we
> swapBuffers and start a new frame).
> . We have to find a system to erase all replicated Objects at BGE exit and
> restore original Object state at BGE exit. A class to save/restore states
> can be done.
> - Replace MOTO (math library with BLI_math).
> ..
> And always keep in mind that we have to reuse maximum of blender code.
>
> What is the 

Re: [Bf-committers] Blender developers meeting notes - 2018-03-05

[Jacob Merrill]

I noticied the Disney PBR nodes now work in glsl mode and bge, but not
standalone mode.

Thank you for the bge support!!
but could we have the ability to publish standalone?

the creator of Krum was asking*

top notch work all!



On Mar 5, 2018 1:38 AM, "Bastien Montagne"  wrote:

> Hi all,
>
> Here are the notes from today's 09 UTC (10 CET) meeting in
> irc.freenode.net #blendercoders.
> Reminder: meetings are on Mondays now, next meeting is 12 March, 17 UTC
> (18 CET).
>
> 1) Blender 2.79 'a' release
>
> - Released last week, unfortunately we already have a regression in 'a'
> regarding hard-cut of sequencer’s strips, so we’ll likely need a 'b' within
> a few weeks.
>
> 2) Blender 2.8 projects
>
> Not much to report this week, people were doing small fixes etc. mostly,
> we also need some planning for upcoming Code Quest event in April in
> several areas.
>
> - Weekly reports:
> -- Sergey Sharybin: https://wiki.blender.org/index
> .php/User:Nazg-gul/Foundation/2018#Week_326:_26th_February_-_4th_March
> -- Joshua Leung: https://wiki.blender.org/index
> .php/User:Aligorith/Foundation/2018#February_26_-_March_2
> -- Dalais Felinto: https://wiki.blender.org/index
> .php/User:Dfelinto/Foundation18#Week_8_.28February_26th_-_2nd.29
> -- Clément Foucault: https://wiki.blender.org/index
> .php/User:Hypersomniac/Foundation/2018#Week_60:_26th_-_4th_March
> -- Campbell Barton: http://download.blender.org/ft
> p/ideasman42/donelist/2018.html#week-363-february-26
> -- Bastien Montagne: https://wiki.blender.org/index
> .php/User:Mont29/Foundation/2018#Week_233_-_02.2F24_to_03.2F02
>
> 3) GSoC & Other Projects
>
> Blender is in this year again, now is time for students to get in touch
> with the team, proposals submissions start on 12th of March.
>
> - Bastien Montagne is finishing review & polishing of 2017’s GSoC on
> normal editing tools buy Rohan Rathi, should be ready for final review this
> week.
>
> 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

Re: [Bf-committers] Blender developers meeting notes - 2018-02-26

[Jacob Merrill]

I meant to attend and was absent*

I had 1 question. it's for something very long term.

could there be some collaboration between simulations?
seperate fire sim, fluid sim, and rigid bodies seems over simplified to me.

an 'energy, state, and bond' system that  handles

a.heat
b.rigid body simulation
c.fluid dynamics
d.gaseous and plasma interactions / light emission

this way a beam of light could melt wax, (solid to fluid transition)
or a laser could melt or vaporize steel etc. (solid to gas)
or even create plasma/caustics (solid to plasma)





thanks for blender!

On Feb 26, 2018 10:14 AM, "Dalai Felinto"  wrote:

> Hi all,
>
> Here are the notes from today's 17 UTC (18 CET) meeting in
> irc.freenode.net
> #blendercoders. Reminder: meetings are on Mondays, next meeting is 05
> March, 09 UTC (10 CET).
>
> 1) Blender 2.79 'a' release
>
> Final release will happen by Wednesday.
>
> 2) Code Quest
>
> * The campaign is doing well. Note that the rockets will go up $10 in two
> days.
>
> * The number of sponsors of all categories is also increasing steadily.
>
> * Unless notified otherwise, the code quest will start April 9th with most
> of the team arriving a week before. Campbell arrives March 16th, and Brecht
> March 30th.
>
> 3) Blender 2.8 projects
>
> In the coming days users should be able to use Eevee with multi-window,
> non-blocking F12 renders, and compositor fully working:
>
> * Multi-window support is coming later today. Clément Foucault is about to
> merge the work he did with help from Brecht Van Lommel and Germano
> Cavalcante. It also handles non-blocking F12 rendering for Eevee.
>
> * Compositing / multi-layer rendering for Eevee is coming today/tomorrow as
> well. Dalai Felinto is done with the changes required for Eevee. But Cycles
> and sequencer are still pending.
>
> * Workspace UI filtering is also ready. Campbell Barton to merge it early
> this week.
>
> * Antonio Vazquez announced he is working on textured strokes for grease
> pencil.
>
> * Fracture Modifier proposal was posted and waiting more feedback:
> https://lists.blender.org/pipermail/bf-committers/2018-
> February/049150.html
>
> In order to prepare everyone's expectation to the upcoming Code Quest,
> Dalai Felinto will work with Pablo Vazquez in a richly illustrated blog
> post with the current state of 2.8. It should be out in early March.
>
> 4)  Google Summer of Code and other projects
>
> * We need more mentors for GSoC. Let Ton know if he should add you!
>
> * Calendar: March 12th submission for students start, with reviewing period
> during the 1st week of April.
>
> * On-boarding forum (https://devtalk.blender.org/) should be officially
> open soon. We still need to sort Blender ID login before it can be widely
> announced though. We also need well defined ownership of the site with
> admins/moderators, with granted autonomy to manage the site.
>
> * Module ownership to be updated on wiki. For example, greasepencil owners
> should be the developers Antonio Vazquez and Joshua Leung, with the artists
> Daniel Pepeland and Matias Mendiola listed as team members.
>
> 5) Weekly reports:
>
> * Bastien Montagne:
> https://wiki.blender.org/index.php/User:Mont29/
> Foundation/2018#Week_232_-_02.2F17_to_02.2F23
>
> * Campbell Barton:
> http://download.blender.org/ftp/ideasman42/donelist/2018.
> html#week-362-february-19
>
> * Clément  Foucault:
> https://wiki.blender.org/index.php/User:Hypersomniac/
> Foundation/2018#Week_59:_19th_-_25th_February
>
> * Dalai Felinto:
> https://wiki.blender.org/index.php/User:Dfelinto/Foundation18#Week_7_.
> 28February_19th_-_23th.29
>
> * Joshua Leung:
> https://wiki.blender.org/index.php/User:Aligorith/
> Foundation/2018#February_19_-_February_23_.28
>
> * Sergey Sharybin:
> https://wiki.blender.org/index.php/User:Nazg-gul/
> Foundation/2018#Week_325:_19th_-_25th_February
>
> Best regards,
> 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] FM 2.8 Proposal : Fracturing, Cache, Rigidbody

[Jacob Merrill]

ideally, a simulator would take energy(light) Solids, liquids and gases and
plasma in 1 simulation,

(so a laser impact can melt, vaporize, as well as emit residual light as
the laser passes)


a 'unified solver' would be spectacular

On Feb 26, 2018 8:59 AM, "Martin Felke"  wrote:

Am Montag, den 26.02.2018, 15:29 +0100 schrieb Brecht Van Lommel:
> Am I understanding correctly that you are proposing to keep all fracture
> data within one Object datablock? And then there would be a "Convert"
> button on the modifier that generates multiple objects, which are then no
> longer influenced by the modifier? If so that makes sense to me. Even if
> many objects were faster, procedurally generating datablocks is not
> supported by Blender design currently and trying to tack it on would cause
> problems.

Yes, I want to have something like a collection of mesh islands over
either one shattered Mesh Datablock, or even outsourcing the "generated"
data to a geometry cache, which is written  to an Alembic file for
example and being read back by something similar like the meshsequence
cache modifier. Each of those islands should be an "Item" in the cache.
And the rigidbody data should be "attached" per island like custom data
is with vertices, edges, loops, polys. I find the custom data concept
quite interesting for that usecase as well.
If it is ok to keep one regular (DNA) stored Meshdatablock as fracture
result in the background, being "overwritten" by new fractures,
also each poly could carry a custom data layer with an mesh island
index, means each poly knows to which island it "belongs".
With the help of this minimal storage one could at load time build a
runtime collection of mesh islands in the modifier or more generally
spoken, in a geometry cache component.
Additionally to that, since constraint buildup is relatively fast, those
dont need to be stored at all anymore, but being rebuilt at load time.
Alternatively, to having all in one Object, is it planned to have
something like Collection Modifiers ? where a collection of objects is
being treated as an object itself and could be fed into the modifier
stack and where the modifier emits a modified collection
(which is treated as one object / ID again ?)
Something similar to this could be some kind of "Pack Geometry"
functionality, which not just joins all into one mesh, but keeps
separate object's settings separate and individually changeable ?
Like some "container" object ?
But i guess just making a fractured mesh with island info as poly layer
could be the most straightforward approach.
The "Convert" button in fact exists already for the FM, making each
meshisland a separate object. (to simulate the objects in other blender
builds for example)

> It's just a bit confusing because you are saying "cross-object constraints
> will be managed by a dedicated constraint-only Modifier" for example. Are
> we talking about actual object datablocks, constraints and modifiers? Or
> just something that happens internally and doesn't affect any actual
> datablocks? Or both, where the "Convert" button generates objects with
such
> constraints or modifiers, and if it's all within one object it happens
> internally?

Sorry for the confusion about "cross - object constraints". Those are a
relatively new FM feature and allow to "glue" islands together across
nearby / adjacent fractured objects. Currently an extra object
referencing a group of to-be-glued objects thru the FM is responsible to
just maintain constraints between islands of the fractured objects
within that group. I mentioned this for the sake of completeness only,
this is advanced functionality. (Here one object respectively
one FM can hold many islands and many constraints, in the current
design.) The "dedicated" modifier is just a "normal" FM with special
settings in this case.
I think I should further go into more advanced functionality only after
the basic concepts are clear / being agreed on. But OTOH i also wanted
to make sure the "basic" design is "powerful" enough to be able to deal
with the more advanced things which will build upon it.

> I suggest to not talk about Python modifiers or more generic modifier
cache
> systems here. This is already a very complicated topic, just integrate it
> with existing physics modifier and cache designs and do any bigger changes
> separately.

Ok, agreed :) It is a very complicated topic. I just tried to think out
of the box since the existing Pointcache cannot dynamically grow and
shrink (to my understanding, the total number of "Points" is fixed atm)
and this would allow other advanced features like dynamic fracturing
for example.
I have a "customized" solution for this currently in the FM. The FM
basically stores a sequence of meshisland lists currently, which is
extended at each fracture event. Furthermore each meshisland stores its
own "motion history" (locations, rotations) per frame (as long as the
island exists, e.g. it disappears if 

Re: [Bf-committers] Blender developers meeting notes - 2018-01-22

[Jacob Merrill]

any word on upbge proposal by youle?
a timetable for the ge project would be nice.

On Jan 22, 2018 1:34 AM, "Bastien Montagne"  wrote:

> Hi all,
>
> Here are the notes from today's 09 UTC (10 CET) meeting in
> irc.freenode.net #blendercoders.
> Reminder: meetings are on Mondays now, next meeting is 29 Jan, 17 UTC (18
> CET).
>
> 1) Blender 2.79 'a' release
>
> - Looks like we are ready for testbuild, AHOY should happen later today.
>
> 2) Blender 2.8 projects
>
> - Dalai Felinto, with help from Pablo Vazquez for UI, added filtering to
> the Outliner, check https://developer.blender.org/
> rB37913cf5326a732cb94c28f96c1deb8f3965c846 for details.
>
> - UI team is making a call for volunteers to help design new icons needed
> by 2.8 projects, see https://developer.blender.org/T53840.
>
> - Sergey Sharybin was busy getting cameras to work with new CoW depsgraph.
>
> - Weekly reports:
> -- Sergey Sharybin: https://wiki.blender.org/index
> .php/User:Nazg-gul/Foundation/2018#Week_320:_15th_-_21st_January
> -- Dalais Felinto: https://wiki.blender.org/index
> .php/User:Dfelinto/Foundation18#Week_3_.28January_15th_-_19th.29
> -- Clément Foucault: https://wiki.blender.org/index
> .php/User:Hypersomniac/Foundation/2018#Week_54:_15th_-_21st_January
> -- Campbell Barton: http://download.blender.org/ft
> p/ideasman42/donelist/2018.html#week-357-january-15
> -- Bastien Montagne: https://wiki.blender.org/index
> .php/User:Mont29/Foundation/2018#Week_227_-_01.2F13_to_01.2F19
>
> 3) Other Projects
>
> Nothing to mention here this time…
>
> 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

Re: [Bf-committers] Blender 2.8 - priorities reconsideration proposal (revised)

[Jacob Merrill]

for new tool system,
I have been toying with an idea for upbge

https://youtu.be/vgXHhty9Bec

basically
kdtree = kdtree.FromMesh() # accelerated rebuilding tree

math = (some c friendly api for applying math)
mesh.stroke(math,kdtree.kd.find_range(strokeCenter, radius))

to be able to select and effect large sets of data, in py without needing a
addon.

'tool tips'


On Nov 20, 2017 4:26 PM, "Julian Eisel"  wrote:

> Hi,
>
> Parts of the new tool-system may indeed be a can of worms. So agree,
> it might be better to postpone it.
>
> I don't think the part of the top-bar with the operator redo settings
> should be postponed though. I've already done most of the work, and I
> think it's a small task to get the rest done. At the same time,
> outcome could be great.
> To not spam this thread with top-bar discussion, I created a separate
> thread in bf-interface
> https://lists.blender.org/pipermail/bf-interface/2017-November/000272.html
> .
> I will try to get further testing & feedback to see how far it is from
> being done.
>
> It also bothers me to still not see a proper mention of the keymap
> revamp. "Workspace specific keymaps" would only be (minor) overrides
> to the default keymap per workspace. Ton pointed out the keymap
> changes may be part of templates. However, I think it really is its
> own project.
> Remember, redesigning our default keymap is unlikely to happen before
> 3.0 if we fail to deliver it for 2.8. At the very least, we should
> discuss if this is acceptable or not.
>
> Cheers
> - Julian -
>
> On 20 November 2017 at 20:30, Ton Roosendaal  wrote:
> > Hi,
> >
> > There's a mixup of two bars here.
> >
> > We still get a bar to select scene, layer, workspace, mode, but the 2nd
> bar with operator redo, and tool buttons (operator widget system) gets
> postponed. A revision of the tools and operator system is going to be a can
> of worms and hard to do well. Needs more design time, a reason we postpone
> it.
> >
> > Note: nothing gets cancelled - it's also a productivity workflow trick
> (for developers). Get first something done and finish it entirely. Not as
> in 'coder says he's done' but as in 'happy and productive users'. I think
> that's the gist of Agile Development :)
> >
> > -Ton-
> >
> > 
> > Ton Roosendaal  -  t...@blender.org   -   www.blender.org
> > Chairman Blender Foundation, Director Blender Institute
> > Entrepotdok 57A, 1018 AD, Amsterdam, the Netherlands
> >
> >> On 20 Nov 2017, at 20:01, Aaron Carlisle 
> wrote:
> >>
> >> I am really surprised to see that the top-bar is being dropped for the
> >> initial release as it seems to me that most of the work is done or
> close to
> >> it with only a couple of design issues to be fixed.
> >>
> >> Also, I do not see any mention of the asset engine. Is this still a
> target
> >> or has this been dropped?
> >>
> >> Aaron Carlisle
> >>
> >> Picture taker | Bit cruncher | Pixel pusher | Document writer | Artist
> >> Project administrator for the Blender 3D Documentation Project
> >>
> >> On Mon, Nov 20, 2017 at 12:11 PM, Ton Roosendaal 
> wrote:
> >>
> >>> Hi Dalai,
> >>>
> >>> Thanks for the update. The first version was a bit confusing indeed.
> (as
> >>> if some targets got cancelled)
> >>>
> >>> I fully agree on keeping the focus as narrow and feasible as possible.
> The
> >>> targets for 2.8 are very intimidating and complex. Let's now first
> finish
> >>> all current ongoing projects and make it ready for daily use.
> >>>
> >>> Thanks,
> >>>
> >>> -Ton-
> >>>
> >>> 
> >>> Ton Roosendaal  -  t...@blender.org   -   www.blender.org
> >>> Chairman Blender Foundation, Director Blender Institute
> >>> Entrepotdok 57A, 1018 AD, Amsterdam, the Netherlands
> >>>
>  On 20 Nov 2017, at 17:56, Dalai Felinto  wrote:
> 
>  *[Note: The first version I sent was a bit unclear, so this is the
> one to
>  be considered instead.]*
>  Dear all,
> 
>  While we are strong in our goal to release Blender 2.8 next year, we
> kept
>  adding project targets for it at a growing pace. Now it is the time
> to go
>  back and reconsider our priorities.
> 
>  Blender 2.8 is not ready for production work yet. This makes the
> timing
> >>> not
>  right for the development to drive enough interest from everyone. And
> it
>  doesn’t make sense to pursuit the new Blender without our users and
>  volunteers to push the design of core components further.
> 
>  Therefore we are postponing as current 2.8 technical targets:
> 
>  * Top bar
>  * Manipulators
>  * Tools
>  * Workspace specific keymaps, add-ons.
> 
>  Manipulators and tools will still be around as an API for add-ons. So
> >>> users
>  can still experiment with custom manipulators, facemaps and the tool

Re: [Bf-committers] Blender-code Questions

[Jacob Merrill]

what about a forum and also the blender discord?

there is a blender coder section but it's mostly bpy and a game engine
section, what if Jerry adds a developer area?

chat is persistent and it marks where you left off as well as mentions
you can share files etc as well.

On Nov 8, 2017 6:38 AM, "Fable Fox"  wrote:

> I agree on the forum and ideas mentioned in the mailing list regarding how
> Rust did it.
>
> I too have to drop out after the chat meeting time change. Can't do it on
> work hours (one fall at 5 PM) and the other is 1 AM.
>
> I also notice that mailing list is not where to do it, because topic are
> arranged by date instead, and forum are way way better for thing like this.
> And reading it in inbox, there are too much quotes.
>
> I notice these days a lot of forum have died because social communications
> have moved to social media.  But for stuff like this, forum is still the
> way to go.
>
> --
> Fable Fox
> fable...@fablefox.com
> http://www.fablefox.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-code Questions

[Jacob Merrill]

https://blender.stackexchange.com/

On Tue, Nov 7, 2017 at 4:24 PM, spock theGray 
wrote:

> Hi guys,
>
> Sometimes I have Blender code-related questions for which I don't need
> real-time help like IRC or maybe nobody is on in IRC at that time who is
> able to answer, etc. In this case, I would be totally cool with just
> posting something somewhere for people to respond whenever they have a
> minute & I can check it later when I have time... kind of like
> stackoverflow, but specifically for blender contributors...
>
> Can contributors just ask code-related questions in the phabricator task
> comments or should we keep those discussions related to requirements /
> design only?
>
> Also, is this mailing list an appropriate forum for contributors to ask
> specific questions about the blender code-base?  If not, is there a mailing
> list for specific code-related questions?
>
> Wanted to verify that code-level questions are on topic ahead of time b.c.
> the wiki (https://wiki.blender.org/index.php/Dev:Doc/New_Developer_Info)
> mentions to stay on topic, but I couldn't find much detail about what's
> considered on topic and I haven't seen any code-related questions flying
> around this forum yet...
>
> Thanks,
> Danrae
> ___
> 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] Project admins and module owners update

[Jacob Merrill]

I would like to join the bge users group module team please.

I have 2 active bge/upbge projects
https://youtu.be/pofl2bxRunc - Wrectified and Manic Mack

On Oct 7, 2017 12:41 PM, "Ton Roosendaal"  wrote:

> Hi everyone,
>
> We have a consensus on technical topics, so it's time to get to work!
> In order to facilitate day-to-day decisions or to approve on patches it's
> important to reconfirm our projects structure.
>
> For many years we defined to work with 'admins' and 'module teams'.
> Read this if you're not familiar with it.
> https://wiki.blender.org/index.php/Dev:Doc/Process/Module_Owners
>
> It was about time to update the admin team, especially to make sure work
> on 2.8 will go smooth.
>
> • Bastien Montagne
> • Brecht Van Lommel
> • Dalai Felinto
> • Campbell Barton
> • Sergey Sharybin
>
> These are all among the most active contributors to Blender and 2.8.
>
> Next to that, I've asked Dalai Felinto accept the role as Blender 2.8
> project coordinator.
> He's now being hired by Blender Foundation to keep working full-time on
> Blender 2.8.
> Dalai's main role is to make sure everyone's aligned and that decisions
> get confirmed or supported by others. Just make sure Dalai's always
> informed about things. We really need at least 1 person who's up to date
> about everything that goes on here.
>
> Note that I'm not on this list! I've done this coordinating work back then
> for 2.5, but I currently have too many other jobs to handle. I'm not coding
> on 2.8 (sob!) and can't even find time to read the commit logs! How much I
> love all this 2.8 work and to be involved every day, for real work on
> Blender I'm just often more in the way (not available) than useful.
>
> That's one of the reasons we spent so much time together on getting a good
> 2.8 doc. We now all agree on the big picture, so I can happily keep doing
> what keeps me occupied as Foundation chairman and Institute director; to
> facilitate blender.org projects, arrange funding, expand the Institute's
> studio (more coder jobs!) and be well connected.
>
> For the rest; there are many established module teams or owners (like for
> Eevee, Cycles, Grease Pencil, UI, and so on). The project admins will work
> everyone to make sure this gets confirmed/refreshed and generally agreed on.
>
> Happy coding!
>
> -Ton-
>
> 
> Ton Roosendaal  -  t...@blender.org   -   www.blender.org
> Chairman Blender Foundation, Director Blender Institute
> Entrepotdok 57A, 1018 AD, Amsterdam, the Netherlands
>
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> https://lists.blender.org/mailman/listinfo/bf-committers
>
___
Bf-committers mailing list
Bf-committers@blender.org
https://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Blender developers meeting notes - 2017-09-25

[Jacob Merrill]

does the dependency graph now allow for the keyed adding and removing of
object instances?

this has always been a limitation for brining the game engine animations
etc into the offline render (bullets etc)

On Sep 25, 2017 10:28 AM, "Ton Roosendaal"  wrote:

> Hi all,
>
> Here are the notes from today's 16 UTC meeting in irc.freenode.net
> #blendercoders.
> Reminder: meetings are on Mondays now, next meeting is 2 Oct, 08 UTC (10
> CEST).
>
> 1) Blender 2.79 release
>
> - No showstoppers have been reported, just some regressions. We will keep
> checking weekly.
> We need some kind of protocol for defining when to do 2.79a, b, etc. And
> it shouldn't
> distract everyone from 2.8x work!
>
> 2) Blender 2.8 projects
>
> - The Eevee planning and roadmap doc:
> https://wiki.blender.org/index.php/Dev:2.8/Source/Viewport/Eevee/Roadmap-
> SeptDec-2017
>
> - Clement Foucault worked on AA in viewports.
> https://wiki.blender.org/index.php/User:Hypersomniac/
> Foundation/2017#Week_41:_18th_-_24th_September
>
> - Bastien Montagne keeps working on the asset management system. Weekly
> report shows mostly tracker work:
>  https://wiki.blender.org/index.php/User:Mont29/
> Foundation/2017#Week_210_-_09.2F16_to_09.2F22
>
> - Sergey works on the dependency graph, the Copy on Write feature to allow
> duplication
> and allow multiple states for same data (render, view, animation).
> He expects to have working system within a week. This will bring back
> modifiers and animation.
> https://wiki.blender.org/index.php/User:Nazg-gul/
> Foundation/2017#Week_303:_18th_-_24th_September
>
> - Dalai Felinto will present a technical 2.8 design doc, reviewed by the
> core dev team. It's meant
> to settle a lot of technical details to speedup work and allow
> contributions from everyone.
>
> - Mike Erwin will check with Daniel Stokes to align work on glTF.
>
> 3) Other projects
>
> - GSoC: Howard Trickey is working on getting patches for vertex paint
> branch ready for review,
> not quite there yet.
>
> - Martin "scorpion81" Felke will read up on Sergey's depsgraph work, to
> check on a design
> to put his Fracture branch in 2.8. The main topic to solve is a good
> generic cache system.
> In a follow-up discussion meeting concluded that Alembic is not a good
> choice for it. (Files
> get too large).
>
> - Plan remains to bring back working 2.7x particles/modifiers in 2.8
> first. A new nodes system
> for this is a more of a midterm project, and not a first 2.8 goal.
>
> Thanks,
>
> -Ton-
>
> 
> Ton Roosendaal  -  t...@blender.org   -   www.blender.org
> Chairman Blender Foundation, Director Blender Institute
> Entrepotdok 57A, 1018 AD, Amsterdam, the Netherlands
>
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> https://lists.blender.org/mailman/listinfo/bf-committers
>
___
Bf-committers mailing list
Bf-committers@blender.org
https://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Blender developers weekly meeting notes - 2017-09-11

[Jacob Merrill]

Just wanted to note that the UPBGE developer team is taking a break from
EEVEE integration to do some bug fixing and general maintenance on UPBGE.

UPBGE still does want to merge into the 2.8 project, but right they feel
with all the planned changes to the code, they will wait for eevee to
solidify a bit.

The game engine community is growing very fast these days, and having a bit
of certainty could increase this pace.


Thanks all for your efforts!
Jacob Merrill


On Mon, Sep 11, 2017 at 11:01 AM, Ton Roosendaal <t...@blender.org> wrote:

> Hi all,
>
> Here are the notes from today's 16 UTC meeting in irc.freenode.net
> #blendercoders.
>
> Note: meetings are on Mondays now, next meeting is 18 Sept, 08 UTC (10
> CEST)!
>
> 1) Blender 2.79 release
>
> - Release Ahoy done! Builds are coming in now, they get a last test and
> then need to be synced
> by the mirrors. Official release is tomorrow daytime EU.
>
> - Bastien Montagne will do the git release tag tomorrow. He will also
> updates the bug fix
> list and other changes since RC2.
>
> - Pablo Vazquez manages the release log on blender.org, Francesco Siddi
> will do the release on Steam.
> Campbell Barton will publish the source.tgz on the download site.
>
> 2) Blender 2.8 projects
>
> - A 2.8 splash (an Eevee render!) will be submitted this week.
>
> - Dalai Felinto works on new doc with a good 2.8 design presentation
> (representing work
> done so-far).
>
> - Clement Foucault will work in Blender Institute this week one day. Goal
> is to schedule
> 6+ months of work on viewport.
>
> - Joshua Leung accepted a Development Fund grant for 2 months to work on
> 2.9 Grease Pencil
> and to help with triaging and bug tracker support.
>
> - Attention module owners: please let us know what dependencies
> (libraries) need to be upgraded?
> For example OpenSubdiv, Cmake, minimal OSX version, etc. Mail this to the
> bf-committers list.
>
> - A topic to tackle soon: massive tracker cleanup - a lot of issues are
> not valid for 2.8x.
>
> - We have to merge the 2.8 branch with master one day... not soon, but
> hopefully this year.
>
> - Howard Trickey: the GSoC Vpaint branch is close to be merged in master.
> Campbell Barton reviews.
>
> - Weekly reports:
>
> Clement (soft shadow!):
> https://wiki.blender.org/index.php/User:Hypersomniac/
> Foundation/2017#Week_39:_3rd_-_10th_September
>
> Dalai:
> https://wiki.blender.org/index.php/User:Dfelinto/Foundation17#Week_15_.
> 28September_4th_-_8th.29
>
> Bastien:
> https://wiki.blender.org/index.php/User:Mont29/
> Foundation/2017#Week_208_-_09.2F02_to_09.2F08
>
> Campbell:
> http://download.blender.org/ftp/ideasman42/donelist/2017.
> html#week-338-september-4
>
> Sergey Sharybin:
> https://wiki.blender.org/index.php/User:Nazg-gul/
> Foundation/2017#Week_301:_4th_-_10th_September
>
> 3) Other projects
>
> - Mike Erwin will pick up the Blender exporter for glTF:
> https://github.com/KhronosGroup/glTF-Blender-Exportergltf
>
> Thanks,
>
> -Ton-
>
> 
> Ton Roosendaal  -  t...@blender.org   -   www.blender.org
> Chairman Blender Foundation, Director Blender Institute
> Entrepotdok 57A, 1018 AD, Amsterdam, the Netherlands
>
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> https://lists.blender.org/mailman/listinfo/bf-committers
>
___
Bf-committers mailing list
Bf-committers@blender.org
https://lists.blender.org/mailman/listinfo/bf-committers

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

[Jacob Merrill]

yeah I have not been getting it either

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

> > Aaron Carlisle wrote:
>
> > Hi, You can fix this by visiting
> > https://lists.blender.org/mailman/options/bf-committers
>
> no i can't
>
>
> i receive digest
>
> and i want to receive digest
>
>  , which is normally sent once a day
>
>
> but somehow since there has been some mail server work done
>
>  , the digest are not sent as they were before
>
>
> the digest i received contains 83 mails starting somewhere in august
>
>
>
>
> On Sun, Sep 10, 2017 at 1:18 PM, INTERLICHTSPIELHAUS < interlichtspielhaus
> at gmail.com <https://lists.blender.org/mailman/listinfo/bf-committers>>
> wrote: >* hi *> >* can someone review the configurations of the mailing
> lists *> >* yesterday i received a digest mail of Bf-committers *> >* turns
> out it contains 3 weeks worth of mails, *>* digest mails were sent every
> day at noon*
>
>
> On Sun, Sep 10, 2017 at 7:18 PM, INTERLICHTSPIELHAUS <
> interlichtspielh...@gmail.com> wrote:
>
> > hi
> >
> > can someone review the configurations of the mailing lists
> >
> > yesterday i received a digest mail of Bf-committers
> >
> > turns out it contains 3 weeks worth of mails,
> > digest mails were sent every day at noon
> >
> >
> >
> > -- Forwarded message --
> > From: <bf-committers-requ...@blender.org>
> > Date: Sat, Sep 9, 2017 at 3:37 PM
> > Subject: Bf-committers Digest, Vol 158, Issue 1
> > To: bf-committers@blender.org
> >
> >
> > Send Bf-committers mailing list submissions to
> > bf-committers@blender.org
> >
> > To subscribe or unsubscribe via the World Wide Web, visit
> > https://lists.blender.org/mailman/listinfo/bf-committers
> > or, via email, send a message with subject or body 'help' to
> > bf-committers-requ...@blender.org
> >
> > You can reach the person managing the list at
> > bf-committers-ow...@blender.org
> >
> > When replying, please edit your Subject line so it is more specific
> > than "Re: Contents of Bf-committers digest..."
> >
> >
> > Today's Topics:
> >
> >1. Re: Audaspace 1.3 for Blender 2.8 (J?rg M?ller)
> >2. Re: Audaspace 1.3 for Blender 2.8 (Sergey Sharybin)
> >3. Re: Audaspace 1.3 for Blender 2.8 (Jeffrey)
> >4. Memory map (Ivam Pretti)
> >5. Re: Breaking fundamental functionality in Blender 2.79?
> >   (Aaron Carlisle)
> >6. Blender developers weekly meeting notes: 2017-08-20
> >   (Ton Roosendaal)
> >7. CMake version bump for blender2.8 (J?rg M?ller)
> >8.  Blender 2.8 planning notes 2017-08-21 (Bastien Montagne)
> >9. Blender developers meeting notes - 2017-08-27 (Ton Roosendaal)
> >   10. Failing addons/module load tests (Sergey Sharybin)
> >   11. Re: Failing addons/module load tests (Campbell Barton)
> >   12. Re: Failing addons/module load tests (Campbell Barton)
> >   13. Blender 2.8 planning notes 2017-08-28 (Campbell Barton)
> >   14. Weekly meetings and communication channels (Ton Roosendaal)
> >   15. Re: Weekly meetings and communication channels (Aaron Carlisle)
> >   16. is static analyzer working? (Tom M)
> >   17. Create a page for my addons (xavier loux)
> >   18. Revisions for 2.79 ReleaseCandidate 3 (Sybren A. St?vel)
> >   19. Re: Revisions for 2.79 ReleaseCandidate 3 (Jacob Merrill)
> >   20. Re: Revisions for 2.79 ReleaseCandidate 3 (Lukas Stockner)
> >   21. Re: Revisions for 2.79 ReleaseCandidate 3 (Jacob Merrill)
> >   22. Re: is static analyzer working? (Campbell Barton)
> >   23. Re: VSE devs? (Alberto Mardegan)
> >   24. Re: Weekly meetings and communication channels (Campbell Barton)
> >   25. Re: VSE devs? (OllyFunkster)
> >   26. Re: Weekly meetings and communication channels (Stefan Werner)
> >   27. Re: VSE devs? (Alberto Mardegan)
> >   28. Re: Weekly meetings and communication channels (Campbell Barton)
> >   29. Re: Failing addons/module load tests (Campbell Barton)
> >   30. Re: CMake version bump for blender2.8 (Dalai Felinto)
> >   31. Re: CMake version bump for blender2.8 (Bastien Montagne)
> >   32. Re: CMake version bump for blender2.8 (Campbell Barton)
> >   33. Re: CMake version bump for blender2.8 (Dalai Felinto)
> >   34. Re: CMake version bump for blender2.8 (Campbell Barton)
> >   35. Re: Weekly meetings and communication channels (Aaron Carlisle)
> >   36. w

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

[Jacob Merrill]

Ok, thanks Lukas! and thanks everyone else!

I look forward to seeing it later (2.8 I guess?)


On Aug 29, 2017 8:59 AM, "Lukas Stockner" <lukas.stock...@freenet.de> wrote:

> Nope, it's far too late for new features in 2.79, and even if it wasn't,
> it's not even in master yet.
>
> Am 29.08.2017 um 17:37 schrieb Jacob Merrill:
> > any chance the new bevel shader will be in the Rc?
> >
> > On Aug 29, 2017 8:10 AM, "Sybren A. Stüvel" <syb...@stuvel.eu> wrote:
> >
> >> Hey list,
> >>
> >> I've just fixed an Alembic crash that would be great to have in
> >> RC3/release: 696f4dc85f7faa8bc21e2e48302c6b680a5bb09e
> >>
> >> Cheers,
> >>
> >> --
> >> Sybren A. Stüvel
> >>
> >> https://stuvelfoto.nl/
> >> https://stuvel.eu/
> >>
> >>
> >> ___
> >> 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] Revisions for 2.79 ReleaseCandidate 3

[Jacob Merrill]

any chance the new bevel shader will be in the Rc?

On Aug 29, 2017 8:10 AM, "Sybren A. Stüvel"  wrote:

> Hey list,
>
> I've just fixed an Alembic crash that would be great to have in
> RC3/release: 696f4dc85f7faa8bc21e2e48302c6b680a5bb09e
>
> Cheers,
>
> --
> Sybren A. Stüvel
>
> https://stuvelfoto.nl/
> https://stuvel.eu/
>
>
> ___
> 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] Build blender for Arm architecture

[Jacob Merrill]

I could really use an eevee / bge build of blender for B_PECS that runs on
android.

this can help autistic children communicate, and the closest equal to the
software is 250$



any way to make a ios blender player and a android blender player?

here is current progress, works great on PC.
https://www.youtube.com/watch?v=RS0PL0XXWJE

On Thu, Aug 17, 2017 at 7:34 AM, Campbell Barton 
wrote:

> A while ago I built blender for ARM, it worked same as building for X86,
> so hint is to try it :)
>
> On Wed, Aug 16, 2017 at 9:49 AM, Nkansah Rexford
>  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
>
>
>
> --
> - Campbell
> ___
> 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] Bringing Freestyle back to Blender 2.8

[Jacob Merrill]

many people are using cell shading in realtime to produce cartoon  renders
in real time, maybe this could be a path to realtime npr?

also, I seem to recall a geometry shader produce can outline almost
instantly?



On Aug 12, 2017 5:54 AM, "Brecht Van Lommel" 
wrote:

> Regarding relying on static material properties, I think those can be kept
> then. The diffuse/specular/hardness could be moved into the Freestyle Line
> panel and only used by Freestyle.
>
> On Thu, Aug 10, 2017 at 4:06 AM, Tamito KAJIYAMA <
> rd6t-k...@asahi-net.or.jp>
> wrote:
>
> > Hi Brecht,
> >
> > Many thanks for the detailed replies, and excuse me for the delayed
> reply.
> >
> > I agree that the first thing to do to keep Freestyle functional in the
> > Blender 2.8 code base is the removal of Freestyle's dependency to the
> > object/mesh data structures of the Blender Internal.  Freestyle in
> > Blender 2.7x and earlier receives a bunch of tris/quads through the
> > Render::instancetable (that is, a linked list of ObjectInstanceRen
> > data).  Freestyle doesn't really have to care about many details of
> > Blender scene data, mesh modifiers, animation, render settings, and so
> > on---instead, the ObjectInstanceRen data allow Freestyle to simply deal
> > with a final set of polygons resulting from all the rendering related
> > details already addressed by the Blender Internal and Cycles.  If there
> > is a convenient way to do the same in 2.8, then I expect the dependency
> > removal would be straightforward.  Otherwise, the work might be a bit of
> > hassle.
> >
> > As to the material system, Freestyle currently relies on static (not
> > node-based) material properties such as diffuse color, specular color,
> > and some other props.  In addition, there are a few Freestyle-specific
> > static material properties such as line color, line alpha transparency,
> > and line priority (plus, line thickness is to be added in the future).
> > Freestyle employs static colors as solid line colors no matter how the
> > material is lit by various light sources and seen by the camera.  If
> > everything is defined by material nodes in 2.8, then a few extra nodes
> > specific to Freestyle are necessary.  At the moment Freestyle doesn't do
> > anything with material nodes when retrieving material props.  So, again
> > everything in nodes might imply a substantial amount of work on the
> > Freestyle side.
> >
> > As far as Eevee gives Freestyle a render buffer to which line components
> > are composited, that's fine and I expect very little work there.
> > Freestyle performance is far from real time, so I would say Freestyle
> > rendering in the viewport is out of scope in short- and mid-term ranges.
> >
> > Best regards,
> >
> > --
> > KAJIYAMA, Tamito 
> >
> >
> > On 2017/08/01 9:47, Brecht Van Lommel wrote:
> > > Hi Tamito,
> > >
> > > Blender internal and its material system have not been removed yet, but
> > > they are planned to be replaced by Eevee. I don't think anyone has
> > actually
> > > gone though what that entails in detail, since there is indeed code
> like
> > > Freestyle and the texture system that rely on it even when not
> rendering
> > > with BI.
> > >
> > > I expect the first thing to keep things functional would be to stop
> > relying
> > > on the BI object/mesh data structures, and rather get geometry directly
> > > from the Blender object/mesh data structures. This should be easier now
> > > than it was when Freestyle was initially implemented, since there are
> now
> > > functions like BKE_mesh_new_from_object to get a mesh from any type of
> > > object. Some of this stuff will likely still evolve some as the
> > dependency
> > > graph is being worked on.
> > >
> > > Materials I think would all be defined using node graphs, which should
> > > already work with Freestyle? But for NPR work is needed to get back
> some
> > > functionality from Blender Internal. There is no design for that yet as
> > far
> > > as I know, would be interesting to get some idea which extra nodes
> Eevee
> > > needs.
> > >
> > > In terms of integrating with render buffers, I hope the way it works
> with
> > > Cycles as an external engine can also work for Eevee. So Eevee could
> > > deliver render buffers the same way as Cycles and freestyle could
> > composite
> > > on top of them in the same way. Beyond that it would of course be
> really
> > > cool if Freestyle could work in realtime on top of Eevee, showing
> OpenGL
> > > accelerated line drawing in the viewport, but I guess that would be
> > almost
> > > a full rewrite of Freestyle.
> > >
> > > Regards,
> > > Brecht.
> > >
> > >
> > > On Mon, Jul 31, 2017 at 4:26 PM, Tamito KAJIYAMA <
> > rd6t-k...@asahi-net.or.jp>
> > > wrote:
> > >
> > >> Hi,
> > >>
> > >> I would like to discuss with the viewport team what precisely would be
> > >> necessary to bring Freestyle back to Blender 2.8.  I was informed that
> > >> the old material system 

[Bf-committers] Plans for game logic and interactive mode logic systems.

[Jacob Merrill]

this - http://www.tukano.it/applications/bgenetlogic/bgelogicnodes.html

(logic nodes by PGI )

is a very robust system already made for bge, and each node calls python.

if someone were to make each node in C or another way to accelerate the
system and have split definitions [GE and Viewport]

one system could be used to design viewport interactive logic and GE logic
that was fast and maintainable. (similar to the way nodes are used
everywhere already)

a feature that I would add, is folders with input and output nodes defined
by the user, that nodes can be placed in that can be collapsed and each
folder can have states.
(state input node(set state) per folder and output = (Current state value?)

this will allow the user to 'fold complexity' and should allow visual logic
projects to scale much better than the current logic bricks.
___
Bf-committers mailing list
Bf-committers@blender.org
https://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Eevee and BGE proposal.

[Jacob Merrill]

For logic for interactive mode, what about applying something like pgi
logic nodes to both engines, but adding the ability to nest folders with
in/outs to be able to segment and fold complexity?

Pgi nodes were pretty nice, can they be compiled or rewritten in C?

https://blenderartists.org/forum/showthread.php?393954-Logic-Nodes-Addon-(Installing-and-getting-started)-BGE-Tutorial

On Mon, Jul 17, 2017 at 1:04 PM, tristan porteries <
republicthunderbo...@gmail.com> wrote:

> Hello Dalai,
>
> Sorry, i want to clarify your question: When you talk about material
> update, it's the update of node values or totally something else ? Also the
> BGE will never modify the node tree of a material so we don't have to
> manage the material creation. At the end the only think we need currently
> for update is a GPUMaterial or GPUShader and a node list for your new
> system.
>
> About probes, we already developed in UPBGE planar and cube probes, i hope
> we could adapt them. For the irradiance/grid probe i have to check deeper.
>
> Tristan.
>
> 2017-07-17 18:43 GMT+02:00 Dalai Felinto <dfeli...@gmail.com>:
>
> > Hi Tristan,
> >
> > Can you elaborate on how do you plan handling updates for the Eevee
> > materials and probes?
> > Right now this all goes via the depsgraph.
> >
> > Perhaps we could talk Tuesday morning (10am or 11am CEST) on IRC with
> > Sergey to get this sorted out once and for all.
> >
> > Cheers,
> > Dalai
> > --
> > blendernetwork.org/dalai-felinto
> > www.dalaifelinto.com
> >
> >
> > 2017-07-14 15:29 GMT+02:00 tristan porteries <republicthunderbolt9@gmail.
> > com>:
> > > Hello Dalai,
> > >
> > > The proposal is to use Eevee in BGE, it looks simple but it requests
> > > refactors in the BGE sources.
> > >
> > > The usage of draw engine based on Eevee help to not interfere the eevee
> > ->
> > > blender side, the idea of common API can be forgotten and replaced by a
> > > little number of duplicated functions if it is too complicated in
> futur.
> > >
> > > I think that the debate about interative mode is for an other proposal,
> > > implementing eevee in BGE will not exclude the interactive mode, doing
> > the
> > > both in same time can be very messy.
> > >
> > > Tristan.
> > >
> > > 2017-07-11 15:37 GMT+02:00 Jacob Merrill <blueprintrand...@gmail.com>:
> > >
> > >> Step 1 in such a scenario, is a realtime switch for rendering and
> > running
> > >> the game loop.
> > >>
> > >> What about getting evee running, and upgrading viewport with new logic
> > >> system, and after evee is integrated, integrate same logic systems
> into
> > >> BGE?
> > >>
> > >> Maybe Bullet3 or even pyBullet based?
> > >>
> > >>
> > >>
> > >> On Jul 11, 2017 5:54 AM, "Dalai Felinto" <dfeli...@gmail.com> wrote:
> > >>
> > >> > Hi Tristan,
> > >> > Thanks for writing this. Sergey and I just finished looking at it.
> > >> >
> > >> > The proposal is missing a big picture. What is it trying to achieve?
> > >> > It seems to simply try to bring Eevee materials into BGE, without
> any
> > >> > extra benefit.
> > >> >
> > >> > If that’s the only goal of this project, I would at least expect it
> to
> > >> > not interfere with the rest of Blender. For example, the idea of
> > >> > changing Eevee to accommodate to a common API seems not ideal.
> > >> >
> > >> > That said, we have an opportunity to do something bigger. Which
> would
> > >> > be to integrate interactivity with the rest of Blender. That’s a
> > >> > bigger undertake for sure, but I was under the impression that this
> > >> > was the original idea for after 2.7. It’s not clear if this was
> > >> > considered, or why was it dismissed.
> > >> >
> > >> > Regards,
> > >> > Dalai and Sergey
> > >> > --
> > >> > blendernetwork.org/dalai-felinto
> > >> > www.dalaifelinto.com
> > >> >
> > >> >
> > >> > 2017-07-02 12:23 GMT+02:00 tristan porteries
> > <republicthunderbolt9@gmail.
> > >> > com>:
> > >> > > Hello everyone,
> > >> > >
> > >> > > I invite the people working on Eevee and 2.8 (Campbe

Re: [Bf-committers] Eevee and BGE proposal.

[Jacob Merrill]

Step 1 in such a scenario, is a realtime switch for rendering and running
the game loop.

What about getting evee running, and upgrading viewport with new logic
system, and after evee is integrated, integrate same logic systems into
BGE?

Maybe Bullet3 or even pyBullet based?



On Jul 11, 2017 5:54 AM, "Dalai Felinto"  wrote:

> Hi Tristan,
> Thanks for writing this. Sergey and I just finished looking at it.
>
> The proposal is missing a big picture. What is it trying to achieve?
> It seems to simply try to bring Eevee materials into BGE, without any
> extra benefit.
>
> If that’s the only goal of this project, I would at least expect it to
> not interfere with the rest of Blender. For example, the idea of
> changing Eevee to accommodate to a common API seems not ideal.
>
> That said, we have an opportunity to do something bigger. Which would
> be to integrate interactivity with the rest of Blender. That’s a
> bigger undertake for sure, but I was under the impression that this
> was the original idea for after 2.7. It’s not clear if this was
> considered, or why was it dismissed.
>
> Regards,
> Dalai and Sergey
> --
> blendernetwork.org/dalai-felinto
> www.dalaifelinto.com
>
>
> 2017-07-02 12:23 GMT+02:00 tristan porteries  com>:
> > Hello everyone,
> >
> > I invite the people working on Eevee and 2.8 (Campbell, Dalai, Bastien,
> > Clement, Mike and few other) to look at the following proposal for a
> merge
> > of Eevee into the BGE.
> >
> > https://docs.google.com/document/d/1dpC2zCVD54yCGwNZFu_WM82uUAGI_
> s5-GmlgMLOcfYY/edit?usp=sharing
> >
> > Feel free to comment on the document, also an experimental branch named
> > ge_eevee is available on https://github.com/UPBGE/blender.
> >
> > Tristan.
> > ___
> > 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 as a multi purpose, algorithmic, no GUI mobile and desktop application

[Jacob Merrill]

Headless is what is commonly referred too,
I think ideasman had a headless build back in the day.

Another name is a 'bpy serverv

On Jul 5, 2017 8:17 AM, "Berserk"  wrote:

> Hello everyone.
> My name is Ivano Arrighetta and I'm Italian.
> I'd like to strip off the Blender's UI and allow users to just use Python
> for doing everything, with just 2 windows:
> 1) For preview
> 2) For coding
>
> This would be a side project, btw.
>
> Now, I have a clue on how to remove the UI, but then I'd also like to port
> to (at least) Android.
>
> Is there any quick and easy way to do all?
>
> Thanks in advance for either.
>
> Bye, Ivano.
> ___
> 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] Eevee and BGE proposal.

[Jacob Merrill]

No one has answered me when asked,

Will evee be using deferred render, or forward+?

If we do use deferred, won't alpha materials be broken?

Thank you Tristan, and all blender developers and the UPBGE team.

On Jul 2, 2017 3:23 AM, "tristan porteries" 
wrote:

> Hello everyone,
>
> I invite the people working on Eevee and 2.8 (Campbell, Dalai, Bastien,
> Clement, Mike and few other) to look at the following proposal for a merge
> of Eevee into the BGE.
>
> https://docs.google.com/document/d/1dpC2zCVD54yCGwNZFu_WM82uUAGI_
> s5-GmlgMLOcfYY/edit?usp=sharing
>
> Feel free to comment on the document, also an experimental branch named
> ge_eevee is available on https://github.com/UPBGE/blender.
>
> Tristan.
> ___
> 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] Audaspace 1.3 for Blender 2.8

[Jacob Merrill]

Does this effect the GE?

(bge sound actuator etc uses audaspace)

On Jun 18, 2017 11:54 AM, "Jörg Müller"  wrote:

> Hi everyone,
>
> it's time to get rid of the old audaspace and use the new one in the
> Blender 2.8 branch, so I created a patch [1].
>
> I would like to ask anyone who is interested to have a look, try it and
> comment on it. I've only tested it on my computer running linux here, so
> it would be especially helpful if developers from the other supported
> platforms (Windows and MacOS) could have a look.
>
> Thanks and cheers,
> Jörg
>
> [1] https://developer.blender.org/D2716
>
> ___
> 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] Weekly Blender developer meeting notes - 2017-05-21

[Jacob Merrill]

1. I was wondering, will evee support forward+ lamp discard?

(we won't be using deferred rendering because it's terrible for
transparency right?)




2. could forward+ lamp discard be added to the legacy blender render, and
be the 'crown jewel' of 2.79?




3. will there be any plans to use external physics servers, and somehow
link the scenes?
(Ie new pybullet)

Blender game and blender itself don't have things like robotic simulation
(BTMultiBody) or tensor flow built in yet.

I would very much like to continue the walking ragdoll project, but
integrate a Guided Adversarial Network, but I am sure smarter people around
here could do much better.(Sybren?)
https://www.youtube.com/watch?v=Ul0Gilv5wvY



Thank you Ton so much for blender.

Thank you everyone,
Coders, Testers, Builders, and users.




On Sun, May 21, 2017 at 8:57 AM, Ton Roosendaal  wrote:

> Hi all,
>
> Here are the notes from today's 14 UTC meeting in irc.freenode.net
> #blendercoders.
>
> 1) Blender 2.79 release
>
> - Project page with targets and planning:
> https://wiki.blender.org/index.php/Dev:2.7
>
> - Open todos: we have bugs! There are over 300 open issues.
> https://developer.blender.org/maniphest/project/2/type/Bug/
>
> - Feel invited to check on the tracker and help. Help is especially
> welcome with triaging,
> just check on the report if it's a valid bug we can fix.
>
> - Python library in Blender is getting updated to latest stable version.
>
> - Splash: The artists of Blender Institute will make a splash using work
> from the secret agent short.
>
> 2) Blender 2.8 projects
>
> - Clement Foucault will work this week in Blender Institute with Dalai
> Felinto to wrap up the May targets.
> Having a code.blender.org blog update would be great.
>
> - We're also talking to Tristan Porteries (panzergame) to make a plan how
> to get GE updated for 2.8
> viewport and shaders, and merge the good stuff from upBGE in.
>
> - Sergey Sharybin wrote a Dependency Graph doc:
> https://wiki.blender.org/index.php/Dev:2.8/Source/Depsgraph
>
> - Mike Erwin reports GL work keeps going on fine. Removing old parts,
> updating GLSL.
>
> - Antonio Vazquez will connect with Dalai Felinto to integrate new
> GreasePencil stuff with 2.8.
>
> - Aim is to have something to show off in Los Angeles at SIGGRAPH in
> August!
>
> 3) GSoC and other projects
>
> - We have a special mailing list to connect with the students and follow
> their progress.
> https://lists.blender.org/mailman/listinfo/soc-2017-dev
> Artists welcome to join!
>
> - Sergey and Bastien Montagne will add wiki and git accounts for students.
> Goal is to have all docs copied to the student's personal space in wiki.
> These pages then also
> will get reports and docs.
>
> Thanks,
>
> -Ton-
>
> 
> Ton Roosendaal  -  t...@blender.org   -   www.blender.org
> Chairman Blender Foundation, Director Blender Institute
> Entrepotdok 57A, 1018 AD, Amsterdam, the Netherlands
>
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> https://lists.blender.org/mailman/listinfo/bf-committers
>
___
Bf-committers mailing list
Bf-committers@blender.org
https://lists.blender.org/mailman/listinfo/bf-committers

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

[Jacob Merrill]

How hard would it be from here for a android build?

On Thu, May 11, 2017 at 3:33 PM, Mike Erwin 
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 
> 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  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

Re: [Bf-committers] GSoC students announced!

[Jacob Merrill]

Hello Ton, and congratulations!

will the vertex painting tools gsoc be adding PBVHTREE to blender now?

will multiple layer painting be possible? (like to use a brush and
interpolate the vertex color from the brush?)

(I was thinking this could be used to make a sort of high density point
cloud painter)

duplicate low poly mesh copy,
subdivide quite heavily
paint textures in vertex paint
bake back to 2d textures from vertex data,

Just a thought.

On Thu, May 4, 2017 at 9:44 AM, Ton Roosendaal  wrote:

> Hi everyone,
>
> Google accepted 7 students to work on Blender this summer.
> https://summerofcode.withgoogle.com/organizations/5768612708089856/
>
> One student (Mikhail, Implicit Deform) announced last week he accepted an
> internship.
> I've contacted him to discuss if this can be rescheduled to work out for
> him and us.
>
> In the coming days I'll post this on our code blog and open a mailing list
> for the students, which is open for everyone to join as well. Students will
> now enter the "community bonding period", let's give them a very warm
> welcome!
>
> Actual work will start May 30.
>
> Laters,
>
> -Ton-
>
> 
> Ton Roosendaal  -  t...@blender.org   -   www.blender.org
> Chairman Blender Foundation, Director Blender Institute
> Entrepotdok 57A, 1018 AD, Amsterdam, the Netherlands
>
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> https://lists.blender.org/mailman/listinfo/bf-committers
>
___
Bf-committers mailing list
Bf-committers@blender.org
https://lists.blender.org/mailman/listinfo/bf-committers

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

[Jacob Merrill]

with the selection code, I think some care is to be taken to allow input
from Vive and other 3d mouse devices,
(implementing this early could spare headaches later* )

another question -

Could a plane inside of the blender viewport have a rendered texture, of
say your desktop, or chrome, or slack etc, to bring API or tutorials,or a
online tutor inside your blender workflow? (this could really help people
learn blender faster)



On Mon, Apr 10, 2017 at 6:35 AM, Mike Erwin 
wrote:

> On Mon, Apr 10, 2017 at 6:34 AM, Luca Rood  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 
> 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
>
___
Bf-committers mailing list
Bf-committers@blender.org
https://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] New developer having issues setting up Blender for build

[Jacob Merrill]

Get on #irc #blendercoders for building help*

On Mar 29, 2017 4:16 PM, "George Guevara"  wrote:

> I am trying to build Blender on Windows with Visual Studio 2015 using the
> information from the wiki page.  I've checked-out the source code and the
> pre-compiled libraries per the instructions given. The problem occurs when
> attempting to create a solution file with CMake.  The exact message
> produced by CMake is,
>
> "CMake Error at build_files/cmake/platform/platform_win32_msvc.cmake:146
> (message):
>
> Windows requires pre-compiled libs at: 'D:/BUILDS-2015/blender-git/
> blender/../lib/win64_vc14'"
>
>
> Again, I followed the setup of the directory structures to the letter. Any
> tips would be appreciated.
>
>
> George
> ___
> 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 and Asyncio

[Jacob Merrill]

Maybe you can apply this to blender verse?

it really needs it*

On Mon, Mar 27, 2017 at 3:50 AM, Andreas Klostermann <
andreasklosterm...@gmail.com> wrote:

> >
> >
> >
> > - A different way to use dialogs; from just browsing through the
> >   code it's hard to see the end-user's benefit here. I also don't
> >   quite understand the need to define and register operators from
> >   inside an async function.
> >
> > No benefit to the end user. It's just for scripting pleasure. It enables
> you to express a fairly complex workflow or even an automated UI test with
> the convenient "async/await" syntax. The operators needed to be registered
> because operators have severe limitations like no return value and no
> callbacks. I think I know a way around this by using one-time tokens, but
> well, it works this way too.
>
>
> > - The _run_once() function is interesting, since it allows running
> >   asyncio tasks for a short period of time. This hooks into:
> >
> > - The web server acts as an example of an asyncio task. Have you
> >   compared the web server's performance with an aiohttp server
> >   running outside of Blender? And have you compared your aiohttp
> >   approach to running some other HTTP server implementation in,
> >   say, another thread or process? I'm also very interested in
> >   seeing the effect on Blender itself when the asyncio webserver
> >   is being stressed.
> >
> >
> I'm completely disinterested in the performance of the http server, or
> anything run in asyncio for that matter. If the workload is 90%
> asyncio/http and 10% blender, then it shouldn't be done inside blender or
> distributed more wisely. Never ever would I suggest connecting this http
> server to the internet, and performance is the least of the concerns there.
> That said, aiohttp is among the most performant options in Python, has the
> most community support compared to other asyncio http frameworks and it
> comes with the least baggage.
>
> In general I haven't seen any real performance issues with asyncio and
> blender. The animations still run smoothly if they would without asyncio.
> If a particular slice of a task takes too much time, of course you will see
> a reduction in fps. I haven't encountered that problem yet, but it then
> would be easy to throw in a couple of extra await calls to distribute the
> workload over time. The loop can also be adapted to check how many time per
> iteration is spent inside or outside the asyncio callbacks, so as to give
> other parts of blender more space in the main loop cycle.
>
>
> > I really like asyncio, but I think personal interest is not enough to
> > warrant building things into Blender. Building web servers into
> > Blender isn't something I see a wide need for. However, downloading
> > things asynchronously is something we certainly have a use for
>
>
> >
> - the package manager
> > - Blender Cloud add-on
> > - add-ons that now bundle large datasets in their scripts
> >   directory (which they shouldn't)
> >
> >
> I don't want to include the http server stuff into Blender, either. It
> should be an optional plugin. There are two major ways to use an http
> server from inside a blender instance:
> - web user interfaces for tasks in which blender's UI is really bad at
> (text editing, browsing data, documenting)
> - RPC through REST API
>
> The latter is the more useful, actually.
> - A website with a shop could for example keep a few blender instances
> running as workers, and when the site needs to render a specially
> configured product, the options are passed via rpc and the image is then
> "downloaded" as response.
> - An external asset manager (usually a webapp I guess) can keep blender
> workers around to render previews or find out what assets are where. The
> alternative, without RPC or inter-process communication, would have to
> create a new blender instance for each call, run a script and take
> parameters from the command line or a temporary file.
> - A render farm could get more insight into the progress and state of a
> blender instance.
> - Blend4Web could get resources or other information directly from inside
> an instance. Maybe even update on-the-fly
> - A plugin for the VSE, run inside one blender instance, could start and
> control another instance in background mode, with a blend file to create
> animated captions
> - it may be a good idea to implement certain integration tests via RPC,
> especially across multiple blender builds to look for regressions. But this
> can also be done through a script with asyncio and no RPC.
>
> The main reason to do this as an http-based REST API is because it is a
> well understood paradigm with a large ecosystem. There are other options,
> like zeromq, which are often faster and more efficient, but they have
> problems of their own. For example, the REST API makes it relatively easy
> to access it from javascript, for example in a web-ui. 

Re: [Bf-committers] GSoC 2017: Camera breathing support

[Jacob Merrill]

what about using a object of known scale to calibrate (like a 3d printed
susan?)



On Fri, Mar 24, 2017 at 8:27 AM, Tianwei Shen 
wrote:

> Hi Levon,
>
> Thank you so much this long reply. First of all, I’ve been looking for
> user tests and suggestions for the multi-view reconstruction project. If
> you have ideas for making it better, just feel free to drop me emails. On
> the other hand, it is still a quite large patch. So we need time to split
> it up and gradually merge it into the master. But hopefully this can be
> integrated well with the camera breathing support project and even
> automatic tracking in the future.
>
> As for the camera breathing support, I didn’t realize lens distortion
> parameters would also change with the focal lengths. I thought we’d only
> deal with changing focal lengths with the zoom-in/out motions. So things
> become complicated here since it seems to me that focal lengths and
> distortion parameters cannot be estimated on the fly. Users have to first
> calculate this information (focal lengths for each frames and their
> corresponding lens distortion parameters) using some calibration tools. Can
> the solver reliably deal with changing focal lengths and distortions? On
> the other hand, if users have to first calculate focal distances using some
> tools (if Blender doesn’t have its own) in the first place, would it impose
> burden and inconvenience for users?
>
>
> Thanks,
> Tianwei
>
> > On Mar 24, 2017, at 8:57 PM, Levon  wrote:
> >
> >>
> >> Message: 1
> >> Date: Fri, 24 Mar 2017 02:26:38 +0800
> >> From: Tianwei Shen >
> >> Subject: [Bf-committers] GSoC 2017: Camera breathing support
> >> To: bf-blender developers >
> >> Message-ID: <3b4ba086-116b-417d-a288-c8f1ca7a8...@gmail.com  3b4ba086-116b-417d-a288-c8f1ca7a8...@gmail.com>>
> >> Content-Type: text/plain;   charset=us-ascii
> >>
> >> Hi Everyone,
> >>
> >> Last summer I participated in GSoC 2016 and worked on the multi-view
> >> camera reconstruction project. Some of my efforts are summarized in this
> >> blog: http://hlzz.github.io/blender3/ 
> >.
> >> And this patch (https://developer.blender.org/D2187 <
> https://developer.blender.org/D2187> <
> >> https://developer.blender.org/D2187  org/D2187>>) is now being reviewed and revised.
> >> This year I would like to apply again and work on the camera breathing
> >> support, which is already requested by some users during the time I
> worked
> >> on the motion tracking project. Now I need clarifications for some
> specific
> >> problems.
> >>
> >> 1. should we automatic detect the changes of focal lengths, or is it
> >> specified by users as additional inputs (like the focal length for each
> >> frame)? I know we can read exif tags to get focal lengths for photos.
> Do we
> >> have a similar approach for videos?
> >>
> >> 2. Is the current UI able to handle camera breathing, if we need
> >> additional inputs from users?
> >>
> >> I think this project also has something to do with my revisions done on
> >> the motion tracking system last summer. Hopefully I should be able to
> merge
> >> the revisions and move towards the goal of automatic tracking.
> >>
> >>
> >> Thanks,
> >> Tianwei
> >>
> >
>
> ___
> 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] Regarding GSoC 2017

[Jacob Merrill]

I wonder if this could tie into pbvh tools? (to get the closest edge /
vertex / face etc to mouse cursor?)

On Tue, Mar 21, 2017 at 11:04 PM, Duaret Ramos Sapo 
wrote:

> I am very much interested in this, it is an area I use daily and
> strongly feel could be improved. I would very much love to see this happen.
>
> There already was an attempt at this in the past, but it did not
> succeed: BA Thread
> https://blenderartists.org/forum/showthread.php?255662-
> GSOC-2012-Precision-Modelling-Tools
> and Wiki https://wiki.blender.org/index.php/User:Kellpossible
>
> And there is one awesome project that I think was going in the right
> direction https://developer.blender.org/T45734
>
> Best of luck with this project!
>
>
> On 21-03-2017 18:20, Rohan Rathi wrote:
> > Hi,
> > I've been a blender user since 2.63 and have ample experience with
> creation
> > in blender.
> > I have a very strong base in coding in C/C++(coding in C++ my entire
> life)
> > and have been understanding the code of blender and have implemented a
> few
> > features as well.
> >
> > I'm interested in Improving the snapping toolset and want to discuss
> > potential ideas regarding the project and the mentor available and
> perhaps
> > contact potential mentors directly.
> > The areas I have identified are:
> > 1) Improve the precision while snapping
> > 2) Add new features
> > 3) Improve the UI in snapping
> >
> > I want to discuss the practicality and acceptability of the ideas
> > pertaining an Advanced Snapping Toolset.
> > Any guidance appreciated.
> >
> > Best Regards,
> > Rohan Rathi
> > ___
> > 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] GSoC 2017

[Jacob Merrill]

https://wiki.blender.org/index.php/Dev:Ref/GoogleSummerOfCode/2017

On Mar 20, 2017 3:25 PM, "Jacob Merrill" <blueprintrand...@gmail.com> wrote:

> Best thing you can do is get on irc, #blendercoders
>
> I think there may be a gsoc link in the group description *
>
> On Mar 20, 2017 3:24 PM, "Alexandros Zanias" <alezanias1...@gmail.com>
> wrote:
>
>> Hi there,
>>
>> It is the first time I participate to a GSoC and I would like to know how
>> this project works.
>>
>> Thank you.
>> ___
>> 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 2017

[Jacob Merrill]

Best thing you can do is get on irc, #blendercoders

I think there may be a gsoc link in the group description *

On Mar 20, 2017 3:24 PM, "Alexandros Zanias" 
wrote:

> Hi there,
>
> It is the first time I participate to a GSoC and I would like to know how
> this project works.
>
> Thank you.
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> https://lists.blender.org/mailman/listinfo/bf-committers
>
___
Bf-committers mailing list
Bf-committers@blender.org
https://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Blender developers meeting notes: 2017-02-26

[Jacob Merrill]

Thank you Ton, and the entire team,

Questions:

Will much tighter verse integration for collaboration and in game
multiplayer be a priority in 2.8? If so, how will permissions be handled?

I have never learned more than working beside a master and asking questions
as they come up.

Other issue, if anything is to be lost from bge when swapping to 2.8, is a
method to turn upbge into a addon a possibility?(until it's back up to 100%)

>From what I understand, upbge could use blend4webs frensel node, and effect
the mipmap level of a realtime reflection probe, with this and some
lighting math, and the proper texture input channels, we can do PBR
realtime, with static draw call batching right now.



It's like waiting for a catapillar to turn into a butter fly and murdering
it otherwise.




On Feb 26, 2017 9:10 AM, "Ton Roosendaal"  wrote:

> Hi all,
>
> Here are the notes for today's 1500 UTC meeting in irc.freenode.net
> #blendercoders.
>
> 1) Blender 2.78c release
>
> - There were build problems causing more delays, final tests and checks
> happen now.
> Tomorrow the binaries should be available.
>
> - Change log for 'c':
> https://wiki.blender.org/index.php/Dev:Ref/Release_
> Notes/2.78/Performance_update2
>
> 2) Targets for Blender 2.79
>
> - We move to BCon2 (targets final) this week. The target list:
> https://wiki.blender.org/index.php/Dev:2.7
>
> - We still need to solve how to add the 'Filmic Blender' configure file in
> a way it's
> compatible. Maybe via User Preferences? Need someone to pick up this task
> to solve.
>
> - New target: Datablock ID Properties. https://developer.blender.org/D113
>
> - Mai Lavelle's Cycles split kernel work is almost there. There are some
> regressions for nvidia OpenCL.
> Sergey Sharybin reviews and checks this before a merge happens.
>
> - OpenHMD is almost ready. Julian Eisel and Joey Ferwerda will finish
> working on it in Amsterdam next week.
>
> - The new 'Surface Deform' modifier can be added. Go for it Luca Rood!
>
> - Bezier Tools GSoC patch, urgent call for reviewers.
>
> - And, call for coders of patches for OpenVDB render (Kevin) and Action
> Tools (Joshua) to speak
> up if their work is ready!
>
> 3) Blender 2.8 projects
>
> - Discussion about custom properties code: let's not all implement own but
> stick to one system in Blender?
> Dalai Felinto and Bastien Montagne will contact about it. Also UPBGE seems
> to use own property system.
>
> - There is Development Fund budget to support a 2.8 GE project as well.
> There's still time enough to talk  about this.
>
> - This proposal for 2.8 GE work by Mitchell Stokes is still valid:
> https://docs.google.com/document/d/1iL4-VRTTrI01TQkFl6VO2IYjM70g5DOtCq
> 86YbfVHsU/
>
> - Further not much news, aside for Campbell Barton coming back to help us
> with it!
>
> 4) Other topics
>
> - Tomorrow Google will announce which .orgs will be participating this
> year.
>
> - Blendercoders IRC meeting had a record of 215 people attending! Luckily,
> most were lurking!
>
> Thanks,
>
>
> -Ton-
>
> 
> Ton Roosendaal  -  t...@blender.org   -   www.blender.org
> Chairman Blender Foundation, Director Blender Institute
> Entrepotdok 57A, 1018 AD, Amsterdam, the Netherlands
>
>
>
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> https://lists.blender.org/mailman/listinfo/bf-committers
>
___
Bf-committers mailing list
Bf-committers@blender.org
https://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Blender 101 / workflow project

[Jacob Merrill]

Welcome Back Campbell!

On Thu, Feb 23, 2017 at 10:15 AM, tristan panzer <
republicthunderbo...@gmail.com> wrote:

> Welcome back !
>
> Tristan.
>
> 2017-02-23 18:05 GMT+00:00 Ton Roosendaal :
>
> > Hi,
> >
> > Big grin :) Welcome back!
> >
> > -Ton-
> >
> > 
> > Ton Roosendaal  -  t...@blender.org   -   www.blender.org
> > Chairman Blender Foundation, Director Blender Institute
> > Entrepotdok 57A, 1018 AD, Amsterdam, the Netherlands
> >
> >
> >
> > > On 23 Feb 2017, at 14:59, Campbell Barton 
> wrote:
> > >
> > > Hi, after a 7 months away I'm happy to announce I'll be working for
> > > the Blender-Foundation again!
> > > It's work from home, on a per-project basis.
> > >
> > > I'll be focusing on the Blender-101 and work-flow improvements starting
> > March.
> > > Also some time on code-review and fixing bugs in UI/workflow related
> > > areas so as not to put too much pressure on existing maintainers.
> > >
> > > Noticed new developers getting involved and 2.8x progress is great to
> > see :)
> > >
> > > Regards,
> > > - Campbell
> > > ___
> > > 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] Bug Fixing process survey

[Jacob Merrill]

GAN assisted texture synthesis using pointiness attribute to provide line
work.

On Thu, Feb 16, 2017 at 11:02 AM, Eibriel  wrote:

> Hi Ton,
> I'll be happy to discuss ideas about how bug fixing could be improved.
>
> My interest on this came not from any flaw on the current process, but
> after learning about the possibility of Machine Learning to assist with
> some tasks.
>
> Some time ago I presented here the idea to automatically tag Bug Reports
> as "Incomplete", and I get very good feedback explaining why that is not as
> useful as I previously thought.
>
> Other aspects where Machine Learning could help are:
>
> - Reproducing the issue
> - Finding the section of code to change
> - Making the actual change
> - Validating the changes
>
> Reproducing the issue using Machine Learning is extremely hard, beyond
> current possibilities. This is a Reinforcement Learning problem, the only
> think we can do here is to add Blender to OpenAI Universe framework, so
> researchers can play with it.
>
> Finding the section of code to change is currently possible, the software
> could read the description and output a list of Files or Functions with
> related code.
>
> Making the actual change is only possible for a marginal type of issues.
>
> And validating the changes have the same limitations as Reproducing the
> issue.
>
> So currently the only step I can work on is "Finding the section of code
> to change", How useful could be such tool, and what characteristics should
> it have?
> Also, do you have some ideas about other places where Machine Learning
> could be useful?
>
> Bests,
> Gabriel
>
>
> El 16 de febrero de 2017 10:26:11 GMT-03:00, Ton Roosendaal <
> t...@blender.org> escribió:
> >Hi Eibriel,
> >
> >I am not sure what you want this for, or what this will be used for, or
> >what the use in general.
> >Making good questionnaires is hard and often a huge waste of time for
> >everyone. Usually it just satisfies personal curiosity.
> >
> >In the future, I would appreciate it when people who feel the urge to
> >send questionnaires to this list, to suppress that feeling.
> >
> >When people think that our bug fixing process needs to be improved, I'd
> >be happy to discuss it here.
> >
> >All the best,
> >
> >-Ton-
> >
> >
> >Ton Roosendaal  -  t...@blender.org   -   www.blender.org
> >Chairman Blender Foundation, Director Blender Institute
> >Entrepotdok 57A, 1018 AD, Amsterdam, the Netherlands
> >
> >
> >
> >> On 16 Feb 2017, at 13:06, Eibriel  wrote:
> >>
> >> Thanks to all developers that completed the survey.
> >> If you are new with Blender, with zero or just a couples of commits
> >don't be shy, this survey is exactly for you!
> >>
> >> Survey: https://goo.gl/forms/u6CQ3clsRBrGiVnw1
> >>
> >> Thanks!
> >> Eibriel
> >>
> >>
> >> El 13 de febrero de 2017 19:50:17 GMT-03:00, Eibriel
> > escribió:
> >>> Hi! I'm doing a small survey to spot bottlenecks on the Bug Fixing
> >>> process,
> >>>
> >>> https://goo.gl/forms/u6CQ3clsRBrGiVnw1
> >>>
> >>> please feel free to fill it, and share it! (I don't have Twitter)
> >>>
> >>> Thanks! :D
> >>
> >> --
> >> Eibriel
> >> ___
> >> 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
>
> --
> Eibriel
> ___
> 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] New Developer / small fix question

[Jacob Merrill]

another bug to chase down that I know is still around with textures

Bake a texture -> pack the texture -> try a rebake and save a new copy with
the same name from the same buffer you baked the last one -> load copy
(still have old file)





On Wed, Feb 15, 2017 at 9:35 PM, Sc Ch  wrote:

> Hi. I'm a new developer interested in starting off with a small fix, but
> I'm not sure if it's actually by design or is indeed a bug. It has to do
> with the discrepancy between texture names in the properties editor and the
> names in the paint slots in the tools panel while in texture paint mode.
> Should I create a bug for this and move on from there, or should I carry on
> this conversation somewhere else? In either case, sorry for the intrusion.
>
> On 14 February 2017 at 03:00,  wrote:
>
> > Send Bf-committers mailing list submissions to
> > bf-committers@blender.org
> >
> > To subscribe or unsubscribe via the World Wide Web, visit
> > https://lists.blender.org/mailman/listinfo/bf-committers
> > or, via email, send a message with subject or body 'help' to
> > bf-committers-requ...@blender.org
> >
> > You can reach the person managing the list at
> > bf-committers-ow...@blender.org
> >
> > When replying, please edit your Subject line so it is more specific
> > than "Re: Contents of Bf-committers digest..."
> >
> >
> > Today's Topics:
> >
> >1. Successful build against system audaspace-1.3.0 (Dave Plater)
> >2. Bug Fixing process survey (Eibriel)
> >
> >
> > --
> >
> > Message: 1
> > Date: Mon, 13 Feb 2017 19:24:48 +0200
> > From: Dave Plater 
> > Subject: [Bf-committers] Successful build against system
> > audaspace-1.3.0
> > To: bf-blender developers 
> > Message-ID: 
> > Content-Type: text/plain; charset=utf-8; format=flowed
> >
> > Hi, just to let you know that blender-2.78b builds with external
> > audaspace-1.3.0 in openSUSE build service.
> >
> > Regards
> >
> > Dave Plater
> >
> >
> >
> > --
> >
> > Message: 2
> > Date: Mon, 13 Feb 2017 19:50:17 -0300
> > From: Eibriel 
> > Subject: [Bf-committers] Bug Fixing process survey
> > To: bf-committers@blender.org
> > Message-ID: <7db6be86-f48f-86a6-8f11-b912f7c68...@eibriel.com>
> > Content-Type: text/plain; charset="windows-1252"
> >
> > Hi! I'm doing a small survey to spot bottlenecks on the Bug Fixing
> process,
> >
> > https://goo.gl/forms/u6CQ3clsRBrGiVnw1
> >
> > please feel free to fill it, and share it! (I don't have Twitter)
> >
> > Thanks! :D
> >
> >
> > -- next part --
> > A non-text attachment was scrubbed...
> > Name: signature.asc
> > Type: application/pgp-signature
> > Size: 819 bytes
> > Desc: OpenPGP digital signature
> > Url : http://lists.blender.org/pipermail/bf-committers/
> > attachments/20170213/2a3e2973/attachment-0001.pgp
> >
> > --
> >
> > ___
> > Bf-committers mailing list
> > Bf-committers@blender.org
> > https://lists.blender.org/mailman/listinfo/bf-committers
> >
> >
> > End of Bf-committers Digest, Vol 151, Issue 12
> > **
> >
>
>
>
> --
> --Suchaaver Chahal
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> https://lists.blender.org/mailman/listinfo/bf-committers
>
___
Bf-committers mailing list
Bf-committers@blender.org
https://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Blender developers meeting notes - 2017-02-5

[Jacob Merrill]

Any word about the vive plugin of blender?  TheOnlyBouncer was talking
about it maybe squeeking in 2.79

On Feb 5, 2017 8:11 AM, "Ton Roosendaal"  wrote:

> Hi all,
>
> Here are the notes from today's 15 UTC meeting in irc.freenode.net
> #blendercoders.
>
> 1) Blender 2.78b, performance update
>
> - Linux and Windows binaries are ready
>
> - Mac OS version is coming soon. Sergey Sharybin will provide a release
> text and benchmark info.
> Ton Roosendaal will do updates on blender.org and logs.
>
> - Expected release date: this Tuesday.
>
> 2) Blender 2.79 targets
>
> - Project page has been updated, with planning proposal:
> https://wiki.blender.org/index.php/Dev:2.7#Release_Cycle
>
> - End of this month we want to make the final selection of targets.
> End of March these then should be finished in master.
>
> - Shadow Catcher will go to master Tuesday latest. Thomas Beck will assist
> Sergey with demos/docs.
>
> - Lukas Stockner's denoiser now is on the target list too. Lukas will
> remove the unfinished bits first.
>
> - Mai Lavelle's split kernel (OpenCL) en auto-tile-size project will be
> ready for merging in 2.79 too.
>
> - Luca Rood reminds everyone to test his deform modifier:
> https://wiki.blender.org/index.php/User:Lucarood/SurfaceDeform
>
> 3) Blender 2.8
>
> - We had a 90 minutes well visited project meeting in irc last week.
> Dalai Felinto will post the log and notes of that meeting here.
>
> - In general we will move as much development in one 2.8 branch now.
>
> 4) Google Summer of Code
>
> - Forms have been submitted, the Ideas page will get a last treatment this
> week.
> Deadline is 9 February. Google will announce the accepted orgs on 27
> February.
>
> - We can always use more mentors! Make sure you're known as mentor
> candidate by speaking up here.
>
> 5) Other news
>
> Luca Rood will pack his bags in Brazil and will move to the Netherlands!
> He gets a job at
> Blender Institute per April. He will work with Dalai (viewport) and Sergey
> (depsgraph), work on
> getting particles/hair restored in 2.8 and will do his share in dev
> support and fixes in the tracker.
>
> Laters,
>
> -Ton-
>
> 
> Ton Roosendaal  -  t...@blender.org   -   www.blender.org
> Chairman Blender Foundation, Director Blender Institute
> Entrepotdok 57A, 1018 AD, Amsterdam, the Netherlands
>
>
>
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> https://lists.blender.org/mailman/listinfo/bf-committers
>
___
Bf-committers mailing list
Bf-committers@blender.org
https://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] UPBGE merge question/plan.

[Jacob Merrill]

No link to the doc here?

On Sun, Jan 29, 2017 at 8:37 AM, tristan panzer <
republicthunderbo...@gmail.com> wrote:

> Hi, upbge team share with main devs/project leaders this editable document
> copy. The goals:
>
> - Ask fundamental questions about the possibility to keep BGE alive in 2.8
> with upbge update.
> - See if upbge can be compatible with 2.8 project.
> - Inform devs on what we did.
> - Tell who we are.
>
> - Make a discussion possible with BF devs about upbge project (The document
> can be edited by all people who have the link)
> - Try to get infos/answers about the questions we are asking ourselves.
> - Try to coordinate a bit.
>
>
> - The doc has 4 pages + 1 page dedicated to a bad joke.
> - The person to who we will send the link: merwin, dfelinto, hypersomniac,
> kaito, Severin, mont29, Moguri, Kupoman, Brecht, Blendify...
> We don't know all devs who might be interested/concerned.
>
> If you have infos/commit links/ideas/proposals/answers... that could
> interest us, could you add it in the shared doc please?
>
> Thanks very much for your attention!
>
> ___
> 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] Interested in becoming a contributor.

[Jacob Merrill]

there is also right click select
https://rightclickselect.com/p/


On Dec 24, 2016 7:37 PM, "Aaron Carlisle"  wrote:

> Hi Vaibhav,
>
> If you want small projects to work on check out the quick hacks project
> [1].
> You can also help by fixing easy bugs [2] or a todo [3].
> All of these are easy ways to start learning the Blender code base.
>
> 1. https://developer.blender.org/project/view/34/
> 2. https://developer.blender.org/maniphest/project/2/type/Bug/
> 3. https://developer.blender.org/maniphest/project/2/type/To%20Do/
>
>
> Aaron Carlisle
>
> Picture taker | Bit cruncher | Pixel pusher | Document writer | Artist
> Project administrator for the Blender 3D Documentation Project
>
> On Sat, Dec 24, 2016 at 8:13 AM, vaibhav dixit  >
> wrote:
>
> > Hello,
> > Sir I am a student of Mathematics and Computing at Indian Institute of
> > Technology- BHU, Varanasi, India. I have been going through your website
> > and Wiki for the past few days and found it very intriguing and want to
> > become a contributor. I was looking to become associated with a project
> for
> > GSOC-17 with your organisation. Meanwhile I want to become associated
> ASAP
> > and would love to hear back from you regarding some projects I could work
> > on.
> >
> > Regards
> > Vaibhav Kumar Dixit
> >
> > P.S.- I am proficient at C and C++ and would prefer if you put me on some
> > project which I could do with these languages at my disposal.
> > ___
> > 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] Viewport project - plan of action

[Jacob Merrill]

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?

Whenever you think the new draw calls are ready I am sure panzergame and
youle and twister_GE are ready to integrate it.

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

Will the game engine be using evee?

On Dec 16, 2016 8:29 PM, "Mike Erwin" <significant@gmail.com> wrote:

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

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

[Jacob Merrill]

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

is forward+ rendering possible with a 3.2 glsl profile?

what lighting system will the realtime eve use?


On Dec 16, 2016 1:48 AM, "Dalai Felinto"  wrote:

> Hi,
> (cross-posting, bf-comitters and bf-viewport)
>
> Clément Foucault started working this week for Blender, and he came
> over the institute to discuss a "viewport kickoff".
>
> We (Ton, and Sergey included) cooked together the follow plan of action:
> https://code.blender.org/2016/12/viewport-project-plan-of-action/
>
> I will port this over to the wiki soon. In fact, I'm planning to
> reorganize the Blender 2.8 wiki docs. I think it's really hard right
> now to get a clear picture of the valid plans by looking at the posted
> docs there.
>
> Best regards,
> 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] blendfile standalone python library

[Jacob Merrill]

that sounds very handy indeed

thank you!

is there an api somewhere for the lib?

can it write a gameobject mesh to a blender mesh?

On Dec 3, 2016 5:08 AM, "Dalai Felinto"  wrote:

> Hi Jacob,
> It is the other way around.
>
> It's not about bring pip into Blender. It is about bringing
> blendfile into pip.
>
> Also be aware that blendfile is NOT bpy. It doesn't have operators, it
> doesn't have a high-level API. It's a low level library to read/write
> blendfiles.
>
> 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] blendfile standalone python library

[Jacob Merrill]

does this mean I will be able to use pip to install things like PYTTSX or
PIL etc with pip inside a blender distro?

On Fri, Dec 2, 2016 at 2:27 AM, Dalai Felinto  wrote:

> Hi there,
>
> The blendfile.py project provides a python module to read/write .blend
> files. This project started in 2009 by Jeroen Bakker, and was later
> maintained and developed further by multiple developers (Campbell
> Barton, Bastien Montage, Sybren Stüvel).
>
> Although long-lived, the library only existed inside the Blender
> source code repository (as part of the io_blend_utils addon). This
> made it difficult for stand-alone Python projects to use its latest
> version and use it as a regular Python library.
>
> We moved on and the library is now here:
> https://pypi.python.org/pypi/blender-file
>
> Which means you can install it by simply doing: `pip install blender-file`:
>
> The project is hosted officially in this repository:
> https://developer.blender.org/diffusion/BBF/
>
> It will be nice to extend the package test suite further. So far I
> made some tests that cover 64% of the code. And as a side benefit,
> testing also adds exemplication for the library usage, which we
> strongly lacked.
>
> Thanks everyone for the blendfile development. In particular Bastien
> Montage, Sergey Sharybin, Francesco Siddi, Sybren Stüvel for the help
> with this migration, test suit, examples, ...
>
> Best regards,
> 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] GSoC-2017

[Jacob Merrill]

checkout rightclickselect.com and then investigate what these features
would take.

in general game logic will need a bunch of work.
(but is a bit of a tangle)(bricks ui to cycles nodes for example)

pbvhtree was added in a previous gsoc and someone should in theory be able
to accelerate a bunch of tools including new ones like painting vertex
color and sculpting in 1 stroke. (think leave a zipper or weld in 1 stroke
on a high poly sculpt(on multiple channels))

I would love to have the ability to keyframe uv cords (for sprites etc)
for use in the game engine* but I think a texture action would be usefull
even to cycles users etc.

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.

On Dec 1, 2016 4:10 PM, "Sebastián Barschkis"  wrote:

> Dear Varun,
>
> Yes, with strong Python and C skills you should be able to navigate the
> code base.
> In addition to that, I think it would also be helpful to know the basics of
> computer graphics. Especially in the area that you would like to work in.
>
> To get started with Blender, I'd suggest you do the following:
>
> 1. Build Blender from source.
> 2. Check out this years GSoC ideas page:
> https://wiki.blender.org/index.php/Dev:Ref/
> GoogleSummerOfCode/2016/Ideas
> 3. Identify some areas that you like and where you could see yourself
> working in.
> 4. Visit the Blender developers IRC channel (#blendercoders) and ask about
> your
> area of choice. Figure out current issues and who is working in that
> area.
>
> Someone will probably tell you where in the code its best to start. Try to
> understand that code (don't worry if it takes some time), make some
> changes and
> play around :)
>
> From there, it's basically a process of "lather, rinse, repeat". That is:
> come
> back to IRC, ask something, try it out in the code, repeat.
> If your changes turn out to be useful you can bundle them and submit a
> patch.
> And boom - your on your way to GSoC'17 :)
>
> Hope this helps, feel free to ask if you get stuck!
>
> Best wishes,
> Sebastián
>
> P.S.: It might also be a good idea to ask some of the previous GSoC
> students
> about their experience. Some, including me, are still on IRC regularly.
>
> > On Dec 1, 2016, at 8:29 PM, Varun Garg  wrote:
> >
> > Dear Developers,
> >
> > I am interested in applying for Google Summer of Code'17. I have a pretty
> > strong base in Python and C . Would I be needing anything else to
> > contribute to Blender Foundation? From where should I start?
> >
> > Regards
> > Varun Garg
> > ___
> > 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 developers meeting minutes, 2016-11-06

[Jacob Merrill]

for the 2.8 project, will we be able to paint and sculpt in 1 stroke using
the gsoc pbvhtree code?

will pbr texture painting similar to substance painter be possible?

I was thinking that we could paint on a highly subdivided mesh, to multiple
layers of vertex color and sculpt the vertex positions in 1 stroke,

and bake the final from that data,

On Nov 6, 2016 7:55 AM, "Ton Roosendaal"  wrote:

> Hi everyone,
>
> Here are the notes from today's 16 CET / 15 UTC meeting in
> irc.freenode.net #blendercoders.
> NOTE: daylight saving ended, meeting is 1 hour later!
>
> 1) Blender 2.78a
>
> The 'a' update was released before the conference.
> All fine so far, minor regression bugs were reported. We'll check this
> next week.
>
> 2) Other projects and 2.8
>
> - Follow-ups on Blender Conference will be done by Ton Roosendaal this
> week. That includes news on
> the 101 project, OpenCL, the workflow workshop and about how to get more
> devs onboard.
>
> - Meeting confirms (and agrees) to move all new development to the 2.8
> branch.
> That means we give it highest priority to make that branch updated and
> usable.
>
> - Some decisions then also have to be made, about putting back particles,
> about BI render, BGE, etc.
> This can be kept an open discussion topic for the coming weeks.
> Meeting tends to agree on just keeping most of it for now, including
> OpenCOLLADA.
>
> - Last weekend of November is a 'workflow' workshop in Amsterdam, with the
> core UI team
> and a number of active contributors (half developers, half artists). That
> workshop can come with proposal for
> the feature list of 2.8 (compatibility and breakage).
>
> Workshop agenda and discussion will start on the bf-interface list this
> week.
> https://wiki.blender.org/index.php/Dev:Doc/Contact
>
> Laters,
>
> -Ton-
>
> 
> Ton Roosendaal  -  t...@blender.org   -   www.blender.org
> Chairman Blender Foundation, Director Blender Institute
> Entrepotdok 57A, 1018 AD, Amsterdam, the Netherlands
>
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> https://lists.blender.org/mailman/listinfo/bf-committers
>
___
Bf-committers mailing list
Bf-committers@blender.org
https://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Blender Smoke Simulation

[Jacob Merrill]

a smoke particle generator having the property 'kill fire' and 'kill smoke'
would be intresting

you could then randomly generate these particles inside a volume and
dissolve your smoke randomly that way?

On Mon, Jul 11, 2016 at 12:37 PM, Jack Millard 
wrote:

> I was recently creating a smoke simulation when I realized I should offset
> the smokes dissolve for my particle system, I am sure that there is a way
> to do this but someone should really have a setting for random smoke
> dissolving when your using a particle system. Thank you for your time :)
>
> - Jack
> ___
> 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] Current state of Blender's user experience

[Jacob Merrill]

I always wondered, why not use script that is fed a list of inputs by mouse
over?

each subwindow then redraws on changes, the 'result' of the ui is cached,

when you mouse over the subwindow a BVHTree provides the mouse over X and Y
local to the subwindow and Res.

this way every tiny corner of the AI can be edited by the end user, (as a
python script) and the UI could 'Evolve in The Wild'

is this a bad idea?

On Thu, Apr 21, 2016 at 4:49 PM, Daniel Stokes  wrote:

> Looks like I have some reading to do, thanks for the links.
>
> On Thu, Apr 21, 2016 at 3:28 PM, Paweł Łyczkowski <
> pawellyczkow...@gmail.com
> > wrote:
>
> > > if something should be done to improve it, and what could be done to
> > improve it.
> >
> > Here are some links to get you started:
> >
> > https://developer.blender.org/project/profile/12/
> > https://wiki.blender.org/index.php/Dev:Ref/Proposals/UI
> > https://wiki.blender.org/index.php/Dev:2.8/Proposals
> >
> >
> https://docs.google.com/document/d/1ScPMbHv8WRCU2znB7IU2l-W9hH-NLs5weQKLkjqmgpA/edit
> >
> >
> http://blenderartists.org/forum/showthread.php?298932-Blender-UI-Mockups-and-Ideas-Requested
> > https://rightclickselect.com/p/ui
> >
> > On Fri, Apr 22, 2016 at 12:07 AM Daniel Stokes 
> wrote:
> >
> > > Greetings,
> > >
> > > I recently came across this thread on the gamedev sub Reddit:
> > >
> > >
> >
> https://www.reddit.com/r/gamedev/comments/4fs4db/why_dont_more_professional_game_studios_use_free/
> > >
> > >
> > > In that thread are several unfavorable opinions about Blender, mostly
> > about
> > > its UI/UX. I thought we had moved past the opinion of Blender's UI
> being
> > > terrible during the 2.5 time frame, so I was a bit surprised to see
> > several
> > > complaints about it. Unfortunately, there are not a lot of specific
> > > complaints other than "it is not the same as Maya/Max".
> > >
> > > I was curious what others on this mailing list thought about the
> current
> > > state of Blender's user experience, if something should be done to
> > improve
> > > it, and what could be done to improve it.
> > >
> > > Regards,
> > > Daniel Stokes
> > > ___
> > > 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] Add sphere radius check to mathutils.bvhtree

[Jacob Merrill]

Thank you!
that was quick!

On Sat, Mar 19, 2016 at 12:46 AM, Campbell Barton <ideasma...@gmail.com>
wrote:

> Useful functionality to have, something we already supported for KD-Trees:
>
> Committed BVHTree.find_nearest_range(), [0], see API doc [1] and
> example script [2].
>
> [0]:
> https://developer.blender.org/rB26f2fe9528250d8935ded4957da34b5bcc58cf00
> [1]:
> https://www.blender.org/api/blender_python_api_2_77_0/mathutils.bvhtree.html#mathutils.bvhtree.BVHTree.find_nearest_range
> [2]: https://developer.blender.org/P340
>
> On Fri, Mar 18, 2016 at 12:20 PM, Jacob Merrill
> <blueprintrand...@gmail.com> wrote:
> > would it be possible to add a command to get all faces that intersect a
> > sphere to mathutils bvhtree?
> >
> > this would expose additional functionality to python based tools.
> >
> > from this command, a user could also then get all vertices involved in
> the
> > faces returned by the sphere radius command, and then iterate against the
> > small list to get all vertices in a radius,
> >
> > example code
> >
> > FaceList = mathutils.bvhtree.sphereCheck(point,radius)
> >
> > vertices =[]
> > for Face in FaceList:
> >faceV = [Face.v1,Face.v2,Face.v3]
> >if Face.v4:
> >faceV.append(Face.v4)
> >
> >vertices.append(faceV)
> >
> > VinR = []
> > for Vert in vecticies:
> > if (Vert.XYZ-point).magnitude > VinR.append(Vert)
> >
> >
> > #VinR = verts in radius#
> > ___
> > 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] Add sphere radius check to mathutils.bvhtree

[Jacob Merrill]

would it be possible to add a command to get all faces that intersect a
sphere to mathutils bvhtree?

this would expose additional functionality to python based tools.

from this command, a user could also then get all vertices involved in the
faces returned by the sphere radius command, and then iterate against the
small list to get all vertices in a radius,

example code

FaceList = mathutils.bvhtree.sphereCheck(point,radius)

vertices =[]
for Face in FaceList:
   faceV = [Face.v1,Face.v2,Face.v3]
   if Face.v4:
   faceV.append(Face.v4)

   vertices.append(faceV)

VinR = []
for Vert in vecticies:
if (Vert.XYZ-point).magnitudehttp://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] [Bf-Committers] [GSoC] Project P-BVH enhanced vertex painting

[Jacob Merrill]

here is the mouse over magic to get the correct projection to cast the ray

https://github.com/jesterKing/blender/blob/master/blender/release/scripts/templates_py/operator_modal_view3d_raycast.py

Note* this is not the BVH flavored ray - it's just a example of the math to
cast the ray youll need to cast inside the BVHTree
instead *

On Tue, Mar 15, 2016 at 10:25 PM, Jacob Merrill <blueprintrand...@gmail.com>
wrote:

> https://www.youtube.com/watch?v=K-MLpEmVgT8
>
> I build the tree on init -> then I use a hitpoint provided by the game
> engine physics, but I think you will want to use the camera projection and
> the mouse x,y to build the raycast, from there you can get all units in a
> radius, you can then get the distance from the hitpoint to do the color
> based on a multiplier
>
> https://www.youtube.com/watch?v=K-MLpEmVgT8
>
>
> On Tue, Mar 15, 2016 at 10:20 PM, Jacob Merrill <
> blueprintrand...@gmail.com> wrote:
>
>> I have used bvh accelerated raycast via Python to do fx in game in the
>> game engine, and I have also used kdtree,
>>
>> It's fairly simple, and a great idea, would it be in Python, or C etc? If
>> it is python I can help with that.
>> On Mar 15, 2016 10:16 PM, "Nathan Vollmer" <bitin...@isu.edu> wrote:
>>
>>> Hi everyone!
>>>
>>> My name's Nate Vollmer, and I'm a student at Idaho State University
>>> interested in computer graphics. (One of my projects last semester:
>>> http://www2.cose.isu.edu/~bitinat2/RayTracer/)
>>>
>>> I've written a draft for Blender's GSoC realizing the BVH vertex/weight
>>> suggested idea, and was wondering if I could get some feedback/tips on my
>>> proposal. Vertex painting is a very important feature for character
>>> riggers, and I'd like to make it as convenient and efficient as possible.
>>>
>>> I appreciate all the help!
>>> -NateVB
>>> ___
>>> 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-Committers] [GSoC] Project P-BVH enhanced vertex painting

[Jacob Merrill]

https://www.youtube.com/watch?v=K-MLpEmVgT8

I build the tree on init -> then I use a hitpoint provided by the game
engine physics, but I think you will want to use the camera projection and
the mouse x,y to build the raycast, from there you can get all units in a
radius, you can then get the distance from the hitpoint to do the color
based on a multiplier

https://www.youtube.com/watch?v=K-MLpEmVgT8


On Tue, Mar 15, 2016 at 10:20 PM, Jacob Merrill <blueprintrand...@gmail.com>
wrote:

> I have used bvh accelerated raycast via Python to do fx in game in the
> game engine, and I have also used kdtree,
>
> It's fairly simple, and a great idea, would it be in Python, or C etc? If
> it is python I can help with that.
> On Mar 15, 2016 10:16 PM, "Nathan Vollmer" <bitin...@isu.edu> wrote:
>
>> Hi everyone!
>>
>> My name's Nate Vollmer, and I'm a student at Idaho State University
>> interested in computer graphics. (One of my projects last semester:
>> http://www2.cose.isu.edu/~bitinat2/RayTracer/)
>>
>> I've written a draft for Blender's GSoC realizing the BVH vertex/weight
>> suggested idea, and was wondering if I could get some feedback/tips on my
>> proposal. Vertex painting is a very important feature for character
>> riggers, and I'd like to make it as convenient and efficient as possible.
>>
>> I appreciate all the help!
>> -NateVB
>> ___
>> 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-Committers] [GSoC] Project P-BVH enhanced vertex painting

[Jacob Merrill]

I have used bvh accelerated raycast via Python to do fx in game in the game
engine, and I have also used kdtree,

It's fairly simple, and a great idea, would it be in Python, or C etc? If
it is python I can help with that.
On Mar 15, 2016 10:16 PM, "Nathan Vollmer"  wrote:

> Hi everyone!
>
> My name's Nate Vollmer, and I'm a student at Idaho State University
> interested in computer graphics. (One of my projects last semester:
> http://www2.cose.isu.edu/~bitinat2/RayTracer/)
>
> I've written a draft for Blender's GSoC realizing the BVH vertex/weight
> suggested idea, and was wondering if I could get some feedback/tips on my
> proposal. Vertex painting is a very important feature for character
> riggers, and I'd like to make it as convenient and efficient as possible.
>
> I appreciate all the help!
> -NateVB
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] blender requests for gsoc

[Jacob Merrill]

You don't seem to understand,
I already have coded more complex gameplay mechanics using python in the
game engine than anyone,

Native compiled functions like logic bricks are considered program output,
unlike python (import bge marks your script gpl according to the FOSS.)
Also there are limits like GIL that logic does not have.

Radar(choose closest)--and--steer to radar target

Or

Ray(health)--andproperty (hitobject health -5]

This would essentially turn the bricks into logic nodes... Almost.
On Mar 15, 2016 4:02 PM, "Nicholas Polet" <nickpo...@gmail.com> wrote:

> "I code python and love it, but I know it's limitations, and logic does not
> have the same limits." - Jacob Merrill
>
> Python has no more limitations than logic bricks do. In fact, logic bricks
> have many *more* limitations compared to using python in the game engine.
> What you were describing to set a property using sensors data is something
> that would be much better to do in python. This is something that would get
> very messy if you were to handle it with logic bricks (almost all logic get
> messy with logic bricks when you start to build moderately complex flows).
>
>
>
>
>
> On Tue, Mar 15, 2016 at 10:55 PM, Jacob Merrill <
> blueprintrand...@gmail.com>
> wrote:
>
> > I have a gsoc idea,
> >
> > I have a gsoc idea if someone wanted to tackle it
> >
> > Blender game engine logic bricks...
> > Sensors are great handles to events and for evaluations triggers, however
> > the ability to set a property using a sensors data would make them far
> more
> > useful
> >
> > Part 2
> > Make actuators accept property as inputs
> > And fail gracefully if the property data is of the incorrect format.
> >
> > This would make blender game logic strong and flexible.
> >
> > I code python and love it, but I know it's limitations, and logic does
> not
> > have the same limits.
> > On Mar 15, 2016 2:33 PM, "Rusty Wright" <rusty.wri...@gmail.com> wrote:
> >
> > > This is from
> > >
> > >
> >
> http://blenderartists.org/forum/showthread.php?369411-blender-absurdest-absurdities-log/page3
> > > where he says it better than I can:
> > >
> > > * Alphabetize things. When clicking on the Surface drop down in the
> > > Properties window, I get a mixed-up order of the types of shaders
> > > available. It always takes me a minute to get my bearings and find the
> > > shader I actually want. This isn't the only spot where things would
> > benefit
> > > from being alphabetized. There's the Surface -> Normal drop down,
> there's
> > > the search menu, there's the User Preferences Input screen, there's the
> > add
> > > material node menu in the Node Editor, etc.
> > >
> > > * ...but don't alphabetize things too much! The outliner is really
> > useful,
> > > but it should list objects in a case insensitive manner. I know that
> > > computers think in terms of case sensitivity, but non-Linux users do
> not.
> > >
> > > * If you change a color selector so that it takes HSV or hex values,
> have
> > > Blender remember that when saving/opening the file. I almost
> exclusively
> > > paste in hex color values from another program; it's great that Blender
> > > remembers so much in a saved file, but it's a bit annoying how it
> > switches
> > > the default color switcher option back to RGB every time I re-open a
> > file.
> > >
> > > For the 3rd one, about HSV or hex values, these are the three buttons
> in
> > > the color picker under the color wheel.  I always use HSV.  But when I
> > > start a new blender it's set back to RGB and I have to click on the HSV
> > > button again.  Blender does remember it's set to HSV if you do a File
> ->
> > > New, but it's when you quit Blender that it forgets you had it set to
> > HSV,
> > > which I find annoying.
> > >
> > > For the 1st one, the place where I find it very annoying is in the
> > Surface
> > > drop down (Glossy BSDF, Emission, Diffuse BSDF, etc.).
> > >
> > > Thanks
> > > ___
> > > Bf-committers mailing list
> > > Bf-committers@blender.org
> > > http://lists.blender.org/mailman/listinfo/bf-committers
> > >
> > ___
> > Bf-committers mailing list
> > Bf-committers@blender.org
> > http://lists.blender.org/mailman/listinfo/bf-committers
> >
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] blender requests for gsoc

[Jacob Merrill]

I have a gsoc idea,

I have a gsoc idea if someone wanted to tackle it

Blender game engine logic bricks...
Sensors are great handles to events and for evaluations triggers, however
the ability to set a property using a sensors data would make them far more
useful

Part 2
Make actuators accept property as inputs
And fail gracefully if the property data is of the incorrect format.

This would make blender game logic strong and flexible.

I code python and love it, but I know it's limitations, and logic does not
have the same limits.
On Mar 15, 2016 2:33 PM, "Rusty Wright"  wrote:

> This is from
>
> http://blenderartists.org/forum/showthread.php?369411-blender-absurdest-absurdities-log/page3
> where he says it better than I can:
>
> * Alphabetize things. When clicking on the Surface drop down in the
> Properties window, I get a mixed-up order of the types of shaders
> available. It always takes me a minute to get my bearings and find the
> shader I actually want. This isn't the only spot where things would benefit
> from being alphabetized. There's the Surface -> Normal drop down, there's
> the search menu, there's the User Preferences Input screen, there's the add
> material node menu in the Node Editor, etc.
>
> * ...but don't alphabetize things too much! The outliner is really useful,
> but it should list objects in a case insensitive manner. I know that
> computers think in terms of case sensitivity, but non-Linux users do not.
>
> * If you change a color selector so that it takes HSV or hex values, have
> Blender remember that when saving/opening the file. I almost exclusively
> paste in hex color values from another program; it's great that Blender
> remembers so much in a saved file, but it's a bit annoying how it switches
> the default color switcher option back to RGB every time I re-open a file.
>
> For the 3rd one, about HSV or hex values, these are the three buttons in
> the color picker under the color wheel.  I always use HSV.  But when I
> start a new blender it's set back to RGB and I have to click on the HSV
> button again.  Blender does remember it's set to HSV if you do a File ->
> New, but it's when you quit Blender that it forgets you had it set to HSV,
> which I find annoying.
>
> For the 1st one, the place where I find it very annoying is in the Surface
> drop down (Glossy BSDF, Emission, Diffuse BSDF, etc.).
>
> Thanks
> ___
> 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