We’re announcing that outlines (aka Lighting.Outlines) are officially deprecated. Don’t panic - deprecated doesn’t mean removed! Here’s what will happen specifically:
- We’re introducing a new property, Lighting.LegacyOutlines. It defaults to false.
- On July 1st, we will start using this property instead of existing Lighting.Outlines property to determine whether to show outlines in games
UPDATE: July 1st has come and outlines are officially deprecated now; Lighting.LegacyOutlines can be used to re-enable outlines on your game if you really really really need to.
If you currently use outlines and they are critical to the visual style of your games and you’re okay with the performance implications of enabling outlines, you can enable outlines using the new property and your place will not change its behavior on July 1st.
We will continue to support outlines through LegacyOutlines property for at least the remainder of this year. No promises for next year, but this means that for people who really need outlines it’s a simple checkbox you need to check for now. We’re giving a heads up early so that there’s no point where your game loses outlines. Of course you’re free to change the new property later as well.
We’re doing this because status quo is broken, and we need to fix it. Let me explain.
Status quo
When we shipped outline support in July 2013, Roblox was very different in two key ways - we thought that we should dictate style and we didn’t think as much about honoring the existing content’s behavior. Because of this, the choice was made to enable outlines by default in all existing games. Due to the community response, in August 2013 we have implemented a property that allowed you to disable outlines, but they were enabled by default.
As is probably obvious from how we have been shipping features for last few years, today we would not have shipped outlines like that - they would at least start as an opt-in feature - and we wouldn’t try to push a purely optional visual change like this on developers in general. inb4 lighting comments, compatibility vs legacy is a much much more nuanced topic that is adequately covered elsewhere
Over the next few years, it became even more apparent that by and large, developers don’t appreciate outlines. Many developers told us that the first thing they do when they create a new place is disabling this feature. In other words, this was a misstep. To align better around the developers’ preference, we have changed new places in Studio to come with outlines being disabled by default; this happened in September 2017.
Outlines were built around the old rendering system (aka featherweight parts); as we developed the new, more GPU-friendly part rendering system (Part Instancing - pre-release announcement), it became apparent that it’s impractical for us to support outlines in the new system since the performance penalty would be too severe for a feature that most developers don’t use. (outlines carry a cost in the old system as well, but there we were able to reduce the cost to be acceptable).
Because of this chain of events, we are in an odd place:
- Outlines carry a performance cost - they disable part instancing which adversely affects memory consumption and update performance
- Most developers don’t use outlines
- Some places that have outlines enabled do so because developers of those places wanted outlines
- In some places that have outlines enabled that happened without developers explicitly choosing them
This change intends to clear this up. With the introduction of new, separate, property, we are essentially making it so that developers who strongly favor outlines are required to enable this property. This means that for the majority of developers, outlines will be completely disabled without them having to do anything about it. From there on we will be able to work with select few who choose to enable outlines, and find alternative strategies to help them achieve the look that they want - our long term goal is to remove outline support in its current form from the platform, but it won’t happen this year.
Long term
For such a small feature, outlines carry a significant complexity cost. The core of the issue is that they aren’t composable - their implementation doesn’t layer on top of the rendering code (like, for example, sun rays do), and it’s not an implementation detail of a single material (like, for example, water reflections) - instead it infects all of part rendering. Specifically:
- As mentioned previously, outlines disable new part instancing system completely. We still need the old system for various reasons, but it does mean that there’s a very non-obvious large cost associated purely with enabling outlines.
- Within the old system the fact that all materials need to support outlines means that we need to spend extra data in each vertex (we managed to reduce the cost to ~10% of the full vertex data but it’s still not ideal, especially since the old system is often used on low-end devices)
- On high quality levels, we spend extra resources on computing outlines which is not very trivial - this cost is paid regardless of whether outlines are enabled because of the deep integration that outlines have into the rendering system. It’s not that significant of a problem since it doesn’t affect low-end, but it’s not ideal.
We have discussed alternative ways to deal with this problem previously that could be easier for us to maintain. Maybe we should implement a special material type that can support outlines in a bit of a different way - maybe it doesn’t work on wedges / has some other special properties. Maybe we should implement a full-screen edge detection filter that can, on high-end systems, dynamically add outlines to visible geometrical edges - which may actually work for cartoon styles unlike our current outlines.
The crux of the issue is that as it stands today, outlines are problematic for the long-term evolution of our renderer, and there’s no obvious way to keep the interface/behavior and change the implementation to make them simpler to maintain. However, it’s very possible that we can add a different feature that will cover, say, 80% of the use cases for developers who do need outlines, and unlock a set of use cases for developers who don’t, and that feature would be implemented in a way that’s easy for us to maintain it in the future.
For developers who choose to enable LegacyOutlines despite the performance drawbacks, we will have to study their use cases and come up with what exactly the replacement features might be.
GPU-friendly updates are always welcome.
