New Subdivision and Waterline
Randy sent me a photo of a toolpath showing a defect where the parallel finishing path would undercut when the path was almost but not quite right. I was able to fix it quickly but the fix led to a 25% increase in calculation time and I didn’t want to go backwards on that after all of the optimizing effort. I wrote a new subdivision method that eliminates the problem with a slight penalty in calculation time. After I spend time optimizing it I expect the get an overall speedup because it allows much more targeted and intelligent subdivision than the initial one.
In between that I’ve ben working on the new waterline code. It came together really quickly and is probably about 20% done already. It’s amazing how quickly you can crank out new code when you written half a dozen versions in the past. The new code is really good in the limited testing I’ve done so far. The stair stepping of the zmap is gone and, like the parallel finish, the precision is now defined completely by the tolerance value. It will still require a surface offset like the zmap offset but the time spent on each slice seems much faster even in debug mode which is much slower than a release build. Below is a photo of the output. The red arrow shows the types of bugs that can pop up that have to be tracked down.
Comments
11 Responses to “New Subdivision and Waterline”
Oh, I can see where this is going.
Jeff: Wow, Robert, build 7238 is really slow!
Robert: Yeah, tell me about it. Better yet, go tell Randy about it. Nah, 6628 wasn’t smoooooooooooth enough for him. [rolls eyes]
Jeff: Just let me go get my baseball bat. What’s Randy’s address again?
Randy: eek!
Best regards,
Randy
Seriously, Robert, that’s about 24 hours from me sending you the screenshots and model to you revamping the whole parallel finishing code. That’s pretty darn impressive. “In between that I’ve been working on the new waterline code.” We’re not worthy! (Well, at least I’m not…)
Best regards,
Randy
That’s why you and Jeff have to be kept on opposite ends of the country.
I think I’d be in trouble without the users like you guys who take things to the extreme since that’s where problem occur. The average user would never notice the type of things that we’ve been going back and forth about because they don’t usually have >500k triangles in a few square centimeters or zoom in on the toolpath to notice really tiny features.
Finally a comment on a real uses of 6628, maybe even before it’s replaced. Speed is quite reasonable and the tool paths seem much more accurate. I am seeing and milling artifacts from the .stl file, enough that I’ll either have to knock down my tolerance (.01mm) or increase the # of triangles. Robert, you have maybe out done your self this time… improvements which come back and bite. I used to only have to be half concerned about showing triangles, now I have to exercise a bit of paranoia at least until I understand the new numbers better.
Jeff
Are you seeing triangles from your STL in the output or are you seeing the little toolpath glitches that Randy pointed out? If it’s the glitches then the tolerance won’t help past a certain point- it’s a characteristic of the toolpath code and it’s been fixed in my not-yet-released- version. If you’re seeing triangles then I’m really impressed by your little Taig given how tiny your triangles usually end up being.
Robert,
Poor photo (blue wax confuses my camera), rhino render and shaded view showing triangles posted at
Same types of lines on the front side (2 sided milling, manually constructed tabs and border, your 2X wizard is nice but really can’t be expected to match a full blown 3d cad modeler)
3 files. Lines along long axis.
They aren’t too deep but when doing a wax for a customer this can give a bad first impression
I missed Randys glitch posts. But think that what I see in the wax rather too much matches the stuff I see when opening the .stl with rhino, not a glitch, just too much honesty following the .stl.
Jeff, my models are not nearly as detailed as yours, but I triangulate the heck out of them (typically .0001 tolerance and 1.1 degrees or so in the STL generating parameters) When I reimport the STL the surfaces are not visibly faceted at all–maybe it is a limitation on the rendering engine in Solidworks.
Robert, this observation is probably out of date by now, but I did an X-Y pass on the model I sent you with .005″ stepover of a .250″ ball-end mill and .001″ tolerance. I notice two things (I wish I were able to embed a screenshot in these blog entries, but then you’d probably get bad spamming too…) about the really zoomed-in CutViewer output–the irregularities in the X and Y toolpaths are not coordinated (the Y toolpath will land on the bottom plane sometimes two or three X passess outboards–it’s hard to explain without the screenshot), and the irregularities in the rendered surface are of larger scale than the stepover, which I interpret to mean that Meshcam’s evaluation of the surface is actually generating the irregularities. Or possibly it is an artifact of the CutViewer rendering, though the toolpaths themselves seem to be rendered with good fidelity.)
Best regards,
Randy
Randy,
It seems as though you triangulate even more than me. Good to hear from another tester of Roberts skills, glad that I’m not the only one trying to keep him awake :-). I suspect that the problems I saw were from not a fine enough triangulation (.01mm) but really don’t want to fight with Roberts attempts at reducing triangle density. I’ll try reducing the tolerance in meshcam, looking good is more important than absolute accuracy for my work.
Rhino does do some nasty things when meshing seemingly simple nurbs curves and surfaces. More research into how rhino generates meshes and how meshcam interpretates them is needed on my part. maybe everything works and I am just using the wrong numbers. Tomorrows project. (please excuse spelling, long day and I’m really tired of fighting spell checkers)
Jeff
Robert, I do promise that I will actually machine a few parts this weekend too, rather than just using an electron microscope on the Cutviewer output. My jaw will probably drop at seeing the physixal results, and I’ll probably feel really foolish about being so “anal”ytical about the toolpaths.
Jeff, I don’t know if it’s possible to “overtriangulate” but I’m sure that you are right in your observation that a balanced overall strategy would/will be productive. So far I’ve been of the mindset “finer is better” but that might indeed be a stumbling block for Robert’s new algorithms.
Best regards,
Randy
I suspect that many people are going to have to reevaluate their tolerance choices with the new code- especially given how many user have Sherlines or a non-rigid homemade machine. I’ve never found a polite way to tell people that their machines can’t hold the tolerance they’ve calculated (That’s not a commentary on Sherline - I’ve machined everything up to lenses on mine before so I’ve got little to complain about). I’ve used some higher end CAM programs and it’s surprising that many default to relatively high tolerance values. The calculation times shoot way up when you reduce that tolerance value.
Meshing is the only thing I’ve had trouble with in Rhino. I’ve had times where no matter what I do I can not get Rhino to generate more triangles. I haven’t played with that in V4 too much though.
I’ve got a Next Engine scanner that’s gone unused for a while. I need to fire it up and generate some really big STL files.
Robert,
Any hints about the amount of interpolation you are providing, it would make reducing my tolerance settings a little easier. I realise my past tolerance settings were way beyond reality but they didn’t cause a bothersome of an increase in time or file size.
Meshing in rhino4 is the only way I’ve managed to crash it, I suspect the default settings are too fine. Probably something to do with the memory limits for a single process in XP. I still have to investigate the settings but for now I just save as ver2 and use it to mesh. One hard learned trick with ver2 to increase # of triangles is to increase the point count and degree of the original nurb lines and surfaces. Some improvement but for real results an even slightly 3D surface yields many more triangles… quick test with an 80 mm disk VS one with a .003mm ‘dome’, max 472 vs 7224 polygons (quads), ver4 will triangulate this mesh to 14590 triangles.
Jeff