OBJ and STL files are the worst possible files to use in an assembly in any cad software.

STL and OBJ files contain no BREP or NURBS surfaces. Its just a pile of triangles with out any useful information behind them. For example. You could never have a truly round hole in an STL or OBJ as the intelligence behind the operation is lost when it it turned in to a dumb mesh. You would also have great difficulty in making constrains also. If there was any file format that solvespace should import it would be STEP. At least you have real geometry to work with there.

It would be really cool to be able to edit STL files in Solvespace. In my experience 3D laser scanners add some background bits and pieces around the object you are scanning which have to be edited out before you could print the object out on a 3D printer for example. I'm sure there are some other things you could do but this would involve more than just linking the STL file.

I would love to work on this but my experience with C++ is not complete enough yet to make a good stab at it. Hopefully sometime though.

@mmiscool Yes, importing or linking STEP is another open issue - number 88, very old wish.
@kk6mrp No, you're never going to edit STL in SolveSpace - at least not like a mesh-based editor.

What I think would be possible is the following:

1. As a viewer for objects in these formats - including views like showing occluded lines.
2. You could take measurements on meshes or make assemblies from them - including interference checks.
3. You could build on them using all the usual SS construction tools.
4. Cut up existing STL objects and assemble them in different ways including adding new stuff in SolveSpace.

I think there are some valid use cases. It's also practice for more difficult things.

@Evil-Spirit I know you were interested in this before, and @ruevs might be able to help with red mesh. I've got the ability to Link and STL file here: phkahler@af9df3d

But there are two issue:

1. The mesh is red and booleans get messed up. I've tried flipping normals and/or reordering verticies with no luck.
2. A vertex should only be created once - they are repeated many times is STL too many of them kill performance and we have a hard limit of 64K of them (limit to 5000 is patch)

I think also for 2 a vertex/point entity should only be created at somewhat sharp edges. I wonder if the edge classifier used for rendering (not booleans) could find edges where say N1.dot(N2) < 0.5 or something and only use verticies from those edges for Entities?

This was supposed to be an easy thing to do but it seems not.

BTW you can readily sketch lines and construct new geometry on the verticies - cool. But still broken until those 2 issues get resolved.

Good thing to have. If even no round holes will be supported, this feature allow to edit some existent models in stl format. e.g. make hole bigger, adjust some dimensions to fit, etc. Also, it can be used for reverse engineering. I have such thing in NoteCAD - you can import STL models and then perform some operations

The color problems were due to uninitialized alpha = 0 making them transparent (but not the red back side).
Works OK here: https://github.com/phkahler/solvespace/tree/import-mesh
But I still need to eliminate redundant verticies and also filter them down to just the ones on edges.

But I still need to eliminate redundant verticies and also filter them down to just the ones on edges.

Hi, I am new to SS, interested in importing FEA mesh into it. See: https://www.reddit.com/r/SolveSpace/comments/kbj4fi/trying_to_add_the_ability_to_import_a_mesh/

I tested this branch. For uniqueness check, I am thinking something like this:

// check if a vertex is unique and add it via newPoint if it is.
static void addVertexIfUnique(float x, float y, float z, EntityList *el) {
    
    //uniqueness check
    int isNew=1;
    for(unsigned int i=0;i<el->n;i++)
    {
        if (x==el[i].actPoint.x and y==el[i].actPoint.y and z==el[i].actPoint.z ) {   
            isNew=0;
            break;
        }    
    }
    
    if (isNew==1) {
        int id = el->n+2;
        newPoint(el, &id, Vector::From(x,y,z));
    }    
}

Is el[i].actPoint.x right? How to get the x, y and z from the el list?

@ceanwang Hello and welcome! My STL import (actually linking which is different) commit is here:
phkahler@06bcfb6

You might want to open an issue (feature request) for your FEA import, so we can discuss it there. I'm not sure you need the entity creation stuff I was aiming for with STL files.

First a little about STL:

I think it's el[i]->actPoint.x but I'm not sure. I was also planning to filter the points first, so just storing them in a (stl) vector of Vector would be fine, and then decide which ones to make entities from and calling newPoint().

If you try an STL import, that code does load the entire mesh. The reason for adding vertex entities is strictly so people can construct additional geometry or modify what's there using booleans with new geometry. For that, I wanted to filter verticies to only ones on sharp edges - for some definition of sharp edge - so we don't overload SS with too many entities.

What are your goals? If it's simply to view an FEA mesh, just follow the STL patch (or add to it) and write code to read your triangles - surface triangles only? - and don't bother with vertexes. If you want to do more than that, definitely open a separate issue to discuss it. It is slightly awkward to "open" a file for viewing by linking it as an assembly because SS isn't really a mesh editor.

Vertex is not a must. Cool.

I am trying to understand the difference between link and import. I'll try open a stl file under Open and under Import.

This code working.

    Entity tEn={};

    int isNew=1;
    for(int i=0;i<el->n;i++)
    {
	tEn=el->Get(i);
        if (x== tEn.actPoint.x && y== tEn.actPoint.y && z== tEn.actPoint.z ) {
            isNew=0;
            break;
        }    
    }

