As a Roblox developer, it is currently too tedious to make Lighting effects like Sky, Atmosphere, SunRaysEffects, ColorCorrectionEffects, BloomEffect, DepthOfField, and BlurEffect render at a certain priority.
Issues:(I had a lot of trouble wording the issues so bear with me)
I can’t make one Atmosphere object render even if there is another one in the Lighting. In other words, if the client has an Atmosphere and the server suddenly adds another Atmosphere because an event is happening, the client’s Atmosphere is totally ignored and not rendered. When the event finishes and the Atmosphere inserted by the server gets removed, the one the client had doesn’t render at all. (Same applies to the sky)
It doesn’t need to be the server the one adding and modifying things, the client could have a loop to modify an Atmosphere object depending on where their camera is, but when the player enters a certain block another atmosphere could be added to override the other one. (This is needed for custom liquids like water).
The other objects ain’t much of an issue, since they do override each other in some way, for example, BlurEffect takes into consideration the object that is applying the most blur. Yet, I would like them to have a property so I can choose which one should be taken into consideration.
Main Issue:
Currently, I have to remove the default Sky and replace it with another one, then delete it and add the default Sky back. Why should I do this, when I could have a property that determines the priority at which the sky should render? I could just add the Sky/Atmosphere and remove them after without any issues since the default ones would render automatically after they get removed.
In case you still don’t understand what I am talking about, here is an example:
There is a ZIndex property under every GuiObject which helps you modify “the order in which a GUI renders to the screen relative to other GUIs”.
That said, I wish I had something like that for lighting effects.
Sample Feature: (This is an example which I coded so you understand)
In this video you will see that when I change the ZIndex property the Atmosphere with the highest ZIndex value gets rendered, while the others don’t and how convenient it is:
Though I understand I could remove temporarily the other objects and insert them back when I am done with the task. This feature I am requesting will reduce some coding time and will make development easier as well.
Thank you, focasds. (once again sorry if my explanation wasn’t clear enough)
Isn’t it better practice to set the values of the sky instead? Even so, parenting and unparenting are no more than two lines of code.
Although, an enabled/disabled property would be sufficient instead of rendering priority (only one is rendered at a time, no point in having rendering priority on something that doesn’t render). This is consistent with other lighting objects.
Since I believe you didn’t understand what I explained, I am basically asking for a property I can set on those objects so the engine knows which one to use. I understand they don’t render at the same time, but yet I want to tell the engine, “here use this one and ignore the others with a lower priority”.
Not at all, why store every Texture of the sky and replace them at run time?
You know how water behaves? Well, the Roblox engine automatically ignores the Fog and Atmosphere we have and it does its task of applying fog while our camera is underwater. This is another example of what the feature would achieve. That way I wouldn’t need to re-parent things back and forth.
No, it won’t be better, as it would be kinda similar to the behavior of parenting. You will have to disable the current sky and enable another one. I would like to insert one sky with a higher priority and when I remove it, the engine will automatically render the one before.
In other words:
Sky 1 → With priority 1
Sky 2 → With priority 2
Sky 3 → With priority 3
If the client inserts the Sky 3, it would render.
If the client inserts the Sky 1, while Sky 3 is in place, the Sky 3 will render.
If the client inserts the Sky 2, while Sky 1 and Sky 3 are in the lighting, Sky 3 will render.
If the client removes the Sky 3, while Sky 2 and Sky 1 are in place, Sky 2 will render.
I’m going to put a disclaimer here that I’m not here to argue but give suggestions on how this feature should be implemented.
Having a priority feature is great, but it doesn’t serve much of a purpose in this case. You’re not reparenting things back and forth but you’re changing properties back and forth. I’d argue that this isn’t different relative to parenting it to something else:
-->> current method
Sky1.Parent = ParentName
Sky2.Parent = Lighting
-->> new method
Sky1.Priority = 1
Sky2.Priority = 2
As you can see, it’s the same number of lines of code.
There’s also the reason that some things will have render priority because they all render (such as sound, where changing rendering priority can change how the audio will sound despite having the same effects applied), unlike this case, where only one skybox renders.
That’s not what I meant though, I meant something like this:
Imagine you have two Sky in ServerStorage and both have a Priority of 2, which you set while in Studio. You also have a default Sky in Lighting with a Priority of 1, which was also set while in Studio. (Just like you do for GuiObjects, you set their ZIndex in Studio)
When the game is running and an event happens, you parent one of the two Sky in ServerStorage to Lighting, and the engine will stop rendering the default Sky and render instead the new one since it has a Priority of 2.
When you remove the Sky after the event has finished, the engine will automatically render the default Sky again.
-->> current method (4 lines)
DefaultSky.Parent = nil
NewSky.Parent = Lighting
task.wait(5) --> Imagine this is the event time
NewSky.Parent = nil
DefaultSky.Parent = Lighting
-->> new method (2 lines)
NewSky.Parent = Lighting --> The DefaultSky stops rendering and NewSky renders now.
task.wait(5) --> Imagine this is the event time
NewSky.Parent = nil --> The DefaultSky will render again.
This can also benefit you if you have another script that uses a different Sky/Atmosphere object and instead of overriding the main one, you instead could just parent the new one and remove it afterward. That way you don’t have to make any if statements around to check if other pieces of code can override it.
For example, let’s say I have the server spawning disasters and setting up an Atmosphere that matches the disaster and all players are able to see the new change. Yet, the client might need to override that Atmosphere if the player is in like a cave. Instead of writing some sort of “complex” code. Having an Atmosphere with a high Priority can let the server insert the amount of Atmosphere it desires that it won’t matter to the client since the cave Atmosphere will always be rendering out of all the other ones. (Once you get out of the cave, the cave’s Atmosphere will be removed and the Atmosphere from the event will start rendering)
Also, the number of lines it takes for something to be made shouldn’t influence the decision of whether something should be added or not. There are many things in the engine that can be done in less than a minute yet they are offered to us.
There should be a separate feature request created like this one for atmosphere blending technologies, since most of the values are float or Color3.
However, with the entirety of the feature request posted here, I agree with all of it. However, an Enabled property like suggested earlier in the thread could suffice as well. I’m wondering why the Lighting service doesn’t have a property named CurrentSky and CurrentAtmosphere, much like the Workspace.CurrentCamera property. You can simply just add:
Hi @SubtotalAnt8185 and thanks for replying. Just wanted to let you know that I attached a video to the main post which will give you an idea of what the feature would look like. I do not agree with an Enabled property or a property in the Lighting (though the properties in Lighting can be added as ReadOnly and let us know which one is rendering).
Issues: (I had a lot of trouble wording the issues so bear with me)
Main Issue:
In case you still don’t understand what I am talking about, here is an example:
Sample Feature: (This is an example which I coded so you understand)