You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As an alternative to #24, I should consider resolving collisions independently: aggregate the forces for each overlapping node, and then apply them at the end after determining all the overlaps. I did this before looking at the previous position ⟨x,y⟩ and it was too soft, but maybe it would be sufficient when looking at the next position ⟨x + vx,y + vy⟩?
Also if we do this, the forces should be divided in half, since they will apply symmetrically to each pair of overlapping nodes. And it means we don’t have to mutate the quadtree as we iterate over the nodes, and we could probably compare indexes i < j to determine whether we need to test two nodes for overlap.
The text was updated successfully, but these errors were encountered:
And since we’re not mutating the quadtree, we could compute the maximum radius of each quadrant (rather than the maximum radius of all nodes), potentially allowing for much faster testing.
As an alternative to #24, I should consider resolving collisions independently: aggregate the forces for each overlapping node, and then apply them at the end after determining all the overlaps. I did this before looking at the previous position ⟨x,y⟩ and it was too soft, but maybe it would be sufficient when looking at the next position ⟨x + vx,y + vy⟩?
Also if we do this, the forces should be divided in half, since they will apply symmetrically to each pair of overlapping nodes. And it means we don’t have to mutate the quadtree as we iterate over the nodes, and we could probably compare indexes i < j to determine whether we need to test two nodes for overlap.
The text was updated successfully, but these errors were encountered: