Immersive Environments V2 - Advanced 'Package'-Based Audio and Lighting Control

Hi there and Happy New Years!

Immersive Environments is a robust and feature packed system that can elevate the degree of control and detail in your game.

IE has been updated to V2 woooo!! - check out this post for information on what this update entails. Because IE V2 is not backwards compatible, please check the post and example place for guidance on conversion

Check out the GitHub Page for more information: GitHub Page
Check out the GitHub repository to view source code (in Rojo format): GitHub Repository
Download the model here: Roblox Library Model

Example place (open-sourced) with Immersive Environments in action.
Check this out to see how settings can be configured: Example Place

Set up instructions are also included on the GitHub Page

Thank you for 1,000+ library downloads!


Immersive Environments (IE) is the successor to Truly Dynamic Lighting (aka TDL). Originally named Truly Dynamic Lighting 2, the focus of the project was shifted to overhaul the initial framework and direction of the system, while also meeting all of the current, anticipated, and potential needs of my current project. IE features all of the same settings as TDL, and also features a host of other new features, settings, and optimizations to expand developer creative control.

The final product is a robust system that allows for time-based and region-based lighting and audio controls.

What Sets Immersive Environments Apart

  • Easy Set-up - IE uses a simple modular setting system, and is designed for people with 0 programming experience. Compared to TDL, settings are now in a much more readable format to streamline editing, organization, and comprehension. IE is built to be set up in Studio (also Rojo comptabible) and ran with a single line of code

  • Scalable to the Extreme - IE’s Lighting system is a class based manipulation system. While it is tailored to settings based around lighting, the lighting system allows for the manipulation of any class of instances. By default, IE is set to work with instances in the workspace and lighting services, however, it is relatively simple to edit the system to expand its capabilities to include other services.

  • Server Side or Client Side IE Instantly - Lighting can be very tricky, especially when the server and client are simultaneously vying to control things. IE allows you to client side the entire system with the flip of a setting. The best part is that, even when IE is Client Sided, you still run it through the server! This allows you to track changes and automatically replicate lighting and audio settings to players without having to worry about complex remote functionalities!

  • Auto Calculated Tween Starts - IE, like TDL, features a system that auto-calculates how fast time moves in your game (i.e. the speed of your Day/Night cycle) and will automatically adjust your audio and lighting periods so that the completion of the setting changes corresponds exactly to the beginnings of your audio or lighting period. This can be disabled as well.

  • Blazing Fast and Lightweight - IE is designed to load fast, get the job done, and do all of this with minimal performance impacts. While running a test of IE in Roblox Studio, I was able to get >300 FPS, initialization times of approximately 9 * 10^-3 seconds, low CPU usage, and low script performance activity. IE also offers different settings to enhance performance as well.

  • and more…

More information on…

Audio Controls

Immersive Environments utilizes a categorical audio definition system. Audio is split into four different categories: the SoundService, server sounds, region sounds, and shared sounds. The later two categories are only used for regions.

The SoundService is a built in service, but it is criminally under-used by developers. The SoundService allows for manipulations to AmbientReverb, which adjusts the ambient sound environment preset used, and other useful settings for controlling 3D sound. If you are not familiar with it, I highly recommend doing some research on why this service is a great tool.

Server sounds are sounds that the entire server can hear. An example of this is a nature ambience for a game that takes place in a forest.

Region sounds are sounds native to a region. An example of this are the sounds of background noise when entering a restaurant.

Shared sounds are sounds that are native to multiple regions. An example of this is a three room building, with music playing from a radio in one room. Using shared sounds, you can precisely tailor how loud the music of the radio or other actives sounds behave in each room. This is particularly useful while also combining SoundService manipulation (AmbientReverb in most cases).

While the lighting system is, in a broad sense, a class manipulation system - the audio system is tailored specifically for audio related instances. Instances in the class of SoundEffect are not currently supported, however, those may be added in at a later point to expand developer creative control. Audio behaves similarly to lighting, in the sense that you can control for different audio triggers, depending on time or region.

The IE audio system also features a special category of random sounds. These random sounds are native only to regions, but allow for randomized sound generation. Developers can specify the frequency and chance of playing that a sound has. An example of this, is the sound of a gun being fired. By manipulating the frequency in which the sound might play and the probability that the sound actually does play, a truly unique environment such as a battlefield can be easily generated.

Lighting Controls

Immersive Environments uses a class-based manipulation system that is tailored towards classes normally placed in the Lighting and Workspace services, as well as the Lighting service itself. However, it is set up to work with any class of instances

(Warning - it is expected that IE will be compatible with nearly all class properties, however, using it on untested class properties may result in errors! With this in mind, please note that any changes regarding classes that are children of the Lighting service are possible to use with classes of other services!)

