When a WorldModel is a descendant of the Workspace and StreamingEnabled is on, parts within it are not replicated to the client as expected. However, the parts are never streamed in after. If the WorldModel is placed in ServerStorage on the server so everything is removed client-side, and then its placed in ReplicatedStorage, all of the parts are replicated, and, then, parenting this to the workspace, these parts remain replicated.
This bug happens in any live game and in studio when StreamingEnabled is on and a WorldModel is located in the workspace and contains parts.
This bug started happening at least since update 474, but, I would assume its been happening before then.
Repro steps:
Create a new Baseplate map.
Insert a WorldModel into the workspace. Insert a Part near the origin.
Hit Play. The part should replicate just fine with StreamingEnabled off.
Now turn on StreamingEnabled and hit Play again. The part won’t be replicated.
Stop the simulation and move the part outside of the WorldModel and repeat the above steps. The part replicates as expected with or without StreamingEnabled on.
I know parts under a WorldModel under Workspace will normally render as if they were just in Workspace, but there will be no physical interaction between those parts in the WorldModel’s physics world and the parts in the Workspace world.
Of course the parts under the WorldModel will never simulate as well. They’ll just be static ghosts to the rest of the workspace.
We intentionally chose this behavior, but honestly had no idea what people would use it for. I’m curious what your use case for this is without a ViewportFrame involved?
My game generates very large maps, and, I wanted a way to performantly load and unload big tiles of terrain on the client, so, I decided I would break up the terrain into one or more WorldModels and that way I could use FindPartsInRegion3 (instead of FindPartsInRegion3WithWhiteList) and it’d only have to check the parts under the WorldModel (meaning I could more easily break up the region3 checking spatially).
I wasn’t aware that physics wouldn’t be simulated, which, wouldn’t have been a problem for me since the terrain is anchored anyway, and, I already assumed stuff like raycasting in the workspace wouldn’t work correctly, which, made sense to me. (Collisions were simulated when I ended up testing)
In hindsight it makes sense for why the behaviour was chosen and it probably wasn’t a great idea to use WorldModels for what I was doing. I was a little confused why something like that would have slipped by this long if it was unintended.
I also was curious on whether or not WorldModels could benefit performance at the cost of a lot of functionality since they’re so much more basic, and, I was curious on what the memory impact was, so, I decided it wouldn’t hurt to test it out even if I wasn’t going to use it
I see. I don’t think you’re likely to see much of a performance advantage here since moving the WorldModels in and out of the DataModel is probably going to have the same overhead of adding and removing the same stuff from the Workspace, if not more. In general WorldModels have their own copy of the physics engine, with the initial size of the internal buffers being much smaller.
Something to keep in mind is there is a (currently very high) cost associated with very large white/blacklists (but we’re working on that). Depending on how narrowly scoped you need this to be it might make sense to do most of your filtering/group afterwards. Right the cost of filtering scales roughly O(partsInRegion * itemsInWhitelist). Our broadphase already spatially partitions up parts in the world to keep partsInRegion that we need to filter check reasonable, so you hopefully shouldn’t have any reason to sub-divide your world for us at least.
If you’re already using streaming that should hopefully already solve your large worlds problem for clients.