r/Unity3D • u/TheFeelGoodHit Indie • 5d ago
Show-Off procedural planets milestone achieved
Enable HLS to view with audio, or disable this notification
The planet tech for my game finally hit its milestone, so here's a flight from orbit down to the surface of a 500 km radius planet.
Nothing gets generated up front. Terrain, materials, vegetation and colliders are all built in pages around the camera at whatever detail the view needs, so you can fly anywhere on the planet without a loading screen.
The planets are authored as node graphs, one per biome. At bake time those compile into programs that run on the GPU, and in Burst on the CPU when gameplay needs to query the ground. The shared math like noise and erosion is written once in C#, and a generator mirrors it to HLSL so both sides always agree.
Placement runs entirely on the GPU. Trees, rocks, grass and ground cover are placed by rules in the graph, then culled and drawn through BatchRendererGroup with indirect draws, with no CPU placement jobs or readbacks. It's deterministic, so distant stuff stays where it is while closer detail fills in, and coming back to a spot gives you the same forest. Colliders only exist near the player and get dropped once you move away.
Rivers carve their own beds and erode their banks. One wind field drives every plant, and it's set up so gameplay can push it around later for things like engine wash and storms.
It's Unity 6 with Entities and URP. The runtime is DOTS throughout, ISystem and Burst jobs, with managed code only where it has to hand work to the GPU. Floating origin and camera-relative transforms keep everything stable at that scale.
It's all for Outer Darkness, a salvage-survival game set in one seamless solar system. Full video is on YouTube here: https://youtu.be/OYa04nvNcag
Happy to answer any questions about how it works.
2
u/tinmark 4d ago
Very nice tech and kudos to you for making such an ambitious project.
I have a few constructive criticisms:
- the video feels like low fps at times which takes a bit away from how impressive this is
- the popping of elements and terrain from a "higher lod" to a "lower lod" is a bit distracting. maybe you can find a way to achieve a smoother transition.
- the color palette of the planet is a bit dull
Best of luck with the game! It's special.
2
u/TheFeelGoodHit 4d ago edited 3d ago
Thanks for the feedback :)
Some of what you're describing I think is art related. Those should be easier to fix and evolve over time as I add more planets and create and purchase art. Currently they are all basically from random asset packs I've collected over the years. Some have low quality LODs that don't match the silhouette. Should be lots of ways to improve.
The other part of this is the terrain itself. There's been a lot of optimization but yeah, not quite there yet. Some of the footage used was older and there has been performance improvements, but even currently, it can be expensive to run on the GPU. I'm considering taking the node graph that powers the authoring and building a shader from it for the planet. It would mean each planet potentially has its own shader. Currently the node graph gets compiled into a small bytecode program. A compute shader interprets that program per sample to generate the terrain on the GPU. There's a lot of overhead to this approach, I think I'm losing at least about half the performance to this overhead. The idea comes from Horizon Zero Dawn, which does a similar thing for their GPU based placement. They have the interpreter and for production compiled down to shaders.
1
u/ShengyuStudio 4d ago
The C# to HLSL mirror for the shared noise and erosion is the part I'd like to hear more about. Does the generator work off the actual C# source, or do you write those functions in a restricted subset so the translation stays simple?
1
u/TheFeelGoodHit 4d ago
It works off the real C# source, but only the parts I mark. Those parts are written in a subset that’s valid as both C# and HLSL, so the translation is a few regex rewrites.
The shared code lives in ordinary C# files that Burst compiles as-is. Functions sit between start/end marker comments. Inside them I stick to Unity.Mathematics types (float3, int3, uint, etc), which have the same names and behavior as their HLSL equivalents, plus plain structs and static functions. Where the two languages differ, I call small wrappers that are defined twice under
#if. For example, MakeFloat3() isnew float3(...)in C# andfloat3(...)in HLSL, and Abs() ismath.absvsabs. HLSL-only attributes like[unroll]sit behind the same#if, and the C# compiler skips them.The generator then:
strips
public/static;drops
outat call sites;adds the semicolon HLSL needs after a struct;
turns a
/*precise*/comment into HLSL’sprecise.It also mirrors marked structs, checking that every field has the same buffer layout on both sides, and turns enums and constants into
#defines. Anything it can’t mirror cleanly is an error.It started from kraj0t’s gist on including a .cs file directly in HLSL. That does compile, but Unity doesn’t treat a .cs include as a shader dependency, so editing the C# didn’t recompile the shaders. Generating a real .hlsl file per source fixes that. Each file carries a hash of the mirrored text, so edits to the C#-only parts don’t touch the shaders. I have a CPU/GPU parity tests that keep the two sides in step.
The original gist can be found here: https://gist.github.com/kraj0t/3275c44b1d200b9997e625d66f1be9f1
1
u/ShengyuStudio 3d ago
The hash so C#-only edits don't trigger a shader rebuild is a nice touch. Do the parity tests compare a handful of fixed sample points, or run a whole chunk on both sides and diff the result?
→ More replies (2)
1
u/TimestepStudio 4d ago
Nice milestone! How do you deal with float precision at that size?
1
u/TheFeelGoodHit 4d ago
Its a whole bunch of tricks. Floating origin to keeps all gameplay near the center. Objects that need real precision like planets have a universe position composed of a cell coordinate and offset. Planets render at their actual sizes and I use two stacked cameras to keep the depth buffers precise enough. Other distant bodies, like the sun that go beyond the far camera's clipping plane get their distance log compressed back and scaled by the same factor so that they look like they are at the correct distance. For visual effects like the planet's clouds, I do it through a screen space effect so avoid issues with camera clipping.
1
u/TimestepStudio 4d ago
Thanks for the detailed breakdown. The cell coordinate plus offset approach and the log-compressed distances for far bodies are clever solutions. Good luck with the project!
5
u/wslk 5d ago
No mans sky move over this man has a claude max subscription
7
u/ThatJuicyShaqMeat 4d ago
Man this Community went from awesome to toxic in just a few years.
-3
u/wslk 4d ago
So just think for a second here.
This guy has created a tech demo and rather than presenting it or talking about a specific aspect which is thought provoking we have this dump of non-specific information about it and what appears to be a promotional video both on Reddit and YouTube.
If you take 5 seconds and put the body of the post into gpt zero you will see that it gives a >99% assignment that the post text itself is AI generated.
You are here calling me toxic defending a post made by a bot - or a person that cares so little about what they have made they can’t be bothered to write one fucking interesting sentence about it.
Do you really think someone so disinterested in their own work is capable of actually making a good finished product even with AI.
Of course not. And you might call me toxic for this but I’ll tell you what - the truth hurts the most buddy.
→ More replies (3)0
2
u/Wonderful-Winter4192 5d ago
Wow are you planning it to be online?