Re: [Bf-committers] The Future of Blender Projects WAS meeting notes

[Mike Belanger]

I'm really happy about the last few years of Blender development.  But I sort 
of miss the built-like-a-tank stability of 2.4x series.  It'd be nice to focus 
on stability, bug-fixes for a while.  

I know that isn't as cool as an open-project though :P

Mike
On 2012-06-17, at 7:33 PM, Knapp wrote:

>> - Ton also invites people to think of post 2.6 projects. A special focus for 
>> 2.7x and 2.8x? Suggestion: in all of 2013, BF focus on Blender itself (no 
>> open movies!).
>> 
> 
> Could you enplane this a bit more?
> 
> IMO VERY HO
> I would like to see a project that pushes fog, clouds, sea, smoke and
> water effects and unifies them. Perhaps a classic Greek / Roman
> sailing adventure?
> Integration of Particles and Array mods could use some work.
> -- 
> Douglas E Knapp
> 
> Creative Commons Film Group, Helping people make open source movies
> with open source software!
> http://douglas.bespin.org/CommonsFilmGroup/phpBB3/index.php
> 
> Massage in Gelsenkirchen-Buer:
> http://douglas.bespin.org/tcm/ztab1.htm
> Please link to me and trade links with me!
> 
> Open Source Sci-Fi mmoRPG Game project.
> http://sf-journey-creations.wikispot.org/Front_Page
> http://code.google.com/p/perspectiveproject/
> ___
> 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] Wiki upgrade 2011

[Mike Belanger]

Like the new navigation header!  Its a lot easier to use.

Darkening the greys might make it look more like Blender.  But that's getting 
nitpicky.  
Good job! 

On 2011-09-20, at 1:13 AM, Thomas Dinges wrote:

> Hi,
> very very nice. This is so much better!!
> Thanks guys!
> 
> Best regards
> Thomas
> 
> Am 20.09.2011 02:50, schrieb mindrones:
>> Hi!
>> 
>> Finally, the Blender wiki has been upgraded, and has now:
>> 
>> * a new navigation system
>> * a new search engine
>> * a new skin, codenamed Naiad.
>> 
>> For more information about the facts and about the people involved,
>> please have a read at the project page at:
>> 
>> http://wiki.blender.org/index.php/Meta:Upgrades/2011
>> 
>> Some information about the new skin and a feature video are available at
>> http://wiki.blender.org/index.php/Meta:Skins/Naiad
>> 
>> If you are registered in the Blender Wiki and you can't see the new
>> skin, please check your preferences ("Appearance" tab) and choose the
>> skin called "Naiad".
>> 
>> Also, please report any wiki bug using the menu at the bottom on the
>> right. Any feedback is more than welcome! :)
>> 
>> It's been though, but we're proud :)
>> 
>> We hope that Blender wiki readers will find the wiki experience more
>> pleasant and enjoyable now!
>> 
>> 
>> Regards,
>> Luca
>> 
>> 
>> _
>> 
>> http://www.mindrones.com
>> ___
>> 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] Weekly developer meeting minutes, march 4 2012

[Mike Belanger]

This new feature looks like it might re-validate Hinge.  From what I understand 
from the wiki, a bone inheriting from not its immediate parent, but from its 
earlier parent *could* be useful.  Sure, like Nathan says, the behaviour can be 
done with trivial rig setups.  However, at the other end of the spectrum, you 
don't want the rigger doing too much stuff over and over.  In theory, the 
rigger *could* 'flatten' the entire hierarchy (minus the ik arms) and have 
basically no child bones, and define all relationships with constraints - but 
that'd be a lot of work. 

Interested in this feature. 

On 2012-03-04, at 7:53 PM, Nathan Vegdahl wrote:

>> - Bastien Montagne worked on new/better definition for "Hinge" bone:
>> http://wiki.blender.org/index.php/User:Mont29/Dev/Pose_Bone_RotScale_Parenting
> 
> In no way do I intend to disparage Bastien's work on this, but is
> improving the hinge feature even necessary?  In my mind, the hinge
> feature is deprecated.  I never use it.  You can accomplish the same
> behaviors (including the behaviors that this patch would enable, and
> beyond) with trivial rig setups.  This just feels like unnecessary UI
> clutter and code complexity to me.
> 
> I'm not saying we shouldn't have *any* shortcuts in Blender's rigging
> features.  I just think we should be selective.  Perhaps my
> selectivity threshold in this case isn't calibrated that same as
> other's...?
> 
> --Nathan
> 
> 
> On Sun, Mar 4, 2012 at 9:23 AM, Ton Roosendaal  wrote:
>> Hi all,
>> 
>> Here's the notes from today's meeting:
>> 
>> 1) current projects
>> 
>> - Today BCon2 starts, which means we should freeze the release targets now.
>>  http://wiki.blender.org/index.php/Dev:Doc/Projects
>> 
>> - Lukas Toenne finished group nodes patch, awaits review still, added to 
>> release targets.
>> 
>> - Cambell Barton fixed BMesh docs as agreed last week. Check his week report 
>> here:
>>  
>> http://wiki.blender.org/index.php/User:Ideasman42/WhatImWorkingOn#Week_80_.28Feb_27.29
>> 
>> - Lukas also is working on custom nodes: (similar to pynode, as first step 
>> towards plugins)
>> https://www.gitorious.org/~lukastoenne/blenderprojects/blender-lukastoenne/commits/custom_nodes
>> 
>> - Bastien Montagne worked on new/better definition for "Hinge" bone:
>> http://wiki.blender.org/index.php/User:Mont29/Dev/Pose_Bone_RotScale_Parenting
>> 
>> - Nicholas Bishop: sculpt masking is getting closer to finished, there are 
>> patches and documentation links here: 
>> http://nicholasbishop.net/wordpress/?p=44
>> 
>> - Sculpting partial-visibility patch has been reviewed and is ready.
>>  http://codereview.appspot.com/5695043/
>> 
>> 2) Google Summer of Code
>> 
>> - End of this week is deadline for submitting Blender Foundation as Google 
>> Summer of code organization. Tom Musgrove will be handling this, Ton 
>> Roosendaal will coordinate the day-to-day GSoC duties.
>> 
>> User wish list;
>> http://wiki.blender.org/index.php/Dev:Ref/GoogleSummerOfCode/2012/Wishlist
>> 
>> Official page for developers:
>> http://wiki.blender.org/index.php/Dev:Ref/GoogleSummerOfCode/2012/Ideas
>> 
>> - The target is to get the official ideas page to only mention ideas that:
>>  a) are commonly accepted projects, fitting in roadmap
>>  b) are being backed up by the module owners
>>  c) are likely to get a mentor who can also review code and help migrating 
>> code to trunk
>> 
>> Thanks,
>> 
>> -Ton-
>> 
>> 
>> Ton Roosendaal  Blender Foundation   t...@blender.orgwww.blender.org
>> Blender Institute   Entrepotdok 57A  1018AD Amsterdam   The Netherlands
>> 
>> ___
>> Bf-committers mailing list
>> Bf-committers@blender.org
>> http://lists.blender.org/mailman/listinfo/bf-committers
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers

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

Re: [Bf-committers] Reference counting, deleting data and fake users

[Mike Belanger]

The only thing I really miss from 2.49x was the 'noodles' mode in the Outliner. 
 Even though it had limited uses, it gave users an immediate impression as to 
what data blocks were in use, and what data blocks were not.

Then again, even that display mode didn't tell the user unused data blocks 
would be dropped upon re-opening the file.  But perhaps this could be used as 
some inspiration to this new 'asset manager' proposal.

Mike

--
mikebelanger.ca


On 2012-03-15, at 9:58 AM, Mango Jambo wrote:

> I suggested it could be part of Outliner, but as Nathan said,  a good
> data/asset management interface are totally welcome and way better!
> 
> Moraes Junior - aka mangojambo
> Animator & 3D Artist
> +55 43 88133399 
> 
> 
> On 15 March 2012 09:35, Mango Jambo  wrote:
> 
>> It could be part of Outliner, IMHO it is a perfect place to it. (But
>> Outliner needs a better attention to make it works properly)
>> Not only showing Fake User, but it could list any kind of data and its
>> users. A good example is images and movies. It would look something like
>> this:
>> *
>> *
>> *- Image A
>> - ./location/image.png
>>- Users
>>  - Texture 1
>> - Texture 4*
>> - Composite Node
>> - Strip 3 (from Video sequencer)
>> - Movie X (from an image sequence)
>> - Image Sequence B
>> * - Start - ./location/image0001.png*
>> * - End - ./location/image0100.png* (or something like that)
>> - Users
>>  ...
>> 
>> It would work with any data, including listing Fake Users. It makes easy
>> to reference count, deleting and other important feature: to re-link/fix
>> outside data, it includes image, image sequences, movies and Linked groups.
>> If we open a bronken linked blend file today, it simply lost it. I mean,
>> it happen to Linked Groups, but broken image keeps the address, even given
>> a pink wrong color to the object. IMHO it should be easy to re-link or even
>> swap the linked group, image address straight from Outliner.
>> 
>> I think these proposals would avoid stupid problems, may be mainly for
>> Mango Project. They will be dealing with images and movies all day. ;)
>> 
>> It was my 5 pence! Cheerios
>> 
>> Moraes Junior - aka mangojambo
>> Animator & 3D Artist
>> +55 43 88133399
>> 
>> 
>> 
>> On 15 March 2012 01:47, Nathan Vegdahl  wrote:
>> 
>>> Agreed.  As long as this is the paradigm, then this makes sense as a
>>> default.  However, I think it's not at all obvious that this is a good
>>> paradigm as Blender moves forward.  I remember this was a concern that
>>> William had in the Big Buck Bunny days as well.  Not sure if he's
>>> around to weigh in on that.
>>> 
>>> The main benefit of the current "garbage collection" style paradigm is
>>> that since data/asset management is quite anemic in Blender right now,
>>> this prevents tons of unused data from piling up.  During Sintel, for
>>> example, we would end up with files that had huge numbers of unused
>>> actions, and manually deleting them (even one-click per action) would
>>> have been a pain.
>>> 
>>> So perhaps as Blender gains a good data/asset management interface, we
>>> can start thinking about shifting away from automatic garbage
>>> collection, and towards a more manual-deletion paradigm...?
>>> 
>>> --Nathan
>>> 
>>> 
>>> On Wed, Mar 14, 2012 at 3:30 PM, Antony Riakiotakis 
>>> wrote:
 Hi Daniel, I agree that the new default makes sense in blender's data
 paradigm but I am questioning the paradigm not the default :)
 ___
 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] Improving Blender's keymap: a proposal

[Mike Belanger]

Inspiring.  In particular, this is what caught my eye:

On 2012-04-05, at 11:30 PM, Nathan Vegdahl wrote:

> (When I say "keymap" in this email, I mean to include the mouse as
> well.  Basically, key/mouse-map.)
> 
> == Principle 5 ==
> Consistency with other software.  Tautology: unless there are good
> reasons to not adhere to an existing ubiquitous UI standard, then
> there is no good reason to not adhere to an existing ubiquitous UI
> standard.
> 
> Lastly: process.  A keymap can be great in theory, but suck in
> practice.  So I would like to err on the side of "try things out"
> rather than "discussion".  Discussion is still important, of course!
> Especially for figuring out guidelines for the future.  But the
> discussion should, as much as possible, be based around seeing what
> works and what doesn't.  Let's treat keymaps as cheap, and not be shy
> about trying things out and throwing them away.
> 
Those things said - I've been "trying" LMB-select for a couple of years.  I 
have to say, I much prefer it, as LMB for select is ubiquitous in virtually all 
other pieces of software I use.

Dare I suggest you try this out as well Nathan?
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Improving Blender's keymap: a proposal

[Mike Belanger]

Inspiring.  In particular, this is what caught my eye:

On 2012-04-05, at 11:30 PM, Nathan Vegdahl wrote:

> (When I say "keymap" in this email, I mean to include the mouse as
> well.  Basically, key/mouse-map.)
> 
> == Principle 5 ==
> Consistency with other software.  Tautology: unless there are good
> reasons to not adhere to an existing ubiquitous UI standard, then
> there is no good reason to not adhere to an existing ubiquitous UI
> standard.
> 
> Lastly: process.  A keymap can be great in theory, but suck in
> practice.  So I would like to err on the side of "try things out"
> rather than "discussion".  Discussion is still important, of course!
> Especially for figuring out guidelines for the future.  But the
> discussion should, as much as possible, be based around seeing what
> works and what doesn't.  Let's treat keymaps as cheap, and not be shy
> about trying things out and throwing them away.
> 
Those things said - I've been "trying" LMB-select for a couple of years.  I 
have to say, I much prefer it, as LMB for select is ubiquitous in virtually all 
other pieces of software I use.

Dare I suggest you try this out as well Nathan?
On 2012-04-06, at 4:15 PM, Knapp wrote:

> "Mike Erwin;
> Instead of a one-size-fits-all keymap, why can't we have it grow or
> shrink based on what devices a person is actually using? Might be
> better as a keymap-gen script outside blender, to keep things simple.
> Input: "I have a US keyboard layout without numpad, an Inutos4M, and a
> SpaceMousePro" Output: a default keymap for exactly that hardware."
> 
> I LOVE THIS IDEA!!
> It makes total sense to have blender be hardware aware or at least keyboard.
> I would love to have a map for Dvorak that is well designed (fat
> chance right?) but Chinese might have very different ideas about what
> is good and also have the users to support it. I think if combined
> with good data about users and how they use blender, the job might not
> even be all that hard to do.
> 
> 
> BTW there is still a strangeness to how it tells what keyboard to use
> in KDE. It does not use the current keyboard but instead the one at
> the top of the list of possible keyboards in the keyboard picker
> setup. It took me a long time to figure this out but now all is good
> because I put the USA Keyboard on top. It used to have USA Keyboard in
> some places and Dvorak in others within Blender.
> 
> 
> -- 
> Douglas E Knapp
> 
> Creative Commons Film Group, Helping people make open source movies
> with open source software!
> http://douglas.bespin.org/CommonsFilmGroup/phpBB3/index.php
> 
> Massage in Gelsenkirchen-Buer:
> http://douglas.bespin.org/tcm/ztab1.htm
> Please link to me and trade links with me!
> 
> Open Source Sci-Fi mmoRPG Game project.
> http://sf-journey-creations.wikispot.org/Front_Page
> http://code.google.com/p/perspectiveproject/
> ___
> 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] Improving Blender's keymap: a proposal

[Mike Belanger]

The only mess-up I'm aware of is weight-painting mode.  Trying to select a new 
bone just paints.  But if you just hit Shift+LMB, you get a list of (hopefully) 
nicely labelled bones.  So it isn't that much of a mess-up.
> 
> I agree with this but I was about to try doing just this when someone
> on IRC warned me off of it saying it messes up to much in Blender. Was
> this just BS, or is there some truth to it?
> 
> 
> -- 
> Douglas E Knapp
> 
> Creative Commons Film Group, Helping people make open source movies
> with open source software!
> http://douglas.bespin.org/CommonsFilmGroup/phpBB3/index.php
> 
> Massage in Gelsenkirchen-Buer:
> http://douglas.bespin.org/tcm/ztab1.htm
> Please link to me and trade links with me!
> 
> Open Source Sci-Fi mmoRPG Game project.
> http://sf-journey-creations.wikispot.org/Front_Page
> http://code.google.com/p/perspectiveproject/
> ___
> 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] Meanless using of space in skin and simple deformmodifiers

[Mike Belanger]

Put google adwords on it - Blender foundation would make a lot of money!  Links 
to cheaper auto insurance and health care.  
On 2012-05-26, at 7:14 PM, Harley Acheson wrote:

> It's an advertising opportunity:
> 
> http://i.imgur.com/Ntdiy.png
> ___
> 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] Meanless using of space in skin and simple deformmodifiers

[Mike Belanger]

Try running this, this offers an improvement in layout of those modifiers:


…And yeah, Campbell honestly has better things to worry about, especially if a 
guy like me can fix this kind of layout stuff.

Mike
mikebelanger.ca
On 2012-05-26, at 7:03 PM, angelo miner wrote:

