[Bf-committers] Are You Attending San Diego Comic-con International Next Week?

[W. Nelson]

Hi All!
If you are attending Comic-con International next week in San Diego please let 
me know.  I am organizing it on the San Diego Blender Meetup Community page.
http://www.meetup.com/Blender/San-Diego-CA/1184812/

BA thread:

http://blenderartists.org/forum/showthread.php?343661-Blenderheads-Social-Mixer-Meetup-at-Comic-con-International-in-San-Diego!&p=2690072#post2690072


Drop into #lablender on freenode.net and IRC chat with me also if you want.

SEE YOU THERE!
JTa
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

[Bf-committers] Simplify Particles toggle patch approval requested

[W. Nelson]

Just a reminder, a very useful and frequently requested particles workflow 
patch is stuck in limbo.  This is a much needed patch that makes only 
minor modifications but has major improvement in workflow.


It is a simple toggle to stop particles from rendering so composition is 
easier in larger scenes and the computer does not get over worked so 
much.

https://developer.blender.org/D355

It has been waiting for final approval for a long time.  This is a simple 
toggle and helpful to anyone working with particles.

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

[Bf-committers] Simplify Particles toggle patch approval requested

[W. Nelson]

Just a reminder, a very useful and frequently requested particles workflow 
patch is stuck in limbo.  This is a much needed patch that makes only minor 
modifications but has major improvement in workflow.


It is a simple toggle to stop particles from rendering so composition is easier 
in larger scenes and the computer does not get over worked so much.

https://developer.blender.org/D355

It has been waiting for final approval for a long time.  This is a simple 
toggle and helpful to anyone working with particles.

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

Re: [Bf-committers] Learning Blender Code?

[W. Nelson]

In my experience it is not just the code takes a "long time" but is the lack of 
specific useful inline documentation and a need for a really good IDE/debugger 
workflow.  So I started making my own code docs when I figured out coding 
techniques.   The code in general is also not usually modular and has some 
unusual conventions so it is a hard read the source without a full debug and 
trace environment to watch it execute.






Then I started working on my IDE/debugger workflow.  So mapping out the pointer 
usage, call backs and variable naming patterns speeds up the "long time to 
learn" process considerably for me.  I also have a strong background as a 
programmer in proprietary code from scratch, maintenance code and some 
experience with other FOSS projects.  So part of the challenge in my experience 
is not assuming things known from these other experiences but rather watching 
Blender code execute so you can see its assumptions and patterns.

So cycling very fast through the debugger to see how the window management code 
blends in with the other code has been very helpful to me in speeding up seeing 
Blender's assumption picture.  You will need to set key breakpoints then 
rapidly step out of the functions to watch the call list.  Once you can 
recognize and ignore the window management code, then there is less code to 
understand.  Once you recognize the callback code and variable naming and 
pointer code patterns then you start getting to the algorithmic code.  The 
algorithms will make much more sense more quickly.


Reading the header files also 
helped speed things up for me.  They sometimes have the only 
documentation for that section of code.  So that's where personal notes 
come handy to remember key variable names and defines when in the 
executing or algorithmic parts of the code.  Also folding the code levels in 
your IDE helps see the big picture of each individual file.  Then expand the 
functions that look relevant.  This really cuts down on the noise and helps 
focus.


The relevant DNA files to the area you are working in help with understanding 
the data.  So always glance at those relevant files.  They are formatted 
DNA_[name].types.h "They are your friend" I was told by a dev.  Tracing the 
symbols in the debugger helps out tremendously.  Also, as in QT Creator, 
"Follow symbol under the cursor" will show you where it came from and there may 
be some insight there.   Also the wiki contains some prefix definitions that 
help sort things out so you can recognize a prefix as belonging to a specific 
part of the code.  Some of the code intertwines very heavily, so it is 
important to sort that out and learn what code to ignore.  Also there is still 
some unused code that has not been removed that can be confusing.  So beware of 
that dead end.


So the pattern here is a good workflow and coding/debugging environment speeds 
up things considerably more than just reading the code in a simple editor and 
trying to wrap you mind around it manually.  So in my experience a good working 
environment and tools, memorizing a few key techniques and making some notes 
mapping and defining things can reduce the "it just takes a long time" down to 
something manageable with Blender's particular code base.  So hopefully you 
more quickly get to where you can achieve some usable results. 

After that, when adding to the code, make sure to keep in line with the wiki 
guidelines.  Also check out the dev's personal pages for information on coding. 
 I think Sergey/Nazg-gul and Cabpbell/Ideasman42 both have some useful 
information on their personal pages.  Other devs may also.

So to recap:
Once you get the technique and workflow down the time is reduced substantially
In the debugger watch and learn the code flow in the function call window 
rapidly several times by stepping out repeatedly

Check the header files and DNA_[name]_types.h files
Follow the symbols back to where they came from in the code to start seeing 
that patern

Take notes to map things out and as reminders
Spend some time identifying window management and call back code so you can 
learn to ignore it when needed.


Keep refining your techniques and things speed up.  Good luck!
JT
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Learning Blender Code?

[W. Nelson]

In my experience it is not just the code takes a "long time" but is the lack of 
specific useful inline documentation and a need for a really good IDE/debugger 
workflow.  So I started making my own code docs when I figured out coding 
techniques.   The code in general is also not usually modular and has some 
unusual conventions so it is a hard read the source without a full debug and 
trace environment to watch it execute.


Then I started working on my IDE/debugger workflow.  So mapping out the pointer 
usage, call backs and variable naming patterns speeds up the "long time to 
learn" process considerably for me.  I also have a strong background as a 
programmer in proprietary code from scratch, maintenance code and some 
experience with other FOSS projects.  So part of the challenge in my experience 
is not assuming things known from these other experiences but rather watching 
Blender code execute so you can see its assumptions and patterns.

So cycling very fast through the debugger to see how the window management code 
blends in with the other code has been very helpful to me in speeding up seeing 
Blender's assumption picture.  You will need to set key breakpoints then 
rapidly step out of the functions to watch the call list.  Once you can 
recognize and ignore the window management code, then there is less code to 
understand.  Once you recognize the callback code and variable naming and 
pointer code patterns then you start getting to the algorithmic code.  The 
algorithms will make much more sense more quickly.


Reading the header files also 
helped speed things up for me.  They sometimes have the only 
documentation for that section of code.  So that's where personal notes 
come handy to remember key variable names and defines when in the 
executing or algorithmic parts of the code.  Also folding the code levels in 
your IDE helps see the big picture of each individual file.  Then expand the 
functions that look relevant.  This really cuts down on the noise and helps 
focus.


The relevant DNA files to the area you are working in help with understanding 
the data.  So always glance at those relevant files.  They are formatted 
DNA_[name].types.h "They are your friend" I was told by a dev.  Tracing the 
symbols in the debugger helps out tremendously.  Also, as in QT Creator, 
"Follow symbol under the cursor" will show you where it came from and there may 
be some insight there.   Also the wiki contains some prefix definitions that 
help sort things out so you can recognize a prefix as belonging to a specific 
part of the code.  Some of the code intertwines very heavily, so it is 
important to sort that out and learn what code to ignore.  Also there is still 
some unused code that has not been removed that can be confusing.  So beware of 
that dead end.


