Oh. Just to be clear, are you making pynodes from scratch? That is implementing it in a branch? How likely is
It that such a wide scope project would get rreviewed and admitted by the foundation?
Totally agree with you. Organization is the key to do not see projects die so often. Join forces please! 
Oh. Just to be clear, are you making pynodes from scratch?
As I mentioned before, this is a simple python AddOn leveraging the existing node API as of 2.69. So no inclusion in trunk is necessary and it should run on any build of Blender after 2.69, no need to branch. I don’t think I could present this to anyone yet because I am still not sure what I am making.
After completing the List node I started to realize that maybe everything should be a list? I ended up putting special code in everywhere to detect if the output node was a list or not. It just makes sense to me now, that all property types should reside inside a Collection Enum property. A simple integer is really a single enum collection with one Int value. Then I can access output values in a unified way. So back to the drawing board. I am trying to update all the previous working nodes with this new concept and see how it holds up.
This is like the third re-write of all the basic nodes so far. But I keep condensing and optimizing code on each pass. I really want these basic value types to be rock solid to build on.
I have my first node, Bool, converted over to run as a value inside a collection. This seems to be working ok so I am moving on to convert others to use this new format.
I have also added a new visual feature to the nodes. When any node issues an update, it’s background color briefly turns RED then fades back to the normal node color. This allows you to quickly see the impact any node update has on the entire node system.
Oh ok, I didn’t understand that Py nodes were now implemented in Blender (thought that they were still under development). For other noobs like me, a new node tree can be created by a python script ‘in addition to’ the old node windows. This newly created pynode tree can generate results in a variety of areas.
Hey Atom, can you save node groups that you create here and share them outside the .blend file? Or will they be lost if the tree is killed off for some reason?
BTW is there any way to access OpenGL drawing directly with python? Could we access the fast OpenGL 3D window renders to use as an output type, then port that from your nodes to other areas of Blender?
This looks really promising 
keep at it sir!
@3pointEdit: I have not tested node groups, but, in theory, it should work. The node group would fail to initialize unless you have the AddOn installed and enabled on the new system (as far as trading Blends).
BTW is there any way to access OpenGL drawing directly with python?
Funny you should mention that. I was running into some problems just using the background color of the node for status (as shown above in RED). It seems that when you change the background color of a node a node.update() event is issued. Thus recursion depth overflows kept occurring. But I was able to get OpenGL drawing to work inside the node rectangle area (via import blf). So it is possible to use OpenGL to draw status colors on top of the node. This is my new approach for status and feed back for node operations.
Hmm I see. Yes the addon for the vse called Transform Tool also draws its own opengl in the preview window. I just wondered if you can capture internally, and use the opengl images that can be rendered from 3d view?
Also the lack of better bit depth in alpha on the OpenGL. But thanks for the reply. Great work, keep it up.
Sure there is, just playblast from the camera view and it’ll use the render dimensions.
Thank you Greg, I never made that connection. I just tried it and it works fine.
I agree that we must make compatible things. For this we have to define sockets type.
Or make convertion between them…
The main issue - is to deal with lists on sockets, for now we have temporery solution of stringProperty, but we need bpy.props.ListProperty as well.
Atom, what do you think and how can I see your solution of list translation?
Should we work in one nodes tree? And if this, what agreement on sockets will be the best?
Why Lukas left his nodes development and for how long?
For now we can try to make it compatible or make translators-nodes.
@Atom
@nikitron: I am still working on lists at this time. I have solved several event/recursion issues that was troubling my system. Now I have a nice way to refresh the node tree and visually give users feedback when a branch is updating. I had to abandon the previously mentioned approach of placing all property types into a Collection. While this did work, the end result was that properties inside a list can not be animated (they have no storage for f-curve). I want as many node properties as possible to be animatable so I reverted back to detecting list type upon update.
Why Lukas left his nodes development and for how long?
I have submitted a couple of issues I thought were bugs and Lukas has replied and explained why they are not. So I think he is still on board with nodes.
Should we work in one nodes tree? And if this, what agreement on sockets will be the best?
I still want to try an integrate some of the existing official Blender nodes into my tree. I think using the string type class detection can make it possible to inherit values from other external nodes. My nodes differ from your Sverchok nodes as explained in post #1. Only the output socket contains the value. Inputs are for routing only.
I detect list type from a connected socket this way…
DEFAULT_FLOAT3 = [0.0,0.0,0.0]
CLASS_COLLECTION = "<class 'bpy_prop_collection_idprop'>"
def returnFromInputAsFloat3(passedNode, passedName):
try:
from_sock = passedNode.inputs[passedName].links[0].from_socket
if str(type(from_sock.value)) == CLASS_COLLECTION:
# Grab the item from the list using the companion index.
X = from_sock.value[from_sock.index].X
Y = from_sock.value[from_sock.index].Y
Z = from_sock.value[from_sock.index].Z
result = "[%f,%f,%f]" % (X,Y,Z)
else:
# All value types should be CLASS_COLLECTION
result = packageAsPropertyFailure(DEFAULT_FLOAT3)
except:
result = packageAsLinkFailure(DEFAULT_FLOAT3)
return result
So a list socket value is a Collection property of type list item. I also assign a companion Index integer with the value to support a single selection or active item in the list.
value = bpy.props.CollectionProperty(type=bgListItem, name = "List") #, description="A list of items.", update=updateListParameter)
index = bpy.props.IntProperty(name="Index", description="An index that points to the currently selected value in the collection.", default=0, min=0, update=updateListParameter)
Here are a few list items I plan on supporting. The bgListItem is kind of generic and is basically all types in one item. Less memory efficient, but more flexible.
class bgListItem(bpy.types.PropertyGroup):
value = bpy.props.StringProperty(name="Item", description="A string of ASCII characters.", default="void") #, update=updateProperty)
float_value = bpy.props.FloatProperty(name="Float", description="A positive or negative real number.", default=0.0) #, update=updateProperty)
integer_value = bpy.props.IntProperty(name="Integer", description="A positive or negative number without a manitissa.", default=0) #, update=updateProperty)
boolean_value = bpy.props.BoolProperty(name="Boolean", description="A True or False value.", default=False) #, update=updateProperty)
Other list types are one-offs or special cases.
class bgBoolItem(bpy.types.PropertyGroup):
value = bpy.props.BoolProperty(name="Boolean", description="A True or False value.", default=False) #, update=updateProperty)
class bgIntItem(bpy.types.PropertyGroup):
value = bpy.props.IntProperty(name="Integer", description="A positive or negative number without a manitissa.", default=0) #, update=updateProperty)
class bgFloatItem(bpy.types.PropertyGroup):
value = bpy.props.FloatProperty(name="Float", description="A positive or negative real number.", default=0.0) #, update=updateProperty)
class bgFloat3Item(bpy.types.PropertyGroup):
def as_array (self):
return [self.X,self.Y,self.Z]
X = bpy.props.FloatProperty(name="X", description="X", default=0.0)
Y = bpy.props.FloatProperty(name="Y", description="Y", default=0.0)
Z = bpy.props.FloatProperty(name="Z", description="Z", default=0.0)
class bgFloat4Item(bpy.types.PropertyGroup):
def as_array (self):
return [self.W,self.X,self.Y,self.Z]
X = bpy.props.FloatProperty(name="X", description="X", default=0.0)
Y = bpy.props.FloatProperty(name="Y", description="Y", default=0.0)
Z = bpy.props.FloatProperty(name="Z", description="Z", default=0.0)
W = bpy.props.FloatProperty(name="W", description="W", default=0.0)
class bgColor4Item(bpy.types.PropertyGroup):
def as_array (self):
return [self.R,self.G,self.B,self.A]
R = bpy.props.FloatProperty(name="R", description="R", default=1.0)
G = bpy.props.FloatProperty(name="G", description="G", default=1.0)
B = bpy.props.FloatProperty(name="B", description="B", default=1.0)
A = bpy.props.FloatProperty(name="A", description="A", default=1.0)
I am getting close to a “proof of concept” code release then you can check out the code.
What a team up I can see in here! hehehe, Can’t wait to see what kind of thing comes out from this! Go guys! 
I have been working on Float3 type support nodes. The Float3 type will be a flexible container for any 3 value series of floats. Such as (X,Y,Z), (U,V,W), (R,G,B) and vertex or curve point coordinates. Internally the Float3 type is a collection item made up of X,Y,Z values. There is a companion as_array() def to fetch all three values at once if you need to. While Float3 collection values themselves are not directly animatible you can drive or create a Float3 by connecting three standard Float values to a Component To Float3 node. It is also possible to fetch/extract either the X,Y or Z component from a Float3 for individual value processing using the Float3 To Component node. While I talk about them as X,Y,Z they could just as easily be R,G,B. So Hue/Saturation manipulation should be possible. Precision is maintained throughout the pipeline and only clipped when displayed.
Attachments
Hi All,
I have implemented a simple random number generator. It accepts low and high input values and returns a float. It also accepts an external random seed so multiple copies can produce different output values. You can also drive the seed from the current frame to generate a new random number for each frame. The node supports three different random number generator types as described in the python docs for the random module.
And here is a possible node tree that randomly picks a phrase from the list every 10 frames and routes that phrase to the body/copy of an existing Font datablock with the phrase surrounded by double quotes.
Impressive! The more node-based systems we have at our disposal in blender - the better. Hope that this tool will grow.
Awesome, can’t wait to have a full nodal system in Blender.
A simple but required node. This node allows you to select what scene will filter other list selection based nodes by providing the name of the selected scene as a string output.
Attachments
Hi All,
I have started work on the Object Node. This one I feel will need to be fairly robust. The node tree image below shows how to filter what appears in the object list via the Scene Input socket. When no scene is specified all object from all scenes will appear in the list. You can connect a Scene node directly to the input and use the scene selector to filter what objects appear in the list. Because the Scene Input socket is a string you can connect any string node or other node with string output to it. This results in two possible outputs. The scene specified at the input is valid or invalid. When the input is invalid the node turns RED as a visual reminder that something is wrong and the objects that appear in the list come from the current context.
