Cannot call Body.setDensity on a static body

[jmfd]

Calling Body.setDensity on a static body will yield invalid results.

This is a regression from Issue #378 (change f7d1877).

See attached example; the box bouncing off the ground will disappear when the ground's density is changed.

setDensityBug.zip

I can easily workaround by testing if it is static first.

[liabru]

The functions setDensity, setMass, setInertia shouldn't be used static bodies because they are considered to always have infinite mass. Do you mean that the functions should guard against this? Might be a good idea?

[jmfd]

Yes - while this is no problem for Hype, I filed because I thought from an API perspective it would probably be better to at least not break physics bodies due to NaNs cropping up from setting this value. Seemed like a regression, as Hype was actually supplying Infinity to density already in static cases and that broke the same way.

To take it further, it would be nice if the supplied values could be preserved; this way setStatic could be simply switched on/off and the body wouldn't need to be resupplied with the density. It seems more like an implementation detail for collision calculations that a static body has Infinity density. (But that's just my 2¢ as I already am working around it!)

[liabru]

Yeah I think adding guards is a good idea then.

To take it further, it would be nice if the supplied values could be preserved;

Agreed, it should be possible to implement that using the existing body.parts[i]._original cache approach that's set inside Body.setStatic.

[jmfd]

I'm not sure how much of a factor it is for what you are proposing, but I am swapping out the body.parts (via Body.setParts()) when there are path changes:

This is an upcoming feature in Hype; if there's a better way to change the vertices feel free to let me know. I need to keep the top-level body object (vs just create a whole new one) because there's also a new API for users to get at it and they may keep it around.

[jmfd]

Agreed, it should be possible to implement that using the existing body.parts[i]._original cache approach that's set inside Body.setStatic.

Interesting; I got a report of a bug today that ended up having me look into this - please see #641.