Re: [Bf-committers] 2.64 release notes
On Sat, Sep 22, 2012 at 12:25 AM, Keir Mierle mie...@gmail.com wrote: I cleaned up the wording in the planar tracking section. Any objection to linking to my youtube video showing the new planar tracking? http://www.youtube.com/watch?v=5FBqpE4XO_s Great, I'm not an expert on tracking so it's good that the text got another review. Any links to videos or other documentation is fine, it's also possible to embed with a youtube tag like this: youtube width=400 height=225 KZalGrjGKSA/youtube Brecht. ___ 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 [50813] trunk/blender/source/blender/ makesrna/intern: code cleanup: make many functions static
This breaks Cycles compile: http://www.pasteall.org/35464 Compiling with everything disabled in cmake is not a good idea ;-) And again, we are in BCon4! Am 22.09.2012 16:07, schrieb Campbell Barton: Revision: 50813 http://projects.blender.org/scm/viewvc.php?view=revroot=bf-blenderrevision=50813 Author: campbellbarton Date: 2012-09-22 14:07:55 + (Sat, 22 Sep 2012) Log Message: --- code cleanup: make many functions static -- 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
Re: [Bf-committers] Regarding sticky coordinates removal from blender
On Sat, Sep 22, 2012 at 9:03 AM, Campbell Barton ideasma...@gmail.com wrote: Committed a material option so UV interpolation is calculated using the same method that sticky used, r50806. - see UV Project material option. This fixes the nasty errors you pointed out. Now blender crashes on loading the same file ( http://www.pasteall.org/blend/16548 ). Not sure about specific revision, but this file works well with RC1 (r50696). Crashlog: http://www.pasteall.org/35469 ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Make Parent - shouldn't it work differently?
In one of the previous posts I explained what I do to get proper relation between parent and child and not to lose the position, rotation and scale of the child at the moment of parenting. The script that I use does this: 1. Stores the current world matrix of the child. 2. Makes parent without inverse 3. sets world matrix of child to previously stored world matrix of the child. a - parent b - child m = b.matrix_world b.parent = a b.matrix_world = m Tested it, it works great, I made an operator from it, assigned keyboard shortcut and I use it regularly. I can live with current behavior, especially that I don't use it :-) I have my own hack, but I simply think that this should be default. Bartek Skorupa www.bartekskorupa.com On 22 wrz 2012, at 00:14, Bassam Kurdali bas...@urchn.org wrote: I don't think it should happen by default. it could be especially nasty for animation data, linked data, etc. Also it doesn't store as much information (the relationship between child and parent at the time of parenting) which could come in handy later. However, it is not hard to do! You need for that is to multiply the inverse transform matrix with the world transform matrix. I think - I may have gotten the order wrong. so, an easy way : 1- do a normal parent operator (creates inverse transform matrix) 2- multiply the inverse transform and the regular matrix for the object 3- clear inverse transform 4- put the matrix from 2 into the transform for the object. I think 4 is a bit more complicated, because I *think* that the matrices are read-only, so you'll have to decompose into translation/rotation/scale (mathutils provides all those functions anyway) bundle that up into an operator and you're home free. Another good option is just to calculate the inverse parent and avoid doing the parent-clear inverse dance. If this is done in blender internally the same code could be used to avoid having two code paths. one possibility for blender behavior is to have a parent menu, with a few choices, similar to the un-parent, and keep the current behavior the top/default choice. On Fri, 2012-09-21 at 21:11 +0200, Bartek Skorupa (priv) wrote: Thank you. However we are only half way there. It solves the major issue as we at least don't have weird properties of the child. The question still remains: How to make a parent such that the child stays at it's current location, rotation and scale, but the values of loc/rot/scale change. This is what should happen by default. @Bassam Kurdali: You wrote: the default behaviour should be kept, of course. Most users want this. I wouldn't agree with that. I'm scratching my head trying to figure out at least one benefit of current default behavior and can't find anything. Is there any good reason for destroying the order in the scene? Having objects with locations, rotations and scales set in relation to who-the-hell-knows what? What do I miss? Bartek Skorupa www.bartekskorupa.com On 21 wrz 2012, at 20:44, Remigiusz Fiedler mig...@gmx.net wrote: no ctrl needed, it is alt p - clear inverse parent 2012/9/21 Bartek Skorupa (priv) bartekskor...@bartekskorupa.com: Ctl-Alt-P ?? When I hit it I get a warning: Can only make proxy for a referenced object or group What do I miss? ___ 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] [Bf-blender-cvs] SVN commit: /data/svn/bf-blender [50813] trunk/blender/source/blender/ makesrna/intern: code cleanup: make many functions static
If you had to build blender as often as I do (apply patches, go back revisions and check for changes, change CFLAGs) - you would see its a very good idea! but point taken - when making changes that effect linking, its good to test with cycles on. On Sun, Sep 23, 2012 at 12:54 AM, Thomas Dinges blen...@dingto.org wrote: This breaks Cycles compile: http://www.pasteall.org/35464 Compiling with everything disabled in cmake is not a good idea ;-) And again, we are in BCon4! Am 22.09.2012 16:07, schrieb Campbell Barton: Revision: 50813 http://projects.blender.org/scm/viewvc.php?view=revroot=bf-blenderrevision=50813 Author: campbellbarton Date: 2012-09-22 14:07:55 + (Sat, 22 Sep 2012) Log Message: --- code cleanup: make many functions static -- 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 -- - Campbell ___ 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 [50813] trunk/blender/source/blender/ makesrna/intern: code cleanup: make many functions static
now the functions which cycles access are giving warnings again (-Wmissing-prototypes). Im looking over these I found cycles had an incorrect definition. - cycles void rna_Object_free_duplilist(void *ob, void *reports); ...vs the actual function declaration... void rna_Object_free_duplilist(struct Object *ob) I've found these kinds of errors don't always crash - it depends on the architecture but at least using -Wmissing-prototypes helps expose problems like this. On Sun, Sep 23, 2012 at 2:28 PM, Campbell Barton ideasma...@gmail.com wrote: If you had to build blender as often as I do (apply patches, go back revisions and check for changes, change CFLAGs) - you would see its a very good idea! but point taken - when making changes that effect linking, its good to test with cycles on. On Sun, Sep 23, 2012 at 12:54 AM, Thomas Dinges blen...@dingto.org wrote: This breaks Cycles compile: http://www.pasteall.org/35464 Compiling with everything disabled in cmake is not a good idea ;-) And again, we are in BCon4! Am 22.09.2012 16:07, schrieb Campbell Barton: Revision: 50813 http://projects.blender.org/scm/viewvc.php?view=revroot=bf-blenderrevision=50813 Author: campbellbarton Date: 2012-09-22 14:07:55 + (Sat, 22 Sep 2012) Log Message: --- code cleanup: make many functions static -- 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 -- - Campbell -- - Campbell ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] Revisiting Color Curves
Now that OCIO has begun to land in Blender, I thought it might be worth evaluating whether we could improve the curves control in the compositor a little. Currently, curves operates on data between output referred values 0 and 1. With native scene referred values, 1.0 is effectively meaningless. Might it be possible to implement a method to display a region of the data in the curves window by specifying a lower and upper limit? Thoughts? With respect, TJS ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
