[Bf-committers] 2.71 Call for Docs
All, Ton has graciously allowed me to take on the role of documentation support. What this means, as I understand it, is that I get the job of gathering all raw documentation from developers and artists ahead of a release and turning it into something useful on the wiki. I believe that this means that I will also be putting together the release log. So this is what I need: Developers: I need anything you can give me, including, but not limited to: notes of any kind (implementation, user interface, scratch notes, etc), videos, screenshots, commit lists (though I can go over the git history if needed), git username (so I can find your commits), and any other useful information. It does NOT need to be organized (that's my job), but any effort would be greatly appreciated. Artists/users: If you worked with a developer on a feature and/or you tested it, I can also use any information from you. Again, the information doesn't need to be organized; I'll do that. Above all, I don't want any of you to stress about sending stuff to me. If necessary, I will go over the commit history. One last thing: to prevent spamming this mailing list, don't send to the list; send everything to me personally at gavin(dot)d(dot)howard(at)gmail(dot)com. Thanks! Gavin Howard ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] Withdrawal
All, This is going to be a pretty weird email, but whatever. I've been using Blender for several years now, after being introduced to it while at version 2.49. I used it a little, then set it aside for a while. A year later, I came back to a wonderful 2.5x series. I was excited, and because I /thought/ I could program, I wanted to help. I was /completely/ wrong about my skill. I bombed GSoC 2013, and as a result, I got super frustrated at myself and went into "hiding". After a while, and more education, I decided to do something a little more humble: the Release Notes. As you all know from last week's Developers' Meeting, I did the Release Notes wrong, especially on the Bug Fixes page. I went back through and tried to fix the problems, but my judgment is lacking, and I'm sure that I didn't quite fix them. Quite frankly, I am frustrated with my ineptitude yet again. I know that the Blender Foundation doesn't need my help, and at this point, I am pretty sure my "help" is a burden in several ways. So I really wonder if it would be better without me. I sincerely hope it hasn't been a burden in /every/ way. Regardless of if I have or not, I think it's time I call it quits. I'm just not competent enough to help out, even in a non-development role. I will finish out this release, but once 2.72 (and any 'a' or other subsequent bugfix release) is out, I will not "help" out anymore. I'll still be a user; Blender (and Cycles!) helped me secure a spot in BYU's Animation Emphasis for the Computer Science major, and I don't intend to stop using it. But my role in its development will disappear. Sorry, Campbell; I know you don't like doing those Release Notes. Thanks for everything. God Bless, Gavin Howard ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Withdrawal
In reality, Ton, I sent that email only to you; I didn't know Sergey's address, I didn't want to spam the mailing list, and I was already too embarrassed. (So much for that.) So it's not Sergey's fault. And neither is it yours; I know you're busy, so I was planning on resending the email today anyways. But I should have sent it to the whole list. Yet another mistake. Sorry. The truth is that I'm not frustrated with you all. What did me in was going back through and trying to clean up the fixes as Sergey said. I thought I understood what he said, and I realized that I didn't. Like I said, it was my own incompetence at following simple instructions. Just to be clear, I never thought I was insulted. I simply get frustrated with myself quite easily, especially after last summer. Sergey, your clarifications helped. (I think.) Give me 24 hours to go back through and get it up to standard. God Bless, Gavin Howard On Sun, Sep 14, 2014 at 9:31 AM, Sergey Sharybin wrote: > I didn't actually see your mail from monday. Either it got lost somewhere > in my client or i dunno. > > As for the fixed bugs section it's not that bad actually, the stuff Ton > mentioned in the minutes are just guidelines for that page to make it > maintainable. It doesn't mean it's fully wrong or so. Main issue with the > page is that it lacks information about the revision range it's valid for. > So if you suddenly becomes busy and i (or cambo or whoever else) need > finish it -- it'll be rather tricky to figure out where to start. To avoid > such issues, we put on the top of the page: > > Changes from revision AAA up to BBB > > It should be really easy for you to add information about revision your > list is updated to. > > Other issue is that i saw quite a few fixes which were a fixes for new > stuff added to 2.72. We don't mention that in the change log. It should be > easy for you again to just ignore such fixes for the rest of the revisions > from now on up to the very release. We'll need to clean up existing list > from those fixes, but for that you can have at least mine help, and as max > -- there could be more volunteers to help cleaning stuff up. > > And the structure issue is also not that difficult to solve. It's just > matter of using old structure and copy-pasteing new fixes to it. Or > renaming the sections, so Modeling is more like a Mesh Editing, Compositor > is Node / Compositor and such. Sticking to some "standard" template is good > for the readability of changes imo. And for this you can also use my help > or help from someone else in the community. > > So to summarize, there is some clean up to be done on the fixes page, but > it's not that much of work and it doesn't mean you need to do it all (we'll > for sure help with the cleanups and so). And consider information from > Ton's mail about fixed bugs section as a guideline for the future work on > that section. Do not consider it as an insult on your work, we really > appreciate your help. > > On Sun, Sep 14, 2014 at 9:11 PM, Ton Roosendaal wrote: > >> Hi Gavin, >> >> Sorry, it's unfortunate that nobody replied to your mail from last monday. >> I had no time either.The issue would/could have been easy to handle in irc >> though... asking sergey or campbell or me. I can only confirm they've been >> very busy and didn't notice or forgot the mail. >> >> In any way - most important is to at least keep communicating! When that >> fails it's usually the core of the issues in a volunteering organization. >> >> I'll ask Sergey to clarify the remarks I copied to the minutes. >> >> -Ton- >> >> >> Ton Roosendaal - t...@blender.org - www.blender.org >> Chairman Blender Foundation - Producer Blender Institute >> Entrepotdok 57A - 1018AD Amsterdam - The Netherlands >> >> >> >> On 14 Sep, 2014, at 5:09, Gavin Howard wrote: >> >> > All, >> > >> > This is going to be a pretty weird email, but whatever. >> > >> > I've been using Blender for several years now, after being introduced >> > to it while at version 2.49. I used it a little, then set it aside for >> > a while. A year later, I came back to a wonderful 2.5x series. I was >> > excited, and because I /thought/ I could program, I wanted to help. >> > >> > I was /completely/ wrong about my skill. >> > >> > I bombed GSoC 2013, and as a result, I got super frustrated at myself >> > and went into "hiding". After a while, and more education,
Re: [Bf-committers] Withdrawal
Well, if I don't get it done, you have to. The time constraint was so you could expect it done before having to work on it yourself. On Sun, Sep 14, 2014 at 1:04 PM, Sergey Sharybin wrote: > Sounds cool, only not sure why to define such a time constraints? > > On Mon, Sep 15, 2014 at 12:59 AM, Gavin Howard > wrote: > >> In reality, Ton, I sent that email only to you; I didn't know Sergey's >> address, I didn't want to spam the mailing list, and I was already too >> embarrassed. (So much for that.) So it's not Sergey's fault. And >> neither is it yours; I know you're busy, so I was planning on >> resending the email today anyways. But I should have sent it to the >> whole list. Yet another mistake. Sorry. >> >> The truth is that I'm not frustrated with you all. What did me in was >> going back through and trying to clean up the fixes as Sergey said. I >> thought I understood what he said, and I realized that I didn't. Like >> I said, it was my own incompetence at following simple instructions. >> Just to be clear, I never thought I was insulted. I simply get >> frustrated with myself quite easily, especially after last summer. >> >> Sergey, your clarifications helped. (I think.) Give me 24 hours to go >> back through and get it up to standard. >> >> God Bless, >> Gavin Howard >> >> On Sun, Sep 14, 2014 at 9:31 AM, Sergey Sharybin >> wrote: >> > I didn't actually see your mail from monday. Either it got lost somewhere >> > in my client or i dunno. >> > >> > As for the fixed bugs section it's not that bad actually, the stuff Ton >> > mentioned in the minutes are just guidelines for that page to make it >> > maintainable. It doesn't mean it's fully wrong or so. Main issue with the >> > page is that it lacks information about the revision range it's valid >> for. >> > So if you suddenly becomes busy and i (or cambo or whoever else) need >> > finish it -- it'll be rather tricky to figure out where to start. To >> avoid >> > such issues, we put on the top of the page: >> > >> > Changes from revision AAA up to BBB >> > >> > It should be really easy for you to add information about revision your >> > list is updated to. >> > >> > Other issue is that i saw quite a few fixes which were a fixes for new >> > stuff added to 2.72. We don't mention that in the change log. It should >> be >> > easy for you again to just ignore such fixes for the rest of the >> revisions >> > from now on up to the very release. We'll need to clean up existing list >> > from those fixes, but for that you can have at least mine help, and as >> max >> > -- there could be more volunteers to help cleaning stuff up. >> > >> > And the structure issue is also not that difficult to solve. It's just >> > matter of using old structure and copy-pasteing new fixes to it. Or >> > renaming the sections, so Modeling is more like a Mesh Editing, >> Compositor >> > is Node / Compositor and such. Sticking to some "standard" template is >> good >> > for the readability of changes imo. And for this you can also use my help >> > or help from someone else in the community. >> > >> > So to summarize, there is some clean up to be done on the fixes page, but >> > it's not that much of work and it doesn't mean you need to do it all >> (we'll >> > for sure help with the cleanups and so). And consider information from >> > Ton's mail about fixed bugs section as a guideline for the future work on >> > that section. Do not consider it as an insult on your work, we really >> > appreciate your help. >> > >> > On Sun, Sep 14, 2014 at 9:11 PM, Ton Roosendaal wrote: >> > >> >> Hi Gavin, >> >> >> >> Sorry, it's unfortunate that nobody replied to your mail from last >> monday. >> >> I had no time either.The issue would/could have been easy to handle in >> irc >> >> though... asking sergey or campbell or me. I can only confirm they've >> been >> >> very busy and didn't notice or forgot the mail. >> >> >> >> In any way - most important is to at least keep communicating! When that >> >> fails it's usually the core of the issues in a volunteering >> organization. >> >> >> >> I'll ask Sergey to clarify the remarks I copied to the minutes. >&
Re: [Bf-committers] Please review code of "Nodes Efficiency Tools" Add-On
Hello all,
Just though that I'd give my opinion of this add-on. I really like it.
I can work much more efficiently in the compositor/materials node editor.
It was stable on my machine. I'd recommend it.
Bartek, I do have one suggestion for the add-on. On the automatic node
alignment, the add-on automatically spaces the aligned nodes the same
distance apart, which often throws off other alignments. I would suggest
that you take that out. If you align them horizontally, only move them
vertically, not horizontally as well. That said, it's a great add-on.
Thanks for making it!
God Bless,
Gavin Howard
On Sat, Jan 12, 2013 at 2:43 PM, Bartek Skorupa (priv) <
bartekskor...@bartekskorupa.com> wrote:
> Hello,
>
> I'd like to ask for reviewing the code of Add On: "Nodes Efficiency Tools"
>
> http://projects.blender.org/tracker/index.php?func=detail&aid=33543&group_id=153&atid=467
>
> I think it's ready to be included in contrib repository.
> The Addon is relatively "young". I published it in the middle of December
> last year, but it got very good response.
> wiki page for it is ready:
> http://wiki.blender.org/index.php/Extensions:2.6/Py/Scripts/Nodes/Nodes_Efficiency_Tools
> Here's a link to video tutorial:
> http://cg.bartekskorupa.com/nodes-efficiency-tools/
> and here's a thread on BA forum:
> http://blenderartists.org/forum/showthread.php?274755-ADDON-Compositing-Nodes-Efficiency-Tools
>
> direct link to the code:
> http://projects.blender.org/tracker/download.php/153/467/33543/23534/node_efficiency_tools.py
>
> With Respect
> Bartek Skorupa
>
> www.bartekskorupa.com
>
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Please review code of "Nodes Efficiency Tools" Add-On
Bartek, Thanks for that clarification. In that case, keep it. And rest assured, that was not the only reason I was using the add-on. Thanks again. God Bless, Gavin Howard On Sat, Jan 12, 2013 at 3:10 PM, Bartek Skorupa (priv) < bartekskor...@bartekskorupa.com> wrote: > Hey Gavin, > > Thank you for your opinion. > About node alignment: > The main purpose of this tool was to align nodes let's say "horizontally" > and evenly space them on vertical axis. > The behavior that you suggest is available without my add-on by hitting > S-X-0 or S-Y-0. > Such key combinations do exactly what you want. My goal was to > additionally evenly distribute the the nodes. > This way you have both options: If you want "my" behavior you hit "Shift > =" and chose the axis and if you don't want even distribution - S-X-0, or > S-Y-0 > > Cheers > > Bartek Skorupa > > www.bartekskorupa.com > > On 12 sty 2013, at 22:52, Gavin Howard wrote: > > > Hello all, > > Just though that I'd give my opinion of this add-on. I really like > it. > > I can work much more efficiently in the compositor/materials node editor. > > It was stable on my machine. I'd recommend it. > > Bartek, I do have one suggestion for the add-on. On the automatic > node > > alignment, the add-on automatically spaces the aligned nodes the same > > distance apart, which often throws off other alignments. I would suggest > > that you take that out. If you align them horizontally, only move them > > vertically, not horizontally as well. That said, it's a great add-on. > > Thanks for making it! > > God Bless, > > Gavin Howard > > > > > > On Sat, Jan 12, 2013 at 2:43 PM, Bartek Skorupa (priv) < > > bartekskor...@bartekskorupa.com> wrote: > > > >> Hello, > >> > >> I'd like to ask for reviewing the code of Add On: "Nodes Efficiency > Tools" > >> > >> > http://projects.blender.org/tracker/index.php?func=detail&aid=33543&group_id=153&atid=467 > >> > >> I think it's ready to be included in contrib repository. > >> The Addon is relatively "young". I published it in the middle of > December > >> last year, but it got very good response. > >> wiki page for it is ready: > >> > http://wiki.blender.org/index.php/Extensions:2.6/Py/Scripts/Nodes/Nodes_Efficiency_Tools > >> Here's a link to video tutorial: > >> http://cg.bartekskorupa.com/nodes-efficiency-tools/ > >> and here's a thread on BA forum: > >> > http://blenderartists.org/forum/showthread.php?274755-ADDON-Compositing-Nodes-Efficiency-Tools > >> > >> direct link to the code: > >> > http://projects.blender.org/tracker/download.php/153/467/33543/23534/node_efficiency_tools.py > >> > >> With Respect > >> Bartek Skorupa > >> > >> www.bartekskorupa.com > >> > >> ___ > >> Bf-committers mailing list > >> Bf-committers@blender.org > >> http://lists.blender.org/mailman/listinfo/bf-committers > >> > > ___ > > Bf-committers mailing list > > Bf-committers@blender.org > > http://lists.blender.org/mailman/listinfo/bf-committers > > ___ > 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 [53908] trunk/blender/source/blender: patch [#33923] Patch for Node Theme Colors
Sergey (and all),
I wrote this patch based on a quick hack that was on the wiki's quick
hack page. (Campbell has since taken it off the page.) To be honest, I
agree with you; the code for colors is kind of messed up. In fact, both Ton
and Campbell said the same thing when I submitted the patch to them.
However, it follows the conventions of the surrounding code, which is one
of the code style guidelines.
That doesn't mean that something can't be done about it, but I am not
in the position to make decisions about code design. I don't even have
commit privileges (which is why I did a quick hack). If something is to be
done about the current code for themes and colors, current developers are
going to have to talk about it. As for me, I have a few projects I am doing
for Blender; however, most of them are small, so I think that I would be
able to help if some decisions are made.
Thank you to all developers, especially Campbell for being so patient
and willing to help me through my first steps. I have enjoyed working for
Blender.
God Bless,
Gavin Howard
On Sat, Jan 19, 2013 at 10:19 AM, Sergey Sharybin wrote:
> I'm not so much sure such approach is indeed cool here.
>
> First, why only matte and distort and not other nodes?
> Second, we already do have custom node colors, which already was served for
> such kind of node highlight. Now we do have two separated ways of affecting
> on visual feedback which is a bit cluttered i think.
>
> IMO, nicer approach would be to define some kind of custom color presets
> for different node types. Any node types, not just two of them. Maybe even
> make it stored in .blend file, because in different projects/files i could
> be interested more in different types of operations. Also, maybe make node
> header depend on custom node color, like shade it by multiplying by 0.5
> (just quick idea).
>
> Color feedback could indeed help here, but currently it's a bit of mess
> here i think and could be made much nicer..
>
>
> On Sat, Jan 19, 2013 at 10:21 AM, Campbell Barton >wrote:
>
> > Revision: 53908
> >
> >
> http://projects.blender.org/scm/viewvc.php?view=rev&root=bf-blender&revision=53908
> > Author: campbellbarton
> > Date: 2013-01-19 04:20:53 + (Sat, 19 Jan 2013)
> > Log Message:
> > ---
> > patch [#33923] Patch for Node Theme Colors
> > from Gavin Howard (gdh)
> >
> > Modified Paths:
> > --
> > trunk/blender/source/blender/editors/include/UI_resources.h
> > trunk/blender/source/blender/editors/interface/resources.c
> > trunk/blender/source/blender/editors/space_node/node_draw.c
> > trunk/blender/source/blender/makesrna/intern/rna_userdef.c
> >
> > Modified: trunk/blender/source/blender/editors/include/UI_resources.h
> > ===
> > --- trunk/blender/source/blender/editors/include/UI_resources.h
> 2013-01-19
> > 03:51:17 UTC (rev 53907)
> > +++ trunk/blender/source/blender/editors/include/UI_resources.h
> 2013-01-19
> > 04:20:53 UTC (rev 53908)
> > @@ -147,6 +147,8 @@
> > TH_NODE_CONVERTOR,
> > TH_NODE_GROUP,
> > TH_NODE_FRAME,
> > + TH_NODE_MATTE,
> > + TH_NODE_DISTORT,
> >
> > TH_CONSOLE_OUTPUT,
> > TH_CONSOLE_INPUT,
> >
> > Modified: trunk/blender/source/blender/editors/interface/resources.c
> > ===
> > --- trunk/blender/source/blender/editors/interface/resources.c
> 2013-01-19
> > 03:51:17 UTC (rev 53907)
> > +++ trunk/blender/source/blender/editors/interface/resources.c
> 2013-01-19
> > 04:20:53 UTC (rev 53908)
> > @@ -389,6 +389,10 @@
> > cp = ts->syntaxc; break;
> > case TH_NODE_FRAME:
> > cp = ts->movie; break;
> > + case TH_NODE_MATTE:
> > + cp = ts->syntaxs; break;
> > + case TH_NODE_DISTORT:
> > + cp = ts->syntaxd; break;
> > case TH_NODE_CURVING:
> > cp = &ts->noodle_curving; break;
> >
> > @@ -2091,7 +2095,7 @@
> > btheme->tclip.panelcolors = btheme->tui.panel;
> > }
> > }
> > -
> > +
> > if (bmain->versionfile < 266) {
> > bTheme
Re: [Bf-committers] 'help'
Erwin, It is: svn co https://svn.blender. org/svnroot/bf-blender/trunk/blender God Bless, Gavin Howard On Feb 23, 2013 12:58 PM, "Erwin" wrote: > At a first glance that wiki page has no information about the subversion > repository. It usually takes me a while of searching too. > > So what is the svn url? > > Sent from my iPhone > > On Feb 23, 2013, at 11:28 AM, Tom M wrote: > > > Follow the directions here > > > > http://wiki.blender.org/index.php/Dev:Doc/Building_Blender > > > > Which will direct you to the method for downloading the source code from > SVN. > > > > Good luck, > > > > LetterRip > > ___ > > Bf-committers mailing list > > Bf-committers@blender.org > > http://lists.blender.org/mailman/listinfo/bf-committers > ___ > Bf-committers mailing list > Bf-committers@blender.org > http://lists.blender.org/mailman/listinfo/bf-committers > ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Blender 2.66a release AHOY!
All, A big thank you to the developers! I have been watching the commit logs for both 2.66 and 2.66a. This release is awesome! I always love it when I get an AHOY! from the mailing list. Thanks again! God Bless, Gavin Howard (gdh) On Tue, Mar 5, 2013 at 9:31 AM, Sergey Sharybin wrote: > Hi, > > And again we've got lots of fixed to be applied on recent release, meaning > we're doing 2.66a. > > Here's information for platform maintainers: > > tag: blender-2.66a-release > tag revision: 55057 > addons revision: 4339 > locale revision: 1586 > > Keep usual naming and let me know when the builds are ready. > > Thanks! > > -- > With best regards, Sergey Sharybin > ___ > Bf-committers mailing list > Bf-committers@blender.org > http://lists.blender.org/mailman/listinfo/bf-committers > ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] GSOC 2013 Proposal
Siddhartha, Personally, I think some of those ideas may have some potential. However, I am not one of the developers, so I can't speak for them. If it turns out that they feel that these projects would not benefit Blender as much as they hope, I would suggest that you apply to work for the Open Source Computer Vision project. That might fit your field better, and you might have more fun. As a fellow GSoC student. I hope this helps. And regardless of what happens, welcome to Blender! God Bless, Gavin H. On Apr 11, 2013 9:25 PM, "Siddharth" wrote: > Hi, > > I am currently pursuing MS by Research in the field of computer vision and > image processing at IIIT- Hyderabad, India. I am interested in working for > Blender organization this summer in a GSoC project. > > > Some of my own ideas: > > a) *Interactive Poisson Image Blending* > > Image editing tasks concern either global changes (color/intensity > corrections, filters, deformations) or local changes concerned to a > selection. Here we are interested in achieving local changes, ones that are > restricted to a region manually selected (ROI), in a seamless and > effortless manner. The extent of the changes ranges from slight distortions > to complete replacement by novel content. Examples:Inserting objects, Color > Transfer, Feature Exchange, Texture Flattening, Local illumination changes, > etc. > > > http://cs.engr.uky.edu/~jacobs/classes/2010_photo/readings/PoissonImageEditing.pdf > > b) *Color2Gray* > > Visually important image features often disappear when color images are > converted to grayscale. This algorithm reduces such losses by attempting to > preserve the salient features of the color image. The Color2Gray results > offer viewers salient information missing from previous grayscale image > creation methods. > > http://www.cse.cuhk.edu.hk/~leojia/papers/decolorization_iccp12.pdf > > c) *Domain Transform for Edge-Aware Image Processing > (Non-Photorealistic Animation and Rendering)* > > The processing involves high-quality edge-preserving filtering of images > (better than bilateral filter). The filter is applied on several image > processing tasks including edge-preserving smoothing, Depth-of-field > effects, stylization, detail enhancement, edge enhancement and pencil/color > pencil sketch. > > > http://www.inf.ufrgs.br/~eslgastal/DomainTransform/Gastal_Oliveira_SIGGRAPH2011_Domain_Transform.pdf > > What are your views about this? > > Best Regards, > Siddharth > > -- > Live as if you were to die tomorrow. Learn as if you were to live forever - > M K Gandhi > ___ > Bf-committers mailing list > Bf-committers@blender.org > http://lists.blender.org/mailman/listinfo/bf-committers > ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] GSoC 201 - Automatic Skeleton Extraction
Alexander, First, I must make a disclaimer. I am NOT a Blender developer, so my opinion really doesn't matter. Take what I say with a grain of salt. That said, time to get to business. Speaking as a Blender user, I would love to have this feature. It would definitely help me. However, as a programmer, I know that implementing something like this would not be easy. If it can be done, without breaking Blender, give it a shot. One last note: to be honest, I'm not sure that this project is small enough to do for GSoC. However, I can see that you have done GSoC before, so you probably know better than I do. Just my two cents. God Bless, Gavin H. On Apr 25, 2013 10:02 AM, "Alexander Pinzon Fernandez" wrote: > Automatic Skeleton Extraction > > Alexander Pinzon Fernandez > > Email: apinz...@gmail.com > > > Short description: > > The character animation is generally done with skeletons that control each > joint in the character which drastically simplifies the animation process. > The construction of the skeleton given a polygon mesh is a task typically > performed by an artist. This project proposes to implement a method for > extracting the skeleton automatically given a polygon mesh. > > > > *Name*: Alexander Pinzon Fernandez > > *Email*: apinz...@gmail.com > > *IRC*: apinzonf > > *www*: http://apinzonf.wordpress.com/, > http://wiki.blender.org/index.php/User:Apinzonf > > *Additional Contact Info* > > *Phone*: +57 300 2 92 74 30 > > *Physical Address*: Cr 81 H No 42a-58 sur Bogota-Colombia > > > Synopsis > > The character animation is generally done with skeletons that control each > joint in the character which drastically simplifies the animation process. > The construction of the skeleton given a polygon mesh is a task typically > performed by an artist. This project proposes to implement a method for > extracting the skeleton automatically given a polygon mesh. > > This method iteratively contracts the shape in the reverse direction of the > curvature flow, with a constraint that forces the contracted model will > closely match the original. In each iteration eliminates details. After the > model volume is close to zero is passed to the next stage in which through > a special surface simplification method removes vertices to obtain a 1D > structure. > > Paper used: > > AU, Oscar Kin-Chung, et al. Skeleton extraction by mesh contraction. ACM > Transactions on Graphics (TOG). ACM, 2008. p. 44. > > > Benefits to Blender > > This project proposes a new tool for blender user that requires extract the > skeleton of polygon meshes. > > This method allows to obtain the skeleton of a polygon mesh quickly and > automatically. > > This method is insensitive to noise because it uses a smoothing algorithm > for contraction which removes the noise and detail in each iteration. > > > Deliverables > >1. A new skeleton extraction tool for Blender. >2. Some pages of documentation to be included in the manual >3. A technical document for developers to improve the method in the >future. >4. A tutorial explaining the use of the tool. > > > Project Details > > The project would divide into seven parts: > >1. Iteratively contracting the mesh until the volume is close to zero. >2. Simplifying polygon mesh to obtain a 1D structure (skeleton). >3. Relocating skeleton nodes in the center of each segment. >4. Create vertex groups for each node of the skeleton. >5. Converting a 1D polygon mesh into an armature. >6. Link vertex groups to bones of the armature. >7. Generation of the documentation and tutorials. > > > Project Schedule > >- *2 Weeks:- May 27 – Jun 09:* Iteratively contracting the >mesh until the volume is close to zero. >- *3 Weeks:- Jun 10 – Jun 31:* Simplifying polygon mesh to >obtain a 1D structure (skeleton). >- *2 Weeks:- Jul 01 – Jul 14:* Relocating skeleton nodes in >the center of each segment. >- *2 Weeks:- Jul 15 – Jul 28:* Create vertex groups for each >node of the skeleton. >- *3 Weeks:- Jul 29 – Aug 18:* Converting a 1D polygon mesh >into an armature. >- *2 Weeks:- Aug 19 – Sep 01:* Link vertex groups to bones of >the armature.. >- *1 Weeks:- Sep 02 – Sep 08:* Testing the tool and Define and >implement graphical user integration. >- *2 Weeks:- Sep 09 – Sep 22:* Generation of the documentation >and tutorials. > > > Bio > > I graduated as systems engineer in Colombia in 2007. > > I am a MSc computer science student at National University of Colombia. > > Skeleton extraction and mesh smoothing are the research topics of my MSc. I > am use CGAL, Graphite and Qt libraries. > > Since 2007 I am a member of the Bioingenium Research Group of National > University of Colombia. > > I have been using Blender for about 10 years. I was working on the develop > of a operator to remove noise from a mesh
Re: [Bf-committers] Cycles performance on Windows
Congratulations, Jürgen! Gavin H. On Mon, May 13, 2013 at 12:20 PM, Jürgen Herrmann wrote: > Hi Ton, > > Just got it ;-) Thank you very much! > I'll read the rules completely first, promised :-D > > Thanks > Jürgen > > Am 13.05.2013 um 18:00 schrieb Ton Roosendaal : > > > Hi Jürgen, > > > > You've been added now, and should have a welcome mail in your inbox. > > Thanks! > > > > -Ton- > > > > > > Ton Roosendaal Blender Foundation t...@blender.orgwww.blender.org > > Blender Institute Entrepotdok 57A 1018AD Amsterdam The Netherlands > > > > On 11 May, 2013, at 19:38, Jürgen Herrmann wrote: > > > >> Hi Ton, > >> > >> I would be proud to be a part of the blender team. I actually had some > >> patches in the Patch tracker that were committed by Brecht. He should be > >> able to judge about their quality. > >> Look here: > >> http://projects.blender.org/tracker/?func=detail&atid=127&aid=35158 > >> http://projects.blender.org/tracker/?func=detail&atid=127&aid=35131 > >> http://projects.blender.org/tracker/?func=detail&atid=127&aid=35234 > >> http://projects.blender.org/tracker/?func=detail&atid=127&aid=35019 > >> http://projects.blender.org/tracker/index.php?func=detail&aid=35153 > >> > >> I have a full set of x64 prerequisite libs freshly compiled and I am > >> currently working on compiling the x86 libs. > >> I've also extended the CMakeFiles to include the new libs and compiler > >> settings. I always doublecheck all changes with VC2008 so I don't break > >> compatibility. > >> > >> /Jürgen. > >> > >> -Ursprüngliche Nachricht- > >> Von: bf-committers-boun...@blender.org > >> [mailto:bf-committers-boun...@blender.org] Im Auftrag von Ton > Roosendaal > >> Gesendet: Samstag, 11. Mai 2013 18:43 > >> An: bf-blender developers > >> Betreff: Re: [Bf-committers] Cycles performance on Windows > >> > >> Hi Jurgen, > >> > >> You're very welcome to join the windows platform team as maintainer for > MSVC > >> 2012. > >> Did you already have patches we should apply? We typically give people > >> commit access after a couple of good patches. > >> > >> -Ton- > >> > >> > >> Ton Roosendaal Blender Foundation t...@blender.orgwww.blender.org > >> Blender Institute Entrepotdok 57A 1018AD Amsterdam The Netherlands > >> > >> On 10 May, 2013, at 22:02, Jürgen Herrmann wrote: > >> > >>> This sounds reasonable. So we need a lightning fast math library > >> replacement for MS compilers... > >>> I'm just kidding, but the idea might be insane enough to try ;) > >>> > >>> I am very satisfied with the speed improvement that MSVC 2012 has > brought > >> to blender. I would love to see this in the wild. It could make some > people > >> very happy. > >>> > >>> I would volunteer to maintain this build platform if desired. > >>> > >>> /Jürgen > >>> > >>> > >>> Am 10.05.2013 um 20:17 schrieb Antony Riakiotakis : > >>> > According to the MinGW64 developers, the math library implementation > is faster for gcc. The simulations use openmp which is disabled in > MinGW64 due to their buggy pthread implementation which makes openmp > hang when used during pthread execution. > ___ > Bf-committers mailing list > Bf-committers@blender.org > http://lists.blender.org/mailman/listinfo/bf-committers > >>> ___ > >>> Bf-committers mailing list > >>> Bf-committers@blender.org > >>> http://lists.blender.org/mailman/listinfo/bf-committers > >> > >> ___ > >> Bf-committers mailing list > >> Bf-committers@blender.org > >> http://lists.blender.org/mailman/listinfo/bf-committers > >> > >> ___ > >> Bf-committers mailing list > >> Bf-committers@blender.org > >> http://lists.blender.org/mailman/listinfo/bf-committers > > > > ___ > > 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] Patch to add "Show/hide 3D Cursor" functionality
All, I say +1 to Jürgen's suggestion. I think hiding the cursor would be incredibly useful in many cases. Having a button in the 3D View header, as well as a hotkey would be awesome. Also, using a LMB click to unhide it (or the hotkey) would be intuitive. Of course, this is coming from a user who is less a user than a developer. Take it for what it's worth. God Bless, Gavin Howard On Jun 9, 2013 9:48 AM, "Jürgen Herrmann" wrote: > It would be nice to have a hotkey to hide the 3d cursor. It might be a > good idea to unhide the cursor when the user switches to another edit mode. > > When hidden the cursor should stay in place so it is not accidentally > moved to another position. An alternative would be to unhide the cursor > when it is moved (for example by clicking LMB in object mode). > > No matter how it is done it should be completely intuitive for all users. > > /Jürgen > > Am 09.06.2013 um 17:29 schrieb Sean Olson : > > > I am a big fan of the 3d cursor, but I frequently I do wish I could hide > it > > as it is just distracting at times when I don't need it. I would love to > > be able to turn it on/off manually just as I can with the > > transform/rotate/scale widgets. I do think this option should probably > be > > on the bottom bar along with those widgets though, and not in the much > > harder to access properties panel. > > > > Additionally, we need to be careful with turning off the cursor in > certain > > modes. Currently in paint mode the 3d cursor is used in the clone tool. > > So to always turn it off would be a mistake. A clone tool in sculpt has > > not been built, but it would be cool to have that functionality as well, > > which of course would use the 3d cursor. > > > > -Sean > > > > > > On Sun, Jun 9, 2013 at 8:54 AM, Dima Glibitsky > wrote: > > > >> I've made a poll > >> > >> > http://blenderartists.org/forum/showthread.php?295865-Hiding-3D-cursor-use-cases-%28poll%29 > >> Most probably auto-hiding in some modes won't draw any objections, > >> though I'm curious what the results of the poll turn out to be. > >> I'll try to make a patch that hides 3D cursor based in Paint/Sculpt > >> modes in the meantime :-) > >> > >> On Sun, Jun 9, 2013 at 3:44 PM, Ton Roosendaal wrote: > >>> Hi, > >>> > >>> A lot of editing still depends on a 3d cursor to exist, hiding it > >> completely is not good feature, unless it bypasses every call that uses > the > >> 3d cursor. > >>> > >>> For us now, a useful hiding for 3d cursor is in special edit modes like > >> paint or sculpt (assuming it is not used). > >>> > >>> -Ton- > >>> > >>> > >>> Ton Roosendaal - t...@blender.org - www.blender.org > >>> Chairman Blender Foundation - Producer Blender Institute > >>> Entrepotdok 57A - 1018AD Amsterdam - The Netherlands > >>> > >>> > >>> > >>> On 9 Jun, 2013, at 14:18, Dima Glibitsky wrote: > >>> > >>>> Hi, thanks for the quick reply :) > >>>> Perhaps the main question is, then, if there are any cases when users > >>>> want to hide the cursor in the Object mode. I'll try to ask that on > >>>> the BlenderArtists. > >>>> I can imagine that some CAD-like addons might use the option to > >>>> disable the default cursor to display something more advanced instead > >>>> (e.g. local coordinate axes/planes). In this case, non-coders won't > >>>> have to know about the existence of this setting. > >>>> > >>>> On Sun, Jun 9, 2013 at 2:57 PM, Ton Roosendaal > wrote: > >>>>> Hi, > >>>>> > >>>>> If painting and sculpting doesn't require use of the 3d cursor, it > can > >> be just hidden by the mode itself? Options and more buttons don't make > >> using Blender easier. We have too many already :) > >>>>> > >>>>> -Ton- > >>>>> > >>>>> > >>>>> Ton Roosendaal - t...@blender.org - www.blender.org > >>>>> Chairman Blender Foundation - Producer Blender Institute > >>>>> Entrepotdok 57A - 1018AD Amsterdam - The Netherlands > >>>>> > >>>>> > >>>
Re: [Bf-committers] Blender developer weekly meeting minutes - June 9, 2013
Hello, What still needs to be done on the Ubershader? Gavin H. On Jun 9, 2013 8:55 AM, "Ton Roosendaal" wrote: > Hi all, > > Here's the notes from a nice short meeting today in > irc.freenode.net#blendercoders > > 1) Blender 2.68 release targets > > - Meeting agrees on sticking to planning, which is moving to BCon3 today. > There's only three weeks left for doing a next release, which we better > spend on stabilizing and a massive bug attack... the amount of tracker > reports went close to 150 already. > > - Based on the available coders, the following targets were moved: > > - Cycles: new hair shaders - including Kajiya-Kay. > - Cycles Ubershader' > - Pie menus > - Save and load "template" blend files > > - Multiview and OpenEXR 2.0 migration: suggested is to move that as well, > but Dalai Felinto can plea his case still (if he insists :). Brecht van > Lommel is available next week for review. > > - Updated release target list: > http://wiki.blender.org/index.php/Dev:Doc/Projects#2.6x_release_cycle > > - Python auto-run script becomes "disabled" as default. Proposal for a > good UI to handle this will be reviewed this week. > > 2) Other projects > > - GSoC branches for students can be added now. Naming convention will be: > soc-2013-name > Where 'name' is descriptive, or name of developer. Student and mentor > can decide together on it. Help with adding branches you can ask Sergey, > Brecht or Campbell for. > > > -Ton- > > > Ton Roosendaal - t...@blender.org - www.blender.org > Chairman Blender Foundation - Producer 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] Install deps script error at OIIO
JamesNZ, You said Python 3 was installed. It appears that in order to build OIIO, it needs Python 2.6, which is incompatible with Python 3. Python 3 is required to build Blender, but not every project has switched yet. You may have to install Python 2.6 alongside Python 3 in order to build OIIO. I hope this helps. Gavin Howard On Fri, Jun 14, 2013 at 8:01 PM, James Wrigley wrote: > Hi there, > > The install deps script is failing at OIIO on Fedora 19 TC3, 64bit, > fully updated. > Error log is here: http://www.pasteall.org/43153/text > Python3, python3-devel, and python3-libs are already installed. > Any ideas? > > Thanks, > JamesNZ > ___ > 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] UI Ideas - Hello community
Neal, Thank you for your interest in helping with Blender. You'll be happy to know that Blender already has a tool to scale two axes uniformly; it's just not easily visible. Blender users learn a lot of shortcuts that allow them to work at a fast pace. Accessing this tool is usually done by shortcut (there are other ways). However, suggestions are welcome. That said, you need to know that the mailing list did not take your screenshot attachment. The best way to make it accessible to the list is to go to http://www.pasteall.org/pic/, upload it there, and then provide a link in your mailing list email. Hopefully that all makes sense. Gavin Howard On Sat, Jun 15, 2013 at 11:33 AM, Neal Connolly wrote: > Hi, > I've recently begun working with blender and have had just few thoughts > about how to improve the blender UI. > I'm not sure where the best place to submit ideas to would be. > I was thinking it would be great add in a tool to scale two axis uniformly > together at the same time. > I've mocked up what the UI could look like with my attached screen shot. > Best Regards, > Neal Connolly > UI Designer > > ___ > 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 developers meeting - June 16no, 2013
Hello all, Quick question: does the switch to OpenEXR mean that developers (or anyone that compiles on their own machine), who run Linux, need to rerun the install_deps script to update their libraries? Gavin Howard On Jun 16, 2013 9:06 AM, "Ton Roosendaal" wrote: > Hi all, > > Here's the notes of today's meeting in irc.freenode.net #blendercoders > > 1) Blender 2.68 projects > > - Release planning overview updated: > http://wiki.blender.org/index.php/Dev:Doc/Projects#2.6x_release_cycle > > - Brecht van Lommel did Multiview branch review. It progresses well, but > has enough open issues to better schedule it after 2.68 release. > > - We do switch to OpenEXR 2.0 for all release builds though. > Campbell Barton or Sergey Sharybin will handle the update for Linux > platform. For OS X and Windows this has been done last week. > > - Jeffrey Hoover (Italic_ in irc) volunteered to install a build-slave, > and provide daily Windows builds for MSVC 32/64 bits, and for MingW 64 bits > build. > > - Python security: Blender now defaults to load files "Untrusted". That > can make some files not work when get them, especially for animation > drivers. The UI will indicate this clearly though. > > This week, Campbell will add the option in User Preferences to mark > directories to have untrusted files - if "trusted" is default - or the > other way around. That will allow you to mark your browser's download > directory unsafe, and the rest of your files can auto-run scripts as usual. > > 2) Other projects & GSoC > > - GSoC starts officially tomorrow! People interested in seeing progress or > reviewing work for students should join this mailing list: > http://lists.blender.org/mailman/listinfo/soc-2013-dev > > Note: especially artists are invited to closely keep an eye on developers > who work on their favourite tools! > > Thanks, > > -Ton- > > > Ton Roosendaal - t...@blender.org - www.blender.org > Chairman Blender Foundation - Producer Blender Institute > Entrepotdok 57A - 1018AD Amsterdam - The Netherlands > > > > ___ > Bf-committers mailing list > Bf-committers@blender.org > http://lists.blender.org/mailman/listinfo/bf-committers > ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] BGE Future
r engine. Again, I hope this email has not offended anyone or stepped on anyone's toes. If it has, I am sorry. God Bless, Gavin Howard ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] install_deps patch
All, This past week, I had problems compiling. Embarrassing. Anyway, point being, I ended up reinstalling my OS, so I had to run install_deps.sh again. This time, because OpenEXR has been promoted to 2.0, I compiled it on my machine. I also made sure I ran the script under dynamic linking. When I finally got Blender compiling again, I tried to run it, and my terminal said that the shared object file didn't exist. Well, last time that happened to me was when I forgot to change the config on my computer and run ldconfig after boost was compiled. I put in an openexr conf file and ran ldconfig. It worked. Because of that, I have submitted a patch to add openexr to the config if it was compiled. The patch is #35897 at http://projects.blender.org/tracker/index.php?func=detail&aid=35897&group_id=9&atid=127. Please review it and let me know if I can commit it to svn. Thanks. God Bless, Gavin Howard ___ 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...
+1 to the last 3-column layout with no headers. Gavin H. On Sat, Jul 6, 2013 at 10:36 PM, David Jeske wrote: > > > > Maybe something like this, with 2 columns: > > http://www.pasteall.org/43817 > > > > Not saying this is ideal, but I think trying to fit everything in > > columns with a single title per column constraints things too much. > > > > I think any of these non-flipping layouts would be a big improvement. The > reason I'm going wider is to keep the common views within mouse-reach when > menu opens "up". Below is a reachability comparison. I think the > difference in everyday usability would be significant. (Keeping 3d-view > close is one of the justifications I hear for today's "flipping" menus) > > http://www.pasteall.org/pic/show.php?id=55034 > > As for the headers, we could just drop them. They are not a very important > part of layout waypointing, memory, or everyday usability. They are mostly > for new-users to get some idea what the categories are. However, if there > isn't enough ontological correctness they confuse more than help. > > What do you/folks think about this 3 column layout? .. with no headers > > http://www.pasteall.org/pic/show.php?id=55036 > > It's the same as your ordering, except I put Node-Editor with the "main" > stuff on the left because I think the compositor is as good a "main view / > start-point" as the other things over there. (ignore the kind of nasty > extra space below "Editor Type".. it's a byproduct of the current menu code > and could be fixed) > ___ > 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 [58987] branches/soc-2013-cycles_mblur: Merged trunk into branch.
Thomas, I know that I have been merging a lot. Maybe it's because of my bad experience previously where a merge went wrong and I had to reset my branch. Usually, the metric I use is how many files were changed, and since Campbell was doing code cleanup, a lot of files were getting changed. So, sorry. I'll try to be less scared of merging in the future. But perhaps you can understand my fear? :) God Bless, Gavin Howard On Aug 7, 2013 1:42 AM, "Thomas Dinges" wrote: > Hi Gavin, > merging often is ok, but merging 4x in only 36 hours? > > That's a bit overkill imho. :) > > Am 07.08.2013 07:54, schrieb Gavin Howard: > > Revision: 58987 > > > http://projects.blender.org/scm/viewvc.php?view=rev&root=bf-blender&revision=58987 > > Author: gdh > > Date: 2013-08-07 05:54:02 + (Wed, 07 Aug 2013) > > Log Message: > > --- > > Merged trunk into branch. Includes r58971 to r58984. > > > -- > Thomas Dinges > Blender Developer, Artist and Musician > > www.dingto.org > > ___ > Bf-committers mailing list > Bf-committers@blender.org > http://lists.blender.org/mailman/listinfo/bf-committers > ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Patch to allow recording of static objects in game engine
James, Even if it can't be applied for 2.69, you can do something else. You can teach the club how to BUILD Blender on their own machines. Of course, I don't know if they would like that, but if they would, then you can teach them how to apply the patch to the sources, build, and then test it. It might be pretty fun for them to have a "customized Blender". God Bless, Gavin Howard On Sun, Sep 8, 2013 at 10:51 AM, James Yonan wrote: > Can this patch be considered for inclusion in 2.69? All feedback has > been incorporated, and the patch has been in the field for several > months (applied to 2.68a) with no known issues. > > > https://projects.blender.org/tracker/index.php?func=detail&aid=35183&group_id=9&atid=127 > > I'm going to be hosting a Blender club at my son's elementary school, > and we need this patch, otherwise we can't record the animation of > static objects that are controlled by logic bricks, which means that we > can't do cool stuff like this: http://www.youtube.com/watch?v=yltDGgW4jd0 > > One could argue that this is a bug fix, since the capability to record > the animation of static objects existed in previous blender versions (< > 2.60) and was removed without explanation. > > James > > On 01/05/2013 03:32, Dalai Felinto wrote: > > Hi James, > > Could you upload the patch in the blender tracker? > > http://projects.blender.org/tracker/?atid=127&group_id=9&func=browse > > > > It's better to discuss eventual changes there > > (and an example file there would help as well). > > > > My only concern with the patch (and we are better off discussing that in > > the tracker) is that I would probably have a m_animate property > > (instead of objprop.m_static_animate). > > This way we don't need to check IsDynamyc() inside RecordAnimation(). > > > > That also means that if you have a dynamic object and temporary disable > its > > Dynamics (via logic bricks) the object will still has its movements > > recorded, which I think it's reasonable (it may already happen, not sure > if > > the actuator affects the result of IsDynamic() - too late now for me to > > check the code ;). > > > > Nice video by the way. > > > > Thanks, > > Dalai > > ___ > > Bf-committers mailing list > > Bf-committers@blender.org > > http://lists.blender.org/mailman/listinfo/bf-committers > > > ___ > Bf-committers mailing list > Bf-committers@blender.org > http://lists.blender.org/mailman/listinfo/bf-committers > ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] Gooseberry VCS?
Hey all, Right now, I'm listening to the Blender Podcast Episode 27, talking about the upcoming Gooseberry project, with its "distributed studio" requirements. With those requirements in mind, I thought I would again bring up a suggestion I made a long time ago. This suggestion is based on the fact (or myth, whichever is the case) that blend files are merely a "binary dump". Because Gooseberry will require coordination with studios across the globe, I think that implementing an internal "version control system" specifically for blend files would make it MUCH easier to manage all of Gooseberry's assets. In my mind (twisted as it may be), I see it using Git-like algorithms. Because blend files are binary dumps (which as I understand it, means that each section, or property in the file is separate from the others), it would generate diffs based on different sections. For example, say we have a blend file with a model and a material. The artist takes the file, changes the material, and recommits the file. The diff would show that only the material changed. Obviously, artists make a lot of changes between uploading, so that may not be entirely feasible. However, if we were to add the concept of "micro-diffs", that might help. In my mind, a micro-diff is ONE change only, and a diff would be a list of micro-diffs. (This actually could also help clean up the undo/redo system too.) Of course, I have a lot more in mind than I'm saying, but before I say more, I want to hear devs' opinions. If this is really not feasible, I'm fine with that. I know that I don't understand even a sliver of what goes on (as demonstrated when I failed this summer in GSoC). But I wanted to at least get it out there and see what real devs think. Thanks! Gavin Howard ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
