DEV Community

Cover image for DeepMonkey Studio: from generated scenes to editable worlds, with GLM-5.3
fatasia
fatasia

Posted on Fully Autonomous

DeepMonkey Studio: from generated scenes to editable worlds, with GLM-5.3

DeepMonkey Studio is an editable 2D/3D world platform: scene editing, data, scripts, and AI operations belong to the same project. I maintain the project. You can try the browser demo or inspect the repository.

From Vibe Coding to Vibe World

Generating a striking scene is only the beginning. The harder question is what remains after the prompt: can you reopen the world, change an object, attach data, inspect an action, and ship it somewhere else?

That is the idea behind DeepMonkey's phrase “Vibe World.” The output should be a project you can keep working on, not just an image or a disposable preview. Its longer-term direction includes world models and AI for Science; those are directions, not a claim that the editor is already a general world model.

What belongs in the project

The editor brings four concerns together:

  • Presentation: 2D dashboards and 3D scenes, with animation, scripting, and plugins.
  • Meaning: ontology objects, relationships, and actions that connect visual objects to domain concepts.
  • Live behavior: data connectors, device topology, real-time data, and alarms.
  • Delivery: viewers and publish targets, with capability and dependency checks rather than an assumption that every backend supports everything.

A factory scene is a useful example. A machine is not only a mesh: it can be an object with properties and relationships, shown in a 3D scene and connected to a dashboard. The project includes industrial tooling around PlantLite, PPRLite, URDF robots, and virtual commissioning.

Why an ontology matters for AI actions

A chat box beside a viewport does not automatically understand the project. DeepMonkey's ontology layer describes objects, their relationships, and available actions so AI can work with project context rather than only generate text about a screenshot.

Operations are designed around permissions, previews, cancellation, and traceability. These controls matter when an action changes an existing project. Generating a suggestion and applying it are different operations.

The AI integration includes model adapters, Responses/Chat Completions support, and MCP. The model is a participant in the workflow, not a replacement for the saved project structure.

Editor and engine are separate layers

DeepEngine includes a TypeScript WebGPU path, Rust/wgpu native work, and WebAssembly, using shared scene packages. Studio also retains a Three.js/WebGL compatibility path.

That distinction matters when evaluating the demo: selecting a rendering backend is not proof of identical support across all deployment targets. Rendering, physics, import conversion, and publishing have backend-specific requirements. The repository documents the available paths.

There are independent SDK and scripting entry points as well. Developers can use Scene/Server SDKs or plugins without treating the whole editor UI as their application's API.

Try the right version

The GitHub Pages demo is a partial frontend demonstration. It does not require an account, stores edits locally, and includes an SMT production-line sample. It is not the full hosted backend service.

For a local editor, use Node.js 24 or later and run:

npx deepmonkey
Enter fullscreen mode Exit fullscreen mode

For an SDK starter, use npx create-deepmonkey my-world. The repository also provides Windows, Docker, and source-based setup paths. Choose one of those when testing server-backed functionality.

Where GLM-5.3 fits

Development used multiple models. My estimated usage split is GPT-6 Astra 50%, GLM-5.3 40%, and Opus 10%. These percentages describe model usage, not measured percentages of authored code. I am not assigning individual engine or editor modules to a model without evidence.

This makes DeepMonkey a GLM-assisted development case, but not a GLM-only application. This article was prepared with AI assistance from the project's documented features.

For evaluation, start with the sample scene, inspect its objects, and distinguish local frontend editing from server-backed workflows. When reporting a problem, include the deployment mode, rendering backend, asset format, and reproduction steps in a GitHub issue.

Top comments (0)