Simulating "Wetness" using EditableImages

[kalebgamevis (Kalebosarus)]

I’ve created a module which simulates the “wetness” of anything with a surfaceappearance and roughness map using EditableImages. You can see this working in the video below.

• Note that for now I have only made a select few assets compatible which is why certain objects and the terrain are not changing as well.

I’m very happy with how well this looks and would love to hear your thoughts on the results, but I do also have some concerns.

How it works:
The basic idea is very simple. With roblox’s EditbleImages I simply change the roughness texture of these assets.

My original approach was to load and modify EditableImages for each separate roughness map at runtime for truly dynamic runtime simulations, but this quickly exhausted the memory budget for EditableImages, especially since roblox seems to require you to load all textures of an object into an EditbleImage (i.e. the color, normal, and metallness maps had to be loaded as well) in order for me to modify one of them.

As I did not know how to fix this (please let me know if you do) I instead opted for creating a simple plugin which would create the different decals for each roughness texture step through the CreateAssetAsync() and CreateAssetVersionAsync() methods. A simple module then just switches out these already generated textures/surfaceappearances.
This is the version shown in the video.

My main concern:
While this does work very well and is easier then my original approach, I am mainly worried about the amount of assets that are created in this way. Currently I’m using 12 steps, that means 12 additional roughness textures are generated per object (with a differing roughness map AssetID).

I have tried to implement multiple deduplication techniques, so duplicates shouldn’t occur. I’ve also ensured that the newly generated decals are of low quality (256x256 for most and 512x512 for larger assets) as this is more than enough quality for a roughness map and at least minimizes the storage required for them on Roblox’s servers.
However, the issue remains that eventually I will possibly have a few hundred different objects with different roughness textures, meaning several thousand decals.

I have rarely uploaded many assets in a short time and was unable to find a clear limit stated anywhere. So I’m wondering whether this system is really scalable.

Any feedback or replies on the general results and the system itself, suggestions for different approaches, fixes/improvements for the current system, or answers to the questions I posed are all very welcome.

[Gucci_Dabs222 (Euphorian)]

@kalebgamevis

My original approach was to load and modify EditableImages for each separate roughness map at runtime for truly dynamic runtime simulations, but this quickly exhausted the memory budget for EditableImages, especially since roblox seems to require you to load all textures of an object into an EditbleImage (i.e. the color, normal, and metallness maps had to be loaded as well) in order for me to modify one of them.

why not simply load each surfaceappearance with editableimage content and then destroy the editableimage instances that aren’t needed anymore while only ever editing (during runtime) the editableimage instance of the roughness map?

@kalebgamevis

Currently I’m using 12 steps, that means 12 additional roughness textures are generated per object (with a differing roughness map AssetID).

and then why do this when you could use :WritePixelsBuffer() to a singular editableimage (which replicates across surfaceappearance instances) for the roughness. this way you avoid having your memory budget capped.

also confused on why you want an unique roughness map per asset?

[kalebgamevis (Kalebosarus)]

I briefly looked into destroying and creating editableimages each time I modify them, but concluded that it likely wouldn’t be performant enough. However, If immediately destroying the editableimages of the maps I don’t modify still let’s me modify the roughness map after then that is something that might help a lot, I’ll look into that.

As for the :WritePixelBuffer() method my original approach already used this and made sure that the single editableimage was replicated across surfaceappearance instances. My new approach however works outside runtime and creates the 12 steps using an editbleimage, saves them, then deletes that editableimage and moves on to avoid this buffer issue, but therefore has to actually create assets to save them.

I also didn’t mean that I use a unique roughness map for each instance of the same asset, but different assets need different roughness maps that correspond to their other texture maps to look correct, right? A rock and a fern cannot easily share the exact same roughness map and still look good.

[Gucci_Dabs222 (Euphorian)]

@kalebgamevis

However, If immediately destroying the editableimages of the maps I don’t modify still let’s me modify the roughness map after then that is something that might help a lot, I’ll look into that.

yep, you can. that’s what i currently do for my ocean which allows me to keep static roughness maps (only using buffers) while dynamically updating the normal map.

@kalebgamevis

My new approach however works outside runtime and creates the 12 steps using an editbleimage, saves them

just confused about this. what’s the point in doing all of this when you could use your original approach to dynamically change the editableimage content?

@kalebgamevis

I also didn’t mean that I use a unique roughness map for each instance of the same asset, but different assets need different roughness maps that correspond to their other texture maps to look correct, right? A rock and a fern cannot easily share the exact same roughness map and still look good.

i don’t see why not? if your roughness maps are solid color images then you could even turn down the resolution to a single pixel to absolutely eliminate the performance cost of dynamically updating the roughness map. however, if you mean you’re using already existing roughness maps (which aren’t solid colors) and then dynamically updating those based on the original map, then yeah that would make a lot more sense. otherwise, solid color roughness maps are often best for making an entire surface appear wet which should look more or less the same across multiple assets.

[kalebgamevis (Kalebosarus)]

@Gucci_Dabs222

yep, you can. that’s what i currently do

Oh wow okay, that’s definitely good to know. Weird that it requires you to load all of them at first though then. That should definitely help a lot.

@Gucci_Dabs222

just confused about this. what’s the point in doing all of this when you could use your original approach to dynamically change the editableimage content?

Just to avoid dealing with the editable image buffer which was the issue with my original approach, but I agree that it’s a far less elegant solution. Hopefully with the tips you gave me I can avoid this now.

@Gucci_Dabs222

if you mean you’re using already existing roughness maps (which aren’t solid colors) and then dynamically updating those based on the original map, then yeah that would make a lot more sense.

I am using existing roughness maps, but I can always edit them and reupload them if really necessary. It’s definitely good though that you point out that roughness maps really don’t need any detail a lot of the time and could even be reused for many assets. I don’t have much experience with texturing so this is something I just hadn’t really thought would look good, but I can see how it could.

Thanks for the help already, I’ll make sure to try and implement this stuff and see if I can make it work.

[Gucci_Dabs222 (Euphorian)]

if you need any help feel free to dm me and best of luck.
the idea of making textures appear wetter dynamically using editableimage while raining or such is a really ingenious solution and it looks awesome!

[RobotJnate (Charcoal)]

Good job on the realism! I LOVED seeing that. It made me feel so nostalgic, considering I have an old love for going outside and being in nature. I like the wetness things too, it looks soooo good!!
KEEP up the GOOD work :>