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.
3 Likes
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.
2 Likes
Ah. Ok. I know most of my friends don’t know what PBR and RTX are.
2 Likes
Agree, actually doing a backrooms game and this feature needs to come in hand, Roblox.
2 Likes
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
4 Likes
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.
36 Likes
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.
9 Likes
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.
9 Likes
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!
6 Likes
Are you accounting for how Roblox is amortising the cost of lighting recalculations across frames?
1 Like
assuming that you’re concerned about the frequency that lights are updated, it seems to be fine*.
(the lights in both tests have a range of 330 studs)
here is with future selected:
*but as for voxel…
i believe the way the engine chooses to update light voxels isn’t very optimal and prioritizes the area around the player way too much, which results in the cutoff between close and far away voxels extremely noticeable.
here’s a particularly noticeable example with me walking up and down a hill:
i still believe the range value should be uncapped (or at least made a much larger value) asap, but these issues should also be resolved at some point.
7 Likes
It’s more Roblox wanting to reinvent the wheel than an inability to improve/revamp the current lighting system. This has been their problem for a very long time, especially in the last few years. It’s apparent by what they are prioritizing (and saying). Metaverse hype, brand events, dynamic heads, new player models, immersive ads, AI integrations, etc. They are focusing on what might happen 10 years from now rather than would should be happening currently:
Now I’m not saying there is anything inherently wrong with the recent updates/changes, but a lot of these can be done by developers themselves and definitely are not worth focusing on over other constantly requested updates to the engine. We only just recently received the ability to use Sprite Sheets (Flipbooks) despite it being one of the oldest computer graphic tools (started being used in the 1970s). Same with Inverse Kinematics or Voice Chat support. There’s a whole laundry list of requests developers have been pleading to Roblox for that any other engine you can go to added 10+ years ago:
- Removal of the 60 FPS Cap
- Light Range Increase
- Sound Engine (adaptive music)
- More Client-Sided Graphics Settings (which would help with a light range increase)
- More Texture Support (Emissives for example)
- Changing Color3 of Mesh Parts with a Texture
- Offline Support for Roblox Studio
Roblox’s limits is creating limits on Developer creativity and what experiences on the platform could look like (figuratively and literally). In fact, Roblox being eons behind just makes certain aspects of development more complicated. I remember a project I worked on a few years ago where the team had to re-do an entire scene because the lights they expected to give atmosphere weren’t even visible when playing due to the scale. Or, when you are wanting a glowing item in your game and have to split up your mesh to make certain parts neon given there’s no emissive texture support. If Roblox would realize this, the platform could improve substantially.
19 Likes
One of the massively important things you neglect to mention here is that Roblox has to maintain complete backwards compatibility in order for this entire model of game distribution to work. Game engines like Unity, Unreal and Godot, and more broadly other 3D software from 3DS Max to Blender all have the luxury of heing versioned standalone binaries, each versioned binary then being associated by game developers and content creators with files and releases designed for that specific version. Within this model, it is far easier to make throwaway API design choices, including API choices that can better exploit hardware in the short term with hyperspecialised techniques, at the expense of inevitable long term incompatibility. Look at the laundry list of features that get deprecated over time for these platforms and what you soon realise is that the entire rest of the game industry is predicated on continual and constant abandonment and adaptation on a level that Roblox is simply not capable of.
Where you should be looking in your analysis is not to these disposable platforms, but towards evergreen platforms such as web browsers. Without backwards compatibility, the entire model of distributing a single engine binary doesn’t work, and as a consequence, you seriously lose out on a whole host of benefits, especially where this intersects app stores on heavily regulated platforms… like, I don’t know, the largest mobile platform in the United States, perhaps? Similar lines of logic similarly explain the absence of other features like user shaders (which I have good authority was partially shot down due to platform concerns about running untrusted machine code OTA on console GPUs).
Take a look at how the W3C have to painfully and thorougly work through every single scenario that their APIs are used for. Missteps are not simply disposable - they have to be supported into perpetuity, across hardware that does not just scale upwards but also downwards, that may look completely different in the future (Meta Quest running into performance issues, anyone?), with the very rare exceptions proving the rule. Sound familiar? This is exactly how Roblox works too.
You complain about how far behind Roblox is to these disposable platforms, and you know what? I’m right there with you. Take a look at any of my projects and you see that I’m constantly running up against these limits. But I do not blame that on any kind of incompetence, ignorance of feedback or some C-suite so far up their own selves that they can’t see what actually needs to happen. I wouldn’t entirely rule any of those things out, but as someone who has watched exactly how this platform has developed over the past 15 years plus, it is clear and painfully obvious that what Roblox is trying to build is, much like the web, a semantic language within which levels are defined. I don’t think that’s nonsense and I don’t think it’s unreasonable. It’s simply forward-thinking insurance. And you know what? Roblox has the single best track record for backwards compatibility of any of these platforms full stop. I can boot up games made almost two decades ago and they have evolved right alongside the platform in ways that you could only ever dream of elsewhere. Roblox have not failed in their goal, and if anything, they have historically threaded this particular needle very well, even at the cost of fast movement.
I have no idea why the idea of Roblox as some thick vision-obsessed corporation is so alluring here. It’s not entirely untrue - that’s just Silicon Valley for you - but you guys are giving them far too little credit for what amount to very real and serious problems.
12 Likes
Parts using SurfaceLights can resize larger than 60 studs with Shadows enabled, but the resolution basically halves as you hit multiples of 60. Great way to make light beams!! Lights larger than 60 studs-topic and video share
I see what you’re saying but worrying about being backwards compatible is pretty moot. Sure, changing the lighting would definitely make games look different if it was forced and a completely new system. However isn’t that the point of Opt-Ins? When they introduced Future is Bright, it was a setting developers can enable if they choose to utilize it. If we were talking about a syntax change or other foundational change then yes of course, that would come more into play. Even if it wasn’t able to be disabled, the pros of having the barebone features of mainstream engines drastically outweigh the cons of temporarily hurting backwards compatibility.
Roblox is very much a Live-Ops type of platform. A lot of games created in Unreal or Unity are focused on a final product. Yet they still are able to deprecate 15 features today and introduce 20 new ones tomorrow and developers can still migrate their 10 year old game to the newest engine version for a remaster if they feel like it. They can do that because they have a way to do it efficiently (if they even need to). Very few experiences on Roblox are not Live-Ops. Any experience with a steady player base is going to be receiving constant updates, constant changes, etc. The experiences on the platform are ever-evolving, so should the engine. Developers being required to keep their experience updated isn’t the inconvenience Roblox thinks it is. It’s literally just the way things go in this industry. It’s required if you want a long term quality experience. The mentality of handholding developers is truly restricting what could be possible. It would make sense if Roblox’s vision remained what it was in 2006 (simple sandbox games created for kids by kids), but it’s not. Roblox wants to age up the platform and bring in more outside developers but that’s not going to happen due to limitations like this. Why would developers come to Roblox to develop an actual game (not a cash grab or shovelware) when technical aspects of the engine can’t even surpass Half-Life 2. We aren’t asking for an entire engine change, just for the bare minimum lol.
9 Likes
It’s hard because historically Roblox has received contradictory signals from the community about this. When it came time to release new materials, or even for the transition between Legacy and Compatibility lighting to go along with the theme of lighting changes, creators made it clear that they want Roblox to uphold artist intent and minimise breaking changes at all costs. Meanwhile when it comes to posts like this developers demand that Roblox cause breaking changes with the justification that they don’t actually mind updating their games. You can understand why Roblox errs on the side of not breaking anything here, because it’s a losing battle either way in terms of developer sentiment.
5 Likes
how is increasing the range of lights a breaking change? other than scripts that wrongly try setting the range to infinity, i’m unsure of anything else this could break.
7 Likes
I was specifically replying to points Joey said within the context of their post.
6 Likes
Some hacky solutions I found is sort of adding invisible nodes of light, the main problems with it is that you’d ideally want to unload these manually and want to use raycasting to avoid having these nodes clipping through walls altogether. Otherwise they do the job pretty nice.
In this example it is a part with a light, welded to a handle, pretty unideal if you have multiple players wandering around with them, as the points of light would just clip and shine through the walls. So again, ideally, raycasting.
Some others examples I heard is shrinking your map, as roblox does allow things to get pretty small but I’d be warry of hit detection at smaller scales.
At the end of the day, I don’t see how using niche, rather performance-demanding tricks, is better then just increasing the range. Or maybe sometime in the future just reworking the lighting engine again, since apparently increasing the range is that scary, then maybe the engine itself is the issue.
7 Likes
What if SurfaceLights supported more shapes? Projections are always lighter with one shape!
6 Likes