> True,
> Its just way to confusing,
> how dare you give me something so unpolished for free,
> the nerve...
> lol
> thankyou blender team(s)
> Ill take it however you want to give it,
> all it has to do is work(you know that s all)
> angjminer
> cryblend blender to cryengine3 exporter.
> - Original Message - 
> From: "Mikee Rice" 
> To: "bf-blender developers" 
> Sent: Saturday, May 26, 2012 2:21 PM
> Subject: [Bf-committers] Meanless using of space in skin and simple 
> deformmodifiers
> 
> 
>> I can understand that you have no UI team to handle all deficiencies in 
>> blender interface, but but.. c'mon!!
>> 
>> http://i.imgur.com/6mdGj.jpg
>> 
>> 
>> -- 
>> Regards
>> Mikee Rice
>> ___
> 
> ___
> 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] Meanless using of space in skin and simple deformmodifiers

[Mike Belanger]

> When someone makes bug report you ask him to fix it by his own?
> 
FYI, what you describe isn't really a bug, its more of an interface/aesthetic 
consideration.  Bugs are unintended behaviours such as a crash, or artifacts in 
a render.  This button layout is clearly intentional, despite its inefficient 
use of space.

Mike
mikebelanger.ca
On 2012-05-26, at 7:39 PM, Mikee Rice wrote:

> When someone makes bug report you ask him to fix it by his own?
> Just ignore kinda requests if dont want to do them.
> 
> 
> 
> 27.05.2012, 03:29, "Campbell Barton" :
>> Everyone know you can ...
>> - open the text space
>> - right click on the offending button,
>> - select 'Edit Source'
>> - change the python source of the UI and run the script to test changes.
>> 
>> Making these kinds of layout edits is really trivial if its just a
>> matter of basic button re-arranging.
>> 
>> On Sun, May 27, 2012 at 1:26 AM, Mike Belanger
>>  wrote:
>> 
>>>  Put google adwords on it - Blender foundation would make a lot of money!  
>>> Links to cheaper auto insurance and health care.
>>>  On 2012-05-26, at 7:14 PM, Harley Acheson wrote:
>>>>  It's an advertising opportunity:
>>>> 
>>>>  http://i.imgur.com/Ntdiy.png
>>>>  ___
>>>>  Bf-committers mailing list
>>>>  Bf-committers@blender.org
>>>>  http://lists.blender.org/mailman/listinfo/bf-committers
>>>  ___
>>>  Bf-committers mailing list
>>>  Bf-committers@blender.org
>>>  http://lists.blender.org/mailman/listinfo/bf-committers
>> --
>> - Campbell
>> ___
>> Bf-committers mailing list
>> Bf-committers@blender.org
>> http://lists.blender.org/mailman/listinfo/bf-committers
> 
> -- 
> Regards
> Mikee Rice
> ___
> 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] Meanless using of space in skin and simple deformmodifiers

[Mike Belanger]

Sorry I sent this script in a reply, but I guess someone replied during my 
reply, hehe.  Mikee, try and run this, see what you think.  

On 2012-05-26, at 9:14 PM, Mikee Rice wrote:

> This is not about me, or someone else, but about that third part of space in 
> skin modifier just lost. And what even worse, someone from developers made 
> this by intend.
> And my guess you will not find blender user who can tell that previous 
> interface of skin modifier was worser then current (symmetry axes part).
> 
> 
> Camblell is not UI module owner, he doesn't must to do something with it.
> 
> 
> 
> 
> 27.05.2012, 04:44, "Mike Belanger" :
>> Try running this, this offers an improvement in layout of those modifiers:
>> 
>> …And yeah, Campbell honestly has better things to worry about, especially if 
>> a guy like me can fix this kind of layout stuff.
>> 
>> Mike
>> mikebelanger.ca
>> On 2012-05-26, at 7:03 PM, angelo miner wrote:
>> 
>>>  True,
>>>  Its just way to confusing,
>>>  how dare you give me something so unpolished for free,
>>>  the nerve...
>>>  lol
>>>  thankyou blender team(s)
>>>  Ill take it however you want to give it,
>>>  all it has to do is work(you know that s all)
>>>  angjminer
>>>  cryblend blender to cryengine3 exporter.
>>>  - Original Message -
>>>  From: "Mikee Rice" 
>>>  To: "bf-blender developers" 
>>>  Sent: Saturday, May 26, 2012 2:21 PM
>>>  Subject: [Bf-committers] Meanless using of space in skin and simple
>>>  deformmodifiers
>>>>  I can understand that you have no UI team to handle all deficiencies in
>>>>  blender interface, but but.. c'mon!!
>>>> 
>>>>  http://i.imgur.com/6mdGj.jpg
>>>> 
>>>>  --
>>>>  Regards
>>>>  Mikee Rice
>>>>  ___
>>>  ___
>>>  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
> 
> -- 
> Regards
> Mikee Rice
> ___
> 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] alternate naming for search

[Mike Belanger]

Actually, this sounds like more of a job for the wiki!
The wiki already has tagging abilities.  Maybe the user could search for a Maya
command, and the wiki would return its Blender equivalent.  

Integrating this functionality into Blender itself seems a little excessive.  

Mike Belanger ( Mikahl )
www.watchmike.ca





On 2010-02-02, at 8:54 AM, Roger Wickes wrote:

> surely you mean Face (Connect)...
> 
> 
> Sent by Roger Wickes for intended recipient. If you are not the intended 
> recipient, please delete this message and contact Mr. Wickes immediately.
> 
> 
> 
> 
> 
> From: Tom M 
> To: bf-blender developers 
> Sent: Tue, February 2, 2010 4:45:12 AM
> Subject: [Bf-committers] alternate naming for search
> 
> Matt and Campbell,
> 
> I'd like to propose we allow alternative naming in the search.  So
> that users can add Maya equivalent names; 3DS Max equivalent names;
> etc.
> 
> So for instance a blender user would search for knife but a user from
> another package might search for Connect
> 
> So if a user enable an alternative naming or keymapping set they type
> Connect in search and find
> 
> Blender Name (Maya Name)
> Knife Cut (Connect)
> 
> I think this would make migration a lot easier for users of other packages.
> 
> LetterRip
> ___
> 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] Script Xtras (proposal)

[Mike Belanger]

Perhaps I'm too late in the discussion, but have existing Python distribution 
tools been considered?

I was cruising through the plone site today, and noticed this tool : 

http://peak.telecommunity.com/DevCenter/setuptools

Of course, I guess its probably as much work to integrate this with Blender, as 
writing a new one.  But in case
it isn't, there it is.


Mike Belanger ( Mikahl )
www.watchmike.ca





On 2010-02-14, at 5:42 PM, Campbell Barton wrote:

> added initial support for extensions (Add Gears script),
> most of the things that need doing now are not so hard..
> 
> - install extension operator (maybe remove extension operator too),
> can start simple and become more advanced: extract zipfiles, create
> extensions folder for the user.
> - extension categories, only one at the moment but sure that will change.
> - improve the UI, set out some kind of standard for formatting the
> descriptions, access methods etc.
> 
> all of these can be done in python only if someone wants to have a go.
> 
> would be nice to have word wrapping in the UI also but thats not so trivial.
> 
> On Sun, Feb 14, 2010 at 9:56 PM, Martin Poirier  wrote:
>> 
>> --- On Sun, 2/14/10, Campbell Barton  wrote:
>> 
>>> By installer I mean a script thats probably 50-150 lines of
>>> code, all
>>> it needs to do is copy files from some place on the users
>>> hard disk to
>>> a user script folder, It can do some nice things like "Your
>>> scripts
>>> dir doesnt exist, would you like it to be created?", as
>>> well as
>>> extracting files from a zip.
>>> Martin wrote something like this for 2.4x.
>> 
>> The keyconfig import operator for 2.5 works like that too, it's super simple.
>> 
>> Martin
>> 
>> 
>>  __
>> The new Internet Explorer® 8 - Faster, safer, easier.  Optimized for Yahoo!  
>> Get it Now for Free! at http://downloads.yahoo.com/ca/internetexplorer/
>> ___
>> Bf-committers mailing list
>> Bf-committers@blender.org
>> http://lists.blender.org/mailman/listinfo/bf-committers
>> 
> 
> 
> 
> -- 
> - Campbell
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers

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

Re: [Bf-committers] [Bf-blender-cvs] SVN commit: /data/svn/bf-blender [27124] trunk/blender/source/blender/ blenkernel/intern/fcurve.c: getting double frames problem, set the epsilon to 100th of a fra

[Mike Belanger]

I can't imagine using a strip scaled 10,000 x.   
I'll add it to the wiki as a warning.  But not everyone reads the wiki before 
diving in.  

