fgebhart / mapa

Create 3d-printable STLs from satellite 🌍 elevation data
MIT License
25 stars 4 forks source link

Geometry simplification #60

Open sevenoffline opened 2 years ago

sevenoffline commented 2 years ago

There are now a lot of controls to modify the output except one: the simplification-voodoo you do with that geometry. I exported a large area first and then a smaller part from that area as a second model. I noticed that the smaller area resulted in a larger file = higher resolution. That's great on one hand (great details on the small one) but bad on the other hand (lack of detail on the large one). And yes, this makes sense if the object would be printed in one piece (print resolution) but my plan is/was to export a large area and cut that into smaller parts to print (like the suggestion I made earlier) - but with the lack of detail this is pointless :(

How about a Geometry Compression-slider to let the user decide how fine the resulting model will be created? Maybe with an estimation of polycount & file size displayed?

fgebhart commented 2 years ago

The main reasons why I initially introduced this resolution-limiting-voodoo was

I agree that the first bullet point could be addressed by introducing something like your suggested compression-slider. Also currently there are only a few requests per day, which is why increased computation times should also not be an issue.

Still, I'm quite certain that at least some resolution limiting is required, as otherwise it would be super easy (simply by selecting a large area) to generate STL files with >10s of GB, which in turn would likely cause rate limiting or a crashed streamlit app.

However, I might be able to change the limitation quite a bit, because:

With that, I'm planning to first implement the tiling feature (as per #45) together with the zipping and will try to come up with a better resolution-limiting-voodoo (maybe with an additional slider) afterwards.