So… this may or may not be a good idea or plausible, but I’ll suggest it anyway.
The idea is fairly straight forward, have 2 models already placed in the workspace, 1 high quality, one low quality, and render them based on the primaryPart distance from the focus point of the camera.
An example of what it would be is like
workspace:CreateLevelOfDetail(LowerQualityModel, HigherQualityModel, (optional) [Int] override)
The override ensures the the high quality model shows within the override distance from the camera/character (camera.Focus), maybe not call it “override” but instead distance until it actually renders the high quality one
Then roblox decides wether to render it or not based on quality settings, or make it configurable with more options, but not render both at the same time.
Creating proper models is up to the developer for it to work.
It would only be able to work for models that don’t move. Otherwise if a player in a car drove away from you the assembley would get all messed up if it swapped in realtime.
What if I shot a rocket and the rocket is supposed to destroy the part it hits, and I shoot it far away? The part references on the server would be messed up.
On top of all the technical hacks that would be required to make this work, loading and unloading massive amounts of parts (the amount of parts that would make an LoD system effective in the first place) is pretty intensive. I don’t think this would help with performance.
Well thats the idea, is non-moving objects. This alone could make a huge improvement if its all handled well on the C-side. its not so much unloading/loading a bunch of parts, but rather rendering or not.
It’s pretty much what AbstractAlex mentioned (< source >):
I'm not sure if they'd want to make LOD specific for static objects or wait until they can find a solution that works for both static and changing/"active" objects.
Well the point of this is say you have a fairly detailed house, you want to see that house in the distance, but not render everything on it to improve performance. Render distance wouldn’t render it at all.
If you did this in lua, the model swapping methods (setting parents, cloning, etc) is already in C. All you’d be doing is a distance check which is nowhere near intensive enough to require a C-side implementation to make feasible.
Although again, don’t think there would be any performance benefits really.
Setting parents and creating new instances both have high overhead. It’s obviously cheaper once the model isn’t being rendered, but that transition causes lag spikes.
I can see this working for both ‘active’ models and static models. If LOD models were treated as single bodies in terms of physics then they could have separate rendering and physics models. Joints would not work within a(n) LOD model, but a(n) LOD model as a whole could act as a complete body with joints connecting it to other bodies. Each LOD model would be treated as a single body similar to how each part or mesh is a single body. Attachments and other joints, for example, could properly target an LOD model as if it were a part.
A car, for example, could be made up of 5 LOD models: one body and four wheels. They could be contained within one normal model, which also houses joints that use attachments to connect them that are direct children of each LOD model.
The ROBLOX engine could even group close, connected LOD models (such as the car and its wheels) and do only one distance check and one LOD transition.