Create different lighting settings, or profiles, depending on either time or region (more on this in the Time and Regions sub-sections). Here’s an example of how this might play out

Time based example

As the sun begins to set in-game, smoothly tween to new lighting settings by changing depth of field to reduce vision, adjust the color correction to a slightly more blue effect, and “turn on” torches by enabling fire, smoke, and a particle emitter for greater effect. At midnight, reduce the depth of field again, and make minor changes to lighting effects. Reduce the fire and smoke of the torch to visibly give the torch a life of its own. As morning creeps, extinguish the lights, make changes to the game’s sun rays to prepare for a bright and beautiful start to the new day. Ambitiously, (since IE is a class based manipulation system) have the doors of shops smoothly open as the business day begins.

Region based example

A player ventures into a local blacksmith’s forge. As they enter the house, the color correction shifts to become more orange and the blur increases because of the heat. Various furnaces begin to smoke as well. Once the player leaves this house, their lighting settings quickly resync to that of the server.

These are immersive environments.

IE also features unique lighting settings and capabilities that set it apart from other similar systems.

In your lighting settings, you can create randomization for each instance affected. This is great for generating dynamic environments (ex: cities where 80% of the lights turn on at night).

One of TDL’s strongest selling points was its ability to control complex instances (previously known/referred to as multi-instances). If you are not familiar, please imagine a lantern model. The lantern model might have an actual part (yellow and neon material), a participle emitter for effects, and a point light for providing light effects. IE allows you to fully control this complex instance by indicating a reference part, indicating the relationships of instances that you want changed (ex: siblings, children, descendants, parents, etc.)

Complex instances also support randomization, so you don’t have to worry about smoke appearing while the rest of the light is not on, or other weird situations.

This is tougher to explain, so please refer to the time-based example above. Imagining that we have 200 torches (each with a 50% chance of turning on), we will have approximately 100 torches once night falls. When midnight comes, we only want to reduce the smoke and particle emitter properties of torches that are on. It would look strange if some suddenly sprang to life, and might ruin the effect. You can denote these torches as lights that are “on” within the settings of both periods so that lighting changes only affect lights that are “on” or that after a lighting period comes to pass, the lights are considered “on”. This can be applied creatively to generate unique game environments.

Region Controls

Regions are handled using @VerdommeManDevAcc 's Object Tracker & Area Manager module. This allows for efficient and fast tracking of regions, with minimal performance impacts.

Side note: If you wish to change IE to a different module, check out the RegionHandling module and make changes there. It should be relatively straightforward.

IE uses smart checks to prevent region glitching and can handle overlapping regions, which greatly expands the creative potential of developers - particularly when paired with shared sounds.

Here’s an example of where this might be handy - when entering 3 regions that all exist within one another (imagine a giant house with different overlapping regions for the house itself, the floor you are on, and the specific room you enter), the settings for the most recently joined region are always applied. IE also tracks the order of regions that you have joined, so if you leave the most recent region (while remaining in the other two regions), IE will automatically adjust relevant lighting and audio settings to the next most recently joined region that you are still in.

Weather Controls

Immersive Environments features a weather control system for developers to leverage. In a sense, the weather system can be thought of as manual triggers/overrides for the current lighting or audio cycles. IE separates weather into lighting and audio categories. This allows developers to mix and match weather settings easily. An example of this is having one lighting profile for a thunderstorm, but three audio profiles for the sound of thunder and lightning, to create variety.

Weather, by default, halts the cycle of either lighting or audio (depending on whether lighting-based or audio-based weather is active). Developers can control whether regions supersede active weather. For example, regions that are outdoors may seem unnatural if they are unaffected by weather. Regions that are indoors may have their effects ruined if their settings suddenly change, despite not being close to the outdoors at all.

Because weather mixes both lighting and audio, it is possible to generate custom events that are not inherently weather or climate related. Through tailored configuration, it is possible to generate fireworks displays, firestorms, sudden ambience changes for an environment like a club, etc.

API and Settings


  • PackageName is the name of whatever your package is (this will be the folder name under Packages)
  • PackageType is always either “Audio” or “Lighting”
  • All API calls should be done from the server, with the exception of Main:Run() which should be called once from both the server and client

This runs IE - call this before interacting with anything else in the API

Main:SetServerPackage(PackageType: string, PackageName: string)
This sets the server package.

Main:SetWeatherPackage(PackageType: string, PackageName: string)
This sets the weather package

Main:ClearWeather(PackageType: string, PackageName: string)
This clears the weather package

Reminder: regions are handled automatically, hence why there is not any API for them

Here is some example code:


local ReplicatedStorage = game:GetService("ReplicatedStorage")

