As a Roblox developer, the current cap of 31 Highlight adorns active at a time has been very limiting to some of the things I’m trying to accomplish with the feature.
We have a house editor (currently unreleased) for our game that utilizes Highlight to mark multiple objects as selected. In the screenshot above, the floor is made up of tiled objects whose Parts are all in separate Models. I’m doing a floodfill selection of top-surface tiles that are brown and highlighting them as one unit.
Because of the 31 adornee limit, I currently have 3 options for handling this:
Put a Highlight into each individual model (This hits the 31 adornee ceiling pretty fast, so obviously can’t do that)
Clone all of the parts I want highlighted into a single container (Cloning a bunch of parts on demand like that is not ideal for performance)
Temporarily move all of the parts I want highlighted into a single container (Mostly safe as long as the parts aren’t running interaction code, probably lots of risky caveats)
Currently I’m using the 2nd workaround, but it’s really awkward that I have to do this in the first place.
Possible Solutions?
While it’s not my job to offer a solution to this, I’d like to offer a couple potential ones worth considering.
It would be cool if we could programmatically add and remove PVInstance targets onto a single Highlight instance. Maybe an API like this?
Why is there even a highlight limit? There isn’t a part limit, or a billboardgui limit, or any limits, really. Roblox states that it’s for “performance,” but it’s dumb to arbitrarily limit developers like this, especially for PC-only “experiences,” where stronger hardware is present.
As far as I understand, this is a deep technical limitation likely related to the number of bits in a number used in some implementation detail for this feature, or else tangentially related. A single outline shader typically requires an input texture with all of the geometry to be outlined rendered to it, so an outline shader that supports multiple outline groups probably requires an input texture with multiple groups rendered to it, so each group in this texture would need to be rendered with separate values (e.g. red channel pixels being 0.1, 0.2, 0.3, etc as a simplified example), but a pixel in a memory-optimized texture only supports so many values + there are other implementation details that can introduce problems. Just speculation of course, but likely a close reason why this is not trivial.
It would likely significantly increase memory footprint just to double the limit (at least on mobile devices, but allowing these to have different limits breaks a lot of developer expectations and is bad), not to mention complicate the programming behind the scenes which also likely comes with a non-negligible performance cost.
If you look at the render passes in renderdoc, you can see that for DX11 the effect is generating an 8-bit red-channel-only stencil texture with all of the outline groups rendered to it with different R values according to depth from the camera, which relates to the speculation above.
The value of 31 (which is 2^5 - 1) is also a hint that this is likely a technical limitation in their graphics pipeline currently and so not necessarily trivial to increase.
I was in the same mind-set when I read about the Highlight limit until I found out that it’s not about the number of objects you put it on, but the number of highlight objects itself that exist. Knowing that, I don’t see a reason to increase the limit since that is basically an unlimited number of objects in 31 different colors if you prefer. I wouldn’t object to the limit being raised, but I don’t see any technical reason why needing more than this number would be useful?
I need highlights to indicate that what the player is hovering over is interactable. At any given time, almost all of my Highlights have their transparency values set to 1 to indicate that they are off. I built my game around this instead of Instantiating them Destroying them (as I should have) but it turns out that a lot of people want to use this for X-Ray vision for locating teammates and stuff, which requires as many highlights as there are players.
Having a higher limit in game would be nice, but since it’s been a while since OP -without any reply- I’m not that hopeful for it.
Any chance the limit can be increased for studio only?
If it’s a (mobile) performance limitation, then it might work for studio where everyone uses a relatively powerful PC?
Looking to use highlights in a plugin. Current workaround would be to dynamically adjust the highlighted parts, which is definitely not ideal for my usecase.
There is a workaround for this.
Make a dictionary defining all the initial parents of the objects a player selected. Then, make a temporary folder and parent all the selected parts to it and add a highlight in that folder. Since it’s only 1 highlight, there is no limit to how many parts you can highlight at once with this method. If an object is deselected, you can fetch it’s parent from the dictionary and parent it (I would suggest creating a fallback system to avoid unexpected errors due to lag spikes, high ping etc.)
Please mark this as the solution if it works out for you.
This however also disallows you from customising colors of those highlighted parts as they must all use the same highlight properties, all of the highlights are treated as one (so there isn’t any border where two different objects overlap) and is also a pain to pull off, requiring you to basically design your game around the limitation. This workaround is infeasible for those reasons.
You can make separate highlights if you need different colors. You would almost never need 31 colors.
Also, setting the OutlineTransparency property to 1 will fix the border problem. If having the outline is a really preferred stylistic choice, there is no workaround for overlapping borders; it’s just one of the cons that come with using Highlights.
That’s true, but we all know Roblox. They take 5 years to fix simple bugs despite being aware.
It’s more logical to use workarounds than to wait for bug fixes, since if you do, your game won’t be coming out in a million years.
Plus, you could always code the workaround as a “outcast”, meaning only the bare minimum game mechanics rely on it, and it can easily be removed without affecting a lot of the game’s code.
