Exporting STL from web app produces file unreadable by orcaslicer

[yeroca]

[Add a title above and insert a description of the issue here]

I exported this model as an STL file, but when I try to import it to orcaslicer, I get an error saying the file doesn't contain any geometry data. However, if I export as a STEP file, it works fine.

Core Dump

[coredump-d5ad8c5b-6329-4d5c-aef2-b5935776885c.json](https://public.blob.zoo.dev/bbdca4a0-91ed-413f-a401-89b30615960f/modeling-app/coredump-d5ad8c5b-6329-4d5c-aef2-b5935776885c.json) Reference ID: d5ad8c5b-6329-4d5c-aef2-b5935776885c

[jessfraz]

I think this is the dupliocate file execution bug

[jessfraz]

can you paste the code please?

[yeroca]

const holeFudge = 0.4
const frontBarD = 5.0
const yBarD = 6.7
const lowerBlockHoleD = frontBarD + holeFudge
const upperBlockHoleD = yBarD + holeFudge
const tubeClr = 1.5
const lowerBlockH = lowerBlockHoleD + 2 * tubeClr
const upperBlockH = upperBlockHoleD + 2 * tubeClr
const elevateH = 20
const upperBlockL = 25
const lowerBlockL = 35
const length002 = upperBlockL
const blockSz = max(upperBlockH, lowerBlockH)
const sketch001 = startSketchOn('XZ')
  |> startProfileAt([0, 0], %)
  |> xLine(upperBlockL, %, $edge1)
  |> yLine(-(elevateH + blockSz), %, $edge2)
  |> xLine(lowerBlockL - blockSz, %, $edge3)
  |> yLine(-blockSz, %, $edge4)
  |> xLine(-lowerBlockL, %, $edge5)
  |> yLine(blockSz + elevateH, %, $edge6)
  |> xLine(-(upperBlockL - blockSz), %, $edge7)
  |> lineTo([profileStartX(%), profileStartY(%)], %, $seg01)
  |> close(%)
  |> hole(circle([
       upperBlockL + lowerBlockL - blockSz - (lowerBlockHoleD / 2) - tubeClr,
       -(blockSz + elevateH + blockSz / 2)
     ], lowerBlockHoleD / 2, %), %)
const rad = 3
const extrude001 = extrude(blockSz, sketch001)
  |> fillet({
       radius: rad,
       tags: [
         getNextAdjacentEdge(edge2),
         getNextAdjacentEdge(edge3),
         getNextAdjacentEdge(edge4),
         getNextAdjacentEdge(edge5),
         getNextAdjacentEdge(edge6)
       ]
     }, %)

const sketch002 = startSketchOn(extrude001, seg01)
  |> startProfileAt([0, 0], %)
  |> circle([blockSz / 2, blockSz / 2], upperBlockHoleD / 2, %)
const extrude2 = extrude(-upperBlockL, sketch002)

[jessfraz]

okay whoa this helps this is def an export bug, cc @alteous

this is a real export but not the react thing i thought it was

[alteous]

@yeroca , thanks for reporting! This was a fun one to debug. :smile:

I was able to reproduce the issue and found both a workaround and a solution. The workaround is to export binary STL instead, which does work. There is an option for this in the export tool:

---

I believe the issue is with OrcaSlicer's ASCII STL importer which is built on top of an older library called admesh. Specifically, it has an upper limit on the number of digits for components in a normal vector:

char normal_buf[3][32];
...
fscanf(fp, " facet normal %31s %31s %31s", normal_buf[0], normal_buf[1], normal_buf[2]);

For compatibility with admesh, we could truncate our normals to 10 decimal places. That should be more than enough precision anyway. This allowed the file to load when I tried locally.

[alteous]

For future reference, the offending line was:

facet normal -1 0.0000000000000000000000553211 0.00000000000000017587692

[yeroca]

Interesting! Thanks for the info. So much for being precise! (in ASCII at least)

Checking my existing STL files produced by OpenSCAD, I see they are all binary. I never bothered to look inside them before.

[jessfraz]

we will get the fix pushed by tomorrow AM!

[jessfraz]

fix is deploying!

[jessfraz]

I just tried it and it is now fixed thanks @alteous and thanks for letting us know @yeroca !