Not having shape keys yet is really dumb, roblox is really behind.
Let’s just keep bumping this… such a simple feature that we need!
And atleast give certain users access to higher resolution texture maps, but still a limit on how many.
Sir yes sir,
Honestly we could use with some info about this. Could a staff member give updates?
I have zero expertise on this stuff, so please correct me here if/where I am wrong.
I can only really see this happening if we get a new class whose instances are parented to SurfaceAppearances, similar to SoundEffects, UIComponents, and PostEffects. If that is possible, it is the only way I could see emission maps not retroactively increase the complexity of all SurfaceAppearances.
Elttob described this really well what exactly this would do:
On unrelated node, @Elttob is a shadergraph still not viable at all? if we would limit it to What OpenGL ES 3.0 and DirectX 10 supports, wouldn’t we still have SO much more that we can do? Because I remember reading the post from zeuxg where he described why a shadergraph is very difficult, not just the shadergraph specifically but user created shaders.
But considering this was in 2016, we now could do much more couldn’t we? Since OpenGL ES 2.0 support was completely dropped (at least to my information), GL ES 3.x could do far more?
I know there are still underlying issues such as shader compiler security, couldn’t Roblox just ship a shader compiler for Studio, which is used to preview shaders inside Studio, where they also integrate something like Unreal where you can preview the shader on different graphics API’s, I forgot what exactly it was called in Unreal Engine but i remember it had a thing where you could preview different shader quality levels for different platforms such as Mobile (Metal, OpenGL, Vulkan) or Desktop, Console and so on. And then if a user ends up publishing a game they send over the shader that they want to integrate into their game, which is then compiled on Roblox’s backend (also is checked to prevent any illegal operations in the shader that could be used to exploit the shader compiler?) and is then shipped within that place? Meaning that you well couldnt dynamically add any new shaders, unless Roblox adds support for loading shaders from e.g the toolbox that were verified to be safe during runtime.
Like, what is the current state on a shadergraph? Its been over 8 years since that post from zeuxg.
Edit: I forgot to include the post from zeuxg:
I did indeed read and like that reply back when they posted it. My first sentence was more about whether or not the modular approach I proposed could even work in this case. I would not be surprised if that isn’t an option here the way it was for the other things I mentioned (unless the release of SoundEffects did make all sounds take up more resources whether or not they actually have SoundEffect descendants, for example).
If the referred post did account for my idea back then, I definitely fail to make the connection.
It probably doesnt make sense to create a whole new instance for something that would be a part of a surface appearance. So it would likely be a extra property. But given that then some people would want something like:
- Multiply Emission Map by a color (and also have it be scriptable like the recently added SurfaceAppearance.Color)
It would just make the SurfaceAppearance class more and more complex while still being so limited, shaders are something I prefer far more and I believe that Roblox could make a primitive yet very cool system for developers to use!
So what if a game has thousands of Surface Appearance instances? Same thing applies to Albedo, Metalness, Normal and Roughness map, one more map won’t affect anything much + Most instances may have it set to nil so there’s no change.
I wouldn’t know about any updates beyond what I’ve heard at RDC or from other devs who’ve talked with staff.
Ah, alright. Hoping that something with a shadergraph will come at one point because its such a huge feature.
bumping this again pls roblox what’s so hard abt adding this feature
The amount of things Roblox studio is missing or half-releasing is absurd. I’m grateful for the clouds, future lighting, IkControls, code optimization, and server ram increase. However, there are some simple things that they are missing that come built into most game engines. They must step up their game and try to implement what the community could use the most. e.g. Shadergraphs, Rendermodes, and other stuff. bump
Bump. Do I even need to say anything?
I’ve talked to @CoastalStarlight at RDC, he had a good idea of how emission could work.
Currently like @Elttob has said, roblox uses RGB/ARGB image packing for the TexturePack for surfaceappearances. Coastal told me that one of the channels for the PBR is unused, im not sure which channel but basically Metallic and Roughness are packed into 1 image, with 1 channel remaining unused. What he has proposed is that we can have a black-white image which acts like a “emission mask” where white would mean full emission intensity and black would mean no emission.
You would basically add the emissive directly to your base color, the emissive mask would then act as a mask and determine which areas of the diffuse texture would be emissive. This might be a bit limiting but its something that is possible without causing a big increase in memory usage.
Correct me if I have explained this wrong @CoastalStarlight, I’m grabbing this out of the back of my head.
@tabby0x to be clear, this was just an idea we were discussing at RDC.
But yes you’ve got the main idea. Metalness and Roughness are both currently provided as a single channel each, meaning if we made a single emissive channel as described above, we could theoretically pack the three maps into a single texture object.
However this doesn’t necessarily mean that the emissive channel is “free”, since it could make the combined texture compress less effectively.
face tracking and ai features before emission maps and shader support
Yeah, what compression do you currently use to pack the PBR? Like DXT5 or DXT/BC? Or well, I would assume its a huge variety of compression methods because of the huge variety of graphics API’s you guys work with right?
@CoastalStarlight from what I have read, leaving a channel empty would literally make almost no difference in compression, ECT1, ECT2, ASCT and DXT5 would all have basically no memory difference if you leave a images channel empty or not. The only limitation is that ECT1 can not support a alpha channel. But then again, do you know why OpenGL ES 2.0 is simply just not being dropped?
@zeuxcg has made a report on GitHub about the graphics APIs that Roblox uses in %, last updated in 31st Dec 2021.
I’m grabbing all the public information that I can, since there obviously isn’t much more disclosed publicly by Roblox here, but I just really want to know why you are still supporting such a fraction of users when it literally makes so many rendering related tasks way more difficult for the rendering team.
ROBLOX hasn’t supported OpenGL ES 2.0 since March 1st, the minimum system requirements for Android require a device with support for OpenGL ES 3.0.