not split by direction. Update many callers, and lock down the
visibility of the old methods.
Tested a few maps manually to make sure there's no behavioral diff. Only
problem right now is the z-order of adjacent lanes covering up half of
the white stripe sometimes. Have some ideas to fix that later, and not
_super_ important in the meantime.
multiple points. This was already handled when the roads went between
the same intersections, but I found a case in Ballard where the roads
are just really close to each other. Screenshot diff empty in Krakow,
but still related to #243
- Cut off the one-way markings before the end of the road, to stop stomping over turn markings
- Draw turn arrows to every road, not each lane
- Only draw turn arrows when a lane is restricted from going to some
outbound lane. At most intersections, all turns are legal, so don't draw
anything.
[rebuild]
data is regenerated. (Ideally screenshots would also be automated, but
that's a little trickier.)
_NOW_ regenerate all data! The only diff anywhere is the binary map
format, so there's confidence the last few commits haven't changed
anything.
just does Dijkstra's. This has a few uses:
- When you import with --skip_ch, the resulting map will still work,
just more slowly
- For congestion capping experiments, we sometimes want to route around
a zone. Regenerating the contraction hierarchy for every combination
of zone being open/closed is likely more complex and expensive than
just falling back to A* for trips that cut through at least one closed
zone.
Not regenerating yet
the API (#245), and beef up the Python example.
Impact to prebaked file size is tiny -- for lakeslice, the original
intersection_thruput is 2MB and the new traffic_signal_thruput is 435KB.
[rebuild]
* Complete wasm backend memory mgmt, extract common glow code
Similar to 3e8d2d7d, but for the wasm backend.
Also takes a pass at consolidating some of the common code between the
glow-native and glow-wasm backends. At this point, the backends just
diverge in their window handling, and the data types of their OpenGL
data types (e.g. vertex_buffer.id is WebBufferId vs. uint32 on native)
* glow impls share prerender innards
* coalesce vertex/buffer types
* minimize diff
* clarify module naming
Without this change, the screen was blank when using the glow backend on macos.
Some debugging traced it down to the shader attribute configuration.
@dabreegster suggested trying to declare a newer version of the shader
language which supports the syntax for explicit attribute layout, which
fixed it.
Specifically, before this commit, this diff was interesting on macos:
diff --git a/ezgui/src/backend_glow.rs b/ezgui/src/backend_glow.rs
index 2046bccd..f834a4fa 100644
--- a/ezgui/src/backend_glow.rs
+++ b/ezgui/src/backend_glow.rs
@@ -244,31 +244,7 @@ impl PrerenderInnards {
glow::FLOAT,
false,
stride,
- // WTF: this offset seems correct, but on macos (OpenGL 4.1)
- // a blank screen is rendered.
- //
- // To debug, I've hardcoded a color assignment in the fragment shader.
- //
- // What's fascinating is that, even if we don't use this second "style"
- // input for anything, the mere act of passing it in with the expected
- // offset causes all the geometries to not be visible.
- //
- // That is:
- // - with a hardcoded color in the fragment shader
- // - set offset `0` here (which is surely wrong?)
- // - I can see the correct shapes with my hardcoded color
- //
- // - with a hardcoded color in the fragment shader
- // - set offset `2*size_of(f32)` here (which should be right)
- // - I'd expect to see the correct shapes with my hardcoded color
- // - But instead I can no longer see any shapes on the screen
- //
- // So it seems like something about setting the offset on this second attribute
- // configuration is corrupting our vertex data, even if we never read from that
- // attribute data.
- //
- // 2 * std::mem::size_of::<f32>() as i32,
- 0
+ 2 * std::mem::size_of::<f32>() as i32,
);
new trips, then seeing the impact they'll have on the normal weekday
scenario. So how much externality would be caused by a bunch of new
trips if some building is built?
Demo showing the whole flow: https://youtu.be/adpED0KGQ7Q. Why do those
few trips at the beginning impact some later trips so much? Who knows.
Likely parking spots get gobbled up.
a zone per hour. This is part of support for some kind of congestion
charging experiments. This step just rearranges the data to define the
cap and makes a UI to edit it. Not enforcing the cap yet.
- Need to draw a background underneath the curved text
- Sometimes the text is "upside-down" relative to what's expected; we
should be able to reverse the polyline sometimes to deal with that. But
when?
