SCP:Secret Laboratory plugin made for optimizing MapEditorReborn(ProjectMER for now) schematics using the LabAPI or EXILED Framework.
It works by destroying primitives for the server and sending clones of the primitives to the clients while simulating their collisions.
It also supports a feature to dynamicly spawn primitives around players.
It got also an API to create and handle client sided primitives (ClientSidePrimitive class).
You can ask me questions on discord (matmoth)

- Completely removes the performance cost of primitives, meaning that having 60/60 tps with multiple thousands primitives loaded is possible.
- Primitives are dynamicly spawned around each players, so that clients only have to spawn and render the primitives that are near them
The available commands are only debug commands made to have a better understanding on how the plugin manages the primitives and clusters. Also giving informations about loaded primitives.
- mero.clusters : Displays information about all of the clusters in schematics.
- mero.disable : Disable or enable the plugin for the current round, for testing purposes
- mero.displayClusters : Display in game via primitives the radius of all clusters for the sender
- mero.displayPrimitives : Display or destroy all of the client side primitives for the sender
- mero.info : Displays information about all schematics ( Total primitive count, client side primitive count, colliders count, etc)
- mero.realtimedisplay : Displays as hints the number of currently loaded primitives for the sender
what mero.realtimedisplay shows to a player, refreshing every second
- Make sure that your SCP:SL server version(14.2.2) corresponds
- Download the latest version of the plugin and place your .dll in the LabAPI\plugins<global/port> folder.
It's the same configuration for both frameworks, some labels may change. Default configuration :
# If the plugin is enabled or not.
is_enabled: true
# Displays plugin debug logs.
debug: false
#
#-------------Global Options-------------
# If the primitives that will be optimized are only non collidable
optimize_only_non_collidable: false
# Prevents group of primitives to be optimized (aka keeped server sided)
# Simply name one of its empty parents with one of the entered name here and it will be excluded.
exclude_objects: []
#
#-------------Schematic cluster splitting options-------------
# Could be quite hard to understand, more info in the plugin readme
# If enabled, splits schematics into clusters of primitives to then spawn them independently per players based on their distance to the cluster
clusterize_schematic: true
# Prevents group of primitives to be used by the clusters. Useful for skyboxs, outer walls of buildings and giant primitives that requires to be seen from far away# Simply name one of its empty parents with one of the entered names here and it will be excluded.
exclude_unspawning_distant_objects: []
# In units, the distance required for a cluster to spawn/unspawn its primitives to the corresponding player
spawn_distance: 50
# Adds a specific spawn distance for cluster of each entered schematics, bypassing the previously entered SpawnDistance
custom_schematic_spawn_distance: {}
# Should spectating players be also affected by the cluster systemIf enabled, when a player spectates another, it will spawn all of the primitives that the spectated player currently sees, otherwise spectators will see all of the schematics at all time
should_spectator_be_affected_by_distance_spawning: false
# Should tutorials be affected by the cluster system, if disabled, every tutorials will see all of the schematics at all time (useful for moderation stuff, etc)
should_tutorials_be_affected_by_distance_spawning: true
# Minimum size of a primitive before being considered as a big one (size = (scale.x + y + z) )
# Huge objects don't work with the cluster system and so they need to be excluded, prevents having to manually exclude each walls/floors of schematics
# Set to zero (0) to disable it, not recommended
minimum_size_before_being_big_primitive: 10
# For each cluster, number of primitives that'll spawn per server frame (higher count means quicker spawn but potential freezes for clients)If set to zero (0), each cluster will spawn its primitives instantly, 0.5 means 1 primitive each 2 frames, etc
number_of_primitive_per_spawn: 0.100000001
#
#-----Clusters Options-----
#In units, the maximum distance between a primitive and a specific cluster to be included in it, the more distance the less cluster will spawn
max_distance_for_primitive_cluster: 2.5
# Maximum amount of primitive per cluster, if reached, a new cluster will spawn and be used. The less primitives per cluster the more clusters will spawn
max_primitives_per_cluster: 100
If enabled, every primitives that are collidable will not be optimized. In case colliders in game are funky.
There you can add every object name that the plugin will exclude for the optimization. For example, if you set your config like this :
exclude_objects:
- 'ExcludedPrimitives'
- 'Skins'All of the primitives that have at least one of its parent that contains "ExcludedPrimitives" or "Skins" will not be optimized.
Example :

