Untold Engine Updates: Faster Scene Loading, SSAO improvements, CLI

Hey guys, I’ve been working hard on improving the engine lately—both performance-wise and editor (user-experience) wise.

Faster Scene Loading with Async Asset Loading

One of the main issues I fixed in v0.7.0 was the long wait times when loading heavy scenes. I don’t have hard numbers, but it was definitely taking longer than what’s acceptable for a game engine. The main issue was that we didn’t have an async loading system in place. All models were being loaded synchronously, which caused long stalls.

With v0.7.0, scenes are now loaded through an async loading system, which makes the overall experience much better and more responsive.

Here is an example of how you can use the new async loading:

// Create entity
let entityId = createEntity()

// Load mesh asynchronously (fire and forget)
setEntityMeshAsync( entityId: entityId, filename: "large_model", withExtension: "usdz")

For more info, read the UsingAsyncLoading.md under the docs folder.

SSAO Performance Improvements (Especially on Vision Pro)

Another issue I worked on was improving SSAO performance, especially on mobile and Vision Pro. I added three quality modes for SSAO computation:

  • Fast
  • Balanced
  • High

Fast mode is the most performant but has the lowest quality, while High mode provides the best quality at the cost of performance. Fast mode did improve performance on Vision Pro, but unfortunately, not enough—the FPS is still not acceptable. Until I find a better solution, I recommend disabling SSAO entirely when using Vision Pro.

To use it in code, simply set the quality as shown below:

SSAOParams.shared.quality = .balanced //.fast or .high

Command-Line Project Creation (Xcode Integration)

The third feature I added, which I think will be really helpful, is the ability to create an Xcode game project with Untold Engine as a dependency directly from the command line. This is especially useful for users who want to bypass the editor and work directly in Xcode. That said, this doesn’t mean you can’t use the editor later—projects created this way can still be opened in Untold Engine Studio.

Here is an example on how to install and use the cli tool:

# clone the repo
git clone https://github.com/untoldengine/UntoldEngine.git
cd UntoldEngine

# Install the CLI globally:
./scripts/install-create.sh

# Verify installation:
untoldengine-create --version
untoldengine-create --help

# After installing the CLI, create a project from anywhere:

#  Create project directory
cd ~/anywhere
mkdir MyGame && cd MyGame

#  Create the project
untoldengine-create create MyGame

#  Open in Xcode
open MyGame/MyGame.xcodeproj

For more information, see: Tools/UntoldEngineCLI/README.md

Editor Workflow Improvements

I also spent time improving the user experience in the Untold Editor. The workflow is starting to take shape:

  1. User opens Untold Engine Studio
  2. Creates a new project or opens an existing one
  3. Populates the scene
  4. Writes game logic using Swift or scripting
  5. Builds & plays
  6. Repeat steps 3–5

This is still a work in progress, but I’m liking how everything is coming together.

What’s Next

For this week, I’m planning to focus on:

  1. Benchmarking + metrics harness
  2. Improving performance on Vision Pro and iOS

That’s the plan.
Feel free to checkout the the Untold Engine Studio v0.7.0.

Thanks for reading.

Untold Engine is Growing Up

I’ve been working on the Untold Engine for nearly 12 years.

I started in 2013, back when I didn’t even know what version control was. The early versions of the engine were crude, fragile, and limited—but seeing it improve, fix by fix, was deeply motivating.

There were many points along the way where I wanted to quit. Days where I was tired of touching the engine at all. At one point, I stopped entirely for about six months before coming back.

What I learned over time is that building a game engine isn’t technically hard in the way people expect. The real difficulty isn’t math, rendering, or architecture—it’s consistency. Showing up every day after the excitement wears off. Continuing when motivation is gone.

That’s the part most people underestimate.

I eventually realized something about myself: I’m not a good engineer because I write good code. I’m a good engineer because I don’t leave problems unfinished. I stay with them. I’ve done that since I was a kid—I just didn’t recognize it until much later.

That persistence is the reason Untold Engine still exists today.

