Changing those settings are a preference, If you are forced to change settings, there is no point in having settings in the first place. Let me quote on of my favorite Youtubers:
“Needing to change something in the settings, -which is a preference- should not be a necessity…”
I hope this sums up why it is stupid to have to change a setting to make a sand texture look half decent
True, This update may benefit Sky Sanctuary into being more plasticy and pastel, like the map theme!
honestly the sand texture looks a little bit bright for roblox, maybe make it darker? Looks great tho
…Your point? Billion dollar company. It’s not going to hurt them to spend a days wage on one person so they can import the old textures into the new system. No excuse; already said they’re going to add more materials in the future, so I’m completely lost as to where the whole argument about adding a few extra megabytes of texture files came from
This is practically drag and drop tier work, what would have to be done to fix this. it’s the very least they can do while we wait 1 - 2 years for a proper custom material system (that will likely have a massive impact on performance)
Please make the foil material be affected by Reflectance slider, it looks PERFECT for a hanging tile of cloth, bed cloth, and more if we could change the reflectance. Right now its only use is to put those shiny foil mats you see in construction, but if you gave most of these materials (mainly foil) some reflectance slider control, they’d become SO MUCH MORE useful for more than their intended purpose.
This is just needless negativity - absolutely no constructive criticism there, only destructive. You are not contributing to the thread.
You’re not forced to change anything, that’s why they are called preferences. You can prefer to have your diamondplate look like metal and incur the cost of specular reflections, or you can prefer it to look like smooth plastic and require less GPU computation.
But my point was that the post I was quoting was comparing old diamondplate with specular ON to new diamondplate with specular OFF. Obviously that’s not a fair comparison, because you need env. specular cranked up for anything to look realistically metal, that slider controls metallicity in the PBR pipeline.
You want to know what I think would be a wonderful compromise? Lower graphics has the old textures and higher graphics has the new textures, since the older ones were obviously lower quality.
I’m talking from a performance stand point, please spare the keystrokes.
That is not true, for several reasons. I’ll link my previous reply here:
The clients would have to store both versions of the texture on their client, which is a 1.8x increase in how much they need to store. The performance is the same anyway, that’s not how PBR works.
Also to your reply below to @Fire540Games, meshparts are much more expensive than default parts - be it rendering, network or replication, meshparts are always worse than default parts. You’re just asking for lag at that point.
For your second point, SurfaceAppearance can still be used on MeshParts that don’t have the texture by simpling importing your own mesh.
You can export a regular part as an .obj, then import it back in. You will still have the seamless part quality, and you’ll be able to use your own “PBRs”.
But they don’t tile. The texture will be stretched across the whole mech surface, unlike how materials work.
you didn’t raise your graphics, why? the new diamondplate looks absolutely beautiful with a skybox and high graphics, and i’d say looks 10x better than the old one
This is not a true statement. There is no difference between a MeshPart, and a Part.
One simply allows you to turn the part into a 3D object.
To the left is MeshPart, and to the right is a regular part.
There is no difference in triangles.
I have said this many times before and I will say it again, I really welcome this update but things need to change. I’ve come to terms with most materials but bricks and grass are still really bad compared to the rest. Brick looks flat and repetitive, whereas real brick varies in colour and damage. Grass also still lacks depth and you can see the very obvious tiling, which is a general issue for all materials. I really hope these will be addressed before release.
I messaged zeuxcg, who has been a Roblox engineer for this platform for over 8 years now I believe, specifically because of this. He confirmed it himself:
It’s a bit complicated to give a general answer here. We don’t remove redundant triangles, so in that sense it could be an interesting idea, however having many tiny meshes shouldn’t really be more efficient than having many blocks as long as each mesh still has 8+ triangles. So my best guess without measuring this is that it doesn’t make a lot of sense to do this, but realistically this would need to be measured. The thread has some benchmarks but they don’t seem to measure rendering time properly so I don’t know how accurate these are. I’m reasonably sure that the impact of MeshParts on non-rendering systems is noticeably larger vs Parts so even if you have a small win on rendering performance here, I’d be worried about other systems like collision and networking.
(I originally asked him about something slightly off-topic about whether rendering meshes with fewer faces than a default part could combat lag, but the point still stands.)
So yes, it is indeed a true statement - unless you are also a Roblox engineer who can debunk zeuxcg’s statements.
To add on, even if you use the Box CollisionFidelity for MeshParts, it would still be more expensive than just using a default part with CanCollide set to true:
Meshes with Box will be more performant than meshes with a different collision fidelity setting, yes. They will still not be more performant than blocks from the collision or replication perspective.
I don’t understand what the actual difference in rendering is. I don’t see any full certainy nor a test of a MeshPart being different performance wise. If they can’t provide further proof of this being the case, we can justify that MeshParts are Parts but with more capabilites.
Wire frame rendering doesn’t lie.
I don’t think this can apply here because Roblox downloads the parts to your client. Download time would be the exact same because it’s the same amount of triangles. I don’t see where this can be the issue. More triangles = more loading time. As you can see, there is no difference in triangles.
You don’t seem to understand how rendering properly works. It’s not just about rendering triangles, but properly handling replication data - since Roblox’s engine knows that Parts always are rectangular prisms with a set amount of triangles and faces, they can bake the parts into the engine to more performantly render all the triangles. With meshes, the engine simply does not know whether a mesh is a rectangular prism or not, but this isn’t even the most noticeable issue anyway. When replicating mesh data from server to client, you need to send much more data about the mesh (such as the convex hull data for physics) than if it were sending data of just a default part.
I’m sorry but you clearly do not know what you are talking about, so I won’t continue entertaining the topic - a Roblox engineer themselves said Parts are more performant, there is nothing to debate here.
That means nothing as there is no actual proof. If you look at their text, they simply don’t seem very strong about it. If you can ask them to provide something that can look identical to what you’re saying, then I’m wrong, but from what I’m seeing, those are tiny bits of data and Parts are basically meshes anyways. They both have triangles, and triangles make up the shape. In the end, it really depends on network connectivity, and how good the computer is.
I think what can be said here is that we don’t know if one is better than the other without accurate test results.
I won’t continue either.