So the pattern here is a good workflow and coding/debugging environment speeds 
up things considerably more than just reading the code in a simple editor and 
trying to wrap you mind around it manually.  So in my experience a good working 
environment and tools, memorizing a few key techniques and making some notes 
mapping and defining things can reduce the "it just takes a long time" down to 
something manageable with Blender's particular code base.  So hopefully you 
more quickly get to where you can achieve some usable results. 

After that, when adding to the code, make sure to keep in line with the wiki 
guidelines.  Also check out the dev's personal pages for information on coding. 
 I think Sergey/Nazg-gul and Cabpbell/Ideasman42 both have some useful 
information on their personal pages.  Other devs may also.

So to recap:
Once you get the technique and workflow down the time is reduced substantially
In the debugger watch and learn the code flow in the function call window 
rapidly several times by stepping out repeatedly

Check the header files and DNA_[name]_types.h files
Follow the symbols back to where they came from in the code to start seeing 
that patern

Take notes to map things out and as reminders
Spend some time identifying window management and call back code so you can 
learn to ignore it when needed.


Keep refining your techniques and things speed up.  Good luck!
JT






 From: John Alway 
To: bf-blender developers  
Sent: Wednesday, July 2, 2014 10:04 AM
Subject: Re: [Bf-committers] Learning Blender Code?
 

Thanks to everyone for the excellent feedback.

Thanks, Jonathan for the details on nurbs.   I definitely don't want to
step on any toes.  I was just looking for a way to get started and thanks
for the green light!

Regards,
...John


On Wed, Jul 2, 2014 at 11:39 AM, Jonathan deWerd 
wrote:

> >> So, I'm wondering how others have learned the code, or is it just a
> matter
> >> of putting in lots of time?
>
> It's just a matter of putting in lots of time. Not what you wanted to hear
> but I think you suspected it was true already.
>
> I'm the summer student working on NURBS. Just wa

Re: [Bf-committers] Blender into a pipeline

[W. Nelson]

Excellent!  That works.  Referencing is much more important than browsing at 
this point.  It is an excellent baseline.  I will make sure the word gets out 
to test it and let you know how my tests go.  Thanks Andrea and Campbell!

JTa





 From: Campbell Barton 
To: bf-blender developers  
Sent: Monday, April 21, 2014 7:46 PM
Subject: Re: [Bf-committers] Blender into a pipeline
 

To follow up on this topic, Andrea Weikert committed UNC support yesterday.

While you can't yet browse network shares, you can use them in your projects.

https://developer.blender.org/rB5afb0abfbd7b93d6b42c594146b53f3ab5d6b9d0

___
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] Automated testing

[W. Nelson]

I wanted to bump this to make sure it did not get buried too deep.
Has anything been added to d.b.o or anywhere else to keep this ball rolling?

Thanks,
JTa




 From: Campbell Barton 
To: bf-blender developers  
Sent: Thursday, March 27, 2014 2:22 PM
Subject: Re: [Bf-committers] Automated testing
 

On Fri, Mar 28, 2014 at 3:14 AM, Reed Law  wrote:
> On 26/03/2014, Bastien Montagne wrote:
>> Well, writing tests is not the funniest part of the work, but I agree we
>> should have more, esp. since we saw again with 2.70 that getting a large
>> amount of users testing even RC's is not an easy thing.
>>
>> And if this means writing more py wrappers to Blender's pieces of code,
>> in the end it's also positive, giving as side effect more tools to
>> scripters (writing tests in a simple, dynamic language like python is
>> much better).
>>
>> And I actually already joined the team by starting work over UI units
>> handling! ;)
>>
>> Cheers,
>> Bastien
>
> Test-driven development (TDD) is more about design than verification. Tools
> like KLEE might provide some utility, but one of the chief goals in writing
> tests is to create a tight feedback loop between design and implementation.
> First off, when you start with writing a test, you're forced to consider
> the external interface. You will consider questions such as how will the
> application use this class or call this function? The second benefit is
> that you don't have to rely on a lot of "manual" prototyping. By that I
> mean creating some throwaway code or using a REPL to test your design
> manually. Your failing test will provide an automated way to see if the
> design is working. Once the test is passing you can then freely refactor
> your code without fear of breaking it.
>
> I used TDD to create a ray tracer  with
> full test coverage. I don't know how I could have done it without writing
> tests upfront. I used the GTest framework to write tests in C++. I'm not
> sure how Blender's python tests are set up, but it seems to me that if
> you're writing tests first it will be hard to do it that way. Don't they
> depend on an interface being present in order to run? In TDD, you only want
> to write the bare minimum to get a test to execute before beginning to
> implement production code. That usually means just empty functions.
>
> I think a good strategy would be to begin requiring test coverage for new
> code and gradually increasing test coverage of old code. The main benefit
> of writing tests for untested code is to aid in refactoring.

This could work in some areas but I think it relies on us having
testing in-place to begin with.

If someone writes new code they shouldn't need to setup a new testing
framework - this is something I rather we do as a project and first
find a good way to test C/C++ code, (building, where to put stubs etc,
which testing system to use... etc).

-- 
- Campbell

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

Re: [Bf-committers] Question about external Blender interface

[W. Nelson]

In #blenderpython on freenode.net a couple other coders and I have talked about 
similar ideas a few times recently.  When I get a chance to post my notes I 
will share them.

We recently talked about PyQT as module and SQLite.  Using SQLite for a 
messaging system instead of using sockets.  Sockets are probably the best way 
to go though.

The hardest part we decided was the messaging system and the timing of it.  
Also keeping any C code additions to Blender to a minimum.  Hopefully it can 
all be done it Python.  That was the hope using SQLite transactions as a 
messaging system.  

I will add more when I have more time.  This is an interesting topic to me also.

JTa





 From: "" 
To: bf-blender developers  
Sent: Friday, April 4, 2014 10:16 AM
Subject: Re: [Bf-committers] Question about external Blender interface
 

Thanks for answering!
I don´t know anything (yet) about python dev inside Blender, could it be
possible to implement it as a plugin?
I´m interested and could dedicate some time in this topic and think doing
it would help the project.

Regards,
Pablo


On Fri, Apr 4, 2014 at 1:16 PM, Dalai Felinto  wrote:

> Hi Pablo,
>
> This can be implemented via Python, but you will need to handle all
> the socket connectivity part.
>
> It would be nice to have this built-in in Blender (maybe as new
> bpy.app.handlers). But I don't think anyone is working on this it at
> the moment.
>
> Dalai
> --
> blendernetwork.org/dalai-felinto
> www.dalaifelinto.com
>
>
> 2014-04-04 13:05 GMT-03:00  :
> > Hi,
> >
> > * My background:
> >
> > I started using Blender a couple of months ago, I´ve been always a fan of
> > 3D and Blender in general since I think it´s an excellent product.
> > I work as a Web and Android developer
> >
> > * The object of the email:
> >
> > Ultimately when using Blender, I thought about using all 5 mouse buttons
> > then it came to me that I have a Joystick with 3d movement and lots of
> > buttons would be interesting using it with blender.
> > Finally I came to the idea of developing an Android application to
> replace
> > the main use of the keyboard.
> >
> > What I don´t know is if Blender allows any kind of connectivity out of
> the
> > app.
> > For example, it could use a port or something to which apps could connect
> > and send in commands, or something else you guys might think of.
> > The possibilities are really big since virtually anything could be used
> to
> > control blender.
> >
> > I would like to know if this is possible and if there are already efforts
> > towards it, I couldn´t find any info on the Web.
> >
> > If this is not the right place to post please let me know.
> >
> > Thanks!
> > Pablo
> > ___
> > 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] Automated testing

