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.
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.
We don’t have a plan for this yet, but we know there’s a a big need to be able to change the color of only certain sections of a texture or mesh and we absolutely see the value in it. We’re tracking this request, but don’t have anything to announce of that front right now.
I doubt it will stay studio-only forever, and from what LightBeamRays is saying it seems like theyre trying to push it to more than just mesh parts. Ive been waiting for a feature like this for quite a while, so the fact that theyre getting this into studio to mess around with is amazing to me, its only a matter of time before its released in a less limited state.
Why is the rendering team so small? If Roblox is so focused on increasing visual fidelity as a part of their “vision”, shouldn’t upper management be focused on hiring more rendering engineers?
Can we please get the option for Nearest-Neighbor texturing for surface appearances? Pixel art styles on Roblox are incredibly hacky to do at the moment.
hey thats finally neat.
the one thing thats now missing is texture scrolling and the entire surfaceappearance thing is perfect, do we know if thats planned?
well… almost, were still missing emission, displacement, and diffraction(which is a roblox limitation but regardless)
I’m somewhat aware of the performance cost it has considering I’ve worked with shaders myself.
I MIIIIGHT have an idea on how it could potentially work.
Okay, let’s say… HSV can be adjusted during run-time, even through scripts.
Let’s give surface appearances a Lua function :GetCopyWithAdjustedHSV(), what this function would do is, it creates a copy of the texture with a temporary asset ID and returns a NEW SurfaceAppearance (or perhaps just a string with the temporal ID) that holds the new, adjusted Albedo/Color.
The new decal asset will exist in memory/storage until the user leaves the game OR until all SurfaceAppearances that hold a reference to the texture’s temporal asset ID are :Destroy()ed.
The pros of this is that this will give/return a re-usable texture and you can just create a new SurfaceAppearance that has an ID to it and works during run-time in a live experience.
The only downside I can think of here is that you wouldn’t be able to create a texture where the HSV is animated for instance but this solutions should work for all platforms.
HSV is only calculated once and after that a temporary and re-usable decal is created.
This is enough for things like character and vehicle customization and whatnot.
And if developers are smart enough to re-use the texture or it’s asset ID, it shouldn’t eat up memory either.
Alternatively:
Since I (and probably many others) don’t make mobile games at all, I wouldn’t mind it being a pc/console exclusive feature.
We already have graphics effects that don’t work on mobile.
And if it REALLY needs to work on mobile too (for the sake of including everyone), I suppose you could use baked/cached textures on mobile and only allow real-time use on PC/console or use shaders on mobile that perform cheaper and less-accurate HSV conversions.
I suppose for mobile you could implement a lookup-table for speedy (but lower quality) HSV conversions.
This is so good but please remove the 255 rgb cap, make it like Texture instance color property. You can actually make emissive textures if you place a really really high number in color3 property of a texture, let us do the same thing with surfaceappareances.
Although I love this feature, I will have little use for it unless if ZIndex were to be released. I’d love to make features such as markings available on my animal characters for character customization purposes, but this is impossible unless if I were to duplicate meshes, which is very costly on performance.
