I’m not sure if I provided a link to the simple code I wrote to place the modules around a circle…
I have not re-visited the code since the last time I used it - you know how it goes, out of sight, out of mind but it works pretty well at the moment and is an upgrade from the previous version which used a hard-coded array list in which I set the positions and orientation from an Excel spreadsheet.
An SMD pad is the only thing that would give you a circular copper fill. The reason KiCad doesn’t do a circular fill is that the fill regions are defined by a polygon. I would prefer to use a “closed loop” to describe the region and that loop can be any number of shaped segments joined end-to-end; a circle would be a case of a single segment defining a closed loop. The next best thing it to at least model the region like DXF’s “PolyLine” which is essentially a loop consisting of arcs and line segments; in that case a circle can be modeled with two arcs. Unfortunately it’s a pretty big task to make those modifications and to ensure that the Gerbers come out right.
On that subject… I don’t know if it would solve anything - approximation by straight segments is pretty good - but I would propose an adaptive method.
One can define number of segments per 360deg at the moment… choices are 16 and 32.
For small radii this is sufficient, but for large radii the segments become visible and in the case of large circular outlines the difference between the arcs for the outline and the finite segments for the zone edge becomes pretty obvious.
Is there a cheap and fast way to define a max length for segments and the algorithm then just adds more to a large radius approximation while it is creating the zone outline? So instead of the one-and-all solution 16/32 that is used everywhere it would increase the segment count for larger radii when segment lengths go over a certain threshold (until they are under the threshold again)?
I can help myself by creating me a zone outline via script that uses a higher number of segments for the loop, so I can deal with it, no problem - just thought I share the idea in case it’s a low hanging fruit:
No arcs etc. needed, no risk for gerber creation, ‘just’ modify the segment creation algorithm to adjust the 16/32 setting on the fly to whatever is needed to stay with the segment length under a (user settable?) threshold.
In part the problem is due to various poor assumptions and dubious sharing of code. No one would ever want more than 32 segments to describe a circle, would they? A better test in most cases is to impose a maximum deviation from the arc/circle, and there are a few calculations like that in various places in the code. The actual requirements for different uses of similar code can vary quite a bit. For example, modeling a 5cm diameter circular board using 32 straight segments is definitely not acceptable; however for 3D visual modeling it’s probably fine in many situations unless you have features near the board edge.
I’m sure we can fix a lot of these issues by changing the various bits of code which do these calculations so that it’s all done consistently and in such a way that some code such as the 3D visualization which can quite happily trade off precision can easily override parameters. Unfortunately there are quite a few places in code which would require some change, but if anyone has the time it can certainly be done without too great a hassle.
I’m trying to have circular boards+mouse bites+internal cuts without having the 3D viewer complaining about non-contiguous polygons. Has anyone succeeded on placing the mouse bites (i.e https://github.com/madworm/Panelization.pretty) while having Edge.Cuts not being perfectly aligned for each segment?
I’ve tried drawing a circle in the middle and adding the mousebites later, but then the middle board is gone and I’m left with castellated mouse bites.
Then I tried drawing partial arcs in the center, interspersed with mouse bites every few degrees, but then the 3D viewer complains 
Any good hints? Thanks for this interesting thread!
For complicated pcb outlines you need a CAD tool that can export DXF that is understood by KiCAD.
I wouldn’t try to do any panels/sub-boards other than rectangular ones with KiCAD really.
Thanks for the feedback, @Joan_Sparky ! I did a small OpenSCAD sketch of what I want to achieve:
And I successfully imported the resulting DXF to KiCad, adding four mouse bites footprints on the inner circle:
But the 3D viewer keeps complaining, more or less as before regarding Edge.Cuts interior graphics error as shown before
Any hints on how to please the 3D viewer are super welcome!
Woah, thanks @Joan_Sparky to actually take the time to create that .dxf O_o!
Unfortunately, after clearing all my imported Edge.Cuts from the OpenSCAD .dxf and including yours, the error persists:
The offending spot is around this area, right near the mousebites lower hole, but I suspect that this is a more general issue since I cannot see any obvious mistake here:
When I dealt with this type of error in the past with simpler boards it was always a case of Edge.Cuts lines not closing/overlapping properly… since this is a continuous generated .dxf file, that doesn’t seem to be the case since it should be closed already (not manually drawn).
I’m having a look now at KiCad’s 3DViewer function to see what it actually does before erroring out and how I could potentially write a test for this:
I checked the dxf beforehand in a windows nightly from 13th May… no problems (I wouldn’t let loose stuff like that without testing):
The dxf coordinates aren’t 100% on top of each other, but kicad usually is not too pedantic about it:
Can we just automatically add that to every post?
I guess if I am not doing the posting I shouldn’t care, but people seem to be happy to spend a lot of time trying to compare 
and 
I get confused trying to follow it, so I wonder how newbies manage.
The nightly builds are getting on for 2 years worth more advanced than the stable release, that is a lot of changes. In particular, the 3D stuff has seen a lot of improvements.
So yeah, there are several bugs in stable that are fixed in nightly builds…
No worries @bobc, I just gave it a shot to nightly for OSX from June the 12th (UI looks great, btw!) and here’s the result (same error yet cleaner, less verbose):
So I tried the bare DXF and four mouse bites and it rendered fine without complaints from the 3D viewer:
So the problem is somewhere else, not in the DXF’s themselves, strange … I’ll play a bit now with the copper layer and footprint placement but I’m a bit out of ideas on what might be the issue here.
Thanks a ton @Joan_Sparky!
Don’t worry @bobc, the dxf comes from inventor and worked in stables before.
I just mentioned the version as @brainstorm is on a mac, which might have been a contributing factor.
Interesting. Maybe a forgotten, nearly zero length outline…
Anyhow, you’ll nail the bugger 
Good luck.
Problem solved! It was actually the mouse bites overlapping somewhere somehow :_S
I just added other mouse bites footprints from madworm and worked like a charm 
Ok, cool… never mind me… too much/too little coffee this morning
FWIW, I tried an Openscad DXF like @brainstorm and @Joan_Sparky’s brainstorm.dxf, and they both load and view OK in 4.0.6. I might look into what is going on with the mouse bites. I would like to add mousebites to gerbmerge, ultimately it would be good to get these sort of panelisation scripts working in pcbnew.
BTW, very cool idea using OpenScad to generate DXF files, I always associate OpenSCAD with 3d stuff!
I tried to do something similar with the mousebites from madworm and a DXF generated by OpenSCAD, I didn’t run into any issues. Came out quite nice. It was a very simple example though, perhaps the issue lies elsewhere.
At least we now have a good data point for OpenSCAD, right? 
Yes, madworm mouse bites worked like a charm for me too at the end, I was having the problems above with those: https://github.com/johslarsen/Misc.pretty
Which have a lower footprint profile, but raise errors on the 3D viewer unfortunately
Ok, would have helped if we’d known that earlier…As I expected, those mousebites contain lines on Edge.Cuts, where madworm’s do not. Lines on Edge.Cuts in a module must join exactly with lines drawn on the PCB, otherwise you get the errors.
Hi, I loaded your TheAmpHour breakout to Kicad 40.6 but it still give error when generating 3D Viewer… is that a normal thing ?
