devrim

Compose Architecture

The /compose-2 system generates complete residential floor plans procedurally — including layout, furniture, decorations, and dynamic objects — and renders them as an interactive 3D scene with primitive geometry. Every spatial decision is captured in a deterministic pipeline driven by a seeded PRNG, so the same seed produces the same house. The output is fully described in YAML so the data is portable to other consumers (game engines, simulators, asset pipelines).

This document describes the architecture in depth, including the data flow, the constraint system, the rendering strategy, the validation pipeline, and a roadmap of future additions.

---

Table of Contents

devrim

Building a Cursor-Quality AI Agent for 3D Scene Generation: Architecture Deep Dive

Executive Summary

Building an AI agent that can interpret natural language like "create a scene where I'm going to assemble legos" and produce a fully realized 3D environment with physics-ready objects, lighting, and scripted behaviors is one of the most demanding applications of agentic AI. It combines the hardest problems in the field: multi-step planning over ordered physical constraints, retrieval over structured asset catalogs with physics metadata, code generation in a domain-specific context (C# game scripts), and tight tool integration with a real-time engine.

This article examines how leading AI-powered creation tools—Cursor, Devin, Replit Agent, GitHub Copilot, Bolt.new, and Vercel v0—architect their backends, and distills the patterns that matter for a 3D scene generation agent embedded in a C++ game engine. We compare seven major agent frameworks (LangChain/LangGraph, CrewAI, AutoGen/Semantic Kernel, DSPy, H

devrim

AI Scene Agent for LuckyEngine — Technical Report

Date: 2026-04-15 Scope: Evaluate approaches for an AI agent that creates interactive training scenes for robots in LuckyEngine

---

1. Problem Statement

LuckyEngine is a C++ physics simulator (Vulkan rendering, MuJoCo physics, entt ECS) with a Python SDK (LuckyRobots) and RL/IL framework (LuckyLab). Users need to create diverse, physically-plausible training environments for robots — kitchens, warehouses, obstacle courses, manipulation tasks, etc.

devrim

LuckyLab Code Review — 9,934 Lines, File by File

The Executive Summary

LuckyLab is an IsaacLab-inspired framework that decomposes the MDP into 5 manager classes, wraps two RL backends (skrl, SB3) and one IL backend (LeRobot), and provides config-as-code for a single working task (Go2 velocity tracking with SAC). It is architecturally coherent — the patterns are internally consistent — but the framework-to-value ratio is terrible. 9,934 lines exist to do what the proposed sim API redesign achieves in ~4 lines of user code.

Bug Tally

These are actual bugs, not style complaints:

devrim

devrim

Session Log — ImGui macOS Retina Fix (2026-03-17)

Prompt 1

Read this repo and write a report about what stage is it for the mac os port of the engine

Response: Comprehensive macOS port status report covering all subsystems (rendering, physics, audio, scripting, editor UI, asset pipeline). Conclusion: ~97% complete MVP, all major subsystems working on Apple Silicon via Vulkan/MoltenVK.

---

Prompt 2

devrim

• LeRobot integration into LuckyEngine (LE, LR, LL)
  • LeRobot already setup inside of LuckyLab and was able to train a policy
  • Focus is on inference into LuckyEngine right now
  • Currently, inference is setup and gRPC connects then sends observations but robot doesn't move inside of LuckyEngine
  • Scene setting is not working correctly in this scenario: piper-blockstacing scene, blocks get teleported out of workspace without robot even moving
• Setup LuckyLab with CLI to start LuckyEngine in specified scene and autonomously start training/inference (LE, LR, LL)
  • Enable command line control from LuckyLab to start LuckyEngine into a specified scene and play scene automatically for full control from command line with luckylab
• Configure mjwarp in LuckyEngine (LE, LR, LL)
  • Setup mjwarp inside of LucykEngine

• Enable multiple robots to be controlled inside of LuckyEngine through Learn/ API

devrim

LuckyEngine Architecture Review & Critique

A brutally honest self-review of LuckyEngine's architecture. Every finding is backed by exact file paths and line counts.

---

Table of Contents

1. Codebase At A Glance
2. Architectural Critique

devrim

Ned Architecture Review & Critique

An honest, brutal architectural review of the Ned editor submodule (Hazel/vendor/Ned/), as embedded within LuckyEngine.

---

Table of Contents

1. What Ned Is
2. System Map

devrim

House Definition System

YAML-driven house composition with pluggable generators and asset.luckyrobots.com integration

Why This Instead of the Original Proposal

The original Procedural Building Generation proposal is a solid C++ mesh-generation system for walls, doors, windows, and floors -- and we want to keep all of that code. The problem is its architecture: BuildingGenerator sits at the top and owns the whole pipeline, and room-specific things like the KitchenLayoutBuilder get bolted on as post-materialization hooks dispatched by room type. That means every new room feature (kitchen cabinets, garage doors, sliding doors, closet shelving) needs its own special-case integration path into the building generator.

In practice, all of these are the same class of problem -- composing assets and procedural geometry inside a room. A kitchen cabinet run along a wall is structurally no different from a garage door filling an opening