As a Roblox developer, it is currently too hard to make a game with an extensive amount of terrain without the performance impact that the voxels of terrain bring.
If Roblox is able to address this issue, it would improve my game / my development experience because it will allow for developers to add more expansive areas of terrain. My game in particular is very dependent on the use of terrain as it shapes the map where the roads go etc. If a streaming option for just terrain this means we can fine tune the distance the terrain is loaded and unloaded, it will also mean that the players on low end machines won’t struggle rendering the terrain across the WHOLE map as using the current version of streaming breaks a lot of in game scripts as they rely on parts which get unloaded, making the game unplayable.
It would also be amazing if a player option could be enabled, expanding the use of an in-game menu/settings feature to allow the player to customise the render radius/distance for the terrain, depending on their preference or machine!
Why do you need a streaming option for just Terrain? How come you can’t use StreamingEnabled for your project?
When parts get unloaded it breaks some
of our core scripts as they get “deleted” or removed from the workspace when unloaded and scripts aren’t able to access or find them, WaitForChild also has an infinite yield when called on the parts in question.
As per the StreamingEnabled wiki article, it says:
The downside of network streaming is it means the client can no longer rely on specific objects being available. Developers should not enable StreamingEnabled unless they understand its implications and have put processes in place to manage them. For example,
LocalScripts may have to use
Instance:WaitForChild in order to access parts of the game.
You’d need to check if the client can actually see the parts you need.
WaitForChild’s second argument is a timeout; for example,
local Part = game.Workspace:WaitForChild("ThisPartIsFake", 10)
--If the part exists, it prints it.
--After ten seconds, if the part doesn't exist, Part will be nil.
There really needs to be better alternatives for the current terrain loading. The voxel system uses an insane amount of memory and bandwidth. The way it loads now is the equivalent of having the game server send each client individual mesh’s vertex data instead of mesh IDs. When our game switches maps, loading a full large-scale terrain map can take over 50 seconds due to it sending each individual voxel to 60+ connected clients. Awful.
I was thinking that a system to package and publish Terrain with a TerrainID would be good, that way the server only needs to send a changelist of voxels that were added/removed and the client can load the Terrain itself from the CDN where it loads meshes or whatever. Having StreamingEnabled constantly loading in/out chunks of static terrain just seems silly when the client should be loading/unloading the terrain based on its own graphical settings. In general the approach of having everything in workspace automatically try to replicate to every client is a bit annoying
Check out the post I made and please respond to it so it goes at the top of engine features and get the attention: Features that needs to be added to the Terrain System