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!
Beams
We shipped Beam effects (https://devforum.roblox.com/t/beam-effect-is-live). 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 (https://devforum.roblox.com/t/roblox-version-317-is-live). 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.
Glass
There is now a new Part material for you to play with, Glass (https://devforum.roblox.com/t/introducing-new-material-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 (https://devforum.roblox.com/t/rendering-updates-april-2017), 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.
???
what do you mean by “dual render”?
