mirror of
https://gitea.wildfiregames.com/0ad/0ad
synced 2026-06-19 14:53:56 -07:00
8e30410109
First, do a ray intersection test with the bounding-sphere for all entities on the map and then check the more detailed selection shape for the remaining candidates. Do checks that require component lookups after the ray intersection tests because these are relatively expensive. The old method for figuring out which entities are below the mouse cursor was incorrect because it does a 2D check to filter out the first candidates which can lead to incorrect results with lower camera angles and high buildings or buildings with a large footprint. Such problems were avoided with quite a large radius for this 2D test and resulted in a large number of candiate entities after this first test (200-500). Also rename PickEntitiesAtPoint to PickEntityAtPoint and make it return only one (the closest) match. I've tested performance with the tracelogger by starting a map and then moving the mouse in circles for one minute. The results were relatively stable. I've compared the total time percentage of input.js:836, which spends nearly all of the time in PickEntityAtPoint. Ardennes Forest - Normal size: Original: 41.46% Patched: 31.6% Ardennes Forest - Giant size: Original: 40.59% Patched: 51.55% As we see, it's faster on normal map sizes but slower on giant maps with a lot of entities. This approach can be further improved with some kind of spatial subdivision for the culling (like an octree), which would help the unit renderer too. This way it should be possible to make it faster (and still correct) on all map sizes and with a large total numbers of entities. This was SVN commit r16098. |
||
|---|---|---|
| .. | ||
| Geometry.cpp | ||
| Geometry.h | ||
| Grid.h | ||
| Player.h | ||
| Position.h | ||
| PriorityQueue.h | ||
| Render.cpp | ||
| Render.h | ||
| Selection.cpp | ||
| Selection.h | ||
| SimulationCommand.h | ||
| Spatial.h | ||