There’s plenty of features that I do agree that roblox should add, and that they need to add, or should’ve added years ago. I don’t think I’ve really argued against that.
For example emissive textures, huge oversight. I also think we need better glass that can render transparent things behind them. Or grass where you can change the length area by area, the current grass is pretty shoddy. Plenty of things really, I could go on and on. The material implementation is personally the most upsetting to me, I waste so much time tiling pbr materials and it makes me just wanna use textures instead.
Roblox isn’t just a game engine, it handles server hosting, storage, accounts for you.
Yes that’s pretty much what I said.
Also, this feature requests, which is asking for longer sliders, will not turn Roblox’ core product, Roblox, into a complicated mess.
Those suggestions are more than just longer sliders.
will not turn Roblox’ core product, Roblox, into a complicated mess.
No but it takes their core product and turns it into something different than intended. Roblox is built around being physically based, even if the lighting does do a poor job of that.
I 100% agree with this. During my time as a ROBLOX developer, i always have been frustrated about the limits on lighting settings, since they handicap the amount of creativity something can have poured in easily, forcing you to use more advanced techniques, when ROBLOX could just make them official. However, for what we have right now, it’s decent to say the least. Not great, not terrible.
Yeah, overglorified Lighting.Technology
And we might never find answer on why is this change necessary. I guess we’ll find out (or not) once it actually gets released.
I personally don’t think cubemaps should be locked to Light Instances, we should be allowed to place our own cubemaps around our levels manually like other game engines allow developers.
Lights in Roblox are really limiting for the slogan “The Future is Bright”, clearly that was a lie. We can’t even change the light shadow quality.
Counter Strike Global Offensive on Source 1 use the closest Cubemap to the player to display reflections. They would need to give us a way to use scripts on these cubemaps.
We should be able to bake these cubemaps to ease up resources and even render new ones with one single line of code.
Current cubemaps have one single big issue and that is that stuff will reflect on themselves, we should be allowed to blacklist what we don’t want included in rendering these cubemaps just like a raycast.
Dynamic cubemaps are a bit hard because, if you bake them how do you automatically ignore dynamic objects? In UE5 you can bake cubemaps pre-runtime or you can set it to be baked on runtime (this however causes more slowdowns i think).
Scripting the cubemaps would be useful if you plan on using different “lighting scenarios” where lets say you baked a cubemap for a dark environment and then it becomes bright, you obviously want to update the cubemaps!
The best would be a function that can be called on a cubemap instance to re-capture the scene when called. This does however need to have some sort of way of ignoring dynamic objects and changes in the scene such as preventing baking in players in the cubemap. But roblox already does this so it should be no big deal
Most of the stuff in my levels are anchored and not physics objects, I want to bake a cubemap when the cubemap is added and whenever a script requests that cubemap to render unless I set it to render automatically which could also be done using scripts.
By scripting the cubemaps I mean like “:Render()” and “CubemapParams.new()”, this would act similar to how a Raycast would. Roblox code would handle all the hard stuff, we would just use their API.
Physics Objects = / = Dynamic objects, its a very loose term i used here.
For example unreal has objects that can be dynamic, think of it like this.
You have static meshes in a scene on unreal, those will probably never move (unless maybe inside of a level sequence.) and maybe you have blueprints with meshes inside, those might be dynamic.
Typically the cubemaps from what i remember ignore certain actors from being baked but the artists tend to tune this fine by hand when they bake them in, if you do it automatically it might come with unwanted consequences.
For example what if a developer uses non-humanoids in their game? Suddenly you have characters captured inside of a cubemap that isnt even there anymore! This is even the case with current roblox, if you want to make your own character controller without humanoids these will be captured in reflections.
This is why i think certain things just cant be automated and roblox has to come with terms to accept this, there are just certain things that you cant fix in the current time, its better to give us features that we will have to manually work with instead having everything to be automatic, no game engine would just ignore a reasonable feature request because “it would be too hard for certain users to use”, then what even is the point of learning game development if everything should be easy and automated for everyone to have a equal skill level?
Dynamic would probably be property wise, if their rgb colour changes just like a teenager looking for attention then that would be Dynamic, if it’s an unanchored object then that’s a physics object. This doesn’t take away from what I’ve mentioned before.