Sverchok 0.5

[ly29]

Or how to stop abusing update in one day.

How to switch over a node to the new system. 1) Rename init to sv_init 2) Change name of update to process 3) Done

For nodes that use multi_socket of changable_socket or creates new or updates sockets an update function is still needed.

Originally I had more advanced plans for this, but they can be built upon this foundation. This obeys the KISS rule

TODO:

• [ ] Documentation
• [x] Viewer colors into init() and standard
• [x] Load old nodes on demand
• [x] Vertices socket with popup, working state
• [x] Load old nodes when needed via I/O

Nodes left:

• [x] Script, done.
• [x] Eval Knieval, a bit tricky to separate process and update
• [x] List Decompose, redone inside process/update switch. Algorithms need some work.
• [x] Formula node (the old one), hard to split update and process
• [x] Waffel node has obfuscated socket creation
• [x] Object in node has obfuscated socket creation

Verify or fix updates to master.

• [x] UV connect
• [x] Wafel
• [x] Docs
• [x] JSONs and scripts

To resolve

• [x] Viewer nodes need safety check in update since process doesn't gets called for single nodes, or change it and call process on empty nodes. No process on single nodes.

[flowb]

oooooh groups!

[ly29]

Editing, names now works, connect to create more sockets etc. Socket type needs some work.

[ly29]

The torus/dount json used as node group to create a parametric object

[ly29]

I stored the node groups in another type of node tree. They aren't meant to be visible. The idea comes from the custom nodes template file, bu the following doesn't seem to be true anymore.

    # Icon identifier
    # NOTE: If no icon is defined, the node tree will not show up in the editor header!
    #       This can be used to make additional tree types for groups and similar nodes (see below)
    #       Only one base tree class is needed in the editor for selecting the general category
    bl_icon = 'NODETREE'

[ly29]

Keep track of nodes that raises errors and clear it when it works. The error is produced because the upstream nodes doesn't produce data.

[ly29]

Of course many nodes hides errors right now, something that should be resolved. Failing is the right thing to do when data cannot be produced.

[ly29]

Reroute - note that this works by processing by changing the output socket type of the reroute

[nortikin]

how do you do it so quick?

[ly29]

I had some bright ideas suddenly. :smile: Or atleast working ideas.

[ly29]

In process(self) it works okay with .is_linked

[ly29]

So testing of this branch and feedback would be very appreciated. If some node/problem can be fixed easily please create a new branch from toProcess so we can merge the changes in a good way.

[flowb]

Hust started playing around with it. It seems a lot more responsive and stable than master so far.

the node group feature is very handy. is it possible to give groups a name besides "group"?

:[florian]:

On Oct 21, 2014, at 06:57, ly29 notifications@github.com wrote:

So testing of this branch and feedback would be very appreciated. If some node/problem can be fixed easily please create a new branch from toProcess so we can merge the changes in a good way.

— Reply to this email directly or view it on GitHub.

[ly29]

Yes, in a backwards way that should be changed. Edit the group, change the frame label and save the group.

[flowb]

awesome.

i was noticing in your mockup above that your reroute node behaves like the "dot" in Nuke. When I use it on my machine it creates a node frame (with a separate in and out pin). how did you get it to behave that way?

[ly29]

Ah, have to fix that also. You can create them by holding down shift and dragging over a noodle.

[ly29]

New version available now with real reroute point.

[flowb]

sweet,thanks!

[ly29]

updated changeable socket, all self.newsock and self.typ can be removed.

[nortikin]

Separate thanks for changable sockets. Hide\unhide of layout from panels not works here. (when you press eye)

[ly29]

@nortikin Yeah, fixed that.

[ly29]

Some reroute fixes.

[ly29]

List Decompose, sockets are created based on user interaction. Levels seems to be wrong (1 to high). Otherwise it works. Well actually it seems to need some further work.

[ly29]

The capability EK presents are important I think, splitting it up is a bit complicated. I think the easiest approach is to split it too a separate nodes called (more or less):