[W. Nelson]

Nice to see automated testing gaining traction.  Like I mentioned in last 
Sunday's weekly dev chat, it's helpful to have a check off list.  This is 
especially true when devs are working from different time zones.  If the test 
check off list is not finalized from reports then the version does not get 
officially released.

IMHO this can help avoid "a" releases because it helps avoid official release 
decisions that are made based on opinions.

Even just simple, quick and easy to use written reports and check off lists  
can make the difference by having concrete results to review IMHO and 
experience.  Below is a quick outline I clipped from a website on using a check 
off list and reporting method.  

Respectfully submitted for your consideration,
Thanks always to the core devs for their hard work,
JTa

.

This uses a check off list method:
http://www.projectconnections.com/templates/detail/software-unit-test-plan.html

How to use it
    *Review the Overview of Unit Testing starting on the following page as you 
prepare for code development and testing.
    *Review your design specifications and source code for the units to be 
tested.
    *Create a Unit Test Plan and detailed test cases using the guidelines on 
page 4. Perform a peer review on the Unit Test Plan.
    *Create any test "stubs" required to provide input to or receive output 
from the code module.
    *When it's time to test particular units, compile the code in the test 
environment to check for any missing files required for test plan execution.
    *Execute the tests. Compare information/values received out of the tested 
software to those expected, as documented in the Unit Test Plan.
    *Record any failures on a Unit Test Report Form (page 6), including 
reporting bugs/defects and changes needed to code, and note re-test needed. 
Update the Unit Test Plan if needed.
    *Retest code when an updated version is available. Record results on the 
Unit Test Report Form.
    *When the unit is considered to have passed all tests, archive the final 
Report form(s).
    *Compile Unit Test Report forms related to a given sub-system into a 
Summary Unit Test Report (page 5).
    *Provide any necessary changes/feedback to the related software 
specifications and design/implementation documents.
 





 From: Reed Law 
To: bf-committers@blender.org 
Sent: Thursday, March 27, 2014 9:14 AM
Subject: Re: [Bf-committers] Automated testing
 

On 26/03/2014, Bastien Montagne wrote:
> Well, writing tests is not the funniest part of the work, but I agree we
> should have more, esp. since we saw again with 2.70 that getting a large
> amount of users testing even RC's is not an easy thing.
>
> And if this means writing more py wrappers to Blender's pieces of code,
> in the end it's also positive, giving as side effect more tools to
> scripters (writing tests in a simple, dynamic language like python is
> much better).
>
> And I actually already joined the team by starting work over UI units
> handling! ;)
>
> Cheers,
> Bastien

Test-driven development (TDD) is more about design than verification. Tools
like KLEE might provide some utility, but one of the chief goals in writing
tests is to create a tight feedback loop between design and implementation.
First off, when you start with writing a test, you're forced to consider
the external interface. You will consider questions such as how will the
application use this class or call this function? The second benefit is
that you don't have to rely on a lot of "manual" prototyping. By that I
mean creating some throwaway code or using a REPL to test your design
manually. Your failing test will provide an automated way to see if the
design is working. Once the test is passing you can then freely refactor
your code without fear of breaking it.

I used TDD to create a ray tracer  with
full test coverage. I don't know how I could have done it without writing
tests upfront. I used the GTest framework to write tests in C++. I'm not
sure how Blender's python tests are set up, but it seems to me that if
you're writing tests first it will be hard to do it that way. Don't they
depend on an interface being present in order to run? In TDD, you only want
to write the bare minimum to get a test to execute before beginning to
implement production code. That usually means just empty functions.

I think a good strategy would be to begin requiring test coverage for new
code and gradually increasing test coverage of old code. The main benefit
of writing tests for untested code is to aid in refactoring.
___
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] Layers for Images, third phase is completed!!

[W. Nelson]

Excellent project Fabio.  Sergey brought up in dev chat that your project could 
be improved by changes regarding the use of IDs.  I suggest you contact him for 
more specific information and increasing your odds of getting this into master. 
 Or after you get it on project.b.o you let him know personally to take a look 
at it.

Good luck.  Keep up the good work and hopefully it will get included.  As I 
have mentioned before in dev chat a few times, I really like this type of 
workflow from experience with it in a different all-in-one 3D package.  So I 
hope it gets some traction and serious consideration for inclusion.

Also, if you are not aware of it already, you might want to check out 
DFelinto's new wiki page section on Multi-Image Layer Handling that he recently 
added.  http://wiki.blender.org/index.php/User:Dfelinto/Ideas

Thanks for all your hard work and good luck,
JTa





 From: Antony Riakiotakis 
To: bf-blender developers  
Sent: Wednesday, March 26, 2014 5:01 PM
Subject: Re: [Bf-committers] Layers for Images, third phase is completed!!
 

> Regarding the latest patch of the project is already on phabricator:
> https://developer.blender.org/T30975
> What steps need to follow for code review?
> Where should I put the patch?
>

Hi,

Generally text patches are difficult to review in patch format, but you can
upload a review-formatted patch, by pasting the contents of a git patch at
the bottom of the page here:

https://developer.blender.org/differential/diff/create/

Guidelines can be found here:

http://wiki.blender.org/index.php/Dev:Doc/Tools/Code_Review

It would be best to clone from our git repository, commit the patch to a
separate branch and then of course rebase/merge against latest master.

Arcanist (see docs) also helps though it may be a bit troublesome to setup.
You can commit on the branch and update the same review patch as we will be
discussing the issues in code review too.

Maybe before I fix the bugs reported and I sync with the 2.70, what do you
> think?
>
> If the bugs are not many they could be fixed while we are doing review.
What would help is if we were able to do the review against a rebased
against latest master patch.

>From first quick skip through for code style, code needs some cleanup (left
over comments - even in Italian :) ) but generally doesn't look too bad.
I'll check the architecture more in depth once we have a nice
review-formatted patch on phabricator.

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

Re: [Bf-committers] GSOC 2014 Proposal Rough Draft

[W. Nelson]

Elijah,
have you gotten any feedback in IRC on your proposal?
JTa





 From: Elijah Caine 
To: bf-committers@blender.org 
Sent: Sunday, March 16, 2014 7:36 PM
Subject: [Bf-committers] GSOC 2014 Proposal Rough Draft
 

Hello BFCommitters,

I have completed my rough draft for the GSOC 2014 Proposal to create an
Improved Vector Blur Node. It is hosted on my website, so you can find it
here:

http://people.oregonstate.edu/~voigte/gsoc_2014.pdf

