The Hitchhiker's Guide To Optimization - Optimize Your Game Using Just One Post Instead of Many

Bookmarked!

There are syntaxes you can search by in the explorer! You can simply just search is:particleemitter or is:seat or c:part or c:particleemitter etc! You can even search by properties, such as locked==true (or locked=true)!

You can then press the “select all matching” button (or press CTRL + A) to select them all.

Also, don’t use waitforchild on the server unless something is created during runtime. I know I worded that horribly so here’s videos on it.

Summary

https://www.youtube.com/watch?v=7tzy1DuPcBQ
https://www.youtube.com/watch?v=mRA0AytlAak

Never even thought of this… I wonder if it’s possible to make a plugin that can do this automatically.

4 Likes

How bad is it to use it frequently on the server if its not waiting for things during that aren’t exactly there?

I quite literally have a thing for smacking anything im looking for into a WFC just incase it doesn’t throw an index nil error.

2 Likes

I’m not sure exactly how bad it is, but most of the time you never need to use WaitForChild:() on the server.

If an object is created during runtime after the script runs you might have to. The videos I sent go over when to use it, and when not to use it.

3 Likes

Just though I’d add a little bit of extra context from my personal experience in this sphere. Do let me know if I’ve made any mistakes, though.

Note that Performance can grant poor results for some meshes, Automatic is distance-based (and the default option), so far away meshes that don’t look accurate enough to be visually pleasing should still be set to Precise RenderFidelity.

Note also that this removes most of the benefits of StreamingEnabled for any model you enable it on. Plus Persistent models aren’t necessarily guarenteed to solve your scripting problems either since they aren’t guarenteed to have loaded until PersistentLoaded has been fired. Ideally, you should code around StreamingEnabled being enabled.

As a little correction here, CollisionFidelity doesn’t change the rendering afaik (except for shadows sometimes) but rather just opts for setting the collision box to a box, this makes it unsuitable for any parts which you use the Touched event (or other collision methods/events) on. It is, however, good for decreasing memory.

As far as I know from what I’ve heard, Roblox converts files to ogg before serving it to users. Maybe there is a mobile bottleneck for mp3 uploaded files, but if so, I personally haven’t heard of it? For any looping tracks, you should upload ogg files, though, since mp3 has an inherent piece of silence at the end of each track.

Do you have benchmarks for this. This feels like it should be the other way around?

For added context on why, task.wait has a shorter minimum waiting time and doesn’t throttle. Those are the main benefits for it afaik. When not using the number parameter, you are probably better off using RunService events, though.

Keep in mind that the reason this works is because it isn’t being streamed to the client. Only items you don’t need to use the client should be stored there.

From my understanding of buffers, you probably don’t need to use them unless you are working with your own binary-like format. Most scripts won’t need to use it.

Only enable this if you see a worthy performance benefit. There are some drawbacks to native code:

  • Code compilation time is required which can increase the startup time of servers.

  • Extra memory is occupied to store natively compiled code.

  • There’s a limit on the total allowed amount of natively compiled code in an experience.

Source

It is also only currently supported on the server.

5 Likes

Some of it is good but most of it is bad

  1. Your main focus on optimizing visuals shouldn’t be to lower the rendering fidelity as low as possible. It should be to minimize draw calls.
  2. If you still need more performance then you can try minimizing triangles.
  3. FindFirstChild is faster than indexing since it skips checking properties.
  4. Use type checking to get the most out of native
3 Likes

And @TimeFrenzied

This Announcement actually says the opposite: Heightmaps Go to New Altitudes! - #27 by JoshSedai
As I understand it having a flat bottomed mountain is better than having it hollowed out since there is more surface area and detail that has to be stored.

However with the new system coming up they are planning to not render hidden faces of Parts but I don’t know how that’ll work for terrain.

5 Likes

I’ll break my truce of not replying because I like this reply, and your reply is a reply meant to add context to help other individuals. Will also probably edit my post to include that I will do some clarifications in the replies lol.

I have added on information on my guide to help clarify some things in this post, specifically regarding your concerns, but I’ll add it in here.

