# 3D models of packages and boards **URL:** \ **Category:** Improvement Ideas\ **Created:** [December 14, 2018, 7:30pm UTC](https://librepcb.discourse.group/t/3d-models-of-packages-and-boards/23 "2018-12-14T19:30:10Z")\ **Posts on this page:** 9\ **Page:** 1
**Author:** ![import](https://avatars.discourse-cdn.com/v4/letter/i/4da419/32.png) [@import](https://librepcb.discourse.group/u/import)\ **Post date:** [December 14, 2018, 7:30pm UTC](https://librepcb.discourse.group/t/3d-models-of-packages-and-boards/23/1 "2018-12-14T19:30:11Z")
_From @ubruhin on Thu Oct 25 2018 19:55:49 GMT+0000 (UTC)_ LibrePCB packages should have support for 3D models, so that we can implement a 3D board viewer & export. In KiCad, footprints can have two different types of 3D models: - [VRML](https://en.wikipedia.org/wiki/VRML) for 3D board viewer and raytracing - [STEP](https://en.wikipedia.org/wiki/ISO_10303) for export to mechanical CAD Although it’s cumbersome to have two different file formats for 3D models, I guess this is the most reasonable solution. So I think it would make sense if we do it the same way… Or are there other opinions? _Copied from original issue: [https://github.com/LibrePCB/librepcb-rfcs/issues/32](https://github.com/LibrePCB/librepcb-rfcs/issues/32)_ ---
**Author:** ![import](https://avatars.discourse-cdn.com/v4/letter/i/4da419/32.png) [@import](https://librepcb.discourse.group/u/import)\ **Post date:** [December 14, 2018, 7:30pm UTC](https://librepcb.discourse.group/t/3d-models-of-packages-and-boards/23/2 "2018-12-14T19:30:14Z")
_From @dbrgn on Thu Oct 25 2018 20:33:15 GMT+0000 (UTC)_ VRML is horrible unfortunately… But I don’t really know a good alternative. On the other hand, using the same format as KiCAD would allow us to use their 3D models and vice versa. With the growing popularity of KiCAD, maybe better editing tools will pop up. KiCAD libraries are licensed CC-BY-SA, so we could use them. This is probably a case where converging on a common format would give the open source community a lot of benefits. Also, it seems that nowadays FreeCAD can generate valid VRML files for KiCAD. That wasn’t the case a few years ago 🙂 ---
**Author:** ![import](https://avatars.discourse-cdn.com/v4/letter/i/4da419/32.png) [@import](https://librepcb.discourse.group/u/import)\ **Post date:** [December 14, 2018, 7:30pm UTC](https://librepcb.discourse.group/t/3d-models-of-packages-and-boards/23/3 "2018-12-14T19:30:15Z")
_From @ubruhin on Fri Oct 26 2018 20:55:13 GMT+0000 (UTC)_ \> On the other hand, using the same format as KiCAD would allow us to use their 3D models and vice versa. Yes, that _would_ be really helpful! > KiCAD libraries are licensed CC-BY-SA, so we could use them. Hmm I’m not sure if we really could/should use them. Actually I want to have all official LibrePCB libraries to be published under CC0, so that users can do absolutely _everything_ with the libraries, without even worrying about their license. CC-BY-SA breaks this, as it has restrictions ☹ ---
**Author:** ![EternityForest](https://yyz2.discourse-cdn.com/free1/user_avatar/librepcb.discourse.group/eternityforest/32/125_2.png) [@EternityForest](https://librepcb.discourse.group/u/EternityForest)\ **Post date:** [January 1, 2019, 7:35am UTC](https://librepcb.discourse.group/t/3d-models-of-packages-and-boards/23/4 "2019-01-01T07:35:13Z")
A cursory glance at other CAD apps shows STEP is everywhere, and STL/AMF are fairly common. The new version of STEP can contain colors it seems, so if STEP alone is good enough for a basic fallback, you could have STEP required, and allow arbitrarily many other files as well. It seems like VRML is the one of the only things that really has an accepted way to put materials with specular reflection and the like into a file, aside from going with an app-specific format. One could define a standard set of STEP material names, and an exporter that knows what material to apply to a GoldPlatedPin or some Solder or some BlackChipEpoxy. That kind of abstraction gives flexibility and prevents being forever tied to one model of how rendering should work. OBJ seems to explicitly be designed for that kind of workflow, with named materials and a separate MTL thing, and it’s pretty bog standard. The MTL files have transparency and specular reflection and such. You could just have a basic flat color+openGL viewer integrated, and leave HQ rendering to a Blender exporter with a library of shaders for each material. This would also save parts authors from having to worry about presentation too much. They just type a material name, and LibrePCB handles making it look good. Another pretty big advantage is that different people’s models will have the same color chips and pins and such in the render, preventing an annoying cacophony unless a part really does have a specific color. ---
**Author:** ![dbrgn](https://yyz2.discourse-cdn.com/free1/user_avatar/librepcb.discourse.group/dbrgn/32/25_2.png) [@dbrgn](https://librepcb.discourse.group/u/dbrgn)\ **Post date:** [January 1, 2019, 9:01pm UTC](https://librepcb.discourse.group/t/3d-models-of-packages-and-boards/23/5 "2019-01-01T21:01:55Z")
> [@EternityForest](#): > > Another pretty big advantage is that different people’s models will have the same color chips and pins and such in the render, preventing an annoying cacophony unless a part really does have a specific color. I like that. Having a standard set of materials allows for consistent look & feel in 3D renderings. ---
**Author:** ![bcallebaut](https://avatars.discourse-cdn.com/v4/letter/b/c0e974/32.png) [@bcallebaut](https://librepcb.discourse.group/u/bcallebaut)\ **Post date:** [May 18, 2019, 12:17pm UTC](https://librepcb.discourse.group/t/3d-models-of-packages-and-boards/23/6 "2019-05-18T12:17:44Z")
We are dealing here with 2 kinds of requirements: - Generate a nice 3D rendering of the board (promote your work) - Create an accurate 3D model for mechanical purpose (make the box around the electronics) 3D rendering is best done with tools like Blender and Maya (list is not exhaustive). These uses format as \*.obj files, collada (more or less standard)… They provides materials, photo realistic rendering… But they are not accurate for dimensions. STEP (and other format like IGES, solidworks…) are for 3D mechanical manipulation and are accurate. According to me, information about 3D rendering (texture,bump map…) must be present in the component library but its format can be proprietary as long as we can export it to a standard 3D rendering format. 3D mechanical information must also be present in the 3D library to allow exportation with software like SolidWorks, or SolidEdge. By the way, third party plugins in Blender (or Maya) already allow asset generation for other applications. An example is OpenTTD (Open Source Transport Tycoon Deluxe) whose has Blender templates to generate new buildings and transport models for the game. ---
**Author:** ![dbrgn](https://yyz2.discourse-cdn.com/free1/user_avatar/librepcb.discourse.group/dbrgn/32/25_2.png) [@dbrgn](https://librepcb.discourse.group/u/dbrgn)\ **Post date:** [November 10, 2019, 1:08am UTC](https://librepcb.discourse.group/t/3d-models-of-packages-and-boards/23/7 "2019-11-10T01:08:10Z")
I took a look at the STEP format. STEP (aka ISO10303) is hugely complex: [https://www.datakit.com/en/step\_organization.php](https://www.datakit.com/en/step_organization.php) There’s the file exchange format (ISO10303-21), but that only describes how to parse the files. It does not say anything about the meaning of the parsed data. The meaning depends on some other substandards, and it depends on the schema that is being used for a file. A schema can be something like `automotive_design`, but it can be other things too. Does someone know whether other schemas than `automotive_design` are being used to model electronics parts? * * * Regarding the OBJ format as an alternative, the main downside is that it doesn’t contain any absolute scale information. However, we should be able to store the scaling information in a separate file, or in the library, right? If I understand the format correctly, then OBJ will contain geometric information and it allows to reference materials specified in a separate file to change the look of a polygon. This means we could create a set of standard materials in a `librepcb.mtl` file and reference those materials from the library OBJ files, right? ---
**Author:** ![ubruhin](https://avatars.discourse-cdn.com/v4/letter/u/c89c15/32.png) [@ubruhin](https://librepcb.discourse.group/u/ubruhin)\ **Post date:** [April 13, 2023, 10:08am UTC](https://librepcb.discourse.group/t/3d-models-of-packages-and-boards/23/8 "2023-04-13T10:08:48Z")
I plan to implement this feature soon, thus here my current thoughts: ## 3D Model Format The more I think about this, the more I don’t like to have two different 3D model formats stored in our libraries. It’s too much redundancy, probably creating lots of inconsistencies between the mechanical 3D representation (e.g. STEP) and the rendering representation (e.g. VRML). For example, a board might look correct in the 3D viewer, but the STEP export misses some models, or contains misaligned models since alignment of STEP and VRML are independent. In addition, the redundancy will heavily bloat the libraries in terms of file size (matters for server hosting and download times) but also in terms of complexity. Therefore I strongly prefer having only a single source of truth for 3D models. As there exists no 3D file format which is suitable for both mechanical and rendering purpose, I think we have two options: 1. Invent our own 3D model file format which covers both use-cases – basically a STEP file with advanced surface/material specifications. The format needs to support conversion from/to STEP since for MCAD data exchange we need STEP for sure. 2. Only use STEP models and forget about realistic renderings (data exchange with MCAD is more important than rendering). At least colors are supported by current STEP revisions, so it is quite usable for a simple 3D viewer. Probably option 1. is way too much effort for now and thus out of scope. And when going with option 2. I think it would still be possible to switch to option 1. some day later (STEP files could be automatically converted during a file format upgrade). Therefore at the moment I tend to go with option 2., i.e. supporting only STEP files. ## Implementation (C++) I also took a look at how we can load and export STEP files with LibrePCB. Unfortunately there are not many C++ libraries to do it, especially no lightweight one. It seems OpenCascade is the only reasonable solution so we have to use it, although it is _huge_ 🙁 ## Source of Models Regarding usage of KiCad 3D models: That’s also a topic I’m not sure about yet, but still I prefer to publish our 3D models under the CC0 license so the KiCad models would not be usable for us. I am thinking about this way to go: - For packages we already generate with our parts generator, we could use [CadQuery](https://cadquery.readthedocs.io/en/latest/intro.html) to also generate our own STEP files. I think this wouldn’t be too hard (I already used that tool, works very well). This would already cover a large percentage of the most common packages. - Optionally we could also ask the KiCad people to release their STEP models under CC0, but I don’t think they’ll agree. - For manufacturer-specific packages it might make sense to ask the manufacturers for permission to publish their official STEP models under CC0. If they agree, just copy their provided models into the library. If they disagree, their libraries simply won’t contain 3D models (motivates users to switch to more liberal manufacturers 😉). If this does not work at all (i.e. all manufacturers disagree), let’s try to find another solution then. Of course it will always be a last resort to also create these 3D models by ourselves and publish them under CC0. That’s my current proposal. Any comments welcome 🙂 ---
**Author:** ![ubruhin](https://avatars.discourse-cdn.com/v4/letter/u/c89c15/32.png) [@ubruhin](https://librepcb.discourse.group/u/ubruhin)\ **Post date:** [April 29, 2023, 10:10pm UTC](https://librepcb.discourse.group/t/3d-models-of-packages-and-boards/23/9 "2023-04-29T22:10:36Z")
FYI, a pull request is now opened for this feature! 🚀 > > > \# Summary > > Finally this PR adds initial 3D support to LibrePCB! :rocket: See a…lso the related \[forum thread\](https://librepcb.discourse.group/t/3d-models-of-packages-and-boards/). > > \## Dependencies > > We now need two new dependencies to compile & run LibrePCB: > > \- \[OpenCascade\](https://www.opencascade.com/) for reading and writing STEP files. Both the official OCCT and the open-source edition OCE are compatible. > \- \[OpenGL Utility Library\](https://en.wikipedia.org/wiki/OpenGL\_Utility\_Library) (GLU) for tesselating surfaces in the 3D viewer. > \- And OpenGL for rendering. > > These libraries cannot easily be bundled with the LibrePCB sources, thus for compiling they need to be installed on the system (fortunately they are available on most platforms). Due to dynamic linking they also need to be installed at runtime, but in our official binaries they are bundled (except OpenGL, but this is an "optional linking" anyway, managed by Qt). > > However, since there \*might\* be troubles getting these libraries on some platforms, LibrePCB can optionally be compiled without them - the 3D features will simply not be available then. In addition, all these libraries are not accessed at all unless the user explicitly requests some 3D functionality. This should keep the rest of LibrePCB working fine in case these libraries cause any problem at runtime (e.g. due to an incompatible system library or so). > > \## 3D Package Models > > The 3D representation of packages is implemented with \*\*STEP files\*\* stored in the packages directory. Each package may contain multiple such 3D models. In addition, each footprint specifies a list of 3D models to be usable for the corresponding footprint. Example: A TO220 package might be mounted vertically or horizontally and thus has these two footprints, while each of the footprint specifies a different 3D model to be compatible with. > > In addition, each footprint specifies placement information for the STEP model (translation/rotation) in case the STEP file has a different origin & orientation than the footprint. > > The package editor now is switchable between 2D footprint editing and 3D model placement: > > !\[librepcb-3d-package\](https://user-images.githubusercontent.com/5374821/235322956-e0a0d6c4-bcf8-4697-aa5c-122e2a65c463.gif) > > \## Package Check > > The package editor shows an info message if there are footprints with no 3D model assigned, to remind the user adding one. > > \## 3D Board Viewer > > The board editor now also allows to switch between 2D and 3D mode, or a split view with both. In addition, it is possible to switch between the different 3D models if a package provides multiple. The board properties as implemented in #1154 are also taken into account for rendering. The 3D preview is automatically rebuilt in a separate thread after each modification so it is kind of "pseudo-live". > > !\[librepcb-3d-board\](https://user-images.githubusercontent.com/5374821/235325079-de54c150-f36f-4bda-ad68-428ed6da0cdb.gif) > > \## Board STEP Export > > The board editor also allows to export the PCB including all devices as a STEP file. Only basic functionality for now, no configuration options yet but I think this is sufficient for the typical use-case. > > !\[librepcb-step-export\](https://user-images.githubusercontent.com/5374821/235325534-5ac4e095-9273-4284-a18f-7cc2af90ff48.gif) > > \## CLI > > The size of STEP files will sooner or later bloat our libraries heavily, thus I implemented a STEP file "minifier" according \[this idea\](https://gitlab.com/sethhillbrand/stepreduce). The GUI performs that operation automatically when loading a STEP file, but for the \`librepcb-parts-generator\` I think it will be useful to automate this process with the CLI. Therefore I implemented a new flag \`--minify-step\` which minifies all package STEP files within a library. > > \## Notes > > Note that of course the value of this feature depends on the availability of 3D models in the packages. Unless we extend our official libraries with 3D models, the 3D viewer will just display the PCB without devices. So far I do not intend to implement a "workaround" for users to allow adding 3D models to projects directly, i.e. without waiting for 3D models in our official libraries, or to use alternate 3D models. Probably this would be useful in many cases, but it should be doable without a file format change so I'd postpone this to a minor release. > > Also be aware that in total this is a quite complex feature (especially the interaction with OpenCascade and OpenGL), thus I expect there are still various bugs or incompatibilities (but of course I already tested a lot).