[Bf-committers] Meeting minutes - nodal logic proposal

jonathan d p ferguson jdpf.plus at gmail.com
Sun Nov 8 20:25:03 CET 2009


hi.

Benoit:

Great proposal. I have a few other pointers (to follow Erwin's  
example). And a concern.


Additional References:

Thanks for suggesting Kismet and Scratch, Erwin. The UDK http://www.udk.com/ 
  will make it easy to compare implementations. I have a few comments  
from experience with Kismet:

* UnrealEd’s Kismet visual scripting syntax. Now available for free  
(free as in beer) in the UDK. Please note that many other modern game  
engines also feature some kind of visual scripting language. Kismet  
can be a great way to lower the barrier to entry, however, the key  
limitation is that Kismet does not provide out of the box support for  
all parts of the Unreal API (hardly surprising). One may write their  
own node definitions using UnrealScript, but the majority of game  
logic changes can be handled with Kismet.

Finally, the key problem I've had with Kismet is that it is only  
useful up to a certain threshold of complexity, after which point, it  
becomes extremely expensive to implement with nodes. In addition, I  
point out that Kismet is not the only node-based UI in the UDK.  
Materials, and Animation Blending also use the node-based UI in the  
UDK. FYI: Animations in UnrealEd are done using Matinee which does not  
use a node-editor.

* Apple’s Quartz Composer http://developer.apple.com/graphicsimaging/quartz/quartzcomposer.html 
  I know that the ML has raised this example in the past, but it bears  
repeating. Of particular interest is the fact that Apple’s Quartz  
Composer shows the values of variables in real-time, which is a great  
boon to increasing the transparency of such network-based-node- 
systems. Further, consider that node-nesting is handled in Composer  
through a column (using the standard Mac OS X column navigation widget).

* Apple’s Shake for post-production. http://www.apple.com/shake/.  
Shake is well known for post-processing using node networks. I do not  
have experience with it. Are others able to chime in here?

* Cycling ’74’s Max/MSP/Jitter http://www.cycling74.com/products/maxoverview 
. Max is built with a notion of animation (time based) and so it may  
prove very useful in that respect as well. There are very few products  
like Max. I do not have much experience with this system either, but I  
know some who do, and who love it.


A concern or two to think about:

You might already know about the following concerns, but I'm sharing  
anyway.

In my experience thus far, I've noticed a few key problems with node- 
based UI's, and GUI programming "languages" in general. One is the  
painful fact that the "node networks" in such systems are frequently  
not transferrable. :-( A given node network may or may not be easily  
integrated into existing node networks. Variables and values are  
sometimes hidden from the user (in sometimes difficult to ascertain  
ways). Few debuggers exist, etc. To this end, and somewhat ironically,  
it is often difficult to identify the flow-control of a program. (A  
realtime representation for such flow would be utterly awesome).  
Finally, given the usual binary representation, such systems are also  
very hard to "merge" using version control (though I expect Blender's  
concept of linking data libraries to help greatly here).

In any case, insofar as it does not present an insurmountable hurdle,  
I encourage a requirement that such a generalized node-network for  
Blender offer as much flexibility for "network reuse" as possible. Put  
another way, it is a good thing to allow users the opportunity to  
transfer logic networks between projects, and allow for automated  
merging. I don't know how possible this is, technically speaking, I  
merely suggest it as food for thought.

My motivation for this comment is that, it is not uncommon, for  
example, to have to entirely rebuild a Kismet sequence (or UT3 or BGE  
"level") due to some totally undiscoverable bug. Such an end-user  
consequence is not entirely surprising given the level of opacity that  
a node-based GUI introduces... I don't know if this issue is  
surmountable--- other than supposing that node description source code  
(expressed as Python, presumably) be made available to users in some  
way...

In any case, great start! I look forward to a nodes based system for  
Blender (in general) and for the BGE specifically.

Thanks!

have a day.yad
jdpf


On Nov 7, 2009, at 12:18 AM, Erwin Coumans wrote:

>
> I highly recommend checking out Kismet visual logic editor from the
> now free Unreal Editor.
>
> Also Scratch, from http://scratch.mit.edu
>
> Erwin



More information about the Bf-committers mailing list