Custom Materials For Parts and Terrain And Higher-Resolution Textures



As a Roblox developer, it is currently impossible to create custom materials for parts and terrain.

Allowing developers to create their own materials would allow more detail and creativity in their work, and it would separate their game from the rest of Roblox.

Developers should be able to upload normal, specular, and diffuse maps in their games, of course, they would go under moderation to prevent inappropriate content from being uploaded.

As for decals & textures, the max resolution should be at 2048 x 2048, of course, the resolution would be downscaled with the player’s quality settings ( to avoid performance problems. )


I’d enjoy this immensely, though loading places would be strenuous on older devices and slower networks.


I don’t think creative freedom should be limited to some slower devices, otherwise things like the Unreal Engine 4 wouldn’t exist. :stuck_out_tongue:

Of course, developers would have complete control over the quality of the created materials and textures, so I think it should be entirely up to the developers if they want to support older devices.


YES! Custom specular, diffuse, etc would be very, very nice when attempting to add a depth effect on certain materials like sand and stuff. I also think materials should become their own category instead of tying them all in with decals. It would be nice to have a “Search by material” option in the toolbox when in Studio. :smiley:

Edit: I think this should go into Client features because it impacts the game client :stuck_out_tongue:


Not solely a matter of slower devices. Balancing the infrastructure needed to store and deal assets against UGC is important. Along with that, having to dish out X amount of data to each individual client compounded by every time they join a game isn’t very healthy for networks without local assets to pull off of.


Is it not healthy though? I mean, the actual place file is stored in the cloud, unions, meshes, current textures and decals, audio files, pretty much everything but materials and some UI elements are cloud-based. I don’t think having another type of texture, being HD or an actual material, would hurt the network anymore than what it is possibly under.


Compared to other objects, textures + spec maps are more data intensive than meshes, unions, and even the place file itself.

Assume that you’re texturing most of the objects in your game at 2048x2048px, providing a spec map of the same size for every texture, and your game’s around the size of Apoc 2. Every time you want to play that game, you’d have to download 200-500mb of textures on top of your other assets.

If I haven’t made it clear, this would be a client issue more than anything. Internet speed for a majority of Roblox’s users is no-doubt on the lower end of the spectrum, and with an entirely cloud-based game platform, there’d really be no reason add this.

(would like to see bump maps tho. would limit them at the 1040p resolution we have now)


Spec maps and texture maps are no different than simply uploading a “decal” and then putting them into a texture object. Of course, it would still appear as blue and green or whatever other color, but the actual file size of said texture would not change, simply because it would be put into a material object.

It’s also possible to have 2048 x 2048 textures under a megabyte in size by simply saving the file as a .jpg.

There’s also different types of .dds maps that are around 8-16 megabytes in size, if they’re optimized correctly. This wouldn’t be too much of a difference than an 16 megabyte audio file, which are allowed on Roblox.

Even if a texture file was 16mb in size, it’d still be the same strain on the game as a 16mb audio file. Rendering and such of said texture would be done on the client’s computer, and with new texture compression and mesh compression coming in a future update ( according to the roadmap ) having a large texture wouldn’t be a huge problem.

And HD textures are possible with .jpg and certain compression algorithms with PNG and DDS.