New offset line node.

[Durman]

My first node)) not sure that I did all right :/
#1914

[zeffii]

stick imports at the top of the file, around the bpy import. See how other nodes do this.

• 1. standard python imports, (math, collections... etc)
• 2. bpy/blender imports, (mathutils...etc)
• 3. sverchok imports (utils..etc)

[zeffii]

option={'ANIMATABLE'} is not needed, properties have this attribute set to animatable by default.

[zeffii]

I would first test if the input vers and edges is linked. Then test if there's also useful output links.

[zeffii]

the goal is to keep the process function abstract, as a "task master".

process is best for

1. get data
2. sanitize data into best form
3. send (sanitized) data to worker functions
4. get product from worker functions
5. fill outputs sockets with product.

The worker functions are cohesive blocks of code that are often specialized enough to stick into their own function.

[Durman]

@zeffii Okay, I understood. I will fix.

[Durman]

@zeffii

i was only thinking that maybe it's possible / efficient to only produce the outer_edge and vert_masks if those sockets are connected.

I think it will not be efficient. I don't use any preparation for these sockets, just assign values for variables in different places of the code. I think that checking boolean values only can to increase time of runtime.

at a later stage we can discuss making it possible to set a unique shift value for every original vertex

I tried to imagine situation when it can be useful. I suppose that in most cases edges_in will be unordered so it will be difficult to prepare data for offset socket and receive interesting result. May with curve in node it could be interesting to have such feature but this node haven't done yet as i know : P. At this moment I prepare offset socket only for different values per object.

TWO_PI = 2 * pi

I am not quite understand benefit of creating the variable. Why not just to use 2 * pi into my function?

[zeffii]

because calc_angle is a function you call many many times, and instead of recalculating 2*pi on each call, you can simply reference the answer (TWO_PI). It's a little bit more efficient. It's also standard graphics programming practice.

[Durman]

I added this node in Alpha. Must it be in beta?

[zeffii]

No, alpha is fine )

[Durman]

It is seems that I fixed all. ))

[enzyme69]

I am an Alpha Rebel. --

…

------------------------------------------------------------ - Jimmy Gunawan http://blendersushi.blogspot.com.au http://mayaspiral.blogspot.com.au http://houdoodles.blogspot.com.au http://puppetar.blogspot.com.au

[Durman]

@zeffii

Why 2 calc_angle functions, keep the outermost that uses TWO_PI

Sorry, don't understand.

[Durman]

@zeffii Yes, didn't notice :/

[zeffii]

i have a question about the verts mask output.

• if you never rearrange the input verts and don't remove any
• then the final verts_mask is a single step

def make_verts_new_mask(verts_in, verts_out):
    num_original_verts = len(verts_in)
    num_verts_out = len(verts_out)
    num_new_verts = num_verts_out - num_original_verts
    f = ([0] * num_original_verts) + ([1] * num_new_verts)
    return f
    

f = make_verts_new_mask(verts_in=[5,2,3,4,5], verts_out=[5,2,3,4,5,5,5,5,2,2,2,3,3,3,4])
print(f)  # [0, 0, 0, 0, 0, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1]

[Durman]

@zeffii

i have a question about the verts mask output.

It's not quite exactly. In my script at first I add new points and after that add old points thus the order is changed.
I have only three strings that is responsible for this.

vers_mask = [0 for _ in verts_out]
...
      vers_mask.append(1)
...
      vers_mask.append(1)

Is there point to change this? I think it must work faster than if writ seperate function for this.

[zeffii]

OK .

It's not quite exactly. In my script at first I add new points and after that add old points thus the order is changed.

this is not a problem. I will merge if you think you're ready to have more people test it :)

[Durman]

Ok. I am ready. ))

[zeffii]

thanks for the cool new node @Durman .

hopefully the process was not too painful. First time is the most difficult (eye - opening).

[zeffii]

i think i can implement variable offset, if you're interested.

[zeffii]

imagine for a moment that we can generate a list of offset radii with the same length as verts_in, (we have a function for this already in utils/core "match_long_repeat") Then rather than shift being static per mesh, it can be variable.

   #Setting points
   findex_new_points = [0]
   for i in range(len(verts_in)):
        if len(neighbours[i]) == 1:
            verts_out.extend(get_end_points(i))
            findex_new_points.append(findex_new_points[-1] + 2)
        else:
            p = get_middle_points(i)
            verts_out.extend(p)
            findex_new_points.append(findex_new_points[-1] + len(p))

and..

   # (not displayed here) we always ensure radii is as long as verts_in
   # meaning we can enumerate radii and use the idx it produces

   findex_new_points = [0]
   for idx, radius in enumerate(radii):
        if len(neighbours[idx]) == 1:
            verts_out.extend(get_end_points(idx, radius))
            findex_new_points.append(findex_new_points[-1] + 2)
        else:
            p = get_middle_points(idx, radius)
            verts_out.extend(p)
            findex_new_points.append(findex_new_points[-1] + len(p))

for speed I would probably make variable offset optional. and modify the offset_edge code to pick which of the proposed loops to use depending on what's needed. Maybe it will make more sense if I just do it.

[Durman]

@zeffii Okay, I agree with it.
I also can do this, and also to do experiments with Z coordinate. Not sure that the node have to have constraints with Z values and to exist only in XY surface. It is easy to add Z coordinate but difficult to calculate normals correctly.

[zeffii]

Z stuff is not important / not interesting use of this node. @enzyme69 often tries to cut grass using a nail clipper. (wrong tool for job)

[enzyme69]

I like cutting tree using nail clipper.