I mean… it’s only like, half of all people that play the game on mobile… who cares about them??
I know that quite a majority of the user play on mobile devices and that mobile support makes quite a huge portion of the money income …
I am only sometimes bit triggered about the feature limitations caused of mobile support …
Well, whether you like it or not, mobile is the future of gaming.
Either you have have the flexibility to service multiple platforms differently yourself, and that comes with way more complexity, or you can get nice support for all platforms out of the box without having to worry about it at the cost of supporting the lowest common denominator. Pick your poison.
I’ve implemented deferred decal rendering in a few projects of mine over the years. How are you unable to access the depth buffer on mobile if I may ask? I haven’t done much mobile graphics programming as such my knowledge of OpenGL is limited to desktop versions, but from my understanding you’ve had depth buffer access since opengl es 2?
How about a warning when adding in a SurfaceProjection: “Warning: SurfaceProjections may cause lag on lower-end devices.” Shouldn’t developers with no intention of releasing on mobile be allowed to push the platform a little farther?
Since OpenGL ES 2.0, we’ve been able to create GL_DEPTH_COMPONENT Renderbuffers for depth buffer, however; in order to read the depth buffer in a pixel shader we need to create a GL_DEPTH_COMPONENT Texture instead of just a Renderbuffer. Support for this texture format wasn’t added until GLES 3.0
https://www.khronos.org/registry/OpenGL-Refpages/es2.0/xhtml/glTexImage2D.xml
https://www.khronos.org/registry/OpenGL-Refpages/es3.0/html/glTexImage2D.xhtml
There are things we have done in the past where we disable certain features (see, Glass Material) on mobile devices. The problem here is that this is a gameplay feature. Roblox as a development platform is about making it once and being able to play anywhere; something like this would go against that philosophy.
Also, we aren’t going to do the redraw mesh approach because it’s performant heavy and is not an ideal solution for this case.
As stated before we want this feature as much as you guys and will continue to investigate solutions in the future.
Is there any breakdown of which devices use which versions of OpenGL on mobile? I’d be curious to see how much of roblox’s mobile userbase use a device that doesn’t support opengl es 3.0.
~10% on iOS, ~25% on Android. All hail Android.
This however is not just about having the depth buffer theoretically readable…
- On most mobile devices reading depth buffer and then rendering something to the color buffer with that as an input requires an extra operation which is called “resolve” which stores color/depth data from fast tile memory to regular memory, and then “unresolve” to load it back so that we can render transparent objects. This is expensive - we try to avoid this in general, we only have color resolve/unresolve right now for color correction once per frame on mobile.
- Speaking of transparent objects, this approach isn’t compatible with them since they don’t have their own depth data. It’s questionable whether we even want to go there with this limitation.
- Additionally, there are extra complications with readable depth and MSAA; on mobile we currently enable MSAA to make the quality loss from screen downscaling that we do for performance reasons more bearable, and depth readback with MSAA isn’t a path that’s used often on mobile drivers.
Note that we currently have all depth-based effects (sun rays, water reflection etc.) disabled on mobile, there’s a reason for that
Any update on this? It’s been a while and this would definitely be a useful tool with plenty of use cases. I do see that it’s not on the roadmap(probably because of the limitations said here) but it’d still be incredible to have these in games.
We’ve done a thorough investigation into this several months ago. For now we’ve decided to not put this on our immediate roadmap which means it’s not going to happen in a year. But might happen after that, we’ll see. The short story is that we have an idea of how to implement this that should work with all of the hardware we need to support, but it’s a complex system and it has lots of performance challenges to solve so we aren’t doing that immediately.
Very good to hear, thanks!
pardon to dig out this topic from the dead & to bother you, but here’s a pretty flawless implementation of Deferred Decals in the Unity engine, maybe it
could at least help with the implementation on non mobile devices idk …
Roblox has a lot of really smart engineers – they’re generally not going to have trouble implementing something for the latest and newest hardware. The problem lies with mobile devices and old computers which aren’t meant to handle this sort of stuff.
I feel like simply having a size / position property to decals would work fine for this. It already works with SurfaceGuis - to an extent.
EDIT
I also just remembered the texture object already has a size property - it shouldn’t be much more difficult to add a size / position to decals, as well as adding a position property to textures.
the only problem with having a position property is that it might mess up with unions and meshparts. having a sepearate object that does this would be better
Or it might fix unions that have improper texture positioning.
It’s a double edged sword to be honest.
Breaking the silence on this dead thread again, but Developers really need this object. It’s much faster and more efficient than constantly creating new parts with decals on them, all while CFraming, resizing, etc.
I’d say for this feature, Mobile support should be the last priority that the engineers look into until they figure out how to work around the problems present with the depth buffer, rather than cut this feature out because Mobile is currently unable to support it.
Game developers would then have the option to opt for the less convenient and slow alternative of sticking a part onto a surface for players on Mobile.
We have no near term plans for this feature. A thorough investigation was done, and it is currently on the back-burner for now.
Has anything about the matter changed by now?
We’ve done a thorough investigation into this several months ago. For now we’ve decided to not put this on our immediate roadmap which means it’s not going to happen in a year.