local IEFolder = ReplicatedStorage.IE

local IEMain = require(IEFolder.Main)


IEMain:SetServerPackage("Audio", "Default")

IEMain:SetServerPackage("Lighting", "Default")


local ReplicatedStorage = game:GetService("ReplicatedStorage")

local IEFolder = ReplicatedStorage:WaitForChild("IE")

local Main = require(IEFolder:WaitForChild("Main"))


Assuming I have two packages, one audio package called “Default” and another lighting package called “Default”, this will work perfectly.

I highly recommend playing around in the example place to get an idea of how to deploy IE V2.

Settings are included and described within the module. They are very similar to the V1 settings with some changes, removals, and additions.

For more information, please check out the GitHub Page here!

Thanks and let me know if you have any feedback!


Great module! I know I will definitely be using the weather controls verrrrrry soon. :smile:


Small update/patch:

  • Added a fix to a bug caused by disabling the EnableSorting setting (previously wasn’t behaving properly and would result in an error). Thank you @NovaCoepta for keying me in on that one.
  • IE now doesn’t panic when folders (ex: AudioSettings>RegionSettings) are removed - because realistically not every feature of the system is going to be used by every developer.

The changes should be reflected in both the Example Place, GitHub repository, and Roblox Library.

Thank you to everyone who has provided feedback on IE. Much appreciated :slight_smile:



  • Added a fix for the AlwaysCheckInstances setting that will prevent region glitches
  • Another fix was prevents breaks that would occur in situations where no audio or lighting time periods are added. IE will still throw a warning to you, but this can be disregarded or manually disabled since some people may only use IE for the region control.
  • IE now does a better job of actively warning you before an error occurs when attempting to create a new region that has the same name as an existing region

The changes should be live on the Example Place, GitHub repository, and Roblox Library.

Thank you @Dominusemprayus for the feedback that led to locating these problem areas.

1 Like

I have everything set up. I followed the tutorials, and it is not functioning in my game. Any solving?

If you could message me privately with a stripped down version of your setup (with only IE) or your full project (if you’re comfortable) I can help debug any issues.

Okay. Where I can message you privately? Sorry for the late response.

Thanks for making this system open-source! I was working on something vaguely similar and your work just summed up pretty much a lot of headaches, I do have a question, if I wanted a region that was beyond the limit of the part size (2048) how would I achieve that? I’m doing this for multiple islands.

1 Like

This would be a question best suited for @VerdommeManDevAcc who created the module that handles region tracking which IE uses. I’m not sure if OT&AM (his module) tracks unions or models, which is what you’d probably want there.

You could also go for the ‘hacky’ solution of just creating overlapping regions with identical settings. This would give it the same behavior as a single large part if the settings are the same.

1 Like

Thanks! just went ahead and did the hacky solution, works perfectly.

1 Like

Hey, my module (OT&AM) doesn’t have any size limits for regions, it has two methods for adding regions

module.addArea(identifier, basepart)

which just calls
module.addArea(identifier, cframe, size)

so what you can do instead of the hacky method is just using the second method

I see only now that my API is not very clear on this.

1 Like

Does this script is break, i only see green thing and its not beutiful

Check out the example place, which shows IE in action. All of the sounds and colors in the example place are used for demo purposes (since in an actual game you would rarely need that level of drastic color changes).

All of those settings (colors, sounds, etc.) are all customizable. However, you will have to change the settings yourself and tailor them to your project.

Oh sorry i didnt understand how this work

69th like :wink:

Very nice release, will be using this in my games.

1 Like

This is pretty impressive, though the only thing I’m not a fan of (this is kind of nit-picky), is that editing the settings requires you to directly edit the Settings.lua file.

This is fine in most setups (i.e. if you’re using the model), but if you’re using this module as a git submodule in a Rojo project, then it requires you to edit one of the submodule files - this isn’t really ideal since you shouldn’t (really) be editing a submodule directly. You would normally create a fork of the repository and add it a submodule if you wanted to do this, which isn’t really ideal just to change the settings.

My idea is that you could have settings be changed like you would change bubble chat settings, which is through Chat#SetBubbleChatSettings(settings : table). Ideally this would be called on the server before Main#Run().

1 Like

Can u tell me script for day night cycle with custom ambient using this module.

I’m not sure what you’re asking here.

IE has a built-in day/night script, but it can also be set to sync to an existing day/night script. Ambient changes can be generated by adjusting the settings for each period of time.

Can u just make tutorial on this module? Kinda confusing me as I m not a good scripter.

I will probably make a tutorial in the future, following the update I’m working on right now. The update should simplify things considerably and add a lot more options to experiences.

Until then, I would recommend going to the example place and around with the different settings and configurations to get a feel for it.

1 Like