Everything nodes

The one on the page I linked to - in essence that you want results as fast as possible, not having to wait too long for your network to cook.

@rawalanche, this is entirely how Houdini works and it’s a tremendous success in production for both people with experience in programming and people without… oh sorry you meant blocks. This thread is going too fast for me to keep up ! ^^

Yes, I meant blocks. The Houdini uses nodes, not blocks, and it’s actually a great example of how everything nodes is done right :slight_smile: While I don’t expect Blender to become full blown Houdini, because it also comes with some drawbacks, I do hope that everything nodes will be something similar to Houdini, albeit simpler :slight_smile:

my thought is to use nodes that are composed of blocks (which are only a visual representation of a programming language) that facilitates the editing and creation of variations of nodes to those who do not know the language of programming … in this way, blender itself would become a programming learning machine … feasible in the field … during the creation of the projects … iin practice, breaking down the limit of not knowing a programming language for an artist or a maker in general. . …
that’s all

Well, with something like UE4 blueprint, you can do pretty much everything an average scripting language such as C# or Python, yet without that clumsiness and limited nature of those blocks. You still can use it without understanding lower level programming syntax, but you don’t encounter many of the inefficiencies and limitations which make those blocks impractical.

So, you have posted this link: https://developers.google.com/blockly/
And it defaults to this code snippet:

So this is what the same code would look like in blueprint:


It’s true node based approach with all the flexibility and the benefits of it, yet with the simplicity of those blocks. :slight_smile:

3 Likes

of course these “blocks” was just an example … because it exists to expose… but if there are far more effective openings well …
the important thing is that we understood each other ^ ___ ^

bare in mind Blueprint is the real deal, a real full blown programming language with static typing and optimised for performance.

There absolutely no comparison that Blocky far simpler and easier to use as it is made for kids, Blueprints is made made for professionals.

oh there is no reason for slow down, Blender nodes are not a real programming language they are built on top of C code and they are designed to be high performance. Also in some cases they involve the GPU as well which makes things much faster too. Plus the shit hits the fan only when you get to this level of complexity

this is basically 20 lines of code, now imagine the equivalent of 100 lines, 1000 lines. When I am talking about complex node setups I mean 10 times more complex that this one. This is when node limitations even with node groups start to become obvious.

But yeah nodes can be even faster than Python.

1 Like

That is misleading at best :wink: I have hard time imagining hand coding those tangent points in all those curve nodes. The visual clutter here is an unfair illustration. Especially since it’s also laid out to be almost intentionally confusing. It could be cleaned up and aligned to look better, and second of all, while Blender indeed doesn’t have true node based programming, for example Cycles nodes have quite a lot of common with it.

Furthermore, Blender does have node groups, so you can have almost infinitely complex node networks and have them still looking clean and be manageable if you use node groups as containers representing classes and functions :slight_smile: Both classes and functions are in their basic nature just means of containing and compartmentalizing the code.

1 Like

I jokingly joking I can easily model objects that I then 3d print… with blockscad … without this I would not be able to model with openscad …

I was talking about Python in regard to performance, since previously you were arguing about your preference to use Python over nodes - which I partly agree with, bear in mind.

Note my preference over nodes is not universal, as I said unless I go for something complex and highly procedural nodes is the way to go. Nodes are great , I have nothing against nodes for most use cases.

Oh my bad, yeah Python can run circles around nodes in terms of performance having access to all high performance libraries out there, GPU , CPU , alien technology , pretty anything can run Python nowadays. Python wise you can do crazy optimisations not to exclude the fact that it gives you direct access to C libraries down to low level code. Which why Python is so heavily used in AI and scientific research.

You cannot optimize nodes, if they are not fast enough for your needs, your are pretty much helpless unless you create nodes with Python or edit Blender source code.

You mean that gui that is mostly defined by Python ? Yeah I wonder how on earth Python could do that the easy way :smiley: , obviously it makes no sense to code everything by hand, you obviously know that even we coders heavily rely on GUIs. What you think an IDE is ?

Or do you think coders design GUI by code ? That may be the way Blender Python does it, but modern coders rely on GUI designers nowadays. Although in case of addons its ok because usually the GUIs are not that complex. In my case I design my custom GUIs cause I have a bit weird demands.

The only scenario I could think that that I would want to adjust the parameters by code would have been if I knew exactly what I was doing which thank god most of the times I have no clue what I am doing :smiley:

So if you heavily rely on GUIs thats even more reason to prefer Python over nodes which have rather limited GUIs anyway.

PS: Kinda surprised none has released a GUI designer for nodes, or someone did and I am not aware of it ?

