If you assign SolveSpace identifiers from the STEP identifiers using the existing remap mechanism or equivalent, then what else is left to be done?

Hmm, what entity types would I be using? The COPY ones? Or just the existing ones, but somehow tell the solver they should be fixed in place?

POINT_N_ROT_TRANS, NORMAL_N_ROT, etc., exactly analogous to linking a SolveSpace model, no? You put the point from the STEP file in en.numPoint, and PointGetNum() applies the transform.

Ok I see now. I misunderstood how linking SolveSpace models worked.

I propose also linking of STL which de-facto 3d printing format #1.

STEP is the de-facto interchange standard for things like connectors. Everything in the McMaster-Carr catalogue has a STEP model. And you can extract features from STEP, so you can constrain everything else to the edges and points from STEP.

STL isn't anywhere nearly as useful since you only get geometry, and even if we extract features, those are piecewise linear. The only real use for STL that I see is as a source operand for booleans, and even that doesn't seem especially handy.

@whitequark,
We can done almost all assembly-realated things on piecewise linear STL just using pt-pt-coicident, pt-on-line, plane-plane parallel, pt-on-plane. I think it is cirtical for DIY and OpenSource, where STEP is not so popular as STL.

Imagine a top face of a cylinder.

just using pt-pt-coicident

Where do the points go? On every vertex? That's intractable.

pt-on-line

Where do the line entities go? Not only that's intractable performance-wise but it also seems useless even if it is done.

There are no needs to define every privitive from STL, only used in constraints. We can draw construction over this and use it in assemblies. For top of cylinder you can just draw circle in 3d sketch, and make 3 pt-on circle to align it with cylinder. You will get ability to calculate its radius and get ability to constrain it center anywhere you want. Looking forward, we can create ability to use such meshes for reverse-engeneering STL to SLVS if we import STL as "construction".

I guess, but I'm still not convinced that STL linking has such a high utility. It's an output format for manufacturing, not an interchange format.

Actually, STL is bad for manufacturing. Nor mesh or b-rep is good for manufaturing output, only csg formats can be good. But still there are no any good csg format... Am I miss something?

Actually, STL is bad for manufacturing.

If we talk about 3D printing then STL is the de-facto standard. In fact you will have a hard time finding a shop that accepts something except STL... regardless of whether it's good or bad.

Don't forget we are talking about the area where expanding curves into pwl gcode, then buying commercial software whose only purpose is to reassemble pwl back into beziers, is considered a good idea.

Yes, this is just some lyrics about awful STL and BREP.
But we are talking about huge database of STL. What to do if the source files lost or hardly to get, but you have STL? You have an options: you can use it in assemblies to design parts compatable with this, or make reverse-engeneering. I know what STEP is good and must have, but still think what working around STL files will be popular for the SolveSpace users.

What to do if the source files lost or hardly to get, but you have STL?

That's not really "open source"; and in fact distributing a product made using such an STL file would violate the terms of various Open Hardware licenses, e.g. see http://www.ohwr.org/attachments/2388/cern_ohl_v_1_2.txt#L125.

Being able to convert a STEP or STL file to SLVS would be perfect for most of my uses.

@Tetsuharu That's not really feasible because the SLVS format can represent infinitely many times less geometry than the STEP format; STEP allows arbitrary NURBS geometry and far more, SLVS only the things you can parametrically define in SolveSpace.

Importing (same as converting) the entire STL mesh as a group of the type described in #237 is feasible, but I'm not sure how useful in practice that would be.

I spent an afternoon hacking up a proof of concept for STL import using the libassimp library:

https://github.com/mattgleeson/solvespace/tree/gui-stl-import

Surprisingly to me it does seem to do something with very well-formed STL files, but it just makes a lot of lines instead of a solid volume. I need to figure out the actual "solve" part of "solvespace" I think.

Unfortunately this won't work, as there is no way to construct an arbitrary bounded solid right now. You should not convert STL to entities (which is very inefficient anyway), but rather import it in a similar way as .slvs files with the "convert NURBS surfaces to triangle mesh" setting checked are imported.

@mattgleeson you can check the STL import and how it's done in https://github.com/NoteCAD/NoteCAD
just go notecad.xyz, click ImpSTL and you can do assemblies using this. Don't try to import too complex, because browser have limited memory.

@mattgleeson The simple way to start implemening this feature is copy-paste all the imported group functionality (link...assembly). There are all things - mesh loading in right place and entities generation. If you need any help, please, let me know. I can point a direction for how to implement this in a right way. But you should consider - this will work only in mesh boolean mode, so we have to force-switch-on this option

and after this group was imported there is no way to use NURBS backend

A good stand-alone tool would be one that reads an .stl file and creates NURBS and STEP files from it. I've given that some though and would say first, find coplanar points and edges. merge coplanar triangles that share edges into larger polygons with polygonal holes. This would reduce the geometry a lot. Next find points that lie on quadric surfaces and do the same type of internal edge elimination. Check for internal holes that are round. Finally, find points/edges that lie on two surfaces. Since many surfaces will have been found, these should be on original geometric intersections. Then define the surface patches and trim curves that have been discovered. This is high level and there are any number of special cases to consider to make it better. Make it a library and maybe SS could use it.

That would be a good tool, but as far as I know it's an extremely complex project to tackle if you want to get good results.

This is much complex than SolveSpace itself.

I also think this addition needs to be a priority. Interoperability is possibly the largest factor when people choose CAD software. Personally, I would prefer .step over .stl but I think whatever format allows for better tracking of geometry when the imported file changes, should be supported.

When wanting to design an enclosure for a PCB with various components which should be considered while designing, the ability to import a 3D model and design the enclosure around it is really valuable. I'm liking solvespace and think that this would be a huge feature to add.

@v01d Would IDF import be enough for you? There is a separate issue #625 for that. To me IDF is a much less difficult format to write code for, and more likely (not certain) to allow editing of whatever comes in.

IDF would get me the board itself, as KiCad supports that. But 3D models from components usually come from manufacturers who offer mostly STEP files (few times, STL). The juicy part is to model your enclosure considering components such as a usb connector protruding, switches, etc.
I don't expect editing the imported 3D model, but use it to create constraints for the enclosure (like snapping against some vertices).

There is GPLv3 code for reading STEP files as part of gcad3d. Looks like the reader is mostly in one big 12kLoC file here:
https://github.com/gcad3d/gcad3d/blob/master/src/exp/stp_r.c

The comments seem to be mixed english/german. I've not had time to really look at it to see how usable it would be for SolveSpace.

To me this was one of the first very basic problems I encountered when I started to look into the whole topic of 3D models. There are plenty of 3D models out there which are only available in STL (or in OBJ). Think of any use case where there's a file which came from sculpting, e.g. a human or animal head, and someone would like to put some parts, e.g. animatronics into it. Or a skeleton made from 3D scans, where one would like to combine the bones with some parts.

@someSven issue #724 is the same thing for stl and obj. I've got partly working STL import working on my import-mesh branch if you can build it and want to mess with experimental feature. It still needs better filtering of which verticies get solvespace point entities created. And OBJ might never happen.

(+1) for adding linking support for step files. When creating enclosures for a produced PCB, it would be really nice to be able to import the step file form the EDA (incl connectores and so on) into the CAD, to design a proper housing.

@trembel Since version 3.0 you can link IDF (.emn) circuit boards . The latest Edge builds will also show keep-out regions on the board as construction lines. If that is useful and you want to give feedback on it, use issue #625 to comment on it. IDF "part models" are not supported yet, and won't be unless I have evidence that people will actually use them. Step is a long way off if ever.