Any and all feedback would be wonderful. I haven't done anything like this
before, both in the huge scale of the Blender Project and in the long
time-line, so I'm completely open to any suggestions.

Thank you,
Elijah
pop_n_fresh @irc.freenode.net
___
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] Los Angeles and USA Blender Developer Meeting March 9th, 2014

[W. Nelson]

We are having a local Working Group developer meeting tomorrow, Sunday March 
9th.  The meeting is not only in person but on line in our chat room.  See more 
info below.  This allows all USA peeps to participate to some degree.  This is 
extremely helpful for our timezone!

Check out the info below taken from our private mailing list if you would like 
to be involved.

Thanks,
JTa

.

LA.blend Working Group Meetup - 
Developer/Programmer/Pipeline/Artist/Documentation

Sunday, March 9, 2014, 3:00 PM - 9:00 PM
iD Cha House
931 West Duarte Road, Monrovia, CA 91076

AND ONLINE! See info below...

This is an excellent opportunity for you to participate and influence Blender 
development. Blender is starting the 2.71 development cycle soon. Please 
forward this email to anyone else you think might benefit from an open 
discussion and local help.

We are having a combined Working Group Meetup. This is an open working group to 
come and hang out with your laptop and work together. We will be collaborating 
on projects involving developers/programmers, production pipelines, artist 
technical development and our pro documentation project.

We will also be on our freenode.net #lablender IRC channel to field questions 
and work with peeps from all over the world. Please email me back if you need 
instructions for IRC. Or you can just jump on http://webchat.freenode.net and 
enter the channel #lablender to get started. Also one of us here can chat with 
you via whatever software you use. Just let us know.

See the Community Meetup page for more information:
http://www.meetup.com/Blender/Los-Angeles-CA/1114142/
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

[Bf-committers] Cmake and CMakeCache.txt questions

[W. Nelson]

Multiple instructions say do a cmake-gui ../blender and then a make from inside 
the build folder.  So: 

Does "make" from inside the build folder use the build folder CMakeCache.txt or 
does it use the ../blender/CMakeCache.txt?   
    
Also, inversely, if you do a "make" from inside the /blender folder does it use 
that CMakeCache.txt file or the one in ../build?  I see that it sets up the 
build folder and uses it for an out of source build.

When you do an update of the source files and do either of these makes, are 
your settings lost to a new CMakeCache.txt file that was just downloaded?

What is the best way to manage multiple CMakeCache.txt files for multiple types 
of builds in the same out of source build folder?

Thanks for the clarifications.  They will help save a lot of time experimenting 
and digging through the scripts.

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

[Bf-committers] Requested change to number input selection

[W. Nelson]

I posted to bf-funboard a requested change to numerical input to speed up the 
workflow for experimenting with numerical settings.

Here's my proposal for quick reference  http://www.pasteall.org/48577

If there are any important dev concerns about this or if this topic has been 
discussed previously, please let me know. 

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

[Bf-committers] Are you coding in screen_ops.c or DNA_screen_types.h?

[W. Nelson]

If you are working in those files, I found the VSE sequencer/preview toggle bug 
and it's there it seems.
It's primarily in screen_ops.c, function: area_max_regionsize() and not in VSE 
code.
The function was never designed for a horizontal space, only for a vertical 
space it seems.
And the VSE sequencer/preview space is the only horizontal + tab pull down/up 
space in Blender.
This is the major part of the bug, the jumping size part, where it doesn't let 
you slide it, it just opens full.
Then there is some VSE logic to also fix after that for consistent behavior.

So I will be hacking away at that code.  Please let me know if you are there 
too so we can coordinate.
Or if you have any familiarity with that particular file and function tips and 
suggestions would be greatly appreciated.

This bug is totally annoying for VSE users so it will be nice to have it fixed.

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

Re: [Bf-committers] Blender 2.69 testbuild1 AHOY

[W. Nelson]

About the chain addon break report for the test build AHOY 
    and the lack of "proactive" warning or documentation 
    of change in python handling code committed to trunk--


Very briefly, something has changed in python handling that has not been 
announced or is not apparent from a quick check of commits and a check of the 
projects page.  After about 15 minutes of checking, I see no "proactive 
notification" of any pending changes. 

This is again the issue that has been discussed previously about unannounced 
changes that break addons without any "proactive" warning.  I agree with Sam 
and his proactive attempt on this mailing list at calling attention to this 
type of "surprise" breakage.


Of course a bug report needs to "reactively" be filed.  But the bigger issues 
is requiring "reactive" actions instead of implementing suggested simple 
"proactive" notifications.


This is the whole purpose of RCs and it has been requested that people give 
more "feedback" on RCs or am I in error in my understanding our RC policy and 
feedback requests?  This is not a rhetorical question so if I am in error 
please enlighten me.  Maybe I am missing or overlooking something.


As a follow-up:
  this needs to be filed as a bug or addon bug of course

  no http://wiki.blender.org/index.php/Dev:Ref/Release_Notes/2.69 
      notification has been posted of this already implemented thus 
"surprising" change

  no easy location of the change and cause in release code is found in commit 
logs

  no notification of pending change has been posted in bf-python as a proactive 
warning

  squeak squeak squeak squeak squeak squeak squeak ; )


Until the bug report is filed heres the console output:

Traceback (most recent call last):
File "C:\Program Files\Blender Foundation\blender-2.68-r60361-win32\2.68\scrip
ts\addons\object_add_chain.py", line 152, in execute
Add_Chain()
File "C:\Program Files\Blender Foundation\blender-2.68-r60361-win32\2.68\scrip
ts\addons\object_add_chain.py", line 71, in Add_Chain
abso_minor_rad=0.5,
File "C:\Program Files\Blender Foundation\blender-2.68-r60361-win32\2.68\scrip
ts\modules\bpy\ops.py", line 188, in __call__
ret = op_call(self.idname_py(), None, kw)
TypeError: Converting py args to operator properties: : keyword "use_abso" unrec
ognized

location: :-1

location: :-1



Thanks always for the hard work and help of core devs,

Respectfully and earnestly,

JTa





 From: Bastien Montagne 
To: bf-blender developers  
Sent: Wednesday, September 25, 2013 11:55 PM
Subject: Re: [Bf-committers] Blender 2.69 testbuild1 AHOY
 

Fixed in r4771, but please use our bug tracker for that kind of report. :)

On 26/09/2013 08:17, Sam Vila wrote:
> The add-on "Chain" has errors so cannot be used. Please check this out.
> 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

Re: [Bf-committers] bf-gamedev mail list

[W. Nelson]

1+




 From: Andy 
To: bf-blender developers  
Cc: bf-blender developers  
Sent: Friday, September 13, 2013 9:58 AM
Subject: Re: [Bf-committers] bf-gamedev mail list
 

This would be great :)

On 13 Sep 2013, at 15:49, Sean Olson  wrote:

> With the new sub-focus on gamedev, would it be possible to get a bf-gamedev
> mail list set up where all things gamedev can go?
> 
> Thanks!
> -Sean
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] [Bf-blender-cvs] SVN commit: /data/svn/bf-blender [59791] trunk/blender/source/blender/ editors/space_view3d/view3d_fly.c: tweaks to fly mode

