transportation:roads
Differences
This shows you the differences between two versions of the page.
| Both sides previous revisionPrevious revisionNext revision | Previous revision | ||
| transportation:roads [2026/04/18 23:59] – timb | transportation:roads [2026/04/19 00:00] (current) – [Science] timb | ||
|---|---|---|---|
| Line 76: | Line 76: | ||
| [[https:// | [[https:// | ||
| + | |||
| + | ===== Science ===== | ||
| + | |||
| + | == The Simple Geometry Behind Any Road == | ||
| + | |||
| + | April 13, 2026 - " | ||
| + | |||
| + | In the last blog post, I explained what sits at the backbone of procedurally generated roads: the data structure, aka the minimum information you need to describe any piece of road infrastructure. The answer to that fundamental question was a set of abstract cross-sections of the road, each storing a snapshot of how the road looks at that specific point (or, should I say, line). I called them simply: profiles. | ||
| + | |||
| + | A good analogy I didn’t have the inspiration to make at the moment was to compare them with Bezier splines. To store a Bezier spline, you don’t need to save the entire curve explicitly, but just anchor points and handle positions. With a bit of math and a few formulas, you can reconstruct the actual path at any time by interpolating between the control points. | ||
| + | |||
| + | The profile-based representation works the same in my system. The profiles are the control information, | ||
| + | |||
| + | In this blog post, I’ll go over how I am computing the purple part. How to interpolate between these green profiles to generate beautifully smooth, parallel paths? | ||
| + | |||
| + | https:// | ||
| + | |||
| + | |||
transportation/roads.1776556752.txt.gz · Last modified: by timb
