Re: [Bf-committers] Surface and Volume modeling with new developed Bezier-Surface math

[Michael Fox]

Very impressive, though a few little pinching and bulging issues

http://www.pasteall.org/pic/show.php?id=61688

i can't wait for it to be interactive :)

On 01/11/13 06:15, Roland Adorni wrote:
> Hello,
>
> I haven't given up completely and am still working on my
> Bezier-Surface/Volume 3D-modelling idea from time to time.
>
> This is the latest results:
>
> http://abload.de/img/renderedbeziervolumeew8poe.jpg
>
> What's new is that I figured out how to auto-calculate the handle
> lengths the way that the surfaces are best rounded and natural smooth.
>
> All the Blender default sphere meshes really become a sphere..and the
> torus is round and the other objects are just natural rounded.
>
> As it seems to me the only thing that  not become a perfect sphere is
> the cube...but than can you even make a sphere out of a cube?
> What was the thing with the impossibility to transforming a circle in a
> square again? (I am joking. )
> I really don't know about the cube thing if it should become a sphere or
> as it rather seems shouldn't become a sphere. At least no perfect one.
>
> Well I created a DropBox and uploaded my python script to it:
>
> https://www.dropbox.com/sh/5ha6d9zvheg43qp/Rio1oFWWMO
>
> So you can use and experiment with it yourself if you like. (Check the
> read me)
>
> Don't expect a very user friendly all working script or something.
>It's my working script and I will update from time to time whenever I
> feel to work on this idea again.
>
> A known issue at the moment: The tangential planes aren't calculated
> always correctly. I will have to calculate them in another way.
>
> best regards,
>rad, Roland Adorni
>
> p.s. Thank you for the head up email in the past Jake. :) That was nice.
> I already thought my study is of no interest to anyone.
>
>
> ___
> 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] Surface and Volume modeling with new developed Bezier-Surface math

[Michael Fox]

let me see if i understand this correctly, does this mean you can have a 
bezier surface point that can have more than 2 handles? (btw, i can 
barely see whats going on because of the handles ;) )

On 04/10/13 04:31, Roland Adorni wrote:
> Hello
>
> You were correct. My example was too simple. Indeed I get sharp edges
> instead smooth ones for general objects.
>
> Here are my first results:
>
> http://abload.de/img/biezervolume1dys7h.jpg
>
> http://abload.de/img/beziervolume2d6b07.jpg
>
> I believe I know how to correct it however it means the still rather
> simple calculation becomes a lot more tricky.
>
> I like that Blender-Python scripting capability. Allows me to do changes
> and directly see the results.
>
> regards
>rad
>
> p.s. given I have 2 vectors and store them  in python with:  a = (2,3,4)
> and  b=(4,5,6).  Does Python have vector operation for this "things"
> (addition, dot multiplication, scaling.. etc)? Didn't really want to use
> or create a class for just 3 coords. :/
>
>
>
>
> On 21.09.2013 22:09, Brecht Van Lommel wrote:
>> In your example it seems you have 6 regular vertices with nice
>> matching handles, but if you want to do more complex shapes, things
>> aren't so simple anymore. If a vertex doesn't have 4 neighbours, what
>> happens then? The tricky thing is extending such a method to arbitrary
>> topology, while still keeping the surface smooth.
>>
>> 
> ___
> 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] Patch [#36028] New 4-column layout for the editor-type-selector menu...

[Michael Fox]

This layout I like if the dividers were a little Dimmer as they are now it
makes the menu too busy visually
On 8 Jul 2013 14:17, "Harley Acheson"  wrote:

> Short of a big overhall, there are also simple things we can do.
>
> The following shows the current menu on the left. On the right there
> has been some margin added to the left of the icons so they are not
> scrunched against the left. The separators are made a lot less invisible,
> and are not extended to the edges.
>
> http://www.pasteall.org/pic/show.php?id=55110
> ___
> 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] Patch [#36028] New 4-column layout for the editor-type-selector menu...

[Michael Fox]

Personally, and this might get me into trouble again, but I do not believe
this is an improvement, the current menu is already segregated and grouped,
and is more natural with the general vertical layout of blender,.

humans naturally finds vertical menus not box menus easier to read as most
read from top to bottom, left to right, hence why menus are generally 1
column layout with simple words, the modifiers list is box because most
modifiers are similar and names can be confusing.

Because if this I see this patch as a step backward and would do more
annoying then actually helping
On 6 Jul 2013 15:51, "David Jeske"  wrote:

> This patch alters the window-editor-type-selection menu to a new 4-column
> layout, based on the multi-column Modifier selection design.
>
> The new design:
> - keeps the "primary" editors very close to the menu-button in both
> orientations
> - makes it SUBSTANTIALLY easier to find and remember the locations of other
> editor types in the menu
> - provides an ordered grouping of editor-types, with a meaning that can
> help new users understand the software
>
> http://www.pasteall.org/pic/show.php?id=54986
>
>
> http://projects.blender.org/tracker/index.php?func=detail&aid=36028&group_id=9&atid=127
> ___
> 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] bug with fcurves

[Michael Fox]

hey all has fcurve interpolation changed recently, i loaded up my old 
"lets paint" file to test some gsoc projects, and tought to see if it 
still works but i find its all jittery and i havn't changed anything and 
i have noticed there is little peaks between keys that are on the exact 
same vertical position, this is in trunk

.blend file
http://mfoxdogg.com/works/lets_paint/Lets_paint_main.blend
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Leap Motion seeding to Blender developers & artists

[Michael Fox]

whoops forgot to mention i am on linux at home (openSUSE12.3) and 
windows at work (7)

On 08/05/13 23:12, Ton Roosendaal wrote:
> Hi all,
>
> https://www.leapmotion.com/
>
> I've contacted Leap Motion and they agreed to seed 10 units to Blender 
> developers and/or actively involved users.
>
> I suggest we do 5 for devs at least, rest for people on this list who can 
> contribute testing and feedback.
>
> Just reply on this message if you're interested, and a short sentence what 
> you intend to do with it (code work or testing, and which OS). I then will 
> select the 10 'winners', ask them for the shipping details and forward it to 
> Leap Motion. They already seed units now btw, before the official launch end 
> of July.
>
> 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

Re: [Bf-committers] Leap Motion seeding to Blender developers & artists

[Michael Fox]

I would like to see how this works with animation and general scene 
management, see if it works well with the sliding interface of blender 
with multiple windows. also i am the blender labrat :)

On 08/05/13 23:12, Ton Roosendaal wrote:
> Hi all,
>
> https://www.leapmotion.com/
>
> I've contacted Leap Motion and they agreed to seed 10 units to Blender 
> developers and/or actively involved users.
>
> I suggest we do 5 for devs at least, rest for people on this list who can 
> contribute testing and feedback.
>
> Just reply on this message if you're interested, and a short sentence what 
> you intend to do with it (code work or testing, and which OS). I then will 
> select the 10 'winners', ask them for the shipping details and forward it to 
> Leap Motion. They already seed units now btw, before the official launch end 
> of July.
>
> 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

Re: [Bf-committers] Proposal for better integration of shape keys

[Michael Fox]

to do this you use vertex groups, and the mirror modifier already 
mirrors vertex groups .L->.R

On 26/02/13 21:10, Tobias Oelgarte wrote:
> Hello,
>
> I'm currently working on a face rig and i wanted to use shape keys for
> the details. But i encountered the problem that i would need to apply
> the mirror modifier. If i don't, then i have no way to create left or
> right sided shape keys, because every shape key will always affect the
> left and right side of the resulting mesh. (in the stack the shapekeys
> are applied first to the mesh, the mirroring happens afterwards)
>
> But if i apply the mirror modifier then i have other problems. At first
> i have to define left and right sided shapekeys. This is a lot of extra
> work. The second point is if i have to make some corrections to the
> geometry later on. Grabbing a vertice is no problem (x-mirror), but
> deleting and creating new faces in a mirrored fashion is a problem that
> x-mirror does no solve.
>
> So i was thinking on how this could be avoided. I came up with the idea
> that shape keys should recognize that a mirror-modifier is the first
> modifier. If it is set to x-mirroring, then the mirror modifier should
> be applied first and the shape keys later on, while automatically
> influencing the left and right side with two influence sliders. This has
> multiple advantages:
>
> 1. no need to give up the mirror-modifier
> 2. shape keys only need to be created on one side
>
> A simple mockup would look like this (left current, right proposed):
> http://www.pasteall.org/pic/show.php?id=46086
>
> Greetings from
> Tobias Oelgarte
> ___
> 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] BBB Of topic but funny

[Michael Fox]

Brilliant deductions sherlock :P

On 08/12/12 06:49, Nathan Vegdahl wrote:
> It looks to me like the kid is intentionally affecting that walk, not
> like that is his normal walk.  I think he's trying to be silly.
>
> On Wed, Dec 5, 2012 at 3:51 PM, Harley Acheson  
> wrote:
>> Douglas,
>>
>> So the reason for this email was to say "have a laugh at the
>> fat kid who is walking funny"?  I highly doubt the kid posted the
>> image himself so that others could laugh at him, so it seems
>> mean-spirited to forward it to a group list in this way. Best to
>> leave that to your Facebook friends.
>>
>> Maybe I'm overreacting but I'm a bit sensitive about bullying
>> behavior.
>>
>> Harley
>> ___
>> Bf-committers mailing list
>> Bf-committers@blender.org
>> http://lists.blender.org/mailman/listinfo/bf-committers
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>

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

Re: [Bf-committers] Blender developer meeting minutes - 2 december 2012

[Michael Fox]

On 03/12/12 02:40, Sergey Sharybin wrote:
> Hi.
>
> Notes from today's meeting in irc.freenode.net #blendercoders
>
> 1) Blender 2.65 Release
>
> - Release Candidate happened last week. Unfortunately, there's a known
> crasher when entering edit mode. We'll make RC2 AHOY middle next week
> - We'll check on status next meeting and hopefully we could make final AHOY
> soon after this
> - Only crucial fixes are allowed! Brecht and Sergey will read over commits
> next week to prevent accidents
> - No interface strings changes, it'll break translations for the release
> - Bug tracker is at 68 mark, some release stoppers are still there
> - Maintainers should check if all their new features are in release notes:
> http://wiki.blender.org/index.php/Dev:Ref/Release_Notes/2.65
> - Artists' help with sample .blend files and better images for notes is
> welcome
i have a nice bevel comparison, http://mfoxdogg.com/bevel_comparison.png
>
> 2) Other projects
>
> - Bastien was working on list_template improvements to make it's possible
> to have several lists per panel. Review is needed:
> https://codereview.appspot.com/6854125/
>
> That's it for now, thanks everyone!
>

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

Re: [Bf-committers] Replacement for pre-compiled Linux libraries

[Michael Fox]

On openSUSE 12.2 i get this "Failed to detect distribytive type" and 
nothing else

On 13/11/12 06:49, Sergey Sharybin wrote:
> Hi,
>
> I was working on a script which is aimed to install/build all
> the dependencies needed by Blender. It should make it easier from
> maintaince point of view than current libraries from the svn.
>
> I've tested the script using Fedora 14, 17 and Ubuntu 10.04, 12.10. Looks
> like this script installs all needed dependencies from the report and
> builds missing ones. However, it's not so nice to build Blender in a
> virtual machine, so could not guarantee there's no linking errors happens
> in the end.
>
> I would ask actual users of this platforms to check if the script behaves
> properly and let me know if there're issues with the script. But please,
> don't use bug tracker for this reports.
>
> This script is placed in build_files/build_environment/install_deps.sh.
>
> One more thing i would need help with is updating wiki pages around
> http://wiki.blender.org/index.php/Dev:2.5/Doc/Building_Blender/Linux (think
> we'll need to mention the script there when it'll be considered 100% ready)
>
> Also, i would like to zap precompiled libraries to the end of this week if
> the script will work nicely.
>

___
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

[Michael Fox]

My vote is for putting them back, since its clear they are being used, 
so as long as BI is still being used sticky should remain, just not on 
bugs associated with it that the feature is no longer developed and will 
not be fixed. Not to mention its very late in the cycle to be doing this