I agree with this part. However, this is to help all kinds of developers, from the ones who just found the DevForum to your professional developer. If you know what you are doing this would be a good way to go about this, but the method I use is what I recommend for your average builder or 3D modeler. I use the method I stated only when I find there is no other way to do so without re-doing a lot of things (either I don’t know what is going on or I am just feeling lazy). To each their own though!

Automatic is NOT the default RenderFidelity option. Perhaps you are thinking of LevelOfDetail? The default option is Precise. I encourage both Performance and Automatic to be used, but Performance should be used for bigger games.

ROBLOX does in fact NOT convert files into OGG format. However, I did not even know about the bit of silence at the end of mp3 files, this is actually really helpful, thanks!

As I’ve stated, I am going off of what I have experienced. I have found most of the posts on the DevForum for optimization to not work completely well for me. For textures, ROBLOX needs to check each and every side, from the experience I have had with this. With custom materials, it just uses the material like your average material, and behaves differently from textures. However, custom materials and surfaceappearances shouldn’t be used that much, and same goes for textures. A lot of people, including myself, want to use PBR more, so this is the best way I have found with making PBR work on ROBLOX. I have attached an image compressor as a result of this though to help developers with optimizing their textures and decals.

Regardless, this is a great reply for adding on more context, and I do appreciate you for that!

While the post you linked is made by a ROBLOX admin, I do want to mention that it is not only made in 2021 but that there has been a lot of research done on this. I would also like to refer you to this post, here. What's better: Hollow or filled terrain?

I do understand the concern with this information though, and will add on something regarding it. I also almost forgot something I wanted to mention about water in this post.

the mp3 I uploaded to roblox has been converted to OGG.

I believe this fact has actually been a bit of a pain point for people archiving audios uploaded to roblox,

they even seem to have trimmed the bit of silence off the beginning of my mp3


(qFu6MdSL is the redownloaded one)

even the ogg i uploaded seems to have been re-encoded anyway, so you’re probably not saving much quality either

the only exception I’ve personally seen to this is raining tacos, which was actually a 320kbps mp3

I’m 99% sure indexing should always be faster than FindFirstChild. Even if it is, at some point it’ll just be slower once there are enough children to look through. There’s a reason you don’t iterate through a dictionary to check for a key when you already have it.

Benchmark it for yourself. FindFirstChild is faster for random access since it skips properties. There’s also no reason for it to internally use a loop when index is a hash. Think about it

1 Like

This is the exact kind of thing my post was meant to avoid. This post is meant to be something everyone can understand, and if some fresh developer is looking for an optimization guide, they will not know what most of these things you listed are without doing a ton of research.

Not everyone has the time to sit around and learn all of this stuff. If you want to really criticize this post, then you can do it like others did, and actually say things in a term that everyone will understand. Minimize Draw Calls is something that barely any avid developer knows about, it’s something that would be higher up.

Basically, speak in a language everyone can understand to make your critique worth it. Don’t speak in dev lang.

You do know FindFirstChild is internally a loop right? I’m pretty sure whatever benchmark you did was wrong. Roblox says it themselves:

If it didn’t loop there would be no recursive option.

1 Like

They don’t know because they are not taught that yet, which is what I thought this resource was about

Besides, FindFirstChild serves a different purpose, so if you already know something exists you should just index it. (Using variables also helps)

You seem to not be acknowledging the crystal clear learning curve in developing… smh. I’m not going to argue with you further because this post is meant to help people, not be a place to argue.

Most of the stuff he said was right (except the find first child thing)

Just because it has a recursive option doesn’t mean it uses a loop

Yes, but it’s important that everyone can understand it. That’s what I’m getting at. What I listed has worked out for me, anyways, and it’s something that most people can easily understand and do. Plus, you can add on what he said into what I put in to optimize further.

I’ve found that a lot of developers starting out have a huge problem with optimizing. They don’t know how to do it, so it’s best to explain it in layman’s terms so that everyone can have smoother games. It should not be locked behind those who have been doing this kind of thing for years.

I seriously doubt they’re storing a large dictionary that gets updated every time the data model changes. That’s just going to eat up memory for no reason.