omniblox/eagle-loader

THREE.js Loader for EAGLE .brd files

eagle-loader's Issues

Could `EagleBrdRenderer.visualizeConnector()` use `THREE.ConnectorHelper()`?

Seems like an overlap of functionality and not clear if there's a reason why it doesn't. (.visualizeConnector() is also called by EagleBrdRenderer._parseElement() for the component connectors.)

Correctly position ghost components for non-centered footprints

See #24.

Demo: Interactive/static kit assembly guide

Test use of GitHub-hosted map file and model files

SVG/Canvas viewer

Hi!

I have a eagle/kicad/geda pcb viewer, but my viewer using SVG/Canvas rendering backend.

I want to make WebGL backend one day, but seems you already have one. Maybe we can work together to merge two almost similar projects.

From my side, I can extract pcb parsing library as a first step.

Decouple board parsing from display

i.e. Parse .brd file into intermediate representation and then build THREE.js display representation from the intermediate form.

Add unique canonical name per connector

Initially can be of the form <board?>.<connector>.<pin> but since it's desired to expose this as a JS property it may need to changed/exposed as <connector>_<pin>, <Connector><Pin> or similar.

Document how best to view repository examples

Viewing the examples via the file:// protocol appears to cause bad URI or cross-site access not allowed source errors for the font files for at least some browsers.