On 22/09/12 08:34, Campbell Barton wrote:
> @Lockal,
>
> Cameras really shouldn't be scaled - when you scale a camera it won't
> render scaled, so UV project is correct in this case.
>
> On Sat, Sep 22, 2012 at 5:12 AM, Lockal S  wrote:
>> Project from view ignores the scale and aspect of camera. Additional
>> uv tweaking is needed to match the scale of original image.
>>
>> The other potential replacement could be adding and applying UvProject
>> modifier on the special uv layer, however it distorts uvs in
>> perspective mode.
> Can you expand on this? - not sure what you mean.
>
>>   Also it doesn't take image aspect into account
>> (default aspect is (1, 1)). And even after fixing distortion in
>> uvproject modifier there are still problems:
> The aspect is 1:1 but its a setting that can be modified. Adding an
> option to use the scenes aspect can be done easily, though it does
> create a tricky dependency (changing scene aspect would need to update
> modifiers).
>
>> 1) No replacement in do_versions provided
> Since this has been hidden for so long, my assumption was that users
> were not accessing.
>
>> 2) No changes in documentation and release notes
> Yep. this needs doing.
>
>> 3) Even then Spacebar menu -> Add sticky is easier than going to
>> modifiers panel, adding Uv project modifier, setting image, setting
>> aspect, setting camera and clicking apply after each geometry change.
> I see your point but dont think its an argument for keeping sticky -
> such a tool can be added as an operator accessible from C, or a macro
> / py script.
> eg - http://www.graphicall.org/ftp/ideasman42/uv_project_apply.py
>
>> On Fri, Sep 21, 2012 at 9:32 PM, Nate Wiebe  wrote:
>>> Unless I'm missing out on something, using project from view uvs is a
>>> better solution and works with cycles.
>> ___
>> 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] Floating buttons proposal

[Michael Fox]

sorry for my outburst, i hope no one really takes offence to me, my 
opinions are my own and i tend to be a little protective of blender, i 
owe my life to it.

some serious things have happened in my life recently and its made me 
irritable, im usually not like this, so for any offence i have caused im 
sorry and please excuse me
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Floating buttons proposal

[Michael Fox]

OK this has gone on long enough, not only have you ignored one of the 
greatest minds we have, but you want to thrown away all of our own work 
which is based on dozens of studies with your 'looks fancy' ideas not 
knowing what is underneath, your arrogance is mighty impressive.

What you are planning is to do a gnome3 on us and here is the new UI 
like it or lump it. Now with all your patches and proposals you have 
done so far lack 1 crucial element which blender is renowned for and 
that is freedom, freedom to mould and define what the user wants blender 
to do and none of your patches have an option to turn it off, its seems 
to me that you think you are above the the user and the user will like 
what you give them without question.

with 2.5 drawing was disconnected from data, so you can have multiple 
drawing kernels and choose what one you want, like replace normal menus 
with radial menus (if someone is willing to code it), so what you are 
proposing is NOT floating panels but a whole drawing kernel, when the 
term floating panels is used in blender world, its the floating panels 
in the pre-2.5 era, not these proposals which have NOT been approved.

And on that note I would like to see your approved GSoC targets and 
detailed descriptions of each and why, and I am sure a lot of others on 
this list would like to see that as well

On 16/06/12 05:00, Jorge Rodriguez wrote:
> The purpose of floating controls is to allow designs from the proposals of
> persons like:
>
>
> - Bill 
> Reynish(On
> the left of the 3D view)
> - Myself  (On the bottom of the 3D view)
> - Leeroy/LCG  (Along the top)
>
>
> My proposal doesn't include any specific designs, only the ability to
> create them through scripting. The 'T' toolbar would likely be replaced
> entirely by some sort of floating control arrangement. The end result would
> be more space available for the user. The "previous operator" panel is in
> my opinion a good workflow idea with a failed design implementation, and we
> should experiment with other
> waysof doing it,
> which would be supported by the floating controls structure.
>
> I think that not having pixel locations, while it makes sense with the
> properties panels, may not make so much sense here. Some designs, such as
> the third, may not boil down to just a row or column of buttons. These
> designs won't change all that often, so I don't think adding one button
> between others is a use case that we need to be more concerned about. To
> zoom, the layout engine can simply scale the pixel locations and sizes. We
> can include the ability to arrange buttons in rows and columns as well, but
> I think pixel locations is a good idea.
>
> Note: Undocking a panel is another thing to do on my list, but it's not
> part of this proposal.
>
> On Fri, Jun 15, 2012 at 7:01 AM, Brecht Van Lommel<
> brechtvanlom...@pandora.be>  wrote:
>
>> Hi,
>>
>> I'm missing details on how you interact with these floating things, a
>> mockup, an example for how they would be used, etc. For me it seems
>> that this would be another way to present what we already have in
>> panels and menus. So how do these coexist, what goes where? Right now
>> we basically have a toolbar, a redo panel, and properties of the
>> space.
>>
>> Could they be some sort of region inside a space like we have now, but
>> overlayed with a transparent background?
>>
>> Also explicit values for pixel sizes should be avoided in scripts,
>> that doesn't work well with a zoomable interface, and makes it more
>> complicated to drop in a button between others. It's nice to allow
>> flexibility but in the end I think you mostly want e.g. a row of icons
>> for a toolbar, or undocking some panel, .. ? So it may not need that
>> many layout code changes, that seems lower priority to me.
>>
>> Brecht.
>>
>> On Wed, Jun 13, 2012 at 8:06 PM, Jorge Rodriguez
>>   wrote:
>>> As part of my GSoC I'm going to be implementing some floating buttons in
>>> the 3D view. It should help with usability, with reducing clutter in the
>>> properties/tool panels, and with tablet users. I'd like some Blender devs
>>> to please review it and make comments so that I can revise it before it's
>>> updated.
>>>
>>> http://wiki.blender.org/index.php/User:Vino/Floating_Buttons_Proposal
>>>
>>> Thank you.
>>>
>>> --
>>> Jorge "Vino" Rodriguez
>>> jo...@lunarworkshop.com
>>> twitter: VinoBS
>>> 919.757.3066
>>> ___
>>> 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 [47283] branches/soc-2012-sushi/source/ blender: Check if all faces are triangle

[Michael Fox]

Ok its no my place to comment, but why not use the underlying tessfaces 
structure, instead of using the top structure, that way the user don't 
have to tesselate their mesh by hand, and granted most scanned models 
are tris, but saying "tri's only" really limits the usability of this tool

On 01/06/12 01:52, Alexander Pinzon wrote:
> Revision: 47283
>
> http://projects.blender.org/scm/viewvc.php?view=rev&root=bf-blender&revision=47283
> Author:   apinzonf
> Date: 2012-05-31 15:52:18 + (Thu, 31 May 2012)
> Log Message:
> ---
>   Check if all faces are triangle
>
> Modified Paths:
> --
>  
> branches/soc-2012-sushi/source/blender/bmesh/operators/bmo_smooth_laplacian.c
>  branches/soc-2012-sushi/source/blender/editors/mesh/editmesh_tools.c
>
> Modified: 
> branches/soc-2012-sushi/source/blender/bmesh/operators/bmo_smooth_laplacian.c
> ===
> --- 
> branches/soc-2012-sushi/source/blender/bmesh/operators/bmo_smooth_laplacian.c 
> 2012-05-31 15:37:44 UTC (rev 47282)
> +++ 
> branches/soc-2012-sushi/source/blender/bmesh/operators/bmo_smooth_laplacian.c 
> 2012-05-31 15:52:18 UTC (rev 47283)
> @@ -59,6 +59,7 @@
>   NLContext *context;
>   float lambda = BMO_slot_float_get(op, "lambda");
>   float we;
> + int i;
>
>   init_index(bm);
>
> @@ -69,8 +70,13 @@
>   nlSolverParameteri(NL_NB_ROWS, bm->totvert);
>   nlSolverParameteri(NL_NB_RIGHT_HAND_SIDES, 3);
>   nlBegin(NL_SYSTEM);
> + 
> + for(i=0; itotvert; i++){
> + nlLockVariable(i);
> + }
>   BMO_ITER (v,&siter, bm, op, "verts", BM_VERT) {
>   m_vertex_id = BM_elem_index_get(v);
> + nlUnlockVariable(m_vertex_id);
>   nlSetVariable(0,m_vertex_id, v->co[0]);
>   nlSetVariable(1,m_vertex_id, v->co[1]);
>   nlSetVariable(2,m_vertex_id, v->co[2]);
> @@ -148,10 +154,8 @@
>   int vc_id = BM_elem_index_get(vf[vc]);
>   wa = lambda*cotan_weight(vf[vb]->co, vf[vc]->co, 
> vf[va]->co);
>   nlMatrixAdd(vid, vc_id, -wa);
> - //nlMatrixAdd(vid, vid, wa);
>   wa = lambda*cotan_weight(vf[vc]->co, vf[va]->co, 
> vf[vb]->co);
>   nlMatrixAdd(vid, vb_id, -wa);
> - //nlMatrixAdd(vid, vid, wa);
>   }
>   }
>   }
>
> Modified: branches/soc-2012-sushi/source/blender/editors/mesh/editmesh_tools.c
> ===
> --- branches/soc-2012-sushi/source/blender/editors/mesh/editmesh_tools.c  
> 2012-05-31 15:37:44 UTC (rev 47282)
> +++ branches/soc-2012-sushi/source/blender/editors/mesh/editmesh_tools.c  
> 2012-05-31 15:52:18 UTC (rev 47283)
> @@ -1604,6 +1604,23 @@
>   int i, repeat;
>   float clipdist = 0.0f;
>   float lambda = 0.1f;
> + BMIter fiter;
> + BMIter viter;
> + BMFace *f;
> + BMVert *v;
> + int count;
> + 
> + /* Check if all faces are triangles */
> + BM_ITER_MESH (f,&fiter, em->bm, BM_FACES_OF_MESH) {
> + count = 0;
> + BM_ITER_ELEM(v,&viter, f, BM_VERTS_OF_FACE){
> + count = count + 1;
> + }
> + if(count>3){
> + BKE_report(op->reports, RPT_WARNING, "Selected faces 
> must be triangles");
> + return OPERATOR_CANCELLED;
> + }
> + }
>
>   /* mirror before smooth */
>   if (((Mesh *)obedit->data)->editflag&  ME_EDIT_MIRROR_X) {
>
> ___
> 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

Re: [Bf-committers] AVI CODEC future

[Michael Fox]

On 28/05/12 18:50, Thomas Dinges wrote:
> Hey everyone,
> I had a look at the AVI Codec format in the Output Format menu.
>
> It never worked in 2.5x, because it's missing the format select menu.
> This was also only working in 2.4x on windows.
>
> Suggestions:
> 1) Comment the entry in the RNA enum
>
> 2) Remove the whole underlying code, because I think it's questionable
> anyone will bring that back. I had a brief look at the code in 2.4, and
> its quite a bit to port over.
>
> What do you think?
>
> Best regards,
> Thomas
>
i'd say port it, because we cop a lot of complaints that blender don’t 
use their fancy installed codec, and not many realise, we don't use 
system codec, and granted it was a pretty big hack in 2.4 but a very 
usful hack
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] New patch: Blender cloth simulator air pressure enhancement

[Michael Fox]

On 14/04/12 02:00, panjz wrote:
> Hi,
>
> I have just submitted a new patch in the patch tracker: 
> http://projects.blender.org/tracker/index.php?func=detail&aid=30941&group_id=9&atid=127
>  , it's about cloth simulator air pressure enhancement. Any suggestions are 
> welcome :)

Nice work very impressive, however we are too close to release to accept 
this, so after release bug us again and we will get it cleaned up and 
ready for merge :)

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

Re: [Bf-committers] Compositing View Port Proposal

[Michael Fox]

On 28/03/12 07:58, Jason Wilkins wrote:
> The problems as I currently see them:
>
> * The current view port rendering code in Blender is a mess.
>
Oh yes it is more then a mess, its a nightmare, I am trying to add view 
tessellation option to the view port, and im having one hell of a hard 
time. we defiantly need an cleaning out
___
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 [44523] trunk/blender/intern/cycles: Cycles: ambient occlusion support, with AO factor and distance, and a render pass.

[Michael Fox]

Wouldn't AO be a post process, given you are sampling irradiance, then 
put ao on top after each sample instead of building on th ao'd sample, 
wouldn't that allow for multiply, add and subtract

