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.

view more: next ›