Thanks Eary. I should give Alpha 3.0 build a new try keeping the latest advice in mind. Eventually things will “click” again for me.
Hello,
I’ve tried a little the Fields in the latest alpha, I really like the direction it’s moving.
But I’m still struggling with some common workflows. For example:
Here, I’m trying to connect the points of one Grid with the points of another Grid. Is there a way to achieve this right now?
Without explicit lists that I could link together, the Position fields don’t know they belong to their corresponding geometries.
I am not sure which is the best solution for this, but I feel the Fields could offer both an easy, efficient workflow but also have the tools to explicitly access and transfer data when the situation needs it. They could be offering some more advanced nodes for these workflows.
1 Like
Wouldn’t you achieve the same by generating points from one of those grids and then instancing your line on the positions of those points? I suppose your end goal is to have grid of vertical lines?
The geometries are placeholders, this is an example to figure out the weaknesses and limitations of the current system.
Here is an example of how this could be handled in a more explicit way.
I am not suggesting this is the best solution, but trying to find some options to consider and brainstorm.
-
I added a parameter in the Field node to define the source of the data. This could be Automatic, or explicit by choosing a specific geometry source.
This could also allow to connect the data to other geometries, and apply math or remap them when doing so. -
Added Index input ports on the Attribute Get nodes so we can explicitly fetch attributes
-
Added a Create Line node where an index defines explicitly the amount of lines that will be created.
Why though? The fields is in such early state that it’s hard to tell the weaknesses at this point. I mean there’s nothing wrong with that, but it’d make sense to look for them using a specific use case, such as “there is no way to achieve this X result I am after”.
In your latter post, what you are trying to achieve makes more sense, but I still don’t think it can’t be currently achieved because it’s not been thought of, but just because how early stage of development fields currently are in.
I’d be very surprised if instantiating curves where their start positions are derived from the points of one objects and their end positions from the points of another object would not be supported.
3 Likes
I know it’s early, that’s why I’m trying to provide feedback. Maybe it has been thought of, but I’m not aware of a proposal for this. We’re invited to give our perspectives on what works and what doesn’t, and there have already been significant design changes that make the nodes more flexible and more intuitive.
This is essentially an example of having two different lists of data and wanting to connect them, I’m not after a one-trick pony solution for this, but rather a more controlled way of accessing data.
I honestly don’t know what you are trying to achieve, but this does not look like a field node tree.
Field’s don’t have source data, they are “commands” sent to the green headed nodes to tell them what to do with the data, the field nodes themselves don’t have geometry data from any source geometry.
Why do you need the index to fetch attributes? If you want a certain index I am pretty sure the method is to use float compare node after the index node.
I don’t think this is how it works, the index node is a field with no source geometry, it doesn’t just tell the Mesh Line node how many points to generate.
1 Like
imho
+1
getting attribute explicitly like this is the way to go
It should be clear where the attribute is coming from
no guessing.
the implicit input design make everything much less readable and more complicated
1 Like
I’d be happy to clarify if you could specify what isn’t clear.
Because you need to synchronize the Start and End values from two different geometry sources, for each line segment. This is iterating both lists of positions, and by providing the same Index in both, you can ensure that the values are synchronized.
In the master branch, there is a “Curve Parameter->Factor” node. It is very generic. Does it have a hidden meaning, or is it kind of template to implement an input for “tilt” or “radius”?
It creates a gradient of the points on a spline from the start and end, much like a special index. it can be used for many things such as taper, change instance id/size, among other useful applications.
1 Like
This sounds like topology mapping for the old attribute transfer node, it’s still unclear how attribute transfer will be done in field workflow but I think it’s planned.
It’s more general, not parts. What result output do you expect to see? A single straight line? Then what about all those points on the grid? Each point of grid has a position, while the straight line can only have two ends.
Or do you expect the line to deform to fit the topology of the two grids (since you wanted to transfer position with topology mapping)? Then it’s even more abstract. I just cannot really imagine what would be ouputted by the node tree in the screenshot.
I was trying to connect each point of a geometry (Grid A) to each corresponding point of another geometry (Grid B) by creating multiple lines:
Hi Orestiskon,
By using the latest implementation of fields, I can think of one way where you can connect all the points of one grid to all the corresponding points of the other grid by using the “Convex Hull” node.
Here’s the full node graph.
4 Likes
I don’t think that’s what he’s after. You’ve connected only the points of the boundary edges, and your result is a closed mesh, not two grids connected by curves.
3 Likes
Fields are not designed for generating or modifying mesh topology, that’s simply out of scope as far as I know. They generate and modify attributes on an existing mesh topology.
That means you can’t somehow join or connect two meshes through fields. Any node that does that would take two mesh geometries as input, not two fields.
Hello guys!
Will it be possible to instance modified geometry from the node tree like before?
Can we expect point instancing functionalities coming anytime soon to alpha?
Hi, thanks for your effort on making the example. But it’s like Ludvik said, it’s not the same, this is making a hull around the objects instead of connecting each point. It’s a useful node in itself but the idea is to have the ability to be precise when using the data.
Hi there,
in my mockup I’m reading the indices of one geometry as a common index to iterate through all attribute lists and add entries to a spline list, I’m not sure if that’s the same as generating/modifying topology.
It would be interesting to discuss what other ways are there to tackle this problem. What if the user wanted to connect every point of one mesh with every second point of the other mesh for example? How could they tackle these situations?
Hi, as far as I can tell they’re working on porting the previous nodes to fields.
It is being worked on, The Point Instance node is now called Instance on Points node, and the Geometry mode would be the only mode left since you can always just use Object Info and Collection info
2 Likes