available variables: **r**, **g**, **b**, **a** for access to initial colors from first input socket. If second input color socket is connected, **R**, **G**, **B**, **A**
variables can be used to access its values.
And **i** for access to index of current color to be evaluated. It is also possible
to get index of current object list of colors evaluated as **I** variable.
So **i** for index of color, and **I** for index of list of colors.
Internally imported everything from Python **math** module.
Blender Py API also accessible (like **bpy.context.scene.frame_current**)
Inputs
------
- **Colors(rgba)**
- **Colors(RGBA)**
Outputs
-------
**Colors**.
resulted colors to red, green, blue and alpha elements of which was applied expression.
Cylinder generator, as well as circle, is used to create a big variety of polyhedra based on the cyliner form: two polygons connected by a body. In the examples will see some possibilities.
Inputs
------
All inputs are vectorized and they will accept single or multiple values.
There is three inputs:
- **Radius Top**
- **Radius Bottom**
- **Vertices**
- **Height**
- **Subdivisions**
Parameters
----------
All parameters except **Separate** and **Caps** can be given by the node or an external input.
*This node testing is in progress, so it can be found under Beta menu*
Functionality
-------------
This node applies Extrude operator to edges of input mesh. After that, matrix transformation can be applied to new vertices.
It is possible to provide specific transformation matrix for each of extruded vertices.
Inputs
------
This node has the following inputs:
- **Vertices**
- **Edges**
- **Polygons**
- **ExtrudeEdges**. Edges of input mesh that are to be extruded. If this input is empty or not connected, then by default all edges will be processed.
- **Matrices**. Transformation matrices to be applied to extruded vertices. This input can contain separate matrix for each vertex. In simplest case, it can contain one matrix to be applied to all vertices.
Outputs
-------
This node has the following outputs:
- **Vertices**
- **Edges**
- **Polygons**. All faces of resulting mesh.
- **NewVertices**. Newly created vertices only.
- **NewEdges**. Newly created edges only.
- **NewFaces**. Newly created faces only.
Examples of usage
-----------------
Extrude only boundary edges of plane grid, along Z axis:
Float digit. Has maximum/minimum values and flexible labeling. Cached in Sverchok 3Dtoolbox.
Inputs & Parameters
-------------------
**float**
Extended parameters
-------------------
**to-3d** - boolean flag makes float catched in 3D toolbox
**minimum** - defines minimum value
**maximum** - defines maximum value
Outputs
-------
**float** - only one digit.
Examples
--------
Three cases of float. With output, as router and as input (not functional). Only first case will be catched in 'scan for propertyes' in 3Dtoolbox of sverchok.
This is 3D toolbox scanned float. Max and min values appears in 3d and node toolboxes (last in extended interface in propertyes panel). Label of node will apear in 3Dtoolbox and sorted depend on it. Flag 'to_3d' makes node catchable in 3D.
To move GText strokes around in NodeView you must move the GText Node then press Set again. This may not be entirely intuitive but it hasn't bugged us enough to do anything about it.
Integer digit. Has maximum/minimum values and flexible labeling. Cached in Sverchok 3Dtoolbox.
Inputs & Parameters
-------------------
**int**
Extended parameters
-------------------
**to-3d** - boolean flag makes integer catched in 3D toolbox
**minimum** - defines minimum value
**maximum** - defines maximum value
Outputs
-------
**int** - only one digit.
Examples
--------
Three cases of integer. With output, as router and as input (not functional). Only first case will be catched in 'scan for propertyes' in 3Dtoolbox of sverchok.
This is 3D toolbox scanned integer. Max and min values appears in 3d and node toolboxes (last in extended interface in propertyes panel). Label of node will apear in 3Dtoolbox and sorted depend on it. Flag 'to_3d' makes node catchable in 3D.
**EvPoint** will need Vertices A and B to be generated. The output will be a new group of vertices between groups A and B, based on the factor setting. See example below.
Analizing geometry and finding centers of polygons, normals (from global zero), normals from local centers of polygons and matrices that find polygons rotation. Not works with edges.
Inputs
------
**Vertices** and **Polygons** from object that we analizing.
Outputs
-------
**Normals** is normals from global zero coordinates, vector. **Norm_abs** is normals shifted to centers of polygons. **Origins** centers of polygons. **Centers** matrices that has rotation and location of polygons.
The code of matrix rotation based on Euler rotation, so when you rotate to plane X-oriented, it makes wrong. We need spherical coordinates and quaternion rotation here, needed help or something
If you have experience with SVG paths most of this will be familiar. The biggest difference is that only the
LineTo command accepts many points, and we always start the profile with a M <pos>,<pos>.
::
M 0,0
L a,a b,0 c,0 d,d e,-e
CurveTo and ArcTo only take enough parameters to complete one Curve or Arc,
unlike real SVG commands which take a whole sequence of chained CurveTo or ArcTo commands. The decision to keep
it at one segment type per line is mainly to preserve readability.
The CurveTo and ArcTo segment types allow you to specify how many vertices are used to generate the segment. SVG
doesn't let you specify such things, but it makes sense to allow it for the creation of geometry.
the fun bit about this is that all these variables / components can be dynamic
::
M 0,0
L 0,3 2,3 2,4
C 2,5 2,5 3,5 10 0
L 5,5
C 7,5 7,5 7,3 10 0
L 7,2 5,0
X
or
::
M a,a
L a,b c,b -c,d
C c,e c,e b,e g 0
L e,e
C f,e f,e f,-b g 0
L f,c e,a
X
More Info
---------
The node started out as a thought experiment and turned into something quite useful, you can see how it evolved in the `github thread <https://github.com/nortikin/sverchok/issues/350>`_
In my opinion new users should avoid the Script Nodes until they understand a majority of the existing nodes and the Sverchok `Eco-system` as a concept. This suggestion applies to everyone, even competent coders.
Script Nodes are great when you want to encapsulate a behaviour which may not be easy to achieve with existing nodes alone. They are my prefered way to either 1) prototype code, or 2) write custom nodes that are too specific to be submitted as regular nodes.
At the moment Sverchok has 2 Scripted Node implementations: SN and SN2. Exactly how they differ from eachother will be shown later. Both offer `practical shorthand` ways to define what a node does, which sliders and sane defaults it might have, and what socket types can connect to it. These scripts have a minimal interface, are stored inside the `.blend` file as plain text python, and can be shared easily.
If you've ever written code for a Blender addon or script, you will be familiar with registration of classes. Nodes normally also need to be registered so Blender can find them, but Script Nodes don't because they are in essence a shell for your code -- and the shell is already registered, all you have to do is write code to process input into output.
Scripted Node 1 -- an informal introduction
-------------------------------------------
Here is a classic 'Hello World' style example used to demonstrate graphics coding. It's called a Lorenz Attractor. ::
Compare the code with the image of the node and you might get a fair idea where the sockets are defined and where the default comes from. Look carefully at
``in_sockets`` and ``out_sockets``, two of the elements are strings (socket type and socket name), and the third element is the Python variable that we automatically bind to those sockets.
Brief Guided Explanation
-------------------------
You've probably got a fair idea already from the example script. SN1 has a few conventions which let you quickly define sockets and defaults. What follows are short remarks about the elements that make up these scripts, aimed at someone who is about to write their first script for SN1.
Sockets
-------
Sverchok at present has 3 main socket types: SvVerticesSocket, SvStringsSocket and SvMatrixSocket. Script Nodes refer to these socket types with only their first letter in lowercase. 's','v','m'::
's' to hold: floats, ints, edges, faces, strings
'v' to hold: vertices, vectors, 3-tuples
'm' to hold: matrices, 4 x 4 nested lists
Socket Names
------------
Each socket has a name. Take a minute to think about a good descriptive name for each. Socket names can always be changed later, but my advice is to use clear names from the very beginning.
Variable names
--------------
Variable names are used to expose the values of the associated socket to your script. If the socket is unconnected then the value of the variable will be taken from the specified default.
node function `(sv_main)`
-------------------------
The main function for SN1 is ``sv_main``, in the body of this function is where we declare socket types, socket names, and variable names for input and output sockets. These are declared in two arrays ``in_sockets`` and ``out_sockets``.
The argument list of ``sv_main`` is where you provide defaults values or the nestedness of an incoming datatype. (don't worry if this makes no sense, read it again later).
That's great, show me!
----------------------
The easiest way to get started is to first load an existing script. Here are some steps:
- Go to `Generators / Scripted Node` and add it to the NodeView.
- Open a Blender TextEditor window so you can see the TextEditor and the NodeView at the same time.
- Paste the Lorenz Attractor script (from above) into the TextEditor and call it 'attractor.py'
- In NodeView look at the field on the second row of the Scripted Node. This is a file selector which shows all Text files in blender. When you click on it you will see "attractor.py"
- Select "attractor.py" press the button the right, the one that looks like a powersocket.
- This changes the way the Node appears. The node will now have 1 input socket and one output socket. It might even have changed to a light blue.
That's pretty much all there is to loading a script. All you do now is hook the output Verts to a Viewer Node and you'll see a classic Lorenz Attractor point set.
Study the sv_main
-----------------
If you look carefully in ``sv_main`` there's not a lot to the whole process. ``sv_main`` has two **required** lists; ``in_sockets`` and ``out_sockets``. sv_main also has a argument list which you must fill with defaults, here the only variable is N so the argument list was ``sv_main(N=1000)``.
The lorenz function takes 2 arguments:
- **N**, to set the number of vertices.
- **verts**, a list-variable to store the vertices generated by the algorithm.
In this example the ``verts`` variable is also what will be sent to the output socket, because it says so in ``out_sockets``. Notice that the lorenz function doesn't return the verts variable. All the lorenz function does is fill that list with values. Just to be clear about this example. At the time ``sv_main`` ends, the content of ``verts`` is full, but before ``lorenz()`` is called, ``verts`` is an empty list.
Here is the same lorenz attractor with more parameters exposed, see can you load it?
