RhinoCAM also has no problem with this, it’s actually a file I have already machined a couple of years ago…
It’s actually one of the smaller files I have, I’ve done much larger.
–Mitch
Ok, then I didn’t understand your question…
I see now that you were talking about Fusion. They would need quad meshes to begin with…
Just trying to see if Fusion would do what I need… as it’s free here. But it doesn’t. However for more conventional machining tasks using surface models, it might be OK. --Mitch
Edit:
Hmm, this is in fact a quad mesh generated from an ASCII Grid file, but exporting it as .stl triangulated it. How would I get a 1m poly quad mesh into fusion from Rhino ?
A bit difficult to figure out, you will have to admit :o).
I have converted very dense quad meshes to surfaces recently…
Don’t use .stl but load the mesh as an .obj to fusion. Make sure that the create Ngon option in Rhino’s exporter is off.
You are doing it wrong.
As I said before – the program doesn’t support milling from meshes. You need to load the mesh into the Sculpt workspace (by using the Insert Menu Item in the middle of the screen). Inside that workspace you can convert the model to Tsplines. If you then switch to the CAM workspace the Tsplines model automatically gets converted to surface data.
If it turns out that one million faces bogs down Fusion/ your machine, there would still be options left to reduce the input polygon count in a way that a cage with a far lower point count wants to convert to a limit surface which equals your source mesh. But this would need to happen inside mesh modeling software.
Hi Holger, could I have that file? I’d love to try to see how it works in F360 and Onshape. Thx!
G
You’ll find the Thai Statue here:
http://graphics.stanford.edu/data/3Dscanrep/
OK, thanks for the detailed procedure.
Yep, exactly how it turns out… It hangs on the conversion to T-Splines, been running for a half hour now and no end in sight, so I’m killing it. So, it’s not ready for prime-time as concerns mesh milling. Probably happen sooner or later, I just wonder why they haven’t adapted something from ArtCAM in that department yet.
–Mitch
[quote=“Helvetosaur, post:91, topic:37603”]
Yep, exactly how it turns out… It hangs on the conversion to T-Splines, been running for a half hour now and no end in sight, so I’m killing it.[/quote]
Yeah, that’s no surprise.
With quite a bit of mesh based preprocessing one probably could make this model convert to surfaces but…
With stuff as complex as your scan of the alps (or the Thai statuette I posted) I simply fail to see the point for converting to surface data just for milling. It’s always a lossy process – and even if one wanted to later perforate the alps with accurate 10 cm holes and 2cm fillets one could do this with sufficient accuracy on mesh data.
And as Bob states : The first thing the CAM program does is triangulating your precious surfaces.
In extreme cases this would mean using a very complex process to create a quad mesh from triangulated data, which then gets converted to surfaces, only to get meshed again for milling.
Still @gustojunk, if you want to try this out, here’s the quadrangulated version of the statuette you would need as input in Fusion.
Yep. So the whole conversion of a mesh to T-Splines to Breps to mesh again is totally ridiculous in this case. And on top of that not all our terrain meshes are quad-based, only those created from grid files. Others are amorphous triangles, so no possibility anyway.
–Mitch
And even they would be of limited use for SubD. To be useful for subdivision modeling one needs a particular mesh topology, having only rectangles is not good enough. Your scan is likely a dense even grid, right?
Are those not contradicting statements for such a model?
Reducing the polygon count will reduce/loose information, I doubt the surfacing will be able to convey that detail back in some magical way.
-Willem
You are right Willem,
and there were sure many (smoother) models where my suggestion worked a great lot better.
As with dense curves or surfaces one can often take away a lot of points in bulged areas
of meshes and can still recreate the original shape.Jagged shapes (again like Nurbs)
need a lot of points though.
If one badly wanted to have surface data from Mitchs scan one needed to create a subdivision optimized
cage first – it would in this case consist of rings of quads which look quite similar to a topology map.
What one would try is making quad faces small where rocks are pointed and jaggy and make them larger
in somewhat flatter areas.
Finally as the limit surface usually looks quite different from a mesh which only got subdivided a few
times one can use some tricks to move the cage point locations to yield the desired appearance.
Blender has great tools for that.
I’d still say that for models like these it was a waste to invest time for Nurbs-conversion.
Meshes are brilliant for holding lots of intricate detail, one can mill them, case closed. :o)
1 Like
That statement is not correct. The mesh the CAM system creates depends on the machining parameters that the user inputs so converting to mesh is hardly the first thing it does. You are implying that there is no advantage in having the surface geometry. If that were true most of the expensive CAM systems would be just importing meshes. They are not for good reason.
It may be true that the toolpaths are almost always mapped to a mesh but that mesh represents where the center of the tool is in space. The mesh the CAM system is using doesn’t represent the surfaces that are being machined. It is a completely different size and shape from the geometry it was derived from.
Regardless of whether it starts with surface data or mesh data the CAM system has to create a new mesh that the toolpath can be mapped to. In general it can do that more accurately and more efficiently with more options for cutting strategy if the CAM system has started with surface data.
jim,
I agree that it’s greatly preferable to feed in surface data – in case one has them.
Having surface data may also be helpful in so far as one is able to extract curves or surfaces as helper geometry for certain machining operations.
Mitch and I were discussing quite an obscure constellation here.
Creating surface data from extremely complex mesh topology, solely in order to make them compatible for toolpath generation inside Autodesk Fusion (which can’t create toolpaths from meshes). We agreed that it’s smarter to use a CAM program, which handles meshes.
Yes. It is interesting to note why meshes are being used here. The desired surface needs to be offset normal to itself a distance equal to the radius of the cutter. And the fact is, that even in the best of surface modeling programs, offsetting arbitrary complex surface geometry (composed of joined trimmed surfaces, fillets, holes, etc.) is not all that reliable. Offsetting a mesh is far more reliable, it’s a lot easier to detect and remove mesh self-intersections and the like in corners too small for the cutter radius to get into for example.
Now, whether this offset mesh is created directly from the original surface, or whether a surface conformal mesh is first created and then that is offset - I have no idea. Few if any CAM programs want to tell you how their insides actually work…
–Mitch
No actually that is backwards. Creating a set of points in 3d space that are offset from NURBS surfaces that aren’t degenerate is fairly trivial and reliable. With NURBS you have more options for how that sampling occurs in terms of distribution and organization of the points… It may be true that creating new water tight NURBS geometry from the sampled data could be tricky but that’s not what needs to be done. The question of removing areas that will gouge ( where the mesh is self-intersecting) it seems to me, is going to be the same regardless of how the sample points were created.
Yes, but you’re offsetting sample points and not surfaces. Which is pretty similar to creating a mesh and not at all similar to offsetting the surfaces themselves.
–Mitch