In the past, i’ve experimented with something quite similar to scripting with nodes. The only difference being that I used a stacking system. I’ve now begun exploring what it would be like to automate common tasks with nodes.
Now, don’t get your hopes up as i’m still just prototyping. Also this won’t be able to perform in EVERY possible scenario, it’s just to cover some common scripting scenarios that an artist is likely to face. Finally, i’m not even sure if this is at all possible as there will be several hurdles along the way.
If you’d like to help, i’m currently in the design phase and i need to be sure that the nodes so far can cover every reasonable scenario. You can help by posting common scripting scenarios you’ve come across.
Here are a few of mine to get started.
assign a diffuse color to all materials in all objects.
if the active object’s z location is less than 0, change its name to “below ground”. Else change its name to “above ground”.
Nodes can be a little bit confusing when you try to figure out in which order events are executed.
The best example of nodes doing this right for me was in Unity Playmaker - where nodes are actually states. They are containers for a stack of actions,that get executed from top to bottom. They also have slots to check if a condition is met and if so to run into the next node (state). Also the game debugger is showing which is the active node and the connection that led to it.
When you expose of all of the actions like that, it is just hard to understand the order of events. At least for me. But it sure beats the current design of BGE. The logic bricks are a pure nightmare to keep track of. Terrible design.
I really like the idea of visual scripting in blender. Not just for the game engine - but also for automating tasks and writing tools.
execution order is a major problem i had to consider. currently, i’m tackling it by assigning an index value for the “action” nodes and the “set property” nodes. those are the nodes that actually carry out the action. those with the lowest indices will be executed before those with larger indices. Another approach i’m considering is using an output node that has a potentially infinite number of sockets (sockets can be added and removed). the actions will then be performed from top to bottom
however, considering the limitations of the node system in blender, debugging is an even bigger problem! i have no idea how i’m going to handle that. or maybe i should just generate the output script into the text editor and leave it up to the user to debug
i’m also looking at c4d’s xpresso and substance designer’s math graph to understand how they tackled some of the problems.
Reason it backwards
You could handle it as a tree problem.
Your final end node is main root. (maybe consider a (end) frame node, that can set several properties.
Use pulldown menus for the get set properties (python can list available properties).
Maybe Give get / set /decision nodes each their own branch color, gets are green, instead of only a small collored conector dot.
Debuging, if you allow the nodes to be named (or use some auto naming, prop1 prop2 prop3, event2:yes; you could simply log them).
As for BGE, currrently you’ve created “if then” logic, the simplest states machines are often just that or select case bricks (end each brick defines a new state for then next looping of all cases). Perhaps read about infinite state machines, they can allready be shown as logic blocks, its not something new (example PLC programming, or sharepoint designer). such machines can be made very complex
but can all be read as if then…
for start frame to end frame // loop
myproperty is color
select case (MYproperty)
– case : is it red
action move it up, and make it green
set new state to green
– case : is it black
action move it left
set new state to red
– case : is it green
action : make it red
set new state to …
to convert it visual; connect case elements vertically (as a list that needs to cycled once)
to debug write each above line that happened to a text file. (but you can pass case elements that didnt trigger).
This is a cool idea. I would love to see something similar to UE4’s blueprint in Blender (I do understand that this is unrealistic though). I’ll be watching this from the sidelines, I’m really curious where it will go.
@blurrymind,
i’m not sure if unity’s style would fit into blender nicely. the blender way of working with nodes is usually from left to right. and there’s usually an output node at the end where everything converges. With unity, things can get a lot more complicated.
Cinema 4D has a scripting system called Xpresso. i think that’s the perfect reference to use. Besides, blender users are already used to seeing node noodle soups with cycles and all. In xpresso, just like in blender, the action moves from left to right so there’s no need for arrows. the user already knows. Also, the nodes will contain lots of tooltips to tell the user exactly what they do.
Blender has a feature that allows users to group nodes together into one. maybe that can help to reduce some clutter.
@Tardis,
python is the only option here. even if i could, i wouldn’t waste my time working on a patch that would most likely never make it into blender. i’ve seen a lot of cool stuff get thrown in the garbage for lots of different reasons.
The technique i used in my previous approach was that the action blocks generated a python script from the user’s input and ran the script automatically behind the scenes. using this approach here means that the nodes won’t have to do any serious work. they’ll just manipulate some code templates.
@razor,
the logging idea is great, but i was thinking i’d expose the auto-generated python script to the user. he can then debug his logic based on the script.
also, i’m not sure i want to change node colors. that’s something that should be decided by the theme. changing them can cause conflicts. but i’ll experiment with it when the time comes. it might be a nice feature when debugging.
How about this: all brushes in the name of which the letter ‘m’ uses Dots as stroke method. al the rest brushes takes one of two random numbers as auto smooth factor.
@Khalibloo
Just to show you how visual apealing a node system can be if both shape and color is taken into account.
It makes it a lot more readable. Now changing shape might be a lot extra work, but color is probaply easy to implement.
It could be just a slight tint, i wouldnt worry about taste people might later adjust theme’s to set those things.
But it would be good for your presentation of logic nodes.
@razor,
that’s a very good example, actually. but you cannot always assume that it will work regardless of the user’s theme.
for example, i have a theme where the text is yellow rather than white. setting the node to be yellow will make the text invisible.
a good compromise that i think would work is to use the theme settings. while creating my current theme, i discovered that different classes of nodes can be assigned different header colors. for example, vector nodes can be blue at the top while input nodes can be red and output nodes green. the problem currently is that these settings only affect the render nodes not my custom nodes.
now, there’s no way to set the color of the node’s header from python, but i’ll keep this in my notebook. maybe when i get the whole system up and running, i can get a blender dev to assist.
Just an update. I’ve got a basic set of nodes. They work as expected, but the code is a real mess. there are several hacks i had to resort to due to my limited knowledge of blender’s nodes. if i go on like this, maintaining the addon might become a very huge task in the future.
i’m currently dissecting other node-based addons. most of them are quite complex compared to mine, so i’m not even sure that the efforts will pay off in the end.