On 29/02/12 05:03, Brecht Van Lommel wrote:
> Hi,
>
> Well, there's a bit of a problem implementing that, it's not possible
> to do with progressive rendering. It would need an integrator that
> renders all samples for one pixel and then multiplies, which doesn't
> fit the current design of progressively taking more samples. An
> integrator that works more like this may be added at some point, but
> that may be a while.
>
> Only thing I can suggest at the moment is multiplying Direct +
> Indirect Diffuse with AO in the compositor.
>
> Brecht.
>
> On Tue, Feb 28, 2012 at 6:05 PM, Carsten Wartmann  wrote:
>> Am 28.02.2012 17:45, schrieb Brecht Van Lommel:
>>> Revision: 44523
>>> 
>>> http://projects.blender.org/scm/viewvc.php?view=rev&root=bf-blender&revision=44523
>>> Author:   blendix
>>> Date: 2012-02-28 16:45:08 + (Tue, 28 Feb 2012)
>>> Log Message:
>>> ---
>>> Cycles: ambient occlusion support, with AO factor and distance, and a 
>>> render pass.
>> Nice! Is "Multiply" also planned? (or possible)
>>
>> Carsten
>> --
>> Carsten Wartmann: Autor - Dozent - 3D - Grafik
>> Homepage: http://blenderbuch.de/
>> Das Blender-Buch: http://blenderbuch.de/redirect.html
>> ___
>> 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

Re: [Bf-committers] Patch Rotate Background Images

[Michael Fox]

On 16/01/12 23:38, Fabio Russo wrote:
> This patch is used to rotate the background images,
> as required by an architect friend!
> This is done using OpenGL API (glRotatef) and calculating the center of the
> image.
>
> The link to the patch:
> http://projects.blender.org/tracker/download.php/9/127/29906/19058/rotate-
> BGpic.patch
>
> An image that shows the rotation of the backgroung images is: http://www.
> pasteall.org/pic/24472
>
> Hoping to be inserted in the trunk!
>
> Best regards,
> Fabio Russo (ruesp83)
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>
Pretty nice patch, havn't looked at the code yet, but it does work, and 
fairly snappy, however, the step size is too large very difficult to get 
the right angle, even with shift held down, and why can i rotate it 
beyond 360 degress, so please work on the usability and UI aspects
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] collada

[Michael Fox]

On 08/01/12 08:28, angjmi...@gulftel.com wrote:
> hey i am hearing that your planning on removing collada!!
> i know there is a lot of issues with it but, at-least as it is right now it 
> can be made to work.
> a lot of people depend on this as their intermediate file format,
> now i know no one likes the idea of what i am doing (cryblend) but someone 
> had to,
sorry to go a bit off here, but why would no one like what you have done 
with cryblend, i think its absolutely awesome what you have done (even 
posted about it on G+)
___
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 [42970] branches/bmesh/blender/source/ blender: bmesh mirror modifier cleanup

[Michael Fox]

when you do the ctrl-p->armature thing it makes them automatically, but 
a nice script wouldn't go amiss

On 30/12/11 10:02, Daniel Salazar - 3Developer.com wrote:
> Can anything be done so you dont have to create the empty vgroups by hand
> or at all?
>
> Daniel Salazar
> 3Developer.com
>
>
___
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 [42970] branches/bmesh/blender/source/ blender: bmesh mirror modifier cleanup

[Michael Fox]

NO and is not hacky at all as it does dose Front and back aswell and it 
uses the same function for flipping as  anything else, does, and truth 
be told im not a fan of the vgroup mods as they seem to be too hackish
On 30/12/11 09:39, Daniel Salazar - 3Developer.com wrote:
> Currently I see it as very hacky, there arent tools to create the needed
> mirrored vgroups, the mirror direction is hardcoded and no where to be seen
> on the UI. Maybe this functionality should better go to a vgroup modifier
> instead
>
> cheers
>
> Daniel Salazar
> 3Developer.com
>
>
> On Thu, Dec 29, 2011 at 4:31 PM, Michael Fox  wrote:
>
>> Off by default is fine, but removal all together i will not allow, it
>> has helped me and many other users immensely modelling a symmetrical
>> object but having each side independently animated, all this does is
>> mirror weights in vgroup .L to vgroup .R
>>
>>
>> On 30/12/11 09:24, Daniel Salazar - 3Developer.com wrote:
>>> maybe bmesh is an opportunity to kill vertex group mirroring in vgroup
>>> modifier or at least have it off by default. I still can't imagine any
>> real
>>> use for this
>>>
>>> cheers
>>>
>>> Daniel Salazar
>>> 3Developer.com
>>>
>>>
>>> On Thu, Dec 29, 2011 at 3:15 AM, Campbell Barton>> wrote:
>>>
>>>> Revision: 42970
>>>>
>>>>
>> http://projects.blender.org/scm/viewvc.php?view=rev&root=bf-blender&revision=42970
>>>> Author:   campbellbarton
>>>> Date: 2011-12-29 09:15:06 + (Thu, 29 Dec 2011)
>>>> Log Message:
>>>> ---
>>>> bmesh mirror modifier cleanup
>>>> * vertex map was a dynamicly realloc'd array when the final size was
>>>> known, use a fixed array instead.
>>>> * vertex map was being calculated even when not used.
>>>> * face tesselation was being called twice.
>>>> * an unused deform group array was being created.
>>>>
>>>> Modified Paths:
>>>> --
>>>>
>> branches/bmesh/blender/source/blender/blenkernel/intern/cdderivedmesh.c
>>>>  branches/bmesh/blender/source/blender/modifiers/intern/MOD_mirror.c
>>>>
>>>> Modified:
>>>> branches/bmesh/blender/source/blender/blenkernel/intern/cdderivedmesh.c
>>>> ===
>>>> ---
>>>> branches/bmesh/blender/source/blender/blenkernel/intern/cdderivedmesh.c
>>>> 2011-12-29 07:29:44 UTC (rev 42969)
>>>> +++
>>>> branches/bmesh/blender/source/blender/blenkernel/intern/cdderivedmesh.c
>>>> 2011-12-29 09:15:06 UTC (rev 42970)
>>>> @@ -2268,15 +2268,16 @@
>>>>}
>>>>
>>>>#if 1
>>>> -/*merge verts
>>>> -
>>>> -  vtargetmap is a table that maps vertices to target vertices.  a value
>>>> of -1
>>>> -  indicates a vertex is a target, and is to be kept.
>>>> -
>>>> -  this frees dm, and returns a new one.
>>>> -
>>>> -  this is a really horribly written function.  ger. - joeedh
>>>> -
>>>> +/* merge verts
>>>> + *
>>>> + * vtargetmap is a table that maps vertices to target vertices.  a
>> value
>>>> of -1
>>>> + * indicates a vertex is a target, and is to be kept.
>>>> + *
>>>> + * this frees dm, and returns a new one.
>>>> + *
>>>> + * this is a really horribly written function.  ger. - joeedh
>>>> + *
>>>> + * note, CDDM_recalc_tesselation has to run on the returned DM if you
>>>> want to access tessfaces.
>>>>*/
>>>>DerivedMesh *CDDM_merge_verts(DerivedMesh *dm, int *vtargetmap)
>>>>{
>>>> @@ -2437,8 +2438,6 @@
>>>>  memcpy(cddm2->mloop, mloop,
>> sizeof(MLoop)*BLI_array_count(mloop));
>>>>  memcpy(cddm2->mpoly, mpoly,
>> sizeof(MPoly)*BLI_array_count(mpoly));
>>>>  BLI_array_free(mvert); BLI_array_free(medge);
>>>> BLI_array_free(mloop); BLI_array_free(mpoly);
>>>> -
>>>> -   CDDM_recalc_tesselation((DerivedMesh*)cddm2);
>>>>
>>>>  if (newv)
>>>>  MEM_freeN(newv);
>>>>
>>>> Modified:
>>>> branches/bmesh/blender/source/blender/modifiers/intern/MOD_mirror.c
>>>> =

Re: [Bf-committers] [Bf-blender-cvs] SVN commit: /data/svn/bf-blender [42970] branches/bmesh/blender/source/ blender: bmesh mirror modifier cleanup

[Michael Fox]

Off by default is fine, but removal all together i will not allow, it 
has helped me and many other users immensely modelling a symmetrical 
object but having each side independently animated, all this does is 
mirror weights in vgroup .L to vgroup .R


On 30/12/11 09:24, Daniel Salazar - 3Developer.com wrote:
> maybe bmesh is an opportunity to kill vertex group mirroring in vgroup
> modifier or at least have it off by default. I still can't imagine any real
> use for this
>
> cheers
>
> Daniel Salazar
> 3Developer.com
>
>
> On Thu, Dec 29, 2011 at 3:15 AM, Campbell Bartonwrote:
>
>> Revision: 42970
>>
>> http://projects.blender.org/scm/viewvc.php?view=rev&root=bf-blender&revision=42970
>> Author:   campbellbarton
>> Date: 2011-12-29 09:15:06 + (Thu, 29 Dec 2011)
>> Log Message:
>> ---
>> bmesh mirror modifier cleanup
>> * vertex map was a dynamicly realloc'd array when the final size was
>> known, use a fixed array instead.
>> * vertex map was being calculated even when not used.
>> * face tesselation was being called twice.
>> * an unused deform group array was being created.
>>
>> Modified Paths:
>> --
>> branches/bmesh/blender/source/blender/blenkernel/intern/cdderivedmesh.c
>> branches/bmesh/blender/source/blender/modifiers/intern/MOD_mirror.c
>>
>> Modified:
>> branches/bmesh/blender/source/blender/blenkernel/intern/cdderivedmesh.c
>> ===
>> ---
>> branches/bmesh/blender/source/blender/blenkernel/intern/cdderivedmesh.c
>> 2011-12-29 07:29:44 UTC (rev 42969)
>> +++
>> branches/bmesh/blender/source/blender/blenkernel/intern/cdderivedmesh.c
>> 2011-12-29 09:15:06 UTC (rev 42970)
>> @@ -2268,15 +2268,16 @@
>>   }
>>
>>   #if 1
>> -/*merge verts
>> -
>> -  vtargetmap is a table that maps vertices to target vertices.  a value
>> of -1
>> -  indicates a vertex is a target, and is to be kept.
>> -
>> -  this frees dm, and returns a new one.
>> -
>> -  this is a really horribly written function.  ger. - joeedh
>> -
>> +/* merge verts
>> + *
>> + * vtargetmap is a table that maps vertices to target vertices.  a value
>> of -1
>> + * indicates a vertex is a target, and is to be kept.
>> + *
>> + * this frees dm, and returns a new one.
>> + *
>> + * this is a really horribly written function.  ger. - joeedh
>> + *
>> + * note, CDDM_recalc_tesselation has to run on the returned DM if you
>> want to access tessfaces.
>>   */
>>   DerivedMesh *CDDM_merge_verts(DerivedMesh *dm, int *vtargetmap)
>>   {
>> @@ -2437,8 +2438,6 @@
>> memcpy(cddm2->mloop, mloop, sizeof(MLoop)*BLI_array_count(mloop));
>> memcpy(cddm2->mpoly, mpoly, sizeof(MPoly)*BLI_array_count(mpoly));
>> BLI_array_free(mvert); BLI_array_free(medge);
>> BLI_array_free(mloop); BLI_array_free(mpoly);
>> -
>> -   CDDM_recalc_tesselation((DerivedMesh*)cddm2);
>>
>> if (newv)
>> MEM_freeN(newv);
>>
>> Modified:
>> branches/bmesh/blender/source/blender/modifiers/intern/MOD_mirror.c
>> ===
>> --- branches/bmesh/blender/source/blender/modifiers/intern/MOD_mirror.c
>> 2011-12-29 07:29:44 UTC (rev 42969)
>> +++ branches/bmesh/blender/source/blender/modifiers/intern/MOD_mirror.c
>> 2011-12-29 09:15:06 UTC (rev 42970)
>> @@ -100,37 +100,22 @@
>>   {
>> float tolerance_sq;
>> DerivedMesh *cddm, *origdm;
>> -   bDeformGroup *def;
>> -   bDeformGroup **vector_def = NULL;
>> MVert *mv, *ov;
>> MEdge *me;
>> MLoop *ml;
>> MPoly *mp;
>> float mtx[4][4];
>> -   int i, j, *vtargetmap = NULL;
>> -   BLI_array_declare(vtargetmap);
>> -   int vector_size=0, a, totshape;
>> +   int i, j;
>> +   int a, totshape;
>> +   int *vtargetmap, *vtmap_a, *vtmap_b;
>> +   const int do_vtargetmap = !(mmd->flag&  MOD_MIR_NO_MERGE);
>>
>> tolerance_sq = mmd->tolerance * mmd->tolerance;
>>
>> origdm = dm;
>> if (!CDDM_Check(dm))
>> dm = CDDM_copy(dm, 0);
>> -
>> -   if (mmd->flag&  MOD_MIR_VGROUP) {
>> -   /* calculate the number of deformedGroups */
>> -   for(vector_size = 0, def = ob->defbase.first; def;
>> -   def = def->next, vector_size++);
>>
>> -   /* load the deformedGroups for fast access */
>> -   vector_def =
>> -   (bDeformGroup **)MEM_mallocN(sizeof(bDeformGroup*)
>> * vector_size,
>> -
>> "group_index");
>> -   for(a = 0, def = ob->defbase.first; def; def = def->next,
>> a++) {
>> -   vector_def[a] = def;
>> -   }
>> -   }
>> -
>> /*mtx is the mirror transformation*/
>> unit_m4(mtx);
>> mtx[axis][axis] = -1.0;
>> @@ -166,20 +151,30 @@
>> CustomData_copy_data(&dm->vertData,&cddm->vertData, 0,
>> dm->numVertData, dm->numVertData);
>> CustomData_copy_data(

[Bf-committers] rpm's and debs

[Michael Fox]

with a release on us, are we going to release a .deb and .rpm for this 
and furthur releases?
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Updated BMesh Merge Proposal

[Michael Fox]

On 01/12/11 11:26, Campbell Barton wrote:
> As discussed last meeting, heres an updated bmesh merge proposal,
>
> http://wiki.blender.org/index.php/User:Ideasman42/BMeshMergeProposal
>
>
>
> Main issues I'd like feedback on are...
>
> - Aim for 2.63 release.
>
> - Who is able to help with testing, running regression tests etc.
>
> - Can admin's agree on suggested level of functionality - key features
> working, some specific tool/modifier options can be left as TODO.
>(this is tricky since everyone has different ides of key features,
> but we can draw a line somewhere)
>
>
> Anything I miss?
>
I fully agree with this proposal especially compatibility, because of 
sites like blendswap and blenderartists, if people start posting models 
all over the place with bmesh, and someone who has not updated will be 
in for a shock, not to mention debian and ubuntu are always a few 
releases behind, so at least some compatibility would be wise.

however 1 thing does spring to mind, mango sprint which if my maths is 
correct, it will be 2.63, and when 2.64 rolls around, mango will be in 
full swing, so something needs to be coordinated in that respect
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Delta Scale (patch to multiply rather then add).

[Michael Fox]

ok sorry i was mistaken

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

Re: [Bf-committers] Delta Scale (patch to multiply rather then add).

[Michael Fox]

ummm yeah, delta loc adds, delta rotation adds, so logically and 
intuitively, delta scale should add,

multiplying is just going cause issues, when you scale something in the 
UI, then it changes when you playback,

  adding scale is more intuitive when animating, so you don't constantly 
fret over what you are actually keying and that key is going to behave 
properly when I playback

ass for the bug, delta scale when its being calculated just needs to 
subtract by 1 that was scale of 1+0=1, changing it to multiply is just 
too severe and heavy handed


On 28/11/11 05:20, Campbell Barton wrote:
> This bug report highlights that delta scaling is adding rather then
> scaling the objects scale.
>
> https://projects.blender.org/tracker/index.php?func=detail&aid=29111&group_id=9&atid=498
>
> I've attached a patch which changes delta-scale to multiply to scale
> which IMHO is much more logical,
> incidentally do_displacement() in convertblender.c is already treating
> dsize as a multiplier which is odd.
>
> The patch attached to the bug report updates existing files with 2 caveats.
> - animated dsize wont be converted.
> - objects scaled to 0.0, with a non-zero delta scale can't be
> converted, think this is really an obscure case though.
>
> Would this be acceptable to apply before 2.61?
>

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

[Bf-committers] Proposal: Keymaps saving

[Michael Fox]

Currently im seeing alot of issues with keymap saving, i propose that 
the key map is not saved in the .blend as that causes no end of issues,

So i am suggesting a seperate save keymap button which will export the 
current keymap and save it in the .blender folder and will be loaded on 
blender start. However i would like to add a flag to the key map item 
which is SAVE_IN_BLEND that way py operators and rigging setups can have 
their keymaps in the .blend for studio productions

This way every user has their own keymap and will not be passed around 
in .blends (unless specified) avoiding confusion amoungst users
___
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 [41723] trunk/blender: Dynamic Paint merge :

[Michael Fox]

On 10/11/11 21:24, Miika Hamalainen wrote:
> Revision: 41723
>
> http://projects.blender.org/scm/viewvc.php?view=rev&root=bf-blender&revision=41723
> Author:   miikah
> Date: 2011-11-10 10:24:34 + (Thu, 10 Nov 2011)
> Log Message:
> ---
> Dynamic Paint merge:
> Commit Dynamic Paint from "soc-2011-carrot" branch into trunk.
>
> End-user documentation:
> http://wiki.blender.org/index.php/Doc:2.6/Manual/Modifiers/Simulation/Dynamic_Paint
>
> GSoC wiki page:
> http://wiki.blender.org/index.php/User:MiikaH/GSoC-2011-DynamicPaint
>

would also like to add a short the BF can use at whim showing what 
dynamic paint can do in a creative sense|| for those who don't know what 
it really is

http://vimeo.com/30408572

hi-res
http://mfoxdogg.com/works/lets_paint/Lets_Paint_2011.avi

*END shamless plug*

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

Re: [Bf-committers] Blender developer IRC meeting, nov 6 2011

[Michael Fox]

3) Dynamic Paint

>> I can only find:
>> http://wiki.blender.org/index.php/User:MiikaH/GSoC-2011-DynamicPaint-BasicsGuide
>>
>> Is it complete? If not, how much work does it need to be final?
>>

  yes it is complete, docs may need some work
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] New Alembic support branch

[Michael Fox]

I have to say this is very impressive, thank you so much for starting to 
work on this, alembic *IS* a very important file type, and is indeed 
very compact and efficient, if you are going to do a new modifier, 
please make it invisable in the list and only appear when you import 
something, and have its settings in the modifier (if any) also i don't 
think pydrivers are supported yet
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Blender Release cycle proposal

[Michael Fox]

On 20/08/11 00:16, Ton Roosendaal wrote:
> Hi all,
>
> Trying to incorporate all reviews&  crits, here's a summary of where
> we can head to:
>
> 1) What we agree on (strict :)
>
> - Trunk is by definition stable and usable
> - Branches&  patches only get applied to trunk when stable&  finished
> &  documented sufficiently.
> (within the specs module owners defined)
> - No branch/patch should get rushed in by only popular demand.
> - No release happens with regressions compared to previous release(s)
> (with exception what announced/agreed on)
> - For each release, we define as early as possible the targets
> (mergers, patches, etc) and timeline
> - We release as often as possible
>
>
> 2) What we keep free:
>
> - Module owners/teams can define what goes to trunk (stable features&
> fixes) and what should be branch development.
> - Release cycle target is 2 months, but should not frustrate quality
> or running projects. If not practical, the cycle can get extended as
> much as needed, preferably not more than a month though.
> - Patch/branch developers are expected to seek themselves active help
> and involvement to get things approved.
>
>
> 3) Love for everyone!
>
> - BF/BI team assists on reviews, but we'd need many more devs to help
> with it.
> - Get artist-buddies for coders
> - Involve stakeholders better.
> - Decision tree: always strive for consensis, starting at lowest level
> (everyone here), if not possible then module owner/teams, then bf-
> blender project admins. I'll act when no agreement can be reached.
>
>
> A graphic with the cycle: (summarizes most of Thomas' wiki page)
> http://www.blender.org/bf/blencon.jpg
>
> 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
Ok i like this one, only thing i don't get, can branches be made any 
time during the cycle but only merged at the start of the cycle, if 
thats the case i like that :)
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Blender Release Cycle

