Re: [Bf-committers] Makefile support
After some days with no activity on this topic it seems the main reason to keep nan-makefiles is because of Irix support. This raises the question does Irix compile now with nan-makefiles? Looking in the lib/irix-6.5-mips dir, referenced by nan_definitions.mk, the last built python is version 2.2, (first released 2001). We also didn't release a 2.5x beta for Irix. Supporting minority *nix OS's is fine but at some point I think we can rely on their user communities to submit patches and making sure their system is well supported. I've used CMake on a few *nix OS's: netbsd, cygwin linux. In my experience the build-system only needs minor adjustments and perhaps a few ifdef's in the code, by far the most work is in building all dependencies blender relies on. Could we treat Irix as we do NetBSD, OpenBSD, Solaris, AIX and similar. accept patches and allow active users to support but not block changes because of these systems? - Campbell. On Wed, Jan 19, 2011 at 7:51 PM, Campbell Barton ideasma...@gmail.com wrote: To link against non-system libraries you can do this in 2 ways... First you can toggle advanced options in ccmake/cmake-gui and set the paths for each lib, just to ensure you can get a working build. After that it could be supported in CMake out of the box as APPLE is supported. ./CMakeLists.txt:679 -- elseif(APPLE) You could add an elseif(CMAKE_SYSTEM MATCHES IRIX) Then set the library paths there just as OSX does. The nice thing about our cmake files is they work with Linux and BSD without any special configuration, and should do for other Unix variants too but if you don't have required depds installed on the system and want to force library paths you'll need to do this. On Wed, Jan 19, 2011 at 6:58 PM, Stefan Gartner stef...@aon.at wrote: On Sun, 2011-01-16 at 19:51 +0100, Ton Roosendaal wrote: Hi all, I already gave up on Makefiles for OSX a month ago or so... it was giving me inpredictable instable builds, and trying to figure out why I gave up after a day. On OS X the Makefiles have troubles finding the right (external) libraries in lib/ and the proper compiler/linker flags, maybe that's what's causing the instabilities. I've been experimenting a bit with a fix for that and didn't notice any problems. It seems to me it's still used by a couple of people here. I'd like to know if there's - apart from personal taste - there's important reasons to keep supporting it? The system is close to collapse under its own weight, seems to me. :) Let me confirm that switching to CMake was painless and quick and it builds faster than ever. I'm not totally happy with the noisy colorful prints of cmake, but I'm quite sure that's a matter of time to get solved too. Obviously; if we remove makefiles from svn, it'll allow in source builds for cmake. I've tried using cmake on Irix briefly and it failed building, I guess this was because it was trying to link against the system libraries instead of the much more recent libs from svn. If that can be fixed or configured easily, I wouldn't mind switching to cmake, especially as this would allow doing parallel builds. greetings, stefan ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] [Bf-blender-cvs] SVN commit: /data/svn/bf-blender [34496] trunk/blender/source/blender/ editors/object/object_transform.c: Refactoring object clear-transform operators to remove ou
Noticed it clears the delta's for location and scale but not rotation, is this intentional? On Wed, Jan 26, 2011 at 9:27 AM, Joshua Leung aligor...@gmail.com wrote: Revision: 34496 http://projects.blender.org/scm/viewvc.php?view=revroot=bf-blenderrevision=34496 Author: aligorith Date: 2011-01-26 09:27:43 + (Wed, 26 Jan 2011) Log Message: --- Refactoring object clear-transform operators to remove out the common parts, like what was done for posechannel clear-transform operators earlier. There shouldn't be any functional changes. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Makefile support
Hi, about this topic, I've heard in #blendercoders that if you will remove makefiles then cmake will allow in-source builds. We discussed about it already in irc, but I'd like to ask this here too. Would it be possible to setup cmake so that in-source builds are not allowed by default and make them an option that we have to setup intentionally? Sometimes it happens that you give the cmake command in the source folder by mistake and this then forces you to manually delete the cmake's cache, which is annoying. Thanks, Luca On 01/26/2011 10:08 AM, Campbell Barton wrote: After some days with no activity on this topic it seems the main reason to keep nan-makefiles is because of Irix support. This raises the question does Irix compile now with nan-makefiles? Looking in the lib/irix-6.5-mips dir, referenced by nan_definitions.mk, the last built python is version 2.2, (first released 2001). We also didn't release a 2.5x beta for Irix. Supporting minority *nix OS's is fine but at some point I think we can rely on their user communities to submit patches and making sure their system is well supported. I've used CMake on a few *nix OS's: netbsd, cygwin linux. In my experience the build-system only needs minor adjustments and perhaps a few ifdef's in the code, by far the most work is in building all dependencies blender relies on. Could we treat Irix as we do NetBSD, OpenBSD, Solaris, AIX and similar. accept patches and allow active users to support but not block changes because of these systems? - Campbell. On Wed, Jan 19, 2011 at 7:51 PM, Campbell Barton ideasma...@gmail.com wrote: To link against non-system libraries you can do this in 2 ways... First you can toggle advanced options in ccmake/cmake-gui and set the paths for each lib, just to ensure you can get a working build. After that it could be supported in CMake out of the box as APPLE is supported. ./CMakeLists.txt:679 -- elseif(APPLE) You could add an elseif(CMAKE_SYSTEM MATCHES IRIX) Then set the library paths there just as OSX does. The nice thing about our cmake files is they work with Linux and BSD without any special configuration, and should do for other Unix variants too but if you don't have required depds installed on the system and want to force library paths you'll need to do this. On Wed, Jan 19, 2011 at 6:58 PM, Stefan Gartner stef...@aon.at wrote: On Sun, 2011-01-16 at 19:51 +0100, Ton Roosendaal wrote: Hi all, I already gave up on Makefiles for OSX a month ago or so... it was giving me inpredictable instable builds, and trying to figure out why I gave up after a day. On OS X the Makefiles have troubles finding the right (external) libraries in lib/ and the proper compiler/linker flags, maybe that's what's causing the instabilities. I've been experimenting a bit with a fix for that and didn't notice any problems. It seems to me it's still used by a couple of people here. I'd like to know if there's - apart from personal taste - there's important reasons to keep supporting it? The system is close to collapse under its own weight, seems to me. :) Let me confirm that switching to CMake was painless and quick and it builds faster than ever. I'm not totally happy with the noisy colorful prints of cmake, but I'm quite sure that's a matter of time to get solved too. Obviously; if we remove makefiles from svn, it'll allow in source builds for cmake. I've tried using cmake on Irix briefly and it failed building, I guess this was because it was trying to link against the system libraries instead of the much more recent libs from svn. If that can be fixed or configured easily, I wouldn't mind switching to cmake, especially as this would allow doing parallel builds. greetings, stefan ___ 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 -- Regards, Luca _ http://www.mindrones.com ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] [Bf-blender-cvs] SVN commit: /data/svn/bf-blender [34496] trunk/blender/source/blender/ editors/object/object_transform.c: Refactoring object clear-transform operators to remove ou
Not intentional. But at least we've now caught this issue before we get a tracker report about it! I will fix this now, along with some other changes here I noticed while making these changes :) On Wed, Jan 26, 2011 at 10:37 PM, Campbell Barton ideasma...@gmail.com wrote: Noticed it clears the delta's for location and scale but not rotation, is this intentional? On Wed, Jan 26, 2011 at 9:27 AM, Joshua Leung aligor...@gmail.com wrote: Revision: 34496 http://projects.blender.org/scm/viewvc.php?view=revroot=bf-blenderrevision=34496 Author: aligorith Date: 2011-01-26 09:27:43 + (Wed, 26 Jan 2011) Log Message: --- Refactoring object clear-transform operators to remove out the common parts, like what was done for posechannel clear-transform operators earlier. There shouldn't be any functional changes. ___ 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] Makefile support
Hi, It's 9 years ago I used Irix for the last time, and then it was already clear it had no future (for workstations). It's really cool if people still keep Blender running there, but as for all abondonned OS's, they then have to do some porting efforts. Getting scons or cmake to work for Irix is probably easy compared to getting 2.56 run :) -Ton- Ton Roosendaal Blender Foundation t...@blender.orgwww.blender.org Blender Institute Entrepotdok 57A 1018AD Amsterdam The Netherlands On 26 Jan, 2011, at 10:08, Campbell Barton wrote: After some days with no activity on this topic it seems the main reason to keep nan-makefiles is because of Irix support. This raises the question does Irix compile now with nan-makefiles? Looking in the lib/irix-6.5-mips dir, referenced by nan_definitions.mk, the last built python is version 2.2, (first released 2001). We also didn't release a 2.5x beta for Irix. Supporting minority *nix OS's is fine but at some point I think we can rely on their user communities to submit patches and making sure their system is well supported. I've used CMake on a few *nix OS's: netbsd, cygwin linux. In my experience the build-system only needs minor adjustments and perhaps a few ifdef's in the code, by far the most work is in building all dependencies blender relies on. Could we treat Irix as we do NetBSD, OpenBSD, Solaris, AIX and similar. accept patches and allow active users to support but not block changes because of these systems? - Campbell. On Wed, Jan 19, 2011 at 7:51 PM, Campbell Barton ideasma...@gmail.com wrote: To link against non-system libraries you can do this in 2 ways... First you can toggle advanced options in ccmake/cmake-gui and set the paths for each lib, just to ensure you can get a working build. After that it could be supported in CMake out of the box as APPLE is supported. ./CMakeLists.txt:679 -- elseif(APPLE) You could add an elseif(CMAKE_SYSTEM MATCHES IRIX) Then set the library paths there just as OSX does. The nice thing about our cmake files is they work with Linux and BSD without any special configuration, and should do for other Unix variants too but if you don't have required depds installed on the system and want to force library paths you'll need to do this. On Wed, Jan 19, 2011 at 6:58 PM, Stefan Gartner stef...@aon.at wrote: On Sun, 2011-01-16 at 19:51 +0100, Ton Roosendaal wrote: Hi all, I already gave up on Makefiles for OSX a month ago or so... it was giving me inpredictable instable builds, and trying to figure out why I gave up after a day. On OS X the Makefiles have troubles finding the right (external) libraries in lib/ and the proper compiler/linker flags, maybe that's what's causing the instabilities. I've been experimenting a bit with a fix for that and didn't notice any problems. It seems to me it's still used by a couple of people here. I'd like to know if there's - apart from personal taste - there's important reasons to keep supporting it? The system is close to collapse under its own weight, seems to me. :) Let me confirm that switching to CMake was painless and quick and it builds faster than ever. I'm not totally happy with the noisy colorful prints of cmake, but I'm quite sure that's a matter of time to get solved too. Obviously; if we remove makefiles from svn, it'll allow in source builds for cmake. I've tried using cmake on Irix briefly and it failed building, I guess this was because it was trying to link against the system libraries instead of the much more recent libs from svn. If that can be fixed or configured easily, I wouldn't mind switching to cmake, especially as this would allow doing parallel builds. greetings, stefan ___ 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] Makefile support
Hi, Reviewed the mails on this topic... so let's move forward; after sunday Campbell will remove the nan-make support, allowing people to present before that date a last minute *really* good argument not to. On sunday meeting we can confirm the decision. Lots of thanks to everyone who kept make alive, and especially to Hans Lambermont (still on this list!) for making the build environment 10 years ago :) -Ton- Ton Roosendaal Blender Foundation t...@blender.orgwww.blender.org Blender Institute Entrepotdok 57A 1018AD Amsterdam The Netherlands On 26 Jan, 2011, at 11:07, Ton Roosendaal wrote: Hi, It's 9 years ago I used Irix for the last time, and then it was already clear it had no future (for workstations). It's really cool if people still keep Blender running there, but as for all abondonned OS's, they then have to do some porting efforts. Getting scons or cmake to work for Irix is probably easy compared to getting 2.56 run :) -Ton- Ton Roosendaal Blender Foundation t...@blender.org www.blender.org Blender Institute Entrepotdok 57A 1018AD Amsterdam The Netherlands On 26 Jan, 2011, at 10:08, Campbell Barton wrote: After some days with no activity on this topic it seems the main reason to keep nan-makefiles is because of Irix support. This raises the question does Irix compile now with nan-makefiles? Looking in the lib/irix-6.5-mips dir, referenced by nan_definitions.mk, the last built python is version 2.2, (first released 2001). We also didn't release a 2.5x beta for Irix. Supporting minority *nix OS's is fine but at some point I think we can rely on their user communities to submit patches and making sure their system is well supported. I've used CMake on a few *nix OS's: netbsd, cygwin linux. In my experience the build-system only needs minor adjustments and perhaps a few ifdef's in the code, by far the most work is in building all dependencies blender relies on. Could we treat Irix as we do NetBSD, OpenBSD, Solaris, AIX and similar. accept patches and allow active users to support but not block changes because of these systems? - Campbell. On Wed, Jan 19, 2011 at 7:51 PM, Campbell Barton ideasma...@gmail.com wrote: To link against non-system libraries you can do this in 2 ways... First you can toggle advanced options in ccmake/cmake-gui and set the paths for each lib, just to ensure you can get a working build. After that it could be supported in CMake out of the box as APPLE is supported. ./CMakeLists.txt:679 -- elseif(APPLE) You could add an elseif(CMAKE_SYSTEM MATCHES IRIX) Then set the library paths there just as OSX does. The nice thing about our cmake files is they work with Linux and BSD without any special configuration, and should do for other Unix variants too but if you don't have required depds installed on the system and want to force library paths you'll need to do this. On Wed, Jan 19, 2011 at 6:58 PM, Stefan Gartner stef...@aon.at wrote: On Sun, 2011-01-16 at 19:51 +0100, Ton Roosendaal wrote: Hi all, I already gave up on Makefiles for OSX a month ago or so... it was giving me inpredictable instable builds, and trying to figure out why I gave up after a day. On OS X the Makefiles have troubles finding the right (external) libraries in lib/ and the proper compiler/linker flags, maybe that's what's causing the instabilities. I've been experimenting a bit with a fix for that and didn't notice any problems. It seems to me it's still used by a couple of people here. I'd like to know if there's - apart from personal taste - there's important reasons to keep supporting it? The system is close to collapse under its own weight, seems to me. :) Let me confirm that switching to CMake was painless and quick and it builds faster than ever. I'm not totally happy with the noisy colorful prints of cmake, but I'm quite sure that's a matter of time to get solved too. Obviously; if we remove makefiles from svn, it'll allow in source builds for cmake. I've tried using cmake on Irix briefly and it failed building, I guess this was because it was trying to link against the system libraries instead of the much more recent libs from svn. If that can be fixed or configured easily, I wouldn't mind switching to cmake, especially as this would allow doing parallel builds. greetings, stefan ___ 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] Scons can't define strings with spaces
In scons, string defines cannot contain spaces. The entire value is wrapped in quote marks even if it has already been escape-quoted. env['RCFLAGS'].append(-DTEST=\a space\) env['RCFLAGS'].append(-DTEST=\nospace\) Gives: windres -DTEST=a space -DTEST=nospace And the first is, of course, an invalid arg. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] Vortex particle sim/set up
Hi guys! well, in past days my email server was down so this message is kind of late ;) anyway, here it goes: Recently an Intel developer has written a series of articles about realtime vortex simulation for games. The demo (http://software.intel.com/en-us/articles/fluid-simulation-for-video-games-part-1/) is spectacular and best of all runs in realtime. Sadly the algorithm is not open source and I wanted something similar in Blender so you know the end, dont you ;) ? I end up taking a different approach with similar results and Im very pleased! my approach require more complex set up but more advanced user control and best of all is completely Lagrangian, I mean completely boundless , whether the Intel approach is a hybrid algorithm lagrangian/eulerian (lattice-particle method). I took advantage of the fact that the current Blender particle system is a second order simulation system , where particles act as source of force field, and the current vortex particle field has the rotational vector very limited and locked to the particle velocity direction . well, I have made a simple patch (http://www.pasteall.org/18508/diff) to allow more user control and watch yourself! http://farsthary.wordpress.com/2011/01/25/spin-my-particles/ Cheers Farsthary ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Vortex particle sim/set up
It is OpenSource, the source can be find here: http://software.intel.com/file/31849 (Link from the 8th and last page of the article) However it is copyrighted and not under any specified lisence. You can still read it or contact the author if you want to copy some code. Xavier 2011/1/26 ra...@info.upr.edu.cu Hi guys! well, in past days my email server was down so this message is kind of late ;) anyway, here it goes: Recently an Intel developer has written a series of articles about realtime vortex simulation for games. The demo ( http://software.intel.com/en-us/articles/fluid-simulation-for-video-games-part-1/ ) is spectacular and best of all runs in realtime. Sadly the algorithm is not open source and I wanted something similar in Blender… so you know the end, don’t you ;) ? I end up taking a different approach with similar results and I’m very pleased! my approach require more complex set up but more advanced user control and best of all is completely Lagrangian, I mean completely boundless , whether the Intel approach is a hybrid algorithm lagrangian/eulerian (lattice-particle method). I took advantage of the fact that the current Blender particle system is a second order simulation system , where particles act as source of force field, and the current vortex particle field has the rotational vector very limited and locked to the particle velocity direction …. well, I have made a simple patch (http://www.pasteall.org/18508/diff) to allow more user control and watch yourself! http://farsthary.wordpress.com/2011/01/25/spin-my-particles/ Cheers Farsthary ___ 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] Scons can't define strings with spaces
In scons, string defines cannot contain spaces. The entire value is wrapped in quote marks even if it has already been escape-quoted. env['RCFLAGS'].append(-DTEST=\a space\) env['RCFLAGS'].append(-DTEST=\nospace\) Gives: windres -DTEST=a space -DTEST=nospace And the first is, of course, an invalid arg. Apostrophes are valid string delimiter also: Have you tried env['RCFLAGS'].append(-DTEST='a space') -- Dr. Lars Krueger Neu: GMX De-Mail - Einfach wie E-Mail, sicher wie ein Brief! Jetzt De-Mail-Adresse reservieren: http://portal.gmx.net/de/go/demail ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] Scons can't define strings with spaces
Hi Lars, env['RCFLAGS'].append(-DTEST=\a space\) env['RCFLAGS'].append(-DTEST=\nospace\) Gives: windres -DTEST=a space -DTEST=nospace among scons docs there is a phrase: string surrounded by double quotation marks is interpreted as a single argument, regardless of white space contained within so env['RCFLAGS'].append(-DTEST=\a space\) might be what you are looking for ( not tested though ) Regards Sergey ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Vortex particle sim/set up
Hi It is OpenSource, the source can be find here: http://software.intel.com/file/31849 (Link from the 8th and last page of the article) However it is copyrighted and not under any specified lisence. You can still read it or contact the author if you want to copy some code. Xavier Thanks Xavier! would be nice if the author agree on using its algorithms for Blender, though is not very starigthfoward to integrate and definately wouldn't be as fast (it relaies heavily on Intel TBB) The small patch I have implemented is a nice solution to some of the desired VFX that can be done with that, currently I have UC and particle surfacing in my priority Blender Todo but is something worth to considerate in the future regarding a full implementation of the vortex particle simulator ;) Cheers Farsthary ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Scons can't define strings with spaces
It's me, not Lars. That line gives SyntaxError: unexpected character after line continuation character because double quotes means a zero-character string, and so everything following it is interpreted by Python. On 26/01/2011 8:01, Sergey Kurdakov wrote: Hi Lars, env['RCFLAGS'].append(-DTEST=\a space\) env['RCFLAGS'].append(-DTEST=\nospace\) Gives: windres -DTEST=a space -DTEST=nospace among scons docs there is a phrase: string surrounded by double quotation marks is interpreted as a single argument, regardless of white space contained within so env['RCFLAGS'].append(-DTEST=\a space\) might be what you are looking for ( not tested though ) Regards Sergey ___ 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] Scons can't define strings with spaces
Hi Tom, and escape sequence with \oooCharacter with octal value ooo \xhhCharacter with hex value hh where space is Octal 40or Hex 20 does not help too? Regards Sergey ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Scons can't define strings with spaces
I don't quite believe it, but no! On 26/01/2011 9:18, Sergey Kurdakov wrote: Hi Tom, and escape sequence with \ooo Character with octal value ooo \xhh Character with hex value hh where space is Octal 40 or Hex 20 does not help too? Regards Sergey ___ 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] Scons can't define strings with spaces
Hi Tom then, though it looks not nice - but instead of space to use a special ( maybe unicode ) character, then replace this character with space as a last step of appending vars to env['RCFLAGS']? Regards Sergey ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] RNA Extension Registration
Hi,
After talking with Campbell at length this morning (my morning), here's what
was agreed upon.
- Keep using a metaclass to build a list of extension type per module
- The automatic registration system should support both runtime and define time
registration. [1]
- Turning on or off automatic registration should require *at most* a single
function call at the end of a module. [2]
The only last decision to take, as far as I understood (and I hope there wasn't
a misunderstanding) is whether or not the automatic method should be opt in or
opt out.
I've made some changes to the automatic system today (patch attached) that
would make it easy to support opt in or opt out painlessly. It also
demonstrates how the metaclass can be used to gather more information about the
types (file and line where they are defined).
Regards,
Martin
Don't read the following unless you want boring details on stuff most people
don't care about (and shouldn't)
===
[0] Currently, IDPropGroups are treated separately than other types. That was a
work around for previous coding practices and needs to be removed.
[1] Define time is the usual case: built in modules and addons. Runtime is both
for definitions during a call to a module and for text window execution
(although the later one could probably work like built-in modules).
[2] Something like bpy.utils.manual_registration() to turn off or
bpy.utils.register(__name__) to register all types in a module. This removes
the need of doing shenanigans like calling the module's register method if
__name__ == main to support text window execution and whatnot, which, IMHO is
a good thing.
[3] I also suggested we support optional register and unregister class methods
in RNA types. This would help remove code entropy and make the definitions more
self contained (for example, a class defining OBJ import could also contain the
code to add and remove itself from menus instead of having it in the module's
function). The jury is still out on whether that's a good idea or not.
[4] We both agreed that IDPropGroups properties should be defined using the
same syntax as operator properties (if possible) instead of having to add them
post registration. Campbell said he'd try his hand at that later this week
(IIRC).
Index: release/scripts/modules/bpy_types.py
===
--- release/scripts/modules/bpy_types.py (revision 34509)
+++ release/scripts/modules/bpy_types.py (working copy)
@@ -553,82 +553,104 @@
import collections
TypeMap = {}
-# Properties (IDPropertyGroup) are different from types because they need to be registered
-# before adding sub properties to them, so they are registered on definition
-# and unregistered on unload
-PropertiesMap = {}
# Using our own loading function we set this to false
# so when running a script directly in the text editor
-# registers moduals instantly.
+# registers modules instantly.
_register_immediate = True
+class DelayedRegistration:
+def __enter__(self):
+global _register_immediate
+_register_immediate = False
-def _unregister_module(module, free=True):
-for t in TypeMap.get(module, ()):
+def __exit__(self, *args):
+global _register_immediate
+_register_immediate = True
+
+class TypeEntry:
+def __init__(self, cls, path, line):
+self.cls = cls
+self.path = path
+self.line = line
+self.registered = False
+
+def register(self):
+if self.registered:
+return
+
+import bpy
+t = self.cls
try:
-bpy_types.unregister(t)
+bpy_types.register(t)
+if hasattr(t, register):
+t.register()
+self.registered = True
+
+if bpy.app.debug:
+print(Registered class '%s.%s' % (t.__module__, t.__name__))
+print(\t, self.path, line, self.line)
except:
import traceback
-print(bpy.utils._unregister_module(): Module '%s' failed to unregister class '%s.%s' % (module, t.__module__, t.__name__))
-traceback.print_exc()
+print(bpy.utils._register_module(): failed to register class '%s.%s' % (t.__module__, t.__name__))
+print(\t, self.path, line, self.line)
+traceback.print_last()
+
+def unregister(self):
+if not self.registered:
+return
-if free == True and module in TypeMap:
-del TypeMap[module]
-
-for t in PropertiesMap.get(module, ()):
+t = self.cls
try:
+if hasattr(t, unregister):
+t.unregister()
bpy_types.unregister(t)
+self.registered = False
except:
import traceback
-print(bpy.utils._unload_module(): Module '%s' failed to unregister class
Re: [Bf-committers] [Bf-blender-cvs] SVN commit: /data/svn/bf-blender [34519] trunk/blender/intern/ghost/intern/ GHOST_SystemWin32.cpp: Silencing some annoying key-event prints in Win32 console:
oh thanks God.
I thought it was something really wrong with my build environment here :)
2011/1/26 Joshua Leung aligor...@gmail.com
Revision: 34519
http://projects.blender.org/scm/viewvc.php?view=revroot=bf-blenderrevision=34519
Author: aligorith
Date: 2011-01-26 23:58:20 + (Wed, 26 Jan 2011)
Log Message:
---
Silencing some annoying key-event prints in Win32 console:
The console was getting flooded with output like
g
i
i
...
all as a result of what looks like a debugging print. Whoever put this
in, you can get back your debugging prints by enabling BF_GHOST_DEBUG
in your local config :)
Modified Paths:
--
trunk/blender/intern/ghost/intern/GHOST_SystemWin32.cpp
Modified: trunk/blender/intern/ghost/intern/GHOST_SystemWin32.cpp
===
--- trunk/blender/intern/ghost/intern/GHOST_SystemWin32.cpp 2011-01-26
23:33:08 UTC (rev 34518)
+++ trunk/blender/intern/ghost/intern/GHOST_SystemWin32.cpp 2011-01-26
23:58:20 UTC (rev 34519)
@@ -738,7 +738,10 @@
}
event = new GHOST_EventKey(getSystem()-getMilliSeconds(),
keyDown ? GHOST_kEventKeyDown: GHOST_kEventKeyUp, window, key, ascii);
+
+#ifdef BF_GHOST_DEBUG
std::cout ascii std::endl;
+#endif
}
else {
event = 0;
___
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] pixel get image processing
Adding image access properly is tricky because it needs to work right with blender, notify on changes, upload rect from float, lock the image threads before accessing. I had a talk to Ton about this but he's of the opinion to support it correctly or not at all (which is understandable). But, I get the impression python devs work on specific projects where image access is useful (research custom scripts) so I wrote a ctypes (pure python) direct memory access to pixel data for people who like to experement with this. a quick test on setting all pixels on a 1024x1024 image though python took 0.75 seconds, getting was about the same. Is someone wants to extend this further they could add 'py_buffer' access to bypass pythons slowness. Note that this is totally unsupported, The script is 30 lines added to the bottom of pydna.py which adds buffer_raw attribute to existing image objects. Download: http://www.graphicall.org/ftp/ideasman42/image_buffer_raw_access.py Example usage. # Inserts property into blenders Image RNA. import image_buffer_raw_access ima = bpy.data.images['MyImage'] x, y, rect, rect_float = ima.buffer_raw pixel_index_max = x * y * 4 # set colors for first pixel rect[0] = 0 # red rect[1] = 255 # green rect[2] = 128 # blue rect[3] = 255 # alpha On Tue, Jan 25, 2011 at 11:55 PM, Domino Marama dom...@dominodesigns.info wrote: On Tue, 2011-01-25 at 15:44 -0700, Dan Eicher wrote: Anyhoo, image data access comes up quite often and the party line it seems is to just use ctypes (which doesn't work for our windows brethren due to the way msvc exports symbols). Or there's an 'unofficial' port of PIL to py3 that works according to Josh (from the Tube project) blog but I haven't tested it yet meself. I've got to say that the continued lack of any official way to manipulate and read images from python is a show stopper for me and a large number of users of my Primstar scripts for Second Life sculpties. One of my users offers paid support for my scripts and I know they get hundreds of new customers each month. The active user base is well into the thousands, and we are all still using Blender 2.49 :) I've users on Windows version from XP upwards, various Linux distros and even Mac users willing to put up with UI bugs caused by my use of tkinter dialogues. I'm not interested in rewriting Primstar in C, some of the features would be too complex to implement as I make extensive use of variable length lists per pixel during the bake process to provide unrivalled flexibility in sculptie creation. I also couldn't support all the platforms I currently do with Python. Hopefully the mission to move all users to 2.5.x will outweigh the issues in allowing image editing in Python soon as there's a lot of us waiting for the scales to tip ;) Something like the RenderLayer.rect access would be great, but I'd settle for get_rect and set_rect if live access is too slow on a pixel basis. Though too slow is better than not possible in my book anyway.. ___ 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] pixel get image processing
Very interesting Ideasman,is this the secret back door for getting into blender from ctypes? Passing empty strings returns blenders internals, just like when ctypes normally loads an external shared library? blend_cdll = ctypes.CDLL() blend_lib = ctypes.LibraryLoader() -brett --- On Wed, 1/26/11, Campbell Barton ideasma...@gmail.com wrote: From: Campbell Barton ideasma...@gmail.com Subject: Re: [Bf-committers] pixel get image processing To: dom...@dominodesigns.info, bf-blender developers bf-committers@blender.org Date: Wednesday, 26 January, 2011, 8:33 PM Adding image access properly is tricky because it needs to work right with blender, notify on changes, upload rect from float, lock the image threads before accessing. I had a talk to Ton about this but he's of the opinion to support it correctly or not at all (which is understandable). But, I get the impression python devs work on specific projects where image access is useful (research custom scripts) so I wrote a ctypes (pure python) direct memory access to pixel data for people who like to experement with this. a quick test on setting all pixels on a 1024x1024 image though python took 0.75 seconds, getting was about the same. Is someone wants to extend this further they could add 'py_buffer' access to bypass pythons slowness. Note that this is totally unsupported, The script is 30 lines added to the bottom of pydna.py which adds buffer_raw attribute to existing image objects. Download: http://www.graphicall.org/ftp/ideasman42/image_buffer_raw_access.py Example usage. # Inserts property into blenders Image RNA. import image_buffer_raw_access ima = bpy.data.images['MyImage'] x, y, rect, rect_float = ima.buffer_raw pixel_index_max = x * y * 4 # set colors for first pixel rect[0] = 0 # red rect[1] = 255 # green rect[2] = 128 # blue rect[3] = 255 # alpha On Tue, Jan 25, 2011 at 11:55 PM, Domino Marama dom...@dominodesigns.info wrote: On Tue, 2011-01-25 at 15:44 -0700, Dan Eicher wrote: Anyhoo, image data access comes up quite often and the party line it seems is to just use ctypes (which doesn't work for our windows brethren due to the way msvc exports symbols). Or there's an 'unofficial' port of PIL to py3 that works according to Josh (from the Tube project) blog but I haven't tested it yet meself. I've got to say that the continued lack of any official way to manipulate and read images from python is a show stopper for me and a large number of users of my Primstar scripts for Second Life sculpties. One of my users offers paid support for my scripts and I know they get hundreds of new customers each month. The active user base is well into the thousands, and we are all still using Blender 2.49 :) I've users on Windows version from XP upwards, various Linux distros and even Mac users willing to put up with UI bugs caused by my use of tkinter dialogues. I'm not interested in rewriting Primstar in C, some of the features would be too complex to implement as I make extensive use of variable length lists per pixel during the bake process to provide unrivalled flexibility in sculptie creation. I also couldn't support all the platforms I currently do with Python. Hopefully the mission to move all users to 2.5.x will outweigh the issues in allowing image editing in Python soon as there's a lot of us waiting for the scales to tip ;) Something like the RenderLayer.rect access would be great, but I'd settle for get_rect and set_rect if live access is too slow on a pixel basis. Though too slow is better than not possible in my book anyway.. ___ 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 ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] pixel get image processing
Blank strings to these functions use the current process. Typically ctypes is not all that useful for data access with large C programs because you need to match the ctypes class with the C headers (involves parsing headers or manual copying). ctypes.CDLL() / ctypes.LibraryLoader() are only used to extract the DNA struct info blender stores internally for blend file reading. Its possible to read the image buffer with a much smaller script if the 'Image' struct was hard coded into it, but when writing pydna.py I was more interested in a way to wrap all DNA, not image access, advantage with this method is Image struct changes wont break. Any changes to the ImBuf struct will break since ImBuf is not a DNA struct, it cant be auto-wrapped. Disclaimer that pydna.py is 'use at own risk', experimental, unsupported by BF. - Campbell On Thu, Jan 27, 2011 at 6:41 AM, Hart's Antler bhart...@yahoo.com wrote: Very interesting Ideasman,is this the secret back door for getting into blender from ctypes? Passing empty strings returns blenders internals, just like when ctypes normally loads an external shared library? blend_cdll = ctypes.CDLL() blend_lib = ctypes.LibraryLoader() -brett --- On Wed, 1/26/11, Campbell Barton ideasma...@gmail.com wrote: From: Campbell Barton ideasma...@gmail.com Subject: Re: [Bf-committers] pixel get image processing To: dom...@dominodesigns.info, bf-blender developers bf-committers@blender.org Date: Wednesday, 26 January, 2011, 8:33 PM Adding image access properly is tricky because it needs to work right with blender, notify on changes, upload rect from float, lock the image threads before accessing. I had a talk to Ton about this but he's of the opinion to support it correctly or not at all (which is understandable). But, I get the impression python devs work on specific projects where image access is useful (research custom scripts) so I wrote a ctypes (pure python) direct memory access to pixel data for people who like to experement with this. a quick test on setting all pixels on a 1024x1024 image though python took 0.75 seconds, getting was about the same. Is someone wants to extend this further they could add 'py_buffer' access to bypass pythons slowness. Note that this is totally unsupported, The script is 30 lines added to the bottom of pydna.py which adds buffer_raw attribute to existing image objects. Download: http://www.graphicall.org/ftp/ideasman42/image_buffer_raw_access.py Example usage. # Inserts property into blenders Image RNA. import image_buffer_raw_access ima = bpy.data.images['MyImage'] x, y, rect, rect_float = ima.buffer_raw pixel_index_max = x * y * 4 # set colors for first pixel rect[0] = 0 # red rect[1] = 255 # green rect[2] = 128 # blue rect[3] = 255 # alpha On Tue, Jan 25, 2011 at 11:55 PM, Domino Marama dom...@dominodesigns.info wrote: On Tue, 2011-01-25 at 15:44 -0700, Dan Eicher wrote: Anyhoo, image data access comes up quite often and the party line it seems is to just use ctypes (which doesn't work for our windows brethren due to the way msvc exports symbols). Or there's an 'unofficial' port of PIL to py3 that works according to Josh (from the Tube project) blog but I haven't tested it yet meself. I've got to say that the continued lack of any official way to manipulate and read images from python is a show stopper for me and a large number of users of my Primstar scripts for Second Life sculpties. One of my users offers paid support for my scripts and I know they get hundreds of new customers each month. The active user base is well into the thousands, and we are all still using Blender 2.49 :) I've users on Windows version from XP upwards, various Linux distros and even Mac users willing to put up with UI bugs caused by my use of tkinter dialogues. I'm not interested in rewriting Primstar in C, some of the features would be too complex to implement as I make extensive use of variable length lists per pixel during the bake process to provide unrivalled flexibility in sculptie creation. I also couldn't support all the platforms I currently do with Python. Hopefully the mission to move all users to 2.5.x will outweigh the issues in allowing image editing in Python soon as there's a lot of us waiting for the scales to tip ;) Something like the RenderLayer.rect access would be great, but I'd settle for get_rect and set_rect if live access is too slow on a pixel basis. Though too slow is better than not possible in my book anyway.. ___ 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 ___ Bf-committers mailing list
