Conversation
…xternal integration
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
…gement" This reverts commit 21d41dd.
…tness and viewer layout - Enhance mesh/texture path normalization with known asset root detection - Add MJCF eigenvalue-based inertia validation and balanceinertia compiler flag - Add SDF synthetic root omission and unique model child name resolution - Refactor URDF geometry generation with capsule compatibility fallback - Add assembly root component selection availability resolution - Fix viewer container stacking context and overflow handling - Improve highlight manager, hover interaction and screen-space helpers Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
…e directly Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
…bridge patterns - Add shared workerPoolClient to reduce duplicated worker bridge boilerplate across collada/obj/stl loaders, project archive, usd export and prepared export cache bridges - Consolidate material creation into materials.ts and urdfMaterials.ts, remove materialFactory.ts and promiseRejectionGuard utilities - Improve URDF generator robustness and xacro parser edge cases - Add material protection utility for Three.js resource lifecycle - Enhance visualization factories and object sync for better scene management - Update MJCF geometry/hierarchy builder for improved parsing accuracy - Add layout actions for AI tools and UI store enhancements Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
There was a problem hiding this comment.
Code Review
This pull request refactors the application layout and state management, unifying robot design and visualization capabilities under a single Editor mode and introducing an AI Conversation feature. Key updates include the implementation of a popup handoff protocol for imports, the addition of extension slots for external integrations, and the modularization of complex hooks into specialized sub-hooks. The Visualizer and URDF Viewer components are now integrated within the Editor domain. Feedback suggests improving the assembly naming logic during auto-seeding by deriving names from the imported archive filename rather than the potentially stale robot state.
|
|
||
| if (canSeedAssembly) { | ||
| if (shouldAutoSeedArchiveAssembly) { | ||
| assemblyStoreState.initAssembly(robotState.name || 'my_project'); |
There was a problem hiding this comment.
When auto-seeding an assembly from an imported archive, the assembly name should ideally be derived from the archive filename rather than the current (possibly default) robot name. Using robotState.name here might result in the assembly being named 'robot' if it's the first import in a session, as the store hasn't been updated with the new robot data yet. This also applies to the initAssembly call on line 554.
const assemblyName = inputFiles[0].name.replace(/\.[^/.]+$/, '');
assemblyStoreState.initAssembly(assemblyName);| } | ||
| }); | ||
| markUnsavedChangesBaselineSaved('assembly'); | ||
| } else if (canSeedAssembly) { |
There was a problem hiding this comment.
No description provided.