nortikin / sverchok

Sverchok
http://nortikin.github.io/sverchok/
GNU General Public License v3.0
2.24k stars 233 forks source link

Sverchok on blender today #3720

Closed onerawartist closed 3 years ago

onerawartist commented 3 years ago

Someone asked a question and pablo gave an answer, i wanna know what you guys think https://youtu.be/LVDFyT0wYaw Start watching around 30 mnts and forward

Durman commented 3 years ago

Geometry nodes and Sverckok have different paradigms. Geometry works with geometry objects Sverchok with lists and numbers. Many nodes in Sverchok are wrappers around Blender library (viewers, modifiers). Many nodes have performance issue. Many nodes have really ugly and difficult to support code (if someone could estimate quality of code of our update system or some nodes probably nobody ask such quastions). Sverchok has a lot of inconsistencies a lot of architectural problems which can even kill Sverchok in the future. Sverchok is a playground. Everybody can add any code which can be irrelevant with other parts of Sverchok. Sverchok does not have any program or particular direction or any plans for its development.

portnov commented 3 years ago

On the other hand, Sverchok is currently far ahead of GN feature-wise (though this can rapidly change if BlenderFoundation will really invest in GN). And, ironically both sides — ugly code and wide set of features — have the same reason: Sverchok development is very open, everyone comes and writes what he wants and how he wants (and many Sverchok contributors are not professional programmers).

vicdoval commented 3 years ago

Also Sverchok initial target (Architectural parametric design) is quite different from the general Blender target (general 3d creation). Because of that many of the features from Sv will hardly ever get to Blender itself and specially because of the last updates (curves, surfaces, solids, SVGs, integration with LadyBug tools, IFC nodes...) I think it will be very difficult for the Blender Foundation to fully replace Sverchok

onerawartist commented 3 years ago

Maybe you can guide the blender team to make geometry nodes like tessue addon by @alessandro-zomparelli a simple version for the vanilla blender and the ones interested in more can dive deep and get the github sverchok, because i believe sverchok can bring more users ''architects'' to blender and definitely more funds to blender. Maybe if the blender dev's saw the capabilities of sverchok they can make the sverchok that we dream of, more stability and better performance, with all these features '' lady bug and freecad '' Im not asking you to change sverchok. Im asking you to guide the blender team into this new phase

zeffii commented 3 years ago

GN will be cool, it will be fast, and if you consider what ridiculously cool things can be achieved inside just a shader nodetree (without a scriptnode), then as soon as the features of GN start to increase - quite a few users might opt for GN instead of SV. good luck to them!

Some users have been working with Sverchok as a "glorified nodebased modifier stack" , but that's not sverchok's strong point. Lots of our modifiers use the bmesh api, which means an annoying amount of back and forward conversion of mesh data - and that's a slow down in performance.

GN's progress can only mean good things for Sverchok, it looks like new UI api are being designed for GN - maybe these features will be available for custom PyNodes too.

I don't agree with @durman about Sverchok's design being "bad" - because "perfect is the enemy of the good", yes a lot could be improved in the backend of Sverchok to allow the front end to be more flexible. But we had to start somewhere. A rewrite was already attempted by @ly29 but i think it failed to gain traction because it was a large departure architecturally from sverchok's internals at the time. This made it hard to build up the node-base and maybe i wasn't ready for that level of abstraction -- and when that's the case, a project gets to a point where it has a "one developer struck by a bus" problem, where all development has a single-dev bottle neck.

Durman commented 3 years ago

Maybe you can guide the blender team

You so distrust them? I think before starting active part of geometry nodes project the team investigated already existing solutions in other softwares and they should have conception of what they would like achieve. Actually I don't see what Sverchok can suggest to geometry nodes.

it looks like new UI api are being designed for GN

It looks like not. All nodes are written on C at this moment. https://developer.blender.org/diffusion/B/browse/geometry-nodes/source/blender/nodes/geometry/nodes/

zeffii commented 3 years ago

@Durman pablovazquez shows screenshots of mockups of colored noodles etc., no mention specifically about new python api, true. This would be the time to get involved with serious requests to get new ui API. and request rightclick behaviour on the socket (rather than a dropdown which takes away precious UI space on the node for sockettext)

portnov commented 3 years ago

What we could suggest to GN is GN <-> Sverchok integration in a way it is working with AN and Sorcar:

This would, obviously, require possibility to write GN nodes in Python.

zeffii commented 3 years ago

right now you can use the GN on Sverchok generated geometry, so that's already interesting. image

a standardized programmatic way to pass data between one program to the GN nodetree (via a listener node or something), reading a rich numpy based mesh structure would be super interesting. (verts, edges, mixed tri+quads, vcols, materialindices) i would gladly sacrifice ngon support :)

ly29 commented 3 years ago

@zeffii Yeah the modell I made back then was in the right direction but had some drawbacks. With what I know now it would have been better (which also does not matter).

The main problem is that the abstraction of what a nodes tries to solve is simple but wrong, each nodes is not simply a node that the data flows thru which composes info a functional architure or pipeline. Instead each nodes tries do that but is its own mini program with way to many responsibilites and complexity.

If ones compare to what is possible inside of an OSL node then one reaches a good approximation of what a pipeline architecture would look like. Less is more. Except the small detail that the unit of execution is a tree.

Something like Sverchok which works on a level of numbers etc I think is very valid thing to have. The easiness of generating geometry from python and combining effects is just plain nice.

onerawartist commented 3 years ago

@Durman i didn't mean distrust the blender team but guide them to where we need blender to be ^^ Ton has always said blender is always developing to where the community wants, and now the only ppl who know what GN can be is you guys, the sverchok team

and i've been talking with alot of blender youtubers, that use blender for game assests, modeling and sculpting guys and no one is interested in geometry nodes that much. Such feature is interesting for people like us '' sverchok gang '' ^^ so what i want: is to get our voice out there, and track the attention of the blender team to what we need, as a parametric design tool. So what im saying is i trust the blender team that they can give us a great tool for parametric design and i trust you guys that you cab guide them to that ^^, im not a programmer but i read every notification of sverchok on github and i see how much work you did put into sverchok and i believe you are the best people for the job. Get involved, ask for features, guide them so we get the best features for our needs. This is your moment ^^ make GN ours

zeffii commented 3 years ago

welcome back @ly29 , even if you don't intend to participate much . it is good to see you.

Something like Sverchok which works on a level of numbers etc I think is very valid thing to have. The easiness of generating geometry from python and combining effects is just plain nice.

This is precisely why Sverchok will remain relevant indefinitely, or until such time that GN provide a DSL language for a script node or adopt something like OpenMeshEffect, then GN will become a more all purpose Mesh modifier tool, and it won't be limited to the nodes provided.

I'm still in favour of a recode, but it would drop a lot of nodes (all bmesh, all ngon support), and be mostly numpy data structures or even an entirely C++ backend. <----- but where does one find the time for that at the moment?

Durman commented 3 years ago

I don't agree with @Durman about Sverchok's design being "bad"

Don't know, probably it's not bad. What I know is that since august nearly all my contribution is about rewriting existing code. 2020-11-18_08-36-02

Sverchok development is very open, everyone comes and writes what he wants and how he wants

It's true until what they want is not in conflict with what others want. Interesting is it Sverchok as open for removing functionality as for adding?

portnov commented 3 years ago

You can try :) I already thought about removing some nodes. But maybe I just do not understand how do they work. Let's create a ticket with a list of such doubtful nodes. Maybe some of them just need better documentation. There are some codes, which, while have weird code, work fine from user's perspective, at least in most cases (many from List category). Such nodes should not be removed, but rewriting them (while preserving functionality) would be good.

ly29 commented 3 years ago

@zeffii Good to be back.

Sverchok might deviate from my current ideals of how to write code (my day job involves writing purely functional code) but still I had a lot of fun both writing code, solving problems and playing with the nodes.

Learned a lot interacting here as well!

zeffii commented 3 years ago

while we're at it @portnov let's also compile a list of things that we would like pynode API to have, so that these things can be shared by many add-ons rather.

portnov commented 3 years ago

Where should such questions go? To dev.blender.org?

rendetto commented 3 years ago

Interesting is it Sverchok as open for removing functionality as for adding?

A node/feature could be removed only if it is 100% surpassed by another. Even if that's the case, it will broke all current node setups and that could be really annoying and discouraging.

What I could suggest for overcoming this problem is creating "Sverchok Legacy" similar to "Sverchock Extra" that contains all those old nodes and functionalities so we got the node backward compatibility as an option when things change in main SV.

onerawartist commented 3 years ago

Does anyone think about starting a ''sverchok today'' youtube videos ? Reading these comments is so motivational ^^

portnov commented 3 years ago

@rendetto , there are also nodes, which work for some very specific cases, and often the only person who knows what those cases are is their author, who can be not available. Some nodes have no documentation, so nobody knows what they do :)

portnov commented 3 years ago

@onerawartist , Sverchok's community is much, much smaller compared to Blender's. We just do not have that amount of people and time available to create any sort of educational / informational content on a regular basis. If you have enough motivation and time, you are free to do it :)

rendetto commented 3 years ago

@portnov

Some nodes have no documentation, so nobody knows what they do

You're right about the lack of documentation. There are nodes with names suggesting something which could be really useful but I don't have any clue how those work.

So a push in this direction will be really helpful - I mean at least a call for all developers who are still in touch to document the nodes they did.

onerawartist commented 3 years ago

@portnov Im just not good enough yet, and i know the frustration that the viewer have when you see the teacher not knowing what they do. Even if its for a moment. I think erindale is the best candidate for the job at the moment, im just waiting for nodevember to end to start annoying him with my requests ^^