This might actually be very useful for creating roads. At the moment, it’s sometimes hard to line up parts with the terrain, but this way we’ll be able to make more curvy, less “static” roads that have lots of bumps and things that can put a car’s suspension to the test.
This next one is Google Earth, so it’s not high quality, but it gets the point across 
Might be just my opinion, but making roads with this feature is a really weird use case. It’d be probably better to make a MeshPart road instead.
A few of the examples on this thread seem really weird for the type of object that I’m imagining this to be. The one with projecting textures on to guns, for example.
I imagine this to work like projecting on to a screen from a distance would, and would probably be set up somewhat similar to how raycasting works. It seems like it would be really awkward and a weird use case to set up a projector to always be pointing towards a gun just to put a skin on to it.
Am I misunderstanding something here?
I 100% support this, this would definitely help me with texturing things with lots of parts/unions, as normally those would be very challenging to texture. I’ve been building things like flowers,succulents, and many other plants with 40-80 parts per plant, and surface projection could definitely help with texturing parts of the plant, rather than having to make a special texture for every single side of it. The current decal/texture system is a bit tedious with this kind of stuff, and it would DEFINITELY have many use cases for me.
we still need this .
To anybody still asking for a usage case .
Buy and play World of Warcraft .
It features few thousand usage example of projected decals/textures.
Alright, I think I’ll finally break the silence on this feature.
@programeow prototyped this last November, and here’s what it looked like:
Now comes the hard part… We aren’t going to be able to release this feature as of right now. We want to continue to take a look at options surrounding it but there were serious performance implications when we did this.
This approach that is being used in this gif is commonly used in other games such as Doom, it’s called “deferred decals”. This would work best for moving decals. Unfortunately, we can’t ship it because we don’t have access to the depth buffer on mobile.
The “redraw mesh” approach that was also brought up and this uses where we do the projection pixel shader. Other games use this, but it isn’t that great when you have a lot of them. Example: This wouldn’t work with bullet holes. Also, this would cause terrain to be drawn twice and that would be too slow.
We could take a “static geometry” approach where we create a mesh for each “sticker”. This would be a large project, but the decal wouldn’t be able to move nor would it be able to project to multiple parts.
So here’s the thing: This is a highly requested feature, and there are some really good use cases for it. There are just some problems we need to solve on the tech side in order to make this happen. We hope you all understand, and we will definitely continue to look for solutions in the future.
Thanks for the news (:
but
great … mobile support is always the problem .
always limiting the Roblox engine 
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…
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.
