Tuesday, July 21, 2015

Firepower playfield visualisation

 

Toolflow

There are still several playfield part to be designed, but I also like to start designing the playfield to check placement and sizing. Sadly I don’t have a powerful 3d cad program like Solidworks to import all the 3d models in. For the model design I am using Openscad, but that is not usable when working with graphics, or rounded shapes using splines. I tried Freecad, but that is not stable enough. So how to do this?

I came across this website https://code.google.com/p/how-to-build-a-pinball/ and https://www.flickr.com/photos/felipesanches by Felipe Sanches. He was designing a pinball based on a DOS game, but don’t think he ever finished it. But his approach is quite nice: an Inktscape and Openscad combination. He even designed ramps using splines in Openscad.  But for the Firepower playfield I don’t need ramps, that is for the next pinball. I adapted his approach for my purpose.

The tool flow I used is as follows:

  1. Using Inktscape draw the locations of all playfield elements, and possible also draw the playfield graphics themself. Saved in a SVG file.
  2. A conversion tool and some script files extract the elements out of the the SVG file and create multiple .scad files containing the elements positions and sizes.
  3. Openscad is used to view the playfield. A scad file uses the locations files and all playfield element designs to draw up the playfield. Now you can viewed it from all directions.

As entry tool I use Inktscape. This is a free vector edit program. This tool is aimed at image editing, and is less suited for cad applications. As lowest layer I load a crappy scan of a firepower playfield. Sadly I never been able to find a good Firepower scan. On other layers the various playfield elements are drawn. For example there are separate layers for targets, lights, pins, bumpers, flippers etc. Each layer is named. The positions are drawn using circles and lines.

The extract program written in C++ reads and parses the SVG file that is formatted in a XML into memory.  It uses the XML library PUGI to read and parse the SVG file to create a DOME tree. Using the PUGI API the SVG is parsed to find the <g> Layer entries.  If the correct layers is found, the <circle>, <ellipse> and <path> are extracted. Sadly Inktscape does not use <line> and instead stores lines into <path>. The path contents need to parsed again to extract the line information.  In will write a separate blog with more details about the parser. Finally it writes the circles and line out as scad files, using arrays to hold all the extracted coordinates. This works all quite well. Except for one issue that I not have solved yet: I was trying to use the start and end co-ordinates of a line to obtain the rotation of the line. Sadly Inktscape is too smart and sorts the coordinates in a line and ignoring start and end as you draw it. If you extract the angle of the it only goes 0 to 180 degree. If it is more as 180 degree, it just swaps start and end. Bugger!

Openscad is used to view the model. A scad file includes all the created scad files by the extraction program. It and includes all the 3d models of the playfield. Then it uses the extracted coordinates to draw up all the elements. It also creates a playfield with all the holes.

For example there is a layer in the Inktscape hold all the inserts drawn using various sized circles. The extract program extracts the circle coordinates and size. The Openscad file use the circle position and size and down the following: It makes a hole in the playfield of the correct size. It draws the insert model in the playfield. It also draws the below playfield led holder. A small issue is that you can not set the rotation of the below playfield led holder angle.

Inktscape

OK enough text. Some examples:

The Inktscape design. This shows all the layers active:

path5752-07-9

Not all layers are in the Openscad yet. The rounded ball guide shapes are not handled yet. You can also see why the scan is crappy: There is also part of the scan missing, that i filled up with some similar shapes. Worse, the right side is not straight!

This is the same picture, without the background firepower scan.

playfield_pic2

Here are all the playfield elements better visible. The lines and circles are drawn on different layers, depending on the function. There are circles for round inserts, bumpers , pins and lights. Lines are for flipper, slingshot, eject holes , arrow inserts, line guides , targets and switches.

 

Openscad

After conversion this is the result in Openscad.

table2

Shows are pin, switches target and lot of playfield parts are shown. Still a lot of playfield elements are missing at this stage. Slingshots, bumpers,ball guides, trough ,playfield plastics etc. are not designed yet.  In you look careful you can see that the left set of 3 targets is facing the wrong way due to the Inktscape – extraction issue listed above.

One of the first issues pooping up, what that the eject hole mechanism, was colliding with screw holes for pins and lights. So I had to go back designing different types of eject mechanisms that use less area , and are in front of  the eject hole. See the eject hole page for more details.

The Openscad also creates a dxf file with all the holes in the playfield. This is used for the CNC mill or laser cutter that cuts the playfield.

table shooter and inserts top

Picture is not the latest version and missing several holes. But you get the idea. The single red cylinder the front just indicates the center line of the playfield. It is not actually present in the real machine.

Some views of the shooter elements.

shooter

Red is the shooter lane insert, gray is the pinball and shooter rod. light green the shooter tip, and dark green the shooter guide.Black the playfield wooden rails.

shooter2

Dark green the shooterlane cover.

No comments:

Post a Comment