Afaik that results in a ton of draw calls, which will bog down render performance. LineSegments should work better here.

Changes: - added rivers_lines_seg, an alternative object construction that uses LineSegments (big performance improvement) - added radio widget to switch between the old and new object - updated three to 0.127.0, added helper to import example modules - moved the draw loop into the canvas cell - fixed model orientation (y is up in three) - clamped orbit controls rotation - merged area_N json cells into a single cell, adapted commented transform cell, removed obsolete cells - removed mutable controls (there's no point, really) - minor cleanups here and there

I strongly recommend to clean up your data before you handle it with three. E.g. there are several arrays that only have points with undefined coordinates, end up with a single point after filtering out undefined. Haven't looked yet, but you can probably also do any scaling in threejs.

Finally, I've removed the update loop. three should now only rerender when the camera is moved. If this causes problems, let me know and I'll add it back.

In summary, we went from 25061 scene objects (Line) to 24 scene objects (LineSegments).

Diff: https://observablehq.com/compare/c9c505c1afa60c61@1207...c9c505c1afa60c61@1347

Thanks Fabian, so many improvements. Yes, the data is pretty raw and needs some cleaning, will look at doing that in the other notebook. I'm also going to check that I got the correct DEM and Rivers for the Taranaki region. It could be that the river data covers part of the next region. Some of the code is new to me, like the way xyzcords is being passed an object to the arrow function is very cool.

The difference isn't lines vs line segments, it's the number of draw calls. With line segments we can lump multiple lines together into a single draw call, while lines require a line to be continuous.