A lot of simple, great UX opportunities would be opened up with the addition of these two values. Basically, the distance from the camera that decides when to cull BillboardGui’s contents from appearing.
This functionality technically already exists, but it’s only for Humanoid’s HealthDisplayDistance & NameDisplayDistance.
It’s not a matter of how easy it is to script. If it’s functionality that a large amount of people need the object to do for their game, it can be proposed and implemented so people don’t have to re-implement it every time.
Ex: Color3.fromRGB. You could divide by 255 every time you hardcode an RGB value, but that gets annoying every time.
Something a large amount of people need is MeshParts to scale under 0.2
We know this because we’ve seen so many threads about it. I think that this feature request is one of the first of it’s kind, which says something about how much it’s needed. I’m all for more features (I’m not against this), I just don’t think it’s worth the administrators very dense time right now. Just my 2c.
Let the engineers decide what’s worth their time and what isn’t.
People are allowed to freely propose ideas that they think would improve the client’s capabilities. Regarding MeshParts scaling under 0.2, use a separate thread for that proposition (I know they already exist)
I’ve been playing Ubisoft’s Steep and they show you checkpoints and map locations from far away but hide it when you’re close. They also don’t show all areas, only ones moderately near you (hence a max distance).
I’d definitely want a max property for custom healthbars and nametags.
The question of how this is implemented is central to the discussion, I think. I don’t think that fading out with distance (near or far) is something that needs to be done at the engine level.
However, I do think that we could do other things to make it easier/faster. I’ve been thinking about proposing a hierarchical transparency modifier for GUI objects that would be perfect for things like this. Basically, you’d set BillboardGui.InheritedTransparency and all of its children would be rendered with that transparency. I was thinking that for each child, the total opacity value would be calculated by (parent->getInheritedOpacity() * myOpacity). This might be confusing though. Any better ideas?
This might actually be a good way for it to work, now that I think of it. It’d basically mean that you can fade entire trees of GuiObjects without needing to care if they each individually have different transparencies.
Seeing as something like this would require calculating the distance between the camera and the gui, might be nice to have a built in distance property that’s updated every frame for devs who want to implement transparency as well.