[W. Nelson]

1+ for fly mode that is usable to position cameras.  It is what I use it for in 
other programs for large scale sets such as pathways between buildings.
JTa





 From: David Jeske 
To: bf-blender developers  
Sent: Wednesday, September 11, 2013 1:35 PM
Subject: Re: [Bf-committers] [Bf-blender-cvs] SVN commit: /data/svn/bf-blender 
[59791] trunk/blender/source/blender/ editors/space_view3d/view3d_fly.c: tweaks 
to fly mode
 

i for one would be happy with a fly mode that was not a game engine, had no
movement over surfaces, but was free of the momentum driven movement. i
just want it to. more easily reposition cameras.
___
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] "+" property panel widget name or location

[W. Nelson]

Perfect! Exactly what I was looking for AE, thanks!
JTs


--
On Tue, Sep 10, 2013 6:46 PM PDT Anthony Edlin wrote:

>That "+" is tied to action zones which are separate from other regular
>interface widgets for whatever reason.  The action zone operators are in
>screen_ops.c file.  Specifically in this case you are looking for the
>region_scale_* set of functions.  The region_scale_toggle_hidden function
>is actually doing the toggle but both _invoke and the _modal functions are
>called even just on clicking the plus.  There is no _exec for the
>region_scale operator.
>
>Good luck.
>
>
>On Tue, Sep 10, 2013 at 4:42 PM, W. Nelson  wrote:
>
>>
>>
>>
>>
>>
>> --
>> On Tue, Sep 10, 2013 2:18 PM PDT W. Nelson wrote:
>>
>> >I need to identify the handling code of the "+" widget that pulls out the
>> properties panel which is also used to pull down the preview area on the
>> both setting for the VSE.  I need it specifically to fix the both VSE
>> preview/sequencer bug.
>> >
>> >
>> >It is difficult to tell the difference from the other very similar named
>> widgets like the 3 line corner chevron widget.
>> >
>> >Thanks in advance,
>> >JTa
>> >___
>> >Bf-committers mailing list
>> >Bf-committers@blender.org
>> >http://lists.blender.org/mailman/listinfo/bf-committers
>>
>> Of specific help is the function that is called when the "+" is clicked on
>> in top of the VSE both area.
>> Thanks,
>> JTa
>>
>> ___
>> 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] "+" property panel widget name or location

[W. Nelson]

--
On Tue, Sep 10, 2013 2:18 PM PDT W. Nelson wrote:

>I need to identify the handling code of the "+" widget that pulls out the 
>properties panel which is also used to pull down the preview area on the both 
>setting for the VSE.  I need it specifically to fix the both VSE 
>preview/sequencer bug.
>
>
>It is difficult to tell the difference from the other very similar named 
>widgets like the 3 line corner chevron widget.
>
>Thanks in advance,
>JTa
>___
>Bf-committers mailing list
>Bf-committers@blender.org
>http://lists.blender.org/mailman/listinfo/bf-committers

Of specific help is the function that is called when the "+" is clicked on in 
top of the VSE both area.
Thanks,
JTa

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

[Bf-committers] "+" property panel widget name or location

[W. Nelson]

I need to identify the handling code of the "+" widget that pulls out the 
properties panel which is also used to pull down the preview area on the both 
setting for the VSE.  I need it specifically to fix the both VSE 
preview/sequencer bug.


It is difficult to tell the difference from the other very similar named 
widgets like the 3 line corner chevron widget.

Thanks in advance,
JTa
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

[Bf-committers] Decrementing the bug tracker ;p

[W. Nelson]

I didn't squash a bug but I did reduce the number by one hopefully ;p
Below is a duplicate bug entry I found during a quick bug sweep of the bug 
tracker.
It's the VSE/preview show bug...and it is annoying btw

So if a dev with permissions can close the newer entry or do whatever you do 
that would be fabulous...

Older report assigned to Ton
https://projects.blender.org/tracker/index.php?func=detail&aid=35709&group_id=9&atid=498

Newer duplicate report
https://projects.blender.org/tracker/index.php?func=detail&aid=36457&group_id=9&atid=498

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

[Bf-committers] UNC shares getting closer to working

[W. Nelson]

I have been discussing the UNC shares fix with Elubie.  She has a quick fix 
that addresses most of the issues.

One of the biggest remaining issues is the use of the double hack use for 
.blend path versus network location handling UNC.  This is a bit tricky since 
there is no uniform file handling routine or module in Blender for all code to 
use.  It is handled by multiple tailored code segments in different parts of 
the codebase.

In the tricky context of it possibly being a UNC or .blend path I propose that 
those routines check a user preference before proceeding.  This will be default 
\\  UNC off and tickable to on.  Or maybe put and operator in the File>External 
Data menu somehow to establish this and maybe save with individual files.


Therefore the user/studio can determine in those circumstances if it wants to 
use \\ as UNC instead of .blend path.  Obviously it will have to establish a 
business rule amongst its workforce that the choice is don't use \\ as a .blend 
path shortcut.  Of course 3rd party addon use will also have to be considered.


The other logic fix is evaluate as a .blend path as usual but if there is an 
error or a detectable discrepancy in loading/saving then evaluate as a UNC path 
next  to see if a the discrepancy is resolved, then if error, fail out if need 
be.  This would work for missing files on load or missing file path segments on 
save.  So in cases where Blender would make a path, it would check first to see 
if there is a valid UNC path of the same reference.  If so, it would use that 
instead of making a path locally where the .blend file is.

These types of fixes could be worked to fix existing code and then there should 
be a coding standard set that subsequent merges/patches will adhere to this 
standard since a standard file i/o module is not very realistic at this point.


This should give a fairly good workable system for those that want to use UNC 
shares


Existing patch tracker ticket:
https://projects.blender.org/tracker/index.php?func=detail&aid=21836&group_id
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Add-ons in Blender for commercial services

[W. Nelson]

The key pivot point to keep in mind is "official release addon" inclusion into 
the official addon folder distributed from the Blender.org "download here" link 
package is what is being proposed.

Of course, anyone can make an addon and distribute it themselves via multiple 
other methods.


JTa



 From: Ton Roosendaal 
To: bf-blender developers  
Sent: Thursday, August 8, 2013 7:09 AM
Subject: Re: [Bf-committers] Add-ons in Blender for commercial services
 

Hi Angus,

The proposal states that there's no difference between 'commercial services' 
addons or regular ones. All addons will go through the same review process and 
need to be proven compliant and useful.

Currently, our reviewing process doesn't accept commercial services, or better 
stated: we don't have guidelines for how to define which ones could be included 
in a release.

If we would add a commercial service addon from provider 'A', the competitor 
'B' would like to have one too, and so on. The proposal was meant to define a 
fair guideline for everyone to know what our procedure is.

-Ton-


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



On 8 Aug, 2013, at 14:50, Angus Hollands wrote:

> Hi,
> Just an initial note; I'm using the batched summary, so I apologise if I've
> missed something, or am reiterating someone else's opinion.
> 
> With regards to these plans, I struggle to identify how a "commercial"
> add-on is different from a "community" developed add-on. Unless there are
> plans to add an interface that provide some additional functionality to the
> commercial developer, I don't think this is the way to go. The reason being
> is this; it looks to me as though we're selectively charging developers to
> use a subset of an open source project that non commercial developers have
> access to. I'm aware that there are scrutinous policies to ensure that we
> don't let substandard works into trunk, so in that respect the commercial
> add-on is treated no differently.
> It reminds me of a recent experience, in which people with employment that
> was connoted to be well paid were targeted as part of a fundraiser. If we
> are to introduce a fee to support development, that should be enforced upon
> all contributors, not just those from commercial origin. How do we
> determine when someone is commercial etc; it seems to be to be rather
> invasive.
> I am fully in support of supporting the development fund; no matter the
> cause, financial incentives are effective, but I'm not sure that I would
> personally agree with using it in this manner. Indeed, apply points one,
> two and three to all developers, but not necessarily number four.
> 
> Regards,
> Angus Hollands (agoose77)
> ___
> 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] Add-ons in Blender for commercial services

[W. Nelson]

So if commercial services become available as an official release addon they 
then would have a wiki category and addon page.  Keeping that organized and 
focused seems like it will help manage the quality.  Also having a clear area 
in the addon preferences to globally disable all or individual ones would help.


For now I think limiting the categories to start and on a trial basis would 
also help keep things focused and manageable.  The 3D printing/hacker/builder 
space movement is very strong and connected to Blender already as are render 
engines and thus render farms.  I think keeping the commercial addon space 
focused on these already integral parts of the Blender community will be of 
direct benefit to segments of the user base.

IMHO,
JTa




 From: Thomas Dinges 
To: bf-blender developers  
Sent: Wednesday, August 7, 2013 8:53 AM
Subject: Re: [Bf-committers] Add-ons in Blender for commercial services
 

Yes, see in Ton's mail "1) Compliancy"

Am 07.08.2013 17:52, schrieb Tom M:
> On Wed, Aug 7, 2013 at 3:40 AM, Ton Roosendaal  wrote:
>> Hi,
>>
>> Hopefully this doesn't become a huge thread - I'd mainly like to get some 
>> feedback from frequent contributors.
>>
>> Some companies have contacted me about the possibility of having an add-on 
>> in our releases that hook up Blender with their services. That's for example 
>> Shapeways, but also render farm providers.
>>
> To clarify, will the addons from these companies be license compatible
> with the rest of the codebase?  Ie GPL license on the addon code?  If
> so, then proposal sounds reasonable and agreeable.
>
> LetterRip
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers


-- 
Thomas Dinges
Blender Developer, Artist and Musician

www.dingto.org

___
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] Clean convert text to mesh

[W. Nelson]

The following workflow is popular with those in chat including motion graphic 
artists and those that work with text regularly. 

Popular fonts with good results:
Bebas and Bebas Neue (Bebas recomended by blenderguru.com, there are other 
popular ones also)
http://www.dafont.com/bebas.font
http://www.dafont.com/bebas-neue.font

(Recomended by Olson and others in #blender)
Object Mode: Object>Convert to>Mesh... (font is not editable as text anymore)
Edit Mode: Mesh>Vertices>Remove Doubles
  Mesh>Delete>Limited Dissolve

Another methods used with varying cost benefits:
Retopo over an existing font>mesh
Modeling from scratch if limited letters are needed (there are some good 
tutorials on this)
Remesh Object Modifier at a low threshold (as already mentioned)

Some references:
http://wiki.blender.org/index.php/Doc:2.6/Manual/Modeling/Texts
http://www.blenderguru.com/videos/how-to-make-metallic-text/
http://www.blenderartist.org/forum/showthread.php?295010-Blender-text-conversion-improvements-wishlist

Some of us that work with fonts and code have been kicking around in chat the 
idea of optimizing this in code or optimizing the retopo/remesh tools to deal 
with fonts better, but todo lists are so long already it may be a while before 
someone gets to it.

JTa











 From: Sergey Sharybin 
To: bf-blender developers  
Sent: Thursday, August 1, 2013 12:38 AM
Subject: Re: [Bf-committers] Clean convert text to mesh
 

HI,

Currently no actual plans to improve conversion operator itself, so if
someone volunteers to look into improvement -- be welcome :)

What you might want to try is to use Remesh modifier on a font object after
you've converted it to mesh. It'll give you much nicer topology.


On Wed, Jul 31, 2013 at 11:32 PM, Blender Attitude <
blenderattit...@gmail.com> wrote:

> Hi dream team,
>
> Is there a plan to improve the text to mesh conversion algorythm, to get a
> nice quad topology ? Or is there a simple method or add-on ?
>
> Thank you all.
>
> Best wishes,
> Romuald from Blender Attitude Magazine (fr)
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>



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

[Bf-committers] IRC Feature Chat to Support Addon Devs - Request for Guest Presenters

[W. Nelson]

The Los Angeles Blender Users Regional Working Group is organizing guest 
presenters for feature chats in our Freednode IRC chat room in an effort to 
build better awareness and support for addons and their developers.  Addons are 
a favorite topic at our users meetings.


If you are a developer of an addon and would like to schedule a time to be a 
guest presenter to this group, please email me back personally and not to the 
whole mailing list.  Better awareness in the group hopefully will boost the 
number of testers, increase feedback and contributions. 


Thanks in advance for putting a little oil on a squeaky wheel ; )

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

Re: [Bf-committers] Python API breakage - squeaking wheels

[W. Nelson]

Thanks for your informative response and your time on this matter...the support 
of 3rd party devs is always appreciated.


Tracking down "real evidence" issues is outstanding work and very tangible, 
something that makes most things happen.   Addressing perception is much more 
challenging but it can have a positive effect on a few things 
happening...especially since perception frequently becomes reality for some 
people.  


Maybe I can add some "real evidence" to the perception facet.  Here's my 
flailing attempt since I don't think it is just the perception of only a few 
squeaky wheels.  I may have ante up'd to 4 cents from 2 cents of opinion with 
this so I will show my hand from the shuffle as I see it...


Quoted from below:
...

'> Maybe some variation on these ideas could be a good balance of progress and 
mitigating fails with predictability.

It sounds a bit like you are under the impression that a dev wakes up
in the morning and says - "I'm going to break the API, now is as good
a days as any" :), but infact this isnt how it happens (mostly),'...

The center of gravity that I am inferring is an improved predictability balance 
as in an ecological system.  The emphasis is on balance as much as 
predictability.

  

My college PolySci teacher, Frank Navarret spoke on the idea of people's 
interaction as an ecological system.  Asserting that something based on 
balances and predictability would help the ecology thrive.


Kwai Chang Caine, the famed 70's philosopher also mentioned balance and 
predictability quite a bit.  ; )

So my center of gravity and assertion is on balance as much as predictability.  
The balance between the core values and goals of internal Blender work and the 
vantage point of 3rd party addon developers should be able to be improved with 
some simple adjustments to the current balancing point.  Something more 
proactive than reactive from this vantage point improves the return on 
investment of time.


I assume this year's SIGGraph will result in a few more prospective addon devs 
taking a look at Blender's platform ecology.  Time absorbing issues versus 
productive time, and what it will take for them to balance that, as has been 
stated, is one of the things they will consider.  Their perception of this 
balancing point being more in their favor from their vantage point will be 
important to attracting them and keeping current devs, IMHO.


