New Worldbuilding is dead?

[upper kestrel]

Nothing was said in the roadmap about the new Worldbuilding. Any updates?

[desert sedge]

Yeah. This one was tough one. Folks were really pumped coming out of Unite for it. BUT the reality is that the product was a very long way from being production ready with a host of bugs and incomplete parts.

Now, we understand that the current Unity terrain tools aren't cutting it, so the team is going to refocus on adding more value the current system.

[upper kestrel]

Was the project scrapped, or will it move forward in parallel with the existing system?

[desert sedge]

Not moving forward.

[kindred quiver]

Thanks for the honesty.

[turbid rose]

any chance of just throwing it up on github for the community to pick and take what works for them?

[coarse star]

Very bad news, no wonder devs keep leaving unity.

Please open-source it

[desert sedge]

I'm not sure of future plans out side of cancelling it, BUT I will pass along that folks would love to see it made open source.

[cerulean yarrow]

Y'all sunk 6 years with 12 people into that, and I wrote MicroVerse in less than a month. You should just save yourself a ton of money and buy me out over trying to have your teams build it.

overhead of large companies makes everything impossible..

[kindred quiver]

Assuming that the new world building all operated at a fundamentally C# and above level, I’m not so upset about this as others. If unity maintains the core of the engine there are lots of good ways to build what your game needs of this yourself (and in fact we do for ourselves). I’d actually rather see unity figure out how to let asset store devs monetize good solutions here.

[languid arrow]

isn't coreCLR also a long way from being production ready and even harder to accomplish? hope that doesn't end up with the same fate 😨

[cerulean yarrow]

The unity terrain system is like 15 years out of date- it could consume drastically less memory, be faster to update, provide high quality results, etc. All asset devs are blocked by that unless Unity opens up the physics engine so we could write our own.

[golden badger]

This is incredibly disappointing, terrain is one of Unity's major weak points (slow, outdated, lacking functionality) and is could use a redesign from the ground up to incorporate technology improvements over the last decade...

[cerulean yarrow]

Most of the work of writing MV was working around outdated APIs and the baggage of unity terrain.

[charred wing]

savage! but good thing you posted that because unity needs a drastic reality check

[cerulean yarrow]

Working in large companies makes it very hard to get anything done- too many cooks, changing directions, changing visions, etc.

They likely blew 10-20mil on that effort.

[versed crypt]

Terrain kind dead, but blender still kinda just a better meshing tool anyway so hard to really beat it

what we could use is a voxelized terrain editor, now those are cool

[kindred quiver]

It does feel like there are things that they could do to move the terrain engine forward and it sounds more optimistic that that’s a short term plan. I think I’m being fair saying it’s algorithmically a solid heightfield and splat renderer from the year 2011. Even just modernizing the APIs like has already happened for texture and mesh would open up options. Making clearer separation between data for terrain collider (which we don’t use) and terrain would also help at the lowest levels.

The only API in unity that takes a 2d Mono array of floats (which it immediately converts to shorts) is in terrain… That’s like textures only supporting set pixels with mono arrays of floating point colours.

[cerulean yarrow]

Don’t look at the details api- it’s a crime scene.

[kindred quiver]

Yeah it is. I also want to write something about the documentation for PatchMinMax, the calculation of which becomes a big CPU hotspot for runtime procedural terrain, but I’ll just shorten the post to “lol”.

But trying to be constructive.. these sorts of things do represent an opportunity to upgrade the base systems of the current terrain, then let asset store devs (or team tech devs) do their thing with higher level systems and workflows.

[cerulean yarrow]

Thing is, it needs a fundamental rewrite. Storing weight masks for each texture on the terrain is hugely wasteful of memory, doesn’t fit streaming, etc. The basic rendering technique of the mesh is ancient and outdated, etc. and I doubt they’re going to fix much of it- most likely just plug in some AI heightmap generation and call it victory.

