On Sat, Dec 22, 2012 at 12:21 AM, Lukas Tönne wrote:
> IMHO storing the links in a separate list like we do now is one of the
> more well-designed code parts ;)
>
> It may be slightly inconvenient if you want to get a list of links for
> a specific socket, but it has several advantages over storin
I think this should be treated as a design issue and not worry too
much about performance. You'd need some really creepy workflow or bad
scripting to generate more than a few hundred nodes and links max. So
for operators and other functions which are executed once, the only
relevant issue is to avo
Thank you very much Lukas.
Access to NodeSocket.links may be very helpful and if I had this earlier, I'd
probably design my code in:
http://wiki.blender.org/index.php/Extensions:2.6/Py/Scripts/Nodes/Nodes_Efficiency_Tools
a bit differently.
I am especially talking about the operator: NODE_OT_swi
IMHO storing the links in a separate list like we do now is one of the
more well-designed code parts ;)
It may be slightly inconvenient if you want to get a list of links for
a specific socket, but it has several advantages over storing lists of
links in each socket or node:
* If each socket stor
On Fri, Dec 21, 2012 at 4:52 AM, Lukas Tönne wrote:
> # List of connected (Node, NodeSocket) pairs for 'socket':
> input_sockets = [(link.from_node, link.from_socket) for link in
> socket.id_data.links if link.to_socket == socket]
> output_sockets = [(link.to_node, link.to_socket) for link in
> s
I've added the aforementioned utility property in bpy_types.py now:
http://projects.blender.org/scm/viewvc.php?view=rev&root=bf-blender&revision=53243
You can get a list of links (bpy.types.NodeLink) for a socket as
"socket.links". There are many different ways of getting linked
sockets or nodes,
I think it's fine to add those few lines with the link function to
release/scripts/modules/bpy_types.py, there's a bunch of similar
utility functions there.
Brecht.
On Thu, Dec 20, 2012 at 12:50 PM, Lukas Tönne wrote:
> I don't say we should not have these properties, i know they can be
> very u
I don't say we should not have these properties, i know they can be
very useful! I just don't want to have this stored in the DNA data,
because it is always secondarily generated from "actual" links and we
then need to ensure it is kept updated properly. Adding this just as a
API function which the
Thank you Lukas.
In a nutshell it means that it's better not to add those properties to sockets
right?
Without going deeper into it I'd say that it's not a big deal working the old
way or use your suggestions.
I only said that it would be easier if we had such properties, but it seems
that addin
Slightly nicer: define 'links' as a property instead of a method:
class NodeSocket(StructRNA, metaclass=RNAMeta):
__slots__ = ()
@property
def links(self):
"""List of node links from or to this socket"""
return [link for link in self.id_data.links if
link.from_socket =
In the bNodeSocket DNA we currently have a sock->link pointer which
directly points to a bNodeLink. However, this only works for input
links with the current connectivity model (input only has one possible
link, outputs can have many). Future nodes can use a different
connectivity model, then this
Assuming Campbell's OK with it it wouldn't be too terribly hard to add
something like Socket.link to push the iterating over the links into C
since IIRC that's how it works internally.
I personally won't have time to mess with it until after New Years but if
someone else wants to bang their head a
12 matches
Mail list logo
