Instance.Sky.Skybox

Proposal:
A New Class called “Skybox” (Inhereted from Sky)
The new class would have three additional properties to the Sky class, the properties being:
-Color3 ImageColor3 (Gives a coloration modifier in the same way ImageColor3 would for ImageButton under the GuiObject class family.
-Float Transparency (Allows you to change the Opacity of the Image)
-Int ZIndex (Allows you to choose its layer priority in the same sense as a GuiObject’s ZIndex would)

Usefulness

Now the main point of this is that we should be able to have Multiple Skybox’s in Lighting to allow a very powerful, robust way of making seamless environment transitions in terms of the sky.

Want to go from daytime to night time? Use the transparency modifier to transfer between two Skybox’s.
Want a seamless transition to night time with a clear skybox? Use the Image3Color modifier!
Want to create an amzing transition? Use both. Layer the night time and daytime skybox’s interchangeably to produce the best effect for your game.

This allows us to make seamless in-game environment transitions such as in space games going from the surface of a planet, to space, and back in a very manageable way. It allows us to create better weather effects, better lighting effects, and it’s just overall very empowering.

I want to be able to get the best out of ROBLOX in terms of envelopment for my playerbase, and this would certainly help that.

  • I would find this useful (Support)
  • I would not find this useful (No Support)

0 voters

9 Likes

I’d love to use HDRI images at some point. Great suggestion btw.

Do you happen to know how to add a poll to this?

[poll]
- Option 1
- Option 2
- Foobar
[/poll]

Thanks, much appreciated. Made the change.

I’d also like to see rotatable skyboxes. It’s not a conventional feature, but I can think of several reasons how I could use it.

We can already put multiple Skies into Lighting, why not just add these three properties to the Sky class?

That’s the whole point of inheritance in OOP.
Hence the new class

I don’t see how inheritance has anything to do with adding properties to an already existing class. What’s the point of making a new class that inherits from another class when there isn’t something else that also inherits from the root class? Why not just change the original class?

6 Likes

Also a way to have a skysphere option would be nice.

2 Likes

Do any modern games still use skyboxes? I’m pretty sure they’re all converted to sky spheres/ sky domes.

3 Likes

I would definitely support improvements to the Sky class, but there’s absolutely no need to add a subclass in order to accomplish that. Subclassing Sky would inevitably lead to Sky becoming deprecated and would contribute to API bloat.

There’s a time and place for inheritance; this is not one of them.
For instance, physical properties were similarly an addition to the previous behavior of Parts. Imagine if instead we had gotten a new subclass PhysicalPropertiesPart–insanity would ensue.

Here’s what I would find most useful (really just the OP sans skybox)

  • Multiple Sky instances can be parented to Lighting
  • Add Sky.ZIndex
  • Add Sky.Transparency
  • Add Sky.ImageColor3
1 Like

Two words: parallax scrolling

Alright I understand, thank you for making these great points

1 Like

I imagine a lot still do. I have to imagine it’s a bit cheaper to render.

I wish we could just set the zindex of a part manually so we could invert a sphere and apply images to it and make it so it renders behind everything else, allowing us to do all sorts of cool stuff like that…

1 Like

Yea we need parts with z-index so we can have massive 3d skyboxes, like mountains and such, especially since they’re adding meshes

The words you’re looking for are parallax scrolling. Skyspheres have that capability.

hence this reply

He’s talking about Rendering priority for parts over other parts specifically (regardless of which is closer in position), that’s way way different than parallax scrolling.

1 Like