possible to create a "true" capsule shape?

Physics
#1

I’d like to create a “true” capsule shape, as a multi-element of two circles at ends and a rectangular polygon joining them (as opposed to approximating it entirely with polygons, because I have reason to prefer the behavior of a true circular curve on the ends).

This doesn’t appear to be possible, as there doesn’t appear to be any way to specify an x/y offset of the component circle shapes.

For instance, and leaving out other details like bounce,density,friction,filter to simplify since they don’t matter here:

local obj = display.newImageRect("capsule\_126x30\_in\_128x32\_rect.png", 128, 32) local props = { { radius=15 }, -- left-side semi-circle, should be offset by x=-48 { shape={ -48,-15, 48,-15, 48,15, -48,15 }}, -- central joining rect { radius=15 }, -- right-side semi-circle, should be offset by x=48 } physics.addBody(obj, "static", unpack(props))

But (obviously) this just creates two circles centered within the rectangle, not at its ends.

Are there any “undocumented” properties of the body spec that would allow me to specify the x/y of those individual circle shape fixtures?

Or is there any other method to get those circles in there where they belong, avoiding polygonal approximation of the entire body?  (also would rather avoid creating three separate bodies and two welds to hold them together)

Thanks!

#2

I’m not an expert, but I think what you’re looking for could be achieved with the Joint API:

http://docs.coronalabs.com/api/type/Joint/index.html

#3

Thanks.  I do know that I could create two discrete circle bodies and a discrete rectangle body, then bond them together with two weld joints, but I’d rather avoid that if possible. (see last sentence of original post)

Three welded bodies are not only more computationally expensive, but also more likely to suffer instabilities.  On the other hand, poly approximation requires lots of vertices to adequately mimic a circle, so lots of 8-vertex-max parts, so also more computationally expensive,… and even with lots of verts is STILL far less “accurate” on the curved collisions (which is my primary focus).

With “native” Box2D you can create the circle shapes and offset them before adding them to the fixture, but I don’t think Corona “exposes” that functionality – you can only create 0,0 -centered circle shapes (it seems).  So “capsules” or “barbells” or other such compound circle-based shapes must (it seems) either be approximated by polys, or welded individual bodies.

But a single body, with 3 component shapes in its fixture, two of which properly act like true semi-circles, no extra weld joints to calc – would be ideal, it’s the best solution in all regards.

#4

Hi @davebollinger,

I’m not sure that multi-part bodies (say even 7-9 parts per “capsule”) would have any noticeable performance effect. Perhaps a tiny bit more processing effort up-front when the body is created, but not necessarily after the body exists in the physics world. Have you seen evidence of this? How many of these capsules will you have on the screen at once?

Brent

#5

Thanks Brent.

Performance isn’t my main concern, but getting an acceptable collision response approximation is.

But you need many vertices to adequately mimic a true circle (else the resulting response feels noticeably “quantized”), that at some point yes, the geometry does become complex enough that it begins affecting performance.  So I mentioned performance only as a side-effect issue.

See attached test suite.  Imagine it as a pachinko simulation, for example.  You can spawn a bunch of circles, or their polygonal approximations, and find the limit at which fps starts to drop for each.   (run on device, not simulator - as a desktop pc won’t be stressed enough to exhibit any performance problems)  For example, my 2012 Nexus 7 can handle about 250 circles, or about 160 3-part-8-vertex polys.

Granted, it’s a fictitious scenario, serving only to illustrate that geometry complexity can impact performance.  (whether it’s enough to matter to any particular app is another question)

What it also demonstrates though, if you play with it a bit, is that if you build a circle approximation out of polygonal “pie slices”, those “seams” in-between the slices are a problem.  So as you up the number of vertices, you necessarily up the number of 8-vertex slices, so up the number of seams between them, so up the number of seam-based penetrations and other artifacts.

I’ve tried various arrangements:  the pie-slice-fans in attached demo, or “horizontally stacked quad strip” -type arrangements, or a single interior n-gon that’s “rounded-out” with additional poly-approximated circular segments across each edge chord, etc.  Doesn’t seem to matter – never as “stable” as a true circle.

Advice welcomed. :slight_smile:  If you can spot anything suspicious in the attached demo, for example, I’m 100% ready-and-willing to be humbled and put-to-shame by learning a better way!  :)

#6

Hi Dave,

I see how the balls in the demo occasionally get caught in each other. A few ideas which may solve this:

  1. Build the circles to eliminate “seams” by having the body parts overlap each other slightly. The “interior polygon with additional rounded arcs” would seem the best idea for this, and I’m not sure why that was causing issues in your previous tests.

  2. Increase the position and/or velocity iterations setting. Yes, that will affect performance, but if not dealing with dozens or hundreds of balls, it may prevent the overlapping. I set this to a value of 16 in your demo, and the balls did not overlap any longer (but I didn’t do direct comparisons between FPS or anything).

http://docs.coronalabs.com/api/library/physics/setPositionIterations.html

Brent

#7

I’m not an expert, but I think what you’re looking for could be achieved with the Joint API:

http://docs.coronalabs.com/api/type/Joint/index.html

#8

Thanks.  I do know that I could create two discrete circle bodies and a discrete rectangle body, then bond them together with two weld joints, but I’d rather avoid that if possible. (see last sentence of original post)

Three welded bodies are not only more computationally expensive, but also more likely to suffer instabilities.  On the other hand, poly approximation requires lots of vertices to adequately mimic a circle, so lots of 8-vertex-max parts, so also more computationally expensive,… and even with lots of verts is STILL far less “accurate” on the curved collisions (which is my primary focus).

With “native” Box2D you can create the circle shapes and offset them before adding them to the fixture, but I don’t think Corona “exposes” that functionality – you can only create 0,0 -centered circle shapes (it seems).  So “capsules” or “barbells” or other such compound circle-based shapes must (it seems) either be approximated by polys, or welded individual bodies.

But a single body, with 3 component shapes in its fixture, two of which properly act like true semi-circles, no extra weld joints to calc – would be ideal, it’s the best solution in all regards.

#9

Hi @davebollinger,

I’m not sure that multi-part bodies (say even 7-9 parts per “capsule”) would have any noticeable performance effect. Perhaps a tiny bit more processing effort up-front when the body is created, but not necessarily after the body exists in the physics world. Have you seen evidence of this? How many of these capsules will you have on the screen at once?

Brent

#10

Thanks Brent.

Performance isn’t my main concern, but getting an acceptable collision response approximation is.

But you need many vertices to adequately mimic a true circle (else the resulting response feels noticeably “quantized”), that at some point yes, the geometry does become complex enough that it begins affecting performance.  So I mentioned performance only as a side-effect issue.

See attached test suite.  Imagine it as a pachinko simulation, for example.  You can spawn a bunch of circles, or their polygonal approximations, and find the limit at which fps starts to drop for each.   (run on device, not simulator - as a desktop pc won’t be stressed enough to exhibit any performance problems)  For example, my 2012 Nexus 7 can handle about 250 circles, or about 160 3-part-8-vertex polys.

Granted, it’s a fictitious scenario, serving only to illustrate that geometry complexity can impact performance.  (whether it’s enough to matter to any particular app is another question)

What it also demonstrates though, if you play with it a bit, is that if you build a circle approximation out of polygonal “pie slices”, those “seams” in-between the slices are a problem.  So as you up the number of vertices, you necessarily up the number of 8-vertex slices, so up the number of seams between them, so up the number of seam-based penetrations and other artifacts.

I’ve tried various arrangements:  the pie-slice-fans in attached demo, or “horizontally stacked quad strip” -type arrangements, or a single interior n-gon that’s “rounded-out” with additional poly-approximated circular segments across each edge chord, etc.  Doesn’t seem to matter – never as “stable” as a true circle.

Advice welcomed. :slight_smile:  If you can spot anything suspicious in the attached demo, for example, I’m 100% ready-and-willing to be humbled and put-to-shame by learning a better way!  :)

#11

Hi Dave,

I see how the balls in the demo occasionally get caught in each other. A few ideas which may solve this:

  1. Build the circles to eliminate “seams” by having the body parts overlap each other slightly. The “interior polygon with additional rounded arcs” would seem the best idea for this, and I’m not sure why that was causing issues in your previous tests.

  2. Increase the position and/or velocity iterations setting. Yes, that will affect performance, but if not dealing with dozens or hundreds of balls, it may prevent the overlapping. I set this to a value of 16 in your demo, and the balls did not overlap any longer (but I didn’t do direct comparisons between FPS or anything).

http://docs.coronalabs.com/api/library/physics/setPositionIterations.html

Brent