Summary
Add Visible property of type boolean to Model class, where when it’s set to false all of its current and future descendants will not render but sounds, physics, replication, and anything that does not produce image will remain unaffected. To put it simply, the sole concern of the property is visual.
Motivation
The ability to hide objects is a very common operation within game development, and it is a fundamental feature of any game engine. Roblox as a game engine already has similar feature where it is available in various forms, such as:
- The Visible property on the GuiObject abstract class.
- The Visible property on the GuiBase3d abstract class.
- The Enabled property on the LayerCollector abstract class, from which a common class like ScreenGui inherits.
- The Enabled property on the UIStroke class.
- The Enabled property on the UIGradient class.
The closest one from this list in terms of functionality is the LayerCollector, which is commonly utilized in a form of ScreenGui instance, where the Enabled property disables rendering its descendants that fall under user interface category when set to false.
Outside of Roblox, many notable game engines implement this feature:
- Godot has “visible” property on “Node3D” instances.
- Unity has “enabled” property on the “Renderer” component which can be found in a “GameObject”.
- Unreal Engine has a “Set Visibility” function in their blueprints.
- GameMaker has “visible” property on their instances.
Besides prior work, there are countless use cases for this feature, where it would not only come handy but prevent many bugs, and make code more reliable and future proof. Currently developers will often resort to writing code that may look something this:
This is a simple solution which often is used as part of the arguments against implementation of the feature, however, it has major drawbacks. The function works under the assumption that the model is only composed of parts (Part, MeshPart, etc.) and nothing else, although it works just fine in plenty of cases, it is not sufficient in many other cases, one of those cases are car games where many of them have cars without interiors, and often placing player’s character inside of the car may not enough to hide it, thus developers need to hide the character itself.
Player characters are incredibly unpredictable due to accessories that the players can equip on their characters, as the developers are not in control of what instances and their behavior might be present within them, and it has become even more unpredictable since the introduction of public UGC items that lets practically any user on the platform (as long as they meet few basic requirements) to create their own accessory which any player can acquire and equip on their character. Additionally, with each new version release of the engine, a new instance may be introduced which will not be accounted for by older code. This forces developers to have to constantly keep up-to-date and perform occasional maintenance to keep their game functioning properly.
To hide the player character, and the accessories within them, developers often resort to more complex functions unlike the one shown earlier, and they often modify properties of BaseParts, Decals, Textures, ParticleEmitters, Lights, Beams, and countless more. Additionally, they have to retain their original values so that they can be restored later when making the character visible again.
For example: In Tower Defense Simulator’s “FPS mode” players are meant to be invisible to prevent obstructing the active player’s view so that they can aim their weapon at the incoming enemies. However, I’ve noticed instances where certain player accessories remain visible (as shown in the image below) while they’re supposed to be hidden, and some properties don’t revert to their original values upon exiting FPS mode, which result in unintended alteration to the player’s character appearance.
These issues likely stem from the difficulty in accounting for all possible properties, instances, and their associated logic. Similarly, many games featuring vehicles (as mentioned earlier) face similar complications when attempting to hide characters upon entering a vehicle.
Besides countless properties to account for, developers may face even greater challenges when the models have descendants added to or removed from while being hidden. Models may also contain instances whose properties continue to change while hidden.
For example, if a developer were to make a game like Murder Mystery 2, and add a feature where murder can become invisible for short period of time, and the character happened to carry a knife equipped with an animated glowing rainbow skin, the developer would have to first disable the effect before being able to hide the player’s character who’s carrying the knife. This might be simple, but as the game grows and becomes more feature rich, it will become increasingly more difficult and annoying to deal with, and it will make a major impact on the code complexity.
Performance is also a concern given switching visibility of objects is a common operation in games. For example, take the “Skinned Avatar” from the built-in Roblox Studio plugin “Rig Builder”, the sample character is composed of 308 instances. That’s just a sample, an advanced avatar made by a user may end up creating an avatar with a lot more. If a game can have 20 players, that’s already 6160 instances.
Having to account for descendants being added, removed, and properties constantly changing in all of those models would be impractical due to the performance cost.
The proposed Visible property would provide developers with a straightforward solution to these challenges, reducing the need to handle numerous edge cases, potential conflicts with future Roblox updates and UGC creator innovations.
Implementing this feature would greatly simplify the development process and enhance the overall quality and consistency of games on the Roblox platform. As a player, developer, and observer of these issues, I believe this addition would benefit both developers and users alike.
Workarounds
There are 4 common workarounds that developers can employ to change the visibility state of their models.
Traditional Method
Acquire the descendants of a model and set all the appropriate properties (e.g., Transparency, Enabled, Visible, etc.) to values that will make them either visible or invisible. Typical approach may look something like this:
Position Method
To make the model invisible: Move the model very far away (either through Position, CFrame, or PivotTo). To make the model visible again: Move the model back to its original location.
Parent Method
To make the model invisible: Set its parent to ReplicatedStorage, or any other instance that does not render 3D instances. To make the model visible again: Sets its parent back to the original parent.
ViewportFrame Method
To make the model invisible: Place the model inside a ViewportFrame. To make the model visible again: Remove Viewport Frame and temporarily place the model in a ReplicatedStorage for at least a frame before parenting it back to its original parent. This method was mentioned by Stellar (@rabbi99) in one of their posts.
Drawbacks
There should be no significant drawbacks associated with one additional property to the Model class. The logic for not rendering objects appears to be already there, and ReplicatedStorage alongside ViewportFrame as workarounds methods are both proof of that.