How to replicate STL conversion workflow using API

[Anonymous]

Maybe this has been asked and answered before but I did not see it, so...

I am working a lot with imported meshes. 

for a quick summary of the types of things I am trying to do, 

you can see some messages here: http://forums.autodesk.com/t5/design-validate-document/stl-file-import-for-sculpting-edit/td-p/59713...

my biggest pain point is the 10k face limit on imported meshes.

I am wondering if there is a way to automate my way around it using the API,

possibly in conjunction with some other python packages.

This is all going to sound ignorant as heck, 

so please be gentle with me.

My theory is that if I could in an automated way slice the source mesh into incredbly small subsets,

I could import and convert these in a way which would preserve much more of the original geometry than I am accomplishing today.

As a manual process this seems tedious bordering on impossible: I wonder if I can make the computer do it in an automated way to accomplish this goal?

I am assuming here that the upcoming mesh workspace will be available, as defined by @colin.smith in http://forums.autodesk.com/t5/design-validate-document/imported-mesh-models/td-p/6254510

Colin presented this diagram:

However, he also said that the 10k limit would not be dealt with in the intial release. 

my questi0n is whether the API could help.

specifically, I wonder if I can automate a workflow to:

in a loop

     read a mesh and arbitrarily slice it (possibly using an external tool like numpy-stl or something like that),

     import the slice, retaining positional information;

     convert the mesh from triangles to quads, and then to BREP
then select all of the BREPS

and merge them back into a whole body

I have taken an initial look at the API as documented

I noted that

 - there does not seem to be an STLImport, although there is an STLExport

 - there also doesn't appear to be an obvious way to convert a quad mesh to a BREP

I'm probably just not looking in the right place, and the mesh workspace has not been published yet.

so looking for feedback here: 

 - if you were trying to accomplish the goal of preserving as much detail in an origin STL as possible

and you had Python and the API as a tool to do that with,

is that how you would accomplish that goal, 

or would you do it a different way? 

for instance, could you read the original stl, take the point cloud from it, and somehow write it directly into the model as BREP surfaces? 

 - Are all the API calls required available, 

or are some still in backlog?

 - is the whole idea in your opinion feasible or infeasible given what is available today? if infeasible, when in the roadmap does feasibility arrive?

any help and comments welcomed. 

thanks!

/malcolm

[marshaltu]

Hello,

Unfortunately current API doesn't support full workflow you mentioned. I would like to suggest log your requirements to our ideastation.

In addition, we do have API to support "import" stl or obj to a design. Please refer to the following sample codes:

#Author-
#Description-

import adsk.core, adsk.fusion, adsk.cam, traceback

def run(context):
    ui = None
    try:
        app = adsk.core.Application.get()
        ui  = app.userInterface
        
        design = adsk.fusion.Design.cast(app.activeProduct)
        design.rootComponent.meshBodies.add('/Users/tum/Downloads/top test.stl', adsk.fusion.MeshUnits.CentimeterMeshUnit)

    except:
        if ui:
            ui.messageBox('Failed:\n{}'.format(traceback.format_exc()))

Thanks,

Marshal

[ekinsb]

Mesh to surface conversion is a hard problem and something that continues to be worked on in the industry.  Software that focuses specifically on this task has typically been fairly expensive and is not fully automatic.

Regarding your suggestion of splitting up the mesh into small pieces, that would solve the problem of having a smaller mesh that can be converted into a surface.  However, the surface patches will not necessarily connect.  There are likely to be gaps and the connections may not be smooth.

[Anonymous]

---

@ekinsb wrote:

Mesh to surface conversion is a hard problem and something that continues to be worked on in the industry.  Software that focuses specifically on this task has typically been fairly expensive and is not fully automatic.

Regarding your suggestion of splitting up the mesh into small pieces, that would solve the problem of having a smaller mesh that can be converted into a surface.  However, the surface patches will not necessarily connect.  There are likely to be gaps and the connections may not be smooth.

---

would the gaps depend on the size of the surface patches used?

