So here’s the early stages of the map I’m working with. (Made by @Orlando777) Looks totally awesome, but I’m struggling to figure out how to actually make it playable, and it’s not even finished yet.
Leaving the map in workspace causes quite a lot of lag (I’m assuming rendering cant keep up) on lower end devices. Putting it in replicated storage and parenting only nearby chunks to workspace makes the game smooth and reduces memory usage a bit, but low end devices simply cant parent and unparent the chunks fast enough to keep up with the cars without freezing and stuttering.
Converting it to smooth terrain gives a good FPS, but the join time is huge and the memory usage massive. What else can I do?
Maybe try reducing the size of the chunks? I’ve scripted a couple of procedural terrain generators and I’ve always found that the world loads in more smooth the smaller of an area im trying to create at a time. There might be optimization issues for you since you’re loading already built sections instead of generating them on the fly with math.noise like I was but then again maybe not ¯_(ツ)_/¯
You could turn on StreamingEnabled. However, trying to support lower-end devices is really going to be annoying. I would just deal with the fact that people on really old devices are going to come and they’re going to crash. Unless you want to remove 90% of the detail you put into that map, I wouldn’t sweat it.
Maybe as @ColdSmoke suggested you can split it into priority levels and load the road immediately as the player moves, but load everything else with a for loop so it doesnt freeze? Also, maybe having the whole map but completely invisible in workspace to act as the collision mesh and then parent the actual non collidable map as the player moves along would help? I assume it wouldn’t have to calculate any physics that way.
You should figure out why low-end and mobile devices can’t keep up. Is it rendering? Is it memory (i.e. even with everything invisible or in ReplicatedStorage, there’s performance issues)? Is it physics?
If the problem is solely rendering, then you can use your existing parts solely for collision (make them invisible), then make a separate rendering mesh. An actual mesh will probably have better performance than a ton of parts. You can even use lower-quality render meshes while keeping the high quality collisions if rendering is an issue even when using meshes.
Also, if you find a solution that works for you, it would be nice to know what it is. You could respond to this topic with your solution someday whenever you figure it out. I’d be interested in hearing what works for this scenario.
Don’t benchmark memory bottlenecks that way. Putting geometry in ReplicatedStorage / anything other than workspace is inevitably going to reduce memory because less memory will be used for things like physics / rendering. It could lead to drawing the wrong conclusion if you assume memory stays the same in both situations.
I generally agree. If it’s the only test you do, or if you misinterpret the results, then you’ll draw the wrong conclusions. Testing with anything out of Workspace is not very useful.
I didn’t word it very well. Putting parts in ReplicatedStorage is not a comprehensive test for if memory is the issue. It’s a test to see if the device has enough resources to even download that many Parts and keep them in the game tree, so it’s not even solely testing memory.
“Memory” is the issue
Why
Fails with parts in ReplicatedStorage
Yes
Because this is the baseline amount of resources needed to download the data for the parts from the server, so if it fails then there’s clearly not enough resources. You can reduce the part count, but chances are the device is too low-end for it to ever work well.
Works with parts in ReplicatedStorage
Unknown
Because parts in ReplicatedStorage use less resources than they would in Workspace, memory could still be the cause if the rendering or physics data uses too much memory. This does narrow down the cause to either physics, rendering, or both.
I don’t forsee any reasonably modern device having an issue with this.
On second thought, perhaps it’s something I should have left out since it’s rarely ever a useful thing to test. I have a habit of including rarely-useful possibilities for “completeness”.
