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…
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
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
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.
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.
I took a look at the STEP format. STEP (aka ISO10303) is hugely complex: 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?
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:
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.
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 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.
). 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.