Notice they said they were working on better tools, not a better system.

[novel zephyr]

Just acquire Storm: https://www.procedural-worlds.com/products/enterprise/storm/
I'm sure folks at Unity are already aware what Procedural Worlds is working on
They were even at GDC for a showcase I think?

[upper kestrel]

I'm guessing Storm will be sold or offered as a subscription on their site, but I'd prefer to use Unity's official solution. The problem is, they're slow to update their tools whenever a new Unity update is released

It also appears to be incompatible with DOTS

[light mica]

You've got to be kidding. If Unity can't do it, then you need to let the asset store do it. Work with these asset store developers to give them access to whatever they need. The current terrain system is terrible to work with.

[novel zephyr]

Yea, honestly preferred if they continued working on it
Like at this point I don't mind if they release it for Unity 7 or 8
Just don't stop working on it, Unity please

[severe crystal]

I would prefer if they worked on improving the backend and API. Leave some of this up to game developers and the asset store.

[versed crypt]

Some features like painting detailed meshes onto the terrain seem to be broken with WebGPU too

Really though I've been only using the terrain to generate a mesh, export to to blender, bake my maps and just use that as of late

[hidden veldt]

terrain is so fundamental to gamedev and it's a shame we have to buy assets to cover this problem of unity.

[coarse star]

Assets don't fix the performance issue.

[robust owl]

How about open sourcing the current system? As Jason Booth already mentioned, our custom extensions are severely limited by what's exposed.

(Alternatively just expose PhysX heightmap colliders so at least we can replace the whole thing)

[cerulean yarrow]

I didn’t think you were allowed to advertise in here?

[marble dune]

Didn't realize I was committing a sin. The way i look at it, if small teams can make the next genshin impact with our tools and unity, then thats a massive win for us all.

[quaint dune]

personally i feel like linking a relevant asset as part of a discussion is fine

there's a big difference between that and just randomly dumping a link to your asset in a chat channel with no context

[robust owl]

The Storm tool is currently listed as "Enterprise". Are there plans to make it more accessible in the future?

[marble dune]

yes. but we need to start with smaller group first otherwise we will be swamped. feel free to register your interest. there is a link on our site.

[robust owl]

I'm sure you'll have it done before I commit to a new project.

[novel zephyr]

Can the procedural generation stuff (terrain, dungeon, etc) run during runtime in builds? Use case is for world gen games like Valheim

This was the feature I was looking forward to with Unity's world building tools

[marble dune]

vegetation, buildings etc are all capable of being generated and tuned at runtime. terrain and texturing will come a little later, as we already have tools for this in gaia.

[robust owl]

Technically you can do that with current terrain

The API is just really slow- largely because of the C# interop layer being unoptimized

[marble dune]

yep - we already have gpu compute versions of this - its just not in there yet

[cerulean yarrow]

Unity’s api is the slowest part of MicroVerse’s realtime update. And working around it a significant part of the dev effort. Unity terrain is kind of unfixable unless they change:

• the LOD system (GeoClipmaps would be a better fit)
• the ways splat data is stored (doesn’t scale to high texture counts)
• the details api and storage method

And they can’t do that well without basically having two systems in one, or breaking compatibility.

Also virtual texturing, etc. god it’s so old.

Can’t believe they spent like 6 years on this and didn’t ship. I could write something way better in a month, and I’m not being hyperbolic about that.

[robust owl]

What would be a better way to store the splat data?

[cerulean yarrow]

Unity uses a RGBA texture for every 4 textured used on the terrain, uncompressed. Want 32 textures on a terrain? That’s 8 textured for solar data. Instead you can store indexes and weights. So for 32 textured you could store 3 indexes in 6 bits each, then two weights in 7 bits each, with the third reconstructed. Now 1 RGBA texture instead of 8.

[robust owl]

Wouldn't this come with the limitation of three potential layers per pixel?

Granted, that's not a very harsh limitation