Lathe Node (bmesh.spin)

[zeffii]

Probably time to make a lathe Node, similar to Screw modifier or Spin tool. I already have workhorse code written just need to relocate it.

input (optional arguments have defaults and will use last provided if found)

• points
• (optional) edges [default=(0,0,0)]
• (optional) rotation center [default=(0,0,0)]
• (optional) rotation axis [default=(0,0,1)]
• (optional) rotation delta vector [default=(0,0,0)] (used to translate each next segment)
• (optional) rotation angle [default=360]
• (optional) steps [default=20]

Ui switches

• Merge, ticked means remove doubles

output

• new verts
• new edges

No ETA, but probably today

[enzyme69]

Nice.... thing will be whole lot easier! I supposed. But glad I learn a bit by doing LATHE the hard way using Sverchok and Vector and Matrix.

Extrude and Poly Smooth is not yet right? The other day Nikitron make Vertex Group or something.

[zeffii]

polysmooth, makes sense in the future -- but we'd need a way to tag each polygon with custom attributes (like smooth), not possible yet. Viewer Draw could do smoothing i'm sure, I tried with BMeshviewer but couldn't figure out the correct way -- that's an ongoing issue (first item on my todo).

[ly29]

Extrude isn't that far of down the line, really should make thickness in solidify settable on individual basis also. We need some better tools for working with indexes also.

[enzyme69]

Will be patient and check out the Lathe node when its' completed. Cheers.

[ly29]

Using bmesh spin or your own code?

[zeffii]

http://www.blender.org/documentation/blender_python_api_2_70_5/bmesh.ops.html#bmesh.ops.spin I think it makes sense to use that, no?

[ly29]

Many things from bmesh we should make available. We should start a list bmesh ops to make avialable as separate issue.

[zeffii]

cool, yes -- Joel did a great job with bmesh

[zeffii]

https://gist.github.com/zeffii/e44077fcf86cfbf65dba at the moment it's still a SN script, after dinner I will stick it into a node in vector form.

[zeffii]

imo, cent, axis, dvec should display as FloatVector3 XYZ property, until something is connected. I'll figure it out

[zeffii]

but maybe cent + axis+ dvec can be ignored, in favour of matrix? :) (I don't know, haven't tried)

[zeffii]

OK it seems they produce unique results. you can check for yourself here (SN version..) https://www.dropbox.com/s/er41q2qyxv2gzcq/lathe_tests.blend

[zeffii]

Angle should be radians according to the docs, but it's (0 -- 2PI) for 360. I would expect if it was in radians: 0.0 = 0 degrees, 1 is 180 degrees 2 is 360 degrees.

This is as far as i'll get tonight: https://gist.github.com/zeffii/5e1157ee9c30af46c180

(not all internally hooked up yet).

[nortikin]

not bad bedtime. Matrix for what?

[ly29]

I want to be able to have a default vector being settable like in cycles nodes, but I haven't had time to sort out the needed code for that then we get proper sv_get for this

