minemotion/nexel3d

Purpose and Entry Points

This repository appears to implement a browser-based 3D scene editor, with project selection, scene editing, object manipulation, materials, animation, rigging, and rendering.

Primary HTML entry points:

• index.html — main editor shell, bootstrapped by index.js

• projects.html — project-oriented view, bootstrapped by projects.js

• rigTest.html and tester.html — specialized/manual test pages

Application Bootstrap and UI Shell

The main application likely initializes shared editor state, UI panels, and runtime systems from:

• index.js

• interface.js

• styles.css

UI-specific subsystems are separated by editor concern: hierarchy/outliner, themes, translations, and icon assets. This suggests a modular desktop-editor-style interface rather than a server-rendered application.

• outliner.js

• themes.js

• translations.json

Scene and Rendering Boundary

Scene representation and viewport presentation are distinct from rendering implementation:

• scene.js

• sceneView.js

• renderEngine.js

scene.js is the likely authoritative scene/object model. sceneView.js likely adapts that model to an interactive viewport, while renderEngine.js owns graphics rendering. This boundary is central: editing systems mutate scene state, then the viewport/render engine reflects those changes.

Object Selection and Transform Editing

Interactive object editing is organized into separate selection, transform-state, and transform-control layers:

• selectionSystem.js

• transform.js

• transformControls.js

The expected control flow is user input → selection update → transform control interaction → scene object mutation → viewport refresh. Keeping transform math/state separate from controls permits actions, undo/redo, and other editor modes to reuse the same object-editing operations.

Editor Modes, Actions, and History

Commands and mode-specific behavior are isolated from base scene management:

• actions.js

• editMode.js

• undoRedoManager.js

actions.js likely provides high-level editor commands. editMode.js supplies alternate interaction semantics for editing object structure or components. undoRedoManager.js is the transaction/history boundary and should capture scene-changing actions rather than raw UI events.

Asset, Import, and Material Pipeline

The repository includes local model and texture assets plus modules responsible for bringing them into scenes and assigning visual properties:

• import.js

• material.js

• assets/Models/suzanne.obj

• assets/Textures/waterPBR.mp4

Assets are browser-served static resources. Import and material handling form the bridge between external files/media and renderer-specific scene resources. Model fixtures such as assets/Models/bone.obj and assets/Models/camera.obj also support rigging or scene-object workflows.

Animation and Rigging Systems

Animation and skeletal/rig workflows are represented as dedicated systems rather than extensions of generic transforms:

• animate.js

• animationSystem.js

• rigging.js

This likely establishes a pipeline where rig definitions/control structures drive animated transforms over time, with the animation system applying evaluated values to scene entities before rendering. The specialized rigTest.html indicates rigging is a meaningful runtime capability.

Persistence and Project Scope

Project-level behavior and reusable module/state storage are separated from the live editor:

• projects.js

• moduleStorage.js

• projects.html

moduleStorage.js is likely the persistence or in-memory storage abstraction used to retain project/editor data. The application appears fully client-side: no backend, API client, database, or deployment infrastructure is represented in the repository tree. Browser runtime dependencies are implied by JavaScript, HTML, CSS, static assets, and manifest.json.