Open follower opened 7 years ago
From my notes:
STL import/export support for SketchUp requires a plug-in to be installed: https://extensions.sketchup.com/en/content/sketchup-stl
While you can download it from there you need a login but if you visit the associated project on GitHub you can download the source directly: https://github.com/SketchUp/sketchup-stl/releases
Once the plugin is installed you can import a .skp
and export a .stl
via the Ruby console with:
model = Sketchup.active_model
status = model.import "/<path>/SSOP20_L.skp", false
CommunityExtensions::STL::Exporter.export('/<path>/SSOP20_L.stl')
I also found a reference on how to run a Ruby script within SketchUp from the command line: "Is there a command line in Google Sketchup to export in 3ds or fbx format?"
The SparkFun Eagle libraries repository is here: https://github.com/sparkfun/SparkFun-Eagle-Libraries
AFAICT there is no explicit mapping within the .lbr
files between the component packages and the associated models--it seems to be assumed that the package name will match the model file name (as is the apparent convention with EagleUp).
The SparkFun 3D model repository is here: https://github.com/sparkfun/3D_Models
It seems to have grown somewhat haphazardly (e.g. varied model source formats, export formats and naming conventions) although it looks like there's some attention being paid to tidying it up currently.
There are two categories of models, split between the production_parts
and products
sub-directories.
Most individual part models (associated with the SF Eagle libraries) are found in production_parts
although some (which are also sold as products) are found in products
.
In order to determine part/model coverage and how many .stl
models needed to be generated I wrote a couple of file/directory scanners.
Summary of production_parts
scan (via ./scan_model_repo.py ../sparkfun-github/3D_Models/production_parts/
):
Components found: 237
Valid components: 109
No sketchup file: 16
No STL file: 112
A "valid component" in this sense is one for which both a SketchUp source file and exported .stl
file exist. These component models should be able to be included in our standard library directly.
"No sketchup file" means that an .stl
file exists but no SketchUp source file was found (often this occurs when the exported file doesn't follow the naming convention of the source file).
And the "No STL file" category are the models for which we need to generate STL files.
There were also additional cases where neither .stl
nor .skp
files existed which seems to occur where another design package was used (e.g. SolidWorks?).
Further analysis of products
needs to occur as most models will not be relevant for us as they are not individual components. But it does seem to include EagleUp and Blender-exported .json
files (exported via) which might be helpful for determining which models would be useful).
With the information from the model scanner it's possible to determine how much model coverage there is of the SparkFun Eagle libraries (via ./scan_library_repo.py ../sparkfun-github/SparkFun-Eagle-Libraries/
):
Total libraries found: 20
Total packages found: 1579
(Note that the package total includes duplicates due to the "same" part (in name, at least) appearing in multiple libraries.)
For a clearer view of the model coverage it's helpful to look at the individual libraries (this is a count of models found (in either .skp
or .stl
format) versus the number of packages found in the library):
GeekAmmo 3 / 18
LilyPad-Wearables 1 / 25
SparkFun-Aesthetics 0 / 91
SparkFun-AnalogIC 12 / 38
SparkFun-Boards 1 / 63
SparkFun-Capacitors 16 / 88
SparkFun-Connectors 32 / 388
SparkFun-DigitalIC 32 / 120
SparkFun-DiscreteSemi 16 / 47
SparkFun-Displays 1 / 24
SparkFun-Electromechanical 12 / 151
SparkFun-FreqCtrl 4 / 26
SparkFun-LED 10 / 31
SparkFun-Passives 16 / 102
SparkFun-PowerIC 16 / 73
SparkFun-RF 8 / 93
SparkFun-Resistors 7 / 28
SparkFun-Retired 7 / 45
SparkFun-Sensors 21 / 119
User-Submitted 4 / 9
Note that some packages (e.g. ones in SparkFun-Aesthetics
) don't need models because they're board features (e.g. logos, solder jumpers) rather than components.
In other cases package names have an suffix (e.g. -KIT
) which suggests it's a different footprint but doesn't require a different component model. If so, then the alternate name can be mapped to the existing model.
It doesn't appear at first glance that there is very high model coverage in most cases, although manual mapping of alternate names would presumably help.
(If desired I can attach the output with the complete per-package model coverage.)
The third scanner uses the component model information to determine coverage for specific board designs (via ./scan_board_files.py ../omniblox.github.com/Eagle-Loader/examples/brd-files/
):
feather (2/19)
adafruit_flora_mainboard_2 (1/22)
gemma (1/14)
neopixel_ring_12 (0/5)
trinket (2/14)
photon (1/9)
picobuck (4/13)
sparkfun_redstick (15/24)
sparkpunk (0/20)
SparkFun_ESP8266_Thing_v10 (16/35)
thing (16/35)
Additional details show that in most cases the "missing" models for SparkFun boards tend to be for packages that don't actually require a model.
This initial analysis seems to confirm the value of providing a standard library with mappings because otherwise the amount of effort required to get useful results is non-trivial (especially given there are many additional sources of models (which vary in quality and comprehensiveness)). Although there are potential concerns around comprehensiveness vs load times which may need to be alleviated.
With these tools and this analysis we can now track progress as we automate the generation of models and create the mappings.
Pushed commits with missing batch generated STL files (Note: GitHub will try to render all these files if you click on the commit links):
These were generated by automating SketchUp and then baby-sitting the automation. Baby-sitting was required because the exporting seem to fail non-deterministically with either segfaults or Ruby errors. Eventually re-running the automation enough times generated all the files. (This was using SketchUp 2015.)
We might want to transfer the branch/fork from my account to Omniblox if we're going to offer to push the generated models back to SparkFun.
Script used to automate the generation of the STL files: https://github.com/Omniblox/pcb-component-models/blob/master/tools/generate_missing_stl.rb
(So we can use it again if we decide we want to use a different model format.)
With generated STL files in place (via ./scan_model_repo.py ../sparkfun-github/3D_Models/production_parts/
):
Components found: 237
Valid components: 219
No sketchup file: 16
No STL file: 2
The 2 "No STL file" items are due to difference in handling of case insensitive file systems.
Thus 110 more valid components. Note that due to duplicate names this is fewer than the number of generated component models.
when you want to work in the main repo - flick me a pull request from your fork. after that then branch the main repo
These are currently located here: https://github.com/Omniblox/pcb-component-models
Current status:
PR created: https://github.com/sparkfun/3D_Models/pull/238
Ideally we'll automate this. Need to investigate how straight-forward automated export is.