Note : If you put a schematic name in it, the plugin will exclude completly the schematic from the optimization process and none of its primitives will be optimized
If enable, the clutter system will be enabled. The cluster system means the splitting of each schematic into small clusters of primitives, used to then spawn or unspawn the primitives of the cluster to each player based on their distance with the position of the cluster.
Same system as exclude_objects, every schematics that has a parent with the same name as one written in the list will be excluded of the clusters and will be spawned with the schematic without being spawn/unspawn to players.
Usefull for large outside walls of buildings, huge text, logos, walls and floors of indoors builds, etc..
The distance between the cluster and the player needed for the primitives of the cluster to spawn/unspawn from the player, a larger distance means that more primitives will be spawned to players at the same time, you can match the distance with the natural fog in game if needed.
Overrides the default spawn_distance value for specific schematic, if a schematic isn't listed in this property, the spawn distance will be the spawn_distance value.
For example, setting this :
# Adds a specific spawn distance for cluster of each entered schematics, bypassing the previously entered SpawnDistance
custom_schematic_spawn_distance:
Underground: 2will change the spawn distance for the schematic name exactly "Underground" to 2.
If enabled, spectators will load only what their spectated player sees, while it's being updated at the same time.
If disabled, all spectators will have all of the schematics spawned everytime whoever they spectated.
The only downside of enabling it is that when spectating new players, their corresponding primitives takes some times to spawn and as such it could be disturbing to watch.

Same principle as the one above but for tutorials, mostly made for helping the moderation, taking screenshots from far away, etc...
When a cluster has to spawn primitives, a fade option is available so that primitives takes multiple frame to spawn, preventing unpleasant freezes from players when trying to load a huge amount of primitives/clusters. The recommended value is between 0.2 and 1 primitive.
-1 = instant spawn 0.1 ... 0.9 = 1 spawn each X frames (0.2 = 1 spawn every 2 frames) 1 ... ∞ = X spawn per frame (2 = 2 spawn per frame)
Big primitives ( such as walls, roofs, stuff like that ) are not clustered by default, simply because huge objects are more likely needed to be seen from far away, and it doesn't match with how the cluster optimisation work So, if a primitive total scale (x+y+z) is higher than this value, it will not be in any cluster and will be spawned for each players independently from where they're located.
Clusters works via an algorithm that, starting from the center of the schematic, get every primitives around it within a specified distance until it's full, if there are no more primitives to get around it or if it's full, another cluster will be spawned based on the closest primitive of the center that is not in a cluster yet, and start again
The maximum distance where primitives can enter a cluster. The higher the value the more primitives will enter, lowering the quality of the client side optimization.
Maximum number of primitives that can enter a cluster The higher the value the more primitives can enter a cluster, lowering the quality of the client side optimization.
For both of the above values, the more cluster is spawned the more the server, depending on its hardware, will potentially lag.
- Quads and Planes with collisions WILL be optimized by the plugin.
- For this plugin to work without breaking any in game system, the real colliders detecting the players are spawned at 2000 units above the real clusters, each player also has a rigidbody+collider 2000 units above them for the colliders to detect them, so if you have any playable area at 2000 units above another one, colliding issues could appear.
- If you're using AMERT or some sort of external plugin that interacts with in game primitives, be sure to use the exclusion feature to exclude every object that the plugin could use (for example with AMERT, every object with scripts, animations, etc.)
If this doesn't work, feel free to reach me via discord to find a solution. - SCP 079 can't use the clusterize option for now, if a player is SCP 079, he will load every maps at all times to prevent desync and stuff
- Plugin made by Math
- Original idea/sample code by a friend
- Example map in this readme is also made by a friend
Thanks to a lot of members of the community for helping me find issues with the plugin.