[Michael Fox]

> Reply to 2 points...
>
> - Blender bug tracker has more bugs because more people are testing
> blender!, many bugs that are fixed are not reported so infact the
> number of bugs in the tracker should be much higher, and 6months back
> should have been 100's more then it was.
>
> - Regarding "not calling bugs show-stoppers belittling users reports",
> and that _any_ bug could be a showstopper eeeh,
> well yes - of course any bug can be a showstopper but the line has to
> drawn somewhere, else we just end up in release paralysis, I think it
> should be enough that we try fix bugs when we find time, holding back
> a release means users who stick to stable builds are not getting the
> fixes we HAVE done, think we just have to try use our best judgment
> here.
>
Sorry my mail was completly out of line, had a long talk with Dingto, 
Bassam, antont, jesterking, mougri and others in irc and i generally 
calmed down, and compromised, with saying having a 12 week cycles 
instead of 8 as that was my my fear is 8 weeks is too short and we will 
make silly mistakes in order to get release, 12 weeks allows for some 
breathing room for us who like to take their time and incase things go 
very wrong, no one is perfect
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Blender Release Cycle

[Michael Fox]

> Michael, its not that you are ignored but can you give some examples
> of why this is bad
does the bug tracker give any clues, or how about the fact each release 
of 2.5 since we have taking this approach is getting worse and worse, i 
have lost count of how many times i have been helping someone for almost 
an hour on irc and turns out its a bug and being absolutely gutted by 
it, and the number times this happens
> , the last few releases we did kept quite close to 8
> weeks and I think it worked well for us
and in your binded state did you happen to notice the droves of users 
and developers leaving because of this stupid practise, Blender is 
increadbly important to 1000's of people, and when you start saying 'oh 
this bug is not a show stopper' you start belittling the 
users/developers and start making blender a developers tool not an 
artists tool as who can say what is and isn't a workflow/show stopper 
bug, it may not be for you but it is a big one for someone else hence 
why they reported it.
> , and helps keep developers on
> track with stabilizing frequently,
ok then how come we have over 200 registered bugs where each release we 
have had < 50 or <20 registered bugs, and numerous 'fix for fix #4545' 
commits and blender is suffering a great deal here. This practise is an 
illusion of greatness because of its adoption by ff and chrome but they 
are web browsers in a rapidly changing market great care really dosn't 
need to be taken, but for us people's lives depend on us where great 
care is required.
In CG you need to take your time, make it adaptive as possible, make it 
as clean as possible,make it fit into the paradig of the B2.5 arch, and 
make sure the fix truly is a fix otherwise its the users who suffer. I 
propose we go back to the bi-annual release with the 1 month of bug 
hunting before release, this way we can take our time, and make sure of 
everything and once again deliver fantatic product called blender, not 
the junk thats 2.57 and 2.59.

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

Re: [Bf-committers] Blender Release Cycle

[Michael Fox]

On 16/08/11 14:55, Campbell Barton wrote:
> On Tue, Aug 16, 2011 at 7:52 AM, Michael Fox  wrote:
>> On 15/08/11 22:40, Sergey I. Sharybin wrote:
>>> Hi, devs!
>>>
>>> We've already got thread about release cycles, but it was a bit long and
>>> seems like there's no final decision made. We've discussed that proposal
>>> with Campbell and also investigated why we've run into some problems
>>> with current release. There are some comments which i'd prefer be final
>>> decision about our release cycle (most people are already ok with it,
>>> just to make things 100% clear).
>>>
>>> Few first weeks of cycle (B-Con 1 and B-Con 2) aren't so critical for
>>> this discussion and we've already agreed with this levels.
>>>
>>> More critical to make work clear in few weeks (1-2) before release (i
>>> mean before starting commiting new splash/changelogs and so). What is
>>> needed there:
>>>
>>> - Only _critical_ bugs should be fixed. Critical doesn't mean "i can
>>> make blender crash in few clicks" but it mostly means this bug was
>>> introduced in current cycle and it stops normal workflow. If this bug
>>> was present in previous release or if it's not making general usage
>>> unusable we'd prefer to keep this bug untouched. Fixing such bugs
>>> wouldn't make real sense on general workflow and if it wasn't noticed in
>>> previous release then it doesn't annoy artists. But fixing such bugs
>>> easily produces new bugs which difficult to predict and we wouldn't have
>>> enough time to test everything.
>>>
>>> - We need clear "FREEZE" and "UNFREEZE" AHOYs. If freezing will happen a
>>> bit earlier -- it's not so critical. But unfreezing should be done quite
>>> accurate -- when everybody who is familiar with making release would say
>>> it's ok to unfreeze.
>>>
>>> - We'll need tag for every release. It should be created even for
>>> "initial" release (not corrective release like 'a' or 'b' releases).
>>> this is needed to make platform maintainers' life more clear. If stopper
>>> is discovered during archive preparation, fix for this stopper can be
>>> easily commited to trunk and merged to tag. It'll help a lot for release
>>> process when most of core/BF developers are offline -- no need to wait
>>> someone to prepare archive.
>>>
>>> - Most probably we'll need guy who is familiar with svn who will make
>>> tag and solve possible issues of platform maintainers. It shouldn't be
>>> "constantly" defined developer, prefer to choose one for each release --
>>> it's needed to be sure he can be available during release.
>>>
>>> - So, FREEZE happens, new tag is creating and AHOY could happen. Day or
>>> two after this normal life of trunk could be restored. But _nobody_
>>> should commit anything than fixes for stopper/fixes for build
>>> environment until _official_ unfreeze. Even commit of stylefix could be
>>> confusing in the future (if more serious problem was discovered, i.e.).
>>>
>>> - If 'a' release is needed, we shouldn't re-tag. We should merge fixes
>>> for _stoppers only_ into tag and do not include fixes for all bugs which
>>> were made since release. This is a way to avoid 'b' releases.
>>>
>>> So, short summary: fix only _really_ critical bugs last week before
>>> release-related commits; make clear FREEZE/UNFREEZE messages in ML.
>>> create tag for release just before AHOY, if 'a' release is needed only
>>> stoppers for previous release (for which 'a' is creating) should be
>>> ported into tag.
>>>
>>> I hope only Campbell/Ton/Brecht make minor changes to this message or
>>> write things i've forgot to tell about. But again. i don't want this
>>> message start new discussion thread and i hope it'll be final decision now.
>>>
>> I thought this is what we already do, its just in the 2.5 series we have
>> become very lazy in these regards, now that 2.5 is final and stable, we
>> should really adopt our old methodology again with no set freeze period,
>> we aim for a date and set freeze a few days before it, and only release
>> if the code is deemed releasable
> This goes against the fixed 8 week release cycle, "release when its
> ready" might sound goo

