If I could, I would, but because of floating point error, the game starts acting weird at around 100k studs, which is ideally how big the planets would be.
So full-size, properly spaced planets is a no.
If only Roblox decided to actually add seamless teleports, I could simply just teleport the player to a new place when floating point error starts to occur
Although it wont be seamless, you could try a custom tp screen. You can try to have all parts get cloned into a viewport frame (if that wont lag, ive barely used vps before) which is set to the teleport gui.
It is a good idea, but because viewport frames are rubbish, the quality would look like poo, and it would take a long time to teleport, which kinda ruins the whole âimmersive experienceâ thing
Yeah, I did try to scale the ships down by 16x but that just made floating point error occur earlier, because the engine had to work with smaller decimal values.
I know that it is possible, as games such as Elite Dangerous, Star Citizen and No Manâs Sky all achieved it, but they obviously use way more advanced game engines, which Roblox just canât compete with.
Itâs all about perspective. You donât need to make the player travel thousands of thousands of studs, rather you just need to scale everything (except the player) down. While it is true you might run into precision issues as you subdivide, remember that the size of the moon is smaller than our thumb at armâs length. An image that spans millions of miles is shrunk to something smaller than 144x144 pixels.
You could shrink them as you move away, so you donât need to move them as far as getting that distance floating point error. This is done with a script that calculates the distance from the player constantly and apply that to object size. So itâs a combo of moving it and resizing it.
If I understand correctly, you mean to keep the player in the same spot, and then grow/shrink the planets as the player âmovesâ. I have thought about this idea before, but Iâm not really sure how to make it look good with multiplayer.
You just would hide the players and represent their general position as a âwarp pointâ and then the player has the option to tp to them. âtpingâ is just reordering the scene by moving the planets to be relative to this position (remember not roblox position, but a virtual position in âspaceâ) and then you unhide the given player. It will work out because their velocities will now be relative as itâs assumed that they arenât traveling hyperfast. No Mans Sky takes this same approach with its hyperspeed mode feature.
Hello, I see your problem and It is very hard to solve. However, I will try my best to help you! the challenge youâre facing is essentially how to handle large spaces and distances in a way that Roblox (or any game engine) can handle, while also keeping the gameplay and visuals smooth and immersive.
For your specific problem, you might consider using âlevel of detailâ (LOD) techniques not just for the visual aspects (mesh scaling), but also for the positional aspects. This means you would dynamically adjust the actual distances between the spaceship and the planets based on various factors such as speed, direction, and whether or not the spaceship is in subspace.
One potential solution to avoid sudden jumps of planets could be interpolating their positions between the normal and subspace states. If the transition between normal and subspace isnât instantaneous but happens over a certain duration (say, a few seconds), you could smoothly move the planets from their position relative to the spaceship back to their original positions. This way, the transition wouldnât be jarring but would appear as a natural part of entering subspace. Similarly, when exiting subspace, you could calculate the spaceshipâs position relative to the planets and then smoothly move them away to create the illusion of the spaceship slowing down.
-- ...
local transitionDuration = 3 -- time it takes to enter/exit subspace
local transitionStart = 0 -- time when last transition started
local transitioning = false -- whether we're currently transitioning
local previousSubspaceState = shipValues.subspace
game:GetService("RunService").RenderStepped:connect(function(step)
local currentTime = os.clock()
if shipValues.subspace ~= previousSubspaceState then
transitioning = true
transitionStart = currentTime
end
for i, v in pairs(Bodies) do
-- ...
if transitioning then
local transitionProgress = math.min(1, (currentTime - transitionStart) / transitionDuration)
if not shipValues.subspace then
transitionProgress = 1 - transitionProgress -- reverse if exiting subspace
end
local normalPosition = workspace.CurrentCamera.CoordinateFrame.p + (v.OriginalPositionConst.Value - workspace.CurrentCamera.CoordinateFrame.p).unit * distanceConstant
local subspacePosition = v.OriginalPositionConst.Value
v.CFrame = CFrame.new(normalPosition:Lerp(subspacePosition, transitionProgress))
-- handle mesh scaling similarly
elseif -- ... rest of your code
end
end
if transitioning and currentTime - transitionStart >= transitionDuration then
transitioning = false
end
previousSubspaceState = shipValues.subspace
end)
This code essentially interpolates the position of each planet between its position in normal space and its position in subspace over the duration of transitionDuration. This should create a smooth transition effect where the planets appear to move naturally when entering and exiting subspace. Youâd do something similar for the mesh scaling.
Remember, you may need to adjust it to fit your specific gameâs mechanics and style. Youâll also want to thoroughly test it to ensure it works as expected and provides a good player experience.
You can use streaming enabled and make it so that certain radius from the player stuff will appear or disappear depending on how far an object is to the player, it also helps prevent lag for huge games.
Wow! Iâm incredibly grateful for this idea, and I will definitely utilize it.
One question though: do you have any idea how I would sort out if the player goes past the planetâs OriginalPositionConst? Because if the player goes past it, or goes inside it, it will look like the planet just disappeared, which is obviously not good.
Either way, thank you so much for this response, I really appreciate it.
UPDATE: I have decided to use this method and combine it with another method, and it works almost perfectly. I can have planets millions of studs away from 0,0,0, but still not encounter floating point error.
There are a few visual flaws, such as a 1 frame period where the planets âdisappearâ, due to the fact that I am moving the ship back and then moving the planets forward, so it makes the planet appear to disappear. Hopefully I can figure something out for that problem, but aside from that it works amazing.
How frequently are you moving the player back? If itâs once a minute, perhaps replicate the playerâs ship and make themselves invisible then lock their camera for a split second and have it be scriptable and set it to their previous camera pose, wait a bit then return the camera back to normal, and destroy the ship at the same time
Thank you for the reply, but I found a solution literally about 30 minutes ago, and I am actually moving the player back 10+ times a second
My system allows travel at up to speeds of 10 million studs per second, and I can have planets/objects tens of billions of studs away, all while not encountering floating point error.
As I stated earlier, I managed to fix the 1 frame âdiappearingâ issue, and it all works pretty much perfectly.