It would be awesome if terrain could be loaded locally per client! More specifically, using Terrain:PasteRegion in a LocalScript with FilteringEnabled on.
I’m working on a disc golf game, and the courses are created with a mix of parts and terrain. The problem is that the current setup forces me to load the terrain server-side, thus for all players. That’s not ideal for the current setup, which allows multiple matches to be running at once. If I were only using parts, I could load it locally and it would be fine. However, terrain can’t be done that way currently.
Perhaps there’s a highly technical complication that prevents this from being possible. If not, it would be sweet to be able to do this.
Can’t you design a whole park that incorporates all the courses on a large amount of terrain? Then you can make the camera circle over the whole map as a sort of intro, and when the game begins you can smoothly transition the camera to the course that the player is playing on, for example.
That’s my current work-around, but I don’t like to do that because that means I’m using way more resources for each individual player than I need to. I don’t want to have a huge terrain map loaded if I don’t need to.
The reason you can’t do this right now is because TerrainRegion contents is not replicated.
And the reason behind that is that the implementation is complicated, so we decided to skip that when implementing TerrainRegion.
Since you can put your entire terrain into TerrainRegion, we can’t implement replication of this object as we replicate other objects - or the client would be forced to synchronously receive a property worth hundreds of kilobytes of data.
To make this work, we’d have to implement “data streaming” for this property - replicate parts of the region without disrupting other objects - which is similar to the current support for replicating terrain contents. And I guess we’d introduce a DataReady property on the region object so that you’d know when the replication is complete.
Note: of course, you can do this yourself by reading data from terrain in small chunks (e.g. using ReadVoxels/WriteVoxels API from smooth terrain - assuming your terrain is smooth, of course), manually serializing it into strings and sending them via Remotes. Which is a bit painful - you’d have to optimize for bandwidth by efficiently encoding terrain data.
I can’t tell if we’re on the same page. I think we’re trying to avoid the networking all together. Setting terrain locally should behave the same as placing parts in the workspace locally (with FE.) This can be used to create a local map that could even be different from the one on the server.
I’m haven’t experimented with it yet, but it’d probably use local procedural generation. OP’s optimization could probably be done automatically by ROBLOX?
I’ll mess around with this when on my laptop, I’m not too familiar with the Terrain API
