Re: [Bf-committers] A practical proposal for the task of re-licensing Blender
I don't think *anyone* is suggesting that the Blender code end up in some closed source software. We're looking at making Blender capable (legally) of using third-party distributed closed-source plugins. This is about *extending* Blender, not taking parts of it and making them proprietary. No, it's not a debate about how to legally use third-party closed source plug-ins in Blender. If you go back you'll see that the main premise of this debate was Big Silicon Valley companies are not using GPL software (eg. Blender) because of fear that their own proprietary software would get polluted with GPL so they would have to publish their code. And the beginning conclusion was that if they could use Blender source without that fear they would have more willingness to contribute to Blender source code. I'm sorry but I don't believe in that. Have you seen any big commercial company that has started to create commercial plug-ins for GIMP or to contribute to GIMP source? And I must say that term polluting is quite significant because it really shows how those companies are looking on free software. Regarding making plug-ins for blender, in GPL FAQ is stated this: *Can I write free software that uses non-free libraries?* If you do this, your program won't be fully usable in a free environment. If your program depends on a non-free library to do a certain job, it cannot do that job in the Free World. If it depends on a non-free library to run at all, it cannot be part of a free operating system such as GNU; it is entirely off limits to the Free World.I'm not an C or C++ programmer but as I understand this, If someone creates commercial plug-in for blender (eg. raytracer) in DLL form, Blender can call that dll on Windows system. Only thing that creator of that dll would have to disclose are dll calls, am I right? And since Blender doesn't really need that dll to work, it can be used on Linux or any other system as well. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] A practical proposal for the task of re-licensing Blender
On Thu, Nov 25, 2010 at 12:42 AM, Damir Prebeg blend.fact...@gmail.com wrote: I don't think *anyone* is suggesting that the Blender code end up in some closed source software. We're looking at making Blender capable (legally) of using third-party distributed closed-source plugins. This is about *extending* Blender, not taking parts of it and making them proprietary. No, it's not a debate about how to legally use third-party closed source plug-ins in Blender. Uh, that is exactly the reason I've joined this discussion. And I think that is the reason most people here are discussing this topic as well. I've got nothing against big Silicon Valley companies, but the main issue is that third-party closed plugins simply can't coincide with the GPL unless you somehow break the GPL, and that is something I would like to see changed. If I somehow gave you some other impression please excuse me. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] A practical proposal for the task of re-licensing Blender
@Knapp There are a billion closed source applications in this world, and yet you are not starving. Neither will you be starving if there is one more closed source application in the world. I should know by now not to joke in internationally read emails. :-) Before I, grew up, and moved from windows to Linux my computer was completely full of stolen software including the OS. As a young high school student with a poor family, it was the only way to have all the software that I wanted to make art and to program. I felt a little bad about that but not very. I have even read reports about how Gates like this because it locks users into the MS system because they invest so much time in the system. I have met VERY few MS users that have no stolen software on their computers. For the last 28 years I have had a completely legal computer and have done my best to give back to all the projects that let this happen. If all the users do as I do (and a lot do) we will have the very best computer systems in the world. Letting people take that community effort and use it for their own personal benefit without giving back to that same community is a bit wrong IMOHO. An artist uses Blender to create some art work, and they decide to sell it. Nobody complains. It took the artist years of training and weeks of effort to make their product. Nobody says You used Blender to make your product, Blender is free, you must make your product free or we will sue you. True, but hopefully that same artist gives back to the community by helping others, writing code, or just by saying Blender is cool and I made this art with blender thus bring in more users and developers or perhaps giving back money to the project. The problem with firms is that they have a mandate to make profit and nothing strong making them give back to the people they take that profit from. I don't want to argue this and I know there is a lot of room to do so but that is the fundamental issue here. Should they be allowed to do so? Or should we just trust them to do right by blender. A programmer comes along, the programmer does not modify Blender but instead writes a separate program which uses Blender to do something special, something which Blender can not do right now. It took the programmer years of training and weeks of effort to make their product. Just as much skill and effort as the artist. Yes, true. But now everyone screams at them You used Blender to make your product, Blender is free, you must make your product free or we will sue you. I can understand people would be upset if the programmer had modified Blender but he did NOT modify Blender at all, he simply used Blender in a similar way that an artist would use Blender to create artwork. Except that art work is not something that you can easily take and add to to make a better work, programming is. Programs take a HUGE amount of work to make, they take a huge number of people to make. We with GPL are saying that we want to make this product in a community setting where everyone contributes to the project and no one can come along and take that work for themselves without helping to make it better. In many ways GPL is saying that if you want to play with our cool toys then help us to make it. Art projects can also take this approach if they would like to. LGPL would allow this programmer to earn a living just like an artist, but GPL would put this programmer in jail for not making their product free. It is simple, play by our rules or else. This group of blender people picked rules to play by. I think it is great to debate that decision and to look for better ways but it is not great to open up GPL and let others play with our toys without helping to make them. If you are still confused please re-read the beginning of this email. I was never confused about this and find that statement a bit insulting but I will drop it. -- Douglas E Knapp Creative Commons Film Group, Helping people make open source movies with open source software! http://douglas.bespin.org/CommonsFilmGroup/phpBB3/index.php Massage in Gelsenkirchen-Buer: http://douglas.bespin.org/tcm/ztab1.htm Please link to me and trade links with me! Open Source Sci-Fi mmoRPG Game project. http://sf-journey-creations.wikispot.org/Front_Page http://code.google.com/p/perspectiveproject/ ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Nameable group node sockets and other improvements
Hi Lukas, From the video, this looks very nicely done, I'll go over the patch later. Brecht. On Thu, Nov 25, 2010 at 8:22 AM, Lukas Tönne lukas.toe...@googlemail.com wrote: Here's a small video demoing the feature: http://www.youtube.com/watch?v=OUidTgzy8zo On Wed, Nov 24, 2010 at 1:28 PM, Lukas Tönne lukas.toe...@googlemail.com wrote: As part of the ongoing work on the particles-2010 branch i decided to address some of the nagging issues of group nodes. While nice in theory, the usability of node groups suffers from bad behavior and missing features to reveal its true power. Three things in particular i would like to fix: * External sockets should be renameable to give some meaning to the parameters and outputs of a complex group. * The order of external socket should be changeable (e.g. to stress different importance of sockets). * The internal sockets that get an external counterpart should be selectable explicitly, instead of having to use ugly workarounds to hide some of them. The first of these has now been implemented as a patch for trunk (which i will port to the particles branch too of course). It seems to work very well, but since i had to change some of the inner workings of group nodes, it could use some more testers. See the patch description for details. https://projects.blender.org/tracker/index.php?func=detailaid=24883group_id=9atid=127 There are certainly more features that would be nice to have for nodes (nested groups, more ui improvements), but these three can be implemented quickly. Cheers, Lukas Tönne ___ 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] S-DNA and Changes
Hi all, I've now started to dig into the codebase - and the VSE in particular. The workings seem fairly straightforward, but as far as changing things I must ask your advice. The problem is the S-DNA representation of the VSE data. The structures used in the VSE, and also written to the blend file, are strongly coupled to the current workings of the VSE. Not an unsurmountable obstacle, but something which requires extra care when changing things. So, my question is this: How has this been handled historically? I can't be the first one to run into this. For the sake of argument: Suppose I want to make really big changes to the VSE - should I... 1. Write a VSE 2 and create all-new structures? 2. Create some kind of compatibility loader or data import filter that converts the old data to the new, as far as possible? That is, we read old and new formats, but only write new format. 3. Convert the old structs to the new in-memory? That is, we read and write the old format, maybe with some back-compatible changes, but use a new format internally? /LS ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Status of C++
All, thanks for the advice. I have no problem following those recommendations. /LS ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] Documenting the VSE
Hello, after digging into the VSE, I couldn't help bu notice that the documentation is a bit terse. I was thinking about submitting some patches consisting of doxygen docs for parts of it - mostly concerning its external interface and connection to the pipeline.c code. Is now a good time to do so, or is that module up for serious reworking? Or is it your experience that code comments end up obsolete and wrong really fast in Blender? /LS ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] A practical proposal for the task of re-licensing Blender
Developing/improving on any code which some other company may be using for making money doesn't make sense, because then you are probably helping improve their program, for which they get more users and more money, which in turn reduces our users money, thus hampering even our speed of development.. That is a negative-feedback loop. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Documenting the VSE
On Thu, Nov 25, 2010 at 4:13 PM, Leo Sutic leo.su...@gmail.com wrote: Hello, after digging into the VSE, I couldn't help bu notice that the documentation is a bit terse. I was thinking about submitting some patches consisting of doxygen docs for parts of it - mostly concerning its external interface and connection to the pipeline.c code. Is now a good time to do so, or is that module up for serious reworking? Or is it your experience that code comments end up obsolete and wrong really fast in Blender? /LS Sounds fine to me, Peter Schlaile is the module owner though so best check with him too. Though best to leave anything in the render/ directory since it could make merging the durian render branch more trouble. Comments in DNA_sequence_types.h seq*.c are safe. Just make sure a developer who understands the code is able to review, a problem with having newer devs add comments is some important aspect may be misinterpreted/overlooked. -- - Campbell ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] A practical proposal for the task of re-licensing Blender
Hi, All things considered I'm apathetic towards LGPL switch. Its still quite restrictive, and I'm not aware of any commercial extensions for blender so far, even though its possible to write them without changing to LGPL. May I point out that existing blender developers are not pushing for this, one might consider if they had trouble feeding their families that this would be of interest to them. So with a less restrictive license I would write a commercial plugin for blender, sit back and earn an income, right? The thing is, I don't want to make money this way, even if I could earn more then GPL dev. Its just not a fun way to do development, so it would make me less interested to be a blender developer if this is the kind of people we have to interact with on the mailing list, irc, etc. I think we can better focus on services and support model for income, it may earn less short term but we will have more satisfied users. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] Planet texture patch
Hi all :)
well, I was expecting the GPU gems procedural parts before releasing the
patch in order to add others if needed but it didn't arrived.
some use advice:
at small scales (i.e the default textures values) it is a curl like
texture but at larger scales (size 1.0) and with 6 octaves in hard/soft
mode then it show the true planet procedural texture goodness :)
Anyway, here's the patch, is very easy and don't disrup any existent
Blender code so is pretty safe:
http://www.pasteall.org/17124/diff
//-
Index: release/scripts/ui/properties_texture.py
===
--- release/scripts/ui/properties_texture.py(revision 32153)
+++ release/scripts/ui/properties_texture.py(working copy)
@@ -444,8 +444,33 @@
col = split.column()
col.prop(tex, nabla, text=Nabla)
+
+class TEXTURE_PT_planet(TextureTypePanel, bpy.types.Panel):
+bl_label = Planet
+tex_type = 'PLANET'
+COMPAT_ENGINES = {'BLENDER_RENDER', 'BLENDER_GAME'}
+def draw(self, context):
+layout = self.layout
+tex = context.texture
+
+layout.prop(tex, planet_type, expand=True)
+layout.label(text=Noise:)
+layout.prop(tex, noise_type, text=Type, expand=True)
+layout.prop(tex, noise_basis, text=Basis)
+
+split = layout.split()
+
+col = split.column()
+col.prop(tex, noise_scale, text=Size)
+col.prop(tex, noise_depth, text=Depth)
+
+col = split.column()
+col.prop(tex, nabla, text=Nabla)
+
+
+
class TEXTURE_PT_wood(TextureTypePanel, bpy.types.Panel):
bl_label = Wood
tex_type = 'WOOD'
Index: source/blender/blenkernel/intern/node.c
===
--- source/blender/blenkernel/intern/node.c (revision 32153)
+++ source/blender/blenkernel/intern/node.c (working copy)
@@ -3185,6 +3185,7 @@
nodeRegisterType(ntypelist, tex_node_proc_noise);
nodeRegisterType(ntypelist, tex_node_proc_stucci);
nodeRegisterType(ntypelist, tex_node_proc_distnoise);
+ nodeRegisterType(ntypelist, tex_node_proc_planet);
}
static void remove_dynamic_typeinfos(ListBase *list)
Index: source/blender/editors/space_node/drawnode.c
===
--- source/blender/editors/space_node/drawnode.c(revision 32153)
+++ source/blender/editors/space_node/drawnode.c(working copy)
@@ -1202,6 +1202,15 @@
uiItemR(row, tex_ptr, noise_type, UI_ITEM_R_EXPAND,
NULL, 0);
uiItemR(col, tex_ptr, noise_depth, UI_ITEM_R_EXPAND,
Depth, 0);
break;
+
+ case TEX_PLANET:
+ uiItemR(col, tex_ptr, noise_basis, 0, , 0);
+ row= uiLayoutRow(col, 0);
+ uiItemR(row, tex_ptr, stype, UI_ITEM_R_EXPAND, NULL,
0);
+ row= uiLayoutRow(col, 0);
+ uiItemR(row, tex_ptr, noise_type, UI_ITEM_R_EXPAND,
NULL, 0);
+ uiItemR(col, tex_ptr, noise_depth, UI_ITEM_R_EXPAND,
Depth, 0);
+ break;
case TEX_DISTNOISE:
uiItemR(col, tex_ptr, noise_basis, 0, , 0);
Index: source/blender/makesdna/DNA_texture_types.h
===
--- source/blender/makesdna/DNA_texture_types.h (revision 32153)
+++ source/blender/makesdna/DNA_texture_types.h (working copy)
@@ -294,6 +294,7 @@
#define TEX_DISTNOISE 13
#define TEX_POINTDENSITY 14
#define TEX_VOXELDATA 15
+#define TEX_PLANET 16
/* musgrave stype */
#define TEX_MFRACTAL 0
Index: source/blender/makesrna/intern/rna_texture.c
===
--- source/blender/makesrna/intern/rna_texture.c(revision 32153)
+++ source/blender/makesrna/intern/rna_texture.c(working copy)
@@ -66,6 +66,7 @@
{TEX_VORONOI, VORONOI, ICON_TEXTURE, Voronoi, },
{TEX_VOXELDATA, VOXEL_DATA, ICON_TEXTURE, Voxel Data, },
{TEX_WOOD, WOOD, ICON_TEXTURE, Wood, },
+ {TEX_PLANET, PLANET, ICON_TEXTURE, Planet, },
{0, NULL, 0, NULL, NULL}};
#ifdef RNA_RUNTIME
@@ -119,6 +120,8 @@
return RNA_VoxelDataTexture;
case TEX_WOOD:
return RNA_WoodTexture;
+ case TEX_PLANET:
+ return RNA_PlanetTexture;
default:
return RNA_Texture;
}
@@ -706,6 +709,60 @@
RNA_def_property_update(prop, 0, rna_Texture_update);
}
+static void rna_def_texture_planet(BlenderRNA *brna)
+{
+ StructRNA *srna;
+ PropertyRNA *prop;
+
+ static EnumPropertyItem prop_planet_stype[] = {
+ {TEX_DEFAULT, GREYSCALE, 0, Greyscale, },
+
Re: [Bf-committers] S-DNA and Changes
Hi Leo, 1. Write a VSE 2 and create all-new structures? this will break compatibility with older versions of blender. Should only be done as a last resort and if you *really* know, what you are doing. 2. Create some kind of compatibility loader or data import filter that converts the old data to the new, as far as possible? That is, we read old and new formats, but only write new format. that is *always* necessary, otherwise, you can't open old files or make sure, that on load of an old file, your new structure elements are initialized properly. This is done in doversions() in readfile.c . 3. Convert the old structs to the new in-memory? That is, we read and write the old format, maybe with some back-compatible changes, but use a new format internally? nope. After each editing operation, DNA data has to be in sync, since DNA load/save is also used on undo operations(!). I'd also suggest, that you first try to make sure, that you *have* to change something, and why. Since, you guessed it, you will most likely make some people unhappy, that want to open their new .blend file with an old version and see things broken all over the place. So I'm a bit wondering, what you want to change? I tried to understand the blog post you linked some days ago. To quote your blog: (disadvantages of the current system) 1.1. Disadvantages The disadvantages come when we wish to perform any kind of processing that requires access to more than just the current frame. The frames in the sequencer aren't just random jumbles of image data, but sequences of images that have a lot of inter-frame information: Object motion, for example, is something that is impossible to compute given a single frame, but possible with two or more frames. Another use case that is very difficult with frame-wise rendering is adjusting the frame rate of a clip. When mixing video from different sources one can't always assume that they were filmed at the same frame rate. If we wish to re-sample a video clip along the time axis, we need access to more than one frame in order to handle the output frames that fall in-between input frames - which usually is most of them. To be honest: you can't calculate the necessary optical flow data on the fly, and: most likely, people want to have some control over the generation process. (Maybe they just want to use externally generated OFLOW files from icarus?) To make a long story short: we should really just add a seperate background rendering job, to add optical-flow tracks to video tracks, just like we did with proxies, only in the background with the new job system and everything should be fine. (For scene tracks or OpenEXR-sequences with a vector pass, there even is already optical flow information available for free(!) ) In between frames should be handled with float cfras (the code is already adapted at most places for that) and the new additional mblur parameters. That has the additional advantage, that you can actually *calculate* real inbetween frames in scene tracks. For other jobs, like image stabilisation, you should just add similar builder jobs. (Which most likely don't have to write out full frames, but just generate the necessary animation fcurves.) The implications of your track rendering idea is - scary. Either you end up with a non-realtime system (since you have to calculate optical flow information on the fly in some way, which is, to my knowledge, not possible with current hardware) or you have to render everything to disk - always. I, as a user, want to have control over my diskspace (which is very valuable, since my timelines are 3 hours long, and rendering every intermediate result to disk is *impossible*!). Or, to put it another way: please show a case to me, that *doesn't* work, with a simple background builder job system, where you can add arbitrary intermediate data to video, meta or effect tracks. Having to access multiple frames at once during playback *and* doing heavy calculation on them doesn't sound realtime to me by definition, and that is, what Ton told me, the sequencer should be: realtime. For everything else, the Compositor should be used. You could still use RenderMode: (CHUNKED, SEQUENTIAL and FULL) to make that background render job run in the most efficient way. But it is still a background render job, which is seperated from the rest of the pipeline. As always, feel free to proof me wrong. If I got it correctly, your interface idea looks like a good starting point for a background builder system interface. So probably, if you convince everyone, that this is the best thing to do for playback, too, we might end up promoting your builder interface to the preview renderer, who knows? BTW: I'm currently rewriting the sequencer render pipeline using a generic Imbuf-Render-Pipeline system, which will move some things around, especially all those little prefiltering structures will find
Re: [Bf-committers] S-DNA and Changes
Hi Peter, thank you for your feedback on the SDNA. You bring up some very good points, let me try to address them quickly: On 2010-11-25 19:45, Peter Schlaile wrote: Or, to put it another way: please show a case to me, that *doesn't* work, with a simple background builder job system, I thought about that yesterday, actually, because it seemed such a simple solution. But let's consider the background builder job itself. In principle, there is nothing that can't be factored out as a background builder job. I mean, I can do anything I want in an external program and then just place the end result in Blender. But then I have to build a UI for my stabilization program, and the whole purpose of doing any work on Blender was to put my stabilization algorithms there in order to have a nice UI. By nice I mean to be able to combine video effects in the VSE much like I can combine nodes in the compositor. I want to be able to apply stabilization, interpolation, etc. by stacking effect strips. Combinatorial power, I think it is called. This means that the background builder job ends up being more or less a render in anything but name. It needs access to the same data as a render - output from previous effect strips. That's why I need to involve the main rendering pipeline. I wish I didn't have to. The implications of your track rendering idea is - scary. Either you end up with a non-realtime system (since you have to calculate optical flow information on the fly in some way, which is, to my knowledge, not possible with current hardware) or you have to render everything to disk - always. I, as a user, want to have control over my diskspace (which is very valuable, since my timelines are 3 hours long, and rendering every intermediate result to disk is *impossible*!). Correct, it is impossible. You've asked this once before (way back), I replied in: http://lists.blender.org/pipermail/bf-committers/2010-September/028825.html and you thought: that sounds indeed usefull http://lists.blender.org/pipermail/bf-committers/2010-September/028826.html Short-short summary: The system need not do it the naive way and write out every frame. We can also optimize away a lot frames being held concurrently in memory by using smart algorithms. The current state of the prototype code is that *nothing* is being written to disk, and it never renders more frames than absolutely needed. Eventually I might need to include the option of writing out some things to disk but I consider that a last resort, and only for operations that the user *knows* will cost a lot of disk. This, however, is not a consequence of the strip-wise rendering algorithm itself, but of the processing we want to do. /LS ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] A practical proposal for the task of re-licensing Blender
On Thu, Nov 25, 2010 at 8:55 AM, Campbell Barton ideasma...@gmail.com wrote: Hi, All things considered I'm apathetic towards LGPL switch. Its still quite restrictive, and I'm not aware of any commercial extensions for blender so far, even though its possible to write them without changing to LGPL. May I point out that existing blender developers are not pushing for this, one might consider if they had trouble feeding their families that this would be of interest to them. So with a less restrictive license I would write a commercial plugin for blender, sit back and earn an income, right? The thing is, I don't want to make money this way, even if I could earn more then GPL dev. Its just not a fun way to do development, so it would make me less interested to be a blender developer if this is the kind of people we have to interact with on the mailing list, irc, etc. I think we can better focus on services and support model for income, it may earn less short term but we will have more satisfied users. Well for a thread which has been apparently dropped it certainly seems to be an interesting an active topic. And I must say that when the thread started I was rather unhappy with the general tone of the responses but as things have progressed I think the responses have gotten a lot better even though they are still generally anti-LGPL. So I would like to reply to this latest batch of responses, but I'm not trying to reopen the debate, I consider the debate to be closed. @Knapp. Thomas Prashant Campbell I completely negative feeling towards the Windows system, that was my experience as well, and it has also been my experience since switching to linux years ago that I have felt better about my system not running on stolen software. But when you say this: Letting people take that community effort and use it for their own personal benefit without giving back to that same community is a bit wrong IMOHO Artists take it and use it and generally do not give back. Writers take it and use it and generally do not give it back. Web users take it and use it and generally do not give back. Office users take it and use it and generally do not give back. You are making one exception, programmers, they must not use it unless they give back 100%. But what I am saying is that there is likely a group of programmers who will simply not _ever_ use it if they are forced to play by those rules. Now ask yourself, why do we release free software for closed environments like Windows, and Macs? Is it not because although we do not agree with those closed environments we know that a good way to get people to switch to an open model is to allow them use it and test it and slowly make the change to a free platform? What I am saying is that there would be two similar benefits to closed extensions. First, programmers who right now would not consider developing an extension for blender because of the GPL might consider it since they might view it as an opportunity to make money. Don't be upset with that view, artists look at Blender with just as greedy eyes, and similarly office users look at Libreoffice (openoffice) the same way, it is an opportunity for them to make or save money. There is nothing wrong with a programmer who wants to make/save money. Second, if these programmers do develop an extension for Blender they may become invested in Blenders future, if Blender becomes more popular then they have more opportunity to sell their extension, so they suddenly want Blender to become more popular. They see that Blender has a bug, so they contribute some code to Blender to fix it. Remember, Blender itself will always be open source, any change to Blender itself must be made public if any of the code is distributed. This is what has happened with Linux, do you think IBM really cares about open source? I don't. I think they care about money. They make money with Linux and so they are invested in Linux's future, they want Linux to be as good as it possibly could be because then they make more money so they have been actively contributing open source code to Linux for years, and they see their profits go up. I doubt there is an IBM out there for Blender just waiting to contribute, but what if there is a single programmer and one or two of his friends who want to make a small company and they are interested in the 3D modeling/animation/design industry. Right now they would look at Blender and say wow wouldn't that be great, too bad it is GPL, and so then they would go and start working on a 3DMax extension, or a Maya extension. It is no problem for them, they can just pick another platform, it is a problem for us because they didn't pick ours. The existing Blender developers (see Campbells most recent email) have said that they would not want to write closed extensions anyway so people who are worried that allowing closed extensions would somehow lessen Blender developers are wrong, it would only increase
Re: [Bf-committers] S-DNA and Changes
Hi Leo, On 2010-11-25 19:45, Peter Schlaile wrote: Or, to put it another way: please show a case to me, that *doesn't* work, with a simple background builder job system, That's why I need to involve the main rendering pipeline. I wish I didn't have to. hmm, that's maybe a misunderstanding. I was talking about using the job system of blender 2.5 (which just forks another job within blender - not an external system/program!). So: still complete access to UI. You've asked this once before (way back), I replied in: http://lists.blender.org/pipermail/bf-committers/2010-September/028825.html and you thought: that sounds indeed usefull http://lists.blender.org/pipermail/bf-committers/2010-September/028826.html again, maybe a misunderstanding here. In that old post, I was more thinking of rendering seperate tracks in advance for prefetch rendering. Not: making CPU heavy stuff run in the previews. (But I didn't make that point really clear, that's true.) Short-short summary: The system need not do it the naive way and write out every frame. We can also optimize away a lot frames being held concurrently in memory by using smart algorithms. The current state of the prototype code is that *nothing* is being written to disk, and it never renders more frames than absolutely needed. Eventually I might need to include the option of writing out some things to disk but I consider that a last resort, and only for operations that the user *knows* will cost a lot of disk. This, however, is not a consequence of the strip-wise rendering algorithm itself, but of the processing we want to do. ok, point taken. I'm still a bit unsure about the CPU-heavy stuff, but I have to admit, that you could always add a proxy, if things start to get slow. Regarding your interface prototype: your interators should take a float increment parameter. (There isn't really a well defined next frame in float precision scene-rendering...) Otherwise: this could really work. Cheers, Peter Peter Schlaile ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] S-DNA and Changes
On 2010-11-25 21:54, Peter Schlaile wrote: Regarding your interface prototype: your interators should take a float increment parameter. (There isn't really a well defined next frame in float precision scene-rendering...) I decided against that due to the complications it resulted in - mostly because it became very difficult to get all frames to align in time when round-off errors may affect the float cfra parameter depending on how it was calculated. (It was also difficult for movie clip sources, again due to rounding errors, where you could end up on the wrong frame.) It was easier to just pretend, in the VSE, that each sequence was continuous, but sampled at a fixed rate. (So the frame rate should really be a field rate.) That way, the only time we risk that the frames don't line up is when we do framerate conversion - and everyone kinda expects them to not line up then. So what I have instead is that each sequence (strip) has an individual rate. That way I could slow down or speed up a sequence by altering the frame rate. An effect strip can then do motion interpolation or timelapse to convert the base sequence to the desired output framerate. So the renderer might have a float frame number, but the VSE only ever sees integer frame numbers. I'm just guessing regarding the float cfra parameter: Is it for motion blur? Then, for example, with output frame rate at 24fps: Strip 1: Movie clip, 60fps. Must be converted to output frame rate. Strip 2: Converts strip 1 to the output frame rate, 24 fps, by combining frames in strip 1. Strip 3: Movie clip 24 fps. Can be used as-is. Strip 4: Gamma cross 13 Strip 5: Blender scene, motion blur, 24fps with simulated shutter at 60fps. As far as the VSE is concerned, the output of this strip is 24fps. Strip 6: Combine 5 and 4 using alpha in 5. /LS ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] Armatures Bones Poses
Dear all, as Stefano already told you I'm writing a collada 1.4.1 importing plug-in. I'm now focusing on importing animations. For that I need to figure out how armature, and motion channels are defined in Blender. I'm using this documentation as reference: http://www.blender.org/development/release-logs/blender-240/how-armatures-work/ Please let me know in case you are aware of others documentation resources. I believe I understood how armature works, but, I still have some problems so I want to double check with you: 1)in POSE SPACE is the global position matrix of a bone given by: node global position matrix=global position of the parent * armature_bone_matrix * bone_action where: - armature_bone_matrix is the matrix that describes the local bone coordinates system with respect to its parent when the bone is in rest pose? - bone_action is the matrix whose rotational portion can be accessed in python in this way pose.bones[].pbone.quat? 2)In the ARMATURE SPACE (edit mode). - global bone matrices can be accessed in python in this way Armature.bones[].matrix[ARMATURESPACE] - referring to the above formula bone_action matrices are Identities therefore armature_bone_matrix can be computed in this way: armature_bone_matrix=global position of the parent^-1 * node global position matrix 3)In POSE SPACE: - Given the global position matrix of a bone G and of its parent P, can you confirm the bone action matrix is given by: bone_action = armature_bone_matrix^-1*(P^-1*G) Thanks for your help, Best regards, Emiliano ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] A practical proposal for the task of re-licensing Blender
El Thu, 25 Nov 2010 12:39:17 -0800 Alex Combas blenderw...@gmail.com escribió: On Thu, Nov 25, 2010 at 8:55 AM, Campbell Barton ideasma...@gmail.com wrote: Hi, All things considered I'm apathetic towards LGPL switch. Its still quite restrictive, and I'm not aware of any commercial extensions for blender so far, even though its possible to write them without changing to LGPL. May I point out that existing blender developers are not pushing for this, one might consider if they had trouble feeding their families that this would be of interest to them. So with a less restrictive license I would write a commercial plugin for blender, sit back and earn an income, right? The thing is, I don't want to make money this way, even if I could earn more then GPL dev. Its just not a fun way to do development, so it would make me less interested to be a blender developer if this is the kind of people we have to interact with on the mailing list, irc, etc. I think we can better focus on services and support model for income, it may earn less short term but we will have more satisfied users. Well for a thread which has been apparently dropped it certainly seems to be an interesting an active topic. And I must say that when the thread started I was rather unhappy with the general tone of the responses but as things have progressed I think the responses have gotten a lot better even though they are still generally anti-LGPL. So I would like to reply to this latest batch of responses, but I'm not trying to reopen the debate, I consider the debate to be closed. @Knapp. Thomas Prashant Campbell I completely negative feeling towards the Windows system, that was my experience as well, and it has also been my experience since switching to linux years ago that I have felt better about my system not running on stolen software. But when you say this: Letting people take that community effort and use it for their own personal benefit without giving back to that same community is a bit wrong IMOHO Artists take it and use it and generally do not give back. Writers take it and use it and generally do not give it back. Web users take it and use it and generally do not give back. Office users take it and use it and generally do not give back. You are making one exception, programmers, they must not use it unless they give back 100%. But what I am saying is that there is likely a group of programmers who will simply not _ever_ use it if they are forced to play by those rules. Now ask yourself, why do we release free software for closed environments like Windows, and Macs? Is it not because although we do not agree with those closed environments we know that a good way to get people to switch to an open model is to allow them use it and test it and slowly make the change to a free platform? What I am saying is that there would be two similar benefits to closed extensions. First, programmers who right now would not consider developing an extension for blender because of the GPL might consider it since they might view it as an opportunity to make money. Don't be upset with that view, artists look at Blender with just as greedy eyes, and similarly office users look at Libreoffice (openoffice) the same way, it is an opportunity for them to make or save money. There is nothing wrong with a programmer who wants to make/save money. Second, if these programmers do develop an extension for Blender they may become invested in Blenders future, if Blender becomes more popular then they have more opportunity to sell their extension, so they suddenly want Blender to become more popular. They see that Blender has a bug, so they contribute some code to Blender to fix it. Remember, Blender itself will always be open source, any change to Blender itself must be made public if any of the code is distributed. This is what has happened with Linux, do you think IBM really cares about open source? I don't. I think they care about money. They make money with Linux and so they are invested in Linux's future, they want Linux to be as good as it possibly could be because then they make more money so they have been actively contributing open source code to Linux for years, and they see their profits go up. I doubt there is an IBM out there for Blender just waiting to contribute, but what if there is a single programmer and one or two of his friends who want to make a small company and they are interested in the 3D modeling/animation/design industry. Right now they would look at Blender and say wow wouldn't that be great, too bad it is GPL, and so then they would go and start working on a 3DMax extension, or a Maya extension. It is no problem for them, they can just pick another platform, it is a problem for us because they didn't pick ours. The existing Blender developers (see Campbells most recent email) have said
Re: [Bf-committers] S-DNA and Changes
Hi Leo, Regarding your interface prototype: your interators should take a float increment parameter. (There isn't really a well defined next frame in float precision scene-rendering...) I decided against that due to the complications it resulted in - mostly because it became very difficult to get all frames to align in time when round-off errors may affect the float cfra parameter depending on how it was calculated. (It was also difficult for movie clip sources, again due to rounding errors, where you could end up on the wrong frame.) It was easier to just pretend, in the VSE, that each sequence was continuous, but sampled at a fixed rate. (So the frame rate should really be a field rate.) That way, the only time we risk that the frames don't line up is when we do framerate conversion - and everyone kinda expects them to not line up then. uhm, ouch. OK, do it differently, tell the next()-iterator the absolute next-cfra not the increment, but please make it a float, because... I'm just guessing regarding the float cfra parameter: Is it for motion blur? ... it's not about motion blur, it's about retiming. If CFRA is float, you can retime a scene strip afterwards and have it render subframe precision frames (read: extrem slowdowns), which are done the real way, not using fake interpolation. Cheers, Peter Peter Schlaile ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] S-DNA and Changes
On 2010-11-25 23:40, Peter Schlaile wrote: Hi Leo, Regarding your interface prototype: your interators should take a float increment parameter. (There isn't really a well defined next frame in float precision scene-rendering...) I decided against that due to the complications it resulted in - mostly because it became very difficult to get all frames to align in time when round-off errors may affect the float cfra parameter depending on how it was calculated. (It was also difficult for movie clip sources, again due to rounding errors, where you could end up on the wrong frame.) It was easier to just pretend, in the VSE, that each sequence was continuous, but sampled at a fixed rate. (So the frame rate should really be a field rate.) That way, the only time we risk that the frames don't line up is when we do framerate conversion - and everyone kinda expects them to not line up then. uhm, ouch. OK, do it differently, tell the next()-iterator the absolute next-cfra not the increment, but please make it a float, because... I'm just guessing regarding the float cfra parameter: Is it for motion blur? ... it's not about motion blur, it's about retiming. If CFRA is float, you can retime a scene strip afterwards and have it render subframe precision frames (read: extrem slowdowns), which are done the real way, not using fake interpolation. Ah, ok. I'd still try to stick with integer frames and a parameterless next(). Allowing the client to specify the advance in the next() method makes it too much of a random-access method (there is no guarantee that the advance is to the next frame, which is the whole purpose of the iterator interface). I'd do it this way: Suppose we have a scene where we want normal speed for frames 1-10, an extreme slowdown for 11-12 and normal speed from 13-20. Strip 1: Scene, frames 1-10. This strip covers frames 1-10 in the VSE. Strip 2: Scene, frames 11-12, with a framerate of 1/100th of the output framerate. This strip covers frames 11-211 in the VSE. Strip 3: Scene, frames 13-20. This strip covers frames 212-219 in the VSE. When the sequencer renders this, the next() for strip 1 and 3 will advance one scene-frame. The next() for strip 2 will advance 0.01 frames. That way, the VSE code only ever sees integer frames (although it does see different frame rates), and we can guarantee machine precision in the slowdown frame number calculation. The renderer, however, sees the fractional frames - but this is hidden behind the scene strip's code. (This also enables us to take a scene that was designed for 24p and render it at 60p with everything lining up properly.) Would this take care of the issue? I realize that we suddenly have a VSE cfra and a Scene cfra, but if you're going to have retiming through the VSE, then you already got that. /LS ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] RNA property updates vs anim sys
On Thu, Nov 25, 2010 at 4:10 AM, Campbell Barton ideasma...@gmail.com wrote: On Wed, Nov 24, 2010 at 5:08 AM, Matt Ebb m...@mke3.net wrote: One possible solution is to queue unique update functions for each update, per ID. A function pointer GHash a check/w previous comparison should make collecting unique functions quite fast. Then these can run at the end, per ID. Well if this is necessary, it would be great to see. I suspect the reason this hasn't caused more problems elsewhere is that the depgraph kind of overlaps with this behaviour and probably masks the effect for a lot of blender data (i.e. scene objects automatically getting updated via depgraph, regardless of update functions). Presumably this doesn't extend fully to texture data. Anyway, I can try to work around this for now by making a whole bunch of abusive property set functions to do what should really be done by update functions but it's something that really should be fixed. If the purpose of RNA is to provide a unified, consistent interface to UI, python, animation system, then it's quite a problem that changing values via UI or python does the right thing, but via the animation system it decides to just not run the code that it's been told to. cheers, Matt ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] S-DNA and Changes
Hi Leo,
Ah, ok.
I'd still try to stick with integer frames and a parameterless next().
Allowing the client to specify the advance in the next() method makes it
too much of a random-access method (there is no guarantee that the
advance is to the next frame, which is the whole purpose of the
iterator interface).
I'd do it this way:
Suppose we have a scene where we want normal speed for frames 1-10, an
extreme slowdown for 11-12 and normal speed from 13-20.
Strip 1: Scene, frames 1-10. This strip covers frames 1-10 in the VSE.
Strip 2: Scene, frames 11-12, with a framerate of 1/100th of the output
framerate. This strip covers frames 11-211 in the VSE.
Strip 3: Scene, frames 13-20. This strip covers frames 212-219 in the VSE.
sorry, that won't work. One can retime using fcurves. Which brings me to
the point: what was the sense in dropping the random access interface
again?
The imbuf reader has also a random access interface, but internally keeps
track of the last fetched frame and only reseeks on demand.
So you get: fast output, if you fetch the next frame and a slow reseek if
you don't, which will work nicely in all relevant cases, since your code
will be optimized to work on consecutive frames as much as it can.
Cheers,
Peter
Just do it internally like this on a movie strip which has a fixed
framerate:
class movie_iterator : public iterator {
public:
Frame fetch(float cfra) {
if (cfra == last_cfra + 1) {
return next();
}
seek(cfra - preseek);
for (int i = 0; i preseek; i++) {
next();
}
return next();
}
private:
Frame next() {
return next_frame using and updating last_frame_context;
}
void seek(float cfra) {
...
}
float last_cfra;
context last_frame_context;
}
where as a scene strip does:
class scene_iterator : public iterator {
public:
Frame fetch(float cfra) {
setup_render(cfra);
return render();
}
}
Peter Schlaile
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] A practical proposal for the task of re-licensing Blender
2010/11/25 José Romero jose.cyb...@gmail.com: Blender is a tool for artists, not programmers. I hate to break the news to you. It is because of programmers that Blender exists. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] A practical proposal for the task of re-licensing Blender
looks like many of you, when talking about proprietary software, see this scenario: an evil super-big corporation (we'll use a fake name for it: Autodesk, or Microsoft) steal or abuse Blender, and get away with it. They make lots of money they don't deserve, our beloved developers get pissed, our users gain nothing? No way! well, I would hate that, too! But in our computer graphics industry (games, animation, vfx) I don't really see this THEM (evil moneymakers) vs. US (passionate community) thing... let me try and give you another perspective on this, based on my professional experience ;) Who's THEM? All over the world there are hundreds of CG studios, ranging from very big (~2000 staff) to very small (~20 staff). It is my opinion that, however strange it might seem, most of the people involved with CG actually _work_ in such a place. You may prove me wrong on this, but CG is so demanding that most of us end up making a living of it to keep it going. :) There are of course artists/developers doing graphics out of fun besides a full-time job/school in an unrelated field, but not as many as full-timers (and you know what? For the most part we love it so much that we work on personal CG stuff in our spare time besides a full-time job in a studio! Check forums where professionals hang out). How is life in a studio? Guys, it is AWESOMENESS! Really, you should see it. A bunch of crazy, _highly_ skilled, _highly_ experienced people crunching ideas, building tools, experimenting on everything, sometimes fighting, getting stressed and overworked, chilling out with pizza and beer in the evening (usually late, late evening), and generally having loads of fun! ;) And all this to go to the theater, watching people watch your work and laugh, cry, think, and then feeling so proud when your name comes up on the screen for a microsecond in the credits and no one but you notice it! Of course studios are companies, too, and so they try to make money. But in the end, as my boss said just yesterday, making images is all we are about! So, are they really THEM? To me they definitely look like US, just maybe not using Blender, yet! How is this related to this thread? Typically in a studio we tend to develop many small or not so small things around our base tools, based on the needs of each show (a game, a movie, a commercial...), but usually there is not enough time to polish them, document them, etc. Remember? We are about making images, not software. And besides there will never be enough resources to develop everything you need, so you go for the big target, what makes your studio unique, and integrate third-party tools for what you don't have resources to develop yourself, or is better done by someone else, or is somehow secondary to you. And where do this third party tools come from? From everywhere, really. Look at the Maya eco-system for example. Even if proprietary, Maya is in a way a very open software: stable APIs for plugins, lots of documentation and examples, good support. You can build amazing stuff around it, I'm sure you've all seen interesting making-ofs and the like. This means that MANY developers distribute their Maya plugins, scripts, or just ideas as open source or public domain. And some software companies (often spinoffs from some studio) develop bigger plugins as proprietary code and sell them. For studios this is very important: I have my base tool and I love it, but if I get a show that needs photorealistic fur, or smoke, or a special renderer, and I can't do it myself, can I get it from someone else? If I have time I could pay developers to do it from scratch, but what if I don't have time? The best option would be buying an already-made, already-tested-in-production plugin. And if at some point all of my shows will require smoke, then I'll develop something myself... This is really what commercial software means in our context. And we have a very bright example that having a tool that can be extended means that a lot of people will extend it: Blender Add-ons! With the add-on system, Blender development is skyrocketing with small and useful things! Couldn't all this things be done in the code before? Sure they could, but it would have been more difficult for someone not knowing Blender internals, would have required centralized management (stealing Ton's time), and would have ended up as low priority projects in the tracker. Instead look at how many add-ons we have now! And it's just the beginning. Now if we just made some more steps in that direction... - give people a chance to make proprietary add-ons and plugins, so if they need to invest money they can. - build a more powerful plugin system with stable APIs and good docs. The license is just a part of it. For the second point, think how cool it would be if things like Dynamic Paint, the Ocean modifier, or all the awesome stuff from Raul could be done as external plugins. No need to get core developers to review, approve and integrate
Re: [Bf-committers] S-DNA and Changes
On 2010-11-26 00:28, Peter Schlaile wrote:
Hi Leo,
Ah, ok.
I'd still try to stick with integer frames and a parameterless next().
Allowing the client to specify the advance in the next() method makes it
too much of a random-access method (there is no guarantee that the
advance is to the next frame, which is the whole purpose of the
iterator interface).
I'd do it this way:
Suppose we have a scene where we want normal speed for frames 1-10, an
extreme slowdown for 11-12 and normal speed from 13-20.
Strip 1: Scene, frames 1-10. This strip covers frames 1-10 in the VSE.
Strip 2: Scene, frames 11-12, with a framerate of 1/100th of the output
framerate. This strip covers frames 11-211 in the VSE.
Strip 3: Scene, frames 13-20. This strip covers frames 212-219 in the VSE.
sorry, that won't work. One can retime using fcurves.
Then you can have one strip with an fcurve to map from VSE output frames
to scene frames:
Strip 1: Scene, frames 1-20, with an fcurve that maps from VSE frames
(iterated over using next()) to scene frames. It covers frames 1-219 in
the VSE.
If I may modify your code a little:
class scene_iterator : public iterator {
public:
Frame next () {
// fcurves go in map_vse_frame_to_cfra
float cfra = map_vse_frame_to_cfra (nextFrame);
setup_render(cfra);
++nextFrame;
return render();
}
int nextFrame;
}
VSE only sees a sequence of discrete frames - which is precisely what
its domain model should look like, because video editing is about
time-discrete sequences, not continuous. The Blender scene is a
continuous simulation - having a float cfra makes sense, because time is
continuous there. In the VSE the domain objects are discrete in time.
Having a float cfra makes no sense.
Which brings me to the point: what was the sense in dropping the random
access interface again?
The imbuf reader has also a random access interface, but internally keeps
track of the last fetched frame and only reseeks on demand.
It is always possible to wrap a sequential interface in a random-access
interface, or vice versa. The purpose of dropping the random access
interface was to be able to write code that didn't have to deal with two
cases - you'd know that you'll always be expected to produce the next
frame, and can code for that. Less to write, less to go wrong.
Clients of the code know that they can iterate over *every* frame in the
sequence just by calling next(). With a random access interface -
especially one that uses floats for indexing - you'll always worry if
you missed a frame, or got a duplicate, thanks to rounding errors.
/LS
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] A practical proposal for the task of re-licensing Blender
On 2010-11-26 00:40, Lorenzo Pierfederici wrote: Maya is in a way a very open software: stable APIs for plugins, lots of documentation and examples, good support. You can build amazing stuff around it Seems like you got your solution right there. Why aren't you just going with Maya? /LS ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] A practical proposal for the task of re-licensing Blender
Hi, Please stop the fight on this thread, there is no point to talk about LGPL, Maya, the good support or whatever. Ton already say that the possibility to re-licensing with LGPL is near zero, so we need focus on ways to get end-user level useful extensions possible. and this mean no more talk about change the license from GPL to LGPL! So please, focus on that topic and if you don't have any other solution that change the GPL to LGPL wait until somebody come back with an alternative! On Thu, Nov 25, 2010 at 9:17 PM, Leo Sutic leo.su...@gmail.com wrote: On 2010-11-26 00:40, Lorenzo Pierfederici wrote: Maya is in a way a very open software: stable APIs for plugins, lots of documentation and examples, good support. You can build amazing stuff around it Seems like you got your solution right there. Why aren't you just going with Maya? /LS ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers - Diego ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] A practical proposal for the task of re-licensing Blender
On Thu, Nov 25, 2010 at 4:38 PM, Diego B bdi...@gmail.com wrote: Hi, Please stop the fight on this thread, there is no point to talk about LGPL, Maya, the good support or whatever. Ton already say that the possibility to re-licensing with LGPL is near zero, so we need focus on ways to get end-user level useful extensions possible. and this mean no more talk about change the license from GPL to LGPL! So please, focus on that topic and if you don't have any other solution that change the GPL to LGPL wait until somebody come back with an alternative! Well actually if you read the discussion you'd see we're not talking about that. Right now we're talking about the value of non-open plugins. This is something Ton has said he does see the value of. Perhaps we should start a new thread just to be clear. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] Check out my photos on Facebook
Hi Blen, I set up a Facebook profile where I can post my pictures, videos and events and I want to add you as a friend so you can see it. First, you need to join Facebook! Once you join, you can also create your own profile. Thanks, Roland To sign up for Facebook, follow the link below: http://www.facebook.com/p.php?i=1421273854k=Z2G42YTSPZTF6BD1PK6YWVPRVWIB4T6CQQ1WKr Already have an account? Add this email address to your account: http://www.facebook.com/n/?merge_accounts.phpe=bf-committers%40blender.orgc=85d5d63ee2fc1c4543bb54ccab5afa28 === bf-committers@blender.org was invited to join Facebook by Roland Douglas Walet. If you do not wish to receive this type of email from Facebook in the future, please follow the link below to unsubscribe. http://www.facebook.com/o.php?k=6ea9d2u=11905621152mid=359554bG5af3820fb8a0G0G8 Facebook, Inc. P.O. Box 10005, Palo Alto, CA 94303 ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
