Re: [Bf-committers] Vortex particle sim/set up
I keep repeating myself but I hope the day when all of your work is merged is near! ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] RNA Extension Registration
Hi Martin, Just looked into your patch and while its improved and more flexible improvement its still creating an environment which is overkill IMHO. This goes back to the problem that you want to keep auto-registration and I'm not convinced its better then an api which gives a convenience registration function for script authors to access. This can simply be solved by collecting classes and having a single function to register them, anything more then this increases complexity of our internals significantly and only means we avoid a few lines at the end of the scripts. Updated my patch posted earlier to the ML, with minor changes. - Uses metaclass to collect classes as we agreed. - Includes line of class definition to include on registration errors (like you added with yours). Attached the updated patch here. http://projects.blender.org/tracker/index.php?func=detailaid=25809group_id=9atid=127 Re #[4], IDPropertyGroups can be defined like operators. Probably nobody did this because adding properties to existing types Scene, Group, Mesh etc.. cant be done this way. - Campbell On Thu, Jan 27, 2011 at 1:10 AM, Martin Poirier the...@yahoo.com wrote: 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). ___ 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
So basically, the best way to expose the blender C API and its data structures, is to parse all the headers in blender? and generate a ctypes bindings for everything?-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: bf-blender developers bf-committers@blender.org Date: Wednesday, 26 January, 2011, 11:11 PM 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
Re: [Bf-committers] Volume Rendering Updates
Another problem I got, I have no good idea, how to add baking of radiance cache. So basically, the radiance cache, is aligned with the global bounding box of one object. For a relative static scene, including light sources and a static volume, this radiance cached can be cached or baked for several frames. For each frame, simple volume ray casting without shading each sample point can then be done, which is of course way faster. For a moving camera relative to the volume, this would currently only work with isotropic scattering, because I don't save the angular distribution of radiance. When doing multiple scattering, this would also be inherently isotropic. Doing this for the anisotropic case would be just way more advanced than this simple solution. For my purpose it was sufficient to just specify two cache files for the ms and ss radiance, compute and dump the cache in a binary format, when those files weren't in existence and load them, if they weren't. But I wonder, how to include this properly,.. should I come up with some cache file format, do this with baking, etc? Currently I also did just one completely normal render pass and dumped the radiance cache on the first frame,... but it may be more appropriate, when there is some baking option, that I don't do a full render, but just compute the radiance cache for selected objects. aurel On 24 January 2011 18:32, ra...@info.upr.edu.cu wrote: Hi Aurel :) Improvements are allways wellcome, thanks! I have written a documentation back then, which is full of other details of the related project and a more general discussion on volume rendering. But in the volume rendering section, there should be a good explanation of my work: http://atommuell.mum.jku.at/~aurel/VolumeScatteringSimulation.pdf Again, it's really not an advanced multiple scattering technique, actually quite simple stuff. At the end of the document there are also some more formal tests, which proof the correctness of the single scattering implementation by comparing it to analytically solved scenes. I must say, is an excelnt paper, I enjoyed a lot reading it, congrats! the technique may seems simple but is correct so is a nice adition to our model... go for it :) 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
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 26.1.2011 17:30, Tom Edwards wrote: 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\) When giving a define like that you should use the Append() function of the environment. And leave out the -D part, so: env = BlenderEnvironment(ENV = os.environ) env.Append(RCFLAGS=Test=\test it\) print env['RCFLAGS'] Exit() Gives Test=test it This should give correct result when it gets used in the call that generates the windres command. /Nathan 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 - -- Nathan Letwory Letwory Interactive http://www.letworyinteractive.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJNQYfUAAoJEKtfN7KsE0Ttjs8H/1UOaZc4TgLE+q7ZqTOrogsz hZBxKm1PygWBAxD5ROif5bEjLXhJ2ZUPi6RPw+RisL02nM9hV6lTOasdpZZYWnZD J068gP/kx6ycIOT7b7VOYvBTMB0xisNSQQ7HyRQjcmZa5+Xt4+ieby3Xje7WUTl7 oFjbPf8eBXjocqDzT31uZ6KgoZEUo7MZ8ejdSAJVNi9L5oW2UVaEmEFE8MMbToVa cWJpYIgjBaj/Z7mEJnZ9xKC82bkMKy1uOnsVRevsqHKuKrJYGGylTqlxlzn8uXVP KSL3BYpL0vWvOfaFwV4/GyhPYltaXOrkBRgXtlQFPdNvWbLMa6z5mvW8LyKgEFc= =lKf0 -END PGP SIGNATURE- ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Volume Rendering Updates
Hi Aurel Regarding baking of radiance cache, have you considered a camara/view independent baking?. A way to implement this is raycasting from ligth sources and not the camera, sice ligth is aditive, for baking with several ligth sources you simply iterates over them. Cheers Farsthary Another problem I got, I have no good idea, how to add baking of radiance cache. So basically, the radiance cache, is aligned with the global bounding box of one object. For a relative static scene, including light sources and a static volume, this radiance cached can be cached or baked for several frames. For each frame, simple volume ray casting without shading each sample point can then be done, which is of course way faster. For a moving camera relative to the volume, this would currently only work with isotropic scattering, because I don't save the angular distribution of radiance. When doing multiple scattering, this would also be inherently isotropic. Doing this for the anisotropic case would be just way more advanced than this simple solution. For my purpose it was sufficient to just specify two cache files for the ms and ss radiance, compute and dump the cache in a binary format, when those files weren't in existence and load them, if they weren't. But I wonder, how to include this properly,.. should I come up with some cache file format, do this with baking, etc? Currently I also did just one completely normal render pass and dumped the radiance cache on the first frame,... but it may be more appropriate, when there is some baking option, that I don't do a full render, but just compute the radiance cache for selected objects. aurel On 24 January 2011 18:32, ra...@info.upr.edu.cu wrote: Hi Aurel :) Improvements are allways wellcome, thanks! I have written a documentation back then, which is full of other details of the related project and a more general discussion on volume rendering. But in the volume rendering section, there should be a good explanation of my work: http://atommuell.mum.jku.at/~aurel/VolumeScatteringSimulation.pdf Again, it's really not an advanced multiple scattering technique, actually quite simple stuff. At the end of the document there are also some more formal tests, which proof the correctness of the single scattering implementation by comparing it to analytically solved scenes. I must say, is an excelnt paper, I enjoyed a lot reading it, congrats! the technique may seems simple but is correct so is a nice adition to our model... go for it :) 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 ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] pixel get image processing
Yes, the problem is you need to have headers from the same version of blender used to get the offsets, that runs the python scripts. This would work best if it was a part of the blender build process though its not at all likely to happen since we already have RNA. You may be interested in: http://code.google.com/p/pybindgen/ On Thu, Jan 27, 2011 at 9:02 AM, Hart's Antler bhart...@yahoo.com wrote: So basically, the best way to expose the blender C API and its data structures, is to parse all the headers in blender? and generate a ctypes bindings for everything?-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: bf-blender developers bf-committers@blender.org Date: Wednesday, 26 January, 2011, 11:11 PM 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
Re: [Bf-committers] [Bf-blender-cvs] SVN commit: /data/svn/bf-blender [34535] trunk/blender/source/blender: More logical ordering of Empty draw types.
I'm not fussed on which defaults are used but better not change
defines (noticed this commit swaps OB_ARROWS and OB_PLAINAXES),
with that old files loading up will have this value swapped too.
On Thu, Jan 27, 2011 at 9:05 PM, Daniel Salazar zan...@gmail.com wrote:
Revision: 34535
http://projects.blender.org/scm/viewvc.php?view=revroot=bf-blenderrevision=34535
Author: zanqdo
Date: 2011-01-27 21:05:01 + (Thu, 27 Jan 2011)
Log Message:
---
More logical ordering of Empty draw types. Made Plain Axes default for
new empties
Modified Paths:
--
trunk/blender/source/blender/blenkernel/intern/object.c
trunk/blender/source/blender/makesdna/DNA_object_types.h
trunk/blender/source/blender/makesrna/intern/rna_object.c
Modified: trunk/blender/source/blender/blenkernel/intern/object.c
===
--- trunk/blender/source/blender/blenkernel/intern/object.c 2011-01-27
19:49:43 UTC (rev 34534)
+++ trunk/blender/source/blender/blenkernel/intern/object.c 2011-01-27
21:05:01 UTC (rev 34535)
@@ -1019,7 +1019,7 @@
unit_m4(ob-parentinv);
unit_m4(ob-obmat);
ob-dt= OB_TEXTURE;
- ob-empty_drawtype= OB_ARROWS;
+ ob-empty_drawtype= OB_PLAINAXES;
ob-empty_drawsize= 1.0;
if(type==OB_CAMERA || type==OB_LAMP) {
Modified: trunk/blender/source/blender/makesdna/DNA_object_types.h
===
--- trunk/blender/source/blender/makesdna/DNA_object_types.h 2011-01-27
19:49:43 UTC (rev 34534)
+++ trunk/blender/source/blender/makesdna/DNA_object_types.h 2011-01-27
21:05:01 UTC (rev 34535)
@@ -385,10 +385,10 @@
#define OB_DRAWTRANSP 128
/* empty_drawtype: no flags */
-#define OB_ARROWS 1
-#define OB_PLAINAXES 2
-#define OB_CIRCLE 3
-#define OB_SINGLE_ARROW 4
+#define OB_PLAINAXES 1
+#define OB_ARROWS 2
+#define OB_SINGLE_ARROW 3
+#define OB_CIRCLE 4
#define OB_CUBE 5
#define OB_EMPTY_SPHERE 6
#define OB_EMPTY_CONE 7
Modified: trunk/blender/source/blender/makesrna/intern/rna_object.c
===
--- trunk/blender/source/blender/makesrna/intern/rna_object.c 2011-01-27
19:49:43 UTC (rev 34534)
+++ trunk/blender/source/blender/makesrna/intern/rna_object.c 2011-01-27
21:05:01 UTC (rev 34535)
@@ -1675,9 +1675,9 @@
PropertyRNA *prop;
static EnumPropertyItem empty_drawtype_items[] = {
+ {OB_PLAINAXES, PLAIN_AXES, 0, Plain Axes, },
{OB_ARROWS, ARROWS, 0, Arrows, },
{OB_SINGLE_ARROW, SINGLE_ARROW, 0, Single Arrow, },
- {OB_PLAINAXES, PLAIN_AXES, 0, Plain Axes, },
{OB_CIRCLE, CIRCLE, 0, Circle, },
{OB_CUBE, CUBE, 0, Cube, },
{OB_EMPTY_SPHERE, SPHERE, 0, Sphere, },
___
Bf-blender-cvs mailing list
bf-blender-...@blender.org
http://lists.blender.org/mailman/listinfo/bf-blender-cvs
--
- Campbell
___
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 [34535] trunk/blender/source/blender: More logical ordering of Empty draw types.
Ah! you are right, will fix this
Daniel Salazar
www.3developer.com
2011/1/27 Campbell Barton ideasma...@gmail.com:
I'm not fussed on which defaults are used but better not change
defines (noticed this commit swaps OB_ARROWS and OB_PLAINAXES),
with that old files loading up will have this value swapped too.
On Thu, Jan 27, 2011 at 9:05 PM, Daniel Salazar zan...@gmail.com wrote:
Revision: 34535
http://projects.blender.org/scm/viewvc.php?view=revroot=bf-blenderrevision=34535
Author: zanqdo
Date: 2011-01-27 21:05:01 + (Thu, 27 Jan 2011)
Log Message:
---
More logical ordering of Empty draw types. Made Plain Axes default for
new empties
Modified Paths:
--
trunk/blender/source/blender/blenkernel/intern/object.c
trunk/blender/source/blender/makesdna/DNA_object_types.h
trunk/blender/source/blender/makesrna/intern/rna_object.c
Modified: trunk/blender/source/blender/blenkernel/intern/object.c
===
--- trunk/blender/source/blender/blenkernel/intern/object.c 2011-01-27
19:49:43 UTC (rev 34534)
+++ trunk/blender/source/blender/blenkernel/intern/object.c 2011-01-27
21:05:01 UTC (rev 34535)
@@ -1019,7 +1019,7 @@
unit_m4(ob-parentinv);
unit_m4(ob-obmat);
ob-dt= OB_TEXTURE;
- ob-empty_drawtype= OB_ARROWS;
+ ob-empty_drawtype= OB_PLAINAXES;
ob-empty_drawsize= 1.0;
if(type==OB_CAMERA || type==OB_LAMP) {
Modified: trunk/blender/source/blender/makesdna/DNA_object_types.h
===
--- trunk/blender/source/blender/makesdna/DNA_object_types.h 2011-01-27
19:49:43 UTC (rev 34534)
+++ trunk/blender/source/blender/makesdna/DNA_object_types.h 2011-01-27
21:05:01 UTC (rev 34535)
@@ -385,10 +385,10 @@
#define OB_DRAWTRANSP 128
/* empty_drawtype: no flags */
-#define OB_ARROWS 1
-#define OB_PLAINAXES 2
-#define OB_CIRCLE 3
-#define OB_SINGLE_ARROW 4
+#define OB_PLAINAXES 1
+#define OB_ARROWS 2
+#define OB_SINGLE_ARROW 3
+#define OB_CIRCLE 4
#define OB_CUBE 5
#define OB_EMPTY_SPHERE 6
#define OB_EMPTY_CONE 7
Modified: trunk/blender/source/blender/makesrna/intern/rna_object.c
===
--- trunk/blender/source/blender/makesrna/intern/rna_object.c 2011-01-27
19:49:43 UTC (rev 34534)
+++ trunk/blender/source/blender/makesrna/intern/rna_object.c 2011-01-27
21:05:01 UTC (rev 34535)
@@ -1675,9 +1675,9 @@
PropertyRNA *prop;
static EnumPropertyItem empty_drawtype_items[] = {
+ {OB_PLAINAXES, PLAIN_AXES, 0, Plain Axes, },
{OB_ARROWS, ARROWS, 0, Arrows, },
{OB_SINGLE_ARROW, SINGLE_ARROW, 0, Single Arrow, },
- {OB_PLAINAXES, PLAIN_AXES, 0, Plain Axes, },
{OB_CIRCLE, CIRCLE, 0, Circle, },
{OB_CUBE, CUBE, 0, Cube, },
{OB_EMPTY_SPHERE, SPHERE, 0, Sphere, },
___
Bf-blender-cvs mailing list
bf-blender-...@blender.org
http://lists.blender.org/mailman/listinfo/bf-blender-cvs
--
- 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] Volume Rendering Updates
First, let me clarify, you are talking about the existing light cache functionality inside blender right, not anything new you've coded? To be clear, it doesn't just cache per object, it caches independently per object instance in the render - if you've got multiple instances you want them to be lit differently. I suppose it may be an acceptable limitation if you want to bake and save lighting that it doesn't work with instances, but it's not too elegant. Currently most volume related things in blender happen on a material level - aside from the smoke modifier, there's not really any way of modifying volumes as geometry, or as object data, which would be a lot better. This also makes it difficult in that the cache data is per object, but applied on a per material basis. This is fine when it's all taken care of inside the render, but makes it even more difficult if you want to save it. It could then introduce even more limitations - only one object per material, which isn't nice either and is starting to veer outside blender's current paradigm. These are the sorts of reasons that this sort of functionality hasn't really been considered so far. Some alternatives could be: a) baking radiance to a format that can be loaded back up in the voxel data texture and rendered using that. That would at least reduce and make clearer any non-standard behaviour like not being able to share materials among objects, since it would then be explicit. b) perhaps you have an option to bake selected objects, and their shaded grids get saved to a nominated folder, by name. Once it's flagged as being baked (perhaps stored in the material), in a pre-process per frame, the renderer looks in that folder for the right files per object/objectinstance and loads up the data directly into each objectinstance's light cache before rendering if the bake files exist. If they don't exist, the light cache can remain null, and then either get cached per frame as is done now, or left un-shaded, or whatever. I would also recommend that any kind of baking be done consistently with other types of baking in blender, using the existing render baking interface. It shouldn't have to introduce yet another UI/workflow. Matt On Fri, Jan 28, 2011 at 1:35 AM, Aurel W. aure...@gmail.com wrote: Another problem I got, I have no good idea, how to add baking of radiance cache. So basically, the radiance cache, is aligned with the global bounding box of one object. For a relative static scene, including light sources and a static volume, this radiance cached can be cached or baked for several frames. For each frame, simple volume ray casting without shading each sample point can then be done, which is of course way faster. For a moving camera relative to the volume, this would currently only work with isotropic scattering, because I don't save the angular distribution of radiance. When doing multiple scattering, this would also be inherently isotropic. Doing this for the anisotropic case would be just way more advanced than this simple solution. For my purpose it was sufficient to just specify two cache files for the ms and ss radiance, compute and dump the cache in a binary format, when those files weren't in existence and load them, if they weren't. But I wonder, how to include this properly,.. should I come up with some cache file format, do this with baking, etc? Currently I also did just one completely normal render pass and dumped the radiance cache on the first frame,... but it may be more appropriate, when there is some baking option, that I don't do a full render, but just compute the radiance cache for selected objects. aurel On 24 January 2011 18:32, ra...@info.upr.edu.cu wrote: Hi Aurel :) Improvements are allways wellcome, thanks! I have written a documentation back then, which is full of other details of the related project and a more general discussion on volume rendering. But in the volume rendering section, there should be a good explanation of my work: http://atommuell.mum.jku.at/~aurel/VolumeScatteringSimulation.pdf Again, it's really not an advanced multiple scattering technique, actually quite simple stuff. At the end of the document there are also some more formal tests, which proof the correctness of the single scattering implementation by comparing it to analytically solved scenes. I must say, is an excelnt paper, I enjoyed a lot reading it, congrats! the technique may seems simple but is correct so is a nice adition to our model... go for it :) 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 ___ Bf-committers mailing list
Re: [Bf-committers] pixel get image processing
Hi Domino, Hard to say when certain features will be added back, but a hack like this could be officially supported if it we can ensure it wont crash blender (and better not use pydna, ctypes could be used internally still). - expose py_buffer access rather then ctypes array. - ensure image data access is bound to a single execution. A problem we have with our api is that python references blender's pointers (#python people tell me this is very bad). and python is not aware of re-allocations, so its very easy to crash blender if python keeps access to invalid memory. In this area we have double standards, referencing a python vertex location after undo or editmode toggle would crash blender too. We should fix this but this is a big topic on its own and I wont go into it. :S Unlike mesh data its not so important to have access to 1000s of elements at once so we could expose buffer data in a way that you only get restricted access to the buffer (so blender wont re-alloc before the next access). 2 ways to do this come to mind. - image.buffer_access(MyFuncWhichEditsABuffer) so the buffer can be disabled for future access by buffer_access once the callback is done. - python's new contexts (unrelated to bpy.context) eg: with buffer in image.buffer_context: edit the buffer The contexts have an __enter__ and __exit__ methods which may be able to be used to ensure the objects dont get accessed later on too. however I didn't use contexts yet, only read examples. http://effbot.org/zone/python-with-statement.htm, http://www.python.org/dev/peps/pep-0343/ You could question why not just add this in our C api, a memoryview patch has been submitted for this. It would work but it doesn't solve the problem of restricting access and I'm making an effort not to allow too much custom-py-c-api code into blender, since it has a tendancy to feature-creep. 2.4x py api was over 100,000 lines. Initial 2.5x RNA api over ~1500 lines (not including rna_*.c), now its approx 6000 since it includes code for keyframing, array/mathutils access and registration but I really want to keep it small. - Campbell On Thu, Jan 27, 2011 at 11:21 AM, Domino Marama dom...@dominodesigns.info wrote: On Thu, 2011-01-27 at 04:33 +, Campbell Barton wrote: 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). It is understandable, though I hope I'm right in reading don't support it until we can do it correctly as the meaning. We can't do it correctly so don't support it sounds wrong :) 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 experiment with this. Thanks for that. It'll be next week before I can test it out, but looks like it'll do what I need. 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. For my use that's plenty fast enough. The largest image size used for Second Life sculpties is 64 x 128 pixels, though I do use 512 x 512 for adding library maps to Primstar. As it's basically import and export stuff, speed isn't a big factor anyway. Note that this is totally unsupported I hope a supported way stays on the todo list, I learnt my lesson on using oddball code with the tkinter stuff under 2.49 :) But at least I can get started on the port now and just isolate the image stuff so it's easy to swap out when there's a better way. Cheers, Domino ___ 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
On Thu, Jan 27, 2011 at 4:02 PM, Campbell Barton ideasma...@gmail.com wrote: You could question why not just add this in our C api, a memoryview patch has been submitted for this. It would work but it doesn't solve the problem of restricting access and I'm making an effort not to allow too much custom-py-c-api code into blender, since it has a tendancy to feature-creep. 2.4x py api was over 100,000 lines. Initial 2.5x RNA api over ~1500 lines (not including rna_*.c), now its approx 6000 since it includes code for keyframing, array/mathutils access and registration but I really want to keep it small. It's not the size of your api that matters, it's how you use it... The simplest solution would be do a BKE_image_acquire_ibuf() in getbufferproc and then a BKE_image_release_ibuf() in releasebufferproc. Easy peasy, the imbuf stays locked as long as python has a live memoryview object on it. Maybe change things a bit so another process could get a read only buffer ptr so the ui could be updated as python did it's stuff. Also, it shouldn't be too hard to make an rna hook for tp_as_buffer so this could be per-object instead of in the pyrna_struct base class where is obviously doesn't belong. rna_struct_tp_as_buffer_procs() or something along those lines. But the main problem imo is that py_buffer support only half works -- only supports bytes and a single dimension arrays contrary to what the docs say -- so you have to do all sorts of .to_char() shenanigans to do anything useful with it which would really suck if it were extended to support the rect_float buffer...and apparently the dev who implemented it up and disappeared so there's no timeline for it working to the PEP specs. Dan ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] pixel get image processing
pybindgen won't do ctypes, thats part of the reason why i wrote RPythonic - it will do ctypes or RFFI. With RFFI compiled python can talk to C, if you need maximum speed.http://code.google.com/p/rpythonic/ --- On Thu, 1/27/11, Campbell Barton ideasma...@gmail.com wrote: From: Campbell Barton ideasma...@gmail.com Subject: Re: [Bf-committers] pixel get image processing To: bf-blender developers bf-committers@blender.org Date: Thursday, 27 January, 2011, 12:42 PM Yes, the problem is you need to have headers from the same version of blender used to get the offsets, that runs the python scripts. This would work best if it was a part of the blender build process though its not at all likely to happen since we already have RNA. You may be interested in: http://code.google.com/p/pybindgen/ On Thu, Jan 27, 2011 at 9:02 AM, Hart's Antler bhart...@yahoo.com wrote: So basically, the best way to expose the blender C API and its data structures, is to parse all the headers in blender? and generate a ctypes bindings for everything?-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: bf-blender developers bf-committers@blender.org Date: Wednesday, 26 January, 2011, 11:11 PM 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
[Bf-committers] Collada -Node- Joints issue?
Hi all, Just a quick observation on the current import/export of armatures from blender. At the moment importing a set of NODES of type JOINT treats the last N-J as a head of a blender bone rather than the tail of the last. A similar issue wioth the export of such files. If you try the COLLADA test cases for 1.4.1 at the site below (skintest_1_ID.dae for example) you will see that blender imports the terminating N-J (or N -- should be the same but not nessesarily skinned) as the head of a final bone rather than the tail of the last. This results in an extra bone compared to the original (see jpg in the folder for the test scene in Maya) This last bone is given the defualt Z-UP orientation and a length generated by some means. (default in 2.49 for this situation is in the same direction as the last bone - but still generates the extra bone over that desired) http://collada.org/owl/browse.php?sess=0parent=41expand=1order=namecurview=0sortname=ASC It is obvious from the test file and the attached jpg that this is not what was intended. When imported into current 2.56 r34525 this results: http://www.pasteall.org/pic/8375 when this file is imported into 2.49b this results: http://www.pasteall.org/pic/8376 Using as DAE generated (2.56) from this blend file: http://www.pasteall.org/blend/4968 reimported results in this for 2.56 :: http://www.pasteall.org/pic/8377 and this from 2.49b:: http://www.pasteall.org/pic/8378 Thus I believe the correct interpretation of a set of nodes, nodes-joints is that the last (leaf?) is a terminating end of a skeleton not the start of another bone. I may have interpreted this incorrectly but to me that seems the intent of the test files and demos on the Collada website seem to be. Perhaps Remi Arnaud may like to comment on the intent of these files? Cheers Mike. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