Judging by how many artist love to use the node system instead of programming in Unreal Engine, I would say that nodes are much more preferred over manually typing in lines in a text file. Nodes are highly domain specific, so they can focus on the problem they are trying to solve 100% without any overhead. --and if there’s demand for more complex functionality programmers can always jump in and easily create new nodes, as the data types are very well defined.

1 Like

Unfair comparison cause everything looks awesome in front of the abomination that C++ is, even if we include the fact that Epic did its best to bring it as close to Unity C# as possible. Blueprint have no overhead ? who told you that ? Of course they do.

So people love Blueprints so much that when it came to customizing the most important part of Unreal engine, the editor, Epic chose to go with Python ? makes sense

And judging from the fact that Unity has not even bothered with making an equivalent of Blueprints , I think its safe to assume that Blueprints is not as much loved as you may assume.

And Blueprints is not exactly the first try at very powerful node system, Softimage did that ages before Blueprints with its own node system language ICE and we all saw how much that helped Softimage :smiley:

Nodes are very useful tool but their limited are well documented among experienced users.

In terms of “market research,” I think that we simply need to keep comments like Kilon’s (post #157) very firmly in mind:

… and then, without(!) judging it, carefully weigh it against the subsequent posts which fairly-immediately followed. Recognizing, all the while, that all viewpoints are equally correct!”

This is the conundrum of the user-interface designer. There are no “bright-line rules” here, only carefully-selected compromises.

Yes, we have three bona-fide user camps:

  1. Those who use GUI.
  2. Those who use nodes.
  3. Those who use Python.

… and, guess what(!) … those “three user camps” might very well be one and the same(!!), since “Laziness is a Virtue!™”

Yes, here are three diametrically-different “use cases,” all legitimate. The challenge for our design(ers) is that we must somehow strive to accommodate all of them, without compromising any of them. Because, after all, "we have probably been in all three places, at one time or another," and it’s likely that we’ll one day be there again … “lazy (and virtuous) as ever.” :smiley:

2 Likes

absolutely the best is to find the balance between nodes , GUI and Python. Even more so the success of Blender is how elegantly it allows you to switch from one to another without any mental overhead. What you learn in one tool is knowledge you carry to the next one.

“There is no spoon”

but sorry, what does the performance have to do with it?
in the end are not simply two different types of languages, nodes and scripting, to communicate with the machine what he have to do?

everything

because in the end everything is machine code and machine code can be from super slow to super fast. It all depends on what it does and how. We have a saying in coding “premature optimization is the root of all evil but sometimes a necessary evil”. Making machine code go fast is extremely complex field, its why we dont code in Assembly anymore, why C is nowadays is considered a low level language while it always have been high level, its why we rely on high performance libraries etc. In the end machine code depends on the hardware and unfortunately the hardware has become insanely complex , unfortunately this complexity is what it gives its speed.

When I started coding back in 1988 moving bytes around coding machine code was a viable strategy , nowadays even low level coding in C is considered an insanity. So the fight is all about how to get top performance while not having to drive your mind insane and that is the reality of professional experienced coder. Back then my computer was 0.004 Ghz single core , essentially 0 speed with 0.000128 Gbs of memory , essentially zero memory. Computationally it was 3 million times slower than an average high end modern pc and 3 million times simpler. Simpler times , slower times.

Now enter the realm of users, which want everything to be easy, simple and straightforward yet very very fast. The same users that carry in their pocket a smartphone that a decade ago would have been considered a supercomputer. Back in the 1988 when I started there would not be enough money in the world to buy that technology. Countries would have gone to war to have that techonoloy.

What we use it for ? To play Candy Crash Saga and it still runs out of battery.

Without performance , you have nothing. There is nothing simple about performance, whether you do it in machine code, Assembly, C , Python, Nodes or your favorite GUI. In any case its a world of pain but that is the price to pay.

You take it for granted like the air you breath.Yet that does not make it any less important. That does not change the fact that in technology , performance, is everything.

I know I’m replying to a comment that’s SOO 6 days ago :smile: but…
Wouldn’t Sverchok add in do this?
http://nikitron.cc.ua/sverchok_en.html

1 Like

I just read that to create a new node in cycles and in compositor, the question is quite complicated at the moment …
will it be so complicated even for everithing nodes?

at the moment there is no porting for blender 2.80 … too bad :slight_smile:

edit:
no im wrong.

One way to handle the complexity is one of the reasons that object oriented programing came about, that is to encapsulate well known functions into a class or function. You don’t need to know how it works inside the class, just how it’s interface works. You can do a similar thing with node groups, almost. It would be nice to have the ability to handle groups as a single object/class that could be easily managed within a library, etc.

2 Likes