55 lines
3.7 KiB
Plaintext
55 lines
3.7 KiB
Plaintext
Police Boat (Taylor Street Dock) — This one I want to flag: 48.735519° N, -122.331931° W. The -122.331931° W
|
|
longitude seems significantly too far east for a Bellingham waterfront dock. The Bellingham waterfront is
|
|
roughly -122.48° to -122.50° W. At -122.33° W you're several miles inland, near the eastern suburbs/I-5 corridor
|
|
— not a dock. Worth double-checking this coordinate. The Taylor Dock / Boulevard Park dock area is around
|
|
-122.497° W.
|
|
|
|
---
|
|
Ground Terrain and LIDAR Data Processing (lines 784-837)
|
|
|
|
Coverage gap for Chain Home: The terrain data (LiDAR zips, ENC chart, USGS GeoTIFF) all cover the Bellingham Bay
|
|
/ Pacific Northwest area. The Chain Home scope is at RAF Ventnor, Isle of Wight, England — there is no terrain
|
|
data for that location. Since Chain Home is an A-scope (not PPI), land clutter isn't visually displayed the same
|
|
way, but if you want to simulate land return/clutter in the Chain Home A-scope signal, you'll need to either
|
|
skip terrain effects for that scope or procedurally generate some clutter. This should be explicitly called out
|
|
in the document.
|
|
|
|
Raycasting architecture — online vs. offline: The document says "processed into a fragment shader via ray
|
|
casting." This is a critical architectural decision that needs clarification:
|
|
|
|
- Offline preprocessing (recommended): Run the raycasting once at startup (or as a build step) using GDAL + CPU
|
|
code to produce a pre-baked radar shadow/land-mask texture. Load that texture once into VRAM. The fragment
|
|
shader then just samples it. This is fast and suitable for the integrated Radeon 780M.
|
|
- Real-time raycasting in the fragment shader: Computing terrain shadows per-pixel per-frame is very expensive,
|
|
even on discrete GPUs. On an integrated Radeon 780M sharing system RAM as VRAM, this would likely be a serious
|
|
performance problem.
|
|
|
|
You should specify which approach you intend. I'd strongly suggest offline preprocessing into a pre-baked
|
|
GL_R32F texture.
|
|
|
|
Moving texture for police boat: The document notes "the texture will need to be moved around for the police boat
|
|
PPI radar." This is more nuanced than translating it — as the boat moves, the UV coordinate mapping from
|
|
radar-local meters to texture space changes. At 6 nm max range the boat could traverse a significant fraction of
|
|
the texture. The shader needs to recompute the texture origin offset each frame based on the boat's current
|
|
lat/lon. That needs to be spec'd out when you get to that scope.
|
|
|
|
Data layering order is correct: LiDAR overrides coarse USGS DEM where they overlap. The suggestion to reproject
|
|
everything to UTM Zone 10N before merging is the right approach for the Bellingham area.
|
|
|
|
One missing element: The ENC chart (US5WA45M.000, S-57 vector format) gives you shoreline and bathymetry. The
|
|
document doesn't yet describe how the ENC shoreline data feeds into the radar simulation specifically — whether
|
|
it's used to generate a land-mask (anything above 0m elevation = land = returns radar signal) or just for visual
|
|
reference. The LiDAR/DEM heights already handle this implicitly (height > 0 = land), but it's worth a sentence
|
|
clarifying the ENC chart's role vs. the elevation data's role.
|
|
|
|
---
|
|
Summary of action items from the review:
|
|
1. Verify the police boat Taylor Street Dock longitude — -122.331931° W looks wrong.
|
|
2. Clarify how Chain Home handles terrain (or explicitly state it doesn't).
|
|
3. Decide offline-preprocess vs. real-time raycasting and document that decision.
|
|
4. Add a note on how the ENC chart's role differs from the DEM/LiDAR data.
|
|
|
|
✻ Churned for 58s
|
|
|
|
──────────────────────────────────
|