[Bf-committers] [BGE Proposal] Improvement of dupli-groups for better workflow, new features, missing stuff (with working implementation)
Hi there! I'm currently working on improvements for linked groups. The way of using them brings a lot of power to the gameengine (e.g. build up reusable libraries, hide implementation detail) but also lacks some missing features. 1) first part: group references At the moment, you can't detect at runtime if the object controller owner is part of a group. The duplicating object also doesn't know about its group members. There is no (easy) way to get the necessary references. My proposal is to provide an improved interface for KX_GameObjects. Here you can find the complete proposal: http://de.wikibooks.org/wiki/Benutzer:Moerdn/_Blender_2.5_Feature_Proposal I've already implemented this small feature and it would be nice if the BGE devs could take a closer look. This page also contains patches, a windows build and some links to youtube that demonstrates some of the possibilities. As you can see in the videos, it makes live for BGE artists and programmers a lot easier. (e.g. parent instances together or use properties as 'constructor' to parametrise these instances to allow creating different behaviour for every single instance) 2) second part: working rigid body constraints for group instances At the moment it is not possible to use constraints with instanced groups. They are completely ignored during the process of replication. It would be nice to get this missing feature for blender gameengine. Here you can read the full feature proposal: https://gitorious.org/bge-sandbox/pages/GroupCons I've also implemented this feature as a quick demonstration. Almost all of the physic constraints demos works well so far (simple hinge, trampoline, complex ragdolls ..) All relevant links to files (builds, videos, test blendfiles) and a discussion is posted to blenderartists: http://blenderartists.org/forum/showthread.php?220666-BGE-proposal-group-references-and-workflow-improvements-%28discussion-testbuilds%29 All of my coding stuff could also be visited on gitorious: https://gitorious.org/~moerdn/blenderprojects/moerdn-bge-sandbox relevant branches at the moment: group-ref group-cons I'm very interested in improving BGE with some smaller things to get closer to the code base. It would be very nice to get some feedback. Thanks for reading! best regards, moerdn ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Blender developers irc meeting minutes, 19 june 2011
Hey, I disagree here. As this is a real release, it is inevitable to do a freeze for a day at least and check on the status of Trunk and run the regression files. I thought we agreed on more strict freezes and tests right before a release? I also want to remind everyone about this wiki page: http://wiki.blender.org/index.php/Dev:Ref/Release_Checklist It's not finished yet, but should be up to date (starting with Checklist) Regards, Thomas Am 19.06.2011 17:50, schrieb Ton Roosendaal: - To respect our bimonthly release schedule, proposal is: - call for a 2.58 this tuesday, release 1-2 days after (no real freeze needed) ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Blender developers irc meeting minutes, 19 june 2011
Hi Thomas, I might have worded it too informal. :) For sure we should do the testing well; but it seemed to me the current commits are mostly related to bugfix and stabilizing anyway. A short freeze of 2 days for everyone to not add 'new' stuff is obviously assumed, but real bug fixing can continue. -Ton- Ton Roosendaal Blender Foundation t...@blender.orgwww.blender.org Blender Institute Entrepotdok 57A 1018AD Amsterdam The Netherlands On 20 Jun, 2011, at 11:00, Thomas Dinges wrote: Hey, I disagree here. As this is a real release, it is inevitable to do a freeze for a day at least and check on the status of Trunk and run the regression files. I thought we agreed on more strict freezes and tests right before a release? I also want to remind everyone about this wiki page: http://wiki.blender.org/index.php/Dev:Ref/Release_Checklist It's not finished yet, but should be up to date (starting with Checklist) Regards, Thomas Am 19.06.2011 17:50, schrieb Ton Roosendaal: - To respect our bimonthly release schedule, proposal is: - call for a 2.58 this tuesday, release 1-2 days after (no real freeze needed) ___ 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] [BGE Proposal] Improvement of dupli-groups for better workflow, new features, missing stuff (with working implementation)
Hi Martin, On Mon, Jun 20, 2011 at 6:31 PM, Martin Sell m.sel...@stud.fh-sm.de wrote: 1) first part: group references At the moment, you can't detect at runtime if the object controller owner is part of a group. The duplicating object also doesn't know about its group members. There is no (easy) way to get the necessary references. My proposal is to provide an improved interface for KX_GameObjects. Here you can find the complete proposal: http://de.wikibooks.org/wiki/Benutzer:Moerdn/_Blender_2.5_Feature_Proposal +1, this would be very useful. In the past I have wanted to access properties defined on the pivot. Your proposal meets that need. Please keep parenting instances to the pivot optional - in many of my groups, I want the objects to act independently. I see from your videos that parenting needs to be done after instantiation with a script; that's fine with me. We could add an option in the GUI to automate that at a later date. My only suggestion is to change the terminology: pivot implies that the objects are parented to it. How about renaming pivot to group, and instance to member? I've already implemented this small feature and it would be nice if the BGE devs could take a closer look. This page also contains patches, a windows build and some links to youtube that demonstrates some of the possibilities. I haven't tried your patch yet, but the videos look great. Cheers, Alex ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] [BGE Proposal] Improvement of dupli-groups for better workflow, new features, missing stuff (with working implementation)
Hi Alex, thanks for you reply. Please keep parenting instances to the pivot optional - in many of my groups, I want the objects to act independently. I see from your videos that parenting needs to be done after instantiation with a script; that's fine with me. This is entirely optional and just one use case to demonstrate this feature. But your right, any restrictions like parenting by default wouldn't make any sense. We could add an option in the GUI to automate that at a later date. This is also one thing that I have in mind. Would make the work with groups even more user friendly and automated. My only suggestion is to change the terminology: pivot implies that the objects are parented to it. How about renaming pivot to group, and instance to member? This could be easily done. 'instances' is a list of all members so the equivalent api property would be con.owner.members. obj.members obj.group If you want to try it, just grab the windows 32 bit build and example files that shows the feature in action. I could also make a Linux Build as well, but I'm not sure how to build it as dependency free as possible. Any further hints and suggestions are welcome. Thanks for your interest and your time. Regards, moerdn ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Environment Map Rendering
Jai, Maybe I'm misunderstanding what exactly you want, but it seems to me you are really asking about reflections, and not environment maps. Env. Maps are exactly as their name suggests, maps. They are simply images, 2d, that are used as textures with specially crafted UV coordinate generation to make them look like they are reflections. An env. map doesn't actually reflect anything from the scene at all, volumetric or not. Can you perhaps send URL an example .blend file that clearly illustrates what you are doing now, along with a complete description of what you'd like it to do in the future? fyi, I'm not saying I have time to implement another new feature, I'm just hoping further clarification will help you find someone who has time to do so. Cheers! Peter On Sun, Jun 19, 2011 at 5:34 AM, Jai Ljubić jaikk...@gmail.com wrote: Hi, I'm new to lists so forgive me if I've sent the wrong sort of thing to the wrong place or any other faux pas. I require some improvements to environment map rendering, and willing to offer the little money I have. Things such as volumetric objects appearing in envmap renders is what I need done. I understand the developers plan to make these improvements but it would be a great help if it were available sooner rather than later. Is anyone initially interested in making an arrangement? Jai Lee Ljubić ___ 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] [BGE PROPOSAL] Saving converted scenes
I'm not commenting on whether or not the approach is correct, but in the chance that the approach is correct: bump up version number char[3] to a char[4] since there are 2.49 and 2.49a and 2.49b and things of that nature. If a file structure was to slightly change between such releases it'd be worth that extra byte to go ahead and store that too. On Sun, Jun 19, 2011 at 5:42 AM, Trouble Maker maker...@gmail.com wrote: Hi, i made a more detailed proposal for saving converted scenes to file. You can find it here http://wiki.blender.org/index.php/User:Makers_F/Save_converted_BGE_data_out_to_a_file There are still some thing undefined, but i would really like to know if i took a good path for doing this, or there are better methods. ___ 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] SVN commit: /data/svn/bf-blender [37537] branches/soc-2011-pepper: == Simple Title Cards for Sequencer ==
about workaround, I asked DingTo to change the max value of the Ortho Size parameter in Blender. So if you set the camera to Ortho and the Ortho size the same value as the Resolution_x of your camera (render settings). 1 pixel on your screen becomes 1 blender unit. which can be useful for this kind of stuff (subtitles, ... ). It was possible before, but the limit was up to 1000, which means at the time you could only do that with SD footages. Now the limit is up to 4K. (but it might need to be 10K actually since I believe it is the limit of Resolution_x, just to keep it consistant) cheers, F 2011/6/19 Vilem Novak pildano...@post.cz hello, I dont have here a pepper build to test the new titles tool, but I want to say it is very very welcome. Regarding the python solution, I allready coded an addon which adds subtitles from templates(first version): http://blenderartists.org/forum/showthread.php?213402-Sequencer-subtitles-addonhighlight=subtitle since I often do some simple subtitling work for low budget projects. The addon has the advantage of simple template creation, but its not possible to have the titles animated. It was very first version which I didnt finish because I was forced to switch to another NLE in the work where I needed it, there is preliminary support for srt reading too. Regarding a proposal about ideal subtitle adding, I would imagine subtitle strips having associated templates and several animatable properties(e.g. rollspeed), where the templates would be blender scenes which would render in background and the few animatable properties would be somehow marked so that the title engine can recognise them and make them part of the strip. Cheers Vilem Původní zpráva Od: François T. francoistarl...@gmail.com Předmět: Re: [Bf-committers] SVN commit: /data/svn/bf-blender [37537] branches/soc-2011-pepper: == Simple Title Cards for Sequencer == Datum: 19.6.2011 09:18:44 huge +1 2011/6/16 Matt Ebb m...@mke3.net Personally, I think a text strip has been sorely missing from the sequencer (and compositor) for a while, and it's great to see it added. Doing it via blender scenes and python is a really slow, nasty overcomplicated way of doing something which really should be quite simple, and is a really simple, common, basic tool in most other editors. Editing the text from the sequence editor interface and having it rendered directly to a strip is the fastest and best way of having such a feature, and it's something I would have loved to have had plenty of times. Note: I haven't tried the current patch but it would be best as a generalised 'text strip' rather than anything aimed specifically at title cards, with properties like text box height and width, and typographic/paragraph controls too. cheers Matt On Thu, Jun 16, 2011 at 9:26 PM, Joshua Leung aligor...@gmail.com wrote: Hey Peter, Cheers for the feedback! Indeed, as I started to pick through things, the issues faced by users who would want to use this as a base on which to start extending it in some ways did come up. Sure, a script which sets up a generic template would be nice in this situation, and is one way I'd thought of doing it. Some factors which made me favour this approach though were that: 1) Using this approach, we let automation take over making sure that the text fits and is aligned nicely in frame when things change. From experience, I've ended up scaling and re scaling text, moving it all over the place trying to get it to fit and be in frame. Registering a special operator for this, and/or trying to find somewhere decent to put it so that it can be easily found is an issue. 2) Text colours can be set in one place with this method, without fudging with material settings (and doing material-unlink dances after copying some text and deciding you want it a different colour - then again here, the level of control over this stuff is entirely hardcoded) 3) AFAIK, scene strips were synonymous with constantly being re-rendered and re-evaluated every single time they're encountered, when doing scene evaluation combined with rendering is a comparatively sluggish process for Blender. The alternative would have been to force people to always render these out to image files (something that I'm trying to avoid here) before they could be used. (*1) 4) With this approach, including text in the sequencer feels more like a first-class entity than just a weirdo heavy-duty workflow, where you have a proliferation of scene strips in your timeline which are essentially just there to display text (but outwardly don't communicate this) 5) There's also the issue of a buildup of scene files in the
Re: [Bf-committers] Environment Map Rendering
Hi Pete, I am talking about generating environment maps from a blender scene, not using one as part of an existing scene. And in my case, I am using it to create a sky box. Perhaps you can suggest a better term, I thought environment map rendering was rather straight forward. Currently, volumetric objects do not appear on the texture when generating the environment map. Does that clear things up? ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] [BGE PROPOSAL] Saving converted scenes
The reason for why i choose to use char[3] is because it is the same in the DNA struct, and it always worked. I assume that the change to 2.49a, 2.49b, 2.49c where due: only major bugfixing, no major stuff that needed to be additionally stored where added, and the pending big 2.5 series. In addition, the ascii table doesn't end after 9(0x39), so if we really need to add another version we can use 0x40, 0x41,etc,but i don't think this will happen. By my side using char[4] don't change anything, but i think it is better to maintain a as more uniform structure as possible. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] Fixing dynamically added lights (BGE)
After some discussion yesterday, we came up with a plan for dynamically adding lights while in the Blender Game Engine. The problem is the shader code currently relies on Blender light objects, and recompiling it is too slow to do frequently in the BGE. So the plan is to create a user settable number of Blender lights and put them into the blender scene during the conversion process. At this time the shaders can be recompiled to so they include this pool of lights. From there, whenever a Ketsji light is dynamically added, it can borrow one of these Blender lights so it can affect the compiled shaders. These lights will be distributed on a first come first served basis. When a Ketsji light is done with a Blender light, the borrowed Blender light's energy can be set to 0 to avoid affecting the scene. When the engine is done running, it of course will remove these added Blender lights. I am sending this to the mailing list for review and feedback. Thanks, Daniel Stokes ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Fixing dynamically added lights (BGE)
To clarify this is for the Cucumber Summer of Code branch, and by we I mean myself, my mentor, and a few other members of the community. On Mon, Jun 20, 2011 at 3:36 PM, Daniel Stokes kupom...@gmail.com wrote: After some discussion yesterday, we came up with a plan for dynamically adding lights while in the Blender Game Engine. The problem is the shader code currently relies on Blender light objects, and recompiling it is too slow to do frequently in the BGE. So the plan is to create a user settable number of Blender lights and put them into the blender scene during the conversion process. At this time the shaders can be recompiled to so they include this pool of lights. From there, whenever a Ketsji light is dynamically added, it can borrow one of these Blender lights so it can affect the compiled shaders. These lights will be distributed on a first come first served basis. When a Ketsji light is done with a Blender light, the borrowed Blender light's energy can be set to 0 to avoid affecting the scene. When the engine is done running, it of course will remove these added Blender lights. I am sending this to the mailing list for review and feedback. Thanks, Daniel Stokes ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Fixing dynamically added lights (BGE)
Honest question, how is that different to just keep some of the lights at energy 0 and turn them on at some points? is this proposal faster or something? cheers Daniel Salazar 3Developer.com On Mon, Jun 20, 2011 at 5:51 PM, Daniel Stokes kupom...@gmail.com wrote: To clarify this is for the Cucumber Summer of Code branch, and by we I mean myself, my mentor, and a few other members of the community. On Mon, Jun 20, 2011 at 3:36 PM, Daniel Stokes kupom...@gmail.com wrote: After some discussion yesterday, we came up with a plan for dynamically adding lights while in the Blender Game Engine. The problem is the shader code currently relies on Blender light objects, and recompiling it is too slow to do frequently in the BGE. So the plan is to create a user settable number of Blender lights and put them into the blender scene during the conversion process. At this time the shaders can be recompiled to so they include this pool of lights. From there, whenever a Ketsji light is dynamically added, it can borrow one of these Blender lights so it can affect the compiled shaders. These lights will be distributed on a first come first served basis. When a Ketsji light is done with a Blender light, the borrowed Blender light's energy can be set to 0 to avoid affecting the scene. When the engine is done running, it of course will remove these added Blender lights. I am sending this to the mailing list for review and feedback. Thanks, Daniel Stokes ___ 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] Fixing dynamically added lights (BGE)
Daniel S. the difference is that this is handled internally by Blender. The user would only need to set the number of extra lights in the UI. Honest question, how is that different to just keep some of the lights at energy 0 and turn them on at some points? This is indeed the current workflow (using python to move lamps around to match the position of new lamps). In a way this solution mimic this workaround. So it's not fast (to run), but it's way easier to use. -- Dalai 2011/6/20 Daniel Salazar - 3Developer.com zan...@gmail.com Honest question, how is that different to just keep some of the lights at energy 0 and turn them on at some points? is this proposal faster or something? cheers Daniel Salazar 3Developer.com On Mon, Jun 20, 2011 at 5:51 PM, Daniel Stokes kupom...@gmail.com wrote: To clarify this is for the Cucumber Summer of Code branch, and by we I mean myself, my mentor, and a few other members of the community. On Mon, Jun 20, 2011 at 3:36 PM, Daniel Stokes kupom...@gmail.com wrote: After some discussion yesterday, we came up with a plan for dynamically adding lights while in the Blender Game Engine. The problem is the shader code currently relies on Blender light objects, and recompiling it is too slow to do frequently in the BGE. So the plan is to create a user settable number of Blender lights and put them into the blender scene during the conversion process. At this time the shaders can be recompiled to so they include this pool of lights. From there, whenever a Ketsji light is dynamically added, it can borrow one of these Blender lights so it can affect the compiled shaders. These lights will be distributed on a first come first served basis. When a Ketsji light is done with a Blender light, the borrowed Blender light's energy can be set to 0 to avoid affecting the scene. When the engine is done running, it of course will remove these added Blender lights. I am sending this to the mailing list for review and feedback. Thanks, Daniel Stokes ___ 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] Fixing dynamically added lights (BGE)
The plan would be to more or less have the lights off until they are needed. The main point of this solution is to create a handful of Blender lamps for the game engine to use when it dynamically adds a Ketsji lamp (through means such as addObject or libload). I guess to answer your question, what you are saying sounds a lot like what I am saying, so perhaps I wasn't very clear in my explanation. Regards, Daniel Stokes On Mon, Jun 20, 2011 at 4:57 PM, Daniel Salazar - 3Developer.com zan...@gmail.com wrote: Honest question, how is that different to just keep some of the lights at energy 0 and turn them on at some points? is this proposal faster or something? cheers Daniel Salazar 3Developer.com On Mon, Jun 20, 2011 at 5:51 PM, Daniel Stokes kupom...@gmail.com wrote: To clarify this is for the Cucumber Summer of Code branch, and by we I mean myself, my mentor, and a few other members of the community. On Mon, Jun 20, 2011 at 3:36 PM, Daniel Stokes kupom...@gmail.com wrote: After some discussion yesterday, we came up with a plan for dynamically adding lights while in the Blender Game Engine. The problem is the shader code currently relies on Blender light objects, and recompiling it is too slow to do frequently in the BGE. So the plan is to create a user settable number of Blender lights and put them into the blender scene during the conversion process. At this time the shaders can be recompiled to so they include this pool of lights. From there, whenever a Ketsji light is dynamically added, it can borrow one of these Blender lights so it can affect the compiled shaders. These lights will be distributed on a first come first served basis. When a Ketsji light is done with a Blender light, the borrowed Blender light's energy can be set to 0 to avoid affecting the scene. When the engine is done running, it of course will remove these added Blender lights. I am sending this to the mailing list for review and feedback. Thanks, Daniel Stokes ___ 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] Visibility of attribution
Hi all, When doing some work for a client recently, I developed a patch for Blender. The client is happy to contribute the code back to Blender, however they are concerned about attribution. Currently it seems there are no clear guidelines about how attribution is given for contributions. My preference, and that of my client, is that detailed copyright notices should be visible both in the code and in Blender's GUI. This is not unusual: consider the Linux kernel (e.g. [1]) and the GIMP (e.g. [2-4]), and the About dialog boxes of gedit[5] and Firefox[6]. Apart from giving contributors credit, detailed copyright notices in the code would better satisfy the GPL, which states in section 2.a: a) You must cause the modified files to carry prominent notices stating that you changed the files and the date of any change. I propose that: 1. All future contributions be attributed in modified source files as Copyright year author or organistion, or at the contributor's option, in another form that conveys the same information. 2. The same copyright information be collected in a place accessible from the GUI, either in the splash screen itself (perhaps in a tab) or on a web page linked to from the splash screen. What do you think? Cheers, Alex -- Alex Fraser Software Engineer The Victorian Partnership for Advanced Computing [1] http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob_plain;f=kernel/cgroup.c [2] http://git.gnome.org/browse/gimp/plain/plug-ins/common/polar-coords.c [3] http://git.gnome.org/browse/gimp/tree/plug-ins/twain/twain.h [4] http://git.gnome.org/browse/gimp/tree/libgimp/gimpitemcombobox.c [5] http://www.pasteall.org/pic/13959 [6] http://www.pasteall.org/pic/13961 ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Visibility of attribution
On Mon, Jun 20, 2011 at 6:52 PM, Alex Fraser adfr...@vpac.org wrote: Hi all, When doing some work for a client recently, I developed a patch for Blender. The client is happy to contribute the code back to Blender, however they are concerned about attribution. Currently attribution is in a link on the download page for each version http://www.blender.org/development/release-logs/blender-257/contributor-credits/ And in the files that are patched. LetterRip ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Visibility of attribution
Also in the release note documentation will usually mention who coded the feature of interest. Note that the release log is linked from the splash screen. (Hmm looks like I said download page previously the contributor credits are linked to from the release log, not the download page). LetterRip On Mon, Jun 20, 2011 at 7:11 PM, Tom M letter...@gmail.com wrote: On Mon, Jun 20, 2011 at 6:52 PM, Alex Fraser adfr...@vpac.org wrote: Hi all, When doing some work for a client recently, I developed a patch for Blender. The client is happy to contribute the code back to Blender, however they are concerned about attribution. Currently attribution is in a link on the download page for each version http://www.blender.org/development/release-logs/blender-257/contributor-credits/ And in the files that are patched. LetterRip ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Visibility of attribution
On Tue, Jun 21, 2011 at 12:52:32PM +1000, Alex Fraser wrote: I propose that: 1. All future contributions be attributed in modified source files as Copyright year author or organistion, or at the contributor's option, in another form that conveys the same information. 2. The same copyright information be collected in a place accessible from the GUI, either in the splash screen itself (perhaps in a tab) or on a web page linked to from the splash screen. I do not remember the exact circumstances, but we had a situation before where some corporation wanted an attribution notice put in the UI before they would contribute code. The answer was no. Personally, I am not sure of the value of asserting copyright over code that is GPL'ed. -- Stephen Swaney sswa...@centurytel.net ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Visibility of attribution
On Tue, Jun 21, 2011 at 3:22 AM, Stephen Swaney sswa...@centurytel.net wrote: On Tue, Jun 21, 2011 at 12:52:32PM +1000, Alex Fraser wrote: I propose that: 1. All future contributions be attributed in modified source files as Copyright year author or organistion, or at the contributor's option, in another form that conveys the same information. 2. The same copyright information be collected in a place accessible from the GUI, either in the splash screen itself (perhaps in a tab) or on a web page linked to from the splash screen. re 1) The contributors are free to add in their own attribution in the patch, perhaps it would help to formalize this, though the few times I've had to deal with this a line in the header assigning copyright was ok. So don't mind either way. re 2) Having a web page for this could work, but -1 for listing all contributors/copyright-assignments in the GUI. I do not remember the exact circumstances, but we had a situation before where some corporation wanted an attribution notice put in the UI before they would contribute code. The answer was no. Personally, I am not sure of the value of asserting copyright over code that is GPL'ed. In practice probably not much though it does mean if we want to add some GPL exception like we did for the BGE or one day move to GPLv3, copyright holders need to agree, -- - Campbell ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Visibility of attribution
On Tue, Jun 21, 2011 at 03:39:25AM +, Campbell Barton wrote: On Tue, Jun 21, 2011 at 3:22 AM, Stephen Swaney wrote: Personally, I am not sure of the value of asserting copyright over code that is GPL'ed. In practice probably not much though it does mean if we want to add some GPL exception like we did for the BGE or one day move to GPLv3, copyright holders need to agree, There is a good point. That would seem to be a deal-breaker, right there. -- Stephen Swaney sswa...@centurytel.net ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Visibility of attribution
- Original Message - From: Stephen Swaney sswa...@centurytel.net I do not remember the exact circumstances, but we had a situation before where some corporation wanted an attribution notice put in the UI before they would contribute code. The answer was no. Do you remember what the objection was? Note that we aren't asking to be attributed more prominently than other contributors; just on the same page. Nor are we asking for a logo to be displayed on the web site. I think attribution in a place that users can see is a fair trade for code contribution. Attribution in the release notes is good (thanks Tom, I didn't know about that page), but that means you become invisible in the next release. - Original Message - From: Campbell Barton ideasma...@gmail.com re 1) The contributors are free to add in their own attribution in the patch, perhaps it would help to formalize this, though the few times I've had to deal with this a line in the header assigning copyright was ok. So don't mind either way. I think it would be good to formalise this, particularly to include the date that the contributions were made. Personally, I am not sure of the value of asserting copyright over code that is GPL'ed. In practice probably not much though it does mean if we want to add some GPL exception like we did for the BGE or one day move to GPLv3, copyright holders need to agree, Yes, one thing attribution does is make it easier to track who owns what. And it really is an incentive to contribute. Cheers, Alex -- Alex Fraser Software Engineer The Victorian Partnership for Advanced Computing ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Visibility of attribution
- Original Message - From: Stephen Swaney sswa...@centurytel.net On Tue, Jun 21, 2011 at 03:39:25AM +, Campbell Barton wrote: In practice probably not much though it does mean if we want to add some GPL exception like we did for the BGE or one day move to GPLv3, copyright holders need to agree, There is a good point. That would seem to be a deal-breaker, right there. Copyright notices are a statement of fact. If you don't have them, the author still owns the code - you just don't know who they are. Cheers, Alex -- Alex Fraser Software Engineer The Victorian Partnership for Advanced Computing ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Visibility of attribution
:cry: I don't see my name between patch makers ;-( :cry: On 21 June 2011 05:11, Tom M letter...@gmail.com wrote: Currently attribution is in a link on the download page for each version http://www.blender.org/development/release-logs/blender-257/contributor-credits/ And in the files that are patched. LetterRip ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Incorrect fsf street addresses in licence files
Hi Dave, corrected r37689 r2050 of extension repo. On Tue, Jun 7, 2011 at 8:19 PM, Dave Plater dpla...@webafrica.org.za wrote: Hi, I just thought I'd pass this on, openSUSE build service now has a licence check on the fly for packages and it produced this message with blender-2.57b, I usually just insert a downloaded license with the spec file : blender-doc.noarch: W: incorrect-fsf-address /usr/share/doc/packages/blender/GPL-license.txt blender.x86_64: W: incorrect-fsf-address /usr/share/blender/2.57/scripts/addons/modules/extensions_framework/util.py blender.x86_64: W: incorrect-fsf-address /usr/share/blender/2.57/scripts/addons/io_coat3D/coat.py blender.x86_64: W: incorrect-fsf-address /usr/share/blender/2.57/scripts/addons/game_engine_save_as_runtime.py blender.x86_64: W: incorrect-fsf-address /usr/share/blender/2.57/scripts/addons/system_blend_info.py blender.x86_64: W: incorrect-fsf-address /usr/share/blender/2.57/scripts/addons/space_view3d_3d_navigation.py The Free Software Foundation address in this file seems to be outdated or misspelled. Ask upstream to update the address, or if this is a license file, possibly the entire file with a new copy available from the FSF. It's usually an old GPL-2.0 license. There will also be a full legal review when I've eventually coaxed python-3.2 into factory and then 11.4 because blender hasn't been reviewed before, it's a virtual minefield when you actively maintain all multimedia. I believe it's an inter distro move to become legally Free Software Foundation. That's why I haven't had a chance to patch blender-2.57b for python 3.1 and it's only available from my home repo along with python3-3.2 : http://download.opensuse.org/repositories/home:/plater:/blender/openSUSE_11.4 There's also a 1 click install : http://software.opensuse.org/ymp/home:plater:blender/openSUSE_11.4/blender.ymp?base=openSUSE%3A11.4query=blender Regards Dave Plater openSUSE blender maintainer. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers -- - Campbell ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Visibility of attribution
Hi Alex, last time I remember this been brought up was for Blender 2.49. In the occasion we had some sponsored contributions and a solution was: 1) to add a name + link in the contributors page: http://wiki.blender.org/index.php/Template:Release_Notes/2.49/Contributors 2) to add credit+thank notes in the header of the source files: e.g. header of KX_Dome.cpp and KX_Dome.h read: # Contributor(s): Dalai Felinto This source uses some of the ideas and code from Paul Bourke. Developed as part of a Research and Development project for SAT - La Societe des arts technologiques. # 3) include a node with no link/logo in the wiki page of the feature: http://wiki.blender.org/index.php/Dev:Source/GameEngine/2.49/Fisheye_Dome_Camera 4) add a note in the commit log (don't remember now what it said, but probably this feature was implemented with the partial support from ) My client was happy, Blender Foundation was happy, and me, well, I couldn't care less ;) I was happy that everyone was happy. But I guess it doesn't hurt to be acknowledged on your work. In my humble opinion this is enough credit. -- Dalai 2011/6/20 Damir Prebeg blend.fact...@gmail.com :cry: I don't see my name between patch makers ;-( :cry: On 21 June 2011 05:11, Tom M letter...@gmail.com wrote: Currently attribution is in a link on the download page for each version http://www.blender.org/development/release-logs/blender-257/contributor-credits/ And in the files that are patched. 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
