Implementation of "Blender Action for Software Box"

[Juho Vepsäläinen]

This patch implements https://blueprints.launchpad.net/phatch/+spec/blender-action .

Note that the .blend file provided with the tarball ~must~ be placed into /phatch/data/blender. The current implementation contains only one action, Product Box and it's quite limited functionality wise (only colors/box depth can be changed, it figures out the width/height based on image proportions). As no float sliders are available yet I used integer one. It's scaled by ratio of 0.1 to float (so 10 -> 1.0 etc.).

The basic architecture is quite simple. It is split in two main sections: the Phatch related part and the Blender related part. The Phatch related part consists of two files, .py and .blend. The Phatch related part is implemented in blender.py action file by subclassing BlenderAction as follows:
class ProductBoxAction(BlenderAction):
    name = _t('Product Box')
    filename = 'box' # this refers to the name of the .blend and .py files provided for Blender in /data/blender! it might make sense to use convention here though so you would get the filename based on name (ie. product_box.py and product_box.blend in this case)

    def __init__(self):
        self.options[_t('Box Depth')] = ConstrainedFloat(value=1.0,
                                                         min=0.0,
                                                         max=10.0)
        self.options[_t('Floor Color')] = Color('#11133A')
        self.options[_t('Upper Background Color')] = Color('#11133A')
        self.options[_t('Lower Background Color')] = Color('#5B86B5')

Note the way options are defined in __init__. The current implementation uses a model based on which user interface related aspects are generated. Currently there are only two types, ConstrainedFloat and Color, but the system is easy to extend on demand. Please see the implementation of these classes and their parent, Value, for more information. If you add a new type, remember to check out /data/blender/runner.py too as it contains an important mapping function that parses this data into format which the Blender script can then use.

The Blender related files (/data/blender/box.py and /data/blender/box.blend in this case) should be prepared to operate Blender based on input data. Option names are mapped automatically to lowercase format (ie. "Floor Color" maps to "floor_color"). The .py file must implement def set_up_render(args). As may be guessed the options may be accessed via args (ie. args['floor_color'] would return color of the floor in Blender compatible format). The rest is using these options to manipulate Blender data via its API. Please consult the Blender Python API for more information.

Note that the current implementation doesn't support concept of relevant fields yet. It can be extended to support it by extending the model architecture a bit (ie. Choice class or similar). Also it would be good to implement Options class as an ordered one instead of a regular. The same applies for the Actions class.

[Stani (stani)]

Hi Juho,
Thanks for your work.
- Could you use the standard lib optparse.OptionParser to parse the values, which Phatch uses? That allows defaults and type conversions. For an example see phatch/app.py
- Please use Fields and don't introduce options. As said before this action should be implemented as the imagemagick action for now. The reason is that in the next release all Imagemagick and Blender actions will be independent actions, next to the pil actions. So I prefer that both Imagemagick and Blender follow the same approach for now.
- I'll look into providing a FloatSliderField. So for now you can use a FloatField or SliderField, as you did now.

[Juho Vepsäläinen (bebraw)]

>- Could you use the standard lib optparse.OptionParser to parse the values, which Phatch uses? That allows defaults and type >conversions. For an example see phatch/app.py

At a quick glance I could not see what specific advantage using OptionsParser might give in this case. It could parse the predefined part, yes. I did not see a way to handle parsing in more generic way as is needed for handling option parameters (ie. Background Color), however. So at the worst case you would end up using a bit of the old solution and a bit of new and might end up with two problems instead of one. :)

>- Please use Fields and don't introduce options. As said before this action should be implemented as the imagemagick action for now. >The reason is that in the next release all Imagemagick and Blender actions will be independent actions, next to the pil actions. So I >prefer that both Imagemagick and Blender follow the same approach for now.

In the current solution it's quite simple to treat Blender actions as separate. Sure it takes some shuffling around but not that much. I won't be spending time restructuring it to the ImageMagick format. I rather let someone else to do that. :)

[Stani (stani)]

Hi, I won't have much time in the near future, as I leave tomorrow to Europython and afterwards to RMLL. After that I'll probably go on holiday for a couple of weeks, so in the worst case it might take till september. I'll try to see what I can do.

[Stani (stani)]

Hi Juho, I finally found some time to implement your action.