I’m hoping for this too. Specifically for character customization systems, being able to layer PBR textures (and tint them individually) would extremely useful. It’s not currently possible to do this without duplicating the mesh, which is inconvenient, especially for animated rigs.
If this isn’t added, I imagine it will be possible with EditableImage, but having something like ZIndex for SurfaceAppearance would be much more straightforward.
FINALLY!!! Super happy to see this, thank you so much for your work guys!!! I cannot wait to see how it evolves and also cannot wait for August 22 [I hope it makes it for that date]. It also comes in a great time! Thank youuuuuuu so muchhhhh!!! :]
This is a great change.
Any chance that we could get a Transparency property for SurfaceAppearances too, and also the ability to apply more than 1 SurfaceAppearance to a mesh (and configure their ZIndex)? This would be absolutely amazing and be a massive step forward.
Thanks for adding this.
Interesting to see Rojo being acknowledged like this. I always thought it was a fully unofficial third-party plugin.
Amazing update. I’ll be able to create tree variations automatically when a game loads, and even add seasonal update without any change to meshes.
Cant wait to see this move into game.
Modelling / rendering shopping list
DoubleSided.PreloadAsync support for SurfaceAppearance.Very happy this is finally out
good feature but… emission maps when???
This is insanely useful, thanks Roblox!
Very nice update indeed! Kinda disappointed that roblox kept the emmisive maps for themselves (lava cracked texture)… hopefully that’ll be public soon!
I’ve been waiting for this for so long, we’re finnaly able to change the tone of mesh textures without having to constantly edit and re-upload it.
Thank you so much for this
I had absolutely no clue that they released a new version, Because I still used an old version from LPGhatguy aka Rojo 7.2.1 , But glad I’ve seen this before its too late.
Re: Adding maps to SurfaceAppearance (+ @Ron1n_Sim, @gluGPU, @TucsonGuy, @CaioAlbarnBR, @Shinrai12, @SomeFedoraGuy, @Razorter, @PestikLove, @Linux_55)
We have those requests on our radar and especially emissive maps as they are very much requested by the community. At this time, our small rendering team is focused on other higher priorities, so we don’t have any plans to share, but we are tracking these requests and keeping them in mind.
While it’s sad emission is not worked on at this moment, or atleast actively, it’s rather relieving that the team knows about the request. Thanks for the insight
Your work is truly amazing. Seeing more and more great features being updated frequently makes every day exciting. Applause to all the developers!
Can i add to this list, the ability to enable/disable PBR both in studio and through scripting, so it can switch to using standard textures.
This would help with mobile support by adding something to a custom settings menu that would let players choose if they want to use PBR or not, depending if their device can handle it.
Thank you! We know how crazy it is to handle so many features, we’re glad you guys are keeping it in mind
This here will be absolutely amazing. So many use cases i can only begin to imagine, especially neat for making seasons
Re: More coloring options on SAs and Textures (+ @HealthyKarl, @Bam_Sori)
Re: Multiplying parameters for roughness and metalness (+ @GloryToTheSunGod)
I’m bundling these 2 topics, since the answer is actually the same for both.
We have discussed adding multipliers to the other SurfaceAppearance maps as well as HSV shifting to both Textures and SurfaceAppearances. However, we are currently fighting shader register pressure on mobile devices and any extra inputs we add to our shaders can result in a significant performance cost, especially on mobile where the majority of our players are. HSV shift is also a quite expensive shader calculation in itself. We were able to pull off SurfaceAppearance Tinting, but it’s not a generalizable solution for many more parameters.
We could add these options as edit-time only, non-scriptable. That would mean modifying them would create a new texture in the backend for every variations. We thought this is still not what the community want and the memory cost could sneak up on users, which wouldn’t be a great experience. We’re open to hearing thoughts about this idea, though!
The TLDR is: We don’t have a clear path to support such features performantly at runtime right now. While we would like to offer these features, the work needed to figure out how we’ll do that is intricate and we are addressing other priorities at this time.
It would be so appreciated if Studio-only features could be kept to a minimum. There’s tons of potential to be had with recoloring MeshParts without the need of extra textures during runtime. Avatar customization would benefit a lot from this, along with all other cases where recoloring required more memory usage due to new textures.
But if something is locked behind Studio-only usage, that feature often becomes tossed away in the backburner for actual in-game use, and we often will not get any update regarding to new functionality related to whatever new feature was pushed out.
Related to rendering,
is there any chance we can get any sort of better transparency features for MeshParts and/or SpecialMeshes?
Using SurfaceGUI’s one can have singular images on the workspace that overlap correctly with eachother,
but when trying to create more complex effects that curve those images it becomes impossible. Inputting an image with transparent background on a MeshPart’s texture field with 0.011 transparency does not work correctly at certain camera angles. Same with using a Decal on a Part with a SpecialMesh component.
https://x.com/SrRafles/status/1489474637348093952
Combining spritesheets with meshes can help to attain very professional effects, and given that the Roblox team already put work into particle effects with spritesheets, it would be incredibly appreciated if there was any way to get transparent meshes with textures to display correctly.