I made a mockup, it’s in the comments under one of the tasks. IMHO all that’s needed is to make data flow lines thicker and leave the function flow lines as they are. No need to reinvent the wheel. Dashed lines do not belong in the node editor connections. Not only in Blender, but any other node based software out there. The only use they have is to imply some connection is disabled/broken/hidden/unused.
3 Likes
Actually, the most popular node program for architects has a few different wires that are very helpful to visualise the flow of information and to pinpoint where translation of different types of data may lead to an error. It has a single line for a single item connecting to nodes, two lines for a list, and a thick dashed line for an array. Not sure how this translates directly with fields, but I am all for having differentiation for visual lines that represent different types of data.
So am I, but if you take a look at the screenshot jamez has posted, does it honestly look like legibility improvement to you?
I agree this seems like a bit of a rushed design… I actually like the dashes, and I think what makes them look like they’re broken is that they’re discontinuous (the dashes are completely transparent). If the dashes were used for lightness variation instead (alternating white and light grey) it might work better. I suspect color coding is out of the question since it’s planned to be used for data types (at least in some of Pablo’s mockups), so we’re left with shapes. Unreal Engine also animates some of their node connections, maybe that would be an option ? of course it would have to be very discreet to avoid being too intrusive.
OR we could use stipple instead of dashes ?
@ManuelGrad didn’t know about this task… I have to say I liked the previous behaviour, I think some of those reversions make sense. I took the liberty of adding my opinion on the task
2 Likes
I read that fields don’t conflict with attributes, and in the vast majority of cases are a far more appropriate solution, but is the intent to get rid of attributes entirely? There are some cases where it would make sense to cache a value on a per vertex basis. For example, if you are performing two move operations and then a third operation that wants to use the intermediate position. It would be great to be able to save “intermediatePosition” to an attribute in this case. Being able to cache an expensive computation would also be useful (though conceivably it could be smart enough to spot no writes to dependences and cache itself, functional programming is awesome), particularly if you want to share it between graphs.
1 Like
I’m sorry but
The lines do not looks regular at all
it looks extremely bad
I like double line better
perhaps change of color?
that’s just my opinion
3 Likes
I agree with the previous comments, the dashed lines are not working here. Saying that the dashed lines are used in relationship lines and some other places, sounds more like a forced justification to use them in the nodes than a solid reason.
From my point of view would be enough if the nodes that connects Geometry with Geometry would have the same greenysh shade, leaving the rest as it is with solid lines. At first sight the user will identify clearly where is the geometry and what are the operation nodes.
This idea is not mine, if I remember correctly was Chris P. who mentioned in one of his GN videos in Youtube.
Here is a dirty mockup:
12 Likes
I’m in favor of using colors as well. I think Pablo Vazquez made a mock up like that which I liked.
I like this. The thing is, this doesn’t differentiate between fields and data, this differentiates between geometry data specifically, and the rest. There can be data of any type, vectors, colors, etc. which are single values so to say, instead of fields. I agree that the geometry flow should be more prominent but I don’t think that’s what they’re trying to achieve exactly. I’m certainly in favor of colored noodles though (yes this word is canonical)
Shouldn’t there be some more time to figure all these things out ? before this development cycle ends, I mean. The fields node conversions are not finished, the UI is wip… even the rendering team are working through CyclesX bugs. I mean it may be wiser to hold out for a little bit so that the release gets the polish it deserves (just my perception as a user)
2 Likes
here is my very quick mockup. 
I’m fine with dashed lines but I would say have no dashes in the middle part of the node wire and have the dashes only near the inputs and outputs. Less visual noise that way. I like the thicker green lines idea also.
Absolutely. In my opinion, the dashed lines serve a specific purpose in relationship lines. You don’t want a bunch of solid lines clogging up your viewport unless they should be a point of focus. Relationship lines should not be a point of focus. They are a quick reference for the viewport. If you want to see which objects are parented to which precisely, you use the outliner.
On the other hand, dashed lines in the node editor take your focus off one of the most important things. For some reason, when I see dashes in the node editor, I think “broken”, “not really connected, but constrained to”, and “proxy/ghost”. None of those thoughts fit the intended definition of “function flow”.
That being said, they might actually be useful some time, for debugging a tree every once in a while. So rather than removing them completely, I would rather they be moved to a display tab in the node editor. This display tab could include colors for types of data and functions, wire thickness variants, among other things.
Interface customization is the power of blender! Give us options!
5 Likes
I also agree that it would be great to have in the overlays drop down. I left a comment about this on BlenderToday #168 https://youtu.be/WSJBwO-JDa4?t=2585. The link is timed to the comment
2 Likes
Is there any hope GN will get some significant performance improvements soon, so Blender can handle (smoothly) a project with like 300K or more instances?
1 Like
Feature request:
The ability to change the origin point in Mesh Line (in a bundle Cube Mesh Primitives) - Geometry Nodes.
The man already wrote, he was told to write here:
blender.community/c/rightclickselect/THgbbc/
Just found the new super useful Realize Instances node - is there a way how to prevent UVs / Vertex Colors / Groups with this one?
Hopefully the dashes and thickness are exposed as parameters in the theme options. Otherwise, I might have to look into building Blender from source (which I have never done before). If you look at the commit, there is literally only 1 line to tweak, by changing the dash_factor variable from 0.75 to 1. I would also change the thickness variable back to 1 for the non fields noodles, and I could have everything back to normal 
Hey @jendabek
Perhaps you could create a performance comparison videos on how instancing compare in different DCC’s on let say 500k instances 
This will help the developers understanding why blender is perhaps behind and motivate them to boost the viewport performance with many instances
Note that this is slightly off topic, as it is not related to geometry node
1 Like