I’m only talking about updating a single property per instance en masse, no where do I refer to traversing the entire DataModel hierarchy.
This isn’t even an issue specific to ‘visibility’, try updating any single property for a few thousand instances and you’ll start to see frames drop. That’s because the overhead is from the compounded cost of userdata reflection, which is unavoidable in this case. You should avoid updating as many instances as possible, not update even more in hopes it’ll somehow pay off.
I don’t know where you got the idea of doing your own frustum culling, that is not implied anywhere in my post, I genuinely have no idea where you got that from.
Nobody is wanting to do that nor is asking to do that.
No it’s not going to take 5 milliseconds to flip CanRender on a model containing all outside features when you’re inside a building.
You are arguing against a point that never existed in the first place, nobody wants to do custom frustum culling with this.
Please re-read the initial use-cases, you have a MAJOR and fundamental misunderstanding of the use-cases put forth.
I’m entirely in support for something like this. I want to hide the lobby or the game map from the player when necessary. Currently, to facilitate this, I parent the map or the lobby to a temporary folder in ReplicatedStorage on the client. This would make that no longer necessary, and remove the overhead and issues that come with re-parenting objects on the client.
I just assumed that’s what you meant by ‘World/Environment Unloading’, you even implicitly refer to it with your Car Crushers example. I mean, frustum/occlusion culling is the de facto way to achieve environment unloading in pretty much every other engine outside Roblox. In fact, I can’t think of any other unloading system besides portal culling (which might be want you want to achieve…?).
It sounds like you just want some way to remove the outside details of your map when the camera is in some enclosed space that can’t see them (to reduce drawcalls or whatever). That’s cool, but doesn’t occlusion culling already do that for you? Your point on Car Crushers’ buildings is pretty much already solved.
And just to be clear, I’m not against a CanRender property in general. I’d like to see it get added regardless of any performance aspects. I just don’t believe it will be of any meaningful value for large-scale map optimizations in the likes of what you’re expecting.
Considering CanRender and Renderable are intended to be inherited, I don’t think you are supposed to update a single property per instance en masse. This is just you being slightly nitpicky, which is fair I guess.
Cursor, windows, etc. all do not utilize Roblox’s RBXScriptSignals for any GuiObject. I created my own bounding box checks for mouse input, though I still bind components to Visible to determine if they should be detected as something the mouse can interact with. This is greatly overcomplicated since I have to walk up every GuiObject ancestor of a specific component to see if any of them are not visible. If I could just do component:GetPropertyChangedSignal("Renderable")…
And, this especially:
Funnily enough, this same game also needs this. I load and unload other player characters via LocalTransparencyModifier when they are not in the same scene… but if I just had the ability to toggle CanRender off…
I also think in some cases, this could have a good boost in performance. Instead of setting dozens of parts’ LocalTransparencyModifier to 1 or 0, they all stop rendering at once.
I use a custom LoD system for trees in my game, reparenting chunk folders in and out of ReplicatedStorage, which is not ideal for performance.
If occlusion culling can instantly decide to render/not render an instance, it seems like a CanRender property like this would be a lot more performant than the existing methods (transparency, repositioning, or reparenting).
