why cylinder collider doesn't exist ?!

hi folks,
Instead of using a mesh collider for cylindrical object like Barrels ... why there's no cylindre collider optimized by unity jst like the box spherical one :s

 

Mathematically (with respect to collision detection at least), cylinders are much harder to work with than triangles, rectangles, spheres, capsules, or boxes. Algorithms involving cylinders are generally less optimal (considerably, in some cases) than similar algorithms involving other simple primitives, so it makes sense that cylinders would not be supported as a basic primitive.

I don't know how PhysX handles intersection testing, but in general there are a few different options. Shapes such as spheres and capsules can generally be dealt with pretty easily. They can be viewed as the Minkowski sum of a sphere and a simple primitive that serves as the medial structure for the shape; for a sphere the medial structure is a point, and for a capsule it's a segment. Many of the queries that commonly need to be performed can then be reduced to simple queries against those medial structures, which is generally fairly efficient.

Another commonly used algorithm is the SAT (separating axis test, or theorem is you prefer). The SAT is a fairly optimal solution for boxes in particular.

Cylinders don't work very well (or at all, depending) with either of these methods. There are general solutions that treat all convex objects uniformly, such as the GJK algorithm, and (AFAIK, at least) some physics engines do use such algorithms. But, these algorithms are in general more complex, less stable, and harder to implement than the alternatives (IMX at least), and in the case of curved objects such as a cylinder may reduce to an iterative solution for the narrow phase, which I imagine you'd want to avoid if possible in a real-time physics simulation.

So, long story short, cylinders just aren't generally an optimal choice for real-time intersection testing, so usually it's better to instead use a reasonable approximation such as a capsule or regular polygonal prism.

[Edit: Just to cover my bases, I don't actually know why cylinders aren't included as a basic primitive in Unity; I'm just speculating. But, I think it's probably a reasonable bet that the fact that cylinders are somewhat harder to work with than other primitives might have something to do with it.]

 

Well, unfortunately I'm not *always* well informed - only sometimes

I may have overstated that aspect of things. From my own efforts with GJK (which were a while ago) I seem to remember some thresholds and tolerances being involved, perhaps more so than with simple tests such as, say, sphere vs. capsule. But, as I said, it's been a while, and I may be misremembering.

 

Interesting.. im facing the same problem. Im searching a better way to simulate a tire than using the raycast method, cause with raycast thers only one contact point. in unity 3 finally has been added the sphere cast, thats a good step forward, but its not perfect (doesnt finds all contacts with the ground). The ideal solution seems to be using a convex cast like in this very well done newton example

http://newtondynamics.com/forum/viewtopic.php?f=14&t=5999

there is also a donwloadable demo where you can see the difference between
raycast (cast 3 rays horizontally) (picture 1)
spherecast (circular raycast - casts 3 rays horizontally and 8 circular around the tire) (picture 2)
convex cast (casts cylinder the size of the tire towards under the car, finds all contacts with the ground) (picture 3)

Unfortunately unity doesnt support convex cast, so im evaluating using a cylinder with a mesh collider, but after reading this im not sure anymore that its a good solution..

A bullet developer adviced about using a cylinder collision shape:
http://www.bulletphysics.org/Bullet/phpBB3/viewtopic.php?p=&f=&t=1817

So for you wich is the best solution to this problem using unity? casting several rays around the tire like in the newton example can be a good solution or is eavy to process?

 

thx guys for these informations

 

but i still think that cylinder collider is a standar geometry that should be added to the standard colliders ...

Cylinder is base on the radius system that the sphere has and the linear projection on the Y -axies of that cylinder that already has the Box too ...

So i think that it really should be added in unities colliders .

 

Well, did you read the earlier posts? There was considerable detail provided as to why it's fairly common to prefer other shapes over cylinders for collision detection.

The best way to understand what's really involved would probably be to write some collision detection code yourself; without that experience, it can be difficult to make reasonable determinations about what 'should' be supported in a collision detection or physics engine.

The fact that both a cylinder and a sphere have a radius is insignificant (for the most part). The important characteristic of spheres and capsules is not that they have a radius, but that their surface is formed from all points that are exactly radius units from the medial structure. It is this characteristic that makes intersection tests involving spheres and capsules fairly straightforward, and it is this characteristic that a cylinder lacks.

Here's one way you might be able to convince yourself. Implement a boolean sphere-box test (by 'boolean' I mean that the test only determines whether an intersection occurred - no other intersection information is computed). Then, implement a boolean cylinder-box test. That should give you some insight into why other shapes might be preferred over cylinders.

Again, I don't know for sure why cylinders aren't supported in Unity; maybe other physics engines support them (I'm not sure off the top of my head), and maybe Unity will support them in the future.

But, it's important to understand that just because something makes sense from an intuitive point or view or because it would be convenient for the user doesn't mean that it would be easy to implement or practical to support. In our intuitive day-to-day world, a cylinder is indeed a basic shape and we might not think of it as being qualitatively different from a sphere or box. Mathematically though, a cylinder is very different from either of those shapes, and as far as collision detection in a computer simulation goes, it's the mathematics that matters, not the intuition.

Does that help clear things up at all?

 

ok and what about convex cast like in the example i put in my post? quote from bullet forum:

 

that "new shape that approximates it better" is commonly capsule though as it has the benefits of the sphere without the problem that the single point of contact normally creates


as for faking a cylinder collider: a combined collider basing on subs using capsule + 2 wheel colliders for top / bottom rings might work out too, never tried that

 

Unity uses PhysX, so if there's no cylinder collider in PhysX (which there isn't), then there's no cylinder collider in Unity. In many cases you can use a capsule collider + box collider (works great for barrels as long as they're not too short).

--Eric

 

hi dreamora,
thank you for your reply.
i dont think that the shape they were talking in the bullet forum is a capsule, cause the height of a capsule cant be less than the diameter (in that case the capsule becomes a sphere)

 

hi Eric5h5,
do you know if the convex cast are supported by physx? if you have a look at the example i put in my previous post, you can see that its the best way if you want to find all contact points of a wheel.
if not, which is for you the best way to find all contact points of a wheel? i tried raycast (only one contact point) and sphere cast (better but doesnt find all contact points, probably cause it casts several circular rays around the tire, but not enough in order to find all contact points)

 

that indeed is true.
But that does not mean you can't use it, it depends on the explicit requirements. and in case of a barrel which has totally different requirements to a wheel there is even less speaking against it

but in unity you wouldn't use primitive colliders anyway as PhysX has a special collider for wheel type usage, which in Unity is exposed as Wheel Collider.

and yes convex colliders can be used for moving objects. use mesh collider and mark them as convex
They would not "cast" in the sense of expanding outwards over time but they would collide fine like primitive colliders.

 

Hi dreamora,
yes i tried to use convex collider as trigger but it doesnt seem to work.
Here what i tried:
I have a terrain with mesh colliders. I create a cylinder gameobject and i add a mesh collider to it.
I check istrigger and convex options, and i add a kinematic rigidbody.

with this configuration no trigger event are fired, instead the same situation with a "basic" collider (cube, sphere, capsule) it works.

So Its not possible to use a mesh collider as a trigger?

 

actually , i think that two mesh colliders don't collide between them ::s
that's why creating a terrain using unity3d terrain tool is better ...

 

mesh colliders can collide with each other (or technically move, because those who don't do never move internally -> not register collisions. they teleport), but the moving ones must be convex (and marked as such).

stationary ones don't need that.

 

my tests say another thing: two mesh collider dont fire trigger event. a basic collider (sphere, cube etc) and a mesh collider do fire trigger event.

 

did you ever solve this Newlife ?

 

@Jesse Anders Umm, wouldn't a collision check for a cylinder collider be just a combination of the math used for capsules and boxes? If anything it should be simpler than boxes.

I mean, you'd perform a capsule collision check at first, but then perform different handling for the caps.

If we just consider checking if a single point is within the volume of a capsule, it'd just be a matter of finding the closest point on a line segment to the point in question. This can be done by imagining the line segment is, rather, an infinite line, but then clamping the point within the start and end of the line segment. Then, with the closest point acquired, perform a distance check.

In the case of a cylinder, if the point needs to be clamped then the point is not within the volume of the cylinder. The distance check can be omitted altogether.

 

Cylinder collision testing is actually not that complicated. I've written it my self. Though it is true, there's more work than needed than a sphere/capsule/box would all use.

But as Eric5h5 points out... Unity uses PhysX. PhysX doesn't have a cylinder collider. Thusly Unity doesn't.

Nvidia probably has their reasons that they don't include a cylinder collider. Maybe they don't want to include the more complicated test in their design, as it might have ramifications against the whole collision testing test. Maybe Nvidia doesn't want to allow a door for someone to use an under optimized solution to a problem that could be done more efficiently another way. Whatever it is... Unity isn't the one in control of it.

 

More or less like Zergling I wonder why an implementation could not (efficiently) model a cylinder as the intersection of a capsule and two planes for intersection purposes.

Bullet provides a cylinder primitive.

It is because something makes sense from an intuitive point of view that an API must support it (or fake it) As you pointed out cylindrical objects appear a lot in everyday life so having a cylinder primitive is convenient, and a capsule is not always a good substitute.
Whether the primitive is implemented using ad-hoc maths, a combination of other primitives or a mesh is of no import to the user as long as 90% of use cases are covered.

Yes, I understand that the reason physics engines support any primitives at all is that they are supposed to be faster than mesh colliders. But a good physics library will attract non specialist users, and these users will ask for things that may seem counter-intuitive (or even counter-productive) from an implementer's point of view.

 

This kind of make now sense to me. I mean, Lets look at the NavMesh Agent. There is what seem to me a cylinder collider. So why are we not able to access that collider anywhere else in unity?

There are many cases where a box, sphere, or capsule collider are not ideal. Mesh Collider set to Convex does fill in the gap but that is just fudging the colliger out of a mesh. which remains as detailed as the original mesh.

Sure I can make a more simple collider mesh for that object that will save on calculations, But for some thing as simple as a Barrel that has flat bottoms and round sides, a capsule collider has way more detail then is needed at the ends. I can't see why a flat ended cylinder is more complex then the capsule.

I could be wrong but something is not making sense here.

I still looking for a better way to do barrels for my own project but I guess I'll just use a Mesh Collider set Convex with way more faces then the graphical mesh has for them. It gets the job done as long as I don't place too many in my scene and don't mind when the faceted nature of the collider makes for some wonky looking rolling.

 

A navmesh agent doesn't use physics; there is no cylinder collider. Please read the second post in this thread again for a good explanation. A capsule collider has no "detail" as such, it's just a mathematical construct, and not like a mesh at all. As for "detail in a mesh", keep in mind that mesh colliders use bounding boxes. As long as they aren't directly interacting all the time, having lots won't have an appreciable effect on performance.

--Eric

 

Inspired by this thread, I just had a look at some old code of mine from 2009. It was the time I started to use physics libraries instead of my own stuff which could of course use cylinders. I used Newton at the time being. Found a NewtonCreateCylinder() function there.
Just my 2 cents ;-).

 

I thought I will post it.
http://www.codercorner.com/blog/?p=1303

Still cylinder would be such a sweet addition.

 

Loving this thread! Until next time I'll keep rolling my 12 sided convex barrels. Because barrels ain't capsules. Never.

 

Thanks a lot for posting that. Interesting insights!
On the cylinder problem the most important sentence for me was:
There is no performance problem using a highly tessellated convex mesh for cylinders, because generally speaking there is no performance problem using highly tessellated convex meshes in PhysX.

Thats good news. So the best way (if a capsule doesn't fit) is to use a cylinder mesh. If you ask me, it would be nice to have that right into Unity. So if you create a cylinder, it uses a pre-made mesh and adds a convex mesh collider.

 

The best way I can think of is to have the cylinder as a nearly round extruded polygon with as many thin sides as reasonably possible and smooth shading. Another would be a capsule collider with a script saying on collision check if the collision happened beyond 1/2 the height of the cylinder then ignore it.

 

isn't a capsule simply a cylinder with a half sphere on top and bottom, shurly if they can make a capsule collider, a cylinder collider would already be in there

 

That was already explained. Read the second post.

--Eric

 

Suppose Unity added it. Because of how math works, it would be slower than the rest. People would notice, ask, and be warned not to use the cylinder collider if you care about speed. They'd complain about why the dropdown has things you shouldn't use. Later on confused people would write things like "I heard you should never use the cylinder collider". People who know their stuff would be confused -- was there some new math discovery about cylinders? In the end, people would do the same thing they do now: capsule+2 boxes, or their own cylinder mesh, and Unity would be just a little harder to learn.

 

i did. but i still don't understand why a capsule collider is ok but a cylinder (which is a capsule without the spherical ends) is not

 

I'd recommend reading a tutorial on implementing collision detection, or better yet try making a simple version yourself.* The thing with a sphere or capsule is that you just need to know the distance from the point/segment - that's not true with a cylinder. Boxes are done a whole separate way.

As far as a practical solution - use a mesh collider with an appropriate resolution. It's plenty efficient unless you're building everything out of cylinders, in which case ... don't do that.

Or rather, do that if you want to, just be aware that a cylinder is not as inherently efficient a collision shape as a capsule or box, and so 100k cylinders is going to be a bigger performance impact than 100k boxes.

* Not a waste of time IMO, even if you aren't going to be writing it yourself in practice. It's an interesting subject and knowing how to implement SAT collision helped get me a job.

 

If you're hell bent on making an accurate collidable cylinder, I'm sure the mesh collider will be more than happy to oblige.

 

sure, that's what i'm doing already. i guess its no more or less efficient than a built in cylinder collider anyhow

 

Problem with mesh colliders starts when you want to have continuous collision detection.

 

The math for detecting penetration with a capsule is trivial - it is the same as testing the distance between a point and a line. Off the top of my head, I'm not sure that there's equivalent trivial math for a cylinder.

 

Here comes a big ol' wall of lordofduct rant:

Because in physics calculation terms... a capsule is NOT just a cylinder with spherical ends. Sure you can look at it like that visually, but mathematically underneath that is not how we treat them.

Note when collision testing we need to determine a few things. Notably... if they intersect, by how much they intersect, the point of intersection, and the normal of that intersection. This way we can move the colliders apart so they no longer intersect. (note most engines want more information than this... but this is the minimum amount of information needed)

A capsule is actually treated as a series of spheres over some distance. This means the tests for intersection is pretty trivial. It's just a sphere test multiplied by its height (under the hood the height of a capsule is measured from the center of the 2 cap spheres... so the visible height - the cap diameter). And a sphere test is the most trivial of trivial tests. It's a distance test! Hell you can do a square distance test meaning it's basic addition/multiplication.

Furthermore, getting the point/normal/depth of intersection is all also trivial since the depth is just the distance - the 2 radii, the normal is the vector between the 2 spheres, and the point is on that vector at the average of the 2 radii. Again all trivial addition/multiplication.

So the only information we need for a sphere/capsule tests are position and radius. That's it.

Next complexity comes in the other 2 primitives. Plane and Box. Plane sphere collision is fairly trivial as well. It's again just a distance test minus the radius. And Box's are really just 6 planes with straight edges, so similar to capsule, it's just the same trivial test done multiple times. (of course there are optimizations, so it's not 6 literal tests... for example a box is just a plane extruded along its normal, or a plane is just a box with one dimension set to 0)

All that's left is plane-plane and plane-box intersection. This one is a bit more complicated than sphere collision. But in math terms it's mostly trivial. There's various ways to do it, such as a simple matrix multiplication, or performing it vertex by vertex and exploiting the fact that the vertices are uniform on a box unlike more complex geometry. (note, tri-tri collision is similar since it's 3 vertex of uniform layout)

...

Now outside of these basic primitive geometries. Things get complex really fast.

Take the cylinder.

If we don't treat it as a sphere (since it doesn't have rounded ends like a capsule)... how do we test that curved surface? How do we test those straight edge on the end? All of this geometry is far more complicated than simple distance tests can handle.

Now you may have heard of SAT (separating axis theorem), which is a common algorithm used for testing the intersection of complex geometry of convex shapes (so no overhangs... no crescent moons). And the SAT for cylinder is actually kind of trivial. It only really has one axis combined with a radius. So we're only taking the dot product (addition/multiplication) over every axis of the opposing geometry.

But there's 2 issues.

Inherently SAT requires more information than sphere-sphere, or plane-plane. We need to know how many axes the geometry has, and then test overlap of each axes. And once that is done we really only have tested IF they intersect... we haven't figured out by how much, or the contact points, or any of that other necessary information.

Basically... we're already doing more work just to test if they intersect, then more work to gather all the needed data.

It's not complicated, but it's more complicated in relative terms.

As well as adds more branching to the entire process.

...

What do I mean by adding more branches? Well branches I mean an if clause where we branch our logic based on some condition. Branching is actually a semi-costly thing when processing large amounts of data. There's many reasons as to why and this post is already long enough as is... just know, yes, when dealing with large amount of similar calculations (like would be done in physics or graphics processing) branching is costly and you want to reduce the number of them as much as possible.

It also increases the complexity of your code because welp... you have to write more algorithms for each branch.

So basically most collision engines work this way. You have 3 major physics types:
Spherical
Planar
Mesh (noting this generally uses SAT anyways)

And we need algorithms for each one:
Sphere - sphere
Sphere - planar
Sphere - mesh
Planar - planar
Planar - mesh
Mesh - mesh

Well lets add one more type in there:
Spherical
Planar
Mesh
Cylinder

And now we have:
Sphere - sphere
Sphere - planar
Sphere - mesh
Sphere - cylinder
Planar - planar
Planar - mesh
Planar - cylinder
Mesh - mesh
Mesh - cylinder
Cylinder - cylinder

We went from 6 branches to 10 branches. Or one more order of the termial function (sum 1->N), which means it grows like a triangle. Every added entry expands the base of an equilateral triangle sized number of operations by 1. (or in combinatrics, which this is, binomial coefficient of N take 2)

Also, as you add these algorithms. What is the cost of each? Each algorithm costs their own unique amount. What if it turns out that cylinder-box is super expensive, but cylinder-sphere is super simple. Sure most of these up here are technically trivial... but what if you add other geometry to the bunch... which gets to my next point (and was my point back 5 years ago just worded differently).

Why cylinder?

Why not some other geometry?

Note our 3 primitives we chose have multi-functions. Spheres can be both spheres and capsules. Planar can be both planes and boxes. Mesh can be pretty much ANY shape we want (as long as that shape can be described as a series of tris, and the complexity of the math raises linearly with the number of tris).

So why cylinder?

Why not cone?

Why not frustum/pyramid? Hell, technically you could call a cylinder a frustum with a large number of sides (so not perfectly round cylinder).

Why not cylindrical plane? (the cylinder you think of is actually a right-angle round cylinder, geometrically cylinder actually refers to any curve in space extruded along an axis... a sheet of paper is technically a cylinder, note how you can loop a sheet of paper on itself to make a right-angle cylinder)

...

Sphere and Planar calculations are big DUH's because they're easy.

Mesh covers everything else.

No reason to add any other geometry unless you want to halve (or worse) your physics simulation's speed.

 

ok, i think i've taken beating a dead horse to new levels,
this is a project that creates 3000 cylinders and drops them onto a sloping plane
https://www.dropbox.com/l/scl/AACiPsr6Jx_HLI5WJ5XauSWGPiUEbK5XID4
when i test with a capsule and box collider to approximate a cylinder, i get about 80fps,
when i test with a mesh collider i get, wait for it.................., about 80fps

this could be a useful tool for profiling colliders i think
if anyone has problems downloading or running it, please let me know

thx

 

Your link doesn't have permissions for anyone but you.

...

If you mesh collider is configured as a convex collider (which it has to be since unity doesn't support non-kinematic rigidbodies for non-convex mesh colliders since unity 5), then a simpler bounding geometry is calcualted for it.

And yes, it'll get perfectly acceptable speeds.

Because convex geometric collision testing is efficient, it's why it's one of the available collision types I went over. Cylinder has nothing to do with it, it's not doing a cylinder test. It's doing a convex collision test on geometry calculated for your mesh that happens to be in the shape of a cylinder.

 

This doesn't tell us anything practical. The "about 80fps" could be a bottleneck caused by something completely unrelated.

To start getting something useful, use the profiler in a build to measure how long physics calculations take in each scenario. If you want to make a decision for an actual project, then make sure your build is running on your minimum target hardware.

 

sorry about the link, please try this
https://drive.google.com/file/d/1KL3uHAk8yTqIfwuOjakNo-1rnA20IU1y/view?usp=sharing

i guess the fps isn't the only measure but since its a super simple scene and i know my pc isn't doing anything else, i think its a good approximation

 

Well, "I think" and "Actually Is" are 2 different things.

I downloaded and ran your tests, with the profiler (just go to Window->Analysis->Profiler to open it, it's not hard).

On my machine (times are average):
CylinderMesh - 6ms to process physics
CylinderCapsuleBox (with box collider turned off) - 4ms to process Physics
CylinderCapsuleBox (with box collider turned on) - 12ms to process Physics
CyldinerCapsuleBox (with capsule turned off) - 5ms to process Physics

Yes, CylinderMesh was efficient because of its convex mesh collider. BUT is slightly slower than Capsule, but close enough it's barely noticeable (you noticed very little frame rate difference... I noticed more personally, a 90:100 fps difference on my machine).

Note though that for me with the box collider turned on with the CylinderCapsuleBox, my performance nose dived. Like noticeably. My frame rate dropped to like 45fps. Which makes sense, it means twice as many colliders in scene all touching one another. Of course it's going to perform worse.

And yes, I also tried just the box collider, and it got slightly better than the convex mesh, but slightly worse than the capsule. Which completely goes in line with what would have been anticipated based on my earlier post.

...

Also note, fps isn't always a good comparison for many reasons. Profile to get actual times. Case in point I saw actual differences in fps when you didn't. YET, I run on a Ryzen 9 3900X 12-core processor with 64 gigs of RAM and a Geforce 2060 RTX Super. (I also run on a ultrawide monitor at 3840x1600).

My conditions allowed me to see differences you didn't necessarily see as FPS goes. But the profiler being more granular allowed me to see what the impacts were specifically dealing with physics. Note, my frame rate halving for box/capsule together was only partially impacted by physics... note how 1000/4 is 250, and 1000/12 is 83. Yet capsule didn't run at 250fps, but more like 100fps. And 83 isn't half of 250, it's a third, yet I halved my framerate going to capsule/box.

Basically... framerate is impacted, but it's not a consistent marker for what's actually going on.

 

thanks for pointing out the profiler tool, very interesting that the mesh collider is more efficient that capsule and box

 

The FPS is a result of how long the entire Unity engine takes to update. Physics are only a small part of that. Because of this, large changes in physics update time may give only a small change in overall engine update time.

Also note that FPS just isn't a great metric for performance comparison.

 

A capsule collider or theoretical pure cylinder collider is perfectly round -- width and height completely describe it. But a mesh collider also has a certain number of sides. That seems to be missing from the discussion.

For a standing column, 6 sides seems to be plenty. I think it's common to model one with 12 sides (whatever looks good) but use fewer for the collider. But it won't roll very well, more sides are needed. A menu would need to have those options, which a way to explain them.

 

So, What about this guy? How do you think he did this cylinder collider?

 

Wheel colliders are often not actually cylindrical. A circlular gizmo is generally drawn around them to assist with aligning them and sizing them to your vehicle's wheels, but the actual collision detection is often done with a raycast, or something similar, rather than an actual cylindrical collider.

As you can see at around the 3 minute mark of that video, things can vertically penetrate a long way into the "cylinder" if they're not aligned with its center, which suggests that the example wheel may be implemented similarly.



(However, I didn't watch the whole 20 minutes. Maybe there are other examples / implementations shown?)


There are a variety of different ways this can be improved on, each with their own pros and cons depending on what really matters in your particular use case.

 

sigh, context matters when the video is 20 minutes.

The example you screen snapped is NOT the volumetric wheel collider.
That is Unity's Standard Wheel Collider, which uses a single raycast, which you mentioned.
The labels of the types of wheels are on the right side, "Tatsu Toybox" contains the volumetric wheels, which in fact is using a dynamically created cylinder collider. "technically a mesh collider".

The video was made to compare different wheel colliders and the challenges. my solution is far from perfect - but it's a start.

I've watched this thread for years. I finally realized there may never be an official cylinder collider for physX/unity.

-climbs back to watching thread in the shadows...