I’m trying to put together a train carriage that is sufficiently detailed but at the same time has few parts. Here is a suspension assembly for the carriage:
The black part and two red parts are separate CSG parts, with respective polycounts of 542 and 400 each. Those of you who are quick on the uptake will notice that the black part is far, far more complex than the red parts despite having only a 25% increase in polygons.
Why is that?
I’m pretty sure it’s because of Roblox’s cylinders.
Roblox cylinders use a 24-sided polygon as a base, something that is far more detailed than is necessary for the tiny parts they are used in (the four cylinders are D=0.2 H = 0.05 and D=0.3 H = 0.2). I’d like to continue using the CSG engine, while optimizing the models where I can, and the cylinders are one place that I would like to start.
Roblox cylinders also have the interesting quirk of not being regular. The sides get smaller as the angle approaches pi*(2n+1)/4 and get larger as the angle approaches pi*n/2. Having a configurable, CSGable N-gon solves a few problems at once:
gives creators the ability to use simpler cylinders should the need arise
gives creators the ability to use regular cylinders should the need arise (which is almost always)
ROBLOX cylinders have their place, even in CSG: the way the sides are created makes ROBLOX’s quirky cylinders an excellent transition between orthagonal surfaces. But that place is not as a tiny detail part.
These configurable N-gons should have:
be mesh object
the ability to select the number of faces between 3 and 24
the ability to be resized like regular cylinder parts and parts with CylinderMeshes in them
star pattern on the caps
polygon’s axis along the part’s Y-axis
smoothing using a 40-degree threshold
EDIT:
I just did some CSG tricks to make some 12-gons to replace the cylinders, and the polycount is now 208. That’s a huge amount.
You’re aiming for less polygons but doing CSGs which isn’t a logical thing to do as CSG creates far more triangles than you need which is what matters for you, am I right? In your case welding these mesh cylinders would be a better choice. Or you could also CSG like you normally would, put them into the Blender use the Demiate modifier on planar mode and get rid of many unnecessary triangles that way.
I only care about polycount. No, not really. The reason I was CSGing these parts was to decrease the part count, which plays a larger role in user experience than poly count. In this case, the reason I cared about polycount is because it was preventing me from combining multiple suspension assemblies together into a single CSG part.
Welding parts is more efficient than combining them. If you’re talking about data or polycount, then yes. But since this is a physics problem, you couldn’t be more wrong. CollisionFidelity allows builders to make CSG parts as efficient as a single regular Part.
Blender is a useful program. I’ve never seen a program with a more spiteful learning curve. I’d rather use the barebones kHED than blender.
This request was not created because CSG hyperinflates polycount. This request was created because no matter what your opinion is on CSG, small detail parts deserve a smaller allotment of polygons.
I don’t think that’s right. Efficient with respect to what?
They’re less efficient to render because you’re dealing with arbitrary mesh data, they’re slower to load over the network because, again, you’re dealing with arbitrary mesh data, and they take up more memory because you’re storing the mesh plus the original part data.
Don’t get me wrong; n-gon primitives would be really useful. I just disagree with some of the stuff in this reply.
I do not have a beefy PC, so it is exactly as I said: in my experience the number of moving parts have a greater impact on performance than the number of polygons, even when the parts are CanCollide false.
Not with respect to data or polycoun, which I explicitly stated. I talked about CollisionFidelity, but I was probably in error not describing what CollisionFidelity is. CollisionFidelity is a feature that changes how accurate the collision mesh of CSG and MeshParts. With CollisionFidelity you can have the collision mesh be a decent representation of the visible mesh (Default), the convex hull of the mesh (Hull), or the bounding box of the mesh (Box). By changing the CollisionFidelity to Box, builders can make the expense of calculating the physics of CSG parts as small as regular Parts.
You’re free to use any 3D program you like. Blender isn’t the only tool capable of exporting to fbx. I’ve even written my own shape generator using C++ and the fbx sdk by manually defining verts, tris and normals.
A personal note about blender, while the UX may be bad, that only really applies if you’re planning on rendering and modeling entire scenes. For the scope of creating game assets, you hardly touch any UI.
Obviously I support improvement in CSG but for the meantime, using a 3D program could solve your problem right away instead of waiting for these improvements to exist
Let’s cut the discussion about what OP should do in the meanwhile. He’s been presented with solutions, weighed them, and decided not to use meshes despite knowing the alternatives. There’s nothing to be gained by trying to push the matter further, nor should it be done on a feature request thread.
On a side note, @AbstractAlex, let me interject that a lot of CSG’s target audience has little to no programming experience and couldn’t plop out a shape generator like it was nothing, and OP has given no indication that he is a career programmer. Be careful not to confuse the others’ needs and capabilities with your own :)
Find an old pre-union gun in free models that’s made out of ~100 parts. Even if all the parts are CanCollide=false, you’ll probably freeze for a couple frames when you equip/unequip it. You’ll also experience significant trouble if you clip your gun with another player’s. The same gun made out of a single union may take up more video memory, but the freezing disappears. It seems collisions aren’t completely disabled when CanCollide = false, and the only way to truly prevent them is to reduce the number of parts. There’s also the issue of replication where network usage increases as it replicates the position/rotation updates of each part.
I think you may be underselling this feature, as you solved that problem in the OP with 6 parts. What would be some creative non-CSG uses for n-gons?
mate, i’m familiar with collisionfidelity. My position is that you should avoid CSG for things that don’t need CSG. Go ahead and benchmark it.
Have you run any tests to see if that’s true? (e.g. weld a bunch of parts together, unanchor them, set ownership to you, see if your outbound physics rate scales linearly with the number of welded parts)
I tested it in a test server, and it looks like ROBLOX does some optimizations so there’s not much networking done (I guess it only replicates the CFrame of the assembly root). There are other performance issues though, even with only 400 parts:
The main culprits is physics. Even without a character the physics resources needed are awful. All parts are CanCollide=false welded to a single root (also CanCollide=false) that’s moving around with a BodyPosition. I’m not sure if this is due to ROBLOX calculating collisions between the parts, ROBLOX simulating gravity on the welded parts, or what, but it’s noticeable. You can use the file I was testing with to see similar results.
Let’s put a wrap on this debate about the feasibility of collapsing everything into less parts. Decreasing the number of static parts in a level? Not so useful. Decreasing # parts by combining parts on different sides of the map? Not useful at all (detrimental even). Decreasing unanchored # parts in close proximity? Essential.
Whether it be tools, vehicles, apparel, etc, ROBLOX still involves CanCollide=false parts in physics calculations. When these are in close proximity to each other, performance gets really bad. Both SpaceK and I are explaining from personal experience that this is true, and with the benchmark I posted above you can clearly see that this is the case. The performance benefit of ditching one or two parts for more complex unions is debatable, but reducing the total part count to 1/2 or 1/4 yields significant performance benefits for dynamic objects in close proximity.
If you would like to question whether this feature would allow for such significant reduction in # total parts just by decreasing poly count, feel free, but aside from that it’s already been made clear that reducing part count through CSG can be tremendously important.
