[Bf-committers] Blender Command Port

Sun Apr 13 07:47:00 CEST 2008

Hi Stephen,

On Sat, 2008-04-12 at 13:00 -0400, Stephen Swaney wrote:
> On Sun, Apr 13, 2008 at 12:12:18AM +0900, Dietrich Bollmann wrote:
> 
> > And for the rest:  Is it enough if I
> > 
> >   - change the code to use a similar option parse strategy
> >     as is used for the other Blender options?
> > 
> >   - delete my general debug option from the patch 
> >     and substitute it with a simplified one 
> >     which is only used by the command port?
> > 
> >   - remove the --geometry NNNxNNN+NNN+NNN option I added?
> > 
> > As currently everybody is busy with the new release, I probably 
> > better commit a new version of my command port patch when Blender 
> > 2.26 is out, right?
> 
> After numerous tracker comments and a long mail list thread, I am 
> happy to see we finally have an understanding.

So am I :)

> After the 2.46 release, we intend for Blender to have a new event
> handling system.

That sounds like good news :)

> It will make doing things like socket reads or command ports easier
> and will not require handlers to sleep().

So it should be easy to adapt the command port code also.

By the way, what do you mean by "handlers to sleep()"?

The `blash' client only sleeps when the Blender client is started
before the Blender server.  By doing so the client waits a certain
time for the server to come up and tries in regular intervals to
reconnect.

This is very handy when using Blender from a "client" program - for
example to render objects generated by the client: The user only
starts the client, the client starts blender and waits for it to come
up.  When Blender is ready to receive commands the connection is
established.

The time can be specified on the command line, and the client only
sleeps during the these intervals before trying to reconnect again.

Nothing - neither the client thread nor the Blender server thread -
ever sleeps in any other situation as their synchronisation is done
via a condition variable and the mutex protected Blender main event
loop.

May be I should explain a little bit better how the command port
works:

  - When Blender is started with the command port option, a separate
    server thread is started and listens on a port.

  - When a client connects to the server, a new client thread is
    forked and the connection is passed to a new client port.  Every
    new client gets a new thread.

  - When a client sends some commands, a new event structure
    consisting of a special event identifier and the command text is
    inserted into Blenders main event loop.

    This doesn't make any problems as I made the Blender event loop
    thread save by protecting it with mutexs.

  - The client waits on a condition variable until the event is
    processed inside the main loop and the the main loop event handler
    signals the client that the result is available.

  - When the client python code has been evaluated the Blender main
    event loop thread continues with the next event.

  - After getting the result the client thread continues within its
    own process - in the case of my `blash' blender python shell
    client by printing the result or error to the user shell and
    waiting for a new shell input by the user.

    The blash shell looks like a normal python shell but the code is
    executed inside the Blender server and the result is a shell
    output and a new Blender state. (New objects render, objects moved
    in the scene etc...)

By the way, the client I developed the command port for is part of a
lisp program which generated 3D objects from a grammar and uses
Blender to display and render them.  (Part of my PhD research in
architecture.)

> This is certainly a useful feature, but personally, I'm not sure if
> further work on this patch as it stands is worth the effort at this
> point.

Probably this is because you personally think about Blender as an
interactive GUI based tool for animation artists and do not understand
why somebody would wish to use Blender as a server anyway?

