Curve and Mesh Topology Inputs #100020
Labels
No Label
Interest
Alembic
Interest
Animation & Rigging
Interest
Asset Browser
Interest
Asset Browser Project Overview
Interest
Audio
Interest
Automated Testing
Interest
Blender Asset Bundle
Interest
BlendFile
Interest
Collada
Interest
Compatibility
Interest
Compositing
Interest
Core
Interest
Cycles
Interest
Dependency Graph
Interest
Development Management
Interest
EEVEE
Interest
EEVEE & Viewport
Interest
Freestyle
Interest
Geometry Nodes
Interest
Grease Pencil
Interest
ID Management
Interest
Images & Movies
Interest
Import Export
Interest
Line Art
Interest
Masking
Interest
Metal
Interest
Modeling
Interest
Modifiers
Interest
Motion Tracking
Interest
Nodes & Physics
Interest
OpenGL
Interest
Overlay
Interest
Overrides
Interest
Performance
Interest
Physics
Interest
Pipeline, Assets & IO
Interest
Platforms, Builds & Tests
Interest
Python API
Interest
Render & Cycles
Interest
Render Pipeline
Interest
Sculpt, Paint & Texture
Interest
Text Editor
Interest
Translations
Interest
Triaging
Interest
Undo
Interest
USD
Interest
User Interface
Interest
UV Editing
Interest
VFX & Video
Interest
Video Sequencer
Interest
Virtual Reality
Interest
Vulkan
Interest
Wayland
Interest
Workbench
Interest: X11
Legacy
Blender 2.8 Project
Legacy
Milestone 1: Basic, Local Asset Browser
Legacy
OpenGL Error
Meta
Good First Issue
Meta
Papercut
Meta
Retrospective
Meta
Security
Module
Animation & Rigging
Module
Core
Module
Development Management
Module
EEVEE & Viewport
Module
Grease Pencil
Module
Modeling
Module
Nodes & Physics
Module
Pipeline, Assets & IO
Module
Platforms, Builds & Tests
Module
Python API
Module
Render & Cycles
Module
Sculpt, Paint & Texture
Module
Triaging
Module
User Interface
Module
VFX & Video
Platform
FreeBSD
Platform
Linux
Platform
macOS
Platform
Windows
Priority
High
Priority
Low
Priority
Normal
Priority
Unbreak Now!
Status
Archived
Status
Confirmed
Status
Duplicate
Status
Needs Info from Developers
Status
Needs Information from User
Status
Needs Triage
Status
Resolved
Type
Bug
Type
Design
Type
Known Issue
Type
Patch
Type
Report
Type
To Do
No Milestone
No project
No Assignees
8 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: blender/blender#100020
Loading…
Reference in New Issue
No description provided.
Delete Branch "%!s(<nil>)"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
This is a WIP design for a more complete set of topology inputs for curves and meshes (point clouds, volumes and instances don't need nodes like that).
Goals:
Challenges:
Feel free to use the .blend file below for more mockups.
topology_lookup_mockups.blend
Added subscriber: @JacquesLucke
Changed status from 'Needs Triage' to: 'Confirmed'
Added subscribers: @HooglyBoogly, @mod_moder, @guitargeek
(Related to the topic of multiple context for transfer nodes)
https://devtalk.blender.org/t/access-to-geometry-data/24618/7
Edit:
For example, face-face connection:
No. That would make them unusable in fields. Also when chaining these nodes, it's very likely that all the nodes should work in the same geometry. It's possible to wrap these nodes with e.g. a Transfer Attribute or Capture Attribute node, to create the kind of node that you want.
I'm not generally against creating e.g. a Point Cloud just as a wrapper for multiple arrays, but it does not seem necessary for the kinds of topology inputs I'm targeting now. That also wouldn't make them easier, and make them impossible to use in a reusable field.
Might be worth to wait for lists sockets instead of having nodes that output a point cloud as a list alternative.
In total, this data has an arbitrary size. Because of this, use in the field will have the character
Since it will be very difficult to duplicate domains in one field and analyze their topology
From the beginning, the Face Contain node (or later renamed the Mesh Contain Connection) was made to be a field only. After several tests, it became clear that these are not suitable for use for the reasons described above.
Well, obviously it depends on what you want to do. Whenever, you want to work with a variable number of elements, a workaround will be necessary currently. We shouldn't force people to use these workarounds for simpler tasks like "get the left-most vertex of the current face" though. My impression right now is that the nodes that you propose could be build out of these smaller nodes in my proposal (but not the other way around).
Your nodes implement link lookup functions. But they have the limitations of the current node system in terms of variable data size.
For example: if we want to create instances and transform them in the right way: points are more convenient, they are easier to copy.
Also, after several tests, I caught myself thinking that the main functionality of this comes down to spawning intans between neighbors in the right way. And also, yes, data transfer between its neighbors is relevant.
+Edit:
I'm not sure if this is accepted, but for users, groups (accumulate, sort in group, ...) are the primary solution for getting around restrictions on arbitrary size data. From this point of view, these knots do not give freedom
Here is an example for how to get a list of all face neighbor pairs (encoded as point cloud attributes). This is just to show that it is possible.(turns out that doesn't actually work this way)But if there is a list design (which will be added, not left as a potential feature) that may appear soon and extend the general functionality of the nodes, then I think this will be solved.
This node system has one bug: This node has no neighbor data, as it will be evaluated for the point cloud.
Or the data that is included in it will not be relevant for the mesh. Or are you talking about combining mesh and point cloud in the same geometry as {mesh, array}?
Yes, lists can make some use cases significantly simpler. I'm not arguing with that. But even with lists, for some use cases the nodes proposed in the initial post are likely to be more efficient and simpler to use. Also note that we might be talking about lists in different contexts right now. Lists should be supported in within and outside of a field context.
Anyway, this task is not about adding support for lists.
You're right. Fixed my comment.
I played with the mockups for a while to see if I could build some of the lookups out of others, and to experiment with the naming.
I think it's helpful to use some chart like this that shows how to find neighboring elements of each type.
Sometimes it's not so bad to build lookups from others. For example, "Vertex to Face", "Face to Vertex" and "Face to Edge" are pretty intuitive.
The others less so, but I could see that kind of flexibility being helpful anyway. I sort of got the point after a while, do I didn't do the last few.
I think this is helpful anyway, to see which of this set of nodes are the most important.
"Face to Corner", "Corner to Vertex", "Corner to Edge", "Corner to Corner", "Vertex to Edge", and "Vertex to Corner" are probably the most important.
topology_lookup_mockups.blend
Added subscriber: @ikakupa
All of these nodes must be calculated with 2 separate mechanisms:
General topology processing, returning a single
GVectorArray
. Most algorithms come down toBecause of this, the use of multifunctions is not possible.
Evaluating all this in its context means that the data can only be used by the domain owner. Therefore, as long as there are no lists, it will be very difficult for the user to use such data, given its arbitrary size.
This is the reason for this option:
Geometry input, return
GVectorArray
connections.Entering sampling indexes and numbers, returning values.
Disregarding sorting, the usage looks like this: The node compiles the topology analysis and returns a sampling multifunction.
Now sorting. If a vertex wants to get neighbors, how to sort them? By number. Okay, what's the geometric meaning? If we enter a sorting context that has a vertex index and a neighbor index, then the user can more meaningfully return weight for sort. But, is such a complex sorting mechanism necessary?
Naturally, in this design, this sort should receive a
GVectorArray
of neighbors, and return aGVectorArray
of weights. In this case, it can be considered as a separate node for working with lists, temporarily embedded in the nodes of the topology.Also, separate:
Vertices belonging to the polygon.
Vertices connected to the polygon through edges
Vertices connected from polygons through adjacent polygons
And
Index (global number) and Number (neighbor number, valid only for enumeration) In order not to create confusion about what 2 polygon indices are for when iterating over adjacent polygons
Added subscriber: @howardt
I'm curious as to what the implementation idea is for each of these. For those that require going through whole Mesh arrays (e.g., Vertex to Edge requires going through all MEdge's), how might this be more efficient than doing that? Seems like a tradeoff between (a) just iterate through the arrays as needed; (b) caching geometry node results; (c) carrying along some general topology structure with geometry (a la BMesh), which is I guess a different form of caching.
I'd imagine it as a combination of the three. Caching some basic topology mappings on mesh could help a lot. It's nice that we can build some mappings out of others.
Calculating some topology data lazily is a potential way to amortize the cost of iterating over all mesh elements. Combined with generalized node caching, we should be able to reuse those geometry-owned caches much more.
Added subscriber: @GeorgiaPacific
This issue was referenced by
8a6dc0fac7
This issue was referenced by
482d431bb6
Added subscriber: @AgentA1cr
I'm not sure how the Edge To Corner/Face groups that you built are meant to function, but in my testing, they provide no guarantee that the Corner or Face returned is adjacent to the Edge in question, rather than merely sharing a vertex. Am I doing something wrong here?
Just checking in on the Edge to Face/Edge to Corner issue
They probably don't work. I was just messing around with nodes to try to get an idea of what was possible, I hardly tested any of those setups. I'll bet there's another way to do it though.
I've messed with it a fair bit and haven't found anything reliable thus far. I can think of a brute-force approach that would work if you know the maximum numbers of edges per face and edges per vertex, but nothing that would work for an arbitrary number of either.
Interesting, I could see why. All this stuff is difficult until we have proper list fields. Maybe we should add a "Faces of Edge" node though, that would make it easier, and it's also a common topological query.
Yeah, that would definitely be useful, and should make corners fairly straightforward to access as well.