Kind of sad that we don’t get to use custom analytics if we’re not a large developer.
2 Likes
I think the definition of Top might be different between you and I. Let’s put it this way, as long as you are actively trying to get your game to be successful and making progress there is a reasonable chance that you will be able to use our Analytics Solution.
Even if not I believe there are other options that will work well for you that we can discuss as the year goes.
9 Likes
Obviously I didn’t see it, but yeah… Bear with me I’m visually impaired.
2 Likes
@Sorcus Will there be support for materials only applying to one face of a part? I know textures can be used for this, but when viewed from a far enough distance textures clip through thin parts, something materials do not.
There’s also this annoying thing where a texture will “clip through” when viewed from a specific angle overlapping with a part. It’s hard to explain, but it looks very bad.
(oh yeah, will 2019 be the year when the games on the Games account are at last uncopylocked?)
10 Likes
It’s gonna be really cool to use custom heightmaps and color maps for terrain. I’ve made my own hobby game engines before, and I had some pretty cool terrain designs in height map form.
That’s going to be one of my favourite additions
3 Likes
Does this mean terrain will get even more optimizations for bigger games to use? Because currently this is a issue with terrain. Can terrain optimizations be improved? Other than that everything on the roadmap looks cool and very good.
2 Likes
Very unsure about open-sourcing; for one this will make exploiting (e.g. code stealing) easier. I’m assuming for personal projects you can use LuaJIT?
4 Likes
Massive thanks to all the amazing staff working at Roblox to provide us with these features and also update the roadmap.
In particular I’m most excited for procedural vegetation / foliage and custom normal + specular maps. There are both things I’ve wanted for a very long time and never thought I’d get to see on this platform this soon.
4 Likes
JIT isn’t a possibility on iOS and Xbox - these two platforms are two of the three platforms we support with the weakest CPUs (the third is Android where JIT could be implemented in theory).
JIT is also a substantial security risk - we need our system to be completely sandboxed and that’s somewhat challenging.
Finally, specifically for LuaJIT there are other problems - the specific way that LuaJIT implements JIT compilation is prone to deoptimizations (The LuaJIT Project) and these transitions are costly; we need a tight integration with our C++ APIs that often require VM changes and LuaJIT isn’t easy to change; finally, LuaJIT design prevents some optimizations that we need to do that would be impactful for Roblox code specifically, for example faster Vector3 math.
There’s going to be no JIT this year. We may eventually implement a lighter weight JIT option that will be slower than LuaJIT but faster than what we have today, but that’s a long term possibility.
28 Likes
Are those supposed to be fixes, or new features/updates for Roblox studio?
1 Like
Just curious, I didn’t see phase 3 of future is bright at all for this year on the roadmap. I’m guessing it was moved to next year?
1 Like
The reason that happens is that textures on part faces are actually marginally larger than the part face, to stop issues with z fighting. If they were the same size, then you’d see a ton of flickering.
3 Likes
Aren’t sun shadows phase 3?
3 Likes
Can confirm faster Lua is actually super hype. Source: I’ve written more procedurally generated stuff than probably anyone else on this forum and I’m constantly running up against the performance barrier. (see: Project Vox, the entire game is procedural)
6 Likes
Checked it out, and it lagged a lot. Really cool project still, hopefully it’ll run better with faster Lua.
2 Likes
If you can extract the performance sensitive parts of your code into a simple reusable model that we can add to our test suite that would make sure we’re capturing all important performance optimizations. The requirements are that it should be simple to trigger the execution - preferably smth like require(somemodulescript):Generate() - should run to completion in a single call without yields, and should produce repeatable results so it can’t rely on unseeded random generators or any other external input.
2 Likes
I’m assuming math.noise() counts as external/random input?
3 Likes
math.noise is fine, as long as the parameters aren’t coming from smth like math.random() without calling math.randomseed() 
math.noise is deterministic.
3 Likes
Yes this feature was amazing what ever happened to it are we still getting it in the future?
3 Likes