@ceanwang A solvespace sketch/model is created by a series of "requests". A request creates something, weather that's a sketch entity (line, circle, point, etc...), a new group (extrusion, or a new sketch-in-plane), and so on. Basically the things a user can do through the GUI. Proper "import" of a foreign file format would basically convert that into something that looked like the user created it in SolveSpace and it would be editable. The DXF import creates actual solvespace entities for example.

Linking a file is normally used to create assemblies. In that case, an entire model is brought in as a single object that can be oriented inside an existing SolveSpace sketch. Until recently linked files had to be SolveSpace .slvs files, but even then you can't edit them from inside the assembly, you have to go open the original file. For linking, no requests are created showing the construction history. Just some entities are copied in and the shell or mesh. Which brings us to Shells and Meshes...

When you're modeling in SolveSpace construction usually follows a series of alternating groups. First a 2D sketch group, and then a group that creates a "solid" model. Then another sketch, and then another solid. The successive solids are always combined with a boolean operation with union being the default. I use the term "solid" but in reality it's just a Shell - a set of surfaces that form a closed shell. Each new group is created as a set of NURBS surfaces to represent the shell. The boolean operations also create a new combined NURBS shell. We also have the option to convert a group to "mesh" which make a triangle mesh and combines that with a triangle mesh of the previous group. Once you do that, every group will be converted and combined as a triangle mesh.

So to import STL or other meshes, I was just going to import the triangles via a linking of the external file. No requests are created and the mesh is in no way editable. But you will be able to make new 2d sketches and combine the included mesh with new solids, it will just have to be done with meshes and not NURBS shells.

I hope that helps clarify how different it is to Link a mesh vs importing something as a fully editable SolveSpace sketch/model. I'm not sure how useful that is for FEA, but it should allow viewing a colored mesh. Or not? I don't think we have a color per vertex, only per triangle?

ATM, I am not considering editable. Mesh as one whole object is good enough for me. Otherwise, It will be too big and too slow.

Mesh as one whole object is good enough for me.

I'm agree on this — just import 3D mesh (with 1/single point according mesh 0,0,0 position & X, Y, Z normals at this point) in same way as SolveSpace "Link/Assembly..." used for linking external SLVS files.

just import 3D mesh (with 1/single point according mesh 0,0,0 position & X, Y, Z normals at this point) in same way as SolveSpace "Link/Assembly...

The origin vertex and normal are added in the IDF importer / linker. That code is kind of a mess but it works. I plan to clean it up when I get around to including the part definitions.... some day. I was also thinking about adding that for linked STL.

It should allow viewing a colored mesh. Or not? I don't think we have a color per vertex, only per triangle?

I can link a mesh now. See: https://www.reddit.com/r/SolveSpace/comments/kcx061/link_mesh_from_file/

How to add an Edge? Is it has color? Beside STriangle, is there a SRectangle, so I could add rectangle cell.

I see your filter with only vertex on edge could be used to build solid from a mesh.

I can link a mesh now. See: https://www.reddit.com/r/SolveSpace/comments/kcx061/link_mesh_from_file/

Good job!

How to add an Edge? Is it has color? Beside STriangle, is there a SRectangle, so I could add rectangle cell.

Not really? There are no edges associated with a triangle mesh. There are sketch entities which includes lines, but they are fed into the solver. Putting entities over all the triangle edges will destroy performance. There is no SRectangle either.

I see your filter with only vertex on edge could be used to build solid from a mesh.

There are no solids, only NURBS SShelll and triangle mesh SMesh.

@ceanwang What exactly are you trying to use SolveSpace for?

I just test it to see if it could be used for FEA pre and post processing.

@ceanwang Your suggestion has given me an idea for a progression for integrating some FEA features into SolveSpace. I'll open an issue covering this after I hear back from the Gmsh folks. How is your linking going? I don't see anything on your fork.

@ceanwang Your suggestion has given me an idea for a progression for integrating some FEA features into SolveSpace. I'll open an issue covering this after I hear back from the Gmsh folks. How is your linking going? I don't see anything on your fork.

Linking a case file is all good. Then tried to link a result file. First the mesh is good, but after I added the displacement and update the mesh with the displacement, the program crashed. It happened after my linkresult call.
I also thought about gmsh. I am trying to export a Gmsh's geo file which is copied from the Save call. The geometry could be saved there in Gmsh's geo file, but I was wondering how do I define the boundary condition. Take the Line entity as an example, I want to give that line a BC like temperature at 25 degree. SS only has style now.
When I got the GEO file, I could use a system shell call to run gmsh to mesh. There need a gmsh setting. I can link gmsh's msh file back, but have to convert it into my solver's format which is Nastran95.
https://discord.gg/SY7TtDm

https://discord.gg/SY7TtDm

JFTR, @ceanwang, if possible, do not share links to Discord for sample files - attach them directly to comment on GitHub.

Or, at least, use public file sharing services, like http://0x0.st

This is landing in edge builds soon. Dropping the OBJ format though as STL is enough for now.

This is landing in edge builds soon.

Awesome! Thanks!