Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Geometry simplification #60

Open
sevenoffline opened this issue Apr 18, 2022 · 1 comment
Open

Geometry simplification #60

sevenoffline opened this issue Apr 18, 2022 · 1 comment
Labels
enhancement New feature or request

Comments

@sevenoffline
Copy link

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
Copy link
Owner

fgebhart commented Apr 18, 2022

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

  • to improve the user experience (of the average user) by limiting the computation time
  • to avoid the streamlit app from being shutdown due to rate-limiting / being non-functional due to resource issues

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:

  • little app usage as mentioned above,
  • while working on the tiling feature, I started implementing zipping the STL files which allows to reduce the volume by roughly a factor of 4.

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.

@fgebhart fgebhart added the enhancement New feature or request label Apr 18, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants