Import Oxide engine (Stages 0–10) under MIT license

Full project snapshot migrated to new Gitea remote without history:
engine, editor, physics, script, examples, tests, docs, and assets.
Relicensed from GPLv3 to MIT and updated repo URLs.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

CLAUDE.md

@@ -0,0 +1,160 @@
+# Oxide Engine — Claude Code Context
+
+## Project Overview
+
+**Oxide** is a general-purpose 3D game engine written in Rust. It is built to make **any** 3D game,
+scaling from stylized low-poly (e.g. with a VCR/CRT post filter) to realistic graphics, and to **ship
+only what each game uses**. It ships with an **in-engine editor** (`oxide-editor`) developed alongside
+the engine and gaining capabilities at each stage.
+
+The work is split into two phases (see `PLAN.md`):
+- **Phase 1 — general-purpose engine (Stages 0–16):** everything needed to build *and export* any
+  game. Stage 16 (game export to Linux + Windows) is the milestone.
+- **Phase 2 — built-in modules (Stages 17+):** optional, self-contained capabilities (ray-traced
+  audio, developer console, procedural toolkit, terrain, open world, pathfinding/AI, water), each a
+  feature-gated **module** built on Phase-1 systems.
+
+Simulation, open world, and procedural generation are **capabilities the engine supports through
+modules**, not design drivers. The guiding idea is **build tools, not games**.
+
+### Core Feature Goals (Phase 1 — the general-purpose engine)
+- Scene graph and entity management
+- **Engine core framework**: a **module/plugin system** (compile-time feature-gated crates + a
+  runtime `Module` trait + `rhai` script modules), system scheduling, a **layers & tags** system
+  (`LayerMask` for physics/render/query filtering + gameplay tags), a central **asset server** with
+  handles, a **reflection/type registry**, and a **data-driven render pass pipeline**
+- **Editor framework & project system**: top menu, dockable panels, undo/redo command stack, a
+  **module→editor extension API** (modules add panels/menus/tools/inspectors), a **settings/
+  preferences framework** (engine + editor + per-module settings, enable/disable modules), and a
+  **project system** (create/open/save projects, file watching)
+- **Comprehensive input mapping**: map any key to press/up/down, *and* named remappable actions
+  (e.g. a `Jump` action defaulting to `Space` that game code references by name while players rebind
+  the physical key in settings)
+- **Comprehensive in-game UI system**: widgets, layout, theming, text, and input routing that ship
+  inside exported games (distinct from the editor's `egui`); UI documents are serializable and
+  dual-editable, authored in a visual editor canvas
+- **Comprehensive** physics simulation (`rapier3d`: colliders, joints, scene queries, sensors,
+  layer-filtered collision/triggers, kinematic character controller — not a thin wrapper)
+- **Scripting + live reload + in-editor terminal**: game scripts are watched and hot-reloaded; the
+  editor hosts a terminal that can run tools and AI agents which edit game code live
+- Animation system · particle engine · shader support (simple → advanced, scalable fidelity)
+- **Standard audio**: mixer/spatial system (ray-traced spatial sound is a Phase-2 module)
+- **Dual-editable types**: every engine object/component type (`Transform`, `Script`, materials,
+  colliders, …) is editable from both the editor UI and from scripts/code via one reflected/
+  serializable representation, so any editor or AI agent can author game code and data in real time
+- Built-in content kit (prototyping primitives, shaders, character controller) for fast starts
+- **Game export** to standalone Linux + Windows binaries (ships only the modules a project uses)
+- **In-engine editor** (first-class; not an afterthought)
+
+### Built-in Modules (Phase 2 — optional, feature-gated)
+- Ray-traced spatial audio (wave propagation, occlusion, reverb)
+- Developer console & cheats (drop-in dev interface; compiled out of release)
+- Procedural toolkit (noise + composable modifier stack — tools, not a fixed world generator)
+- Terrain system (generate, sculpt, paint splat layers, scatter foliage/objects)
+- Open world support (streaming, LOD, chunking)
+- Pathfinding & NPC AI (navmesh, agents, behavior trees/state machines, perception)
+- Water (rendering + buoyancy/swim/flow mechanics)
+
+Anyone can write a module; each ships docs for **both** using it **and** authoring one.
+
+### Platform & Targets
+- **Linux is the primary platform, on both Wayland and Xorg (X11)** — keep both backends working at
+  every stage (`winit` `wayland` + `x11` features).
+- **Windows support is added later**, once the engine is substantial; avoid Linux-only assumptions.
+- **Game export targets both Linux and Windows** standalone binaries (editor runs on Linux and can
+  cross-export). See PLAN.md Stage 16.
+
+## Development Philosophy
+
+- Build in stages; each stage must be tested and stable before the next begins
+- **Build tools, not games** — ship composable building blocks; genre-specific behavior lives in
+  game code or optional modules
+- **Ship only what's used** — subsystems are feature-gated modules; an exported game compiles in only
+  the modules it registers
+- **Scalable fidelity** — the data-driven render pass pipeline lets a project run anything from a flat
+  low-poly/stylized look to a full realistic stack, paying only for the passes it enables
+- **Modules are the primary extension point** — a module registers engine logic *and* editor UI *and*
+  its own settings through one documented API; anyone (including AI agents) can write one
+- Every system should be composable and independently usable
+- Prefer correctness and clarity over premature optimization
+- Keep public APIs minimal — internal complexity is fine, external surface should be clean
+- No feature creep between stages; additions go into the backlog for later stages
+- The editor (`oxide-editor`) grows with the engine — each stage adds editor support for new systems
+  through the Stage-6 editor framework (panels, menus, undo stack, settings pages)
+
+## Documentation & File Maintenance
+
+- **Always update** `CLAUDE.md`, `PLAN.md`, `README.md`, and `.gitignore` when project rules, goals, stage definitions, or project structure changes
+- `PLAN.md` is the authoritative roadmap — keep it accurate and up-to-date
+- `README.md` must reflect the current build/install instructions and feature list at all times. Keep it a **short overview** — detailed documentation belongs in `docs/`, not the README
+- `.gitignore` must be updated whenever new tools, output formats, or file types are introduced that should not be tracked (e.g. new build targets, generated files, editor temp files)
+- Do not let these files become stale after structural or process changes
+
+### Full documentation in `docs/`
+
+- The `docs/` directory holds the full documentation of the engine — both **usage** (how to call each system) and **inner workings** (how/why it works). The project is too large to fit this in `README.md`.
+- **Write documentation as you work, not after.** A stage is not complete until its systems are documented under `docs/`.
+- One topic per file; link between files rather than duplicating. `docs/README.md` is the documentation index — add new docs to it.
+- When an API changes, update the affected doc and its code snippets **in the same change** so docs never drift from the code.
+- Current docs: `architecture.md`, `conventions.md`, `getting-started.md`, `development.md`, and per-system references (e.g. `math.md`, `windowing.md`, `render-context.md`, `scene.md`).
+
+## Packaging, Installation & Export
+
+- The project must be compilable to a Linux installable package
+- `install.sh` at the repo root builds in release mode and installs the editor binary plus assets to the system (`/usr/local` by default, overridable via `PREFIX`)
+- Keep `install.sh` updated whenever new binaries or assets are added
+- The installed binary name is `oxide-editor`
+- The editor must run on Linux under **both Wayland and Xorg**
+- A later stage adds a **Windows build** of the editor/engine and **game export** to standalone
+  Linux *and* Windows binaries (the exported game links the engine runtime without the editor) — see
+  PLAN.md Stage 16; keep packaging docs current when that lands
+
+## Language & Tooling
+
+- Language: Rust (stable toolchain)
+- Build: Cargo workspace (`engine/`, `editor/`, `examples/`, `tests/`)
+- Graphics: `wgpu` (portability across Vulkan, Metal, DX12)
+- Physics: `rapier3d`
+- Math: `glam`
+- ECS: `hecs` (preferred lightweight approach)
+- Editor UI: `egui` (integrated into `oxide-editor`)
+- Scripting: `rhai` (preferred — embeddable, sandboxed); file watching via `notify` for live reload
+- Audio: standard system via `kira`/`rodio`; ray-traced model built on the engine's own ray casts
+- Windowing backends: `winit` with both `wayland` and `x11` enabled (Linux); Win32 later
+
+## Repository
+
+- Remote: `https://git.houmeres.sk/Houmeres/Oxide.git`
+- Local: `/home/homer/Oxide`
+
+## Git Workflow & Branching
+
+Two long-lived branches: **`dev`** (integration) and **`main`** (stable). Full
+detail in `docs/development.md`; the rules Claude follows:
+
+- **Auto-commit and push to `dev`** every new piece of work that can be **fully
+  verified automatically** (it builds and its unit/integration/fuzz tests and
+  benchmarks pass). Do this as soon as the work is complete and green — no need
+  to ask first for these.
+- **Manual-test gate before `main`.** If a change cannot be fully verified by
+  automated tests — anything involving the GUI, rendering, audio, input feel, or
+  otherwise needing a human to run the engine and observe it — push it to `dev`
+  only, then ask the maintainer to test it. Promote to `main` **only after the
+  maintainer explicitly approves** it works.
+- **Fully-automated changes may go to both `dev` and `main` together**, because
+  the passing automated suite is the sign-off (e.g. pure-logic modules like the
+  math system).
+- Decision rule: *"Can a test prove this works without a human looking at it?"*
+  Yes → eligible for `main`. No → stop at `dev` and request manual testing. When
+  in doubt, treat it as needing manual testing.
+- Always run the local gate before committing:
+  `cargo fmt --check && cargo clippy --all-targets -- -D warnings && cargo test`.
+- End AI-assisted commit messages with the Claude co-author trailer.
+
+## Working with Claude
+
+- Read `PLAN.md` for the full staged roadmap before starting any new stage
+- Each stage has defined deliverables and test criteria — do not skip testing phases
+- When implementing a system, prefer small focused modules over large monolithic files
+- Breaking changes between stages are acceptable; backward compatibility is not a goal during early stages
+- After completing work that changes project structure, goals, or process, update `CLAUDE.md`, `PLAN.md`, and `README.md` before considering the task done