Re: [Bf-committers] Blender Release Cycle

[Michael Fox]

On 15/08/11 22:40, Sergey I. Sharybin wrote:
> Hi, devs!
>
> We've already got thread about release cycles, but it was a bit long and
> seems like there's no final decision made. We've discussed that proposal
> with Campbell and also investigated why we've run into some problems
> with current release. There are some comments which i'd prefer be final
> decision about our release cycle (most people are already ok with it,
> just to make things 100% clear).
>
> Few first weeks of cycle (B-Con 1 and B-Con 2) aren't so critical for
> this discussion and we've already agreed with this levels.
>
> More critical to make work clear in few weeks (1-2) before release (i
> mean before starting commiting new splash/changelogs and so). What is
> needed there:
>
> - Only _critical_ bugs should be fixed. Critical doesn't mean "i can
> make blender crash in few clicks" but it mostly means this bug was
> introduced in current cycle and it stops normal workflow. If this bug
> was present in previous release or if it's not making general usage
> unusable we'd prefer to keep this bug untouched. Fixing such bugs
> wouldn't make real sense on general workflow and if it wasn't noticed in
> previous release then it doesn't annoy artists. But fixing such bugs
> easily produces new bugs which difficult to predict and we wouldn't have
> enough time to test everything.
>
> - We need clear "FREEZE" and "UNFREEZE" AHOYs. If freezing will happen a
> bit earlier -- it's not so critical. But unfreezing should be done quite
> accurate -- when everybody who is familiar with making release would say
> it's ok to unfreeze.
>
> - We'll need tag for every release. It should be created even for
> "initial" release (not corrective release like 'a' or 'b' releases).
> this is needed to make platform maintainers' life more clear. If stopper
> is discovered during archive preparation, fix for this stopper can be
> easily commited to trunk and merged to tag. It'll help a lot for release
> process when most of core/BF developers are offline -- no need to wait
> someone to prepare archive.
>
> - Most probably we'll need guy who is familiar with svn who will make
> tag and solve possible issues of platform maintainers. It shouldn't be
> "constantly" defined developer, prefer to choose one for each release --
> it's needed to be sure he can be available during release.
>
> - So, FREEZE happens, new tag is creating and AHOY could happen. Day or
> two after this normal life of trunk could be restored. But _nobody_
> should commit anything than fixes for stopper/fixes for build
> environment until _official_ unfreeze. Even commit of stylefix could be
> confusing in the future (if more serious problem was discovered, i.e.).
>
> - If 'a' release is needed, we shouldn't re-tag. We should merge fixes
> for _stoppers only_ into tag and do not include fixes for all bugs which
> were made since release. This is a way to avoid 'b' releases.
>
> So, short summary: fix only _really_ critical bugs last week before
> release-related commits; make clear FREEZE/UNFREEZE messages in ML.
> create tag for release just before AHOY, if 'a' release is needed only
> stoppers for previous release (for which 'a' is creating) should be
> ported into tag.
>
> I hope only Campbell/Ton/Brecht make minor changes to this message or
> write things i've forgot to tell about. But again. i don't want this
> message start new discussion thread and i hope it'll be final decision now.
>
I thought this is what we already do, its just in the 2.5 series we have 
become very lazy in these regards, now that 2.5 is final and stable, we 
should really adopt our old methodology again with no set freeze period, 
we aim for a date and set freeze a few days before it, and only release 
if the code is deemed releasable
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Blender Release Cycle

[Michael Fox]

On 15/08/11 22:40, Sergey I. Sharybin wrote:
> Hi, devs!
>
> We've already got thread about release cycles, but it was a bit long and
> seems like there's no final decision made. We've discussed that proposal
> with Campbell and also investigated why we've run into some problems
> with current release. There are some comments which i'd prefer be final
> decision about our release cycle (most people are already ok with it,
> just to make things 100% clear).
>
> Few first weeks of cycle (B-Con 1 and B-Con 2) aren't so critical for
> this discussion and we've already agreed with this levels.
>
> More critical to make work clear in few weeks (1-2) before release (i
> mean before starting commiting new splash/changelogs and so). What is
> needed there:
>
> - Only _critical_ bugs should be fixed. Critical doesn't mean "i can
> make blender crash in few clicks" but it mostly means this bug was
> introduced in current cycle and it stops normal workflow. If this bug
> was present in previous release or if it's not making general usage
> unusable we'd prefer to keep this bug untouched. Fixing such bugs
> wouldn't make real sense on general workflow and if it wasn't noticed in
> previous release then it doesn't annoy artists. But fixing such bugs
> easily produces new bugs which difficult to predict and we wouldn't have
> enough time to test everything.
>
> - We need clear "FREEZE" and "UNFREEZE" AHOYs. If freezing will happen a
> bit earlier -- it's not so critical. But unfreezing should be done quite
> accurate -- when everybody who is familiar with making release would say
> it's ok to unfreeze.
>
> - We'll need tag for every release. It should be created even for
> "initial" release (not corrective release like 'a' or 'b' releases).
> this is needed to make platform maintainers' life more clear. If stopper
> is discovered during archive preparation, fix for this stopper can be
> easily commited to trunk and merged to tag. It'll help a lot for release
> process when most of core/BF developers are offline -- no need to wait
> someone to prepare archive.
>
> - Most probably we'll need guy who is familiar with svn who will make
> tag and solve possible issues of platform maintainers. It shouldn't be
> "constantly" defined developer, prefer to choose one for each release --
> it's needed to be sure he can be available during release.
>
> - So, FREEZE happens, new tag is creating and AHOY could happen. Day or
> two after this normal life of trunk could be restored. But _nobody_
> should commit anything than fixes for stopper/fixes for build
> environment until _official_ unfreeze. Even commit of stylefix could be
> confusing in the future (if more serious problem was discovered, i.e.).
>
> - If 'a' release is needed, we shouldn't re-tag. We should merge fixes
> for _stoppers only_ into tag and do not include fixes for all bugs which
> were made since release. This is a way to avoid 'b' releases.
>
> So, short summary: fix only _really_ critical bugs last week before
> release-related commits; make clear FREEZE/UNFREEZE messages in ML.
> create tag for release just before AHOY, if 'a' release is needed only
> stoppers for previous release (for which 'a' is creating) should be
> ported into tag.
>
> I hope only Campbell/Ton/Brecht make minor changes to this message or
> write things i've forgot to tell about. But again. i don't want this
> message start new discussion thread and i hope it'll be final decision now.
>
I thought this is what we already do, its just in the 2.5 series we have 
become very lazy in these regards, now that 2.5 is final and stale, we 
should really adopt our old methodology again with no set freeze period, 
we aim for a date and set freeze a few days before it, and only release 
if the code is deemed releasable
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Blender developer irc meeting, 14 august 2011

[michael fox]

oh and almost forgot the freestyle branch i think its ready to be merged
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Blender developer irc meeting, 14 august 2011

[michael fox]

> - Branches mentioned that could get included for next release:
>   - Joshua Leung's work on animation system
>   - Benjamin Cook's work on motion capture input
>   - Joerg Mueller's audio/speaker work
> Will get further reviewed or decided next week.
>

I would also like to add dynamic paint (carrot branch) to that list
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Windows 2000 build please.

[Michael Fox]

On 15/07/11 11:16, Blankfirstname Blanklastname wrote:
> I'm saddened that a lot of work is done for Blender to work on BSD,
> Linux, MAC and XP but in the process you developers left us Windows 2000 
> users out in the cold.
we cannot help it that we cannot build for win2k. Blender's internals 
are not compatible with the win2k system
> There is NOTHING WRONG with Windows 2000 and
> conceivably there's not anything you can't do on XP that can't be done
> on Windows 2000.

You Couldn't be furthur from the truth, comparing win2k and XP is like 
comparing apples and oranges, they are vastly different internally, 
win2k is 16bit OS winXP in 32Bit, with different calls to different 
systems, may seem the same on the surface but underneith where we work, 
is 2 different worlds. Hence support for win2k was dropped

>Blender is suppose to be open and free and with this
> one snafu, Blender is no longer open and free.
yes blender is still free and open, but the doesn’t mean we are obliged 
to cater for everyone, the source is available, you are more then 
welcome to get your own builds going, and there is a whole community 
that could lend a hand

>I nor others can run a 2.58 build on our systems because of this upgrade.  
> Please build a Windows 2000 Optimized 32 bit.  Thanks.
No we will not. we will not be abused or insulted to be you or any one's 
slaves we are people, volunteers, thank your lucky stars and be grateful 
that blender even exists

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

Re: [Bf-committers] splitting (off) hair

[michael fox]

I think we can get great hair without particles, using the physbam physics
library
http://physbam.stanford.edu/

and
http://physbam.stanford.edu/~mlentine/research.html which provides the best
results have ever seen (last paper)

granted it will take a bit of work but most of the legwork has already been
done, just some polish and cleaning and it will be fine


On Sat, Jul 2, 2011 at 1:00 AM, Daniel Salazar - 3Developer.com <
zan...@gmail.com> wrote:

> I want to donate for Node Particles! with a strong particle system
> like what lukas is doing we can easilly do a card system for hair in
> the meantime. Don't let crappy features slow you down lukas! node tree
> particles and modifiers are extremely important
>
> Daniel Salazar
> 3Developer.com
>
>
>
> On Fri, Jul 1, 2011 at 8:57 AM, pete larabell 
> wrote:
> > phony I can say I and others I know would also donate if you can write it
> up.
> >
> > On Fri, Jul 1, 2011 at 7:41 AM, Jonathan Williamson
> >  wrote:
> >> If a system such as the ones Fancois T. just posted and has posted
> before were to be implemented I would absolutely donate. I can also make
> sure the campaign is heavily featured on Blender Artists and give it an ad
> spot on Blender Cookie.
> >>
> >> --
> >> Jonathan Williamson
> >>
> >> Instructor - http://www.blendercookie.com (
> http://www.blendercookie.com/)
> >> Personal Trainer - http://www.mavenseed.com (http://www.mavenseed.com/)
> >> Portfolio - http://www.jw3d.com (http://www.jw3d.com/)
> >>
> >>
> >> On Friday, July 1, 2011 at 5:23 AM, François T. wrote:
> >>
> >>> and I'll drop those links one more time, since I would donate for this,
> and
> >>> I bet would not be the only one
> >>>
> >>>
> >>> *Super-Helices for Predicting the Dynamics of Natural Hair*
> >>>
> >>>  - video :
> >>> http://www.lmm.jussieu.fr/~audoly/research/hair06/HairDVDVideoQT.html
> >>>  - paper :
> >>>
> http://www.lmm.jussieu.fr/~audoly/research/hair06/BA_hair_siggraph06.pdf
> >>>
> >>>
> >>> *Predicting Natural Hair Shapes by Solving the Statics of Flexible
> Rods*
> >>>
> >>>  - paper :
> >>>
> http://www-evasion.imag.fr/Publications/2005/BAQLLC05/BertailsElectronicFinalEG.pdf
> >>>  - publication :
> http://www-evasion.imag.fr/Publications/2005/BAQLLC05/
> >>>  - video 1 :
> >>>
> http://www-evasion.imag.fr/Publications/2005/BAQLLC05/astaticStrandEG05.mpg
> >>>  - video 2 :
> >>>
> http://www-evasion.imag.fr/Publications/2005/BAQLLC05/fullModellingEG05.mpg
> >>>
> >>>
> >>>  - Basile’s Website : http://www.lmm.jussieu.fr/~audoly/
> >>>
> >>>
> >>>
> >>>
> >>> 2011/7/1 Christopher Cherrett  ccherr...@openoctave.org)>
> >>>
> >>> >  Original Message 
> >>> > Subject: Re: [Bf-committers] splitting (off) hair
> >>> > From: Lukas Tönne  lukas.toe...@googlemail.com)>
> >>> > To: bf-blender developers  bf-committers@blender.org)>
> >>> > Date: 07/01/2011 01:54 AM
> >>> > > I'm sorry people, i have given up on hair systems :(
> >>> > > My primary intention was to get the hair code out of the way of
> >>> > > particle development, so i can finish paged buffer implementation
> and
> >>> > > then continue working on nodes. As it turns out, separating hair
> code
> >>> > > from particle code is just as much work, if not more, than writing
> it
> >>> > > from scratch. After all i'm a volunteer like most other coders
> here,
> >>> > > so as long as nobody pays me for this, i'm not going to waste my
> time
> >>> > > on it.
> >>> > >
> >>> > > This means that hair will be either broken or completely missing
> from
> >>> > > paged particles. Whether or not the new dynamic buffers will make
> it
> >>> > > into trunk will therefore depend on
> >>> > >
> >>> > > a) dropping hair support officially (unlikely)
> >>> > > b) finding somebody to voluntarily "fix" the hair systems (i.e.
> make
> >>> > > it work somehow) or code a new hair system (the latter would be
> much
> >>> > > preferred, but takes time)
> >>> > > c) raising enough money to get b) done
> >>> > >
> >>> > > Again, i'm sorry, but it looks like you will have to live with
> crappy
> >>> > > particles - or use my branch and accept that there is no (more or
> >>> > > less) working hair system.
> >>> > > ___
> >>> > > Bf-committers mailing list
> >>> > > Bf-committers@blender.org (mailto:Bf-committers@blender.org)
> >>> > > http://lists.blender.org/mailman/listinfo/bf-committers
> >>> > Why not write up a proposal with some objectives and clearly defined
> >>> > prices to implement it yourself.
> >>> >
> >>> > Then the community can start to fund raise for it.
> >>> >
> >>> > Thanks!
> >>> >
> >>> > --
> >>> > Christopher Cherrett
> >>> > ccherr...@openoctave.org (mailto:ccherr...@openoctave.org)
> >>> > http://www.openoctave.org
> >>> >
> >>> > ___
> >>> > Bf-committers mailing list
> >>> > Bf-committers@blender.org (mailto:Bf-committers@blender.org)
> >>> > http://lists.blender.org/mailman/listinfo/bf-committer

Re: [Bf-committers] Substituting hot keys in an addon

[Michael Fox]

On 16/06/11 06:46, Nathan Vegdahl wrote:
> Hello all,
> I am wondering if there is a best practice for substituting hotkeys
> via an addon.
>
> The use-case is that in Rigify I would like to allow the user to
> add rig-type samples via shift-A in armature edit mode.  Doing so will
> require popping up a menu of some kind.  However, currently shift-A in
> armature edit mode does not produce a menu, and instead immediately
> calls the bone_primitive_add operator, so I cannot simply insert items
> into the non-existent menu.
>
> What I would like to do is substitute in a menu when the Rigify
> addon is enabled.  I am curious if there is an accepted best-practice
> way to do this, that is robust against custom keymaps, for example,
> and other corner-cases.  Should I just search the active keymap for
> the bone_primitive_add operator, and substitute in my own?  That seems
> like it could potentially cause problems.
>
> Alternatively I could make vanilla Blender produce a menu, and then
> simply insert my own items into the menu when rigify is enabled.
> Would that be a better way to go about it?
>
> --Nathan
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
why don't you look at how dynamic spacebar addon does it

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

Re: [Bf-committers] Patch: Adaptive time step for fluid particles

[michael fox]

I have done a little test using this already
http://vimeo.com/24544354

and yes if you keep the same value the results are predictable and
consistant

On Tue, Jun 7, 2011 at 12:13 PM, Matt Ebb  wrote:

> What he means is that if you run two sims with the exact same settings,
> will
> the results be exactly the same? This is pretty important.
>
> cheers
>
> Matt
>
>
> On Tue, Jun 7, 2011 at 12:05 PM, Alex Fraser  wrote:
>
> > - Original Message -
> > > From: "Shaul Kedem" 
> > > No, I mean is it deterministic?
> >
> > >From one run to the next, yes, you should get the same result.
> >
> > In terms of being predictable, I did some tests with the TwoPipe demo, in
> > which water drains through a hole (you may need to increase the fluid
> > interaction radius to see this effect). With zero subframes, it takes a
> long
> > time to drain; with more subframes, it tends to take less time (time in
> > frames, not computation time). However, it starts to converge for
> subframes
> > > 3 or a Courant target < 0.2, and barely changes beyond subframes = 8 or
> > Courant target = 0.1. So it seems to become more accurate with smaller
> time
> > steps, but you should rarely need to go beyond those values.
> >
> > The adaptive subframe code gives a stronger guarantee that your
> simulation
> > will be stable, but it's not predictive, so for some simulations a
> constant
> > time step is still more appropriate.
> >
> > Cheers,
> > Alex
> >
> > --
> > Alex Fraser
> > Software Engineer
> > The Victorian Partnership for Advanced Computing
> > ___
> > 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 [36779] trunk/blender/source/blender/ blenkernel/intern/fcurve.c: modify fcurve evaluation for bool/enum/ int values.

[Michael Fox]

Campbell you have gone too far this time, you are not an animator and 
have no businesss fiddling in there, return it bat to the way it was, 
which is how it was designed, it was no where near unituitive before, if 
anything add an option to the curves of rounding value/settings, give 
use some control over it

On 21/05/11 03:12, Dan Eicher wrote:
> On Thu, May 19, 2011 at 5:34 PM, Matt Ebb  wrote:
>> On Fri, May 20, 2011 at 10:17 AM, Campbell Bartonwrote:
>>
>>> Aligorith and I discussed this before committing, and are aware of the
>>> implications.
>>>
>>> To me if you are editing floats, but have them converted to ints later
>>> it makes most sense (on a user level), to round them. If the GUI makes
>>> it unintuitive then it should be made intuitive (grid lines when
>>> zoomed in for example), if you want I can add this.
>>>
>> Rounding them to whole numbers, sure, I totally agree, and if floor() works
>> better then I'm all for it. But when animating bool values it makes perfect
>> sense that as soon as your curve crosses from 0 to 1 (not 0 to 0.5), the
>> value is switched on. Same goes for integer values, animating my curve from
>> 4.0 to 4.51 should not switch the value to 5.
>>
>> cheers
>>
>> Matt
>> ___
>> Bf-committers mailing list
>> Bf-committers@blender.org
>> http://lists.blender.org/mailman/listinfo/bf-committers
>>
> I totally agree,<  1 == false and>= 1 == true is how I always thought
> it worked.
>
> Dan
> ___
> 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] Camera view navigation rant

[Michael Fox]

My only critique is that i use the mousewheel to zoom in and out of the 
currecnt view to get a better view of the scene through the camera, 
however with this patch and camera locked mousewheel now moves the 
camera, so blender left the camera move in only using ctrl-mmb
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Camera Guides

[Michael Fox]

ok i will stop now, thank you all

On 06/05/11 07:33, Campbell Barton wrote:
> On Thu, 2011-05-05 at 20:03 +1000, Michael Fox wrote:
>> In the past few days i have been working on adding guides to the camera
>> object, to be used for perspective and eye line tracking  as well as
>> composition guides (rule of thirds, etc etc) ,  now granted there is
>> patches available to do this but they are all hardcoded and don't allow
>> for much in the way of adjustment or precision, and certainly not
>> elegant or integrated well.
>>
>> However there has been concerns over this feature is really necessary,
>> like people should use BG images or Grease pencil, really slapdash stuff
>> and that custom guides are not needed nor should be developed, so I
>> would like to ask, do I continue on this project, or call it a day and
>> let the patch pass around the community because I do not want to keep
>> going if it is deemed of little or no interest or need.
>>
>> the Patch
>> http://mfoxdogg.com/development/cam_guides.txt
>>
>> Pros.
>>   -uses SDNA/RNA
>>   -fully accessible via python
>>   -update real-time
>>   -both ends of each guide are independent and can be put anywhere in
>> the area of the camera
>>   -has a transparency value
>>   -position values are percentages of the camera area so no need to
>> redraw guides if resolution or camera scale change
>>   - due to accessibility of python, a preset system could be
>> developed for this
>>   - guides are saved in the file
>> Cons
>>   -only exist in camera view
>>   -only a dashed line and no colour support at this time
>>
>> The patch has a few issues
>>   - need a way to clear memory made where the guide is made
>>   -due to this files saved with guides will crash
>>   -the remove guide button does not work, for some reason
>>   -only very basic UI has been developed
>>   -no documentation at this time
>>
>> Now please don't view this as me sulking and being a primadonna its just
>> i have very little time these days and havn't developed anything for a
>> while, there is not design docs for the object colour rules system yet
>> so i took on this challenge, which has been in the back of my mind for a
>> long time.
>>
>> Thank you for your time
>>   Michael B. Fox
>> ___
>> Bf-committers mailing list
>> Bf-committers@blender.org
>> http://lists.blender.org/mailman/listinfo/bf-committers
> It seems to me that this is spending energy on a feature which is mainly
> useful in corner cases, while grease pencil isn't perfect, I think with
> some minor tweaks it can work very well.
>
> Suggest to do this instead:
> * Add generic overlay presets like golden rule, center, diagonal lines?
> There could be 3-6 of these that can work like existing tile safe.
>
> * Rather then adding new code, use grease pencil for this feature, the
> only change needed is show a cameras grease pencil while in the camera
> view - irrespective of selection.
>
> * Modify the SVG importer to optionally load paths into grease pencil or
> import SVG and convert curves to grease pencil internally.
>
> --- (end implementation details)
>
> For users this can be made as simple as a button in camera panel:
> "Load SVG to Camera Grease Pencil".
>
> This avoids adding DNA, rna api, editing tools etc.
> If people really like to make some detailed camera overlay that cant be
> drawn by hand in grease pencil they can use inkscape and import it.
>
>
>
> ___
> 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] Camera Guides

[Michael Fox]

In the past few days i have been working on adding guides to the camera 
object, to be used for perspective and eye line tracking  as well as 
composition guides (rule of thirds, etc etc) ,  now granted there is 
patches available to do this but they are all hardcoded and don't allow 
for much in the way of adjustment or precision, and certainly not 
elegant or integrated well.

However there has been concerns over this feature is really necessary, 
like people should use BG images or Grease pencil, really slapdash stuff 
and that custom guides are not needed nor should be developed, so I 
would like to ask, do I continue on this project, or call it a day and 
let the patch pass around the community because I do not want to keep 
going if it is deemed of little or no interest or need.

the Patch
http://mfoxdogg.com/development/cam_guides.txt

Pros.
 -uses SDNA/RNA
 -fully accessible via python
 -update real-time
 -both ends of each guide are independent and can be put anywhere in 
the area of the camera
 -has a transparency value
 -position values are percentages of the camera area so no need to 
redraw guides if resolution or camera scale change
 - due to accessibility of python, a preset system could be 
developed for this
 - guides are saved in the file
Cons
 -only exist in camera view
 -only a dashed line and no colour support at this time

The patch has a few issues
 - need a way to clear memory made where the guide is made
 -due to this files saved with guides will crash
 -the remove guide button does not work, for some reason
 -only very basic UI has been developed
 -no documentation at this time

