There’s a possibility I found a bug and wanted to flag it in case I am doing something wrong or anyone else comes across it.
Setup: ShapeWorks 6.7, Windows. I’m doing a fixed-domains-style workflow: a healthy population plus some new shapes added later.
Test A:
New project, add 25 shapes, Groom, Optimize.
“Save As” under a new name.
Try adding 4 more shapes.
Error reading the new shapes “Error reading: ../../../../../[path]/[filename].stl” even though the file genuinely exists at that exact location (checked file size, permissions, whether it was open elsewhere, etc).
Test B:
Identical setup: new project, 25 shapes, Groom, Optimize.
Skip “Save As” entirely, stay in the same project.
Add the same 4 shapes.
Works fine, no error.
The only difference between the two tests is whether “Save As” happened before adding the new shapes. I repeated this a few times with different project names to rule out anything name-specific. The original 25 shapes always load fine in every copy; it’s specifically shapes added after the Save As that break.
The error you’re seeing comes from our mesh reader rejecting the path before it ever opens the file,
so Windows can see it but we can’t. We’ve found and fixed one path-handling bug that can cause this,
but I’m not yet certain it’s the one biting you, and I’d rather confirm than guess.
Three things that should help track it down:
1. Your Studio log. Paste %APPDATA%\shapeworks\logs into the Explorer address bar and grab the studio-*.txt file from the session where this happened — we keep the last 100, so it should still be there. It records the path and the working directory Studio was using at each step.
2. The .swproj file. It’s JSON — the shape_1 value for one of the original 25 next to one of the 4 that failed is exactly the comparison I need.
3. Does the copy reopen cleanly? Close the saved-as project and open it again. Do the original 25 still load? Studio keeps meshes in memory once loaded, so them looking fine right after Save As doesn’t prove their paths survived it, but reopening does.
Here are the last messages from one of the logs where this was happening. I tried playing around with the files names/locations some and I have a bunch of logs where the same error was occurring. not sure if this is descriptive enough
I changed the way I build the project with the diseased models, to bypass the save-as issue. I can recreate a sample project to test if the issue persists. I do, however, recall that the original 25 would still load, upon closing/reopening the project.
I’m glad you were able to work around it. I still wasn’t able to reproduce it, but was wondering if you could try that failing method using this version of ShapeWorks:
Coming back a couple days later to try to reproduce my described error, I can’t make it happen again. The diseased models are being read into the Saved-As project just fine, and I can run optimize.
There was probably something specific in the workflow I did to make the error pop up, or the damaged models’ file names were too long, etc. If it happens again I will bring it up!