Skip to content

add shapes overlay#693

Open
DTCurrie wants to merge 2 commits into
mainfrom
app-16292-add-shapes-overlay
Open

add shapes overlay#693
DTCurrie wants to merge 2 commits into
mainfrom
app-16292-add-shapes-overlay

Conversation

@DTCurrie
Copy link
Copy Markdown
Member

@DTCurrie DTCurrie commented May 19, 2026

Note: Quickly put this together to support the education training effort. Open to suggestions/commits on this. It replaces the old = hotkey.

Adds an "Add Shape" dashboard button to allow creating simple geometries. Also adds color and visibility controls to the details panel.

As a follow-up, I am going to look into splitting up the detail panel into tabs, it is getting overloaded and we will want space for controls soon.

Screenshot 2026-05-20 at 10 19 44 AM Screenshot 2026-05-20 at 10 19 57 AM Screenshot 2026-05-20 at 10 20 09 AM Screenshot 2026-05-20 at 10 20 24 AM

@changeset-bot
Copy link
Copy Markdown

changeset-bot Bot commented May 19, 2026

🦋 Changeset detected

Latest commit: 403e238

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package
Name Type
@viamrobotics/motion-tools Minor

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

@github-actions
Copy link
Copy Markdown
Contributor

github-actions Bot commented May 19, 2026

PR Preview Action v1.8.1

QR code for preview link

🚀 View preview at
https://viamrobotics.github.io/visualization/pr-preview/pr-693/

Built to branch gh-pages at 2026-05-19 21:52 UTC.
Preview will be ready when the GitHub Pages deployment is complete.

@DTCurrie DTCurrie requested review from mattmacf98 and micheal-parks and removed request for micheal-parks May 20, 2026 14:21
{/if}

<div aria-label="mutable visibility">
<Checkbox
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why are we adding a checkbox for invisibility? Doesn't this duplicate the Treeview invisibility button?

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

consistency with other metadata rendering values, and just discoverability.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is that really a problem though? I worry that we're inventing the problem here - no one that I've talked to has reported the eye buttons on the tree to not be discoverable

}
})

keys.onKeys('-', () => {
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd maybe leave this out until we have undo keybindings + modal, the trash button works and this could cause confusion

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

we can, this was just to not lose the existing behavior for custom geos that were added with the =/+ key

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, but this expands niche behavior to something that encompasses all delete-ables

* changes in EditedMatrix and round-trip through the robot config; local
* Removable entities write directly to Matrix and skip the config call.
*/
const getEditTarget = (entity: Entity) => {
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These file edits concern me a lot. I don't like how entangled this is getting. I'm working on a PR that extracts all of frame editing into a plugin, and I was going to have completely separate pathway for editing local entities. Coupling them like this seems very risky for stability.

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

oh yeah, and to @mattmacf98 comment this was just a quick way to get this stubbed in and working based off the old geos, but I think they should be separate

const box = useTrait(() => entity, traits.Box)
const capsule = useTrait(() => entity, traits.Capsule)
const sphere = useTrait(() => entity, traits.Sphere)
const plane = useTrait(() => entity, traits.Plane)
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: a little iffy about adding planes as a geo type since it is not a viam supported one and people may be confused why they can set geo to a plane for this flow but not for frame geos

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yeah as mentioned I would probably separate this from the frame editing stuff in general this was just a quick way to get something useable to test out.

{@const edgesGeometry = box.current ? unitBoxEdges : unitSphereEdges}
{#if box.current || sphere.current || plane.current}
{@const meshGeometry = box.current ? unitBox : sphere.current ? unitSphere : unitPlane}
{@const edgesGeometry = box.current
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: is this enough nested ternaries to warrant a helper func?

{ value: 'frame', label: 'Frame', icon: Axis3d },
]

let counters = $state<Record<ShapeKind, number>>({
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

do we decrement this on remove? if not maybe we should rename this to shapeIds so people don't mistake this as a true count of the number of them in the scene

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

not sure it matters too much, but we can. its just to avoid name collisions since these should just be temporary entities. I don't if poeple will care to much since they aren't persisted

if (!trimmed) return

const entity = spawners[kind](world)
entity.set(traits.Name, trimmed)
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

is this not already handled in the baseTraits in the spawner?

const baseTraits = (kind: ShapeKind) => [
	traits.Name(`custom ${kind} ${++counters[kind]}`),
	traits.Matrix,
	traits.Removable,
	traits.Transformable,
]

could the source of truth ids just be in there instead?

const tempPose = createPose()

/**
* Picks the matrix trait to edit. Config-backed frames (with FramesAPI) stage
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this expands the responsibility of the FrameConfigUpdater.svelte.ts‎ too much (it now deals with frame updates and the custom geo ones)

I think it would be good to create a new updater to just handle the custom geo stuff and use that when the focused entity is a custom geo and then we can leave this file alone to just deal with frames

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants