Hierarchical Control of Instance Visiblity Without Re-Parenting

bool Instance:GetVisible() and void Instance:SetVisible(bool) or bool Instance.Visible

This would be an extraordinarily powerful tool that developers would be able to utilize in their games, allowing them to show and hide objects without:

  1. Needing to change their parenting or hierarchies
  2. Changing Transparency for an arbitrary number of objects

This feature already exists in engines such as Unreal and Unity.

With the ability to control the visibility of objects, this behavior should function in a hierarchy. If the parent is not visible, none of its descendants shall be visible, however if any of the children are not visible, it has no effect on the parent. The part still exists as normal, but without being displayed. This has major impacts on a larger scale, for example, culling world geometry. Instead of parenting chunks of the world to and from, these chunks can be streamed with StreamingEnabled, always loaded in, but with its visibility controlled by client-side scripts. This will allow clients to “pre-load” chunks of a level while you are travelling around an area reducing the performance impact of suddenly throwing several assets into view. This would also increase performance when implementing “culling”, by toggling visibility of rooms around a player while they roam the interior of a large house, without needing to change transparency of several objects within the map or, again, parent them to storage.

Currently, parenting and manipulating large quantities of objects is very performance intensive, especially to load and unload these assets into the scene. Having this control over instance visibility overall would allow game streaming to more accurately manage nearby resources and keep any existing object connections, such as welds, constraints, and more still functional, as well as make the job of programming far easier, as the assets do not have to be continuously shifted around into different locations.


If you title your topic after the problem (“Control over whether instance hierarchies are rendered” / “No easy way to hide certain objects from workspace currently without reparenting”) rather than proposed solutions (API signatures), you’ll find you’ll have a much better time coming up with a good topic title. :slightly_smiling_face:

Feature requests should be about problems, not proposed solutions.

See also: XY Problem