I think I made a mistake. Somehow I thought you used Geometry Proximity in your setup, but you actually used Indexes only.
So in the end, I can’t confirm that the behavior is normal…
Then why is the id socket a diamond without a dot by default? How is one supposed to know that a single value would be useful in any case? And how is a beginner supposed to guess that another node is needed to achieve this effect?
In 2.93, random float had it’s own node, so obviously generating single values was used often enough.
I think a Boolean checkbox value named “single value” would be enough. When the value is set to 0, the node looks and acts the same. When set to 1, the ID socket disappears and everything is evaluated on a common index.
3 Likes
Hey everyone
Gentle reminder that we’ll enter in bcon3 soon (might get delayed btw), so if you see important problems in the current state that need attention, now is the time to speak 
1 Like
Have to agree, this is the most undiscoverable thing. The ID should have a number input field too (field, as in the interface widget where you enter a number), so that it defaults to a value (still accepting fields, as indicated by the socket shape).
I think that until the problem of rendering attributes in eevee is not fixed (not including the experimental view of vertex color in development extras mode in the settings), it is worth postponing bcon3.
Just make this real via python
Note that it’s not an ideal behavior, ideally it should switch per area context
check here
8 Likes
Ok I see where the confusion comes from.
So it’s like this, all field sockets can accept single values, no matter dotted or not.
Dotted means: It does not have a field in it. So it’s either empty or has a single value connected.
Non-Dot Diamond means: It already has a field connection. If you didn’t connect it, it’s an implicit connection.
So whenever you see a diamond shape without a dot it means it already has a field in it, if you connect a single value to it, you are replacing the field with a single value, therefore turning it into a dotted diamond.
The implicit field connection is also expected, it was written in the original proposal:
I hope this is clear enough
6 Likes
After 24 hearts on this video showing the ability to turn off dashed lines, Dalai posted his opposition to the option of turning dashed lines off: “Just for the records (I talked to Pablo about that in real life as well): I don’t think dashed lines should be an option. The same way the socket shape is not an option (I borrow this argument from someone else 
)” See ⚙ D12886 Node Editor: Introduce color and dashed wires overlay And then Pablo removes it after that post. That is baffling to me. A very strong negative reaction from the community on the feature of dashed lines, and a large amount of users in favor of the option to turn them off (24 hearts?), and when finally one gets the freedom to turn the dashes off, the opposition of one person takes it away. Somewhat mind-boggling for a FOSS touted as giving users the freedom to do what they want with the software.
4 Likes
What was Dalai’s explanation for why it shouldn’t be optional?
That was his explanation: ‘I don’t think dashed lines should be an option. The same way the socket shape is not an option (I borrow this argument from someone else’ Basically, socket shapes are not an option, so let’s also make dashed lines not an option.
I guess the arbitrarily decision to not make dashed lines option is based off the arbitrarily decision to not make socket shapes optional. Exciting.
1 Like
What is noteworthy about this, aside from its being tone deaf in ignoring a large portion of the community that wanted the option and ignoring its own stated ethos of creative freedom, is that good UI would not require multiple levels of redundancy in communicating information. If there is one area that communicates the information, one would think that the reasoning would be, ‘Well, we’re already communicating that information here, so it is not absolutely necessary that it be communicated in some other area. One area should suffice, and the user can have a second at his preference if he wants it’. Instead, the poor UI reasoning is that if it is necessary in the first instance, it must be necessary in a second.
4 Likes
I do have to say that THIS and other things that happen for no logical reason are slowly bordering on insanity, especially when community says “please optional” to which a dev says “should not be optional”
Sometimes i ask myself if this is a open source project or a closed source project with a illusion of being open 
2 Likes
I think there’s a bit of a misunderstanding here. I believe what Dalai was saying was that the ability to toggle dashes shouldn’t be an overlay, as the dashes are built into the fields system (unlike colours which are just aesthetic, and work with any node network)
Don’t get me wrong, I think there should be an option to disable them, but I think Dalai is just saying that that option would be better placed in the preferences rather than overlays.
2 Likes
Using that same logic, these options that are built into the 3d vp system shouldn’t be an overlay either?
Wireframes and origins are not aesthetic, they are useful to toggle on and off during the workflow. I think the same goes for field noodles.
No, aesthetic options belong in themes. Options that you might temporarily disable should be in an overlay tab.
1 Like
Not saying I agree with it, I’m just pointing out that I don’t think he’s saying that there should be no toggle for dashed lines anywhere (which some people seem to think)
1 Like
Maybe someone can invite Dalai to better explain himself in this thread?
On the page of the provided link (⚙ D12886 Node Editor: Introduce color and dashed wires overlay), no mention is made of moving the option to preferences. Dalai’s words were ‘I don’t think dashed lines should be an option’. It would still be an option if it were in preferences, just an option that is more of a hassle to get to. But supposing for the moment that you were correct, why make it that much harder to toggle dashed lines? The ostensible basis for this is that it provides some information that would be of use, but many users hate the visual clutter and noise and feel quite confident that they could get on for much of their work without the dashes. If they messed up somewhere in the node tree and thus could use that field information provided by dashes, the place for that is a quick overlay accessible through the dropdown. It is not as if that dropdown were overly large. Far from it. It had only the options for colored wires and dashes.
If it be responded that there would be no indication of what is a field if sockets change shape to indicate that they are receiving data (if that is the final result for socket visualization), then they could simply change the socket display such that it does not lose all indication that it is or is for a field, or, barring that, they could simply accept that some users will have enough familiarity with the nodes to not need the indication but do want the reduced noise and visual clutter of solid wires and yet still have the ability to get back the dashes briefly if they need them for solving a problem with their node tree, upon which resolution of the problem they could turn the dashed lines overlay back off.
Dalai’s words were indeed “‘I don’t think dashed lines should be an option”, but it was in the context of a proposal for a dropdown with a list of options. This would suggest that what he meant was “‘I don’t think dashed lines should be an option [in this dropdown]”.
It’s true that he didn’t say it should be in the preferences, I was again extrapolating that if the option was not in that menu, it would be in the preferences.
Tbh, we’re just getting into semantics here, which is a bit pointless, and it’s impossible to know without asking the man himself…