Also, trying to bypass this by serving them locally (via Python's built-in HTTP server), requires the server being run in the repository root directory rather than the examples directory because of relative references that use the dist directory.

Finally, the URL for the font ends up being of the form /examples/OCRA.woff rather than the actual location of /dist/OCRA.woff.

Omniblox.io Issues

• Fix issue where home page images are hidden on mobile/narrow windows due to overflow-x: hidden; on the thumbList element.
• Fix hard-coded renderer.setSize( 640, 480 ) call & style in e.g. http://omniblox.io/eagleloader/sparkfun-redstick which causes poor location/visibility on mobile/narrow windows.

Dashed silkscreen lines are drawn as solid lines

On SparkFun Thing board, the dashed silkscreen lines render as solid:

Rather than being rendered as dashes like the actual PCB:

Implement Component display tasks

• Map component to model file.
• Load model.
• Attach connector.
• Set scale. (Note: .stl files have no scale and use arbitrary units. (via))
• Set orientation. (Note: EagleBrdRenderer._parseElement() currently appears to not use the rot/angle value to modify the rotation of the connector. )
• Set location.

Improve connector visualisation

Connectors have both a position and a direction attribute but the current visualisations (using spheres) only clearly show the position attribute.

Since understanding the direction attribute seems to be important in understanding how connectors work it seems like it would be a good idea to visually indicate the direction of a connector.

(My initial mis-understanding about connector direction was that I thought a connector's direction was always perpendicular to the object to which it was attached (e.g. the geometric normal of PCB) but this is not the case for the board loader.

This was discovered by using a THREE.ArrowHelper to visualise the direction of the connector. The ArrowHelper visualisation shows that the component connector direction runs along (i.e. parallel to) the surface of the board.)

I feel like a notched disc/extruded triangle may be a clearer connector visualisation or, at least, adding an arrowhead/cone that protrudes from the current sphere.

I've experimented with some possible direction visualisation approaches but have uncovered some wider issues:

• The loader doesn't currently use the ConnectorHelper to visualise connectors, see: #6
• The ConnectorHelper constructor currently does not receive the connector itself nor connector direction which would be needed in order to be able to indicate the direction in the visualisation.
• The connector visualisation appears to currently be unconnected to the connector object itself which results in the visualisation not being updated when the connector changes e.g. due to a change in orientation of the object to which it is attached. (This seems to not currently be an issue in the position-only visualisation due to the symmetrical appearance of the sphere.) (This seems to mean that ConnectorHelper can only be added after all positioning is completed but also that the direction may still be incorrect. By way of comparison, the ArrowHelper visualisation does correctly set the direction, presumably due to the code in ArrowHelper.prototype.setDirection().)

Investigate why board texture disappears after prolonged animation

Chrome for Android:

[.Offscreen-For-WebGL-0xac23f410]GL ERROR :GL_OUT_OF_MEMORY : glBufferData: <- error from previous GL command
complex.html:1
[.Offscreen-For-WebGL-0xac23f410]GL ERROR :GL_INVALID_OPERATION : glBufferData: 

Fix donut pads that are rendered as squares

See: #9 (comment)

Bottom Copper layer is displayed on top of Top Copper Layer

With a 2 sides PCB, the eagle's bPlace layer is well drawn on the bottom of the 3D PCB, but the Bottom Layer (copper) is drawn on the Top Layer.

Document tested/supported Browser/OS combinations

Handle `!xx`/`!xx!` inverted signal label display convention

Currently the library does not display labels using the !xx or !xx! convention with the specified bar above the label.

Example of current display:

Photo of actual board with correct display:

PCB Render issues umbrella

Examples of rendering issues which don't already have a dedicated ticket.

Add "standard library" of component models and associated mapping

Initial plan is to make this from STL models already gathered for examples and also generated from the SketchUp models in the SparkFun repository (#17). (Which we could presumably push back to the SF repo.)

Once we have the models we need to create the mapping from component name to the model file path and integrate that.

Refactor to use layer name "constants" rather literal values?

For clarity, it would be nice to have layer names rather than layer numbers (e.g. layers: [ 21, 25, 29, 51 ],) in the code.

The mixed-case nature of the standard Eagle layer names is unfortunate and it's not immediately clear what constant naming convention might be best (especially given JS's support/lack "const" and enums).

Maybe one of these styles:

// tDocu
EAGLE_LAYER_tDocu
LAYER_tDocu
EAGLE_LAYER_TDOCU
LAYER_TDOCU
layer.tDocu
layer.tDocu.id

Or something...

Fix incorrect rendering related to `tStop`/`bStop`

See comments in #9.

Component display umbrella issue

Questions to answer:

• Does existing parsing code extract & store all relevant details (e.g. location, orientation, package) from .brd file?

  Location and orientation appears to be stored as does a reference to the package by name--but not necessarily a direct mapping to a model.

• How do we associate a 3D model with a particular component?

  Still needs to be determined. For designs that use component libraries with associated 3D models (e.g. SparkFun) it may be able to be determined "automatically".

  For now we use a mapping from component name to model file path.

• What 3D model format(s) do we want to support? e.g. .stl

  Three.js supports loading of a number of model formats with various feature support. It has a preferred format itself which might require use of conversion tools.

  Answer: Initial support is to be .stl only.

• What should the relationship between connectors and models be?

  Connectors are attached to models, centred on the bottom face.

• What is the relationship between connectors, components, models and pads?

  Still to be investigated--but it appears one connector per component except when the component itself is a physical connector.

  Understood enough for now.

• How sophisticated do we want the component rendering to be? e.g. texture, material, etc

  Answer: Initial .stl support means single material support is acceptable.

Demo: Interactive board/circuit description

Replace text font with more accurate representation?

From "Vector Font available elsewhere?":

[Is] the Vector Style Font that is utilized within EAGLE available as a standard Font for use in other softwares?
In old MS-DOS times, that font (plus several others) was shipped with all of Borland's "Turbo" compilers (which I think is the reason why CadSoft uses that font).
[...]
LITT.CHR
[...]
Legal issues: [...]

Seems like the LITT.CHR font was at some time converted into an approximation in .ttf form (by a designer with the non-search-engine friendly name "Character") and is widely available over the net: e.g. http://www.fontspace.com/character/litt & https://www.onlinewebfonts.com/download/2e08e25c2fee3c5bb759d7fa1ed99ec4. The license for this font states "You are hereby licensed to do whatever you wish with this.".

Example render via FontSpace (compare with the current render and actual board photo shown in #11 (comment)):

The licensing of the original .CHR font file in terms of re-distribution is unclear. (The thread linked at the top of this ticket has more discussion of this aspect.)

It appears that the TrueType version of the font is limited in its accuracy by virtue of the fact it is an outline font while the other is a stroke/line font. If we wanted even more accurate representation we could (of course :p ) implement a parser/renderer for the .CHR format in Javascript, as it appears the font format is at least somewhat documented and relatively straight forward:

• "The Borland CHR Font File Format"
• "CHR (Borland font)"
• ".Chr font files"
• "Convert Borland CHR Font Format"

The original LITT.CHR file also seems available in multiple places, e.g.: https://github.com/vincentbernat/old-turbo-pascal-programs/blob/master/TP/LITT.CHR

Other potentially useful references:

• Additional Background information on the Borland .CHR font:
  • "How was this PCB Silk Screen Font Made?"
  • http://www.u.arizona.edu/~kforster/dmastr/dm_man13.htm
• Other single line ("Hershey") fonts:
  • Summary of single-line fonts
• Related fonts:
  • The current font we use: http://fontzone.net/font-details/ocr-a-extended
  • Another font recommended as similar: http://fontzone.net/font-details/isocpeur

For reasons of checking similarity, the lower case "k" character is helpful.

Fix `Connector` so it handles rotation of parent (e.g. PCB)

See here for current workaround: follower@bb0bb73

Ideally this workaround would be fixed by handling the rotation of the parent correctly in the connectTo() method.

Possible via in single-sided pad render issue

Not sure if this is an actual issue or not, but on the SparkFun Thing board there appear to be vias placed in single-sided SMD pads (used for mechanical or thermal purposes, I assume) which get rendered with grey rectangles on them. Possibly because we're somehow rendering a solder paste layer also (yes, it seems so: tCream/Layer 31)?

Presumably this is unintentional as it doesn't occur for other SMD pads which also have tCream.

As rendered:

As viewed in Eagle:

As viewed in Eagle with tCream (diagonal line hatch) visible:

Expose signal name as connector property

A separate issue due to it requiring additional effort.

Fix handling of footprints with non-centre origins

While most components footprints have their origin (as shown by tOrigins or bOrigins) at their centre, some components (e.g. SparkFun's MICRO-SD-SOCKET-PP shown below with highlighted origin at bottom right) have the origin at some other point:

At present it appears the footprint connectors are placed with the assumption that the origin is at the centre of the footprint. This results in the connector, ghosts and models being in an incorrect position e.g. for sparkfun-9dof-razor-imu.brd.

As it happens the 3D component model also has the origin at a non-centre location which needs handling separately when this issue fixed.

It appears finding the centre point is non-trivial (due to curve handling and layers) and the current code base appears to do it in two separate places. It also appears that due to how packages/elements are parsed and placed on layers, there's no intermediate/parsed/structured form of the package available so the package element needs to be re-parsed to find the centre.

Use autorotate functionality from ObjectControls.js?

See: 45ac494#diff-85d56dfc9b7cbd325567cf56d0c20637R235

Expose additional properties on hole/pad connectors

For a given connector (from .connectHoles, i.e. holes and pads, as created in ._buildDepthHoles()) we want the following properties exposed (via .userData):

• Element name (already available via .userData.element?)
• Pad/Pin name
• Mirrored? or Top/Bottom Layer? [Not to be specifically handled currently (see here).]
• Signal name (Is only one signal ever connected per pin?) [see #40]

Incorrect display when board opacity changed from 100% to <100% back to 100%

Replication steps from Dave:

the “to replicate” is: load BRD file, set material opacity = 0 ….

1. load brd file
2. set material.opacity to 0 and material.transparent = true;
   then
3. set material.opacity to 1 and material.transparent = false;

that’ll show the problem

Generate STL files from SparkFun library for "Standard Library"

Ideally we'll automate this. Need to investigate how straight-forward automated export is.

Move component model loading code into main library

Move the new component model loading code boilerplate in the complex example into the main library.

• Include populateComponentFootprints() and related code.
• Add a mapping from component name to model file path as additional BrdLoader params entry.

Remove layer 51 / tDocu (etc) from top render layer

Layers 51 & 52 (tDocu & bDocu) are currently included in the render but this seems inconsistent with their documented (no pun intended) intended use, e.g.:

• https://learn.adafruit.com/ktowns-ultimate-creating-parts-in-eagle-tutorial/creating-a-package-outline
• http://www.lucidarme.me/?p=2363

The version of the Thing board in the example has "Ground Plane" rendered because the text is in layer 1, the version of the board currently on https://www.sparkfun.com/products/13231 also has this text rendered but it's been moved to layer 51. The final PCB does not have this text rendered.

This might be best implemented via default layer visibility setting in the library?

Fiducials are displayed as squares rather than circles

On the SparkFun Thing (and at least Red Stick) fiducial marks are rendered as squares rather circles:

The fiducials should render as circles as per the actual board:

This may also be related to #9 patch which reveals RST and other donuts as squares also.