Now please don't view this as me sulking and being a primadonna its just 
i have very little time these days and havn't developed anything for a 
while, there is not design docs for the object colour rules system yet 
so i took on this challenge, which has been in the back of my mind for a 
long time.

Thank you for your time
 Michael B. Fox
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] cycle todo list

[Michael Fox]

Use ccmake as with it you can set the paths of your includes


On 30/04/11 15:27, Daniel Salazar - 3Developer.com wrote:
> make fails in latest OpenSuSE 11.4 with this
>
> [ 31%] Building C object
> source/blender/imbuf/CMakeFiles/bf_imbuf.dir/intern/jp2.c.o
> /home/zanqdo/Storage/Blender/blender-cycles/blender/source/blender/imbuf/intern/jp2.c:43:22:
> fatal error: openjpeg.h: No such file or directory
> compilation terminated.
> make[2]: *** [source/blender/imbuf/CMakeFiles/bf_imbuf.dir/intern/jp2.c.o]
> Error 1
> make[1]: *** [source/blender/imbuf/CMakeFiles/bf_imbuf.dir/all] Error 2
> make: *** [all] Error 2
>
> In my system that header file is located here:
>
> usr/include/openjpeg.h
>
> somehow cmake isn't finding it?
>
> cheers
>
> Daniel Salazar
> 3Developer.com
>
>
>
> On Fri, Apr 29, 2011 at 11:09 AM, Paul Melis  wrote:
>> Hi,
>>
>> On 04/28/11 12:28, Brecht Van Lommel wrote:
>>> Actually, anything on this list is open to be implemented by others.
>>> > From the point of view of the core engine, if implemented well they
>>> can fit in right away. I guess the first ones go from a couple of days
>>> to a week, once you are familiar with the code, the big features can
>>> take from a week to multiple months. It's quite hard to say, but if
>>> someone is interested, they can of course contact me, and I can give
>>> some pointers on how to go about implementing things.
>>>
>>> For me personally, integration, stability, performance, will likely
>>> take up most of the time for now.
>> How should we report build problems found? Here on the list?
>>
>> If so, on a Gentoo 32-bit Linux system with GCC 4.4.5 I get:
>>
>> [ 95%] Building CXX object
>> intern/cycles/util/CMakeFiles/cycles_util.dir/util_system.cpp.o
>> /home/melis/c/blender-cycles-svn/intern/cycles/util/util_system.cpp: In
>> function 'std::string ccl::system_cpu_brand_string()':
>> /home/melis/c/blender-cycles-svn/intern/cycles/util/util_system.cpp:63:
>> error: can't find a register in class 'BREG' while reloading 'asm'
>> /home/melis/c/blender-cycles-svn/intern/cycles/util/util_system.cpp:63:
>> error: can't find a register in class 'BREG' while reloading 'asm'
>> /home/melis/c/blender-cycles-svn/intern/cycles/util/util_system.cpp:63:
>> error: can't find a register in class 'BREG' while reloading 'asm'
>> /home/melis/c/blender-cycles-svn/intern/cycles/util/util_system.cpp:63:
>> error: can't find a register in class 'BREG' while reloading 'asm'
>> /home/melis/c/blender-cycles-svn/intern/cycles/util/util_system.cpp:63:
>> error: 'asm' operand has impossible constraints
>> /home/melis/c/blender-cycles-svn/intern/cycles/util/util_system.cpp:63:
>> error: 'asm' operand has impossible constraints
>> /home/melis/c/blender-cycles-svn/intern/cycles/util/util_system.cpp:63:
>> error: 'asm' operand has impossible constraints
>> /home/melis/c/blender-cycles-svn/intern/cycles/util/util_system.cpp:63:
>> error: 'asm' operand has impossible constraints
>> make[2]: ***
>> [intern/cycles/util/CMakeFiles/cycles_util.dir/util_system.cpp.o] Error 1
>> make[1]: *** [intern/cycles/util/CMakeFiles/cycles_util.dir/all] Error 2
>> make: *** [all] Error 2
>>
>> Attached a patch (untested, but it compiles) based on the stuff in
>> http://newbiz.github.com/cpp/2010/12/20/Playing-with-cpuid.html.
>>
>> Regards,
>> Paul
>>
>> ___
>> 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] Fluid particles refactoring

[Michael Fox]

i don't like how size is now being used as ui tend to use "size deflect"
with some random size which means if i increase the size, hence the
radius then the particles will float above the collision object.


On Sat, 2011-02-19 at 00:23 +0200, Janne Karhu wrote:
> I've been refactoring the fluid particles recently, and before I actually  
> start getting ready to commit this I'd like to get some feedback on my  
> current progress and ideas.
> 
> http://code.blender.org/index.php/2011/02/particle-fluids-refactoring-under-way/
> 
> And yes I do know that this will break old simulations, and that you book  
> writers have to do some pages all over again, but my sincere intention is  
> a better user experience with the particle fluids, so please forgive me.
> 
> I'll gladly read and respond to feedback either here or in the post  
> comments!
> 
> janne
> ___
> 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 [34914] trunk/blender/release/scripts/ui/ properties_material.py: Commit patch [#25939] material panel proposal by Ervin Weber (lu

[Michael Fox]

This goes against all of the 2.5 UI design principles and pardigms and
show be removed or onlt be visible when needed, as its a clear case of
craming chikens into a basket, a big ugly mess

On that note it seems the design principles and paradigms that was set
when 2.5 was being desinged seem to have been trown out the window, its
a bloody mess, didn't parts behave differently share same info
differently, the UI of 2.5 is really getting more and more like 2.49 its
not funny, please can we get back on track instead of tacking on UI
elements like in the 2.4 series


On Wed, 2011-02-16 at 19:39 +, Thomas Dinges wrote:
> Revision: 34914
>   
> http://projects.blender.org/scm/viewvc.php?view=rev&root=bf-blender&revision=34914
> Author:   dingto
> Date: 2011-02-16 19:39:45 + (Wed, 16 Feb 2011)
> Log Message:
> ---
> Commit patch [#25939] material panel proposal by Ervin Weber (lusque). Thanks!
> 
> >From the patch description:
> "A new panel is proposed to bring togheter all the properties of a material 
> that belong to the render pipeline level.
> Such properties are currently not mixable with node materials, as nodes 
> operate on a shader level."
> 
> Commiting this patch as approved in the sundy meeting. 
> 
> Modified Paths:
> --
> trunk/blender/release/scripts/ui/properties_material.py
> 
> Modified: trunk/blender/release/scripts/ui/properties_material.py
> ===
> --- trunk/blender/release/scripts/ui/properties_material.py   2011-02-16 
> 18:29:26 UTC (rev 34913)
> +++ trunk/blender/release/scripts/ui/properties_material.py   2011-02-16 
> 19:39:45 UTC (rev 34914)
> @@ -34,6 +34,16 @@
>  return None
>  
> 
> +def check_material(mat):
> +if mat is not None:
> +if mat.use_nodes:
> +if mat.active_node_material is not None:
> +return True
> +return False
> +return True
> +return False
> +
> +
>  class MATERIAL_MT_sss_presets(bpy.types.Menu):
>  bl_label = "SSS Presets"
>  preset_subdir = "sss"
> @@ -116,9 +126,16 @@
>  elif mat:
>  split.template_ID(space, "pin_id")
>  split.separator()
> -
> +
>  if mat:
>  layout.prop(mat, "type", expand=True)
> +if mat.use_nodes:
> +row = layout.row()
> +row.label(text="", icon='NODETREE')
> +if mat.active_node_material:
> +row.prop(mat.active_node_material, "name", text="")
> +else:
> +row.label(text="No material node selected")
>  
> 
>  class MATERIAL_PT_preview(MaterialButtonsPanel, bpy.types.Panel):
> @@ -129,16 +146,66 @@
>  self.layout.template_preview(context.material)
>  
> 
> +class MATERIAL_PT_pipeline(MaterialButtonsPanel, bpy.types.Panel):
> +bl_label = "Render Pipeline Options"
> +bl_options = {'DEFAULT_CLOSED'}
> +COMPAT_ENGINES = {'BLENDER_RENDER', 'BLENDER_GAME'}
> +
> +@classmethod
> +def poll(cls, context):
> +mat = context.material
> +engine = context.scene.render.engine
> +return mat and (mat.type in ('SURFACE', 'WIRE', 'VOLUME')) and 
> (engine in cls.COMPAT_ENGINES)
> +
> +def draw(self, context):
> +layout = self. layout
> +
> +mat = context.material
> +#split = layout.split()
> +mat_type =  mat.type in ('SURFACE', 'WIRE')
> +
> +row = layout.row()
> +row.active = mat_type
> +row.prop(mat, "use_transparency")
> +sub = row.column()
> +sub.prop(mat, "offset_z")
> +sub.active = mat_type and mat.use_transparency and 
> mat.transparency_method == 'Z_TRANSPARENCY'
> +
> +row = layout.row()
> +row.active = mat.use_transparency or not mat_type
> +row.prop(mat, "transparency_method", expand=True)
> +
> +layout.separator() 
> +
> +split = layout.split()
> +col = split.column()
> +
> +col.prop(mat, "use_raytrace") # 
> +col.prop(mat, "use_full_oversampling") # 
> +sub = col.column()
> +sub.active = mat_type
> +sub.prop(mat, "use_sky")
> +sub.prop(mat, "invert_z")
> +
> +col = split.column()
> +col.active = mat_type
> +
> +col.prop(mat, "use_cast_shadows_only", text="Cast Only")
> +col.prop(mat, "shadow_cast_alpha", text="Casting Alpha")
> +col.prop(mat, "use_cast_buffer_shadows")
> +col.prop(mat, "use_cast_approximate")
> +
> +
>  class MATERIAL_PT_diffuse(MaterialButtonsPanel, bpy.types.Panel):
>  bl_label = "Diffuse"
>  COMPAT_ENGINES = {'BLENDER_RENDER', 'BLENDER_GAME'}
>  
>  @classmethod
>  def poll(cls, context):
> -mat = active_node_mat(context.material)
> +mat = context.material
>  engine = context.scene.render.engi

[Bf-committers] number of commiters

[Michael Fox]

Recently i have noticed a rathur alarming trend in that its getting
extreamly easy to become a commitor, especially in bf-extensions. I was
once a position you had to earn and work hard for, now you show up with
a patch or 2, and you become a commiter. 

The result of this is causing me concern as i think the standard of code
is going fall quite drastically and blender is splintered enough as it
is, failing to follow the paradigms and rules that were developed.


is anyone else noticing this or am i just being paranoid again



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

Re: [Bf-committers] Node-able render pipeline

[Michael Fox]

http://wiki.blender.org/index.php/Dev:2.5/Source/ShadingSystem initial
steps are in the render branch


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

[Bf-committers] Text rendering

[Michael Fox]

Hi all quick question is there anyway of reinitialising the UI font's
system during runtime. 

i have been working on making text AA an optional and made it in such a
way that other options should be easy to add, however i have run into
the last hurdle, the option requires the user to save the default then
restart blender, this is not ideal, it should update as soon as the
option is changed. 

the notifier NC_SCREEN is not High enough since font drawing is so
deeply rooted and its not handled in NC_WINDOW and NC_WM. i would like
to make a new notifier for this but there is really no functions open to
reinitialise fonts. If any one can help please do

what i have so far http://www.pasteall.org/17136/diff


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

[Bf-committers] text Hinting patch

[Michael Fox]

Hello all, i have made a little patch of what was suggested on BA and
turn off text hinting. 

Now when i did this it made the UI far more clear and readable and the
UI is lose to 200% faster and more responsive, i can actually acheive
24fps playback with an animated character on my 6200 and i have never
been able to do that.

so what i would like is for some here to try out the patch and find any
dramas or problems, although the patch is very small, it makes a huge
difference and i want to ask for approval to commit

http://mfoxdogg.com/development/text_hinting_fix.txt



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

Re: [Bf-committers] Declarative UI Experiment

[Michael Fox]

There is one thing here that no one has seemed to have mentioned is we
are close to release date, and 2.53 has already become the defacto
standard of blender, which means a majority of people are using it and
developing addons and UI related stuff already and we are already
pissing them off with all the rna changes recently. 

So if we go ahead with all these proposed declarative systems then they
are just going to be fed up (i am very close, 'imagine' software anyone
or netscape for that matter) and not bother as the api is too unstable
and doesn't remain the same for long. This will severely cripple blender
in both the eyes of our long term users and higher up users. Limiting
the range of what blender can achieve due the lack of adequate
addons-tools.

This fact is multiplied due to the advanced Python centric of the
proposed methods as this limits simple changes to those who know what
they are doing where as  the current api is easy and changed quickly
with copy and paste and the like. Like i have very little python
knowledge and i find the currently api much more understandable then
proposed methods, and view the current api as far more flexible.

any proposals to mix methods will only achieve utter confusion on behalf
of the user and any budding developer as they would not know what to use
and would be aggravated by the shear lack of consistency and consistency
is a corner stone of 2.5, and in recent times i have seen it thrown out
the window without a care.

So i propose is keep the api that we have, instead adjust and optimise
what is behind there and all these arguments about speed, its not the UI
falut, its improper use of notifiers and redraws, which has been
completely ignored or over looked, i view these new UI proposals as
putting a band aid on a broken leg with the main issue being ignored and
many agree with me.

This also look to me like over adjusting and concentrating on somthing
that shouldn't be, there is a huge bugtracker out there you know.

Michael Fox
Animator, Programmer
Training Resource and multimedia Studio
m...@trams.net.au


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

Re: [Bf-committers] Proposal to Remove Features

[Michael Fox]

I agree with most of the list, but Fields is still defiantly needed and
should be fixed Rather then ignored, and please keep the vnormal flip in
as it helps in rendering corrupted meshes, i maybe wrong though. 

Object Colour would be nice to keep full if it was to draw the object
wires using it other wise hiding it in the GE mode is fine. 

i agree with making what you suggested on by default.

"Outline Selected, All Object Origins and Relationship Lines in the 3d
view should become user preferences."
 that i really don't agree with they are needed as quick access not
hidden in user-prefs.

i don't agree with anything in the controversial list they all are used
and all must stay.

also on this note i don't think the removal of things should happen just
yet, with 2.6 release everyone will start loading up old files and
saving them in 2.6's format after everyone has moved up to 2.6 then we
can start phasing out things
 after all loot at the big uproar that happened when radiosity was taken
out.

so let the users setting in, update their files, then you can start
pulling things out but please give the users proper notice and docs on
how to to get the same effect

-- 
Michael Fox 
Developer and user of Blender3d
www.blender.org
http://mfoxdogg.googlepages.com

mfoxd...@gmail.com

___
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 [28923] trunk/blender:

[Michael Fox]

Crap log message didn't go through :S

anyway this commit is to make the add_curve operator more atomic/modular
to be inline with the add mesh operators, this also allows for add_curve
addons to be un the curve menu instead of add mesh

the old operator is still there until all addons scripts are ported to
the new operators then it can be saftly removed

On Sun, 2010-05-23 at 04:02 +0200, Michael Fox wrote:
> Revision: 28923
>   
> http://projects.blender.org/plugins/scmsvn/viewcvs.php?view=rev&root=bf-blender&revision=28923
> Author:   mfoxdogg
> Date: 2010-05-23 04:02:04 +0200 (Sun, 23 May 2010)
> 
> Log Message:
> ---
> 
> 
> Modified Paths:
> --
> trunk/blender/release/scripts/ui/space_info.py
> trunk/blender/source/blender/editors/curve/curve_intern.h
> trunk/blender/source/blender/editors/curve/curve_ops.c
> trunk/blender/source/blender/editors/curve/editcurve.c
> 
> Modified: trunk/blender/release/scripts/ui/space_info.py
> ===
> --- trunk/blender/release/scripts/ui/space_info.py2010-05-23 00:09:56 UTC 
> (rev 28922)
> +++ trunk/blender/release/scripts/ui/space_info.py2010-05-23 02:02:04 UTC 
> (rev 28923)
> @@ -199,7 +199,19 @@
>  layout.operator("mesh.primitive_grid_add", icon='MESH_GRID', 
> text="Grid")
>  layout.operator("mesh.primitive_monkey_add", icon='MESH_MONKEY', 
> text="Monkey")
>  
> +class INFO_MT_curve_add(bpy.types.Menu):
> +bl_idname = "INFO_MT_curve_add"
> +bl_label = "Curve"
>  
> +def draw(self, context):
> +layout = self.layout
> +layout.operator_context = 'INVOKE_REGION_WIN'
> +layout.operator("curve.primitive_bezier_add", icon='CURVE_BEZCURVE', 
> text="Bezier")
> +layout.operator("curve.primitive_bezier_circle_add", 
> icon='CURVE_BEZCIRCLE', text="Circle")
> +layout.operator("curve.primitive_nurbs_curve_add", 
> icon='CURVE_NCURVE', text="Nurbs Curve")
> +layout.operator("curve.primitive_nurbs_circle_add", 
> icon='CURVE_NCIRCLE', text="Nurbs Circle")
> +layout.operator("curve.primitive_curve_path_add", icon='CURVE_PATH', 
> text="Path")
> +
>  class INFO_MT_armature_add(bpy.types.Menu):
>  bl_idname = "INFO_MT_armature_add"
>  bl_label = "Armature"
> @@ -221,7 +233,8 @@
>  #layout.operator_menu_enum("object.mesh_add", "type", text="Mesh", 
> icon='OUTLINER_OB_MESH')
>  layout.menu("INFO_MT_mesh_add", icon='OUTLINER_OB_MESH')
>  
> -layout.operator_menu_enum("object.curve_add", "type", text="Curve", 
> icon='OUTLINER_OB_CURVE')
> +#layout.operator_menu_enum("object.curve_add", "type", text="Curve", 
> icon='OUTLINER_OB_CURVE')
> +layout.menu("INFO_MT_curve_add", icon='OUTLINER_OB_CURVE')
>  layout.operator_menu_enum("object.surface_add", "type", 
> text="Surface", icon='OUTLINER_OB_SURFACE')
>  layout.operator_menu_enum("object.metaball_add", "type", 
> text="Metaball", icon='OUTLINER_OB_META')
>  layout.operator("object.text_add", text="Text", 
> icon='OUTLINER_OB_FONT')
> @@ -416,6 +429,7 @@
>  INFO_MT_file_external_data,
>  INFO_MT_add,
>  INFO_MT_mesh_add,
> +INFO_MT_curve_add,
>  INFO_MT_armature_add,
>  INFO_MT_game,
>  INFO_MT_render,
> 
> Modified: trunk/blender/source/blender/editors/curve/curve_intern.h
> ===
> --- trunk/blender/source/blender/editors/curve/curve_intern.h 2010-05-23 
> 00:09:56 UTC (rev 28922)
> +++ trunk/blender/source/blender/editors/curve/curve_intern.h 2010-05-23 
> 02:02:04 UTC (rev 28923)
> @@ -85,6 +85,12 @@
>  void CURVE_OT_smooth(struct wmOperatorType *ot);
>  void CURVE_OT_smooth_radius(struct wmOperatorType *ot);
>  
> +void CURVE_OT_primitive_bezier_add(struct wmOperatorType *ot);
> +void CURVE_OT_primitive_bezier_circle_add(struct wmOperatorType *ot);
> +void CURVE_OT_primitive_nurbs_curve_add(struct wmOperatorType *ot);
> +void CURVE_OT_primitive_nurbs_circle_add(struct wmOperatorType *ot);
> +void CURVE_OT_primitive_curve_path_add(struct wmOperatorType *ot)

