EDIT: I turned out being wrong, see Geometry Nodes - #1978 by HooglyBoogly
Well, try it youself, have your GN on the default cube, and connect a curve primitive to the output, select the object and see the colors of the outlines:
Curves will always be instances if the object itself is a mesh.
Thatās misleading actually. The only reason itās a different color is because the system we use to output different geometry types from a single object also uses the instancing system. The curve in this case is not actually an instance.
Hmm that sounds strange
So it is an instance?
So it is not an instance?
This is getting confusing
Itās not meant to be an instance for the user, thatās only the system for how itās displayed internally, which managed to sneak through in this case (weāll fix it soon hopefully).
Proximity never worked with empty even in legacy nodes because empty doesnāt have any real geometry. If you want to use empties as spherical falloff you can make a group like this, and then for example use it as factor to mixing between position and what ever you want to do.
Jacques just posted a new task regarding Object Infoās new option for instances or not
https://developer.blender.org/T91890
@Orestiskon So there will be a boolean checkbox on Object Info for switching between instance and real geometry I think.
im wondering why not doing the same for geo instance node, having a proper node to realize instance is not good ux
Well, the Instance on Points node has the word āinstanceā in its name so it is expected to output instances anyway
then rename that copy to point or duplicate on point or something else ?
That will be weird. In the upcoming future we are going have nodes that operate directly on instances, (I mean the Translate/Rotate/Scale Instance nodes) and it is really not necessary to realize the instance, having the node is fine I think.
My two cents about the ādashed lineā topic.
Not a big fan here as well as it is now, but the bottom version in this image looks acceptable to me.
My original opinion before this change was committed was that fields connections are kinda similar to shader connection in the way you use them so it would make sense for them to be visually similar.
The real new concept (if compared to blender versions before GN existed)
Is the Geometry Connections.
So I thought that fields connections should be kept just as they were before, and Geometry Connections should be represented as āBoldā ,since to me, they carry āheavy weight dataā or " Real and Concrete Data" Wich is Geometry, something tangible if compared to fields that are just āfunctionalā connections.
The first thing that came to my mind is double connections for geometry noodles, but I didnāt do any mockup, and I imagined them to be confusing and strange, but now that I see thisā¦
I must admit that the double line doesnāt look that bad.
Color coding could work, but for accessibility reasons I would not rely to much On that for connections ( color blind people could maybe have hard times distinguish the noodles if only color is used ?)
MY CONCLUSION:
Maybe a Simple solution would be just making Geometry Connections 1 or 2 pixels thicker and the fields 1 or 2 thinner, so they still feel Like real and not broken connections, but have a decent weight difference, and hopefully they would be sufficiently distinguishable.
What do you think?
anyone know whatās the replacement for the attribute mix?
Didnāt find it here, it just said āremoveā with no equivalent
Color have the Mix node
However, we are stuck for Float/Int/Vector type
Are we supposed to create our own LERP nodegroup?
It might be an essential functionality, attr mix will definitely be missed by the users
You can separate vector and use map range on each component
Note that didnāt say it was not possible/feasible
iām saying that the fact that thereās no longer easy lerp for Float/Vector/Int is a regression
I totally agree.
In the meantime you can also use this MixRGB node to also mix vectors. RGB colors are a triple / vector anyway. It works but it looks ādirtyā as hell as the socket colors also turn from blue (vector) to yellow (color):
But still easier to plug together and read than separating vectors into float components and combine them back 
Regarding function lines, Iām not a fan either of the dashed lines or of the double lines, Iām more inclined to something like this.
My two cents on the situation: as much as I understand the need of differentiating the visualization of fields for 3.0, Iām a bit surprised the devs decided to introduce this change basically at the start of bcon2, this is a change that will deeply affect the visualization and understanding of node trees from now on.
Now, while the strength of Blender is indeed updating, refactoring and ābetteringā features from one release to another, Iād prefer to wait one more release and have a good, tested and perfected way of visualizing lines, instead of sticking with this dashed lines for one release until gets changed, or try to change it now with rush.
In my opinion, we should keep the lines as before, with no differentiation, for this release, and use the time until 3.1 gets out to create a proper visualization of different lines. Here in the thread there are some good proposals, but they were all created to try to solve a change that was put right at the end, Iām afraid that even if the devs decide somehow to use one of these proposals for 3.0, it would still be something decided more for the rush of getting it done on time, and would probably meet some disagreement by the users until gets changed again.
I quite like dashed line, it got this ASMR vibe when Iām pulling nodes, but I agree that with more complex cables it can result with readability lost so definitely fan of making smaller breaks between dashes, and maybe some color differentiation, or whatever can make more readable crossing between two dashed lines, maybe some drop shadow? And one more thing itās more readable with clean background, half of complaints might be due to this.
I am still confused about how is it possible that changes like this do not go through some vetting process. That just single person with a really poor taste can make a decision and push it right into the master branch while ignoring feedback.
MixRGB has been used in shader nodes to mix single channels for years. Thatās not to say it should be though.
Question:
When using color sockets to transport float data, will it cost the same performance as using a full rgb color? Or will lazy evaluations take care of that and make it cost only as if you were using math nodes?
