experimenting with body/fixture/shape in-engine editing

[GoogleCodeExporter]

I'd really like to experiment with in-engine body/fixture/shape/joint changes, 
where you could change a polygon's points or a circle's radius without 
removing/adding from the engine.

This would probably consist of:
1. marking the object as 'dirty' or 'updated'
2. world checks for new contacts on the object
3. ????
4. PROFIT!!!!

Original issue reported on code.google.com by toucansa...@gmail.com on 21 Jul 2011 at 4:05

[GoogleCodeExporter]

Original comment by toucansa...@gmail.com on 21 Jul 2011 at 4:05

• Added labels: Priority-Low
• Removed labels: Priority-Medium

[GoogleCodeExporter]

at the very least, solidify what can be edited in-engine (like distance joint 
length), and what can't.

Original comment by toucansa...@gmail.com on 21 Jul 2011 at 4:07

[GoogleCodeExporter]

I really like this idea, I think it would be great to figure out, it would add 
a lot of flexibility to the engine; I know for a fact that it can be done very 
simply in some cases, I played around with it a bit in earlier versions but 
never quite tracked down the limits or the changes that would need to occur to 
make it work all the time.

I think your checklist is pretty much right on, with a couple of additions - 
just bear in mind that some of the shape initializations will need to be 
re-calculated if the shape changes, for instance, IIRC several bits of 
information about polygons are calculated once at shape initialization and are 
left to linger after that.  Shape AABBs are also stored away, I think.

The other issue is what to do about velocity; for instance, if I "animate" a 
circle to be pulsating, then I would assume that as it blew up it would push 
things away with a non-zero relative velocity, but without some additional 
stuff going on internally that wouldn't be the case, the normal velocity would 
always be zero even though the shape is changing.  There are a couple solutions 
to this problem:

1) Calculate the relative velocities (which would otherwise be 0) based on the 
current time step and the change in local position "at that point" relative to 
the last step.  "at that point" is something we'd need to think about in more 
detail, but it's probably pretty straightforward, we just figure out the 
relative velocity of each polygon segment and assume that wherever the contact 
happens, we use the velocity for that segment...the one thing I'm not sure 
about is whether it's very easy to extract information about what segment a 
contact is touching, because of the relative complexity of the polygon 
collision code (which has always somewhat mystified me).

2) Come up with a way to let the user specify the relative velocity at any 
point on the shape.  The bonus here would be that a) we could still implement 
1) as a special case, and b) things like conveyor belts and tank treads become 
absolutely trivial to add, because people can just specify relative velocities 
on non-changing shapes.  There was some discussion in the forums about this a 
while back, though I can't find the link right now...

Original comment by ewjor...@gmail.com on 21 Jul 2011 at 6:09

[GoogleCodeExporter]

Original comment by toucansa...@gmail.com on 21 Jul 2011 at 6:16

• Added labels: Type-Enhancement
• Removed labels: Type-Defect

[GoogleCodeExporter]

I really like that second option, I that could be used to do a lot of very cool 
things.  

Original comment by toucansa...@gmail.com on 22 Jul 2011 at 3:58

[GoogleCodeExporter]

I'll look into what that would take, then, maybe I can dig up the forum post 
that mentioned that - I think in addition to dirty-flagging changed shapes, 
that could actually be enough to do the trick.

Original comment by ewjor...@gmail.com on 22 Jul 2011 at 9:00