-
Notifications
You must be signed in to change notification settings - Fork 759
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Experimental object collision and positions handling improvements #1393
base: master
Are you sure you want to change the base?
Conversation
- Use it for collision tests
…xisting object position This can happen if a gdjs.RuntimeObject is deleted from the scene: it's marked for deletion, but still used by the current events, which can pass its id to the gdjs.ObjectPositionsManager (which won't have an associated ObjectPosition for its id, as it would have been marked for deletion and really deleted at the next call to "update", which happen at any query like collision handling).
Remove "GDJS/tests/games/Collisions with creation and deletion benchmark.gdg.json" as now already existing in GDJS/test/games/memory-benchmarks
… improve perf * Use a slightly more complex object for ObjectIdsSet to be able to quickly clear the set * Fix bug where some objects were considered for pointsTest while not in the set of object ids to test.
A few questions I'd like to ask about this. |
JavaScript is single threaded, so runs on the same thread as the rest. Web-workers or wasm could be used to maybe have it running on another thread, but it was not a goal in this implementation (there is more complexity to achieve this). |
@4ian has the efforts around this been dropped? It seems like your checklist is mostly complete, and I'm sure people would love collision performance improvements. (Especially with Davy's other outstanding PRs) |
This enables RuntimeObject positions to be managed by a spatial data structure (a "RTree", called RBush too here), allowing to speed up collision/separate objects/raycast on a large number of objects.
This is still highly experimental, and a large PR. I want mainly to ensure that there is no regression in terms of behaviors in games, and no large performance regression too.
Performance benchmarks (average frame time):
Collisions benchmark when not hovering the ~1200 boxes with the ~1200 cursor objects:
SeparateObject
Distance test (Distance between objects benchmark)
"Collisions with creation and deletion benchmark"
"Cursor on object benchmark"
Raycast benchmark:
"Point inside object benchmark":
markObjectAsDirty should be called also when setWidth/setHeight is called for most objects (much like
this.hitBoxesDirty
).Todos:
Clean-up todos:
separateFromObjectsList
,cursorOnObject
,isCollidingWithPoint
,raycastTest
Future:
As GDevelop is a generic game engine, there can be cases where the usage of an RTree can be actually too costly and slow down the game compared to not using one. We would probably need to expose this is a setting somewhere in the IDE.
Trying this
Changes in this PR should be invisible to the user. You probably won't notice even difference in your game, unless you're in the case where the RTree can be speeding up things for you (lots of collision check between lots of objects) or slowing this down (few checks but lots of objects moving).
For now, I want to ensure the stability of this - there is room for optimisation later. In the worst case, this could be disabled by default and enabled in the UI on a case by case basis. For now, it's activated for all objects.
To help me, you can simply download the GDevelop versions below. They are beta 88 with this PR applied:
Once you have this version, try to open your game and launch it: