-
Notifications
You must be signed in to change notification settings - Fork 2
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Ideas about nodes #3
Comments
vectorization on some level. main levels of vectorizations - objects and their values. we ned convention |
as a model for generating mesh data I still really like SN1's simplicity, but it's |
@ly29 |
@nortikin |
We could even have multiple forms for writing nodes as long as they can describe themselves properly. But a standard form is better. |
Some nodes (minority) would be really short to describe because they are essentially Effects. Take Remove Doubles or Intersect Edges, nodes like that could be described in an eval/exec form like from svrx_base_modules import intersect_verts_edges
inputs("verts") # this named input is special and will always generate a V input
inputs("edges") # now StringProperty, probably we should call it NestedPropery, or IndicesProperty
a, b = intersect_verts_edges("verts", "edges")
outputs("verts", a)
outputs("edges", b) Remove doubles: from svrx_base_modules import remove_doubles
inputs("verts")
inputs("edges")
inputs("faces")
distance = ui_slider("distance", dict(default=0.0001, min=0.0))
a, b, c = remove_doubles("verts", "edges", distance)
outputs("verts", a)
outputs("edges", b)
outputs("faces", c) or from svrx_base_modules import remove_doubles
v = inputs("verts")
e = inputs("edges")
f = inputs("faces")
distance = ui_slider("distance", dict(default=0.0001, min=0.0))
a, b, c = remove_doubles([v, e, f], [distance])
outputs("verts", a)
outputs("edges", b)
outputs("faces", c) or even more common from svrx_base_modules import remove_doubles
v, e, f = inputs("verts", "edges", "faces")
distance = ui_slider("distance", dict(default=0.0001, min=0.0))
a, b, c = remove_doubles([v, e, f], [distance])
outputs("verts", a)
outputs("edges", b)
outputs("faces", c) or taking that abstraction further by using Mesh to mean verts, edges, faces from svrx_base_modules import remove_doubles
# 'mesh' would auto inflate to `verts, edges, faces` sockets
v, e, f = inputs("mesh")
distance = ui_slider("distance", dict(default=0.0001, min=0.0))
a, b, c = remove_doubles([v, e, f], [distance])
outputs("mesh", [a, b, c]) here Then i start to think adding the UI can be a separate file...or section in the same file from svrx_base_modules import remove_doubles
v, e, f = inputs("mesh")
svrx_prop1 = StringProperty(name='prop1')
svrx_prop2 = IntProperty(name='prop2')
params = [svrx_prop1, svrx_prop2]
def draw(self, context):
... # optional, will draw props in order of appearance in params list.
a, b, c = remove_doubles([v, e, f], params)
outputs("mesh", [a, b, c]) |
a good time to rethink the naming convention of our socket types. |
the whole getting data from socket paradigm has to go I think, the node execution unit should be called with the relevant data, for its execution type. The socket is an indication of data type, not a guarantee unless we enforce type safety on top of python which to me, doesn't seem worth it. I general I would like to store the blender properties in the socket, not in the node, but this has some limitations so am not sure about it. The problem of course being the we would have to generate a new socket type for each case of say limits in the float property. I wish properties could be individually adjusted with default/min/max etc |
right i get ya! |
Socket Types
|
For now I think pynodes are workable but writing our own nodes thing would be a nice challenge. |
can we not combine Matrix/Euler/Quaternion as |
I think Curve data would be great too, 10 socket types isn't too bad.. I think @nortikin had objections to raising the socket count? |
Ideally this should be two parts, one being the blender properties ui location, dimension, the other being the properties of the node as relevant to sverchok execution. @zeffii |
yeah, this fuzzy logic has many positive uses, and it mirrors the behaviour of the shader node trees |
exactly |
I also think we should copy the socket naming convention from the rest of blender i.e. |
about names - propose tolimit names lenght to 5-6 maximum 8 Have to admit we need basic sockets to be defined, not to use verts+pols in one node and bmesh or obj in other. it should be some kind of basic data-paradigm. If we use bmesh as second basic in hierarhy than obj have to have switch or something like converter we have to have in any case. more types more probllems. Sorry for many characters |
the problem of matrix generator and matrix deform node is not obviouse for user - second float socket for rotation can eat vertex (or vector wich is second problem how to name). |
now we have to collect all issues to mind-map, because it helps a lot, at least for me. |
On UI I prefer proper names or sensible shortnames. I think 'vers' is not the best. 'verts' is one letter extra and actually means something in English. Similarly with |
you know English better anyway, let it bee. |
|
but agreed that simply one letter like grasshopper is a bit too economical :) |
it would be awesome if socket nipples had a hover state which could trigger a tooltip for that socket, I haven't seen that anywhere, in blender , but would be handy. |
https://gist.github.com/nortikin/eace3b46e85c585b06a0 this has to be in one node (not formula shape node, but make surface from two vertices sequences) |
@zeffii even not imagin how. OpenGL popups? |
i'm not fussy about going over 8 characters, if it's acceptable for standard Blender nodes, as @ly29 mentions 'Displacement' is 12 and i've never considered that too long. After a while of using new nodes your brain doesn't really read them any more, it works more on position (if the node isn't dynamically naming sockets ) |
about fuzzy sockets, I think
rather than
|
Such conversion rules should be supported. |
yeah, this is such a pain, but perhaps it is possible to simply assign a dynamically added Property to a node along the lines of some_prop = IntProperty(min=0, max=20, step=2)
#later
stored_value = copy.copy(self.some_prop)
del self.some_prop
self.some_prop = IntProperty(min=0, max=40, step=4)
self.some_prop = stored_value
|
@zeffii again, rna, not id, maybe node can have id property on fly? oh, no it cannot, for sure |
@ly29 material socket with texture assigned to it? we can make unwrap with python, maybe someone wish to assign material and unwrap exact polygon of bmesh (when we decompose bmesh to vertices polygons we lost unwrap layout data and others how to solve?) |
I was under the impression that if you have a list of edges from |
@nortikin |
might but appears several ways to deal to sverchok - first is usual low level, second is bmesh, third objects and scene. Or maybe whan we edit in low level than bmesh not deleted during layout but updated its data - changed vertices - making ensure lookup table and output it? so every bmesh decomposition must meet node called |
or we deal with data as container with |
after adding any verts + edges + face manually to a bm we must call |
Some of the problems you see I don't see. However it is not the stage I am at the moment. |
guys, we also need vector socket that will have: |
but dx, dy, dz can be inferred at calculation time, it can be a simple separate additional structure for np_Mesh to produce when asked. Storing that information explicitely and allways is not necessary. If we have a node that uses deltas then it can call a function and store all the result to the or make it possible to push an array of deltas at any time onto np_Mesh, same with 'weight' (capacity) w. Separate stream included in np_Mesh. |
who knows what else will be needed - vertex colors can be coded just like thhat, so additional dictionaries needed extremely, maybe globally it will cover curve type of data -with addtional handles to knots, so you will have additionally two lists with identical looku table for level 2,3,4... so level 1 wil only lookup as 3 or 1 or 2 numbers depends on what we need. for one object one lookup table wich will decrease memory usage. cool. |
Function annotations seems perfect for type info... def f(a : int = 2, b: float = 3.0) -> (float, float):
return b, b*a >>> import inspect
>>> f.__annotations__
{'b': <class 'float'>, 'a': <class 'int'>, 'return': (<class 'float'>, <class 'float'>)}
>>> sig = inspect.signature(f)
>>> str(sig)
"(a:int=2, b:float=3.0) -> (<class 'float'>, <class 'float'>)" |
Furthermore in 3.5, will have to review a bit soonish. |
import numpy as np
def linspace(start : float = 0.0, stop : float = 1.0, count : int = 10) -> ("linspace", np.array):
return np.linspace(start, stop, num) Something like this could be a complete node for simple cases, like node scripts. Annotations are amazing (not really but a very nice feature). UI could be generated from this. @zeffii |
yeah, I would like to commit to doing a massive overhaul of mk1. Looking back at it it seems massively bloated. I'd like to think that I could do better, after a year and half :) But unfortunately my mother has been seriously ill for a few months and will be operated on tomorrow for the n-th time ... the outcome of which will greatly influence how much time I can commit to this.. and how clear i'll be able to think. |
I am sorry to hear about your mother. Take care. I have been busy lately but I want to boot strap this now, the ideas have been brewing in my head. I like the fact the fact that with this we could basically have an OSL like simplicity. |
Thanks @ly29 . Difficult times, but I do like the distractions and it's why i've been coding in the open a bit more again. I'm interested to see a less complicated back-end for SN MK1, and wouldn't feel obliged to retain any form of backwards compatibility, scripts should be easy to convert as and when they are needed. Afterall the interface is what would change, the work-code mostly remains unchanged. Having some typed interface, is kind of what sn mk1 already has, but making it explicit is something i'm all for. (Even if we have to allow custom data types... float vs list..vs np array etc :) |
Progressing slowly. import numpy as np
def linspace(start : float = 0.0, stop : float = 1.0, count : int = 10) -> [("linspace", np.array)]:
return np.linspace(start, stop, num)
linspace.label = "Linear space" From this I produce a node. But no connection the other way, the code doesn't do anything more than inspect the node and producing a ui element automatically from the above. |
using a class factory? :) |
Yeah. Ugly thing. def node_factory_from_func(func):
annotations = func.__annotations__
if not annotations:
return None
class_name = "SvRxNode{}".format(func.__name__)
bases = (SvRxNode, bpy.types.Node)
sig = inspect.signature(func)
inputs_template = []
for name, parameter in sig.parameters.items():
s = Socket(annotations[name], name, default_value = parameter.default)
inputs_template.append(s)
ret_values = annotations["return"]
outputs_template = [Socket(socket_type, name) for name, socket_type in ret_values]
node_dict = {}
node_dict["bl_idname"] = class_name
node_dict["bl_label"] = getattr(func, "label", func.__name__)
node_dict["bl_icon"] = 'OUTLINER_OB_EMPTY'
node_dict["inputs_template"] = inputs_template
node_dict["outputs_template"] = outputs_template
node_class = type(class_name, bases, node_dict)
return node_class |
Yeah, it was you that introduced me to |
i'm nodding my head with a big YES :) |
ordered dict would be nice, but maybe not as pythonic. |
@zeffii take care of mother's health, hope its to be all right after all. |
Of course there is big problem with the annotations above, Sensible things like Below is a schedule of numpy types matched to python types.
Type conversion code from stack overflow http://stackoverflow.com/questions/9452775/converting-numpy-dtypes-to-native-python-types def get_type_convert(np_type):
convert_type = type(np.zeros(1,np_type).tolist()[0])
return (np_type, convert_type) |
This isn't a finished model.
How should this be accomplished?
Let us at looks some different models to create nodes.
SN1
SN2
Basically there are more or less identical, as I see the most easily inspectable one with types etc is more complex SN2.
What I propose is a python class that provides a functional unit that can be executed on individual pieces of the mesh.
The text was updated successfully, but these errors were encountered: