CSG-able N-gons

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:
blob.jpg

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:

  1. gives creators the ability to use simpler cylinders should the need arise
  2. 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.

11 Likes

Import them from Blender if very accurate physics is not much of a concern?

Or

Or

(This a copy from Adjustable count of Cylinder and Sphere's segments - #12 by Oseday)

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.

Welding is very efficient by the way.

I think this request will make more sense when CSG gets better at managing triangle count.

You are making several assumptions in your post:

  1. 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.

  2. 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.

  3. 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.

Can you expand on that?

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.

1 Like

Just use Blender. CSG is obsolete.

1 Like

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.

1 Like

Thank you for your interest in my feature request. CSG will always continue to be relevant until Blender’s UX team gets it together.

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 :slight_smile:

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.

1 Like

That’s because CanCollide defines whether or not an object has collisions, not if it can be collided with.

And yeah I agree with my programming example, that was just because I knew the OP was a very capable programmer :stuck_out_tongue:

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.

1 Like

I actually didn’t, because that isn’t a low-poly substitute for cylinders:
blob.jpg

(the 236 figure is when CSGd together)

I’m going to assume you mean physics efficiency, because we’ve already said the same thing about data and polycount.

Do you have an estimate on how many parts contribute the same amount of physics lag as a CSG part set to Box fidelity?

1 Like

Oh, that’s pretty horrific.

Parts and box unions are pretty much identical as far as physics goes, but again, physics isn’t the sole arbiter of overall performance.

1 Like

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.

2 Likes