Rendering Updates - November & December 2017

This is a thread with rendering updates for November & December! We are in the code freeze period so we won’t ship any new changes for the remainder of the year. It was a great year - we shipped a lot of exciting features. Thanks to @ConvexRumbler, @Homeomorph, @maxvee, @programeow, @Qiblox and @zeuxcg for working hard the entire year on all of this - next year will be even better!


We shipped Beam effects ( These are a bit similar to Trails - you need two attachments - but instead of following the motion of the line defined by two attachments, they render a series of segments approximating a Bezier curve between the two attachments, with controls for width/etc. You can refer to the thread above for usage examples.

Since the initial release we’ve also fixed a number of issues you have reported:

  • Fix color issues for last beam segment in certain cases
  • Improve texture interpolation when width0 and width1 were very different
  • Improve performance by culling distant beams on low quality levels
  • Fix rare cases where beams would not render even when they should be visible

Terrain colors

We shipped an ability to change terrain colors ( You can now control colors of individual materials via new APIs, Terrain:GetMaterialColor/Terrain:SetMaterialColor, or in Studio using MaterialColors property group in property grid.

Some sort of color/texture control was one of the highly requested features as a result of a previous roadmap poll; this specific feature has minimal performance impact and no memory impact, and hopefully should address a large portion of the use cases (by making the terrain more varied, or sometimes maybe even dynamically changing the colors at runtime - in FE games you can do it per client from a local script).

We have considered and - for now - discarded alternative options:

  • Per-voxel color - this substantially increases both voxel and rendering memory cost, and makes the implementation much much more involved; in addition we would have to limit the color palette to BrickColor palette because a full Color3 per voxel is completely infeasible. This might still happen one day as an extra layer of variation.
  • Custom textures - we currently do not have some backend systems that would allow us to do this without memory implications on all platforms; additionally we’d have to carefully consider the download bandwidth implications.

Overall I think per-material colors are a great 90% solution - it satisfies most of the use cases and we could ship it this year. We will continue looking into other customization options as terrain evolves going forward.


There is now a new Part material for you to play with, Glass ( It features color tinting, Fresnel sky reflections and refraction support. You can now build bottles and glasses that look nicer, stained glass windows that more faithfully simulate optics, cloak/camouflage suits, scope lenses, looking glasses and a lot of other cool stuff.

Word of warning - many of you have excitedly discovered that glass does not render other transparent objects behind it and are using it for many creative effects. While this is undoubtedly cool, keep in mind that:

  • This is a known deficiency that we decided to ship with because we don’t have a good performant solution; we will continue to investigate potential approaches here and one day all your cool invisible models will break. And when they do, we will not feel sorry.
  • Taking advantage of these tricks requires using Transparency ~0.02 - this is one of the worst things that you can do for performance on both desktop and mobile, both on CPU and GPU. Please do not change your levels to use lots of parts with Transparency 0.02.

Increased max render distance to 100k

We used to have a hardcoded draw distance cap of 5k studs. You would only get to that distance on high quality levels, of course - but it would never get larger. This was a problem for some large games that wanted 10k or more studs of view distance.

After carefully evaluating the impact of large draw distances on precision we decided to go all the way to 100k. On devices that support increased depth precision update we shipped earlier this year (, you will have good Z precision everywhere; on other devices you may see increased Z fighting on objects >10k studs away from the camera.

This update should be live everywhere but remember that it depends on the quality level - on low quality we will still limit the draw distance as before.

Vulkan on Android 7.1+

We have been working on this internally for quite some time now, and now it finally works well enough to ship. You might remember us shipping Metal support on iOS late last year / early this year, and this is an equivalent on Android. It’s a low level graphics API that makes rendering large worlds faster, improves battery consumption for small worlds, and opens a path towards having better visuals on Android since more features are readily available there.

This was (and is) very challenging because of a sheer number of Android driver bugs; we currently don’t have it enabled on Android 7.0 because of an outstanding issue. In addition, we have instancing ready to run on Vulkan but we’ve discovered a driver bug with this on Android 8.0 so it’s currently off.

We expect to enable Vulkan on Android 7.0 early next year, as well as to enable instancing on all Vulkan-compatible devices at the same time. Based on our earlier metrics, this would improve the experience for around 10-15% of Android users which is not a whole lot but this number will increase over time. We also have some future Vulkan performance improvements planned.

Various fixes and improvements

As usual this is an assortment of small tweaks, reported both internally and by developers:

  • Fix the fact that at 11:59 pm and 59 seconds, the moon teleports over FOUR THOUSAND MILES
  • SurfaceGui/BillboardGui with LightInfluence now receive humanoid shadows
  • Improve stability on early Android versions
  • Fix ShowDecompositionGeometry rendering - now individual convexes have unique colors as before
  • Fix teleport interaction with asset loading causing RequestQueueSize to never become zero in some cases

Miscellaneous performance/memory improvements

We shipped almost everything we had been working on in this category, except for one change that unfortunately ended up being too complicated so we’ll have to ship it early next year. We have a lot of plans for further improvements but for now here’s what is live today:

  • Improve video memory reporting to correctly recognize video memory amount on some laptops. The old code could accidentally decide that your device has very small amount of VRAM which would lead to low quality character textures and occasional texture flickering.

  • Improve character texture compositing performance - it now takes ~50-100ms less time for the character texture to update.

  • Fix cluster invalidation starvation where a lot of part updates could monopolize the update budget and cause some parts to seemingly never update. This has been reported multiple times in the past; instancing fixes this for Mesh/CSG parts, and we now fixed this for all other cases as well even when instancing isn’t active.

Aaand that’s it folks! As always please let us know if you experience any issues with the mentioned updates.


Glass kinda acts as a lower quality dual render thingy. Can we expect dual render stuff for scopes and such in the future :grimacing: ???


The speed at which your team builds features these days is nothing short of amazing. Phenomenal job on finishing out the year strong!


I’m not sure I understand this :frowning: what do you mean by “dual render”?


Any other future plans for memory improvements to meshparts? (in other words, am I good to start uploading my meshes to roblox? as before there was an update that only affected newly imported meshes)

No; we have some plans to improve download size for mesh parts but that may not happen for a while, upload away.

1 Like

It looks like what glass is doing right now but more clear and the ability to change the magnification.


I think you can distort the view through the lense if you make it thicker or more curved. If they did something like this as you’re suggesting, how would this be exposed as an API?

I have no clue honestly. Best I can come up with is something like a SurfaceGui or some other UI element. I remember them saying how blur in select areas is more costly than blurring the entire screen or something like that so I don’t know :man_shrugging:

1 Like

You can distort - however the quality is very low so it’s fairy impractical to use.

Obviously not the intended use case, but would be awesome anyhow.

@zeuxcg Awesome work on this! I’m really excited for the 100k render cap. This fixes so many issues for a ton of genres!



All looking good - now to look forward to even more goodies.

what’s the limit on the draw distance per quality level?

graphics 10 = 100k studs
graphics 1 = …how much

The reason I ask is because in a game I’m working on, I want all clients to see low-poly islands far away (5k, 10k, 20k studs away), and pop the real islands in when they get close. This is all done locally based on distance/zones. I don’t want the 10-brick low-poly islands to be cut off at 5k studs, lol


Thanks to you and the team for all the awesome updates this year! Looking forward to next year.

1 Like

Some really cool updates recently. Thank you!


To build on that. Defining a camera and an output (to a UI element) would be quite interesting to see. Could make some really cool effects ^^


I found a bug with terrain colors

On lower quality levels, transitions between two materials will revert to the original color
Level16 (how it should look):

The dark grey from the first image is the original color of the rock texture, which I changed the color of to appear lighter and redder.


So this works for gun scopes in short range application as shown below.

The only thing I could think of at the moment to improve it is increased magnification for long range or semi-long range sights, or whatever neat application you may have for it!

It looks neato when firing!


Yeah good luck hitting anything at 144p

1 Like

And also not being able to see the bullet trail lol


I’ve done this before in Unity. Basically, Roblox would have to support multiple cameras and some kind of way to render a camera to a texture that isn’t the screen. A kind of Roblox-y way of doing this would be to have a UI element called CameraFrame that has a CFrame property, a resolution, an FoV, and some properties involving render distance, possible a layermask for what’s being rendered. This’d allow for cool things like mirrors and CCTVs and the like but would probably be difficult to implement. I’d imagine the Roblox Dev team would have to shuffle around a bit of the render pipeline to manage this, esp. coming from their current one camera at a time system. I’m mostly just thankful for the incredible features that they’ve come out with in the past month.