How to load a binary STL?

[paulftw]

I'm getting errors when trying to import a binary STL.
My file is 2mb binary and 10+mb ascii, loading latter takes more than 5 minutes.

Is that expected? If so, is there a workaround to import binary STL?

Documentation doesn't specify which formats are supported, but blingmything specifically says to use ascii STL.
Underlying OCC seems to support both binary and ascii

[sgenoud]

I am not sure that loading in binary will be faster than the ascii. For what I have seen the issue for complex STL is that the kernel creates faces for every triangle and it takes a lot of memory / processing. For instance FreeCAD does not use opencascade for meshes.

The ideal process for STL in replicad should be STL => triangulation => vectorisation => Shape (i.e. STEP like).

I have been tempted to put time on trying to implement a vectorisation of STLs (in this spirit), but it was a chunk of work too big for my appetite.

That said, when I looked the kernel was only working on ASCII STLs - but things may I changed (I could not find the doc that said it).

[sgenoud]

For my curiosity, what is your use case for using replicad to modify a STL?

[paulftw]

I want to customize a toolhead sensor of the VoronDesign extruder.
They distribute their designs as a bunch STL files for printing, and one STEP file which I haven’t found software for (while typing this I realized I haven’t tried FreeCAD but yeah).

The plan was to load STL in replicad, cut() and fuse() some changes.
(That idea is inspired by demo video from CascadeStudio and how BlingMyThing works).

[sgenoud]

Have you tried to use the STEP file with replicad? It should work better with it (unless there are way too many things in the STEP file).

STEP file store data as BRep which can be compared to vector graphics in 2d images, while STL are meshes which is more like raster graphic.

replicad is a based on a Brep kernel, so not so great with mesh data. It is still possible to do some things if the mesh is not too big.

[raydeleu]

If you want to modify an existing STL a simple approach is to use Blender (https://www.blender.org/). I have used this method a few times and often it works fine. Have a look at https://www.youtube.com/watch?v=9EF2VryBAq4 for a detailed example how this could work. The downside to this approach is that you are limited in the type of adaptations you can create.

Therefore I have found that rebuilding the complete shape in Replicad is sometimes a better approach. An example how this could look is #47. The benefit of this approach is that you can make the design truly parametric, so you can easily make small changes to create a part that fits.

Also have a look at https://www.opencascade.com/products/cad-assistant/. This program has helped me several times to convert an existing model into a format that can be opened by one of the other programs that I use. And if this does not work, try https://solidedge.siemens.com/en/solutions/users/hobbyists-and-makers/. This software can definitively open a lot of formats and also export a lot of formats. For a hobbyist it is perhaps too complicated, but the commands for opening and saving are very straight forward.

Once you have the original file in the desired format you can choose your approach from the options I mentioned previously.

[paulftw]

Yeah, using blender or reverse engineering the shape in replicad are feasible options.
I wanted to achieve the same in replicad because a) it seemed possible and fun; and b) coded workflow can be re-used for different shapes and/or parametrized modifications.

Ended up converting the STL to ascii and using replicad on the ascii file. Here's the end result (includes hacks for converting SVG to replicad extrusions).
Biggest drawback to this approach is that it takes ~2minutes to process entire sketch.

[sgenoud]

I should create a drawSVG helper from the code extracted here!

Another avenue that might be interesting is working with jscad for the mesh structure (and using replicad for creating the shapes to boolean).

P.S. Back from holidays! I will look into your issue today (if I find the time!)

[raydeleu]

@paulftw I noticed that you have included replicad in your website at scriptcad.com. You did a really nice job as the error messaging in your implementation seems improved over that in the visualizer and workbench offered in the replicad repository. Furthermore you included a feature as evaluate on request only. And finally you seem to have tackled problems like importing parts and SVG-sketches. The downside seems that evaluating a script in scriptcad takes longer. Is this caused by the additional functionality to identify the location of errors or is it just a matter of processing power?

• Is your implementation officially available as replicad is not mentioned on the opening page of scriptcad.com as one of the offered modelling libraries?
• If processing power is the limitation, would there be a way to install the application locally?

The link to drawSVG mentioned in the post above does not work any longer.

[paulftw]

@raydeleu just spotted your comment regarding scriptcad. First of all thank you for noticing the small improvements and taking time to write to me.

Scriptcad started as a "codesandbox" for designs of physical things. Quite similar to cadhub.xyz, but different (I learned of cadhub years after I've started working on Scriptcad, for better or worse)
Therefore I don't have a special implementation of replicad (and no plans to have one), all I did is added boilerplate to parse and render output of the most useful (in my opinion) CAD packages from npm.
Original idea was to not have "supported libraries" at all - users should be able to write importScript('https://whatever.js') and use absolutely any CAD kernel. But this is quite hard to get right.

I think performance issues you've noticed come from three main sources:

• user scripts are executed in a web worker - infinite loops or crashes in a user sketch are less likely to break the IDE, improved security etc. But it's slower and sometimes Chrome does weird or slow things if a page uses web workers.
• js code is fed through a Babel compiler in yet another worker. This is needed to support modern import, generators, etc, but it's expensive on its own, let alone in a web worker on the client side.
• generally it's a much more complex web app with lots of moving parts and lots of optimization work still to do, as I'm still learning which features are worth focusing on.

Overall, with pre-caching and optimizations already in place, everything adds up to roughly 200-500ms per full run and maybe up to 10% speed penalty. Numbers wise it doesn't look that bad on my 2017 macbook, so every time I think about it I always come up with a more important feature or problem for the day :)

Also worth mentioning that first page load and first compilation are extremely slow for new users because ten megs of JavaScript have to be downloaded, parsed and compiled. It all gets cached by the browser for the next run, but first impression matters and currently it isn't great.

Installing locally may help with some of these problems, but I think it won't magically solve everything.
And if I release an Electron app or something I'll have to support it, on multiple versions of multiple OSes. This will be a distraction from improving the product. I'm just not ready for that yet.