Problem
moveSupportVertices qualifies a support vertex with:
thrCount = max 1 (round $ supportThreshold tfCfg / 100 * fromIntegral vertexCount)
where vertexCount is the number of nodes in the spatial group. With the default supportThreshold = 96, a group of n nodes requires round(0.96 * n) connections. But a node can have at most n - 1 connections within its own group, and round(0.96 * n) > n - 1 for every n < 25.
So for any group smaller than 25 nodes, no vertex can ever qualify, no matter how connected it is.
Measured across 3073 vehicle jbeam files extracted from a BeamNG install: 2989 of them (97%) have at least one spatial group under 25 nodes.
The reason this has not been noticed is that support classification currently also happens by name (a name ending in a letter becomes a support vertex regardless of connectivity), which masks the dead threshold path. That name shortcut is tracked separately.
The metric compares two different things
Connection counts span the whole file: a centreline node connects to both the left and right groups. Group size counts only one side. So the check effectively asks "does this node have more connections than there are nodes in its own group", which happens to identify cross-group hubs and systematically misses local ones.
Concretely, from the example files:
| node |
degree |
group size |
ratio |
current verdict |
rl19 (frame, Middle) |
18 |
11 |
164% |
support |
bfsl (fender, Left) |
10 |
12 |
83% |
not support, cannot ever be |
bfsl is connected to 10 of the 11 other nodes on its side. It is unambiguously the hub of that group, and it is unreachable at any group size below 25.
A measure that does not depend on group size
Comparing degree against the group's median degree puts every file on one scale:
frame rl19 18 / median 6 3.00x
frame rl_r48 15 / median 6 2.50x
frame rl_f14 13 / median 6 2.17x
fender bfsl 10 / median 5.5 1.82x
fender bfl6 8 / median 5.5 1.45x <- correctly rejected
frame rl22 10 / median 6.5 1.54x <- correctly rejected
Validated against the files where the answer is known:
frame.jbeam: picks exactly rl19, rl_f14, rl_r48, no extrassuspension.jbeam: picks exactly rl14, rl19, rl48, no extrasfender.jbeam: picks exactly bfsl and bfsr
Across the 3073-file corpus, with a 1.7x cut and triangle-referenced vertices excluded: 1245 vertices total, 0.5 per file, 22% of files get at least one, and only 12 files get more than six. No file has the distribution run away.
Triangles are a necessary but not sufficient condition
Excluding triangle-referenced vertices helps and is already implemented, but it cannot carry the decision alone. On the curated examples the nodes outside triangles are exactly the support nodes, but on real files it is far too permissive: 42% of bluebuck_frame and 46% of burnside_frame sit outside triangles, because a chassis is internal structure by nature. And 12% of files have no triangles section at all, where the filter passes everything.
Problem
moveSupportVerticesqualifies a support vertex with:where
vertexCountis the number of nodes in the spatial group. With the defaultsupportThreshold = 96, a group ofnnodes requiresround(0.96 * n)connections. But a node can have at mostn - 1connections within its own group, andround(0.96 * n) > n - 1for everyn < 25.So for any group smaller than 25 nodes, no vertex can ever qualify, no matter how connected it is.
Measured across 3073 vehicle jbeam files extracted from a BeamNG install: 2989 of them (97%) have at least one spatial group under 25 nodes.
The reason this has not been noticed is that support classification currently also happens by name (a name ending in a letter becomes a support vertex regardless of connectivity), which masks the dead threshold path. That name shortcut is tracked separately.
The metric compares two different things
Connection counts span the whole file: a centreline node connects to both the left and right groups. Group size counts only one side. So the check effectively asks "does this node have more connections than there are nodes in its own group", which happens to identify cross-group hubs and systematically misses local ones.
Concretely, from the example files:
rl19(frame, Middle)bfsl(fender, Left)bfslis connected to 10 of the 11 other nodes on its side. It is unambiguously the hub of that group, and it is unreachable at any group size below 25.A measure that does not depend on group size
Comparing degree against the group's median degree puts every file on one scale:
Validated against the files where the answer is known:
frame.jbeam: picks exactlyrl19,rl_f14,rl_r48, no extrassuspension.jbeam: picks exactlyrl14,rl19,rl48, no extrasfender.jbeam: picks exactlybfslandbfsrAcross the 3073-file corpus, with a 1.7x cut and triangle-referenced vertices excluded: 1245 vertices total, 0.5 per file, 22% of files get at least one, and only 12 files get more than six. No file has the distribution run away.
Triangles are a necessary but not sufficient condition
Excluding triangle-referenced vertices helps and is already implemented, but it cannot carry the decision alone. On the curated examples the nodes outside triangles are exactly the support nodes, but on real files it is far too permissive: 42% of
bluebuck_frameand 46% ofburnside_framesit outside triangles, because a chassis is internal structure by nature. And 12% of files have no triangles section at all, where the filter passes everything.