[Bf-committers] Python callbacks and keeping properties in sync

Wenzel Jakob wenzel at wazlaf.org
Wed Mar 30 16:23:31 CEST 2011


Hello Ton and Doug,

Campbell requested to put use cases at the bottom of his Wiki page 
(http://wiki.blender.org/index.php/User:Ideasman42) so that a list of 
requirements can be made.

@Doug: do you have additional use cases? I just put the one that 
currently bothers me the most (see also below).

Best,
Wenzel
================================

*Notifications for custom property changes*: When implementing an 
additional rendering backend in Blender, there will usually be a slew of 
custom material properties. In LuxRender and Mitsuba, these are 
reachable via bpy.data.materials[index].(lux/mitsuba)_material.*.* (i.e. 
with some nesting). For instance, the 'v' roughness parameter of the 
Ward model in Mitsuba would be stored 
at"someMaterial.mitsuba_material.mitsuba_mat_ward.vroughness"

An important use case would be to register a callback that is invoked 
whenever one of these properties is changed so that the user interface 
can be updated (for instance to cause a redraw of the material preview). 
In the most general case, the callback would have a signature that 
provides information about what particular property was changed, and it 
would also provide the old and new value.

Ideally, this callback would be active across all material instances, 
without having to register it manually for each one. -- Wenzel 09:21, 30 
March 2011 (CEST)

On 03/30/2011 04:09 PM, Ton Roosendaal wrote:
> Hi Doug,
>
> I remind Campbell about this regularly, and we've reviewed a couple of
> strategies for it.
> The issue is extremely complex though, especially because existing
> code might need to be upgraded to comply to a decent API on python
> level.
>
> In short:
> - Data-Data dependencies belong in the dependency graph, handled
> reliably outside UI.
> - Data-UI dependencies can be handled on notifier or event levels
>
> Issues:
> - Some UI widgets/menus might maintain data as well, with dependencies
> - Our UI is directly using data pointers to write/read, with
> dependencies
>
> What would be helpful is to first make the minimal list of crucial
> features required for proper handling of exporter/integration scripts.
> I'm still missing the big picture a bit.
>
> -Ton-
>
> ------------------------------------------------------------------------
> Ton Roosendaal  Blender Foundation   ton at blender.org    www.blender.org
> Blender Institute   Entrepotdok 57A  1018AD Amsterdam   The Netherlands
>
> On 30 Mar, 2011, at 16:00, Doug Hammond wrote:
>
>> Is anyone going to acknowledge this at all?
>>
>> Cheers,
>> Doug.
>>
>>
>> On 28 March 2011 23:05, Doug Hammond
>> <doughammond at hamsterfight.co.uk>  wrote:
>>
>>> I've also seen too that there were plans to get this implemented
>>> around
>>> about now.
>>> (It was suggested in meeting minutes some weeks ago to be done in
>>> March?).
>>>
>>> Campbell has also admitted that he's got some of the code for it
>>> already
>>> written, and
>>> it is really about time this became implemented, us python devs
>>> have been
>>> waiting
>>> forever (it seems).
>>>
>>> So, any chance to get this before the stable release ?
>>>
>>> Cheers,
>>> Doug.
>>>
>>>
>>>
>>> On 28 March 2011 12:55, Wenzel Jakob<wenzel at wazlaf.org>  wrote:
>>>
>>>> Hello all,
>>>>
>>>> I am currently designing a rendering backend that integrates
>>>> Mitsuba (a
>>>> physically based renderer) with Blender 2.56a based on Doug
>>>> Hammond's
>>>> extensions framework.
>>>>
>>>> One of the issues I am periodically facing is synchronization
>>>> between
>>>> the Blender and Mitsuba interpretations of the scene. For instance,
>>>> Blender Internal and Mitsuba have wildly different material
>>>> configurations, and hence the rendering plugin adds custom UI
>>>> panels to
>>>> configure all materials.
>>>>
>>>> However, there is still a bit of overlap with Blender Internal. It
>>>> would
>>>> be great if it was possible to "react" to property changes in a
>>>> material
>>>> so that they can be forwarded to the other respective material
>>>> implementation (where it makes sense). For instance: if the user
>>>> specifies a diffuse gray BI material, that could easily be
>>>> replicated in
>>>> the Mitsuba material panel.
>>>>
>>>> I remember that somebody was working on Python-based property
>>>> callbacks,
>>>> which could potentially be used to implement such a feature. I'm
>>>> curious
>>>> to hear about the state of this work.
>>>>
>>>> Thank you,
>>>> Wenzel
>>>>
>>>>
>>>> _______________________________________________
>>>> Bf-committers mailing list
>>>> Bf-committers at blender.org
>>>> http://lists.blender.org/mailman/listinfo/bf-committers
>>>>
>>>
>> _______________________________________________
>> Bf-committers mailing list
>> Bf-committers at blender.org
>> http://lists.blender.org/mailman/listinfo/bf-committers
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers



More information about the Bf-committers mailing list