lets say there were gaps. if we left them in p[lace, and did not join them, 

could we still use the resulting surface to generate a cam toolpath?

lets use a concrete example, so we are on the same page about goals.

so for instance, lets say I am working on this guy:

(he is at http://www.123dapp.com/catch/homer/5232175if you want to look at him more closely)

today if I run his mesh through meshmixer and memento I drop ~98%+ of the resolution in the image, 

and when I render it using my x-carve I get something that looks like this: 

it is this de-resolutioning to a low-poly image I am trying to address.

the rendering resolution of this is approximately 0.25-0.33mm: those are the usual sorts of step-over values for the ball mill I am using on the x-carve.

So what if I sliced the .stl into thousands of segments which were a fraction of that resolution, say .05mm - .10mm thick? 

If when stitched or rejoined the joins were imperfect, the resolution of the render would mask a lot of it, and you could possibly just sand out the rest...

You could never manage that many slices manually, but with automation and the right API calls it **might** be possible process the image in this way:

position the image, slice it finely, convert each slice in place, join the slices or just select them all, and merge them into a single body.

I know this is out of box thinking on an out of box sort of project type,

but still wondering if this approach might work if we execute it the right way...

[Anonymous]

this code is very helpful: thank you for posting it...

[ekinsb]

The reason for you current loss of accuracy is because of the step of using MeshMixer to reduce the mesh in size.  It's not a MeshMixer issue, it actually does a great job, it's just to get down to 10K you have to lose some detail.  The simplest way to break up the model will be in sections along a defined axis.  In this case, say the axis runs up through the head, so you would have a series of somewhat cylindrical sections starting with on at the neck and moving up.  For each of these sections you would still be limited to 10K but you can make the sections as small as needed to get the accuracy you want.  A program could be written that would read in either an existing mesh or an STL file and then create several meshes where each one represents one of these slices.  This would all be logic in the program itself.  There's nothing in the API that can help with this.  Once you have the smaller mesh, you can then use the API to create a new mesh body of the small mesh.  Conversion to a smooth surface is not currently supported by the API so you would still have to do that manually.

When I said earlier that the pieces probably won't line up, I was talking about where each of these "cylindrical" meshes should connect to each other.  There's certain to be some gaps which means you won't be able to convert it to a solid.

I'm suggesting a possible workflow, but I'm not saying that it will necessarily work or provide decent results. It would have to be tried to see how it does work.  As I said before, it's a hard problem and people have invested many millions trying to solve it.

[hanskellner]

That's the process I've used with MeshMixer and the Edit->Make Slices tool (see below).  Once I generate the slices I'm able to export them then import into Fusion.  Their relative positions remain correct and they align with no gaps.

[Anonymous]

---

@hanskellner wrote:

That's the process I've used with MeshMixer and the Edit->Make Slices tool (see below).  Once I generate the slices I'm able to export them then import into Fusion.  Their relative positions remain correct and they align with no gaps.

---

Right! I think a version of this workflow could really help me get where I want to go. 

The question is, can I automate it within Fusion, especially once all of the discreet workflow steps are available inside the mesh workspace? 
That might allow me to do MANY more slices, perform the slicing within the same workspace, and eliminate all of the exporting/importing from one application to the next...

One question: I have been editing the meshes in meshmixer, then importing them into memento to do the conversion from tri/.stl to quad/.obj.

Are you doing the conversion to quad/.obj inside meshmixer as well? I honestly didn;t realize you could do that... 

[hanskellner]

Yes, I'm exporting each slice to OBJ within meshmixer.  After slicing the object, select each slice in the Object Browser, then File->Export.  Only the selected slice will be exported.  A bit of a pain to do this for each slice but it works.  It's possible this process could be automated through the scripting API:

http://meshmixer.com/forum/index.php?topic=1889.0

Cheers,

Hans

[Anonymous]

Feeling wary of that API:

the github looks like it hasn't been updated in a long time,

and the other indications are that the functionality will be embedded into the mesh workspace.

definitely aiming to use an API to try to automate this,

but think I will wait until the mesh workspace is released and then look to see what API is supported... 

[ekinsb]

To set your expectations; there won't be any API support for the mesh workspace when it is first released.  It will probably be a while after that before something is exposed.  It's usually best to let the dust settle a bit on new functionality before exposing an API for it.  It's ok to change commands but it's not ok to change the API and break existing programs.

[Anonymous]

Good to know, and seems reasonable enough...

do you have a usual cadence for the latency between release and API support,

or does it just depend? 

[ekinsb]

It depends on how we prioritize this functionality and then what else is still missing from the API that has a higher priority.  It depends on how difficult the API is to design and implement compared to other API work.  It depends on which team will be doing the actual implementation and what else they have on their plate.  It depends on what other changes are expected in that area and if they would impact the API.  And probably several other things can impact when things get done.

[Anonymous]

---

@ekinsb wrote:

It depends on how we prioritize this functionality and then what else is still missing from the API that has a higher priority.  It depends on how difficult the API is to design and implement compared to other API work.  It depends on which team will be doing the actual implementation and what else they have on their plate.  It depends on what other changes are expected in that area and if they would impact the API.  And probably several other things can impact when things get done.

---

so it is just like the rest of my life, is what you are saying...:-)

[The3rdIcon]

@hanskellner & @Anonymous, do you remember the version of meshmixer shown here? I found the Make Slice feature was remove but I don't know which version that happened in. Have you found another software that allow you to make all these cuts at once. 

[OceanHydroAU]

I've thought a lot about this - I would solve it with "particle swarms" - but it's a huge amount of compute power needed.

Basically - you pick any arbitrary starting point on the mesh, and then "randomly" try to fit known shapes on to it (spheres, cubes, cylinders, etc, at all different sizes and angles) using "gradient descent" to work out the optimal match.

You then "Remove" all the mesh bits that matched within your required tolerance (in 2D, I'm finding that 0.1% is a great threshold for that), and repeat the above, until there is no mesh left.

For the brep case - same idea, except you pick points instead of shapes, and "wiggle them around" until the shape "takes out" a required threshold number of mesh elements within your tolerance.

The "perfect" solution is of course both of the above, since it would (in theory) generate a fully parametric-able output of all the "base shapes" that might be present, and "tidy up" all the leftovers with splines.  Obviously - that's way more suited to engineering-based STL files, rather than 3D biological scans, but it would work with both (eyeballs, for example, should always match nicely)

Here's an example in 2D instead of 3D - I'm "wiggling" 3 points at once https://www.youtube.com/watch?v=_mmeQpILpUI - this same code serves 2 purposes for me - finding optimal airfoils (the video, and not relevant to you) and finding the optimal set of 17 spline points that most-perfectly match any arbitrary input shape (in my case - any legacy airfoil that anyone has drawn) - so basically - take my idea, add another dimension (easy, but CPU intensive!), and wait...

[OceanHydroAU]

Quick question, since this isn't my field: since you know the ball-mill you want to use, is there not software out there which can take a high-res STL, and the finishing ball-mill size you want, and eradicate all the pointless detail that isn't needed?

That sounds like a pretty simple algorithm - any decent final-year uni student should be able to knock that out in about a week I'd guess?  You can sometime get lecturers to assign stuff like this to students if you want the answer for free btw.

[hanskellner]

@The3rdIcon I just installed the current version of Meshmixer (Windows) and it still contains the slice functionality.

Also, you may find this article helpful as it describes various steps for slicing:
https://blog.prusaprinters.org/cut-stl-models-3d-printing-meshmixer_7652/

@OceanHydroAU One way to do what you are suggestion is to use the mesh decimation feature that some apps provide.  For example, Maya has the ability to decimate a mesh.  This act of decimating reducing the face count of the mesh but at the risk of losing detail.  Depending on the resolution of the final physical form, decimating to a specific level might not impact the final shape.  Although this will require some trial-and-error to know how much to decimate.

[OceanHydroAU]

@hanskellner yeah - I was just thinking out loud... if you know the dimensions of the finishing bit, it's possible to do lossless "decimation" (thanks for the word!) because you only discard the unnecessary resolution.  My guess, since it's mathematically intensive, is that existing implementations probably are "trivial" and do not take "fine feature preservation" into account - e.g. it's WAY easier to reduce 27 triangles down to 8 triangles (3^3 down to 2^3) than it is to work out which ones might be significant to the shape and remove the others...

[hanskellner]

@OceanHydroAU Yes, there are a lot of trivial decimation implementations.  The very nice implementations take into account detailed areas, edges, etc. and change the decimation level for those sections.