Repository navigation
fix(conversions): re-center mesh/polyhedron geometry so TransformControls attaches at the visual center - #33
Merged
ericgozzi merged 1 commit intoOct 13, 2026
Conversation
This was referenced Sep 23, 2026
ericgozzi
added this pull request to stack #34
September 23, 2026 06:27
gonzalocasas
approved these changes
Oct 11, 2026
gonzalocasas
left a comment
gonzalocasas
left a comment
Member
There was a problem hiding this comment.
lgtm! although I have to say it's not 100% clear to me which cases are affected by this
Member
|
ahh nevermind, I think i get it :P |
…rols attaches at the visual center mesh.vertices/polyhedron.vertices arrive as absolute world coordinates and get written into the BufferGeometry as-is, so the returned THREE.Mesh's own .position stayed at the world origin no matter where the mesh actually sits. That's invisible for rendering (the geometry itself is already in the right place), but it broke anything reading .position/matrixWorld instead of the geometry - notably TransformControls.attach, which planted the transform gizmo at the world origin instead of the mesh's visual center. Adds centerGeometry(), used by both meshToThreeJS and polyhedronToThreeJS: translates the geometry by -center and sets mesh.position to that center, keeping every rendered vertex at the same world position while giving the object an origin a gizmo (or anything else keyed off object position) finds where the mesh actually is. Adds tests/datastructures.test.ts, covering both conversions. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
ericgozzi
force-pushed
the
fix/center-geometry-transform-controls
branch
from
October 13, 2026 08:52
c5639b4 to
54079dd
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
mesh.vertices/polyhedron.verticesarrive as absolute world coordinates and were written into the BufferGeometry unchanged, so the resultingTHREE.Meshalways had its.positionat the world origin. That renders correctly, but anything that reads.position/matrixWorldbreaks. In particular,TransformControls.attachput the gizmo at the world origin instead of at the mesh.centerGeometry(), used by bothmeshToThreeJSandpolyhedronToThreeJS, moves the geometry by-centerand setsmesh.position = center. Every vertex stays at the same world position, and the object's origin is now at its visual center.Stacked on #32; merge that first. Backend counterpart: compas-dev/compas_threejs#59 (scale-mode
object_transformpivot fix).Test plan
tests/datastructures.test.ts(both conversions)🤖 Generated with Claude Code