Yes, I’m inclined to suspect a footprint as well but if it is a footprint it does seem odd that he can move the board around and the lines don’t move.
I initially deleted all the items on the layout, so all I had left was the page outline…the lines remained in 3-d.
I then deleted the pcb file, and vreated a new pcb with nothing in it, and the lines were gone, but the 3-d had other stuff, that obviously should not be there.
Creating a new project with an empty pcb shows as it should with nothing in the 3-d.
Here’s the pcb file with the junk lines…without external footprints, it might show correctly.
nanominilayout.kicad_pcb (100.5 KB)
It is a text at bottom copper (Reset)
The complete lines are: (Line number 1457)
(gr_text Reset (at 129.54 -2147.483648 180) (layer B.Cu) (effects (font (size 1.016 1.016) (thickness 0.254)) (justify mirror)) )
If i remove that, everything is ok.
1 Like
the problem is in the following code inside the board
(gr_text Reset (at 129.54 -2147.483648 180) (layer B.Cu)
(effects (font (size 1.016 1.016) (thickness 0.254)) (justify mirror))
)
you have a label extremely far
gr_text Reset (at 129.54 -2147.483648 180) (layer B.Cu)
if you put the label at the right place
gr_text Reset (at 129.54 96.00 180) (layer B.Cu)
everything will be fine
EDIT @Rene_Poschl was faster 
1 Like
GREAT, but which text is that? I have 3 or 4 texts in the copper.
Is the text violating some rule? I opened a bug request anyway…
The question now is: Why the ■■■■ does it not simply render the text extremely far away but distorts it. (stretches it in the y direction.)
I fear there might be a bigger problem hidden somewhere.
for some reason your text was placed too far from the board center (-2147.483648)
Then the pcbnew got a problem in managing the label
nanominilayout-fixed.kicad_pcb (100.5 KB)
the “Reset” label is now at
gr_text Reset (at 129.54 96.00 180) (layer B.Cu)
Yes i get an assertion fault 
If you delete everything from the board and open it with the 3d viewer you get the following assertion:
/builddir/build/BUILD/kicad-6996/3d-viewer/3d_canvas/cinfo3d_visu.cpp(308): assert “(m_boardSize.x > 0) && (m_boardSize.y > 0)” failed in InitSettings().
This looks like there is some sort of number system overflow.
I think this needs to be reported on the bug-tracker.
By the way which versions of kicad are affected?
I use kicad nightly builds and have the problem which versions do you have?
1 Like
I’m using version 4.04.
I deleted the “RESET” text, and itr made no difference…
If you delete everything in the file (via pcbnew) is there anything left in the file?
(Except the header stuff)
And very important: after you delete the lines in the file close kicad completly and reopen it. (Or close it before you edit the file in the texteditor)
You’re deleting the wrong “Reset” text.
It’s odd, Pcbnew stops rendering it around -2030 and the 3D viewer has problems when it gets to around -2147. In the positive direction KiCAD stops rendering at the same point at which the 3D viewer has problems, +2147.
KiCAD needs some error checking on the position values entered into the Properties dialog.
The gerber file has a lot of interesting values in it:
example line from the generated gerber: X129104571Y-2147483648D02*
and if you look at the binary representation (twos complement of the y coordinate):
0x80000000 there is only the most significant bit set.
This is the smallest integer representable with 32 bit.
The fun starts if you multiply it by -1. (spoiler: you get the same value )
And if you subtract one you get the largest re-presentable integer (0x7FFFFFFF = 2147483648 - 1). This explains why the text is distorted. The center is at INT_MIN. Everything further in the minus direction gets very large.
I’m sure it affects every version as it is due to a limitation of the datatype used to hold those values. It’s sufficient unless someone tries to make a board more then 4 meters wide.
There just needs to be some error checking so the user can’t enter unreasonable values in the dialog boxes.
The software should at least report an integer overflow when exporting to gerber.
Hopefully there is no exploitable integer overflow somewhere hidden in kicad.
I created a bug report outlining the problem discovered here.
@crusader27529: I saw your report to late. (already committed mine)
1 Like
Not the core bug, but did you really want text in copper? I know that when I add text, I have to select the appropriate silkscreen layer. Text in copper can be hidden by solder resist, fab dependent.
If you don’t have a silk layer you have no other options.
(As example: The student team i work for gets pcbs for free. We can’t always choose the process that is used. Two layer pcbs are produced without silk by the fap who supports us.)
I never had the problem that text is unreadable. Yes text on silk stands out better, but if you don’t have other options you take what you get.
True and when you don’t have silkscreen you probably don’t have resist either hiding the copper.
@crusader27529 does have valid and used silkscreen layers in the PCB files
I get resist but no silkscreen. It’s just one processing step that gets dropped. (Don’t ask me why. Maybe the prototype fab where my two layer pcbs are produced does not have a silk printer.)
Good point. Didn’t remember that when i wrote my comment.