- 
                Notifications
    
You must be signed in to change notification settings  - Fork 0
 
Description
What is transformation?
Transformation is everything in the codebase that aint Formatting and Parsing, for example sorting vertices and moving them to correct tree type. This code is as of writing this marked/experimental unstable in the master branch and will probably be for a while since I have many breaking changes planned and there are no unit tests since a upcoming refactoring could cause me to remove some of the unit tests. I plan to add unit tests whenever the codebase stabilizes.
How does transformation work?
You’ve got a raw data structure (Node) that describes vertices and beams (kind of like a messy blueprint). The goal is to clean it up, reorganize the vertices, and rename them consistently.
Here’s how the modules work together:
SupportVertex
- Scans the "beams" section.
 - Counts how many connections each vertex has.
 - Produces a map of vertex → connection count.
 - This helps later to spot support vertices (the ones holding stuff up).
 
VertexExtraction
- Digs into the "nodes" section.
 - Reads raw vertices, pulls out metadata and comments.
 - Groups them into a VertexForest (trees like Left, Middle, Right, Support).
 - Handles global vs. local metadata so values aren’t duplicated.
 
Transformation
- Takes the VertexForest + the connection map from SupportVertex
 - Decides where each vertex belongs (Left/Middle/Right/Support).
 - Sorts them in order, groups them by prefix, and renames them with consistent IDs (l1, m2, r3…).
 - Rewrites the whole Node tree with the updated vertices.
 - Updates all other references to these vertices so names stay in sync.
 
End result
The input data becomes a neat structure:
- Vertices are in the right groups.
 - Support vertices are identified and placed correctly.
 - Metadata is cleanly separated into global vs. local.
 - Names are consistent and collisions are avoided.
 
Basically, the system turns raw vertex + beam data into a well-organized, fully updated node tree ready for further use.
Previous changes
- Transformation reimplemenation: before errors were handled less safely and meta groups interrupting vertex groups was not supported Reimplement transformation, handle Meta Nodes interrupting vertex grouping #2
 - Transformation refactoring: split Transformation into different files and added improved how comments and metadata is handled when moving vertices Transformation.hs refactoring #41
 - Sorting threshold: support for configuring a threshold which decides when two Y values are too close and compare Z values instead feat(transformation): z-sorting threshold via YAML config #38
 - Prefix replacement: added a argument which can provide replacement values for the vertex prefixes Prefix replacement from cli arguments #50
 - Support vertex detextion: implemented detection of support vertices and automatically moving them to their own tree Support vertex detection #52
 - Associate comments without newline before with prior node Associate comments without newline before with prior node #56
 
Remaining problems as of September 2025
Better support vertex detection:
Currently this is how vertices are detected:
  let annVertexCount = round $ supThr * fromIntegral (length annnotatedVertices) / 100
      isSupportVertex' v = any (>= annVertexCount) $ M.lookup (vName . aVertex $ v) conns
      (supportVertices, nonSupportVertices) = partition isSupportVertex' annnotatedVerticesSo basically it works like this:
- Calculate how many vertices there are
 - Multiply by supThr, by default 97
 - Dvivide by 100 and save the value as annVertexCount
 - Determine if the amount of connections for the vertex in the whole mesh are higher than annVertexCount
 
Ideally it should instead work like something like this:
- Count direct connections: For each vertex in the VertexTree, count how many direct connections (edges) it has to other vertices.
 - Compute the threshold: Determine a threshold based on a percentage of the total number of vertices in the VertexTree. Only vertices whose number of direct connections exceeds this threshold are considered potential support vertices.
 - Identify potential support vertices: A vertex with many direct connections, especially when the vertices it connects to themselves have relatively few connections back. likely serves as a support vertex.
 
In other words, vertices that act as hubs, with a high proportion of connections relative to the size of the VertexTree, are more likely to be support vertices.
Better comment handling:
      [    "id",   "posX",   "posY",   "posZ"],
      {"frictionCoef" : 0.7},
      {"nodeMaterial" : "|NM_METAL"},
      // Left side
      {"collision" : true},
      {"group" : "cot_fender_l"},
      {"nodeWeight" : 0.65},
      {"selfCollision" : true},
      [  "bfl0",    0.948,   -1.435,    0.730],
      [  "bfl1",    0.756,   -1.413,    0.843],
      [  "bfl2",    0.963,   -1.024,    0.112],
      [  "bfl3",    0.964,   -1.072,    0.507],
      [  "bfl4",    0.778,   -1.008,    0.873],
      [  "bfl5",    0.987,   -0.743,    0.109],
      [  "bfl6",    0.987,   -0.744,    0.494],
      [  "bfl7",    0.812,   -0.759,    0.896],
      // prefix group vfl
      [  "vfl0",    0.739,   -1.845,    0.716],
      [  "vfl1",    0.959,   -1.762,    0.576],
      [  "vfl2",    0.855,   -1.788,    0.707],Currently, when multiple VertexTrees are combined, such as when there are multiple vertex prefixes for a single VertexTree type, a comment is added to indicate the combination. However, comments that appear at the top of some of the individual VertexTrees may be lost during this process and not preserved in the final combined VertexTree. This will be fixed.

