Max number of anchor points in a vector file?

I’ve got a 149KB SVG file with 8500 points, the vast majority of which occur in a background pattern of filled vector circles which I would like to engrave. File seems to generally upload ok but I’m having varying success when it comes to getting it to render in the GFUI – worked a couple of times last night, not at all today.

I have tried rasterizing the background pattern and that seems to solve the rendering issue, but I am not happy with the engrave results I am getting for the rasterized dots – on PG Maple Ply, SD Engrave cuts through the paper but makes no mark on the wood, and HD engrave takes 2x the time and barely marks the wood.

I want to try engraving the pattern without rasterizing it to see if I can get the look I’m after, but every time I’ve tried uploading and rendering the full-vector SVG, the rendering screen hangs and then ultimately gives me an error message from the browser – in Safari (which I know is not preferred around here but has been working just fine for me thus far), it reloads the page because of an unspecified error, and in Chrome I get a “page unresponsive” pop-up.

A little digging around the forum suggests that 8500 points is probably on the high end but not the max number people have been able to successfully render and cut. I haven’t been able to find info about an upper limit of points – is there one? I can solve this particular problem by changing my background design to something simpler, but I am curious whether there’s a known point quantity at which vector rendering fails so I can work around it in future.

It’s a combination of factors, I believe. Not just the number of nodes, but how close they are, total number of paths, whether the pathing? pathways? is/are actually clean, etc.

Is there potentially something amiss with the vector file? Or, some extraneous points that could be cleaned up? I’d be happy to look if you wanted to post or PM the file.


Not sure if it will work in your case, but sometimes just putting a box around the entire graphic (in your vector editing program) will fix stuff. (make it a unique color and just set it to Ignore in the GFUI)

As far as number of anchor points… the Aztec Sunstone vector that I found a while back (and have printed successfully several times) has 22,771 anchor points.


What if you sent a PDF to the GFUI instead of an SVG?

1 Like

Then you generally get annoying clipping paths too that will generate a warning/error every time you render in the GFUI.

^^^^ is probably the best suggestion at this point. FWIW it is what the support team would suggest if this were in the problems category with a “try it and see” note attached.

1 Like

Why would you be getting clipping paths? I mean I know you get can get weird things from printing to PDF but @reliablepants is an Illustrator user, she can save as Illustrator PDF which wouldn’t add any odd clipping paths.


You’re right. Thanks.

I just tried some of the recent PDF files I generated from Illustrator and no issues with the latest ones.

1 Like

Thanks for all the suggestions! Adding a box in an ignorable color solved the rendering problem and I just finished cutting out my design. As I hoped, the vector engrave looks much better than the rasterized version did, so I’m happy to have a solution.

Drawing a box struck me as sort of a weird workaround but I could see how providing some sort of container for a design that has a lot of separate parts could be useful for the browser’s SVG renderer. Thinking about it that way, I double-checked the outer cut path of my design and lo, it was an intersecting (looks fine, cuts fine) set of open (lets things spill out into infinity and never ever render) paths. Closing that outer path solved the rendering problem as effectively as adding the box and lets me avoid having to actually add a box that I will inevitably at some point forget to ignore.

So! My current working theory: close my outer path when my design has one; draw a bounding box in an ignorable color when design has lots of pieces but no natural border. Oh, and here’s the silly little textured-background keychain that caused all the drama:


I’m glad @jbv’s suggestion got you on the right path!

One thing that might work also, as far as the bitmap engraving goes. You might consider using one of the vary power settings instead of dither, if all of the dots are the same colors as I suspect they might be? The dither will, well… dither, to try and make up the tonality. But, the vary power won’t perform dithering - it will give consistent power across the same shade. Does that make sense? If these were all black dots, then the laser would basically give whatever power you assigned as max power without trying to perform the dithering process to approximate the tonality.


Yes, that vary power explanation makes perfect sense, thanks. Trying to solve today’s rendering problem was actually the first time I’d ever engraved a rasterized image and it didn’t even occur to me that I would need to tweak the settings…and possibly not have the dots be lime green. :roll_eyes: That’s what I get for being a one-trick Illustrator pony!

1 Like

That’s great and the silly background is what makes it.

1 Like