[Bf-committers] Looking into HFSM and blender

[Ton Roosendaal]

Hi,

I guess you've read the notes about Nodes in the logs?
http://www.blender.org/cms/Blender_2_42.727.0.html

> I was looking into implementing HFSM functionality in blender for my  
> master's project similar to Softimage Behavior  
> (http://www.softimage.com/products/xsi/pricing_and_packaging/advanced/ 
> behavior/) since I have played quite a lot with it at a former game  
> cie. I am glad that you started work for a Node editor, since I can  
> reuse a lot of the node editor for my HFSM editing.

I've only quickly checked on this XSI feature, but it seems to be  
script based, allowing the scripts to be visualized as hierarchical  
nodes.

> I just wanted to know if someone else had already mentioned in  
> performing a similar functionality for blender?

There have been Python scripts coded for it. I've added the  
Group-duplicator with NLA option just for this reason too btw. Groups  
allow instances quite nicely.

> 1.I need nodes to support dynamic inlet and outlet connections, but I  
> saw that node types are staticly declared? How would you go about  
> creating dynamic outlets? A good example would be the javascript patch  
> in Quartz Composer, whre we could have an equivalent Python node in  
> Blender with a dynamic number of inlet depending on the written  
> script?

Experiments with Python nodes have been done already, including dynamic  
generated ones.

The static definition is for being able to save setups, and keeping  
upward/downward compatibility. It's not really static in the sense it  
cannot change, but static in sense that you have to be able to  
reconstruct saved data into something that works. Or change  
functionality in next releases without losing older saved file  
functionality.

BTW; Probably Quartz Composer is script based too... which is a  
different approach.

> 2.I need sub-nodes. I like the group concept, but I would have liked  
> for all nodes to permit to have sub-nodes and hierarchical outlet  
> forwarding. I played quite a bit with Quartz Composer and I was  
> wondering why you didn't treat all nodes as groups?

I've only really looked at compositing and shader trees, which is quite  
static compared to game logic or behaviour trees. That latter I don't  
know requirements of really, we don't have design specs for it.

The Node Group was meant to be the library-linkable part for node  
trees. So you can share data among files or create custom libraries. In  
theory groups can contain groups and so on, but that was a feature I  
rather not think of in a first release, the complexity of that code  
will be a nightmare (with node tree definitions recursively propagating  
around...)

What I saw of XSI's behaviour editor is really not something I'd do  
with the current Node editor from scratch... you probably could first  
design it entirely script based, as a new Python module. And then use a  
Python-Node tree editor to have a more visual editing of the linked  
scripts.
That latter idea is what I've discussed with Nathan Letwory, who worked  
on Py-node. Not sure where this code is now btw!

With this approach, it probably will be not a showstoper that sub-nodes  
only go 1 level deep then. If you want more complex behaviour nodes, a  
script can be adjusted as well.

Hope the info helps,

-Ton-


>
> Sorry if these questions are already implemented or answered, but I  
> could not find much advanced info on what you are planning to do with  
> the Node editor.
>
> Anyways keep up the great job!!!
>
> Thank you,
>
> Paul Gavazzi
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at projects.blender.org
> http://projects.blender.org/mailman/listinfo/bf-committers
>
>
>
------------------------------------------------------------------------ 
--
Ton Roosendaal  Blender Foundation ton at blender.org  
http://www.blender.org