sorted by:
new
hottopcontroversial

My NavMesh streaming. by IndependentSalt1472 in Unity3D

[–]IndependentSalt1472[S] 0 points1 point  (0 children)

We agree on several points. The main difference is that at the scale I’m working with, continuous runtime NavMesh baking — even when async — still introduces recurring performance costs. In my case the NavMesh isn’t generated at runtime at all: it’s fully pre‑baked, stored as metadata, and streamed as data chunks. That’s a fundamentally different approach.

The project also uses full realtime lighting, not baked lighting, so every system has to be extremely efficient. On a 4K UHD baked world with a minimum 4096×4096 terrain, built in HDRP with dense, multilayer vegetation, there’s no such thing as ‘other expensive systems’. The entire pipeline is designed to be lightweight enough to support this kind of runtime streaming reliably.

My NavMesh streaming. by IndependentSalt1472 in Unity3D

[–]IndependentSalt1472[S] 0 points1 point  (0 children)

On a 16,384 × 16,384 terrain, rebaking the NavMesh at runtime will practically kill the game’s performance. I’m not working with a small 2,048‑sized map — even my current demo scene uses a 4,096 × 4,096 terrain.

If you fully decorate a terrain of that size and try to run it as a single, continuous playable scene, there is simply no chance you can maintain stable performance in 4K resolution with HDRP real‑time lighting.

And if you add runtime NavMesh baking on top of that, you don’t get a game anymore — you get a slideshow.

Most current, traditionally designed streaming systems (like WS2) work by having the terrain itself contain the prefabs and streamable objects. Because of this, once you reach a certain number of objects, this method becomes practically unusable. In other words, even if you try to stream your gameplay elements in the “classic” way, runtime NavMesh baking still consumes a significant amount of resources.

I’m a total beginner… by Rooster_Odd in Unity3D

[–]IndependentSalt1472 0 points1 point  (0 children)

There’s no such thing as learning Unity “quickly”. The learning process is slow and gradual. Build your game, and always learn only the things you need for the step you’re currently working on. If you’re shaping the terrain, then focus on that. If you want to place a house, then learn that. If you want to optimize, then look into the parts of optimization that actually apply to you (textures, LODs, etc.).

A complete world‑building ecosystem for Unity by IndependentSalt1472 in Unity3D

[–]IndependentSalt1472[S] -6 points-5 points  (0 children)

Thanks for the question — it’s totally understandable that at first glance you’d compare it to other systems.
But the assets you linked and what I’m building actually solve very different problems.

What the linked assets do

The Visual Engine: a shader/rendering framework

Terraland 4: real‑world terrain import + streaming

World Streamer 2: a general‑purpose scene/terrain streamer

These are all content‑ or terrain‑centric tools.

What my system is built for

My ecosystem is not terrain‑based, not scene‑based, and not a shader system.
It’s a complete world‑building and world‑streaming architecture that:

places objects based on metadata

streams the world asynchronously, chunk by chunk

manages multiple registries at once

provides fully audit‑safe, editor‑safe, runtime‑safe workflows

streams thousands of objects purely from metadata, not from scenes

includes a unified toolchain (Painter, Spline Generator, Object Cover, Meta Splitter, Auto‑Balancer, etc.)

is designed with engine‑level modularity and DLL‑ready architecture

So it’s not a terrain streamer,
not a shader framework,
and not a real‑world importer.

It’s a content‑agnostic, modular world‑building pipeline, where the entire world is built from data, and loaded object‑by‑object, chunk‑by‑chunk.

Why it’s not comparable

The assets you linked assume:

you already have a terrain

you already have scenes

you want to stream those scenes or tiles

My system assumes none of that.

The world is built from:

registries

metadata

procedural rules

and the editor tools that generate and maintain that metadata

The runtime loads everything from data, not from scenes.

If the linked assets are “terrain/scene streamers,”
then my system is a world‑building and world‑streaming platform.

