Re: [Bf-committers] The dilation I am seeing in Blender is imo not good. I thought I'd propose an alternative (if there's support)?
+1 I always thought I was just using bake margins that were too small! these results look amazing! Definately worth pursuing in my book! Hiding the unwrap seams by manual choice is one thing, but the reduced artefact here is much nicer On 21/07/11 01:13, Morten Mikkelsen wrote: The dilation I am seeing in Blender is imo not good. I thought I'd propose an alternative (if there's support)? Here's a close-up of the dilation blender does -- http://jbit.net/~sparky/blender_dial/bakezoom_BI_dial.png Here's a close-up of the dilation I was able to do outside of blender using diff. code -- http://jbit.net/~sparky/blender_dial/bakezoom_other_dial.png The bumped visual you get using the first one is this (ugly filtering scar) -- http://jbit.net/~sparky/blender_dial/scr_BI_dial.png The visual you get using the other method is this (significantly more subtle) -- http://jbit.net/~sparky/blender_dial/scr_other_dial.png The blend file to produce the texture is up there -- http://jbit.net/~sparky/blender_dial/bmake.blend This is the full-res baked result you get with dilation using blender -- http://jbit.net/~sparky/blender_dial/bake_BI.png and this is using the alternative dilation -- http://jbit.net/~sparky/blender_dial/bake_other_dial.png I dumped everything here http://jbit.net/~sparky/blender_dial/ incl. a blender file. Let me know what you think. Cheers, Morten. ___ 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] Material Nodes: No normals in worldspace?
On 21/07/11 00:37, Tobias Oelgarte wrote: in this simple case. It could be much easier and powerful to have worldspace normals and maybe even the view-vector in wordspace coordinates. This would allow many new possibilities for reflection mapping and other cool stuff. On top of that it would work smoothly together with GLSL and shouldn't be so hard to implement. Maybe this can convince one of the programming gods to implement this feature? It would be much easier! For reflection I've found the current system works fine, but if normals were changed to world space then view would have to as well It'd be nice to get object origins and current shading points world coordinates available in the nodes too so you could do x distance from empty for example... I know you can a bit of that in texture nodes... but would be nice in material nodes! ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Help needed! Animation problems for 3D Audio GSoC
Hi! Sorry for the late reply, but I had no internet for 3 days. Lars: The problem is that the Data API in blender doesn't have such mutexes and as such isn't thread safe, I guess making blender thread safe in this way, requires a GSoC project or even more on its own. Knapp: This is not about interpolation ;-) And why it's not readable? Imagine a thread accesses a pointer while another thread deletes that memory?! Brett: This doesn't change anything regarding the data access. Sergey: Well yes, the question is whether the main thread can do such a preprocessing. At least the cache can be updated with the current frame value once it's reached so that the value is correct at least the second time you playback after a change (not doing changes between first and second playback for sure). Regards ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] Blender on the Mac App Store
Hello everyone. what about putting blender on the App Store (the one for Mac applications of course, not for iOS)? Blender could reach a lot more popularity. Markus K. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Blender on the Mac App Store
Hi, Personally, I don't think it's a good idea. App Store isn't compatible with GPL license. Even more, it was accident with VLC already -- Apple simply removed this application from App Store due to license incompatibility. Markus Kasten wrote: Hello everyone. what about putting blender on the App Store (the one for Mac applications of course, not for iOS)? Blender could reach a lot more popularity. Markus K. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers -- With best regards, Sergey I. Sharybin ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] python32_d.dll requires MSVC9
If VC9 is not installed, Blender debug builds quit with an application was unable to start correctly error as soon as they try to load the Python library. The problem is that python32_d.dll was built with the VC9 debug CRT dynamically linked, and that the debug CRT is available only through an install of VC9. The solution is simply to recompile the DLL with the runtime statically linked (/MTd). This is the only thing preventing VC10 builds from succeeding! ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Proposal: better envmap scripting
Then I'll begin. :) On 20/07/2011 2:47, Tom Edwards wrote: Hello all. I'm currently writing an add-on to ease the export of renders and environment maps to the Source game engine, and I'm finding my options when it comes to envmaps extremely limited. I'd like to add the following functions: bpy.types.EnvironmentMap.save( filename, layout=( (0,0),(0,1),(0,2),(1,0),(1,1),(1,2) ) ) Saves the envmap with the scene render settings. layout determines the location of each face in the output image; 1 == EnvironmentMap.resolution. bpy.types.EnvironmentMap.render(ignore_cache=False) Renders the envmap if it is stale. Ignores the camera and indeed goes ahead without one. Might render other envmaps for recursion. ignore_cache bypasses the normal envmap cache checks. bpy.types.EnvironmentMap.clear() Same as bpy.ops.texture.envmap_clear(), but without the overhead of setting up then reverting the context. Is there any reason why the above couldn't be added to trunk? ___ 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] Material Nodes: No normals in worldspace?
Hey guys, I wrote the patch to add reflection mapping (and could easily extend to other things like WS normals) to the material nodes. The issue behind the patch's delay is more of a logical issue of what parts of blender you want to expose to the node system. I spoke with kaito about this for a while and he had a good idea how we could do it without exposing render core internals. If I get a little more time I will implement the way kaito and I discussed. Cheers! Pete On Thu, Jul 21, 2011 at 2:15 AM, michael williamson micha...@cowtoolsmedia.co.uk wrote: On 21/07/11 00:37, Tobias Oelgarte wrote: in this simple case. It could be much easier and powerful to have worldspace normals and maybe even the view-vector in wordspace coordinates. This would allow many new possibilities for reflection mapping and other cool stuff. On top of that it would work smoothly together with GLSL and shouldn't be so hard to implement. Maybe this can convince one of the programming gods to implement this feature? It would be much easier! For reflection I've found the current system works fine, but if normals were changed to world space then view would have to as well It'd be nice to get object origins and current shading points world coordinates available in the nodes too so you could do x distance from empty for example... I know you can a bit of that in texture nodes... but would be nice in material nodes! ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Blender on the Mac App Store
Hi, As I understood, the VLC incident was because of the original authors of VLC not wanting their software to be in the App store, apple just followed the original copyright holder's request. As for the license, we need a lawyer for that :) On Thu, Jul 21, 2011 at 6:16 AM, Sergey I. Sharybin g.ula...@gmail.com wrote: Hi, Personally, I don't think it's a good idea. App Store isn't compatible with GPL license. Even more, it was accident with VLC already -- Apple simply removed this application from App Store due to license incompatibility. Markus Kasten wrote: Hello everyone. what about putting blender on the App Store (the one for Mac applications of course, not for iOS)? Blender could reach a lot more popularity. Markus K. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers -- With best regards, Sergey I. Sharybin ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] python32_d.dll requires MSVC9
Steady on, nobody is suggesting that. ;-) On 21/07/2011 4:28, Shaul Kedem wrote: Well, not only... when running cmake with VC10 in builds that require boost and ioimage libs it will fail on them as well. If we want to upgrade to VC10 I think that we should abandon VC9 and do the move once and for all On Thu, Jul 21, 2011 at 8:12 AM, Tom Edwardscont...@steamreview.org wrote: If VC9 is not installed, Blender debug builds quit with an application was unable to start correctly error as soon as they try to load the Python library. The problem is that python32_d.dll was built with the VC9 debug CRT dynamically linked, and that the debug CRT is available only through an install of VC9. The solution is simply to recompile the DLL with the runtime statically linked (/MTd). This is the only thing preventing VC10 builds from succeeding! ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Blender on the Mac App Store
hi. As far as I know, the GPL is *incompatible* with the terms of the Apple App Store. VLC was pulled because the GPL is incompatible with Apple's terms [1]. It is Apple who needs to liberalize their terms, not the FOSS developers. We must all respect the terms of the GPL, and encourage Apple to be more liberal with their terms. Given that Apple's Lion Operating System will be deployed through the App Store only, and given that Lion includes a substantial amount of GPL software, perhaps these changes are already afoot. Perhaps not. Thanks. have a day.yad jdpf [1] http://arstechnica.com/apple/news/2011/01/vlc-for-ios-vanishes-2-months-after-eruption-of-gpl-dispute.ars On Jul 21, 2011, at 11:26 AM, Shaul Kedem wrote: Hi, As I understood, the VLC incident was because of the original authors of VLC not wanting their software to be in the App store, apple just followed the original copyright holder's request. As for the license, we need a lawyer for that :) On Thu, Jul 21, 2011 at 6:16 AM, Sergey I. Sharybin g.ula...@gmail.com wrote: Hi, Personally, I don't think it's a good idea. App Store isn't compatible with GPL license. Even more, it was accident with VLC already -- Apple simply removed this application from App Store due to license incompatibility. Markus Kasten wrote: Hello everyone. what about putting blender on the App Store (the one for Mac applications of course, not for iOS)? Blender could reach a lot more popularity. Markus K. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers -- With best regards, Sergey I. Sharybin ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Material Nodes: No normals in worldspace?
This sounds really good. As impatient as users always are, I like to see it inside blender as soon a possible. ;-) The minimum I would need is the normal of the material (in world space or/and local object space), together with the world space vector of the view. Do you have some hints on how you thought it to be implemented (how to access the data) after your discussion? Greetings Tobias Am 21.07.2011 15:04, schrieb pete larabell: Hey guys, I wrote the patch to add reflection mapping (and could easily extend to other things like WS normals) to the material nodes. The issue behind the patch's delay is more of a logical issue of what parts of blender you want to expose to the node system. I spoke with kaito about this for a while and he had a good idea how we could do it without exposing render core internals. If I get a little more time I will implement the way kaito and I discussed. Cheers! Pete On Thu, Jul 21, 2011 at 2:15 AM, michael williamson micha...@cowtoolsmedia.co.uk wrote: On 21/07/11 00:37, Tobias Oelgarte wrote: in this simple case. It could be much easier and powerful to have worldspace normals and maybe even the view-vector in wordspace coordinates. This would allow many new possibilities for reflection mapping and other cool stuff. On top of that it would work smoothly together with GLSL and shouldn't be so hard to implement. Maybe this can convince one of the programming gods to implement this feature? It would be much easier! For reflection I've found the current system works fine, but if normals were changed to world space then view would have to as well It'd be nice to get object origins and current shading points world coordinates available in the nodes too so you could do x distance from empty for example... I know you can a bit of that in texture nodes... but would be nice in material nodes! ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Blender on the Mac App Store
I might be wrong, but as I understood it the problem is that the GPL requires the distributor to also provide the source of the application. In the case of the App Store Apple is the distributor. But they have never thought that anyone would like to distribute source code through their system and I think they think it's not the right place for the source anyway. I wonder why it should not be enough to provide a link to the source in the description? After all the binary in the App Store would be the same as on blender.org (binary compare would match), so one can be sure it wasn't tampered with (if you really want to test that). But I haven't read the GPL or the App Store license. That's all just what I take from all the news articles about this incident. -panzi On 07/21/2011 06:01 PM, jonathan d p ferguson wrote: hi. As far as I know, the GPL is *incompatible* with the terms of the Apple App Store. VLC was pulled because the GPL is incompatible with Apple's terms [1]. It is Apple who needs to liberalize their terms, not the FOSS developers. We must all respect the terms of the GPL, and encourage Apple to be more liberal with their terms. Given that Apple's Lion Operating System will be deployed through the App Store only, and given that Lion includes a substantial amount of GPL software, perhaps these changes are already afoot. Perhaps not. Thanks. have a day.yad jdpf [1] http://arstechnica.com/apple/news/2011/01/vlc-for-ios-vanishes-2-months-after-eruption-of-gpl-dispute.ars On Jul 21, 2011, at 11:26 AM, Shaul Kedem wrote: Hi, As I understood, the VLC incident was because of the original authors of VLC not wanting their software to be in the App store, apple just followed the original copyright holder's request. As for the license, we need a lawyer for that :) On Thu, Jul 21, 2011 at 6:16 AM, Sergey I. Sharybing.ula...@gmail.com wrote: Hi, Personally, I don't think it's a good idea. App Store isn't compatible with GPL license. Even more, it was accident with VLC already -- Apple simply removed this application from App Store due to license incompatibility. Markus Kasten wrote: Hello everyone. what about putting blender on the App Store (the one for Mac applications of course, not for iOS)? Blender could reach a lot more popularity. Markus K. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Blender on the Mac App Store
If that is the problem then the solution would be to provide a link to the source, problem solved. There is no reason apple will object to that and there is a link to the developer anyway. Btw, It's debatable whether or not apple has actually any part here, in the sense meant in the GPL. The developer chooses to use the app store as means of distribution, like a DVD or steam or other pipelines, if the GPL meant to burden every link in the chain with taking on the GPL it shoots itself in the foot. What's next? we'll ask ISPs to provide the source code and attribution because the code flows through their servers? On Thu, Jul 21, 2011 at 3:43 PM, Mathias Panzenböck grosser.meister.mo...@gmx.net wrote: I might be wrong, but as I understood it the problem is that the GPL requires the distributor to also provide the source of the application. In the case of the App Store Apple is the distributor. But they have never thought that anyone would like to distribute source code through their system and I think they think it's not the right place for the source anyway. I wonder why it should not be enough to provide a link to the source in the description? After all the binary in the App Store would be the same as on blender.org (binary compare would match), so one can be sure it wasn't tampered with (if you really want to test that). But I haven't read the GPL or the App Store license. That's all just what I take from all the news articles about this incident. -panzi On 07/21/2011 06:01 PM, jonathan d p ferguson wrote: hi. As far as I know, the GPL is *incompatible* with the terms of the Apple App Store. VLC was pulled because the GPL is incompatible with Apple's terms [1]. It is Apple who needs to liberalize their terms, not the FOSS developers. We must all respect the terms of the GPL, and encourage Apple to be more liberal with their terms. Given that Apple's Lion Operating System will be deployed through the App Store only, and given that Lion includes a substantial amount of GPL software, perhaps these changes are already afoot. Perhaps not. Thanks. have a day.yad jdpf [1] http://arstechnica.com/apple/news/2011/01/vlc-for-ios-vanishes-2-months-after-eruption-of-gpl-dispute.ars On Jul 21, 2011, at 11:26 AM, Shaul Kedem wrote: Hi, As I understood, the VLC incident was because of the original authors of VLC not wanting their software to be in the App store, apple just followed the original copyright holder's request. As for the license, we need a lawyer for that :) On Thu, Jul 21, 2011 at 6:16 AM, Sergey I. Sharybing.ula...@gmail.com wrote: Hi, Personally, I don't think it's a good idea. App Store isn't compatible with GPL license. Even more, it was accident with VLC already -- Apple simply removed this application from App Store due to license incompatibility. Markus Kasten wrote: Hello everyone. what about putting blender on the App Store (the one for Mac applications of course, not for iOS)? Blender could reach a lot more popularity. Markus K. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Blender on the Mac App Store
I don't understand the purpose of Mac App Store. You can simply download .zip from the web and drag it on desktop. What can be simpler? On the other hand you need to get in iOS App Store to be on iPhone. There absolutely no reason why we must or want to be in Mac App Store. Mac App Store probably inherited long and tedieous review proccess. And even if Blender can pass it, there will be literally weeks of delay before updates. Look at Ubuntu Software Center. Blender is 2.49 there. Moreover, downloading from website, gives the feel of community. Users can discover wiki, video tutorials, gallery, forums which are undoubtedly major sources of learning and inspiration. Differently, App Store gives a feel of no community and no development engagement. Granted, Blender can easily be in top 20, but user base will be very pretty random. Many will complain why Blender doesn't do X and does Y differently. Most of those users will uninstall faster then they feel the potential and never try it again. Alex K On Thu, Jul 21, 2011 at 3:57 PM, Shaul Kedem shaul.ke...@gmail.com wrote: If that is the problem then the solution would be to provide a link to the source, problem solved. There is no reason apple will object to that and there is a link to the developer anyway. Btw, It's debatable whether or not apple has actually any part here, in the sense meant in the GPL. The developer chooses to use the app store as means of distribution, like a DVD or steam or other pipelines, if the GPL meant to burden every link in the chain with taking on the GPL it shoots itself in the foot. What's next? we'll ask ISPs to provide the source code and attribution because the code flows through their servers? On Thu, Jul 21, 2011 at 3:43 PM, Mathias Panzenböck grosser.meister.mo...@gmx.net wrote: I might be wrong, but as I understood it the problem is that the GPL requires the distributor to also provide the source of the application. In the case of the App Store Apple is the distributor. But they have never thought that anyone would like to distribute source code through their system and I think they think it's not the right place for the source anyway. I wonder why it should not be enough to provide a link to the source in the description? After all the binary in the App Store would be the same as on blender.org (binary compare would match), so one can be sure it wasn't tampered with (if you really want to test that). But I haven't read the GPL or the App Store license. That's all just what I take from all the news articles about this incident. -panzi On 07/21/2011 06:01 PM, jonathan d p ferguson wrote: hi. As far as I know, the GPL is *incompatible* with the terms of the Apple App Store. VLC was pulled because the GPL is incompatible with Apple's terms [1]. It is Apple who needs to liberalize their terms, not the FOSS developers. We must all respect the terms of the GPL, and encourage Apple to be more liberal with their terms. Given that Apple's Lion Operating System will be deployed through the App Store only, and given that Lion includes a substantial amount of GPL software, perhaps these changes are already afoot. Perhaps not. Thanks. have a day.yad jdpf [1] http://arstechnica.com/apple/news/2011/01/vlc-for-ios-vanishes-2-months-after-eruption-of-gpl-dispute.ars On Jul 21, 2011, at 11:26 AM, Shaul Kedem wrote: Hi, As I understood, the VLC incident was because of the original authors of VLC not wanting their software to be in the App store, apple just followed the original copyright holder's request. As for the license, we need a lawyer for that :) On Thu, Jul 21, 2011 at 6:16 AM, Sergey I. Sharybing.ula...@gmail.com wrote: Hi, Personally, I don't think it's a good idea. App Store isn't compatible with GPL license. Even more, it was accident with VLC already -- Apple simply removed this application from App Store due to license incompatibility. Markus Kasten wrote: Hello everyone. what about putting blender on the App Store (the one for Mac applications of course, not for iOS)? Blender could reach a lot more popularity. Markus K. ___ 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] python32_d.dll requires MSVC9
To be able to compile Blender using MSVC 2010 (x86 at least) without recompilling some of the libraries you need to disable: - Openexr - Opencollada And this is for non debug builds. This way Blender builds and is quite stable when compilled with MSVC 2010. Is possible to compile Blender using MSVC 2010 with all the features enabled, but this require you manually recompille using MSVC 2010: - Python - Openexr - OpenCollada - Zlib (for x86 only, x64 will build fine) And manually replace these on the LIB directory, or modify the cmake scripts and filelists for the linking phase. Scons will build only if you replace the old libraries in the LIB folder for the new libraries, since scons is still not updated to support MSVC 2010 (x86) and/or MSVC 2010+Windows 7 x64 SDK (for x64 builds), and will use the components taken from the environment assuming that MSVC 2008 is installed. And if you want to build cycles, you really need to recompile all it's dependencies. Good Luck with Boost ;). I've uploading builds done with MSVC 2010 to graphicall in the past, but Real Life (TM) issues keeps me to do anything serious nowadays. Maybe in the future i will upload again these, but don't hold your breath for now. Regards. J. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] python32_d.dll requires MSVC9
Sorry, is not really needed to recompile Python in the release builds, but only on debug builds. Regards J. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Blender on the Mac App Store
From the Mac App Store Terms and conditions: Programs that don’t comply with Apple’s Human Interface Guidelines will not be accepted. Blender uses its own HIG. From the Adium Mailing list: In the current agreement for the App Store - on all platforms - there are several provisions which restrict distribution. These are incompatible with the GPL. If we were to submit Adium to the App Store, any contributor - which includes contributors to underlying libraries like libpurple, libglib, or libintl - could (1) sue us directly and (2) activate the deauthorization provision in the GPL to remove our right to use the code, both because we would have knowingly violated the GPL. This was checked with Karen Sandler, which is their legal representative. These are the 2 main reasons Blender can't use the Mac App Store. Of course the Blender Foundation can ask Apple but is a well known fact that Apple dislike the GPL, and i know at least that the ffmpeg/libav guys are pretty willing to fight anyone that uses their code in any way that breaks the GPL/LGPL part of their licensed code. Can of worms, anyone? Regards. J. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Blender on the Mac App Store
On 07/21/2011 10:48 PM, Alexandr Kuznetsov wrote: I don't understand the purpose of Mac App Store. You can simply download .zip from the web and drag it on desktop. What can be simpler? You could basically say the same about your favourite Linuxs package manager. Although I do not know if the App Store really provides all the features of a full blown package manager. I use Linux. On the other hand you need to get in iOS App Store to be on iPhone. There absolutely no reason why we must or want to be in Mac App Store. Mac App Store probably inherited long and tedieous review proccess. And even if Blender can pass it, there will be literally weeks of delay before updates. Look at Ubuntu Software Center. Blender is 2.49 there. Yeah, probably it would only be for publicity and would have no real use for blender users. -panzi ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Blender on the Mac App Store
On 07/22/2011 12:54 AM, J. wrote: From the Mac App Store Terms and conditions: Programs that don’t comply with Apple’s Human Interface Guidelines will not be accepted. Blender uses its own HIG. From the Adium Mailing list: In the current agreement for the App Store - on all platforms - there are several provisions which restrict distribution. These are incompatible with the GPL. If we were to submit Adium to the App Store, any contributor - which includes contributors to underlying libraries like libpurple, libglib, or libintl - could (1) sue us directly and (2) activate the deauthorization provision in the GPL to remove our right to use the code, both because we would have knowingly violated the GPL. This was checked with Karen Sandler, which is their legal representative. These are the 2 main reasons Blender can't use the Mac App Store. Of course the Blender Foundation can ask Apple but is a well known fact that Apple dislike the GPL, and i know at least that the ffmpeg/libav guys are pretty willing to fight anyone that uses their code in any way that breaks the GPL/LGPL part of their licensed code. Can of worms, anyone? Regards. J. I don't understand: If Apple is seen as the distributor it would be Apple that violates the GPL, because it does not provide any source. If not, then the source is not needed to be in the App Store but just somehow reachable (link to blender.org) and there would be no violation at all. Anyway, yes, it seems to be not worth the trouble at all. -panzi ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Blender on the Mac App Store
- Original Message - On 07/22/2011 12:54 AM, J. wrote: [...] From the Adium Mailing list: In the current agreement for the App Store - on all platforms - there are several provisions which restrict distribution. These are incompatible with the GPL. Right. The problem, as I understand it, is that section 6 of the GPLv2 states You may not impose any further restrictions on the recipients' exercise of the rights granted herein, but the App Store imposes further restrictions. See: http://www.fsf.org/blogs/licensing/more-about-the-app-store-gpl-enforcement Cheers, Alex ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] [Bf-blender-cvs] SVN commit: /data/svn/bf-blender [38593] branches/merwin-spacenav/release/ scripts/startup/bl_ui/space_userpref.py: Show NDOF sensitivity field in userprefs
This branch is failing to build (cmake) with itasc http://www.pasteall.org/23408 Daniel Salazar 3Developer.com On Thu, Jul 21, 2011 at 4:26 PM, Nathan Letwory nat...@letworyinteractive.com wrote: Revision: 38593 http://projects.blender.org/scm/viewvc.php?view=revroot=bf-blenderrevision=38593 Author: jesterking Date: 2011-07-21 22:26:58 + (Thu, 21 Jul 2011) Log Message: --- Show NDOF sensitivity field in userprefs Modified Paths: -- branches/merwin-spacenav/release/scripts/startup/bl_ui/space_userpref.py Modified: branches/merwin-spacenav/release/scripts/startup/bl_ui/space_userpref.py === --- branches/merwin-spacenav/release/scripts/startup/bl_ui/space_userpref.py 2011-07-21 21:43:42 UTC (rev 38592) +++ branches/merwin-spacenav/release/scripts/startup/bl_ui/space_userpref.py 2011-07-21 22:26:58 UTC (rev 38593) @@ -817,12 +817,9 @@ #sub.prop(view, wheel_scroll_lines, text=Scroll Lines) col.separator() - ''' not implemented yet sub = col.column() sub.label(text=NDOF Device:) - sub.prop(inputs, ndof_pan_speed, text=Pan Speed) - sub.prop(inputs, ndof_rotate_speed, text=Orbit Speed) - ''' + sub.prop(inputs, ndof_sensitivity, text=NDOF Sensitivity) row.separator() ___ Bf-blender-cvs mailing list bf-blender-...@blender.org http://lists.blender.org/mailman/listinfo/bf-blender-cvs ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] [Bf-blender-cvs] SVN commit: /data/svn/bf-blender [38593] branches/merwin-spacenav/release/ scripts/startup/bl_ui/space_userpref.py: Show NDOF sensitivity field in userprefs
And after disabling itasc it fails on spacenav related code http://www.pasteall.org/23409 Daniel Salazar 3Developer.com On Thu, Jul 21, 2011 at 6:44 PM, Daniel Salazar - 3Developer.com zan...@gmail.com wrote: This branch is failing to build (cmake) with itasc http://www.pasteall.org/23408 Daniel Salazar 3Developer.com On Thu, Jul 21, 2011 at 4:26 PM, Nathan Letwory nat...@letworyinteractive.com wrote: Revision: 38593 http://projects.blender.org/scm/viewvc.php?view=revroot=bf-blenderrevision=38593 Author: jesterking Date: 2011-07-21 22:26:58 + (Thu, 21 Jul 2011) Log Message: --- Show NDOF sensitivity field in userprefs Modified Paths: -- branches/merwin-spacenav/release/scripts/startup/bl_ui/space_userpref.py Modified: branches/merwin-spacenav/release/scripts/startup/bl_ui/space_userpref.py === --- branches/merwin-spacenav/release/scripts/startup/bl_ui/space_userpref.py 2011-07-21 21:43:42 UTC (rev 38592) +++ branches/merwin-spacenav/release/scripts/startup/bl_ui/space_userpref.py 2011-07-21 22:26:58 UTC (rev 38593) @@ -817,12 +817,9 @@ #sub.prop(view, wheel_scroll_lines, text=Scroll Lines) col.separator() - ''' not implemented yet sub = col.column() sub.label(text=NDOF Device:) - sub.prop(inputs, ndof_pan_speed, text=Pan Speed) - sub.prop(inputs, ndof_rotate_speed, text=Orbit Speed) - ''' + sub.prop(inputs, ndof_sensitivity, text=NDOF Sensitivity) row.separator() ___ Bf-blender-cvs mailing list bf-blender-...@blender.org http://lists.blender.org/mailman/listinfo/bf-blender-cvs ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Blender on the Mac App Store
So OSX uses no GPL software? none? On Thu, Jul 21, 2011 at 8:16 PM, Alex Fraser adfr...@vpac.org wrote: - Original Message - On 07/22/2011 12:54 AM, J. wrote: [...] From the Adium Mailing list: In the current agreement for the App Store - on all platforms - there are several provisions which restrict distribution. These are incompatible with the GPL. Right. The problem, as I understand it, is that section 6 of the GPLv2 states You may not impose any further restrictions on the recipients' exercise of the rights granted herein, but the App Store imposes further restrictions. See: http://www.fsf.org/blogs/licensing/more-about-the-app-store-gpl-enforcement Cheers, Alex ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Blender on the Mac App Store
They use at least bash, wget and gcc. Lets tell GNU so they can sue them! :) I've got another idea (then I stop spamming here): Would it comply to App Store rules if one would write a native OS X application (conforming to HIG and BSD licensed) that is a Blender Downloader or Blender Installer or Blender Manager. This would not include blender, but would download and install blender. It would also provide a menu with options like put blender into dock and associate .blend files with blender etc. Maybe it could let you manage multiple blender installation. E.g. blender 2.49, blender 2.5x and a list of the latest GraphicAll builds. If I would use OS X I would write such a software just to see whether Apple rejects it. -panzi On 07/22/2011 03:19 AM, Shaul Kedem wrote: So OSX uses no GPL software? none? On Thu, Jul 21, 2011 at 8:16 PM, Alex Fraseradfr...@vpac.org wrote: - Original Message - On 07/22/2011 12:54 AM, J. wrote: [...] From the Adium Mailing list: In the current agreement for the App Store - on all platforms - there are several provisions which restrict distribution. These are incompatible with the GPL. Right. The problem, as I understand it, is that section 6 of the GPLv2 states You may not impose any further restrictions on the recipients' exercise of the rights granted herein, but the App Store imposes further restrictions. See: http://www.fsf.org/blogs/licensing/more-about-the-app-store-gpl-enforcement Cheers, Alex ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