Re: [Bf-committers] "Security" gets in the way

[Michael Fox]

Ok it seems we are getting nowhere fast on this, so to address the
original issue, have it off by default as that is what seems to be
causing the most troubles, yet keep it there for those who need it (ie
paranoid IT people :) ), 

as in a studio you will mainly be using internal scripts for like rigs
and such not much from the external world

also to show the danger to new users put a warning on the download page
in nice red letters at the top

all of this is done until a suitable option is available, and dropping
python all together is certainly not a viable alternative

now can this argument please end?

-- 
Michael Fox 
Developer and user of Blender3d
www.blender.org
http://mfoxdogg.googlepages.com

mfoxd...@gmail.com

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

Re: [Bf-committers] Blender Conference 2010

[Michael Fox]

Great Ideas Ton informal sessions are always good and a market place
could be a nice thing aswell, now i just need a plane ticket and im
there :)

On Fri, 2010-04-16 at 12:19 +0200, Ton Roosendaal wrote:
> Hi all,
> 
> Based on the 2009 conference feedback, here's some improvements we'll  
> test in 2010:
> 
> - Devs get free tickets! (at least 2 accepted commits in trunk).
>We had too few developers visiting past years...
> 
> - Third room with only informal sessions
>Great for developer-user feedback, sprints, etc.
> 
> - Market place
>If you want to present your own (commercial) product, get a table  
> and large screen!
> 
> 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


-- 
Michael Fox 
Developer and user of Blender3d
www.blender.org
http://mfoxdogg.googlepages.com

mfoxd...@gmail.com

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

Re: [Bf-committers] I'd like to kill the soft body module

[Michael Fox]

Please Don't kill softbodies, it is still needed for natural movements
of objects, cloth cannot maintain its shape well enough nor does it
maintain impact shapes and the the amount of options in SB is simply
amazing, I'd say change to docs to reflect that SB is NOT for cloth
including the screenshots, use the cloth sim for that, please im begging
you don't kill SB it is a critical part of effects and character
building and a critical part of blender itself


On Wed, 2010-03-03 at 01:09 +0100, bjornmose wrote:
> Hi all,
> I've been watching 2.5 evolving and I feel the (one size fits all .. 
> experimental physics code) soft body module has been replaced by the far 
> better cloth module at the hot spots. ( Thanks will go to janne and daniel )
> Further I think that future development ( in Blender ) should focus on 
> visual effects rather than try to simulate real world physics (which is 
> 'in given range' mission impossible ) .
> So I'd like to kindly ask for the permission to remove  that  wrong view 
> angled, physicists, crappy code.
> BM
> 
> 
>  
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers


-- 
Michael Fox 
Developer and user of Blender3d
www.blender.org
http://mfoxdogg.googlepages.com

mfoxd...@gmail.com

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

Re: [Bf-committers] Commit Rights: Nathan Vegdahl (Cessen)

[Michael Fox]

Congrats Nathan :) tackle-hugs all round :)

On Mon, 2010-01-18 at 21:30 +0100, Campbell Barton wrote:
> Nathan has been granted svn access,
> *Welcome Nathan* :)
> 
> We'll set him up to start committing tomorrow.
> 
> On Mon, Jan 18, 2010 at 7:08 PM, Andrea Weikert  wrote:
> > Campbell Barton schrieb:
> >> Nathan has mostly taken over maintenance of the autorigging system for
> >> durian and it would help if he was able to commit directly to it.
> >>
> >> - Nathan agrees to commit only to rigging scripts
> >> - realize other developers have contributed a lot and could be given
> >> commit rights too however its a bit different when they are working on
> >> blenders internals opposed to their own codebase.
> >> - We could also move rigify development out of blender (use our own
> >> Durian SVN), but I think its good to at least attempt a general
> >> blender rigging system, if it fails to be generalized enough by the
> >> time Blender2.5 becomes stable we can move it into an external
> >> repository.
> >>
> >> Would it be acceptable to give Nathan commit rights?
> >>
> >>
> > +1 from me
> >
> > It should be fine for Nathan to commit in his own code and it also makes
> > life a bit easier for Campbell (or Brecht) who would have to commit his
> > patches each time.
> >
> > - Andrea
> >
> > ___
> > Bf-committers mailing list
> > Bf-committers@blender.org
> > http://lists.blender.org/mailman/listinfo/bf-committers
> >
> 
> 
> 


-- 
Michael Fox 
Developer and user of Blender3d
www.blender.org
http://mfoxdogg.googlepages.com

mfoxd...@gmail.com

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

Re: [Bf-committers] Fixed, and Updated Torus mesh tool

[Michael Fox]

Make a patch and submit it to the patch tracker then give us the link

On Thu, 2010-01-14 at 02:40 -0600, Jaevixa McNomera wrote:
> Hello,
> 
> I've fixed the descriptions of the properties for the torus mesh in
> .blender/scripts/op/add_mesh_torus.py
> 
> Also, i've added 3 new controls to it.
> 
> The new controls add the ability to specify an Exterior Radius, and an
> Interior Radius, and then whether or not to USE those dimensions, or the
> regular Major/Minor Radii values.
> 
> 
> How do I go about submitting this to blender?
> 
> Jae
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers


-- 
Michael Fox 
Developer and user of Blender3d
www.blender.org
http://mfoxdogg.googlepages.com

mfoxd...@gmail.com

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