143 lines
6.9 KiB
Text
143 lines
6.9 KiB
Text
inital comms with CNC shop:
|
||
------------------------------
|
||
Me: "project description": A relief map of California, carved from wood. Height exaggerated enough
|
||
to visibly discern the Santa Monica mountains. I can provide an STL file if needed.
|
||
|
||
Shop: STL can work but I can’t manipulate it, which could save some money. If possible can it be
|
||
exported to an .igs or .iges or .stp format?
|
||
|
||
Me: Yeah, STP should be no problem. Can you give a rough estimate of the cost for 1x2-foot relief carving?
|
||
|
||
Shop: Without seeing the drawings, I can’t give even a close price but in the past they range from a
|
||
few hundred dollars to several thousand dollars.
|
||
|
||
Me: That's totally fair! I'll get you some files in a few days.
|
||
------------------------------
|
||
|
||
next comms with shop three weeks later:
|
||
------------------------------
|
||
|
||
Hi Steve, I'm sorry for taking so long to get back to you! I had a harder time producing the IGES
|
||
file than I thought I would, but I think this should be OK:
|
||
|
||
(snip url to file)
|
||
|
||
It's 51 megabytes, otherwise I'd attach here.
|
||
|
||
As modeled, there's probably more high-frequency detail in the mountains than is necessary, as I'm
|
||
going for something that feels nice to the touch so smoother is better. It's also modeled at a
|
||
slightly larger scale than necessary, though not too far off (it's 500x577mm, and I'm interested in
|
||
the 400-500mm range for width; the relief height is in the 20-30mm range depending on scale). I was
|
||
imagining it would be carved with contour cuts in some thick nice ply, though I'm happy to hear
|
||
better ideas; I have literally no experience with making something like this.
|
||
|
||
(NOTE: go back to email thread and summarize the back-and-forth over tooling)
|
||
---------------------------------
|
||
|
||
Note that the shop did the extra work anyway just because they were nice, and that he was glad when
|
||
I told him it was a gift for my wife.
|
||
|
||
|
||
Zulip dump from 10 days after initial contact:
|
||
-----------------------------------
|
||
It IS Mt. Shasta!
|
||
|
||
After I made the mosaic out of the tiles I downloaded to cover the area, I masked it with an outline
|
||
of the state that I downloaded from a California gov geo site, then used a program called
|
||
gdal_translate to turn the image, a "geotiff" file with height data encoded, into that heightmap png
|
||
with the lowest value mapped to 0 and the highest to maxint.
|
||
|
||
I also had to reproject the geotiff with the height data into the same coordinate system as the
|
||
state outline was in. The height data was in a system using lat/long called "EPSG:4326", while the
|
||
state outline was made from line segments with 2d vertices in a projected coordinate system called
|
||
"EPSG:3857" with units of "meters". 3857 is "web Mercator", and is the coordinate system used by
|
||
Google and Open Street Map for their map tiles and other shapes.
|
||
|
||
It may or may not be surprising that cartography is very complicated!
|
||
|
||
My next step is to turn this heightmap into solid geometry that I can 3d print and/or send to a
|
||
local CNC shop to have them carve a relief of California out of wood, which is close to the final
|
||
step of producing an artifact as a present for my partner.
|
||
|
||
There are a bunch of python packages for working in this domain, but they're all just wrappers
|
||
around various GDAL libraries or tools.
|
||
|
||
The raw topo data I got from
|
||
https://portal.opentopography.org/raster?opentopoID=OTSRTM.082015.4326.1 (that was the epsg 4326
|
||
geocoded tiff; actually, several of them because you can only download up to 450km^2 at a time,
|
||
hence having to mosaic them with the gdal_merge.py command (the '.py' is in the name of the command
|
||
that gets installed when you do apt install gdal-bin)), then use gdalwarp to re-project to 3857,
|
||
then I had to write a python program to mask it for some reason, then gdal_translate (no .py on that
|
||
one, but they're all just python scripts) to convert to the png heightmap. I'm leaving out a couple
|
||
details in the workflow, but that's the main shape of it.
|
||
|
||
OK, actually, now that all that context is established, here's the actual command that produced that
|
||
file from the geocoded tiff:
|
||
|
||
gdal_translate -of PNG -ot UInt16 -scale -130 4412 0 65535 cropped_ca_topo.tif heightmap_cropped.png
|
||
|
||
and then I used convert (the imagemagick program) to scale the png from 33,311x38,434 to
|
||
2,000x2,2308 pixels.
|
||
|
||
the -scale -130 4412 0 65535 is mapping the height data min/max to the png whiteness in the output
|
||
file.
|
||
---------------------------------------
|
||
|
||
Zulip musings from a few days after that, still working on the heightmap:
|
||
---------------------------------------
|
||
(re: non-linear scaling of height to reduce pointiness)
|
||
ok, it was easier than I thought it would be. gdal_translate has a -exponent flag you can use with
|
||
-scale, so I remade the heightmap with an exponential scaling, using 0.41 as the exponent.
|
||
|
||
funny enough, I'm still working on this, since even when I drastically scale the size of the mesh
|
||
down in Blender (which I export to OBJ for import by FreeCAD), doing anything like modelling (eg,
|
||
extruding downward or joining with a solid base, or cutting the shape so it's CA-shaped and not a
|
||
rectangle) requires tens of gigabytes of resident memory and I keep having to kill the program and
|
||
start over.
|
||
|
||
a 60-megabyte OBJ file turns into 21 GB of resident data in the modelling software.
|
||
|
||
I have 32GB of RAM installed
|
||
|
||
that 21GB expands to 30 when I try manipulating it
|
||
------------------------------------------
|
||
|
||
Zulip from two weeks later (July 7):
|
||
--------------------------------------
|
||
|
||
Two weeks later I'm finally printing something out. I've given up on converting it into a parametric
|
||
CAD-like object; it seems this is a Hard Problem, but I'm not sure why. My goal with doing that was
|
||
to give a parametric CAD file to a local CNC milling shop, per their request, since when I suggested
|
||
a mesh-based file (STL), the guy was like "I can't do much manipulation with that to make it more
|
||
manufacturable, so a real CAD file would be best".
|
||
|
||
But at least with an STL file, I can print it myself. So that's going now, we'll see how it turns
|
||
out in no less than eight hours.
|
||
|
||
I haven't really done anything else with my computer besides this for a while.
|
||
|
||
(next day)
|
||
ok, I got something printed out, but I'm not super stoked on it. Also, I'm still chasing the elusive
|
||
dream of turning this into a parametric solid for easier CNCing. Vape pen for scale:
|
||
(insert shitty print photo)
|
||
|
||
(next day after that, the 9th)
|
||
I've finally "finished": I've created a mesh that has no missing faces, is not too crazy, and can be
|
||
converted into a parametric solid, and sent that off to a local CNC shop for a quote on having it
|
||
routed out of wood. I'll also do another 3D print, since the base is now a larger version of the
|
||
coastline instead of a rectangle, and the high frequency detail is a little diminished.
|
||
|
||
----------------------------------------
|
||
|
||
Links:
|
||
|
||
https://data.ca.gov/
|
||
|
||
https://portal.opentopography.org/raster?opentopoID=OTSRTM.082015.4326.1
|
||
|
||
https://www.printables.com/model/240867-topographic-california
|
||
|
||
https://touchterrain.geol.iastate.edu/
|
||
|
||
https://en.wikipedia.org/wiki/Shuttle_Radar_Topography_Mission
|
||
|