I wonder why this can't just be restricted?  I.e. >
There's a maximum scale of say, 100x, or whatever's within practical ranges.

 
Mike Belanger ( Mikahl )
www.watchmike.ca





On 2010-02-25, at 3:36 AM, Nathan Vegdahl wrote:

> If people end up having real use-cases for scaling NLA strips so
> extremely, then we can always revisit this and try to fix it in a more
> sophisticated way.  But I have a hard time imagining real use-cases
> for that, so I suspect it will be a non-issue.
> 
> --Nathan
> 
> On Wed, Feb 24, 2010 at 9:25 PM, Joshua Leung  wrote:
>> Hi,
>> 
>> I thought I'd just mention here a possible issue that arises (or arised in
>> the past) with a coarse epsilon value like this here, in case anyone has to
>> track this down again at some point.
>> 
>> Basically, past a certain point, if NLA strips get scaled, and then the user
>> tries to add more keyframes, epsilon values like this simply won't suffice.
>> However, I strongly DO NOT RECOMMEND to let your NLA strips get into such a
>> state (i.e. you scale you NLA strips, then intend to go back to the action
>> and add more keyframes to the end (as opposed to simply tweaking the
>> existing ones)), since this is not the best way to do things. This comes
>> from seeing many files come and go in the bug tracker that were scaled to
>> ridiculous amounts (scale factor around 1, all keyframes stored in the
>> space of 1 frame or less in non-nla-scaled-time), though part of that was
>> also the result of the buggy design of the old NLA system.
>> 
>> In short, you (as in the animators) have been warned ;)
>> 
>> 
>> Regards,
>> Aligorith
>> 
>> On Thu, Feb 25, 2010 at 6:14 AM, Campbell Barton wrote:
>> 
>>> Revision: 27124
>>> 
>>> http://projects.blender.org/plugins/scmsvn/viewcvs.php?view=rev&root=bf-blender&revision=27124
>>> Author:   campbellbarton
>>> Date: 2010-02-24 18:14:16 +0100 (Wed, 24 Feb 2010)
>>> 
>>> Log Message:
>>> ---
>>> getting double frames problem, set the epsilon to 100th of a frame rather
>>> then 100,000th.
>>> 
>>> Modified Paths:
>>> --
>>>trunk/blender/source/blender/blenkernel/intern/fcurve.c
>>> 
>>> Modified: trunk/blender/source/blender/blenkernel/intern/fcurve.c
>>> ===
>>> --- trunk/blender/source/blender/blenkernel/intern/fcurve.c 2010-02-24
>>> 15:56:27 UTC (rev 27123)
>>> +++ trunk/blender/source/blender/blenkernel/intern/fcurve.c 2010-02-24
>>> 17:14:16 UTC (rev 27124)
>>> @@ -326,7 +326,7 @@
>>>  }
>>> 
>>>  /* threshold for binary-searching keyframes - threshold here should be
>>> good enough for now, but should become userpref */
>>> -#define BEZT_BINARYSEARCH_THRESH   0.1f
>>> +#define BEZT_BINARYSEARCH_THRESH   0.01f /* was 0.1, but giving
>>> errors */
>>> 
>>>  /* Binary search algorithm for finding where to insert BezTriple. (for use
>>> by insert_bezt_fcurve)
>>>  * Returns the index to insert at (data already at that index will be
>>> offset if replace is 0)
>>> 
>>> 
>>> ___
>>> Bf-blender-cvs mailing list
>>> bf-blender-...@blender.org
>>> http://lists.blender.org/mailman/listinfo/bf-blender-cvs
>>> 
>> ___
>> 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] Python sandbox

[Mike Belanger]

To me its not a question of how secure your pipeline is, but how quickly you
can 'bounce back' after a system failure, maliciously-motived or otherwise.
Yeah, you should have a firewall, passwords, admin rights etc.  But really,
the best insurance policy for studio assets is automated-backup.
If anything, this sandbox thing almost sounds like it could restrict
backups, or make them difficult/require consent every save.  Anything
discouraging/inhibiting backup is a far bigger threat, imho.

A disclaimer in front of AddOns works for me.


On Wed, Mar 17, 2010 at 11:28 PM, Matt Ebb  wrote:

>
> On 18/03/2010, at 15:09 , §ĥřïñïďĥï Ŗäö wrote:
>
> > Hi,
> > This is my very first mail to this list . I am not a developer but I
> > thought
> > i will put my 2 cents here since I felt that this discussion is a
> > waste of
> > time for many reasons .
> > 1: +100 for Brecth and his opinion (He is perfectly right !!)
> > 2: sanboxing blender will make it unusable  in large pipelines where
> > we need
> > blender to be integrated with other softwares and also need to do a
> > lot of
> > automatic IO (this includes IO to databases and in  renderfarm too
> > which can
> > be used for other than just rendering out images )
>
> +1 to this too. Even in 2.4* we had lots of trouble at our studio with
> scriptlinks, pydrivers, etc being off by default. We had problems (and
> wasted hours of work) when an artist took work home, installed a
> default blender from online and worked with that - getting the file
> into a state that caused lots of problems when the scripts were
> working as intended. This may have happened more than once too, can't
> remember. Similar trouble when doing some complicated things and
> sending files out to other studios who weren't familiar with Blender
> and this particular issue that really doesn't affect them.
>
> Many people who use blender don't download and open files from
> strangers on the web, and I would not like to see practical usability
> hindered just to try and give people who do the impression of security.
>
> cheers,
>
> Matt
>  ___
> Bf-committers mailing list
> Bf-committers@blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>



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

Re: [Bf-committers] Interested in GSoC project about motion capture data

[Mike Belanger]

What might make motion capture ( and baked keyframes in general ) more 
bearable, is some
kind of proportional editing for keyframes.  

I think this feature has been proposed before, but its
been left on the backburner, probably because of the recent animation refractor.

Mike Belanger ( Mikahl )
www.watchmike.ca





On 2010-03-20, at 11:11 AM, Roger Wickes wrote:

> Cool! Some thoughts for variations/features:
> - what makes repeating human motion "humanly" is the variation from one step 
> to another. so, like the gimp plugin that can fill in cutoouts, intelligence 
> in varying the cycle would be great.
> - what makes human motion "humanly" is the irregularity of the motion. 
> Eliminating keys that can not be interpolated, and which result in smooth 
> flow, makes it robotic. Pehaps a LOD (Level of detail) selector would be cool.
> 
> i address some of the library issues you speak of in a tut i wrote 
> at http://wiki.blender.org/index.php/Doc:Tutorials/Animation/Advanced/MoCap
> 
> 
> --Roger
> 
> 
> Check out my website at www.rogerwickes.com for a good deal on my book and 
> training course, as well as information about my latest activities. Use coupon
> Papasmurf for $15 off!
> 
> 
> 
> 
> 
> From: Yumei Wang 
> To: bf-committers@blender.org
> Sent: Sat, March 20, 2010 3:13:36 AM
> Subject: [Bf-committers] Interested in GSoC project about motion capture data
> 
> Hi all,
> 
> I am interested in the idea "Improve blender for dealing with motion
> capture data". I'm a graduate student doing research on motion
> synthesis based on motion capture data. I think this project is quite
> related to my research. I once do a small project of motion blending
> using BVH motion data.
> 
> Following is my understanding about the features mentioned in the idea:
> 
> Curve simplification for mo-cap data: we can use a smaller set of key
> frames to represent the original mo-cap data. Users can edit the
> motion with these key frames. So the problem here is how to sample
> these key frames to fit the original motion data.
> 
> Turn repetitive motion into loops: a simple example is generate
> walking motion of any length with one walking cycle. The problem here
> is to find the repetitive pattern of  motion from the mo-cap data.
> 
> Not sure if I get it correctly or not? Any suggestions or information
> is welcome.
> 
> Thanks
> 
> --
> Yumei Wang
> School of Computing,
> National University of Singapore.
> ___
> 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] Python sandbox

[Mike Belanger]

> , there needs to be a way of recuperating
> 
> ~Leif Andersen

Load your most recent backup files, assuming your entire project has been 
erased.  

Mike Belanger ( Mikahl )
www.watchmike.ca
> 
> 
> --
> So Much to Learn, Such Little Time
> http://leifandersen.net/2010/02/03/so-much-to-learn-such-little-time/
> 
> 
> On Mon, Mar 22, 2010 at 17:53, joe  wrote:
> 
>> Is any of this a problem in practice? What do other applications do?
>> Seems to me we might be making this too complicated.  Just have a
>> "warning: this .blend has scripts, which can be dangerous if you don't
>> trust the author; enable scripts?" popup on loading .blends.
>> 
>> For something as complex as a digital art production package, I think
>> it's ok to treat .blends as if they *are* .exe's, and warn users
>> appropriately.
>> 
>> Joe
>> 
>> On Fri, Mar 19, 2010 at 2:36 AM, Campbell Barton 
>> wrote:
>>> Hi Leif, probably repeating myself here but I don't understand the
>>> rationale for some of your suggestions.
>>> - Secure+Updated script installation doesn't help much since blend
>>> files themselves can include auto-executing drivers.
>>> - Separate python doesn't help with security, unless its separated in
>>> such a way blender can run without python at all. but in that case
>>> they also wont get a user interface so... don't think this helps
>>> either unless we move the UI back into C.
>>> 
>>> Agree patching python would be a pain.
>>> 
>>> This is an interesting sandbox project but I dont think blender can
>>> use since we would need to switch trusted/untrused context a lot but
>>> since the topic is raised worth mentioning.
>>> 
>>> http://github.com/haypo/pysandbox/tree/master/sandbox/
>>> It works by writing into CPythons memory with ctypes to disable
>>> certain aspects of python.
>>> 
>>> 
>>> On Fri, Mar 19, 2010 at 3:55 AM, Leif Andersen
>>>  wrote:
>>>> As sad as it is, it seams like your axiom Jonathan, has been true.
>>>> Although, that is based only on empirical evidence, not an actual
>> rigorous
>>>> proof.  (i.e., I would die happy if I ever found a way to make a
>> computer be
>>>> secure, and work seamlessly).  Some examples of this are the previous
>> emails
>>>> in this thread, about people who have had trouble with a locked down
>> python.
>>>> 
>>>> I still think though (like the first email in this thread), that it
>> would be
>>>> better to keep python separate, but still make sure that it has been
>>>> included on the system.  We could also have a script that checks to make
>>>> sure it is still the latest version, in an attempt to keep it secure.
>> If we
>>>> include python directly into blender, that would add a severe amount of
>>>> overhead to ensure that blender keeps up with the latest build of
>> python,
>>>> and even worse, if we customize it with patches, we would have to
>> constantly
>>>> repatch it, work that would be better spend fixing bugs/other flaws
>> unique
>>>> to blender/adding new features.Than again, on the other hand, we may
>> have to
>>>> still do the same thing if we try to customize a separate python build.
>>>> 
>>>> Than again, all of this is at a very hand wavy level.  And my arguments
>> seem
>>>> to me consist of me waving my arms, and claiming I can fly. :)
>>>> 
>>>> Anyway, thank you for the support thus far everyone.
>>>> 
>>>> ~Leif Andersen
>>>> 
>>>> --
>>>> So Much to Learn, Such Little Time
>>>> http://leifandersen.net/2010/02/03/so-much-to-learn-such-little-time/
>>>> 
>>>> 
>>>> On Thu, Mar 18, 2010 at 12:43, Mike Belanger <
>> mikejamesbelan...@gmail.com>wrote:
>>>> 
>>>>> To me its not a question of how secure your pipeline is, but how
>> quickly
>>>>> you
>>>>> can 'bounce back' after a system failure, maliciously-motived or
>> otherwise.
>>>>> Yeah, you should have a firewall, passwords, admin rights etc.  But
>> really,
>>>>> the best insurance policy for studio assets is automated-backup.
>>>>> If anything, this sandbox thing almost sounds like it could restrict
>>>>> backups, or make them difficult/require c

Re: [Bf-committers] Blender security paranoia

[Mike Belanger]

Couldn't agree more with both of you.  Anyone in this day in age uses
regular backups, not just when they THINK their might be a system failure.
If you have work you care about, but you don't backup on a regular basis,
you are a douche.  Its so easy to do, and you should do it even if Blender
developes some new-fangled python-sandboxing.

I think the bigger danger is if these superflous security featurse are
actually attempted, and more critical things ( ie general stability) are
overlooked or neglected.

On Tue, Mar 23, 2010 at 9:12 AM, §ĥřïñïďĥï Ŗäö wrote:

>  On Tue, Mar 23, 2010 at 7:30 PM, Raul Fernandez Hernandez <
> ra...@info.upr.edu.cu> wrote:
>
> > Hi all :)
> >
> > WARNING: this email is not targeted to anybody in particular, is just my
> > opinion and I like to learn from my mistakes :)
> >
> > I think is good to think in all threat possibilities that could arise in
> > the future but I really don't understand all the paranoia that has being
> > awaken toward Blender.
> >  It makes more harm than good because it introduce the fear in the
> > Blender ecuation , the user that will make .blend content that is worth
> > downloading and sharing will not burn his hard earned reputation in
> > making scripts for stealing user information or deleting user files.
> >  C'mon we are 3D guys working hard for making  well, you guess, 3D ,
> > is very different from people killing time writing trash on Word or
> > Power-points and also from a malicious developer point of view the user
> > share of Blender (and really from any 3D app) is not worth it.
> >  In all the blender history mention a case when something like that have
> > happened before.
> >  And while that is not a strong argument that prevent such situations
> from
> > happening in the future I think such level of security is an SO duty, not
> > an app task.
> >  Blender could not live without python and making mechanisms for avoid
> > automatic and hiding script running is OK, but I think we should not
> > take that further.
> >
> >Regards farsthary
> >
> >
> >
> >
> I agree with you anytime..:) . Instead of concentrating on such "security "
> issues which is not worth the effort because IF a person intends to put
> some
> malicious code HE WILL put it at any cost even with high security settings
> .. :( ... I  would rather suggest to get the API to a stable condition and
> make it more straight forward than thinking about security. As i told in my
> earlier mail that making a software more secure makes it highly unusable in
> a production environment which needs a lot of automation .. just my 2 cents
> . :)
>
> regards
> shrinidhi
>
>
>
> --
> Ęvęņ ģóđ fąįļş ŧŏ ųŋđęŗşţąņđ å ĥųmąņ ųņţĭļ ĥĭş đęąţĥ
>
> http://www.linkedin.com/in/shrinidhi666
> http://www.shrinidhi666.wordpress.com
> http://www.imdb.com/name/nm3025616
>  ___
> Bf-committers mailing list
> Bf-committers@blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>



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

Re: [Bf-committers] FFMPEG UI is bad

[Mike Belanger]

Absolutely +1 from me.  FFMPEG is currently a minefield for users, even
developers.

Although, I must warn different encoding settings work on different
platforms.  So the presets would
best be OS-specific.

On Mon, May 31, 2010 at 6:50 AM, Thomas Dinges  wrote:

> +1 for this :)
> This way we may also reduce the amount of ffmpeg bug reports. :P
>
> Am 31.05.2010 13:47, schrieb Joshua Leung:
> > Yep.
> >
> > On Mon, May 31, 2010 at 11:44 PM, Thomas Dinges  wrote:
> >
> >> So you mean, put all possible combinations that work and we support,
> >> into the list and get rid of the manual settings for codec/format?
> >>
> >> Am 31.05.2010 13:41, schrieb Joshua Leung:
> >>
> >>> +1 to this suggestion.
> >>>
> >>> While technically it might be nice to be able to control these things,
> >>> the fact with FFMPEG is that it is only usable with a very select few
> >>> combinations, and even then only under strict conditions (any other
> >>> combinations either crash immediately, crash on the last frame of the
> >>> render, or give useless junk that few players can make sense of
> >>> correctly). Having a double-step to choose the output format (FFMPEG
> >>> ->Encoding) is really quite clumsy, and as Gustav mentioned, an
> >>> "FFMPEG" option will be pointless and confusing for many users.
> >>>
> >>> 2010/5/31 Gustav Göransson:
> >>>
> >>>
>  It's confusing indeed. However most uses don't have a clue what FFMPEG
>  is, which makes it confusing to only have FFMPEG. An alternative might
>  be to merge the encoding and the output panel and have all file format
>  in the same list...
> 
>  /gustav
> 
> 
> >>> ___
> >>> 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
>



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

Re: [Bf-committers] Bind Camera to markers

[Mike Belanger]

I honestly don't know either reevuedelibre.

I just keyframe the camera, I don't see the point in learning a different tool 
just for camera moves.
Also, you can use the NLA to keep track of shots : http://www.vimeo.com/5860167

On 2010-06-10, at 1:41 AM, revuedelibre . wrote:

> Hello,
> 
> I recently discover that way to change active camera during render is to use
> "Bind camera to markers".
> Why use markers ? Why not use Keyframe/drivers to change Scene.camera (
> would be more homogeneous to other anim settings ) ?
> 
> Using markers, after binding, how to retrieve witch camera is linked to
> witch marker ? I can't find any information about that.
> 
> Regards,
> 
> Ju+
> ___
> 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] Bind Camera to markers

[Mike Belanger]

What kind of usage case scenario would that fill?  The current animation system
can animate text, do camera moves, and keyframe meshes.  
I'm unsure what you mean by uses in rigging.

Markers are kind of neat, but IMO they're meant to remain simple.

On 2010-06-10, at 12:08 PM, Vilem Novak wrote:

> If I remember it right, the commit was in the svn mailing list commented as a 
> temporary hack.
> I would love some animation support for such properties, which are in the ui 
> represented 
> as the name of the datablock/string, since it could also be used not only to 
> replace scene camera, 
> but also replace meshes in some cases or to animate text. I can also imagine 
> it could be used 
> for some rigging cases.
> Not sure if this could be done through the animation system?
> 
>> ---- Původní zpráva 
>> Od: Mike Belanger 
>> Předmět: Re: [Bf-committers] Bind Camera to markers
>> Datum: 10.6.2010 15:01:14
>> 
>> I honestly don't know either reevuedelibre.
>> 
>> I just keyframe the camera, I don't see the point in learning a different 
>> tool
>> just for camera moves.
>> Also, you can use the NLA to keep track of shots : 
>> http://www.vimeo.com/5860167
>> 
>> On 2010-06-10, at 1:41 AM, revuedelibre . wrote:
>> 
>>> Hello,
>>> 
>>> I recently discover that way to change active camera during render is to use
>>> "Bind camera to markers".
>>> Why use markers ? Why not use Keyframe/drivers to change Scene.camera (
>>> would be more homogeneous to other anim settings ) ?
>>> 
>>> Using markers, after binding, how to retrieve witch camera is linked to
>>> witch marker ? I can't find any information about that.
>>> 
>>> Regards,
>>> 
>>> Ju+
>>> ___
>>> 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] Bind Camera to markers

[Mike Belanger]

Ok, so if I understand your proposal correctly, there should be a way to 'bind 
some kind of operator' to a Marker. 
Rather than having a python hack ( the current system ) there should be a 
hard-coded, more extensible system for markers.

On 2010-06-11, at 2:36 AM, Vilem Novak wrote:

> Ok, this is a bit of a misunderstanding:
> Besides the original cameras topic
> we are talking about replacing some properties, so e.g. replacing a mesh, 
> which would be a typical case if you e.g. simulate clay-based animation 
> with replacement heads/mouths, since in such case
> you don't always want to do things from 1 shape and animate it as shapes.
> Another case is something I use quite often nowadays - conversion of 
> greasepencil
> animation to real curves so it can be rendered.
> By 'animating text' I meant not animating of the object, but of the 'content' 
> of such object,
> thus e.g. doing animation of somebody typing, or else. 
> These things can allready be done, when you animate object layers or hiding. 
> or if you make a
> set of object misplaced by e.g. 1000units, parent them all to an empty and 
> then offset this empty.
> I used both of these methods. Hiding/Layers don't work currently well with 
> the current system, 
> since what is hidden, is also hidden in the dopesheet, so you can't actually 
> move the keys
> (everything has to be scripted).
> The 'misplacement' method is not optimal because of it makes scene bounds 
> huge, so you can't use the
> home key anymore, and probably during rendering with raytracing it can cause 
> some serious performance
> hit.
> When we go back to the 'camera switching' topic, besides that the method is 
> probably used by durian team,
> (which is a strong argument why something is userfull), it's a way close to 
> classical film making - you don't run
> around with 1 camera, you shoot with several cameras and you make cuts.So, 
> you can do it another way too,
> but if properly implemented, this is more intuitive. If I remember right, 
> Motion builder has a tool called camera switcher as
> a separate thing, with it's own timeline.
> Hope this explains what I actually meant in the previous e-mail.
> Cheers
> Vilem
> 
> 
> 
>>  Původní zpráva 
>> Od: Mike Belanger 
>> Předmět: Re: [Bf-committers] Bind Camera to markers
>> Datum: 11.6.2010 02:31:12
>> 
>> What kind of usage case scenario would that fill?  The current animation 
>> system
>> can animate text, do camera moves, and keyframe meshes.  
>> I'm unsure what you mean by uses in rigging.
>> 
>> Markers are kind of neat, but IMO they're meant to remain simple.
>> 
>> On 2010-06-10, at 12:08 PM, Vilem Novak wrote:
>> 
>>> If I remember it right, the commit was in the svn mailing list commented as 
>>> a
>> temporary hack.
>>> I would love some animation support for such properties, which are in the ui
>> represented 
>>> as the name of the datablock/string, since it could also be used not only to
>> replace scene camera, 
>>> but also replace meshes in some cases or to animate text. I can also imagine
>> it could be used 
>>> for some rigging cases.
>>> Not sure if this could be done through the animation system?
>>> 
>>>>  Původní zpráva 
>>>> Od: Mike Belanger 
>>>> Předmět: Re: [Bf-committers] Bind Camera to markers
>>>> Datum: 10.6.2010 15:01:14
>>>> 
>>>> I honestly don't know either reevuedelibre.
>>>> 
>>>> I just keyframe the camera, I don't see the point in learning a different
>> tool
>>>> just for camera moves.
>>>> Also, you can use the NLA to keep track of shots :
>> http://www.vimeo.com/5860167
>>>> 
>>>> On 2010-06-10, at 1:41 AM, revuedelibre . wrote:
>>>> 
>>>>> Hello,
>>>>> 
>>>>> I recently discover that way to change active camera during render is to
>> use
>>>>> "Bind camera to markers".
>>>>> Why use markers ? Why not use Keyframe/drivers to change Scene.camera (
>>>>> would be more homogeneous to other anim settings ) ?
>>>>> 
>>>>> Using markers, after binding, how to retrieve witch camera is linked to
>>>>> witch marker ? I can't find any information about that.
>>>>> 
>>>

Re: [Bf-committers] Component Group Proposal

[Mike Belanger]

In current ( 2.49b) to make a distinction between modifier and rigging vert
groups, I just prefix names with RIG or VERT.  Does this help?

On Tue, Jun 22, 2010 at 2:03 PM, Daniel Salazar - 3Developer.com <
zan...@gmail.com> wrote:

> Also I want to mention this would help on the tasks of deleting all vgroups
> used on an armature without deleting the ones used on hair or similar
> stuff.
> Currently I use a simple py script with an exclusion list for this
> repetitive task. Would be nice if we could do this kind of operations for
> the relevant set only
>
> Daniel Salazar
> www.3developer.com
>
>
> On Tue, Jun 22, 2010 at 12:58 PM, Daniel Salazar - 3Developer.com <
> zan...@gmail.com> wrote:
>
> > Yah I mentioned this is a visual separation I'm proposing
> > and completely optional. A group belonging to one set or another woudn't
> > have any effect on the group's usage all over blender.
> >
> > Daniel Salazar
> >
> >
> >
> > On Tue, Jun 22, 2010 at 8:49 AM, Brandon Phoenix  >wrote:
> >
> >> Hey Daniel,
> >> Just to clarify: "Maybe you can expand this concept to include Group
> >> Sets? This would be bags of data groups that could
> >> classifyvertes/edges/groups for their usage". Here you're essentially
> >> suggesting groups of groups? So that all of the vert groups used in
> rigging
> >> are kept separate from, say, the groups used to emit hair etc.?
> >> I'm not sure I agree with this though: "example the set of vertex
> >> groups that an specific armature modifier uses should not be visually
> >> mixed with the ones that are just used to feed another modifier". I can
> >> think of cases that it may be beneficial to use the same edge group for
> >> multiple things. For example, it is often beneficial to seam UVs along
> hard
> >> normal edges, so the sharp marked edge group could just be passed into
> the
> >> UV set, if that makes sense. Perhaps if it was at the user's discretion
> to
> >> separate the group sets. I'll need to speak to matt_e about a UI
> >> implementation of this, because I'm not sure I've seen something like it
> >> (outside of the outliner). I like the idea though, I'll see what I can
> draw
> >> up.
> >> Thanks,
> >> -Brandon Phoenix
> >> (I realized in my initial e-mail, I signed my name "Brandon Phoenix?".
> >> Oops.)
> >> ---Date: Sun, 20
> >> Jun 2010 21:11:04 -0600
> >> From: "Daniel Salazar - 3Developer.com" 
> >> Subject: Re: [Bf-committers] Component Group Proposal
> >> To: bf-blender developers 
> >> Message-ID:
> >> 
> >> Content-Type: text/plain; charset=UTF-8
> >>
> >> This is something that has been a real need since the introduction of
> >> modifiers. Maybe you can expand this concept to include Group Sets?
> >> This would be bags of data groups that could classify
> >> vertes/edges/groups for their usage, example the set of vertex groups
> >> that an specific armature modifier uses should not be visually mixed
> >> with the ones that are just used to feed another modifier
> >>
> >> cheers
> >>
> >> Daniel Salazar
> >> www.3developer.com
> >>
> >>
> >>
> >> On Sun, Jun 20, 2010 at 9:05 PM, Brandon Phoenix 
> >> wrote:
> >> > This proposal is aimed at expanding the functionality of vertex groups
> >> and unifying the UI by adding both vertex and face grouping. This may be
> a
> >> bit late for the 2.6 release, but should probably be considered for the
> >> future. I would like to solicit as much discussion on the topic as
> possible.
> >> The document is here:
> >> >
> >> > http://dim.blenderge.com/Documents/componentGroupProposal.pdf
> >> >
> >> > Thank you,
> >> >
> >> > -Brandon Phoenix
> >> >
> >> >
> >> >
> >> >
> >> >
> >> > ___
> >> > 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
>



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

Re: [Bf-committers] Component Group Proposal

[Mike Belanger]

True - RIG in front of all bone names is obtrusive.

+1 from me for a visual distinction.


On Tue, Jun 22, 2010 at 2:45 PM, Daniel Salazar - 3Developer.com <
zan...@gmail.com> wrote:

> That proves my point, there is a need for a distinction, and its not that
> simple. You would need to also name all your bones starting with RIG
> because
> vgroups are linked to bones by the names
>
> Daniel Salazar
> www.3developer.com
>
>
> On Tue, Jun 22, 2010 at 1:42 PM, Mike Belanger
> wrote:
>
> > In current ( 2.49b) to make a distinction between modifier and rigging
> vert
> > groups, I just prefix names with RIG or VERT.  Does this help?
> >
> > On Tue, Jun 22, 2010 at 2:03 PM, Daniel Salazar - 3Developer.com <
> > zan...@gmail.com> wrote:
> >
> > > Also I want to mention this would help on the tasks of deleting all
> > vgroups
> > > used on an armature without deleting the ones used on hair or similar
> > > stuff.
> > > Currently I use a simple py script with an exclusion list for this
> > > repetitive task. Would be nice if we could do this kind of operations
> for
> > > the relevant set only
> > >
> > > Daniel Salazar
> > > www.3developer.com
> > >
> > >
> > > On Tue, Jun 22, 2010 at 12:58 PM, Daniel Salazar - 3Developer.com <
> > > zan...@gmail.com> wrote:
> > >
> > > > Yah I mentioned this is a visual separation I'm proposing
> > > > and completely optional. A group belonging to one set or another
> > woudn't
> > > > have any effect on the group's usage all over blender.
> > > >
> > > > Daniel Salazar
> > > >
> > > >
> > > >
> > > > On Tue, Jun 22, 2010 at 8:49 AM, Brandon Phoenix  > > >wrote:
> > > >
> > > >> Hey Daniel,
> > > >> Just to clarify: "Maybe you can expand this concept to include Group
> > > >> Sets? This would be bags of data groups that could
> > > >> classifyvertes/edges/groups for their usage". Here you're
> essentially
> > > >> suggesting groups of groups? So that all of the vert groups used in
> > > rigging
> > > >> are kept separate from, say, the groups used to emit hair etc.?
> > > >> I'm not sure I agree with this though: "example the set of vertex
> > > >> groups that an specific armature modifier uses should not be
> visually
> > > >> mixed with the ones that are just used to feed another modifier". I
> > can
> > > >> think of cases that it may be beneficial to use the same edge group
> > for
> > > >> multiple things. For example, it is often beneficial to seam UVs
> along
> > > hard
> > > >> normal edges, so the sharp marked edge group could just be passed
> into
> > > the
> > > >> UV set, if that makes sense. Perhaps if it was at the user's
> > discretion
> > > to
> > > >> separate the group sets. I'll need to speak to matt_e about a UI
> > > >> implementation of this, because I'm not sure I've seen something
> like
> > it
> > > >> (outside of the outliner). I like the idea though, I'll see what I
> can
> > > draw
> > > >> up.
> > > >> Thanks,
> > > >> -Brandon Phoenix
> > > >> (I realized in my initial e-mail, I signed my name "Brandon
> Phoenix?".
> > > >> Oops.)
> > > >> ---Date:
> Sun,
> > 20
> > > >> Jun 2010 21:11:04 -0600
> > > >> From: "Daniel Salazar - 3Developer.com" 
> > > >> Subject: Re: [Bf-committers] Component Group Proposal
> > > >> To: bf-blender developers 
> > > >> Message-ID:
> > > >> 
> > > >> Content-Type: text/plain; charset=UTF-8
> > > >>
> > > >> This is something that has been a real need since the introduction
> of
> > > >> modifiers. Maybe you can expand this concept to include Group Sets?
> > > >> This would be bags of data groups that could classify
> > > >> vertes/edges/groups for their usage, example the set of vertex
> groups
> > > >> that an specific armature modifier uses should not be visually mixed
> > > >> with the ones that are just used to feed another modifier
> > > >>
> > > 

Re: [Bf-committers] Proposal to Remove Features

[Mike Belanger]

I pretty much agree with the Removal List.

As far as the Controversial list goes, I think that "Blend Sky" thing could
easily be replaced with compositor stuff.  I find 'horizon' and 'zenith' far
too esoteric, compared to just using a gradient node in the compositor.
 That's just my artist-brain though.

Although I like the idea of animating object layers, I find the current
system confusing, so it might be better to just remove it.

On Thu, Jul 8, 2010 at 12:30 PM, Brecht Van Lommel wrote:

> Hi,
>
> Here's a proposal to remove a number of features before 2.6. I've been
> gathering items on this list for the last few months as I came across
> them. If there is enough agreement I can make the changes quickly. If
> you agree or disagree with items on the list, please read the
> explanation at the top and comment on the wiki page.
>
> http://wiki.blender.org/index.php/Dev:2.5/RemoveFeaturesProposal
>
> Thanks,
> Brecht.
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>



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

Re: [Bf-committers] Proposal to Remove Features

[Mike Belanger]

Yeah the ghost button in the Action editor can toggle visibility now.
 Thanks Aligorith.

But as far as replacing layer keys, I don't think restricting individual
objects' visibilities are as efficient.

However, we can now toggle the visibility of groups, it would be nice if we
could keyframe them as well ( I can't seem to do this on trunk r30112 ).  If
I could keyframe them, I could probably live without
layer keys.


On Thu, Jul 8, 2010 at 7:17 PM, Joshua Leung  wrote:

> 2010/7/9 Vilem Novak 
>
> >
> > Animateable object layers:
> > first to mention, this doesn't work in 2.5, and I miss that feature a
> lot.
> > as allready mentioned, it actually saves performance when moving objects
> > between layers instead of animating their hiding.
> > Also, currently animating hiding of objects with the restrict prop is a
> > pita, since animation editors don't show hidden objects, so moving the
> keys
> > for these is nearly impossible.
>
> These "bugs" were fixed earlier this week. Monday to be precise.
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>



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

Re: [Bf-committers] Blender 2.5x beta status

[Mike Belanger]

Have to agree with William and Benjamin.  The mounting/unmounting disk-image
thing is probably from OSX's Unix background, not designed for people at
all.

On Tue, Jul 13, 2010 at 8:43 PM, Benjamin Tolputt  wrote:

> William Reynish wrote:
> > I think zip is much simpler to understand and manage for the user, it's
> also faster too (no need to mount, drag-to-apps, unmount).
> >
>
> >From a non-technical standpoint (my wife), installing from a zip is not
> an issue. Simply double click the zip in the downloads dir and drag to
> the Applications shortcut in the taskbar. She's done this so many times
> now it is second nature and she is not technically trained in any way,
> shape, or form.
>
> --
> Regards,
>
> Benjamin Tolputt
> Analyst Programmer
>
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>



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

Re: [Bf-committers] Blender 2.5x beta status

[Mike Belanger]

'If you are a real mac user, you use .dmg images very often,
since it's the way most apps do it, so why should this be confusing?'

If your ANY kind of real computer user, you've probably decompressed a .zip
file before.

On another note, PackageMaker.app *may* provide an easier installation, as
it chooses the directory for the user,
and it might be possible for it to check the environment, ie what version of
python, for the user.  However, its an extra step for builders, and takes
quite a while to package blender on my machine.

2010/7/14 Luke Frisken 

> There's really not much point trying to use something as complicated
> in computer usage terms as blender if one can't cope with the
> installation how it is now.
>
> On 7/14/10, Vilem Novak  wrote:
> > If you are a real mac user, you use .dmg images very often,
> > since it's the way most apps do it, so why should this be confusing?
> > I guess I would rather be confused by a zip on mac.
> > as said, it takes the same amount of clicks.
> > So, my voice is for .dmg
> >
> >>  Původní zpráva 
> >> Od:  
> >> Předmět: Re: [Bf-committers] Blender 2.5x beta status
> >> Datum: 14.7.2010 10:42:41
> >> 
> >> +1 for an uncomplicated .zip approach!
> >>
> >> jms
> >> ___
> >> 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
> >
>
> --
> Sent from my mobile device
>
> >From Luke
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>



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

Re: [Bf-committers] Proposal: renaming Head/Tail into Root/Tip in armatures

[Mike Belanger]

That actually makes sense.  I few times I've been confused over Head/Tail.

And hair, grass have Roots > Tips, so I think the analogy makes sense.
 Maybe Start > End too.

On Sat, Jul 17, 2010 at 9:04 AM, David Hutto  wrote:

> On Sat, Jul 17, 2010 at 9:59 AM, mindrones  wrote:
> > Hi,
> >
> > since new documentation for rigging, constraints, and animation is going
> > to be put in the manual, sometimes ago in #blenderwiki we were talking
> > about rigging naming conventions (how to call bone ends) and after some
> > debate we ended up asking opinions in #blendercoders too.
> >
> > It seemed that all the present people agreed (including Ton) that it
> > makes more sense that a bone has a "root" and a "tip" rather than a
> > "head" and a "tail", because chains can go upward (spine) or downward
> > (legs) hence the concept of the tail being higher that the head seemed
> > weird.
> >
> > The Blender Summer of Documentation tutorials use "root" and "tip" too,
> > for example, see
> >
> http://wiki.blender.org/index.php/Doc:Tutorials/Animation/Armatures/BSoD/The_Armature_Object#Armature_Edit_Mode
> >
> > The new docs would use root and tip too: see the upcoming
> >
> http://wiki.blender.org/index.php/Doc_talk:Manual/Rigging/Armatures/Bones#Bones
> >
> > What's the general idea about change from "Head" and "Tail" to "Root"
> > and "Tip" in the UI and in the API?
> well why not root to leaf, or root to foliage/flora. As long as the
> analogy applies, then use it. to push urther, why parent> child, when
> you could use master>slave?
>
> >
> > Regards,
> > Luca
> >
> >
> > _
> >
> > http://www.mindrones.com
> > ___
> > Bf-committers mailing list
> > Bf-committers@blender.org
> > http://lists.blender.org/mailman/listinfo/bf-committers
> >
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>



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

Re: [Bf-committers] Has there been any word on Aligorith?

[Mike Belanger]

I was wondering about that today too.  Man the latest earthquakes look 
horrific.  I hope Aligorith is ok.
Its safe to say if he's ok, he'll reply to this thread.

On 2011-02-22, at 11:11 AM, Jaevixa McNomera wrote:

> Sorry if this is not the place for this email, but can it stated in here
> when someone hears word on Aligorith?
> 
> The IP's I can get to are somewhat restricted here in the hospital (but of
> course I can get Google) so I can't always see other sites (notably
> graphicall.org is blocked from in here...)
> 
> 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

Re: [Bf-committers] armatures, ipos and actions

[Mike Belanger]

Yes the NLA is designed (and very good) at sharing actions.
raphael,

Here's a file demonstrating the NLA solving your problem.  Note that I'm not a 
huge fan of keying on object level, but it is possible.

http://www.pasteall.org/blend/5543

On 2011-03-10, at 7:38 PM, Joshua Leung wrote:

> Hi,
> 
> For a moment there I was confused by the terminology you were using.
> If I understand correctly, you want to have several rigs sharing the
> same action (pose-bone level animation), but still be able to position
> the rig objects in different places (object-level animation).
> 
> There isn't any bug here. By design, a single animation data (1 action
> + a collection of drivers + a collection of nla-tracks (containing
> strips referencing actions)) block lives on each ID-block (i.e.
> Object/Lamp/Material/etc.) Now, PoseBones are data hanging off an
> Object, just like the Object's transform properties
> (loc/rot/scale/etc.) Hence, they are affected by the same animation
> data block.
> 
> For what you want to accomplish, what you really want to do is to use
> the NLA system. One strip gets the object-level, another gets the
> pose-bone level.  See
> http://aligorith.blogspot.com/2010/10/clarifying-animation-workflow-in.html
> with regards to NLA usage.
> 
> Hope that helps,
> Joshua
> 
> On Fri, Mar 11, 2011 at 3:13 AM, raphael  wrote:
>> Hi everyone,
>> 
>> i was about to make a bug report but i prefer posting here first.
>> (didn't have any answer in supports forum)
>> 
>> In blender 2.49, you can have one ipo linked to armature's Object,
>> one action linked to it's data. So, differents armatures can have
>> their own position (+rotate and scale), and sharing the same action.
>> 
>> In 2.5, ipos and bones animations are both included in "actions",
>> and differents armatures can't share actions and have
>> different movements on the same time.
>> 
>> Is it a bug, the result of the new design or something that can be
>> changed in users prefs ?
>> 
>> some test files here
>> http://dwarf.free.fr/blender2.5/armatures_249-01.blend
>> http://dwarf.free.fr/blender2.5/armatures_250-01.blend
>> 
>> regards
>> raphael
>> ___
>> 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] Relative Paths as default setting

[Mike Belanger]

+1

I've had to move certain assets independently of others as well, but its a
rare occurrence.
Rather than having a 'Relative Option', I'd prefer an 'Absolute' option.
This is of course, in addition to the proposed paths' conversion invoked
during a file-save.

On Mon, Dec 7, 2009 at 10:37 AM, Mike Pan  wrote:

> Of course one can do that. (ctrl+u) But for all the user that does not
> mess with the default setting, wouldn't relative be a better default
> option out of the box?
>
> mike
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>



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

Re: [Bf-committers] New Developer Meeting minutes

[Mike Belanger]

If there's people willing to maintain for their own respective compile systems, 
I don't see the issue.

I suppose collectively, our efforts are split, but that's the nature of open 
source projects.  Different
people with different systems, goals, etc.

Mike Belanger ( Mikahl )
www.watchmike.ca





On 2010-01-12, at 12:51 AM, Mats Holmberg wrote:

> 
> On 12.1.2010, at 8.39, Nathan Letwory wrote:
> 
>> 2010/1/12 Erwin Coumans :
>>> I'm surprised of so much resistance among the Blender developers
>>> to such a nice build system as cmake.
>>> 
>>> Thanks,
>>> Erwin
>> 
>> We can also reverse the question - we have a very nice and working
>> SCons system. Why would you want to get rid of the nice system I
>> created?
>> 
>> "I'm surprised at the resistance among certain people to such a nice
>> build system as SCons"
> 
> Just to comment on this: I know nothing about the hassle that is required for 
> maintaining any of these systems, but from a Blender user standpoint scons is 
> very easy to use. As Nathan said, I do "svn up && python scons/scons.py" and 
> that's all that's ever needed. During the years, I haven't seen anything 
> being even close to that kind of ease of use.
> 
> Dont' take that away, please!
> 
> -mats
> ___
> 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