So the core value of my assertion is shifting this balance point of awareness 
of upcoming changes more towards the 3rd party developers vantage point than it 
currently is.  Whether that means wiki page changes, the numbering or frequency 
changes I mentioned, or a specifically defined mailing list subject line that 
is IN ALL BOLD! ; ) or something more noticeable than the current balance point 
would work to improve the ecology, IMHO.  


The new wiki link added in March IIRC is an excellent example of this type of 
improvement.  Thanks to whoever added it.  From the root wiki page, two clicks 
away is "Blender Python API changes if you need to update your addon" and it 
contains the Restricted Context topic among others.  Yet, this is still a 
reactionary help, not a proactive help.  People are still getting surprised by 
this change as illustrated by the very question on it today in #blenderpython.  
So any type of proactive help that will facilitate devs not getting so easily 
caught in this reactionary trap should increase the predictability balance 
point of the ecology.


So if anything can be done to shift that balance point more towards that of the 
3rd party addon devs typical vantage point, I think it will improve the ecology 
of the Blender platform, give a better return on time investment and also 
attract more new devs, IMHO.

-=JTa=-


PS: okay, maybe 8 cents ;p




 From: Campbell Barton 
To: W. Nelson ; bf-blender developers 
 
Sent: Tuesday, May 28, 2013 3:01 PM
Subject: Re: [Bf-committers] Python API breakage - squeaking wheels
 

On Wed, May 29, 2013 at 4:06 AM, W. Nelson  wrote:
> Would some sort of scheduling updates to a specific date or version of 
> Blender help alleviate a lot of the finding out after the fact issues that 
> seem to be floating to the top of this conversation?

We have done this for planned API updates (deprecating game engine API
I think worked quite well some years back), with warnings giving line
number and letting dev know they used a deprecated features.

The reason I dont think this applies much to current projects we do is
that most breakages are not because we choose to update blenders API's
directly, but because we choose to improve blender, and API changes
are side effects of blenders internals working differently. This also
makes it hard/impossible to deprecate old behavior - its just blender
works differently and its very hard to predic

Re: [Bf-committers] Python API breakage - squeaking wheels

[W. Nelson]

Would some sort of scheduling updates to a specific date or version of Blender 
help alleviate a lot of the finding out after the fact issues that seem to be 
floating to the top of this conversation?

That would give time for looking at the upcoming change before it gets 
committed.  It could be proactively posted on a scheduled changes to py wiki 
page.  If there is not urgency to the change, then it would come at predictable 
or expected time frames.  This allows us 3rd party script developers to be 
proactive instead of reactive to changes.  Predictability even gives core 
development clear windows of opportunity.


Something as universal to Blender as Python/scripting maybe could only be 
updated with specific version numbers or reduced to once or twice a year.
Without throwing fuel on the versioning topic in general...maybe something like 
second digit changes and the 5 on third digit changes.  

EG:  py maintenance updates only on 2.70, 2.75, 2.80, 2.85...

Or date changes could be used.  Only twice per year at most maybe?  

EG: February's nearest release after February 1st and July's nearest release 
after July 1st  


Maybe some variation on these ideas could be a good balance of progress and 
mitigating fails with predictability.

RECAP:
Proposing ideas like-
  flipping the reactionary coin to proactive side

  scheduling updates to py for predictability

  changes only on dates or specific version numbers  

  wiki page with upcoming changes

JTa





 From: Domino Marama 
To: bf-blender developers  
Sent: Tuesday, May 28, 2013 9:17 AM
Subject: Re: [Bf-committers] Python API breakage - squeaking wheels
 

On 05/28/2013 02:31 PM, Campbell Barton wrote:
> >From your mail it looks like all changes you note were from bmesh
> upgrade (except build_revision)
>
> On Tue, May 28, 2013 at 9:36 PM, Domino Marama
>  wrote:
>> For my scripts the changes to UV handling caused the most problems..
>> Supporting multiple Blender versions from same script version results in
>> code like this:
>>
>>         u_points = []
>>         v_points = []
>>         mesh = obj.data
>>
>>         if svn <= 44243:
>>             for f in mesh.uv_textures[uv_name].data:
>>                 for u, v in f.uv:
>>                     u_points.append(u)
>>                     v_points.append(v)
>>         else:
>>             if svn > 45996:
>>                 uv_loops = mesh.uv_layers[uv_name].data
>>             else:
>>                 loopindex = mesh.uv_textures.keys().index(uv_name)
>>                 uv_loops = mesh.uv_layers[loopindex].data
>>             u_points = [v.uv.x for v in uv_loops]
>>             v_points = [v.uv.y for v in uv_loops]
>>
>> And other changes mean I have to do this to get the svn version :)
>>
>>     try:
>>         svn = bpy.app.build_revision.decode().split(':')[-1].rstrip('M')
>>     except:
>>         svn = bpy.app.build_revision.split(':')[-1].rstrip('M')
>>     svn = int(svn)
> This isn't totally reliable, some builds dont include buildinfo, Id
> suggest using blender version rather then checking revisions.
> Also moving to git - revisions will work differently too.
Yeah I just posted that because of the irony in my routine for handling
API changes being affected by them. I'm sure you see the additional
irony in pointing out that it is going to break again in the future :)

In the full code the svn = int(svn) line is in a try: except with a
fallback of estimating a svn number from the Blender version. I had to
do it this way as the Blender version isn't updated until release so
when API breakages occur I need to be able to target specific commits to
test against current builds
> It does but also confirms that BMesh was main offender (not sure you
> were aware of this regarding UVs?).
>
Yeah the majority of the the current switches in my code are bmesh
related. I couldn't do a full switch to bmesh without losing backward
compatibility, so it's mostly old API with just the UV handling from
bmesh on newer versions. Now there's enough old versions with bmesh I
can plan the full migration of the code to the new APIs.

Prior to that the last big script shakeup was the switch to python3.

I really posted as an example of a different way that script authors may
be working. Assuming a new Blender release with API changes means that
script authors will do new versions of their scripts makes work for
people who may not have scheduled for it. Having a few releases where
depreciated functions give warnings lets people schedule these things in
rather than having to make it their main priority. For those of us who
support older versions on same scripts, it also makes life a little
easier as we could fall into synch with the depreciation cycle rather
than having to work around things to keep compatibility.
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers
___

Re: [Bf-committers] Restoring 2.49 Feature: Groups in Add menu

[W. Nelson]

Yes, Add>Group is in addition to the "Add>Group Instance" item at the bottom of 
the Add menu and is intended to help manage linked libraries from the Add menu 
as seen in the reference video.  So currently the new Add>Group menu item 
brings up the same Group Instance menu code in addition to a library custom 
group place holder.


Ideally as discussed with others, the library custom groups from this menu can 
be organized and nested in composition workflow groups so to say and as in the 
reference video.  These are different groups than actual ctrl-g grouping.  
These groups, or the presentation of these custom organized groups can 
therefore be added very quickly while in a scene composition workflow.  This is 
distinctly different than grouping for modeling purposes therefor different in 
usage than
 the Group Instance menu item.

