How would I make something like a full-scale planet? I’ve seen other people do such.
I’m confused on how they manage to add stuff like height-maps to their planet, and small details.
I’m trying to achieve something like this in roblox.
That’s what im trying to achieve basically, I may know how to do the gravity, but the main thing I’m trying to get over about, is how would I generate a height-map or something to make big mountains / hills that aren’t frequent? and what would I use to do such.
I’ve been thinking of terrain cause it’s flexible and it makes itself low-quality.
I’m not trying to make planets that are similar to earth where you can see their surface, take this video as a example.
I’m trying to get ideas on how to achieve something like this.
There is an old topic similar to this back in 2021 but it’s pretty dead and it’s not what im really aiming for, he’s aiming for gravity, im looking for generation, as far as we need to worry the planet is NOT moving anywhere.
Well, very few people if any have done this on roblox. It would have to be generated in chunks by the client.
The first step I would take is figuring out how I should store the map aka “Planet”. Maybe with an algorithm like what minecraft does? or store information in a table? and send the client the needed data chunks.
This really isn’t the answer but I hope it helps with direction. The only way to reach this scale is with some kind of chunk loading system. Because the scale is too much for the server and client to load at once.
Same state (i think), same time, my god I need to get sleep as well.
But anyways that makes a bit of sense to me.
I guess we use magnitude on the player’s humroot, and start rendering the terrain using the data from the table, if it’s within the region, i’m guessing thats what the function is?
My conclusion on this topic: I’m sure this is all theoretically possible, but I decided it just isn’t worth the time.
The Trouble with Scale: A Short Treatise
Roblox Terrain is a No-Go
Roblox Terrain, in my opinion, is pretty great. It’s an excellent voxel solution that enables a variety of landscapes and creative freedom.
For procedural generation at scale, however, it’s pretty bad.
It’s fast, but not fast enough to generate hundreds of square kilometers of terrain in seconds. Remember, if players are moving at 1km/s, your terrain generation will need to keep up. 1km/s is also nothing – if you are trying to represent Earth, 1km/s isn’t even orbital velocity.
Ok, let’s just pre-generate the entire planet! No dice – you’ll hit Roblox’s server memory cap (~= 4gb (I think???)) way before you even have a large island.
Floating Point Precision will Ruin Your Day
This is the killer though.
The core issue to building at the scales you desire in Roblox (and in other situations too!) are floating point precision errors. If you have ever seen your Roblox character shake when far from the center of the world…
…floating precision is the culprit. Oracle does a pretty good job explaining it:
I would like to stress that floating point errors are a feature, not a bug. IEE 754 floating point numbers were designed with intention, and they do their best to enable high precision decimal representations while making sacrifices when possible to ensure good performance.
There are solutions to these problems. They are both miserable:
However, this solution is immediately off-the-table for you because you want to render this scale using Roblox instances, whose coordinates are 32-bit floats, not 64-bit floats. Oof.
The Floating Origin Solution
You could try to implement a floating-origin system instead. With a floating origin system, there are two coordinate systems: the world coordinate system and the local origin coordinate system. Every game object has set of world coordinates represented as 64 bit numbers. Another set of 3d coordinates is initialized at (0,0,0), let’s call this the origin position. At runtime, every object in the world is positioned relative to the origin position. So if the origin position is at (10,10,10), a ship has the world coordinates (-10,-10,-10), and the player is at (10,10,10), then the ship would be positioned in the Workspace at (-20,-20,-20) and the player would be positioned in the Workspace at (0,0,0).
This, of course, is not impossible to implement. However, with Roblox, it’s an extra headache because there is no good way to do selective replication of moving instances. This means you can’t use Roblox’s built-in replication to position parts in your floating origin system – instead, you will have to build a replication system from the ground-up to support selective realtime replication. I wrote about it here.
It’s a headache.
No Low-Level Management
In order to have large planets, having low-level memory management and control over rendering is a necessity. Low-level memory control allows your program to allocate memory for new planet features and immediately delete data that is no longer used instantly. Without low-level memory management, you are at the mercy of the garbage collector.
Additionally, because Roblox terrain is too slow, we will likely want to roll our own terrain system that uses wedges as triangles. However, each triangle created out of two wedges represents 8 wasted faces that must be represented as memory-hungry Roblox instances. I once again want to underscore that Roblox instances are pretty lean. It’s just when you need to render millions at once where you run into problems.
All of the above is so hard to implement in Roblox because Roblox does its absolute best to hide low-level control from its developers. This, once again, is a feature and not a bug. Roblox wants to build an engine that is simple and accessible. Exposing low-level details would raise the barrier of entry. In some cases, in order for Roblox to function properly, low-level exposure to certain parts of the engine may not even be possible.
For example, Roblox games run what we in the industry call “untrusted code.” Untrusted code is any code that is written outside of the dev team. This is code that can do anything. Roblox deals with untrusted code using a technique called sandboxing. In short, Luau code doesn’t have access to any functions that can modify the local user’s computer because it runs in an environment that only has access to functions Roblox gives explicit permission to use. This keeps things secure. However, there are performance and practical limitations to sandboxing – I’m sure low-level access to stuff like memory could be problematic here.
Roblox just isn’t the right tool for the job. That doesn’t make Roblox bad – it just makes it different.
This is like, maybe 3% of the problems.
But this post is long enough for me!
* Quadtree Planets (at much smaller scales) are Achievable!
I don’t like to be a nay-sayer, so I will leave you with this:
Quadtree planetary terrain is not impossible if you are OK with keeping the scale much, MUCH smaller – don’t hope for planets with radii exceeding a few thousand studs at MOST.
My good friend @Elocore has a working demo. He wrote the code, I did a bit of technical consulting to help him. It uses a perlin-noise procedural approach paired with subdividing quadtrees to achieve a planet effect.
Note these gifs represent a LOT of work. Even at a small scale, Roblox can make doing stuff like this relatively painful, and the system as a whole still has a few issues that will eventually get ironed out.
Pick a Different Engine
Roblox simply is not designed to deal with the scales that you demand.
In short, you are trying fly a used car to orbit. Use a space shuttle instead.
Hope this was helpful. If you have any questions, I’d be happy to answer them!
