BasedLOD Usage
This post explains the ins-and-outs of using the system. I realize I write too much, so some sections have a TL;DR. And and then my yap fest.
This post assumes you followed the installation tutorial!
Intro & Disclaimer
Recommended to read this section
Keep in mind you should NOT expect that you’ll get good results from the generator for every model you throw in. You can always include a premade imposter (tutorial later). It is definitely possible for the generator to spit out models that have worse tris than the original, and sometimes it’s best to just leave your model to Roblox’s LOD system
Adding your models to the system
Recommended to read this section.
TL;DR for this section:
- Variation tags is how you add your model to the system, and your model will follow the settings for that variation
- Characteristic tags is how you describe quirks specific to your model. These are very niche, however, and you likely won’t use them often
Full section:
Adding an LODVariation tag is what makes a model able to be added to the system.
If you take a look inside the runner script, you’ll see it gathers all models that have LODVariation tags (.GatherLODTaggedModels), and then adds them to the system (.AddToModelSelection)
(the task.spawn is not needed, but just to signify the user that the method yields)
Every model added to the system HAS to have an LOD variation tag!!
You can gather your models to be added however you’d like, but given each model has to have a tag, it’s recommended to use the .GatherLODTaggedModels helper function.
Anyways, each model:
- must be a model
- must have 1 LODVariation tag
- can have a varying number of LODCharacteristic tags, but often none
Here’s my sample scene. I’ll be focusing on the small house right now. All the house needs, for this example scenario, is a LOD_LowDetailBuilding tag. This tells the system the house will use the settings under the LODVariation ‘LowDetailBuilding’. I’m not going to tag it with any characteristics, and most of the time you won’t, since those are for pretty niche cases.
Keep in mind, for the preset LOD variations, the name of the tag refers to the desired outcome, not the model itself. This was just a design choice I made for coherence. This isn’t always perfect, however, so sometimes guess and check is needed to find the correct fit for your model.
Your model has been added! Besides the lengthy explanation, all that really happened is the click of a button.
For the sake of it, I’ll add another model. Let’s add the car. The car is considered a ‘utility’ model, and I wish for higher quality outcome (especially since the car is mainly made up of meshes, you’ll want this), so I’ll choose LOD_HighDetailUtility
And it’s good!
I’d just like to include a little disclaimer here: Even though I’m using a car in this example, the system is only meant to work with anchored, non-moving models. Kind of a bad choice to use a car in the example, so just don’t let this confuse you.
The Preset LODVariations
Recommended to read this section.
TL;DR for this section:
- The name refers to desired outcome (a design choice)
- I created each ‘category’ by gathering a ton of related models, then testing and tweaking a variation on them until they all looked evenly good.
Full section:
The system comes with a bunch of preset LODVariations. It may look intimidating, but just bare with me.
As I stated earlier, all of the presets are named by the desired outcome, NOT the model being tagged. This is solely a design choice I made.
To catch you up with what each ‘section’ is meant for:
-
‘Building’ refers to, well, buildings. There’s currently LowDetail, MediumDetail, and CloseMatch. CloseMatch is NOT considered HighDetail because it tries to match the model while keeping the tris relatively low. (honestly, this is a bit of an odd choice and I might change it at some point)
-
‘Nature’ refers to trees, bushes, plants, etc. There’s currently LowDetail and MediumDetail.
-
‘Utility’ refers to generic props such as street lights, chairs, cars, lanterns, statues, etc. There’s currently LowDetail, MediumDetail, and HighDetail.
You may ask, what makes each of the presets what they are? (ex. what makes the nature variation for nature?)
How I created each preset is by gathering a bunch of models of similar category, plopping them into a test place, and constantly tweaking a variation until it looks good for all of the models.
For example, for the Building categories, I gathered a bunch of buildings of varying structures and complexities from the toolbox, and continued to tweak a variation on them until it gave good results for all of them. This variation as a strong middle ground, I could then pretty easily create the different levels of detail for that category.
LODVariations - Advanced
Only recommended for people who know what they’re doing
What are LODVariations literally?
If you take a look inside the system, LOD variations are tables of data, or settings, for how the system will work with your model.
(ex. one of the preset LODVariations)
Each variation includes some distance settings, which describe the distance away that your model swaps with it’s imposter model. They include the generator settings (for models that don’t come with a presupplied imposter). And finally they include some meta settings, which are things about the variation itself (these don’t have an in-game effect).
Within the Presets module (found in BasedLOD->Libary->LODVariations->Presets), you can find an ok explanation for each generator setting:
(I edited this to be easier to read incase you want to read it here)
I will not lie, the generator settings are very intimidating, and not exactly the easiest to work with. (If you are at this point in the tutorial and are maybe thinking you aren’t able to add your own LOD variation but want to, shoot me a DM. I can walk you through it or even make one for you 
)
How do I load my own LODVariations and how do you recommend I create them?
The template runner script actually comes with a very basic preset LODVariation
You’ll notice this preset has no Generator settings. This is ok, actually, and just means the system will expect that models tagged with this variation come with a premade imposter (hence this variation’s name being PremadeImposter). I’ll explain more on supplying pre-made imposters later.
Anyways, if you’re looking to make your own LODVariations, my suggested method is to create a separate place, create a script that directly uses the generator on a bunch of models in a container. The system can be ran on the server in Run mode, and you can quickly go back and forth from tweaking to trying.
I made a template script (which is the same script I used to make the presets!): https://create.roblox.com/store/asset/110955101161821/GeneratorTesterServer
- Insert the script into ServerScriptService, and add a StringValue beneath the script named “LODVariation”:
- The script expects BasedLOD to be in ReplicatedStorage, and a folder in workspace named ‘Folder’
Now, with this setup, set the value of the StringValue to the variation you want to tweak, add a bunch of models into the folder, and you have yourself a way to guess and check! It’s not the most streamlined method, but can be done pretty quickly if you get in the groove of using Run mode, quickly tweaking, and repeat.
The script will directly use BasedLOD’s generator and then pivot the result above your original model. In the screenshot above, I’m trying out the ‘MediumDetailBuilding’ variation.
DISCLAIMER: For some reason, the system gives different results on the server than the client. From what I’ve seen, the server generally gives better looking results. I’m not entirely sure why this happens.
LODCharacteristics - Advanced
Only recommended for people who know what they’re doing
Sometimes you’ll have a model that you want to tell the system to do things specific to that model. This is where characteristics come into play. Right now, there’s only 2 available characteristics, and they are pretty niche.
(The current 2 characteristics do pretty much the complete opposite of eachother)
Why should I use LODC_Dynamic?
- Tagging your model as ‘Dynamic’ disallows the system Swapper to move individual parts (BulkMoveMode) of the model, and instead makes sure it will only ever pivot the entire model at a time. When could this be useful? Imagine, for example, you have a building that has spinning ceiling fan inside. You probably don’t want the Swapper to individually move every parts of the ceiling fan because it could mess up outside scripts interacting with it.
Why should I use LODC_ForceBulkMove?
- This tag does literally the opposite of LODC_Dynamic. Instead of telling the system to not use BulkMoveMode, this tag forces the system to use BulkMoveMode. When could this be useful? Well, usually the system will dynamically determine if your model is chunky enough to use BulkMoveMode. The decision isn’t always perfect though, since there’s not an exact way to determine how frame intensive your model will be to pivot altogether. Sometimes it won’t choose correctly, and if this happens, you can use this tag to force the system to use BulkMoveMode on your model.
Pre-supplied Imposters
Recommended to read this section
If you don’t like the results of the generator, or want literal fine tune control over your imposter models, you can pre-supply them yourself!
The set up is relatively simple:
-
Create your imposter
-
Position it onto your original model
-
Create a folder under your original model named ‘LODImposter’, and parent your imposter to it
And you’re done! If you want to hide your imposter model in studio, you can do so through the BasedLOD plugin.
Simply select the imposter, and use the following buttons to toggle it’s visibility. Don’t worry, the system will automatically switch the model back to its original transparency at runtime.
Interacting with the system
Wip
Downsides
Wip