Make it possible to stop Instances from being rendered easily

As a Roblox developer, making specific Baseparts, Decals, Textures, etc. stop rendering for the player is a huge pain. This is an important part to help with performance of your game, but the lack of an easy toggle causes a lot of friction for developers.

Currently the only solutions are:

  1. Set the Transparencies of all Instances to 1 and set all Instances with the Enabled property to false.

While not too difficult to implement, there are many gotchas and scalability issues with this method, such as having to track the original states to avoid making instances intentionally invisible now visible and vice versa.

This also requires you to iterate over every single descendant in a section of the explorer and modify them to their correct state, which can definitely add a huge cost of grabbing and modifying large areas of your workspace.

  1. Parent them outside of workspace.

This method is fairly straightforward but can have some fairly rough drawbacks:

  • Physics no longer able to update
  • Animations being unable to be loaded if no longer present in workspace,
  • Huge hitches in framerate from loading/unloading large sections
  • Collision no longer being present (this can easily cause issues of players/physics objects falling through the world if reparenting is too slow)
  • Code relying on the existence of certain Instances now have to have escape hatches in case they’ve been parented elsewhere

The most ideal scenario would be having a parent Instance with a Visible flag that can stop rendering all of its descendants immediately without having to rely on these awkward half solutions or just hope the upcoming occlusion culling can solve all your intended usecases.

I’d like to also reference these other feature requests that Daw588 shared with me:

16 Likes

Visible property would be a huge relief! If you haven’t already, I would encourage you to support similar feature request that relates to Models. I wrote up a quite lengthy post explaining why Visible property should be implemented for Models, but it can also be applied to any other instance like the ones you listed.

4 Likes

I agree that there is a need for a way to easily control the visibility of instances, especially in bulk.

Reparenting is particularly problematic when hiding player characters or other instances subject to incoming replication, because the replication will stop until the instances are reparented AND new replication is received. Which means if another player is idle for a few minutes, after their character is reparented they will appear to be standing in an outdated position until they move again.

Sometimes I want to hide things not for performance but for some cosmetic or gameplay effect, and in this scenario using a transparency value is nice so that things can be smoothly faded in/out. However it is very difficult to do this to multiple at instances at once currently because you need to track and modify the LocalTransparencyModifier of each of the instances individually. It would be nice to have a way to do this in bulk so I only need to track and modify one instance.

It’s also worth mentioning that sometimes different systems want to control the visibility of the same instance. You could image a scenario for example where you have a culling system and a character hiding system. Or to use a real example, the PlayerModule camera scripts which modify LocalTransparencyModifier inside the player character based on camera zoom, and a separate gameplay system created by the developer which wants to set transparency of the character. With current features, these use cases are difficult to achieve because they do not allow the systems to co-exist: there is only one LocalTransparencyModifier property, and an instance can only have one parent. So the systems must be coded to explicitly know about each other or have the visibility logic be centralized (which may also mean forking the PlayerModule!!!). I don’t actually mind the centralization that much if only my code is involved (it’s good for making robust systems which don’t behave unpredictability), but the biggest issue for me is that the centralization requires forking and modifying and maintaining the PlayerModule or other third party code which wants to hide stuff.

3 Likes