Why multiple ? this already exists so why not use it… if a node shows multiple errors they can always span several lines can’t they ?
I’m not sure how many potential errors can happen with geometry nodes. Missing attribute, or connection between incompatible types… maybe these can be shown differently. I know node links go red, maybe attribute string fields could go red, too ? the same way object fields do when the chosen object goes missing. The “warning” icon on the node header could be a “hub” of sorts for these error messages.
To me it just seems unnecessarily diverse. It’d make more sense to use just one design language. For example, node connection lines where there are two incompatible types without any implicit conversion would show red, and fields with invalid attribute name would be also highlighted in red.
This is already a standard in Blender:
But as usually, someone introduced a new standard (random warning icon clumsily squeezed into node header) instead of checking if there’s already existing one.
Yes, this is exactly what I suggested lol
I do wonder if the header warning icon is necessary. Hence my questioning what other potential errors there could be with nodes. I tend to prefer a solid color or a stripe pattern or something similar to indicate an error, but Blender uses node colors for node categories so it wouldn’t be obvious how to blend the two
Here’s what you’re looking for. Initial entry, at least.
Unfortunately, It is now not possible to build this kind of setup using only internal Geo nodes. You need an external curve for a wire profile.
UPDATE: or! alternatively, you may spread individual wires manually. It would not be very convenient to weave a thick bunch, although, everything you need for that kind of setup is already in Geonodes.
I know it’s less exciting to talk about this than talking about adding new features
are the developers aware of this limitation?
but I’m really wondering how this issue will be tackled in the future?
maybe by adding more options to the object info node?
Thanks for your response
I was indeed waiting for this node for a few months, hoping that it would resolve this limitation
I had also the same intuition
It would be indeed really nice and it seem quite logical too !!
Unfortunately, as confirmed by @HooglyBoogly this separate component node cannot read the “pointcloud” componement from an “instance type” object, because it seems that “instances type” object do not have any point cloud information. Once point instance node is used it seem that the point cloud componement is removed for some reasons (?)
maybe it would be possible to add it to the task?
tbh i don’t get why instances don’t retain their point cloud componement
I think that we can all agree that it’s important to give the users a flexible way to read the instances loc/rot/scale
@slowburn
I tried and it’s partially working but, there’s a problem with this technique,
if you do your instancing is coming from emitter vertices, then there’s no point cloud componement
so is there a way to a mesh type to a pointcloud type?
or a task for this perhaps? perhaps a component convert node in the work?
No, there’s no way to convert vertices directly into a point cloud AFAIK. Maybe developers didn’t see a point to do that. But for interacting between different GN modifiers it would be useful.
TBH there is no need for an specific vertex to points convert node, just a point distribution mode that places one point per vértice, that’s it, or could be part of the actual point distribution node, the one with random or poisson disk
Well for flexibility of course converting vertices to point and points back to vertices seems a no-brainer
Let say you just distributed your point clouds with the scatter node and want use modifiers on your cloud?
well you can’t because point clouds types are not supported by modifiers and other nodes dedicated to meshes…
Vertices and point cloud are extremely tied anyway, to be honest i don’t understand why they go splitted back in 2020
I know that these kind of “details” are boring comparing to working on new features but at some point we need to tackle the workflows incoherencies like this IMHO
But that’s not converting vertex to points, what you want is to convert from one object data type to another, that’s a different thing.
AFAIK that’s not going to happen, at least for now, but I can be wrong.
What you are asking for is that if your output in the modifier is a point cloud, then the object data should turn into a point cloud type, however AFAIK that cannot happen.
What you can do is to create a mesh object and then get the data from the point cloud, that way you will be able to use the mesh modifiers.
I think there’s some misunderstanding here, because mostly everything you can do with points you can also do with mesh vertices. The idea of point clouds is to have a more basic storage for data with none of the complications like edges, faces, etc.
So in any current workflow, converting from mesh vertices directly to points will not get you anything. If you want the id attribute for instancing, just use attribute randomize with id as the result. The result should be the same.
I honestly don’t understand what you’re skeptical about. The point to volume node already does this, and a Point Distribute Volume node will cover the other direction.
What might actually be helpful is a way to generate one point per mesh face, that would be simple to add and possibly a nice improvement.
@JskJ I may have missundertood you, but you want is this:
1.- You create a point cloud object
2.- You create a GN modifier and distribute some point clouds
3.- You create some geometry inside GN from that point cloud
4.- You want to modify that PointCloud object with some other modifier put after the GN modifier
Since PointCloud is an specific data type you cannot add a Subdivision Surface Modifier to that point cloud object.
That does not mean that you cannot use nodes internally in the GN modifier/tree, but in the end you cannot treat that object as a mesh data object because in the end it’s a point cloud data object.
I’m not sure if that’s what they were talking about, but yes : a more “rational” scattering method would be very welcome. I’ve seen people trying to instance objects in regular patterns to make tires, for instance. Of course it’s possible to use the points directly, but more often than not you’ll want to instance the object on the face itself. Same goes for edges, although this is most likely less useful than faces.
OR this could be covered by a loop and some mesh analysis variables… something like “for each edge in mesh, create a point on edge centerpoint and inherit normal”
A nice tool would be something similar to the Component Analyser in Sverchok. Lot’s of super handy analytical outputs that can be use for all sorts of selections and masking like face centres, face areas, boundary edges, edge angle etc. That would give people access to things like face centres but also other data that is invaluable
