Level baking/compiling

Now I’m going to start by explaining something:- in pretty much every game engine I’ve used and I assume most other engines, the maps/levels need baking/building/compiling before they can be used in the game client. One of the only engines I’ve used which doesn’t do this is ROBLOX. The .rbxl is just about the exact same in the client as it is in the studio. I feel this should change. (.rbxlf (roblox map file) anyone?)

I can think of a few benefits of what my idea of map compilation could bring:
[ul]
[li]less exploits (i’ll explain why later in the thread)[/li]
[li]smaller .rbxl files (even though they are quite small already making them even smaller would be a benefit)[/li]
[li]allows for better graphics (again i’ll explain why later)[/li]
[li]possibly less load on roblox servers (i don’t know much about networking so i can’t be sure about this)[/li]
[/ul]

Anyway on to describing all the points.

Less exploits
After compilation everything would in effect become baked into the file, certain services locked etc, however I’ve never really dealt with exploits so I can’t be too sure what would be prevented with baked/compiled maps, I can only assume.

Smaller .rbxl files
I was thinking that instead of just having an “Anchored” property that determines if the part is simulated by physics or not, there could also be a “World geometry” property which is only toggleable in the editor and when the map is compiled it would merge them all into one single physics model to reduce the amount of space taken up by parts since they wouldn’t have the possibility of becoming unanchored, intangible etc, they would just be static parts and as a result they would take up less space within the rbxl after compilation. As most parts within a roblox level are usually part of the world geometry I feel like this would be useful to have.

Better graphics
You must think I’m nuts when I say this but what I’m really thinking is that part of the baking process could include “baking” static lights (similar to the Source engine’s vrad.exe function which calculates all the radiosity and bakes the lighting). I feel that in combination with the “World geometry” mentioned in the previous section it could produce some pretty neat lighting since it wouldn’t have to constantly be updated in the voxel grid. It could also perhaps generate cubemap reflections around reflective surfaces automatically and produce much nicer reflections.

Less load on ROBLOX servers
All I’m considering here is that upon baking a map all decals, sounds etc. would maybe be embedded into the level file and as a result would produce a lower load on ROBLOX servers, I’m not too sure what impact this would have on file size though so it may be contradicting my point about it producing smaller .rbxl files.

If anyone has anything to add to this, any comments etc, please reply. Any questions will also be answered promptly.

tl;dr: “compiling” a map would be v. sexy and make roblox levels better.

5 Likes

What if the server decides to un-anchor an anchored part AFTER compilation?

[quote] What if the server decides to un-anchor an anchored part AFTER compilation? [/quote] I’m pretty sure I covered that…

The idea is that compilation would just remove any possible physics from parts marked as “world geometry” - a part wouldn’t be able to be world geometry AND unanchored at the same time - so if you set a part as world geometry the anchored boolean would become unusable and irrelevant for that part.

basically it wouldn’t be allowed as the part wouldn’t HAVE an anchored property anymore if it’s marked as world geometry.

[quote] What if the server decides to un-anchor an anchored part AFTER compilation? [/quote] I’m pretty sure I covered that…

The idea is that compilation would just remove any possible physics from parts marked as “world geometry” - a part wouldn’t be able to be world geometry AND unanchored at the same time - so if you set a part as world geometry the anchored boolean would become unusable and irrelevant for that part.

basically it wouldn’t be allowed as the part wouldn’t HAVE an anchored property anymore if it’s marked as world geometry.[/quote]

I dont see how a feature like that would require level baking/compiling. At least not on the user end. Roblox can already freely do whatever optimizations they feel like when you upload your place. Wasnt the binary place format only used on roblox’s end in the beginning?

I wouldnt want a feature like that though. I dont understand what you mean by removing physics, wouldnt world geometry still need physics? Or are you talking about some kind of decorations? In which case making the stuff cancollide=false would do.
If you meant that removing physics would essentially disallow you from modifying that part independent of other parts, allowing for more optimizations, CSG will be doing exactly that.
The only reason for adding such a property would be to allow some really expensive calculations to be done for pathfinding/graphics optimizations, but I feel it would limit the platform too much (look at what the humanoids have done, the humanoidsssss)

[quote] [quote=“Basswobble” post=70515]What if the server decides to un-anchor an anchored part AFTER compilation? [/quote] I’m pretty sure I covered that…

The idea is that compilation would just remove any possible physics from parts marked as “world geometry” - a part wouldn’t be able to be world geometry AND unanchored at the same time - so if you set a part as world geometry the anchored boolean would become unusable and irrelevant for that part.

basically it wouldn’t be allowed as the part wouldn’t HAVE an anchored property anymore if it’s marked as world geometry.[/quote]

I dont see how a feature like that would require level baking/compiling. At least not on the user end. Roblox can already freely do whatever optimizations they feel like when you upload your place. Wasnt the binary place format only used on roblox’s end in the beginning?

I wouldnt want a feature like that though. I dont understand what you mean by removing physics, wouldnt world geometry still need physics? Or are you talking about some kind of decorations? In which case making the stuff cancollide=false would do.
If you meant that removing physics would essentially disallow you from modifying that part independent of other parts, allowing for more optimizations, CSG will be doing exactly that.
The only reason for adding such a property would be to allow some really expensive calculations to be done for pathfinding/graphics optimizations, but I feel it would limit the platform too much (look at what the humanoids have done, the humanoidsssss)[/quote]

What I mean by removing physics is removing need for the engine to check if it’s anchored or not, and therefore whether or not gravity and other such physics should apply.

By compiling the map it would merge all their physics models into one and generally increase performance as it would only count as one part.

After compilation the level would not be editable so when you compile it in Roblox Studio it would prompt you to save it as a seperate file. In my mind the uncompiled maps would be .rbxmf (roblox map file) and compiled maps would remain .rbxl.

Further adding to this, levels wouldn’t require baking/compiling, but doing so would improve the quality of your levels.

The reason why ROBLOX doesn’t have a similar system to other engines is because of ease of use.

It’s meant to be easy for young people to use, so they don’t have to fiddle around trying to get their places to work; they just upload and go.

[quote] The reason why ROBLOX doesn’t have a similar system to other engines is because of ease of use.

It’s meant to be easy for young people to use, so they don’t have to fiddle around trying to get their places to work; they just upload and go. [/quote]

Yeah but that’s why I also said it would be optional - it would be an option for the more advanced developers.

[quote] The reason why ROBLOX doesn’t have a similar system to other engines is because of ease of use.

It’s meant to be easy for young people to use, so they don’t have to fiddle around trying to get their places to work; they just upload and go. [/quote]

Yeah but that’s why I also said it would be optional - it would be an option for the more advanced developers.[/quote]

I saw that, but what really is the point? ROBLOX already preforms as many optimisations as they can, so it’s not really worth much anyway.

[quote] [quote=“FiniteReality” post=70625]The reason why ROBLOX doesn’t have a similar system to other engines is because of ease of use.

It’s meant to be easy for young people to use, so they don’t have to fiddle around trying to get their places to work; they just upload and go. [/quote]

Yeah but that’s why I also said it would be optional - it would be an option for the more advanced developers.[/quote]

I saw that, but what really is the point? ROBLOX already preforms as many optimisations as they can, so it’s not really worth much anyway.[/quote]

It’s not entirely about optimization, I did mention the possibility that it could help prevent exploiters as well as improve the appearance of levels.

Big yes, for example lightmaps could be pre-rendered, which would massively minimize the load on clients computers and even make them look a lot better. Also exploiters wouldn’t have as much access to the precompiled level.

Very nice and what I’ve been dreaming to happen for years, however I really doubt roblox will ever do such a thing, because of their “Not the style roblox should be going for” excuse.

Bump :slight_smile:

I see no reason for this to happen except the amount of work and design needed on it