Document GPS routing research
This commit is contained in:
@@ -2,6 +2,28 @@
|
||||
|
||||
Current date/time context: 2026-06-27, local timezone America/Chicago.
|
||||
|
||||
## 2026-06-27 Routing Literature And Engine Research
|
||||
|
||||
- Added `docs/gps-routing-research.md` as the durable summary of the GPS
|
||||
routing research pass.
|
||||
- Main conclusion: stop treating "prefer highways" as the objective. It is a
|
||||
useful proxy, especially for AutoDrive, but manual player GPS should optimize
|
||||
momentum/corridor quality: low turn count, low short-segment churn, good
|
||||
continuity, fewer awkward ramps/intersections, and later slope/airtime risk.
|
||||
- Production engines split edge cost from transition/turn cost. Mirror that at
|
||||
the native solver relaxation surface instead of using another broad highway
|
||||
multiplier. Prefer nonnegative additive penalties first so the vanilla
|
||||
A*/Dijkstra-like assumptions stay sane.
|
||||
- The user explicitly allows external dependencies if they are justified.
|
||||
Recommendation after research: do not link a full production engine yet.
|
||||
Borrow OSRM/Valhalla/GraphHopper cost-model ideas now, and consider
|
||||
RoutingKit or a tiny custom A* runner offline for graph/cost experiments.
|
||||
- Full in-game engine replacement remains feasible but expensive. It requires
|
||||
extracting/owning the full drivable graph, mapping live start/target points,
|
||||
computing the path, and converting the result back into Cyberpunk route
|
||||
handles/records. Revisit only if native relaxation cannot support the desired
|
||||
model.
|
||||
|
||||
## 2026-06-27 Momentum/Corridor Direction
|
||||
|
||||
- The user reframed the target objective: player GPS should optimize for
|
||||
|
||||
Reference in New Issue
Block a user