phatch-dev team mailing list archive

[Juho Vepsäläinen <bebraw@xxxxxxxxx>]

Public bug reported:

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.

** Affects: phatch
     Importance: Undecided
         Status: New

-- 
Implementation of "Blender Action for Software Box"
https://bugs.launchpad.net/bugs/392999
You received this bug notification because you are a member of Phatch
Developers, which is subscribed to Phatch.

Status in Phatch = Photo & Batch!: New

Bug description:
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.