• get property
• set property
• do

[zeffii]

Agreed, A family of 3

For .get and .set EK can be done nicer. I keep imagining a mix of prop_search and dynamic enums as a sort of cascading property selector, instead of typing the path you get choices based on what's available, I think a search based on the letters typed is also possible. This would shrink that code a lot and allow much convenient reuse of code.

.do well I dunno.

I'll be doing a Port of EK for FLOW, and if i think it's an improvement I will Port back to Sverchok. Unless you guys come up with something better

[ly29]

I a full faith in your imagination when comes to these kind of things. Get and Set I would like to have soon. Anyway will see what happens. Have you tested groups? Do for me is less important.

Soon off to Amsterdam.

[zeffii]

Yes! I eagerly await the talk and the exposure it will give to the Sverchok and custom nodes in general and perhaps improvements in certain parts of the C side.

The very best of luck on the trip Linus..

[ly29]

Thank you, I hope it will go well.

[nortikin]

yes. best to voyage groups tested, it is ok for me, fantastic. have catch a cold and bronchit illness. two days was terrible. i should ask phone number to communicate... to email now

[nortikin]

it seems, that we could do workshop, not lection... it is too late

[ly29]

removed sverchok from the python path added a simple cache node to play with.

[ly29]

A part of the new __init__.py code is growing on me. The monkey patching/aliasing to make sure sverchok is loaded correctly no matter what the is directory called sverchok (this is probably the case most of the time, consider sverchok-master for example)

import sys
# monkey patch the sverchok name, I am sure there is a better way to do this.
if __name__ != "sverchok":
    sys.modules["sverchok"] = sys.modules[__name__]

[nortikin]

but sverchok-master is common for everage user. Registering to blender python path not smart, many people say it.

[ly29]

This works with the name as sverchok-master or anything. So we are fine. At least for me, however testing is always appreciated.

[ly29]

A hypen in the name isn't considered good practice since you can't import it with standard import. Long time we should fix that too. But if we alias it like I showed above it appears under the sverchok name not matter what.

import sverchok-master
#!   File "<blender_console>", line 1
#!     import sverchok-master
#!                    ^
#! SyntaxError: invalid syntax
#! 

[nortikin]

Setup of preferences failed Couldn't setup Sverchok frame change handler

[ly29]

Oops thought I had pushed the fix for that.

[ly29]

Okay, try now.

[nortikin]

you made shorter intro?

[nortikin]

working

[ly29]

Yeah, there was lots of duplicate code in __init__.py some things is still in flux there.

[nortikin]

is it what allow to avoid registering?

     for m in imported_modules + node_list:
         if hasattr(m, "register"):
             m.register()

[ly29]

yes, but that we had there for a long time. there are modules in utils for example that don't need anything to register, but we still need to include them here so they can be reloaded on F8

[nortikin]

node_list doubled some times

[ly29]

What?

[nortikin]

65 line- can delete this line

[ly29]

yes. will do.

[ly29]

I suspect that merging with master will be hard and therefore will try a manual merge of certain files.

But in general this branch will just overwrite the master branch.

[ly29]

@zeffii @nortikin @Kosvor @AgustinJB

I propose that we freeze development of master and focus on the toProcess branch. Further work in master just create more possible conflicts that prolong development and create complications. Otherwise we (I) only have to fix the same issues over and over.

Agree?

Small bugfixes only etc.

[ly29]

EK Node

The code has 4 entry points that are distinct. Today 1 and 3, 4 are the same.

1. Setting the stringproperty
2. Setting the mode
3. update
4. process

What should happen for each event type.

1, the string property shouldn't be linked directly to updateNode. When it is set it should be verified and then appropriate socket types might be created, re linked etc. Color set and then we can call process via the updateNode

2. Change the socket, etc. Verify that is is property that can be set/read.
3. Morph sockets perhaps, not really needed.
4. Get/Set the data/property as appropriate. If anything goes wrong raise and error. No socket modifications.

[zeffii]

I don't have the energy to do any of this