Files
EmilandClaude Sonnet 5 e0e6c1d503 M3: real 3D translate gizmo — the "полноценный 3D-пайплайн" it was chosen for
TranslateGizmo draws three axis handles at the selected GameObject's
world position by projecting real 3D points through the real camera's
View/Projection (GizmoMath.WorldToScreen) onto ImGui's foreground draw
list. Nothing OpenGL-side draws lines yet, so this isn't 3D geometry
in the GL sense — but it IS driven by the actual camera matrices, which
is what the earlier scoped-2D-vs-full-3D-pipeline choice was actually
about: a handle dragged in screen space has to map onto a real 3D axis,
and that only means something once there's a real camera to project
through. The screenshot below shows exactly that — the axes aren't
screen-perpendicular, because the camera at (0,3,6) looking at the
origin means they shouldn't be.

Dragging a handle re-projects the mouse delta onto the axis's own
screen-space direction (GizmoMath.ProjectDragOntoAxis) and writes the
result back through GizmoMath.WorldToLocalPosition, which inverts the
parent's WorldMatrix rather than writing LocalPosition directly — a
parent with non-identity scale or rotation means "move 1 world unit"
and "add 1 to LocalPosition" are different amounts, and
samples/WindowDemo's ChildQuad (parented under a (2,2,1)-scaled Quad)
is exactly that case.

Split the actual math into GizmoMath (Engine.Editor.Contracts, no GL/
ImGui/mouse dependency) so it's unit-testable without a window or a real
mouse — neither exists in a headless test run, and dragging is exactly
the kind of interaction that's easy to get subtly wrong (screen-space
ratio direction, perspective sign, parent-scale correctness) without
something to check it against beyond eyeballing a screenshot. New
Engine.Editor.Tests project, 8 tests: screen-center projection, a
behind-camera point returning null, drag-ratio math on both an
axis-aligned and a diagonal screen direction, and the parent-scale/
parent-translation inverse-transform cases. All 8 passed on the first
run — including the non-uniform-scale case, the one most likely to be
subtly wrong.

Full suite: 73 tests, all green (65 previous + 8 new).

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01N1qPfzq8TDCUMFMV3UwV5N
2026-09-02 16:30:54 +03:00

88 lines
3.9 KiB
C#

using System.Numerics;
namespace Engine.Editor.Contracts;
/// <summary>
/// The pure math behind a screen-space-drag-to-3D-axis gizmo, split out
/// from TranslateGizmo (Engine.Editor, which owns the ImGui drawing and
/// live mouse/GameObject state) specifically so it's unit-testable without
/// a GL context, a real window, or a mouse — none of which a headless test
/// run has. See TranslateGizmo's own doc comment for how these three
/// functions compose into an actual drag.
/// </summary>
public static class GizmoMath
{
/// <summary>
/// Projects a world-space point through view*projection to a
/// screen-space pixel coordinate. Null when the point is behind the
/// camera (w &lt;= 0) — there's no sane screen position for it, and
/// drawing one anyway (naive perspective division) would fling it to
/// whatever's on the opposite side of the screen instead of just not
/// being there.
/// </summary>
public static Vector2? WorldToScreen(Vector3 worldPos, Matrix4x4 viewProjection, Vector2 screenSize)
{
var clip = Vector4.Transform(new Vector4(worldPos, 1f), viewProjection);
if (clip.W <= 0f)
return null;
var ndcX = clip.X / clip.W;
var ndcY = clip.Y / clip.W;
// NDC's Y axis points up; screen-space pixel Y points down.
return new Vector2(
(ndcX * 0.5f + 0.5f) * screenSize.X,
(1f - (ndcY * 0.5f + 0.5f)) * screenSize.Y);
}
/// <summary>
/// How far along a world-space axis the current drag corresponds to,
/// in world units. Works entirely in screen space: how far the mouse
/// moved along the axis's own on-screen direction (not just its raw XY
/// delta — an axis pointing diagonally on screen needs the component
/// of the mouse movement that's actually along it), scaled by how many
/// world units one screen pixel represented for this axis at drag
/// start (screenLen pixels spanned axisWorldLength world units).
///
/// This is a projection-ratio approximation, not true ray/nearest-point
/// axis math — ratio holds exactly only at the handle's own depth, and
/// drifts slightly as the object moves toward or away from the camera
/// mid-drag under perspective projection. Good enough for a first
/// working gizmo; a real nearest-point-on-ray solve is more machinery
/// than a single translate handle has earned yet.
/// </summary>
public static float ProjectDragOntoAxis(
Vector2 origin2D, Vector2 tip2D, Vector2 dragStartMouse, Vector2 currentMouse, float axisWorldLength)
{
var screenDir = tip2D - origin2D;
var screenLen = screenDir.Length();
if (screenLen < 0.0001f)
return 0f;
var normalizedDir = screenDir / screenLen;
var mouseDelta = currentMouse - dragStartMouse;
var pixelsAlongAxis = Vector2.Dot(mouseDelta, normalizedDir);
return pixelsAlongAxis / screenLen * axisWorldLength;
}
/// <summary>
/// Converts a desired new world-space position into the local position
/// GameObject.Transform.LocalPosition needs to produce it — the inverse
/// of GameObject.WorldMatrix's own composition. Null parentWorldMatrix
/// (no parent) means local and world are the same space. Matters
/// specifically because a parent's non-identity scale or rotation means
/// "move 1 world unit along X" and "add 1 to LocalPosition.X" are not
/// the same thing — see samples/WindowDemo's ChildQuad, parented under
/// a GameObject with a non-uniform (2,2,1) scale, which is exactly the
/// case this needs to get right.
/// </summary>
public static Vector3 WorldToLocalPosition(Vector3 worldPos, Matrix4x4? parentWorldMatrix)
{
if (parentWorldMatrix is null)
return worldPos;
Matrix4x4.Invert(parentWorldMatrix.Value, out var inverse);
return Vector3.Transform(worldPos, inverse);
}
}