New property: Model.Visible

Basically, a true/false setting whether the model is visible or not. Parts and their descendants would behave as if transparency == 1. I dont know how feasible this would be to implement but there are some very practical use cases:

  • Making certain models invisible while working on others in studio
  • Creating a custom LOD system without needing to loop through all parts on a LOD switch
  • Making a super awesome massive detailed RPG boss that can turn invisible as an ability

I really think this would help the Roblox vision of everything being dynamic, while also helping performance (No more loops! Yay). If you have any more use cases feel free to mention them! :smile:

79 Likes

Wouldn’t an implementation of this use a loop anyway?

It would be faster on the C++ side, and we wouldn’t need to worry about interacting other scripts that use part.Transparency/LocalTransparencyModifier, decal.Transparency, pointLight.Enabled, particleEmitter.Enabled, etc.

Mainly this feature would be an alternative to removing/destroying models, and would keep the model’s physics running at the same time.

16 Likes

To some degree, I feel inclined to create the counter-argument that it is easy to pre-compile a table/list of all the parts in a model that can easily be used to toggle this all. It wouldn’t be difficult to create a little module to do this quite easily. But it still stands that it would be much faster outside of Lua, considering the possibility of hundreds (maybe thousands?) of parts that may need to be toggled instantaneously. Also your points about conflicting with other scripts that interact with transparency is a good point.

12 Likes

I’m bumping this because my co-developer brought up that this exact feature would be great for building inside studio a couple days ago, and now because it seems like models will be getting level of detail functionality soon.

If the (visual) geometry of a model is completely switchable at runtime, a property like the one suggested should be able to be implemented too.

4 Likes

Would be pretty neat since a side project of mine already has a script that uses the LocalTransparencyModifier, but there is also a LOD system which should be able to override it.

I had to create a wrapper to hold and apply the value when a model enters/exits a render sector, but it can get a bit laggy when there are over 500 parts to load.

3 Likes

It’s been almost 7 years since this feature request was created, and I would like to finally see this implemented, as this is a crucial feature of any game engine. Many games engines have this feature, here is some of them:

The ability to turn on, or turn off rendering for a “Model” would be greatly beneficial to development on the Roblox platform, as developers would be able to:

  • Efficiently show, and hide complex or high instance count models, with little computation cost as most of it would be off-loaded to C++ API, where the process could be well optimized by the Roblox engineers responsible for the game engine.
  • Easily show, and hide any model desired without writing their own helper methods, which often requires to save all the current transparencies, and restore them back later.
  • Modify transparency of objects within a Model, as well add or remove children while it is hidden without unnecessary computation, and complexity.

I’m currently working on core feature for a large game that requires me to show another character, and hide the current character. This would’ve just been a simple script like this:

localPlayerCharacter.Visible = false
specialCharacter.Visible = true

But since the feature doesn’t exist, I have to waste a lot of development resources to write a complex function, to preserve character’s body parts, and accessory transparencies, which I have to make sure that won’t change while the character is not suppose to be visible, because, otherwise it will break the transparency preservation feature, and result in some character parts showing up due to the possibility of character controller overwriting them, while they are suppose to be hidden, and thus add additional complexity to ensure that it doesn’t occur, while the character is hidden.

Additionally, I know plenty of developers like to hide interiors of the buildings, when they are not needed to be visible in order to improve performance, but that comes at its own computation cost, especially for complex, and high instance count buildings as Luau code has to loop through all of them, check if they are a “BasePart”, and then finally set the transparency, which has to be saved to memory, and then restored back, and then also account for other code that might be changing transparencies for items in the buildings, such as furniture that is animated. As you may tell, this results in an increased computation, and memory usage, when it could’ve been a simple property switch.

In other words, we have to account for the following:

  • “ChildAdded” event.
  • “ChildRemoved” event.
  • “Transparency”, “Enabled”, or “Visible” properties changing in one of the descendants of the model.
  • “Enabled” property on many instances, such as lights, particle emitters, beams, trails, etc.
  • “Visible” property on instances, such as “Explosion”.
  • Account for instances like “SurfaceGui”, and their descendants.

While it is possible to parent a model to locations, such as “ReplicatedStorage”, to hide them, it may not always be a viable option, such when you need to keep the player character around for the replication radius, or when you want to preserve physical momentum, or also when you want to include a model for raycasting.

Whatever the reason might be, if it’s not already apparent, that’s a lot of work, both on developer side, and the hardware executing the code needed to account for all kinds of things, not to mention that it has to be kept up-to-date, with new features being added, or changed (both developer, and Roblox made), but it doesn’t have to be, therefore, please consider adding this valuable feature to the engine.

21 Likes

Seems quite useful ngl, would probably use it quite often.

1 Like

This is so real

I use the “offload things by banishing them to replicatedstorage” technology because Model.LevelOfDetail is tied with StreamingEnabled and no sane person would ever reference everything to ever exist for all time with WaitForChild() spam

The workarounds that devs have to go through in order to have some semblance of a proper instance loading/offloading system is unreal

4 Likes

For StreamingEnabled, you could also just make interactable stuff and humanoid entities (Players and NPCs) to be always persistent, and geometry stuff will use regular streaming since those don’t have any logic

But custom LOD will always be better