Hi. Would you guys say the tiling on the walls of these bathrooms is too much? I am trying to create something detailed looking for a bathroom. The map isn’t going to be huge. Maybe a couple of buildings.
For a bathroom I was planning on adding tiles like the above. Would you say that is alright?
For a wall, that’s way too much,
yours seems to be about 13 parts for only one small surface, big youch even for low tier PC users if this wall is common.
A simple solution to this is to use a low kb grid texture, you can find it or make your own easily, you’ll only need a single part to use it
If you can’t make one, here is the id for the one shown
ID : 206738010
It’s people’s own preferences really, as for my opinion. I think fewer tiles would look more realistic then the large amount of tiles you have shown us in the screenshot.
Another thing I also really like – is the tiles to be symmetric to each other.
Larger tiles look better aesthetically and better for performance due to less parts.
Less tiles and make the lines a little thin.
Parts are super cheap. If your map is only going to consist of a few buildings, it will be fine. You can have tens of thousands of parts currently without too much trouble.
If you’re making this for a showcase or something, go all out with the bricks, but if you’re making this for an actual game, I suggest using textures like some other person had said.
Also if you’re only making a few of these like you said, there shouldn’t be too much of a problem. As long as you’re not at like 5k bricks per house, you should be good
@goldencowboy @madattak If you’re currently taking advantage of part instancing etc. Then you can have as many parts as you want without getting any FPS lag so long as they are anchored and not effecting physics. But still there’s a point where too much is too much and you’re no where near that limit. However when you can just use a texture I’d say this is a bit redundant at the very least build it as parts then union sections of it. After that add a texture that way you can just separate the union and watch it fall apart. 
Absolutely do not do this. Unions do not have instancing, so they will be less efficient to render and they use more memory. If you’re building something anchored, it’s almost always better to use parts over unions where possible.
Unions will allow you to use a smaller total of parts. I wasn’t saying to use a union for instancing. Plus if you were to separate it back into parts you would regain the instancing capabilities.
Smaller total of parts doesn’t mean less lag. This is a common misconception. Overall, you’ll typically raise your triangle count higher and, since they don’t use instancing, will likely cause more lag than just basic parts.
I was talking about the aesthetic view of OP’s bathroom wall and not if it induces lag or not
As I explained how part count doesnt really matter with instancing. It does matter when manipulating and moving the model. The only reason I would recommend to union is for that manipulation. The fact that if you separate the union it goes back to parts. Basically if you have tons of buildings like this I wouldn’t recommend doing unions. But for one large tower, this could be better manipulation wise. Not rendering wise.
A well built, efficient and detailed game can contain thousands of parts, I’ve been able to reach up to 40,000+ parts for a huge map without it having low frame rates or lag. Roblox’s engine automatically changes the player’s graphics setting (unless set to manual.)
This isn’t universally true. In a lot of cases, unioning a bunch of anchored parts into a single UnionOperation can be a huge performance and memory size win. This case of tiles is a perfect example: Block parts have so little actual geometry data that the memory overhead of the Instance itself is significant. Unioning 100+ basic blocks together that are not touching each other (as with these tiles) does not increase the render triangle count, and it significantly decreases the size of the tiled wall in memory. If the number of individual tiles >> number of tiled walls, gains from instancing can be moot and on low-end devices that don’t support instancing the Union version can be an overall win in all categories (performance, memory cost, physics sim cost).
Because walls are collidable, and because it’s not normally a consideration for characters or things to be able to stick into the cracks between tiles, you can set the Union version of the wall to have CollisionFidelity of Box, and now the physics system sees the whole wall as one simple box, rather than hundreds of individually-collidable parts.
TLDR; Test both ways, and look at the performance and memory usage in the developer console, and go with what performs best for the specifics of your build.
I can’t tell looking from the angle of the photo if the black part are sticking out or not but try to make it more look like a tile for an example
Make the tiles separate parts but keep the black part as one big piece.
This reduces the amount of parts and also looks for realistic.
There was a time (CSGv1) when you were pretty much guaranteed that unioning things would increase the triangle count, and when Unions were not instanced. Those days are gone. With CSG2 and sensible use of it, unioning parts that are not overapping will keep counts the same, and when there is overlap, you can actually get a significant reduction in triangle count because CSGv2 culls interior geometry! For example, take a bunch of Ball parts and make a caterpillar by overlapping them, and union it. Depending on how much you overlap the spheres, your Union can have as little as 1/3 to 1/2 of the number of triangles as if you left them as Ball parts. Use View->Render (Shift-Ctrl-F2) to see how many tris your scene has before and after.
There is another misconception which is that Anchored parts have zero physics cost. Alas, this is not true. They have greatly-reduced physics cost, but If you have something made from 200 anchored parts, it still has 200 collision parts in the spatial hash (octree) against which moving parts and raycasts will be collision tested. This is true even when cancollide is set false, because of raycasts and Touched events. As you can imagine, making a single Union with collision set to Hull or Box can be a big optimization.
I already addressed the issue of Instance overhead, it can be significant. 100k of the same part has a very different memory cost than 10k of the same Union or MeshPart. Instance overhead can easily dominate.
You’ll get the most insight into the tradeoffs just by watching zeuxcg’s presentation on this topic from last year’s RDC, here: Roblox Developer Conference 2018 - Designing for Performance - YouTube
The TLDR is what you see in that screenshot: the general rule of thumb w.r.t. efficiency and getting the best performance is:
Optimized MeshParts > Well-made Unions > Lots of Parts
For a given object, lots of anchored or welded-together basic Blocks is often the worst-case for performance.