Even though bmesh exposes the matrix input I think we can ignore it, we have matrix apply for that. We could use matrix for center (location) and axis ( mat*Vector((0,0,1)).

Blender uses radians internally and using them properly is the right solution. it is very easy conversion in python anyway. Making them 0-2 and *pi internally doesn't make any sense when you just use radians(angle) anyway. Then you would have to make a separate angle function for that particular case... If you specify angle as subtype for float property it will display degrees but you get radians from the property in python, however then you need to parse the list and convert degrees to radians.

Otherwise it is looking good.

[nortikin]

I don't know how end user will use radians instead of degrees, i like degrees

[zeffii]

@nortikin the node is a 1-1 port of the bmesh.ops.spin, some of these bmesh ops have quite a few input params, matrix is one of the input params. @ly29 mentions that it can be dropped, I think this makes sense after testing in SN.

I'm OK with degrees, arguments could go on indefinitely between user expectation vs math coder expectation. From a math point of view I'd be OK with radians. I think degrees, as Float will be the way. I'm not excited about the idea of making the angle property switchable between degrees / radians.

[ly29]

The right answer here is to expose degrees and to convert to radians somewhere along the way to the bmesh op. And to don't specify angle as subtype.

In general we should expose degrees in the user interface. The problem is that of course that radians have many valid mathematical reasons for existing, so the math and formula nodes use radians which can cause confusion...

[zeffii]

OK, degrees it is then!

[zeffii]

On a side note, maybe a num_rotations variable would make sense for those using the tool to Screw https://gist.github.com/zeffii/17c7a2797645d0c6300f#file-node_lathe-py-L72-L159

I Will make time later to re-factor before committing, much streamlining to do. It's embarrassing to show that code. It brings up a topic which deserves it's own Issue thread or documentation page: The canonical node or Node Manifesto, where we lay out things to consider when implementing vectorized node inputs with our tidiest examples.

[zeffii]

[zeffii]

it's mostly vectorized now, but I want to allow input for cent, axis, dvec, angle and steps as flat lists, else we'll always have to do list splits. https://gist.github.com/zeffii/c0a086d0bb457b9b0af6

[ly29]

I think that is a good idea, at least it is consistent with what we do in many other places...

[nortikin]

good idea about flat lists? btw

remove_doubles = BoolProperty(
        name='merge', description='Remove doubles', update=updateNode)

default forgot...

[ly29]

Yes. For this purpose to use the first list in the list. [[1,2,3,4]] instead of having to make the list [[1],[2],[3],[4]]

[zeffii]

default to BoolProperty is False, so if that's what I was going to use anyway, it doesn't need to be included ( I think you mean why did I drop default?)

[zeffii]

There's a big chance I will kill all that socket reading code and start over, now I know what to do. ( i think )

[nortikin]

yes

[zeffii]

I've chiselled at it, now it's a reasonable size (still maybe a day from committing) https://gist.github.com/zeffii/93e6a8e001678f2fcba3

[zeffii]

this is the kind of file length I had in mind: https://gist.github.com/zeffii/56856e905a7991dd54e7 (not tried yet) -- i'm switching to 100 char line lengths max

[ly29]

Vectices socket doesn't support prop_name yet even if has it. You can assign it but it doesn't do anything.

145 somewhere in the start. I will take look at it again, would be nice if it could look like a cycles node.

[zeffii]

i see, i'll keep those ,prop_name for future compatibility. Yeah, i think allowing vector display on the node in a compact way is quite nice. I was having a conversation with Ton the other day about nodes, he asserts that the future of nodes is not so much UI on the nodes but more draw_buttons_ext where the node noodling is just to diagram how stuff is connected ( or really show the top - top level of important parameters for the node)

[ly29]

That makes sense partially, but also would be nice to see the values directly in the node without having to look in another place for simple things. Some kind of popup zoom and as default they are hidden, but a bit bigger/more clean than today.

[ly29]

I could implement that you get the prop_name value sv_get for vecticessocket...

[zeffii]

is sv_get supposed to be the replacement for SvGetAnySockey + datacorrect ?

[ly29]

Well, about data correct you cannot assume that is should be done. In general I think it is a bad solution to the depth part of #105 ... But I thought it could replace Vector_generate and Matrix_generate, but since we should switch data formats at some point I didn't bother finish it for the cases where it didn't really make a difference.

[zeffii]

https://gist.github.com/zeffii/95277d2d54496765d540

this was a bit of a battle, but i think it generalizes nicely now. Vectorized too. Further refactoring should be easy, but i'll resist.

[zeffii]

undecided about adding spins as parameter, but a little voice inside me says it's better to add it and not use it than need it and not have it. spins would add n * 2PI radians to angle, with n being 0..n. Spins would faciliate easy screw using integers instead of extra math nodes to spit out large Angle values in degrees.

[zeffii]

here it is with Spins parameter. not sure I like it... https://gist.github.com/zeffii/c72769bdfc05d61cedf1

[nortikin]

norm, it usable node to make some topology easy.

[zeffii]

'norm' ? not sure what you mean @nortikin

[nortikin]

@zeffii, i apretiate you ))

[ghost]

How to make the sverchoke nodes such responsive and autoupdated as these GIFs? is it possible ?

[zeffii]

@teeneagle at the moment the way to do that is to have the timeline in play mode, that way Sverchok updates each frame (useful if you are using object in for the Curves/Spline shape).

[ghost]

Nice, this is a smart idea, by the way i appreciate all the work you are doing with sverchock and i wish i could help to make more robust and intuitive, unfortunately i am just a graduated architecture student with some expert with Rhino and Grasshopper and very shallow experience with computer since and python.

[zeffii]

Sverchok is still in early development we appreciate any time you can afford to give. The best thing you can do is to test and speak up when you think something should work one way but doesn't. We will try to either fix (or implement) it or explain alternatives.

If you have drawings you'd like to make into geometry using Sverchok don't hesitate to start a new issue and we can do a case-study. (I'm trying to build up the gallery with nice images)

[ghost]

Actually i did this with grasshopper and i am trying to duplicate with Sverchock : https://www.behance.net/gallery/14936449/Single-Stroke-mimicry

I am very intersted with integrating CAD infrastructure into blender to compete with industrial design softwares like Rhino, i was hoping if blender can compete with every CAD/CAM application but mechanical softwares like solid works and catia seems to have a different approach so i think Freecad is better in this field.

So i am more interested in the Rhino-Approach, command line, more snap options and more Nurbs tools in rhino will help alot but sverchock is a huge step also, i will try to provide a detailed feed back from the end-user point of view soon.

[zeffii]

@teeneagle I enjoyed that Behance link. reminds me of the possibilities of ScriptoGrapher (or what is now Paper.js ) http://paperjs.org/examples/spiral-raster/ . Not super sure how I would approach that in Sverchok..

The snapping is useless in Blender at the moment, altho it has become better in the last year regarding Spline knot/handle snapping. but no real convenient 'copy with basepoint' like we might use in AutoCAD like tools. Blender is not really aimed at precision geometry, more artistic.. as you might guess from the tragic lack of decent CAD style functionality.

[ghost]

Glad you liked it, Paper.js looks cool, and this reminds me i have to learn scripting as it seems much efficient than graphical algorithms editors, once i do it in sverchock i will share the algorithm.

For now this is all wht i got "my first trial with sverchock" not so good for a gallery but may be could be used as an usage example for formulas :

Blendes is indeed too poor as a CAD software, but i still beleive in its potentials as a multi functional software, if i had enough knowledge and resources i would gladly dedicate couple of years to develope a decent CAD infrastructure in blender, even if its community aren't so enthusiastic about it.

[zeffii]

here are the tools I made a few years ago https://github.com/zeffii/Blender_CAD_utils