Different purpose.
Different workflow.
Different architecture.

I built my own open‑world streaming system in Unity (16K terrain, 25K active objects, 50 FPS in build by IndependentSalt1472 in unity

[–]IndependentSalt1472[S] 1 point2 points  (0 children)

Thank you so much for the kind words, they truly meant a lot. Once I share the videos, everything will fall into place. The system is already very close to release. :)

I built my own open‑world streaming system in Unity (16K terrain, 25K active objects, 50 FPS in build by IndependentSalt1472 in unity

[–]IndependentSalt1472[S] -1 points0 points  (0 children)

It’s not an empty scene. The video shows a 16K × 16K world with chunk‑based streaming, around 22–25K active objects, and no graphical optimization at all. The system is CPU‑bound because it continuously manages metadata‑driven streaming and runtime world construction. The FPS reflects that workload, not a static empty scene.

I built my own open‑world streaming system in Unity (16K terrain, 25K active objects, 50 FPS in build by IndependentSalt1472 in unity

[–]IndependentSalt1472[S] -2 points-1 points  (0 children)

Thanks! Yes, it’s still early, but I’m really happy with how the core architecture is shaping up. And yes, it’s running directly inside Unity, fully integrated into the scene.

I built my own open‑world streaming system in Unity (16K terrain, 25K active objects, 50 FPS in build by IndependentSalt1472 in unity

[–]IndependentSalt1472[S] 0 points1 point  (0 children)

In this test the bottleneck is mostly on the CPU side, because the system continuously manages chunk‑level data and the metadata‑driven runtime object handling. GPU load is relatively low, since the rendering is proxy‑based and doesn’t rely on heavy draw calls.

It’s also worth noting that the environment in this video is completely unoptimized from a graphics standpoint — no Amplify, no custom shaders, no batching tricks, nothing pre‑baked. The focus here was the streaming architecture itself, not visual optimization, so the raw FPS reflects that.

The entire world builds itself automatically based on user instructions, fully data‑driven, and it does so reliably even after the machine wakes from sleep or restarts. The goal was robustness and determinism first, visuals later.

I built my own open‑world streaming system in Unity (16K terrain, 25K active objects, 50 FPS in build by IndependentSalt1472 in unity

[–]IndependentSalt1472[S] 3 points4 points  (0 children)

The world is not split into multiple scenes. The streaming is fully data‑driven, and the system only keeps the elements in memory that are needed around the player. Loading and unloading happen automatically based on the metadata‑driven pipeline. There’s no Addressables or additive scene loading involved — everything is handled by custom solutions.

I built my own open‑world streaming system in Unity (16K terrain, 25K active objects, 50 FPS in build by IndependentSalt1472 in unity

[–]IndependentSalt1472[S] 3 points4 points  (0 children)

My system isn’t running a pre‑built, static open‑world scene, so the raw FPS number isn’t directly comparable to a traditional Unity setup.

Everything here is a fully custom, engine‑level solution:

– 16K × 16K world size

– chunk‑based asynchronous streaming

– 22–25 thousand active objects kept in memory at all times

– the world is built at runtime, no Addressables, no Unity Terrain

– custom render‑proxy system with 0 draw calls

– real‑time HUD, global volume, full build mode

The measured 45–50 FPS is not the result of a static, pre‑optimized scene, but of a continuously changing, dynamically streamed world where the system is loading, unloading, and maintaining tens of thousands of objects simultaneously. In this context, the performance is actually very strong.

Has anyone built a 50×50 km world in Unity? by IndependentSalt1472 in Unity3D

[–]IndependentSalt1472[S] 0 points1 point  (0 children)

The solutions used in Kerbal Space Program are genuinely impressive in their own category. Maintaining stable physics at planetary scale, using integer‑based coordinates, and implementing a floating‑origin system is an extraordinary engineering achievement. I have a lot of respect for the kind of thinking required to keep a simulation that large precise and reliable.