phatch-dev team mailing list archive

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

Hi,

2009/10/8 Stani <spe.stani.be@xxxxxxxxx>:
> Maybe use the truck as a test case for a random blender file.
>
> On Wed, Oct 7, 2009 at 10:39 PM, Stani <spe.stani.be@xxxxxxxxx> wrote:
>> 2009/10/7 Juho Vepsäläinen <bebraw@xxxxxxxxx>:
>>> Hi,
>>>
>>> 2009/10/7 Stani <spe.stani.be@xxxxxxxxx>:
>>>> Hi Juho,
>>>> Do you plan add do some more blender power to phatch before the
>>>> blender conference? Such as:
>>>> - support for any blend file
>>>> - node editor action
>>>> Best regards,
>>>> Stani
>>>
>>> I have to spend some time on those before the trip. I will be leaving
>>> on 14th to Italy so that's my personal deadline.
>>>
>>> Currently there are a couple of things you can probably provide some
>>> useful pointers for:
>>> 1. How to construct choices of choicefield in Phatch dynamically?
>> Be sure you have merged with revision 1509 of trunk. Than you can do
>> for example in get_relevant*:
>> image_size = self._get_field('Image Size')
>> image_size.set_choices(selected_object.image_size_choices)
>>

Ok. That seems easy enough.

>>> (If
>>> you can point me to load choices from given text file for instance, I
>>> could extrapolate what I need based on that.
>> I guess you know how to open  a text file in python.
>>

Sure.

>>> If possible, it should be
>>> set up so that if the file gets changed, the choicefield updates
>>> automagically (timer  + hook to check file modification time?
>>> Alternatively use inotify on Linux
>>> (http://trac.dbzteam.org/pyinotify). Perhaps there's something similar
>>> for the other OSes).)
>> I guess the change of the file is predictable, so we can use a lighter
>> solution. Can you clarify a scenario when there would be a change that
>> phatch doesn't couldn't guess? Eg if the user gives a new blend file,
>> you can check for that in the get_relevant_* method. For an example of
>> getting the modification time of a file see lib/thumbnail.py
>> get_mtime.
>>

The point was that it should be possible to just drop in new .blends
(folder + accompanying .py and .blend) and have Phatch recognize them.
If it's a guided process, this doesn't yield any problems.

I will postpone using custom, non-prepared .blends for now and focus
on porting the old system to the new scheme.

>>> 2. How to handle the spawning of Blender node editor? It probably
>>> takes some custom UI widget for this I suppose. (Ie. have "Launch
>>> Blender" button in "Node Editor" Action. Note that it should spawn
>>> Blender only ~once~ to avoid overwriting the .blend containing the
>>> node graph (sync issue)).
>> And what happens when you have two node editor actions? You need to
>> decide if you make the node graph storable in some text format, which
>> can be embedded in the *.phatch action list, or if you use blender
>> files for it. I guess blender files are the more easy and quick
>> solution, but maybe not the best. If you use blender files they should
>> be stored alongside the action list. Maybe you should check first to
>> see how easy it is to extract the node graph. But if the python  api
>> does not support it we have no choice than using blender files. If
>> this api will be provided by blender 2.50 i would propose to  postpone
>> this feature and to focus first on using any blender file for texture
>> rendering.

The point of "one node editor" rule was to avoid any potential
complications for now.

There is no proper Python API for the node editor in 2.4x series. I
could add one but that would be rather pointless as it would mean we
would have to distribute our own, customized version of Blender with
Phatch. That would be just a lot of extra work for little gain. I
rather wait for 2.50 and see if they can come up with nice API and use
that instead. So for now it's better to store .blends.

There is another, quite significant problem related to "Node Editor"
action. There really has to be a way to pass some image to use with
previews for it. Using just some image isn't really straightforward as
Blender's node editor doesn't always support relative values (think
dilate/erode, it's given in pixels). This means that the node graph
doesn't necessarily yield the wanted results. Optimally the user
should be possible to choose which input image to preview.

Considering these two issues it might be better to postpone the
feature till 2.50 is released or just write a small node editor that
can be hooked up with Phatch without much fuzz. Alternatively
depending on design of jQuery(?) based 0.3 it might be possible to
whip up a simple node editor inside Phatch itself (example
http://javascript.neyric.com/wireit/examples/jsBox/jsBox.html). This
might lead to some sort of weird hybrid design (graph of lists of
graphs etc.) and could be beyond the point of the application.

>>
>>> 3. Where to stash node editor .blends and how? I suppose a temporary
>>> folder might do the trick for now.
>> Temporary is fine if you can extract and reconstruct the node graph.

Ok.

Sincerely,
Juho Vepsäläinen

>>
>> Best regards,
>> Stani
>>
>> PS Moved this to phatch-dev.
>>
>> --
>> Phatch Photo Batch Processor - http://photobatch.stani.be
>> SPE Python IDE - http://pythonide.stani.be
>>
>
>
>
> --
> Phatch Photo Batch Processor - http://photobatch.stani.be
> SPE Python IDE - http://pythonide.stani.be
>
> _______________________________________________
> Mailing list: https://launchpad.net/~phatch-dev
> Post to     : phatch-dev@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~phatch-dev
> More help   : https://help.launchpad.net/ListHelp
>