Hey Norbo. I asked a question a while ago about making an arrow that sticks into the ground and got it working pretty well at the time. I'm now revisiting it though and want to get some additional features working. Previously I was removing the arrow's physics entity upon collision so it would stay stuck in the ground.
I want to change it so that the player can pick up the arrow after it hits the ground and also have the arrow fall and behave properly if the ground below it is removed (the terrain is modifiable). I tried leaving the arrow's physics entity alone after collision, but of course the arrow doesn't stick in place anymore. I thought maybe I could weld it to the ground, but WeldJoint only accepts 2 entities. I think I remember that setting one to null will weld it to the world, but then the arrow will just be stuck floating in air if the terrain below it disappears. I also thought to maybe just disable gravity for the arrow but then it wouldn't fall when the terrain is modified.
Basically I just want the arrow to stay still until the terrain it's attached to is removed or it collides with the player item detector shape. Any ideas?
Arrow physics revisited
Re: Arrow physics revisited
Using a WeldJoint or just making the entity kinematic or otherwise immobile would all work fine. From a performance perspective, there's two main things to be aware of:
1) Using a WeldJoint will add another item for the solver to iterate over. It'll be very cheap since the arrow will (presumably) be inactive, but it's more than zero. An approach which accomplishes the effect without adding an extra joint will be faster.
2) An entity sitting around in the broad phase will cost more than removing the entity entirely. Once again, it won't be huge, but it may matter if there's thousands of them.
(Notably, both of these should become irrelevant when I get around to rewriting the broad phase and collision detection->solver pipeline. Inactive objects and constraints will become approximately free.)
No matter how the arrow is made stationary, it won't be directly aware of any changes made to the terrain. That part has to be handled manually regardless. One option would be a dictionary containing a mapping from cells to arrows stuck in those cells. So, when removing a block from the terrain, check the dictionary to see if any arrows are associated with it. If there are, unweld them/wake them up/add them back or whatever needs to be done. A less direct approach would be to query the broad phase for anything intersecting the cell's AABB. That would find any arrows stuck to the cell. That might require some extra filtering to stop it from unwelding arrows stuck to adjacent cells; a flag on the stuck arrow indicating which cell is 'responsible' would patch it.
1) Using a WeldJoint will add another item for the solver to iterate over. It'll be very cheap since the arrow will (presumably) be inactive, but it's more than zero. An approach which accomplishes the effect without adding an extra joint will be faster.
2) An entity sitting around in the broad phase will cost more than removing the entity entirely. Once again, it won't be huge, but it may matter if there's thousands of them.
(Notably, both of these should become irrelevant when I get around to rewriting the broad phase and collision detection->solver pipeline. Inactive objects and constraints will become approximately free.)
No matter how the arrow is made stationary, it won't be directly aware of any changes made to the terrain. That part has to be handled manually regardless. One option would be a dictionary containing a mapping from cells to arrows stuck in those cells. So, when removing a block from the terrain, check the dictionary to see if any arrows are associated with it. If there are, unweld them/wake them up/add them back or whatever needs to be done. A less direct approach would be to query the broad phase for anything intersecting the cell's AABB. That would find any arrows stuck to the cell. That might require some extra filtering to stop it from unwelding arrows stuck to adjacent cells; a flag on the stuck arrow indicating which cell is 'responsible' would patch it.
Re: Arrow physics revisited
Hmm, alright. I was hoping there'd be a less manual way that didn't involve keeping track of such details. I'll go with making them kinematic for now and give the cell-list thing a try. Thanks for the suggestions Norbo.