After rebuilding the engine twice—from C++ to Swift—the project is finally reaching a point where it feels grown up. Today, I’m releasing Untold Engine Studio, the first bundled desktop release of the Untold Engine ecosystem.

This release exists for one reason: to remove friction.

With Untold Engine Studio, developers can:

  • Download a single DMG and start immediately
  • Skip repository cloning and local build setup
  • Create and manage projects from a standalone app
  • Work visually with scenes, assets, and entities
  • Iterate quickly using Play Mode and Scripting language

From the beginning, my focus has been user experience. I’m not trying to compete with Unreal on performance or Unity on market share. My goal is simpler—and harder: to build a tool that feels intuitive, stable, and dependable. Something that doesn’t fight you. Something that just works.

That’s not easy. It requires constant iteration and restraint. But this release is a meaningful step in that direction.

If you’re curious, I encourage you to download Untold Engine Studio and try it for yourself. Your feedback—good or bad—is genuinely valuable, and you can share it through the Untold Engine GitHub issues.

I’ve also invested a significant amount of time in documentation to make getting started easier, and I hope it helps.

As 2025 comes to a close, I’m proud of where Untold Engine is today. I have ambitious plans for 2026, and I’m excited to see how much further this project can go.

Thank you for reading.

Untold Engine Update: Gaussian Splats, Scripting Support, and macOS Build System

It has been a while since my last update, but I’ve been quietly working behind the scenes on several major features. Today, I want to share three big milestones for the Untold Engine.

Gaussian Splats

The first major update is that the Untold Engine now supports Gaussian Splat Rendering. This is a feature I’ve wanted to implement since I first learned about Gaussian Splatting last year. Other priorities kept delaying it, but a few weeks ago I finally had enough time to focus on it—and I got it working.

Gaussian Splats now run inside the Untold Editor, on iOS, in AR, and on the Vision Pro, running directly on the device. This means both 3D models and splats render natively on visionOS hardware, not just the simulator.

There are a few current limitations:

  • I’m using Bitonic Sort instead of Radix Sort for depth sorting. Bitonic Sort works, but it is slower for large splat counts. Radix Sort is the long-term goal.
  • Spherical Harmonics support is not implemented yet. I’m hoping to add this before the end of the year.

Even with these limitations, this is a major step forward for the engine’s rendering capabilities.

Scripting Support

The engine now supports runtime scripting directly through the Untold Editor.

You can write game logic in Xcode, attach scripts to entities, and instantly see the results while the engine is running. All scripts appear in the Asset Browser, and you can add, link, or reload them with a click. This makes the development workflow smoother and faster.

This feature was long overdue, but I approached it carefully because of past experience integrating scripting languages. Instead of Lua or Python, I built a lightweight DSL (Domain-Specific Language) specifically for the Untold Engine. I used ChatGPT heavily at the beginning to help with the initial structure, and once everything made sense, I took over and customized the system for the engine.

If you see anything that can be improved, please let me know—this is a brand-new system and will evolve with feedback.

Feel free to check out the Scripting Section in the Docs to learn more.

Build System

Another major milestone is the new Build System.

After you set up your scene in the editor and attach scripts, the Untold Engine can now generate a macOS build of your game. The Build System packages your scenes, assets, and scripts and produces an app ready for the App Store. All you need to do is provide a project name and a destination path.

At the moment, the Build System supports macOS only, but iOS and visionOS support is planned.

What’s Next?

I’m currently working on a packaged app bundle for the Untold Engine. The idea is to let developers download a .dmg file and start building games immediately—without cloning the repo or setting up dependencies. Developers who want full control can still clone and build from source.

This bundled version will be called Untold Engine Studio, and it will include everything required: the Untold Engine, the Untold Editor, and all dependencies. My goal is to make the development experience as smooth and accessible as possible.

More updates coming soon. Thanks for following the journey!

Untold Engine Progress Update – New Editor and VisionOS Support!

This past couple of months have been amazing for the Untold Engine — from getting its first contributor and sponsorship to adding VisionOS support.

Let me tell you all about it.

Engine & Editor

You may recall that I had both the core and the editor integrated tightly in the engine. It worked nicely, but the coupling was going to give us headaches in the future.

Thanks to the effort of our first contributor miogds, the core of the engine and the editor are now de-coupled.

So, this is the new architecture of the engine:

  • Core: Handles the runtime — rendering, physics, ECS, and all engine systems.
  • Editor: A dedicated app for scene creation, entity manipulation, and asset management.
 

Untold Engine - Core

 

This separation makes development cleaner, more modular, and sets the stage for headless or custom integration workflows.

Additionally, the core engine will continue in its original repository UntoldEngine, while the editor now lives in a new, dedicated repo UntoldEditor.

 

Untold Engine Editor

 

Unit Tests & Workflows

I've also been working on making the Untold Engine repository more professional.
This includes adding unit tests, GitHub Actions workflows, and automatic formatting and linting.

My hope is that these improvements will make contributing to the project much easier and more reliable.

 
 

Website & Documentation

Another area of progress has been the new website and documentation.
The documentation site covers how to install the engine, explore the APIs, and contribute to development.

You can check it out here: Untold Engine

Each engine release will include its own version of the docs for consistent developer onboarding.

 
 

VisionOS Support

Lastly, the engine now compiles and runs on the VisionOS simulator — the first step toward supporting Apple’s Vision Pro platform.

However, this is still early support — the engine has not yet been tested on an actual Vision Pro device.
We’ve already received an issue report related to Vision Pro hardware, so if you happen to have one and would like to help debug, you’re more than welcome to contribute!

 
 

Thanks for reading.

Debugging a Flickering Issue Caused by Asynchronous Culling

After implementing frustum culling in the Untold Engine, performance improved, but right away I noticed flickering. It didn’t happen every frame, but it was noticeable whenever most of the models were in view.

So, I opened up Instruments to profile the issue. I noticed warnings that the engine was holding on to the drawable too long. I tried restructuring things to hold on to the drawable for as short a time as possible, but nothing helped.

According to Instruments, the engine was not CPU-bound or GPU-bound. There was no clear indication of the root cause of the flickering.


Digging Deeper

At that point, I decided to record a short video of the issue. I slowed it down and went frame by frame. What I saw wasn’t the usual kind of flickering—it was different.

  • Frame 1: a certain set of models was visible.
  • Frame 2: a completely different set was visible.
  • Frame 3: some disappeared, others suddenly appeared.

Models were popping in and out, almost as if something was out of sync.

This was a huge hint: it looked like a data race.


The Culprit

Looking at the code confirmed it.

In the frustum culling command buffer completion handler, I was updating the visibleEntityId array. This array held all the entities that passed the culling test.

The problem was that the GPU calls this completion handler asynchronously, while the CPU was already using that same array during the rendering passes (shadow and geometry).

 
 

In other words, the CPU was iterating over visibleEntityId at the same time the GPU might be modifying it.

Classic data race.


The Fix: Triple Buffering

The solution was to add a triple-buffered visible entity list.

During culling, the GPU writes results into buffer n+1.

 
 

During rendering, the CPU continues to read from buffer n.

 
 

When the frame finishes and the render command buffer’s completion handler triggers, I update the index so the CPU reads from the freshly written buffer n+1 on the next frame.

This guarantees that the CPU never reads data being modified by the GPU. The renderer always sees a stable snapshot of the visible entities.


The Result

With triple buffering in place, the flickering disappeared instantly. Models no longer popped in and out between frames.

This bug was a good reminder: sometimes what looks like a rendering artifact isn’t a math error at all, but a synchronization issue between CPU and GPU.


Lesson Learned

Whenever the GPU produces results asynchronously, the CPU should never iterate over those results directly. Always work with a snapshot. Triple buffering (or even double buffering) is a small architectural change that guarantees stability and avoids subtle bugs that can masquerade as rendering issues.

This experience reinforced for me how crucial synchronization and data ownership are when building GPU-driven systems—sometimes the hardest-looking bugs aren’t about shaders or math, but about who’s allowed to touch the data, and when.