As a roblox developer it is currently impossible to use the EnvMap system correctly to create realistic worlds, it needs a massive rework and here is why.
I have been facing massive issues with EnvMaps in my game as of recently, they look quite literally terrible and cant be controlled. Which has led me to further dig into roblox by using a multitude of tools such as RenderDoc to figure out why the EnvMaps look and behave so poorly.
Currently from what RenderDoc has shown me, EnvMaps are “generated” with a resolution of 128x128 pixels. How do I know this? Using RenderDoc to dump the current rendered frame shows the EnvMap 2D Render Target texture. Which as shown below here.
Now, this is a masssive issue because of how terrible these EnvMaps look on objects that clearly show the reflection of these EnvMaps.
Here is a great example of my game as to why these look awful.
Which leads me to my 2nd point.
Please, for the love of god let us control the placement and resolution of these envmaps. Static Cubemaps that are pre-baked are not only more consistent, it can be even better as implementing parallax corrected cubemaps is a possibility here, essentially fixing one of the issues shown above in the video. I currently cannot express my absolute hate towards the “automatic” generation and placement of envmaps. Sometimes these end up generating near a neon surface and will make every single specular object look like it became the sun.
This is a great video that explains the usage of parallax corrected cubemaps.
So please, can we developers finally get a more functional implementation of this feature that isn’t MEANT for mobile for once? I know mobile devices aren’t the most capable devices ,but having pre baked cubemaps that are static are not impossible on mobile. Unity, Unreal and other engines ALL support them on mobile.
I honestly hate the current state of EnvMaps as well. As you stated, there is no way to control the EnvMap at all! As a developer, you would actually want to have control when it comes to stuff like this, but Roblox pulls the funny and says this nonsense.
(also it is forced now so you cannot just not use it)
Automating something that shouldn’t be automated is hilariously funny. The best part is that old engines like Source, which don’t use automated hacky solutions, look 100 times better than whatever Roblox cooked up for us.
Not to mention static baked cubemaps dont suffer from the limitaitons as runtime generated ones and also take less processing power as they are well STATIC
This is something that holds me back as a developer on the platform as well. The EnvMaps are limited and aren’t enough to create a realistic Roblox game. Currently, we have to rely on other methods that negatively impact performance, and the overall quality of EnvMaps is poor. This greatly affects the desired “photo-realistic environments” that Roblox aims for. Not having control over EnvMaps actually contradicts their intended goal. In general, the EnvMaps are in a terrible state, and I wish we could have the option to place them or use a custom cubemap system, or if not at least their quality increased.
I personally never liked this current EnvMap system, especially the way its implemented
Personally this should be done manually instead of automatically as was mentioned, so i support this.
I totally agree, how is the current system good at all?
Its terrible. You cannot control their generation at all nor disable it correctly. They look terrible as soon as a surface has clear specular reflections.
One problem with implementing static cubemaps would be when should the engine decide when to create one. With features like Streaming Enabled and live physics, a scene may be extremely dynamic, so having it just static may not be always acceptable.
I think it may be useful for engineers if they were given what we envision such a system to look like. This gives a better narrative of what we want to achieve, rather than just saying “the current implementation is bad, fix it.” For example, there could be a new instance that gives user facing controls to the EnvMap. Here’s an example:
EnvMap inherits PVInstance
Properties
Enum RenderMode - How the map is generated
Automatic - Map is dynamically generated
Static - Map is generated once at load
Scripted - Map is only generated by scripts
Custom - User can enter a ContentId for the Map
Enum WrapMode - How the map interacts
Parallax
ParallaxCorrected
Enum EnvResolution - The resolution of the generated map
Level1 - 128 x 128
Level2 - 256 x 256
Level3 - 512 x 512
ContentId Texture - What RenderMap.Custom will use
Methods
ContentId Render - Forces map to be generated, and returns a rbxtemp assetid of the generated map
ContentId GetCurrentMap - Returns a rbxtemp assetid of the generated map
Static cubemaps are not generated during runtime. They are static because they are baked in studio before the game even runs. This reduces the overall performance impact of having to constantly bake new cube maps in runtime.
Which is basically the entire point of cube maps. You can’t make them efficiently during runtime without having massive quality loss.
Cube maps are meant to be baked before runtime. Not a singular engine I know of does them in runtime. If you would want runtime reflections you could as well just add SSR at this point. That fixes your issue with reflections not being represented for dynamic objects.
If you look at the video that demonstrates parallax corrected cube maps in the source engine. You can see you can define an area where said cube map is rendered as a box. Engines like unity and unreal do the exact same thing. This gives you great control over where cubemaps are rendered and from what origin they are captured.
A dynamic EnvMap implementation like currently is just unusable. Roblox can’t rely on runtime generation for them considering it is Raycast based. If they want realistic runtime reflections that consider changes from objects then we will need SSR or Planar Reflections.
I also agree. Roblox’s cubemaps are so bad. They’re so low quality that I could probably count the pixels that make up the images, and due to their quality, they stand out when they’re used around well-designed environments.
If there’s one game that shows just how bad that these “environment maps” look, it’s Royale High. Go to Campus 2 or your apartment and the smooth plastic(?) floor/ceiling makes it so easy to see the pixels.
Also, yeah, I agree about being able to set cubemaps’ resolutions and positions. During the limited time when I was messing around with the Source Engine, I think I liked having control over exactly where it would take the six photos from, and even what surfaces that any given cubemap would affect.
As far as I can tell, the only way to avoid using these bad cubemaps is to always set the “reflective” property on all parts to 0. That’s what I have to do in my experience just to make sure that these ugly cubemaps that I have no control over don’t show up and make it look worse.
(Also, Roblox, real life doesn’t have “light probes” but it also doesn’t have static reflections that look worse than the Source Engine’s, and it doesn’t have reflections that update at complete random. Roblox won’t try to get with the times and include somewhat “real time” reflections so they should just admit this engine is kind of outdated and just make the cubemaps work like Source.)