Yes again, I am looking at the Outliner and how an addon for that would work 
with the Add menu.  Other work is being done on the Outliner so I figured a 
streamlined Add menu modification with a simple panel to manage the custom 
nesting would be a good start and then eventually working it to play nice with 
the other goals for the Outliner.

This workflow is especially useful in scenes with lots of repetitive object 
group composition work or large scale scenes such as a landscape or a city 
greeble.  This type of workflow is frequently in production studio type 
settings.

Thanks for the excellent input,
JTa







 From: Brecht Van Lommel 
To: W. Nelson ; bf-blender developers 
 
Sent: Monday, May 27, 2013 3:54 AM
Subject: Re: [Bf-committers] Restoring 2.49 Feature: Groups in Add menu
 

Probably the place would be
release/scripts/startup/bl_operators/object.py or a new group.py.

However there is already a "Group Instance" item in the Add menu? So I
guess this is about the feature of adding groups from other libraries
directly form the menu. This was part of a bigger change that also
added library linking functionality to the outliner. Probably that
could be implemented as a python addon, but for best
 integration
that's really a bigger feature that needs to be implemented in C.

On Mon, May 27, 2013 at 5:13 AM, W. Nelson  wrote:
> Feedback is requested on restoring the 2.49 feature of Groups in the Add menu.
>
> It has been suggested that this feature can be implemented solely in bpy
> without altering the C code.  From a coding standpoint, does anyone have
>  any suggestions or devs have a preference on where to add the bpy
> code?  There was not a clear place in the existing scripts folder to put
>  this type of code.
>
> It seemed like all the items in the Add menu
> in scripts>startup>bl_ui>space_info.py were referencing
> existing operators in the C code.  So are there any suggestions on where
>  to add the
 code that will populate the menu from the groups and links
> operators?
>
> Thanks! JTa
>
> Thread link:
> http://www.blenderartists.org/forum/showthread.php?293583-Restoring-2-49-Feature-Groups-in-Add-menu
> ___
> 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] Restoring 2.49 Feature: Groups in Add menu

[W. Nelson]

Feedback is requested on restoring the 2.49 feature of Groups in the Add menu.

It has been suggested that this feature can be implemented solely in bpy 
without altering the C code.  From a coding standpoint, does anyone have
 any suggestions or devs have a preference on where to add the bpy 
code?  There was not a clear place in the existing scripts folder to put
 this type of code.

It seemed like all the items in the Add menu 
in scripts>startup>bl_ui>space_info.py were referencing 
existing operators in the C code.  So are there any suggestions on where
 to add the code that will populate the menu from the groups and links 
operators?

Thanks! JTa

Thread link:
http://www.blenderartists.org/forum/showthread.php?293583-Restoring-2-49-Feature-Groups-in-Add-menu
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Minimal Blender specs - 5 year old systems & OS

[W. Nelson]

A "graceful degradation" of Blender features on older/XP/Mac systems would be 
best IMO.  So a development strategy of a fault-tolerantBlender that does not 
crash or break on older systems would be to proactively disable features when 
incompatible with detectable hardware. This is a strategy that all could 
benefit from, especially longtime professionals with legacy niche 
hardware/software solutions.

For reference: http://en.wikipedia.org/wiki/Fault-tolerant_system

JTa
 



 From: Ton Roosendaal 
To: bf-blender developers  
Sent: Tuesday, January 29, 2013 5:35 AM
Subject: [Bf-committers] Minimal Blender specs - 5 year old systems & OS
 
Hi all,

I propose to update the minimal spec for hardware on the Blender site. This was 
getting very ancient now.

Old:
  1 GHZ Single Core CPU
  512 MB RAM
  1024 x 768 px Display with 16 bit color
  3 Button Mouse
  OpenGL Graphics Card with 64 MB RAM

New:
  32 bits, Dual Core CPU with at least 2 GHZ. 
  2 GB RAM
  24 bits 1280x800 display
  Mouse or trackpad
  OpenGL Graphics Card with 512 MB RAM

I really like it when Blender runs well on any OS and older computers. There's 
practical limits we need to cope with though:

- Support for old systems is impossible without any developer using it.
- There's demand for good support of modern hardware specs.

As rule-of-thumb we could define our minimal support level as "Decent quality 
new hardware and OS you would purchase 5 years ago for 1000 dollar".

If we can keep that work, systems with less specs might work, or not... but 
that would be in the unsupported category - unless a volunteer steps in to 
maintain it well.

It also means that we could drop Windows XP this year, Vista was released 5 
years ago.

For OSX we failed keep 10.5 work (october 2007). Also for PPC that's not 
possible anymore afaik. OSX 10.6 is quite recent (june 2009), but the current 
minimum we can support. If an OSX 10.5 user/developer steps in, feel welcome!

-Ton-


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

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

[Bf-committers] FW of email to Stirling on activities

[W. Nelson]

--- On Thu, 7/26/12, W. Nelson  wrote:

From: W. Nelson 
Subject: Extra Activities
To: stirling.go...@accenture.com
Date: Thursday, July 26, 2012, 2:35 PM

Hi Stirling,On the extra activities thoughts...I was thinking one option was 
Griffith Observatory, but the public transportation shuttle only runs on 
weekends to get up the hill.

Something interesting and relevant in NoHo district would be nice...great food, 
easy to get to on the metro rail Red Line.  I will look for places after 
conference hours.  We do have the Academy during business hours.
Hollywood and Vine area via the rail also was an idea, just walking the 
boulevard and checking out the stars and the Chinese Theater area.  Again, easy 
to get to on rail.
You should have gotten my Sony Pictures Imageworks for the booth group email.
Weather average is mid 80s, 10 day forecast is for 76 degrees for temperature.
Of course L.A. Live is
 right there...I was hoping for a couple options that had more wow or novelty 
value.
Here is the LACC attractions page link: 
http://www.lacclink.com/lacclink/attractions.aspx
L.A. Grand Park is partially open.  Saturday is the official grand opening of 
blocks one and two.  The rest comes later in the 
year.http://civicpark.lacounty.gov/http://civicpark.lacounty.gov/gettinghere.htmlIt's
 about 20 mins. away by rail.I am not sure if the fountain area is open yet, 
more of the park will open later in the year.  I am looking into it. 
Google Maps link for close by breweries.  If I know one thing about Dutch 
people, they like a good brew ;
 
)http://maps.google.com/maps?q=brewery+near+los+angeles+convention+center&hl=en&ll=34.04825,-118.238297&spn=0.072965,0.162392&sll=37.0625,-95.677068&sspn=35.684144,83.144531&hq=brewery&hnear=Los+Angeles+Convention+Center,+1201+S+Figueroa+St,+Los+Angeles,+California+90015&t=m&z=13
I have not been to any of these but Yelp is pretty good at reviews for brews.

USC has a couple 3D type graphics labs...we could probably get a tour there for 
a small group.http://gl.ict.usc.edu/
There is a second lab that is interesting and relevant, I will dig up the info.
So that's pretty much my ideas off of the top of my head.
Let me know what you think and have in
 mind.
JTA

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