I personally think the Blender server mode is a __VERY__ useful
feature.  Please ask also other people and think about their way of
using blender - for example Stani's way to use Blender from SPE!
(SPE, a (Blender) Python IDE is the client, Blender the server, even
if it looks the other way around from the user perspective.
http://lists.blender.org/pipermail/bf-python/2008-March/thread.html#5190 )

I think there is much more potential in Blender than to use it as a 3D
artists design tool only (which is of course also a very good way to
use Blender :)

By the way, I used the name `blash' for my shell client, because years
ago, after changing to Blender from Maya, I had to switch back from
Blender to Maya.  The reason was the absence of a command port for
Blender and the presence of the "Maya Command Port" in the case of Maya.

The Maya command port is part of the Motion Capture developers kit and
can be used in lots of different ways, for example for ... motion
capturing :). See for example:
http://caad.arch.ethz.ch/info/maya/manual/Commands/commandPort.html ,
http://www.google.com/search?q=maya+command+port .

Beside motion capturing, another usage could be to remote control
Blender animations from other tools - for example to use it as a
virtual puppet theatre.  Here in Japan for example, there are recently
a lot of new games using computers in this way and I see a potential
for Blender here also.  This would also be a great tool for children
to learn animation :)  ...and a nice way to play around with blender
and premodelled puppets and objects like those on the new Bunny CD for
people who do not have the time or the patience to spend months on
playing around with animation curves.  It might be nice for professional
animators also.

another interesting way to use the command port could be crowd
simulations like fish swarms in the sea: A client calculates their
movement and sends the command over to Blender to render them in real
time.  Or the automatic rendering from scientific results
(visualisation) using Blender!

But rather than to use Maya I prefer to work with open source products
and this is why I started to implement this functionality for Blender
after I had to switch back to Maya.

I used `blash' as name for the shell client as it allowed me to get back
to Blender and to abandon Maya once again: `BLender Again SHell' = BLASH
- and in order to honour `bash' of course :) - (`bash' is the the `Back
Again SHell' - the revival of good old `sh' after `csh', `tcsh', ...
got into power for a while...)

I hope these thoughts make the command port more interesting for you :)

Thanks for your understanding,

Dietrich

I just realised that your answer didn't reach the bf-python list
archive.  Also I think the current thread might be better relocated to
the developer mailing list?

Sending a copy to both, bf-python and bf-committers...

Relevant links:

  - original thread:
http://lists.blender.org/pipermail/bf-python/2008-March/thread.html#5190
  - command port links:
    http://formgames.org/blender/command-port/

https://projects.blender.org/tracker/index.php?func=detail&aid=6887&group_id=9&atid=127
    (The patch only works until Blender 2.44 but I have a private
    version working for the current state of the Blender SVN if somebody
    is interested.)

Thanks again, Dietrich :)

On Sat, 2008-04-12 at 13:00 -0400, Stephen Swaney wrote:
> On Sun, Apr 13, 2008 at 12:12:18AM +0900, Dietrich Bollmann wrote:
> 
> > And for the rest:  Is it enough if I
> > 
> >   - change the code to use a similar option parse strategy
> >     as is used for the other blender options?
> > 
> >   - delete my general debug option from the patch 
> >     and substitute it with a simplified one 
> >     which is only used by the command port?
> > 
> >   - remove the --geometry NNNxNNN+NNN+NNN option I added?
> > 
> > As currently everybody is busy with the new release, I probably
better
> > commit a new version of my command port patch when blender 2.26 is
out,
> > right?
> 
> After numerous tracker comments and a long mail list thread, I am 
> happy to see we finally have an understanding.
>  
> After the 2.46 release, we intend for Blender to have a new event
handling 
> system.  It will make doing things like socket reads or command ports 
> easier and will not require handlers to sleep().
> 
> This is certainly a useful feature, but personally, I'm not sure if 
> further work on this patch as it stands is worth the effort at this
point.

On Sun, 2008-04-13 at 00:12 +0900, Dietrich Bollmann wrote:
> Hi Stephen, 
> 
> On Wed, 2008-03-26 at 07:48 -0400, Stephen Swaney wrote:
> > The comments I made on this patch last August still apply:
> > 
> >   From a quick glance, it looks like there is a lot going on in
> >   this patch:
> > 
> >   - command arg processing refactor
> >   - a debug facility
> >   - the command port
> >   - re-implementation of some standard C functions like isdigit.
> 
> I could only find one reimplemented C function:
> 
>   /**
>      Returns true if `c' is a digit.
>    */
>   int is_digit(char c)
>   {
>       return ('0' <= c) && (c <= '9');
>   }
> 
> and substituted it with `isdigit()'.
> 
> If you find some time, could you please tell me about the other
> reimplemented functions you found in my code?  I would like to replace
> all of them before releasing a new patch...
> 
> And for the rest:  Is it enough if I
> 
>   - change the code to use a similar option parse strategy
>     as is used for the other blender options?
> 
>   - delete my general debug option from the patch 
>     and substitute it with a simplified one 
>     which is only used by the command port?
> 
>   - remove the --geometry NNNxNNN+NNN+NNN option I added?
> 
> As currently everybody is busy with the new release, I probably better
> commit a new version of my command port patch when blender 2.26 is out,
> right?
> 
> Thanks for your help,
> 
> Dietrich
> 
> By the way, to make things easier, the patch is here:
> https://projects.blender.org/tracker/index.php?func=detail&aid=6887&group_id=9&atid=127
> 
> 