Think, Roblox, think! You have to listen to the community before you come to a decision that might hurt many people’s development!
Joking aside, I like the new materials, but if you guys don’t include a toggle it’s going to hurt a lot of developers. Having a toggle such as something like “LegacyMaterials.enabled = true/false” would honestly be a good move.
In case you guys didn’t see, they mentioned that they would do their best to keep the old textures in. So don’t panic about it anymore. New Terrain and Parts Built-In Materials - Release Build - #1204
i already posted that the normal map can be fixed pretty easily.
I like the new terrain a lot but it ruins my game completely it would be nice if you gave us the option of custom grass/custom terrain through PBR textures and images.
You could add the new textures like how you added in the new fonts a few months ago, just add them in addition to the old textures. Or if that idea causes longer load times for people with not as good of connections you could give it an option in the game settings window in studio and if the box is checked to use old textures it loads Just the old textures and if the box is not checked it loads the new textures. These are just some ideas.
Thank you very much for listening to our feedback. This way, I can use old textures on some of my games which depend on them and use the new ones on the games that don’t.
Thank you so much.
It might be a good idea to have the new materials as an Enum on a material-by-material basis. I think the new Birck material fits my game really well, but the other textures make it look horrible.
My possible solution is to have the new Materials called “BrickV2”, “SandV2” etc. so we can control this
It’s cartoons, there is literally zero depth and curves in the new textures compared to the old which actually had some kind of depth in them.
Heyo, roblox actually listened!
Thank you so much for postponing this update in order to add options to switch to it or not.
There are many ways that the new textures could be added while also still satisfying the users that want to use the former textures.
One way that I thought of is by a plugin being made, or perhaps a downloadable add-on for Roblox Studio. This plugin, or add-on would create a second “Texture” tool next to the already existing “Texture” tool, preferably having the second “Texture” tool use a different name than the other “Texture” tool. This second “Texture” tool would allow users to use the former textures.
The former texture files could simply just remain in the Roblox Studio program files and the Roblox database, allowing users that have the plugin/add-on downloaded to use the former textures.
The Second “Textures” tool would not be seen in Roblox Studio unless the user has the plugin.
This also allows for if someone with an account from the time before the new textures were added was to lose their account, (maybe they forgot the password and can’t reset it), and they have to make a new one, then they can still use the former textures even though their account creation date is after the time frame that the previous textures were used. They would just simply have to download the add-on/plugin.
Note:
If the staff at Roblox do not wish for the previous texture files to remain in the Roblox Studio program files, then the texture files could be embedded into the add-on/plugin download, or embedded into the actual add-on/plugin itself.
I remember all of that - I also remember more recently having to adjust all the neon in my game when its appearance drastically changed. Yes, we got past those changes and yes we would have managed to get past the new materials if they were forced upon us - that doesn’t mean it is a good thing when these sort of changes happen, and in my opinion these sort of forced changes should be avoided whenever possible.
In the case of the neon change I can accept it and I didn’t make too much of a fuss over it, even though it was a lot of work to change and some of the original appearances of objects in our game are not obtainable anymore. I accepted it because I felt as though the “moving the platform forward” argument was valid for that specific instance - the old lighting engine was very limited and it was a worthwhile sacrifice for what can be done with the new lighting.
That is where I think this update differs and I can’t agree with your take - I don’t buy that it is the same sort of upgrade. It’s true that the new materials are higher resolution, cleaner, play better with the new lighting, etc. - that all makes them a good option to replace the old textures as the new default, which I have no problem with. What I do have a problem with is that you are framing it as being an update for the good of the engine, when in reality all it is is a different material set that is more up to date with modern graphical standards.
I simply do not see a good argument in your post as to why it makes sense to have the old materials be unusable after the new materials are released. The only points you have given are that Roblox has done this sort of thing in that past, it will delay the release of the new materials, and the possible issue of affecting performance / download times. I don’t see any of these arguments as legitimate and I will explain why.
First of all, to the point that Roblox has done this is in the past - I’ve already stated above that I think these sort of changes can be ok when done out of necessity of pushing the engine forward. I do however disagree that this update falls into that category. Also on that point, I think Roblox has changed a lot over the last 10+ years and it was arguably more permissible to make those sort of changes when the engine was younger and less people were making a living from it. I think changes like these that affect the overall appearance of a game should definitely be avoided whenever possible.
In regards to delaying the release of the new materials, that’s a valid point and I can see why you would be against that happening. In my opinion, however, these issues simply should have already been addressed at this point and it was a bit silly that keeping the old materials was still up in the air until this post was made and we were given the 1 month timeframe.
Perhaps the biggest argument is the performance / download time impact that keeping both materials would have - but personally I don’t buy it. I see no reason why the old materials couldn’t just be downloaded, like any other texture my game uses, when a player decides to play my game. I don’t target lower end devices, my game is not even playable on phones or tablets, and believe it or not I don’t mind trading the few players who are on the edge of system / internet specs for keeping the appearance of my game the way it was intended.
Again, no problem with these materials being the new default, but I’ve still yet to see a valid argument as to why the old materials would have to go.
I know your post was mostly just to put your thoughts out there, and that you said there is no need to respond, but as you are one of the largest Roblox developers and your post has gotten quite a bit of traction, I wanted to respond anyways and I do hope this response makes it to you.
In Workspace, there should be a property called something like MaterialType. That property would have 2 enums, Enum.MaterialType.Legacy and Enum.MaterialType.Future (Can’t think of a better name). By default for new games, it would be Future, but for old games, it would be Legacy, but developers could change it. This would be kind of like Lighting.Technologly.
This would be the most logical solution I can think of.
The grass needs to be more detailed.
This is definitely what roblox should be doing, instead of forcing this and causing huge, game breaking issues. I mean, just think about games with big maps, like Jailbreak or Adopt me.
Hey, I’m just grabbing the old texture files while I can. I recommend you do, too.
The orange normal maps that Roblox uses encode the blue channel implicitly to save on space. They do have enough information to convert to standard blue normal maps, they just require a special tool to do it.
This next bit isn’t as useful unless you’re writing an algorithm to interpret or convert them, but I’ll drop the information for those who are curious.
The blue channel is derived from the alpha and green channels by using the assumption that the normals stored inside are unit length. With just the alpha and green channels the vector stored inside is smaller than a unit vector. Using this knowledge you can compute the axis that would be stored in the blue channel with z = sqrt(1 - x^2 - y^2) where x = 2 * a - 1 and y = 2 * g - 1. This is all assuming you’re using a z = 1 normal axis.
Hi, I’ve got some feedback about the materials
The grass texture looks too repetitive, kinda breaks the illusion of randomization
The concrete is too soft and there isn’t enough depth. it looks too much like a lame plaster texture. please fix!
Yeah my major concern is the concrete (my favorite old material). as you can see it looks too smooth and ruins the rough and gritty look of the stairs
Haha I said that in a post then deleted it, but yeah that should be something they should work on!
Yup. The easiest way to convert it for most is probably just to use Blender’s separate / combine RGB and math nodes, it worked for me.
Also, something odd about Blender and this map: the thumbnail for the dds file shows as the blue normal map file, but when I add it to the project I have to do all the conversions still. ![image|690x394]
How is it that you’re doing that?
