Re: [Bf-committers] Text editor: tab as space as default? do we really need to push PEP8 that way?

2010-03-05 Thread Campbell Barton
for consistency we are following pep8, to match other python projects.

agree backspace should also remove indentation, but this is what other
editors do (SciTE for example), so we can do it also.

On Fri, Mar 5, 2010 at 8:54 AM, Mike Pan mike.c@gmail.com wrote:
 Personally I strongly prefer tabs over spaces, for simplicity's sake.  (a
 single tab is much faster than multiple spaces, and is more visible for
 indentation)

 And for consistency's sake, I think Blender should always defaults to what
 most people comes to expect from a code editor, which means tabs are
 inserted as tabs, and not converted automatically to x number of spaces.

 When someone hits tab 3 times, and then hit backspace 2 times, there should
 be exactly 1 tab left (and not 2 tabs and 2 spaces), making the code editor
 do anything else fancy is just confusing to users.

 -mike
 ___
 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


Re: [Bf-committers] Text editor: tab as space as default? do we really need to push PEP8 that way?

2010-03-05 Thread Paolo Ciccone
One more voice in favor of tabs as spaces. TextMate, the editor that I use,
and Emacs, can handle that situation very well.
But what's more important, tabs have been proven in several occasions to
lead to inconsistent presentation of the code.
They are a relative entity, while a given amount of spaces will always
appear as originally intended. When code uses a
mix of tabs and spaces, and that happens often when inserting hard tabs, the
resulting indentation goes often haywire.
When I hit Tab I expect the editor to indent and align my code in a
consistent manner, based on the language used.
In Emacs pressing tab in the middle of the line, not just at the beginning,
performs that operation. So, there is clearly
a separation between what the key does and its ASCII representation.

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


Re: [Bf-committers] Python RNA Type Registration

2010-03-05 Thread Pacific Morrowind
Well since you're asking for more comments on this from casual coders. 
I'll just stick in my 2 cents.
I guess I would say I'm a bit more than casual coder... code 99% Python 
but working as secondary dev on both the NifTools nif import/export 
scripts for Blender and PyFFI, and as primary dev for Wrye Bash (a game 
specific modding/mod user tool).
I think that having to manually register each individual class is sucky 
and highly error prone with each update; yes you can get around that but 
I think something semiautomatic is better.
However I'm happy with any solution; don't have a whole lot of concern 
that you 3 will be able to come up with something that you can all agree 
on and is highly workable.
Pacific Morrowind

On 04/03/2010 4:13 PM, Martin Poirier wrote:
 Hello again,

 --- On Wed, 3/3/10, Campbell Bartonideasma...@gmail.com  wrote:


 Discussed with Brecht yesterday.
 - We agree class enumeration is ugly and should be
 replaced.
 - We agree it would be acceptable to collect classes
 automatically and
 register all with 1 or 2 lines at the bottom of the
 script.
 - At some point it doesn't make sense to discuss if
 something is
 complicated or not, harder to debug etc. I just need to
 test it, try
 make changes, see what happens when things go wrong etc.
  

 I think it's also important to consider that this isn't just something that 
 is used by people doing a lot of python dev but also by casual coders. Dalai 
 raised a good point, but I wished we had more input from others.



 Nevertheless this MUST be fixed before release, My
 impression is that
 you are worried the current system will stick if we don't
 replace
 soon, which is why you want to get this in?
  

 Mostly that and the fact that I find the explicit registration method prone 
 to errors and bad boilerplate code.

 Maintaining the patch (conflicts every time someone modifies the stupid class 
 lists) is an annoyance but not really an issue.


 After this mail I'm left thinking this might be more
 important then I
 originally thought, will see of I can get time to work on
 it.
 Otherwise it can be put on hold.
  

 I know what happens with things that are put on hold, so you can expect me to 
 keep insisting.

 Martin


__
 Looking for the perfect gift? Give the gift of Flickr!

 http://www.flickr.com/gift/
 ___
 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] Commit rights for Sergey I. Sharybin (nazgul)

2010-03-05 Thread Emmanuel Stone
This sounds like a good point to replace the existing NURBS
architecture with the libNurbana backend.
The code has been stable enough to do this for some time, but I was
waiting until more functionality was exposed in the UI before
suggesting it.

Sergey, I'm glad that you're on board, there is a lot of work that's
needed on the UI side of things :)

However, if there will be changes made to curves/NURBS in the head, it
will make maintaining a parallel branch much more difficult or
impossible.

I believe the libNurbana backend is faster, more feature rich and
easier to maintain than the existing code.

If I make up a patch that adds libNurbana to the head, will someone review it?

-Emmanuel

On Fri, Mar 5, 2010 at 6:19 AM, Brecht Van Lommel bre...@blender.org wrote:
 Hi,

 I've granted commit rights to Sergey for working on nurbs and curves.
 In particular he's added support for constructive modifiers and is
 fixing various problems. I'll still review his commits and patches for
 a while. Anyway, congrats!

 Brecht.
 ___
 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 [27269] trunk/blender/source/blender/ makesrna/intern/rna_space.c: Patch #21459: Expose viewmat (in Region3DView) via the py API

2010-03-05 Thread Campbell Barton
added reprojection which shares functionality with projection painting,
next I'll try make an operator which deals with rendering shadeless,
opening in the gimp and re-projecting back so its not so tedious to
setup.

On Fri, Mar 5, 2010 at 10:23 AM, Campbell Barton ideasma...@gmail.com wrote:
 projection paint code can also do this, but not actually paint by hand
 ofcourse, just use it to bake the image back.

 The advantage with this is low res view project into high res texture
 will work fine (wont miss pixels). and there is already code to do the
 normal falloff (fade out faces that point away) and deal with UV bleed
 etc.

 On Fri, Mar 5, 2010 at 10:12 AM, Tom M letter...@gmail.com wrote:
 On Thu, Mar 4, 2010 at 11:26 PM, Campbell Barton ideasma...@gmail.com 
 wrote:
 Brecht did view based re-projection for BigBuckBunny with the gimp but
 we didn't end up using it, IIRC it wasn't a high quality method.

 Hmm I would think that would be quite easy to solve for brecht :) -
 just up sample based on uv coordinate per pixel.  It will still have a
 problem of stretching when you are at an extreme angle to the face,
 but that is also quite solvable by generating an image mask based on
 face normal angle to the viewing angle (another solution to it, which
 is mentioned in the digital humans book that talks about a texture
 projection shader is to project back on to the mesh from multiple
 views and based on how flat the face is to the texture being projected
 it determines how much of the texture to take from that view).

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




 --
 - Campbell




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


[Bf-committers] cyclical cloth, hair and other simulation (possibly useful for Durian?)

2010-03-05 Thread Tom M
This paper describes a method for cyclical cloth variation (which can
be applied to other simulations such as hair and fur movement) and
also color variation methods for cloth

http://isg.cs.tcd.ie/cosulliv/Pubs/EG2006Dobbyn.pdf

This could reduce a lot of calculation for secondary characters,
possibly even main characters; and would also be useful for game
characters.

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