just discovered this video about a hack week project from 2015.
2015.
(give this entire video a watch btw, really interesting stuff!)
what’s crazy to me is that it’s just a 1x1x1 stud grid of voxels, no pixelated shadow maps, or performance draining future lights, just voxels.
this isn’t exactly related to the light range of lights, but my point is to show what is and has been possible this entire time, if the lighting system were to be given more attention.
I believe there are multiple factors in place why roblox lighting is so terrible
Shadow Bias. There are even fast flags to set this but they are incredibly broken.
Shadow Atlas Resolution (By default its a really low value)
Shadow Resolution
Terrible code and inconsistency for light types (surface lights compared to other lights have terrible sharp shadows)
In general this engine is just unbelievably far behind, decades to other engines.
We have no:
The list goes on but i dont even remember it anymore, there is just so much.
This can still be done, but requires you to use IDA and disassemble Roblox studio. You can change the voxel generation size so a ridiculously small value and it doesn’t even run that bad.
You need to fix the update rate for voxels though, their update rate is very slow by default.
Exactly this, I have pointed this out so many times on threads now and its getting on my nerves.
My games audience isn’t meant for mobile and because the engine lacks such visual features makes it look really bad on PC or new gen XBOX consoles.
Its unbelievable how far behind we are.
WHAT THE HECK
This is from 8 years ago and it runs so well.
The same person who made that Hack Week tech demo made another video the next year for that year’s Hack Week, which features some explanation for why they thought, after some time, that the whole voxels thing was not a good idea. Eventually, what was shown in the video made it to Roblox:
@MCWither_Storm Apparently Future Is Bright ran and looked better than the 1x1x1 voxels.
The same person who made the previous two videos mentioned wrote up a full post detailing exactly why having a custom shader system is difficult for an engine like Roblox. From picking a good language, to compiler issues, to “What if we need to change parts of the rendering pipeline in the future?”, I believe what you mention is answered as well.
Here it is:
Those are the same thing? Well, not literally the same thing, but having baked lightmaps means that lighting is static. But, one of Roblox’s goals with the engine is for everything to be completely dynamic, and they have succeeded. Nothing is baked-in, all lighting is dynamic, and yet there are still good-looking games like Frontlines.
Roblox has PBR support? I don’t know what you mean.
“Physically-Based Rendering (PBR) textures allow you to represent realistic shading and lighting by using multiple types of texture images, or maps, on a single object. Combining multiple texture maps can more accurately simulate color, roughness, and reflectivity in any lighting environment and can enhance the visual elements of your assets and environment.”
Minecraft Bedrock Edition uses this same Technology for their RTX graphics mode. You use multiple texture maps, and it can even look 3D if you do it right!
It makes things look pretty good. (Used in layered clothing on Higher Graphics Settings)
//////////////////////////////////////////////////////////
I feel like they DO need to remove the limit. This topic is just like the Minecraft Bug MC-2 was for the LONGEST time. The second bug report ever for Minecraft.
I dont mean the textures themselves. I mean how much a light instance affects each part of a object.
You can look at it in blender which shows exactly what I mean.
They should also increase the max part size.
Why though?
Oh yeah, terrain isn’t good.
If they put math.huge, it means they want an infinite range, not 60. If roblox increases the range, it would be better for them.
I was not actually trying to say that I don’t know what PBR is, I was just asking for more explanation and suggesting what I thought they were trying to say. Sorry for the confusion! I read it now and realize how someone can mistake what I am trying to say. I will make sure not to use that specific wording anymore.
It’s ok! I’m sure that some people will be hearing the term “PBR” for the first time when I mention it.
I think that you can control these with SurfaceAppearance’s, which is how you use PBR in Roblox.
Ah. Ok. I know most of my friends don’t know what PBR and RTX are.
Agree, actually doing a backrooms game and this feature needs to come in hand, Roblox.
This is miserable to acknowledge, knowing that we had the technology to implement things like this, but nooooo for some reason ROBLOX just doesn’t want to budge
What’s worse is that Voxels could’ve looked really really good but today’s Voxel is DISGUSTING
Not to be ‘that guy’, but I’ve seen a whole lot of armchair experts in this thread talking about mobile performance when I don’t think they actually understand the internals of Roblox’s specific lighting engine in the slightest.
Roblox has two ways of rendering lighting; either it samples the voxel lightgrid, or it renders out a depth texture (a ‘shadow map’) from the light’s perspective and uses that for pixel shading. The two techniques are fundamentally different and have very different performance characteristics.
The reason that the voxel lightgrid is used for lower end devices is not because it is fundamentally cheaper than shadow-mapped lighting. In fact, in many cases it scales much worse than shadow-mapped lighting does, and light radius is one of the places where it hurts the most. As you linearly increase the radius of a given light source, the cost to compute the voxel lighting influence increases cubically (that is, O(n^3)) because the volume of influence of the light increases cubically, intersecting more points on the voxel lightgrid and thus requiring more points to be touched. Additionally, as a light source spills across voxel chunks, you may run into more significant performance slowdowns as the ratio of contiguous vs random memory accesses goes down; you need to rasterise into more chunks, and chunks may not necessarily be stored contiguously in memory, so you.lose some benefits from things like prefetching memory. Compare this to shadow-mapped lighting, which merely renders a depth texture from a single point of view - performance does not scale with respect to light radius because the only thing that would change is the far depth of the shadow map.
The problem here is that all of Roblox’s lighting modes use the voxel lightgrid. Future merely adds shadow-mapped lighting on top of the voxel lightgrid for nearby lights. This basically makes the cheapness of long-range shadow-mapped lights useless, because regardless you end up having to do a huge rasterisation job touching tons of chunks and lightgrid positions, which is ridiculously slow.
I’ve seen some people imply that somehow, Roblox having lots of money and years of research should somehow overcome this. This is simply not the case - what we are grappling with here is not a simple issue you can throw money at. We are talking about algorithmic complexity. The only way you beat algorithmic complexity is by using a different algorithm, which basically means anyone talking about how Roblox ‘should have solved this by now’ are saying that Roblox would need to basically do another lighting engine upgrade on the magnitude of FiB all over again. This is all before mentioning that the state of the art in lighting technology that scales back to Roblox’s minimum spec devices is exactly the same as it was back when FiB was first conceived. The current focus of light transport research is ray tracing, which practically requires dedicated hardware to run anywhere even close to realtime, and even then it requires so much processing power to be practically non-viable for mobile phones, not to mention the fact that ray tracing produces fundamentally different looking results to anything you would get from today’s lighting engines that it becomes yet another update breaking artist intention for builds.
The simple reality is that increasing the range limit for lights is nowhere near as trivial as certain individuals in this thread may lead you to believe. We are not dealing with amateur graphics programmers here - Roblox’s rendering team is, and has long been, a cast containing well-respected researchers who have contributed to the field in non-insignificant ways. If they are telling you that this is a hard problem, you should probably listen.
also i would like to add to this feature request, and ask they enable us to morph the shape of the lightning, and keep it consistent with graphic settings. so effects like this i made are easier and practical to execute.
Don’t worry, I’m completely with you that developers should be handed control over their own performance rather than necessarily being babied all the way to production. However, I think you don’t understand the technical restrictions I carefully outlined in my post. It is already very difficult to update range 60 lights while meeting Roblox’s standard performance quotas, and with cubic performance scaling, you will very quickly blast through all sorts of performance ceilings even for modest range increases. This is not something you can turn off, because it is fundamental to Roblox’s lighting system and has been since 2012. It is implicated in almost all areas of the render pipeline at this point.
The post you linked seemed to be testing static lights. Static lights do not incur performance penalties in the voxel lightgrid, however many of the use cases for longer range lights have indicated that they are anything but static, such as car headlights for example. Performance is more complicated than opening Cheat Engine, unclamping a number, shoving something in a level and pointing to an FPS counter. It is not just about the behaviour in one specific situation now, it is about how it evolves and interacts with other systems both now and into the future. Remember, Roblox is not publicly versioning its engine, and API commitments it makes now become chains it will be bound to in the future. There is ample reason to be careful around performance considerations, even if you wanted to give developers fuller reign, because performance regressions can become backwards compatibility hazards that become the subject of blame (Future is Bright has notoriously suffered from this, especially on mobile).
It is a false equivalence to compare these performance issues to something like meshes and unions. Those do not nearly have the same scaling characteristics and are not nearly as integral to the engine.
I’m not appealing to authority and it is a complete misconstrual of my point to imply this. I’m not telling you that, by virtue of having worked on Roblox’s rendering team, they are somehow above the rest of us. What I am saying is that these people have actively and consistently been at the forefront of researching these techniques. I don’t care what you think about their status or authority, but they have undeniably put in the work to try and discover whatever solutions they possibly can, and they have not yet done so. It is objective to say that there is almost no new research in this area that has the ability to make any significant impact on Roblox’s lighting model.
The performance of Future lighting is more than in line with exactly where it should be. If anything, it is many times faster than other engines, and has even made notable quality sacrifices in pursuit of allowing greater flexibility. What Roblox have done with their shadow mapped lighting is a miracle of engineering to even get it to run with the dynamicism and fidelity it does across the breadth of devices it does.
In industry it is commonly accepted that you should be limiting the number of dynamic light sources and the number of light sources simultaneously coincident on a surface, because these are the main sources of performance slowdown. Unity, Unreal and Godot simply cannot handle dynamic lighting at the level people demand from Future, unless they are using state of the art ray tracing techniques that scale on resolution and iteration depth alone. These technical boundaries may be foreign to Roblox users, but they are not easy to surmount, and so the notion that Future is somehow slow relative to these engines is simply nonsense. Roblox have pulled out plenty of industry-standard stops to get their lighting running as fast as it does - whether it’s rendering using tiles and light cone meshes, reducing shadow map resolution, and even optimising the machine code instructions being sent to your GPU.
Higher ups will not care about such restrictions as the range limit of lights. Product managers and C-suite employees deal with broad-level direction, vision and high level organisation of resources and efforts, not specific implementation details. Engineers absolutely make these decisions.
It is understandable that people are growing weary of Roblox’s poor communication here - I’ve been on the receiving end of especially poor communication in years past myself. However, we must remain proper and thorough in what we say, lest it be dismissed as reactionary and non-actionable. The reality is that, when there is a lack of communication for years, knowledge has likely cycled at the company. You can’t expect Roblox to remember and address every point, because Roblox quite literally will not be what they used to. Old experience leaves, and new talent has to come in from further-out horizons. That is the nature of a growing company.
None taken. I do not take any of this personally in the slightest - we are working on the same side of the same issue, but I’m attempting to provide context based on my understanding of how Roblox works under the hood.
decided to mess around with cheat engine to see how far i could push the light range and uhh…
there are 5 lights active, all moving around. each has shadows enabled, randomly changing colors, and their brightness set to 5.
(the goals of these images are to show the performance, the visuals arent all that interesting tbh)
60 studs:
120 studs:
300 studs:
600 studs:
3,000 studs:
1,000,000 studs:
obviously you aren’t actually getting anything past about 600 studs, but clearly the engine can handle the value being set to anything, so the current limit is entirely artificial!
Are you accounting for how Roblox is amortising the cost of lighting recalculations across frames?
