Read the library convention https://kicad.org/libraries/klc/F9.3/
@Rene_Poschl @eelik thanks for the information and I apologise if all the questions I am asking seem obvious.
Hopefully this will be my last question on the topic:
I can see from the footprint 3D library convention that you currently keep placeholder for 3D models that have not yet been created. However I am still confused as to why the above footprints don’t just link to the models that already exist?
From footprint 3D library convention:
- If a footprint is a simple variation that does not change the 3D representation, the common 3D model should be used ( do not duplicate models unnecessarily )
Am I missing something here?
(Again: I am offering help to fix the above issues - at least the ones I can fix)
What existing model should it use? There is no model for any footprint similar enough in the lib.
The quote you made is for avoiding having a separate model for a thermal via and non thermal via variation. So in other words IF AND ONLY IF the package itself has the EXACT same dimensions then the footprint can share the 3d model.
Please see my post #8 above for examples.
Probably the best example would be Footprint DFN-6-1EP_3x2mm_P0.5mm_EP1.65x1.35mm inside the Package_DFN_QFN library. A suitable 3D model could be: DFN-6-1EP_3x2mm_Pitch0.5mm.wrl In fact this 3D model appears to not be used in any other footprint, suggesting that it was created but not linked to the footprint?
I apologise if I am missing something obvious here but all of these footprints could be linked to existing 3D models which I believe are perfectly suitable. Maybe there is some subtlety I am missing about them?
That 3d model seems to have been left over by accident and should be removed. It does not follow the current naming convention and can not be trusted (does not specify the size of its exposed pad).
@Rene_Poschl thank you for the clarification.
I think I understand a bit better the issue: the library is setup in a way that it cares a lot about the size of the exposed pad in the 3D model.
I would argue that this is a bit overkill: when do you ever look underneath the component? You could have generic 3D model that just needs to be the right height, x,y dimensions and pad pitch. It would definitely save a lot of work in 3D model generation and also size of the libraries.
I guess the above is debatable and there must be a strong reason for doing it the way it is currently done?
PS: I apologize for going a off topic from my original post. Maybe this topic should be split?
It is either right, or it isn’t. Errors accumulate. Your use of the viewer and someone else’s are different.
1 Like
@hermit There is no absolute “right”, unless some rules have been agreed in advance.
For example, one could argue that the existing 3D models don’t show the correct manufacturer markings, logo and “pin 1” notch shape (e.g. triangle, circle, line across top part, etc.) and therefore they are not “right”. Now, clearly it would be ridiculous to make a 3D model for each and every part that exists in the world just to make sure we have the correct markings on the 3D model.
The above argument also applies to a thermal pad that is underneath the IC that you cannot see when you do a ray-tracing render of your board. In fact, arguably, the markings issue would actually have a bigger impact for this scenario.
The other scenario is sharing 3D data with your mechanical team: ultimately they just care about how tall the component is and don’t really need any other detail such as pad shapes/etc. (but we keep those in the 3D model for visual effect when ray-tracing)
At the moment the 3D libraries are ~5GB in size and it is only going to grow bigger. The point I want to make isn’t just about whether thermal pads should be included or not, but more generally for all 3D models: where do you draw the line? Again, quoting from KiCad Library Convention 3D model requirements
- […] ( *do not duplicate models unnecessarily* )
I would suggest we could work together on defining which 3D model variations are important to have and which ones are not*. This will result in two benefits:
- Reduce overall library size
- Improve total number of footprints that have valid 3D models associated with them (without any additional design effort).
* My vote would be on not worrying about any features underneath the component unless they are visible due to the shape of the component
[by the way I am very conscious this is going off topic a lot since it is about 3D libraries and nothing to do with symbols - could we split this topic starting from post #8?]
I could make the same argument.
Just because YOU don’t require that accuracy doesn’t mean someone else doesn’t. I have stuck wrong 3D models on a board for MY visualization purposes. You are free to do so. I doubt you’ll ‘win’ the ‘close enough’ argument on an engineering forum.
@hermit yes I am aware of the KiCad Library convention (I did link it in my above post), but it does not have any detail about what features of a 3D model are considered “important”. For 3D models it just discusses how it should be aligned to the footprint and how it should be named.
Please can you re-read my above post in its entirety - I think I am making quite a valid argument…
Yes, but still it can be argued that pins and EP are physical and can affect physical design while e.g. top markings aren’t. Therefore pins and EP are important while markings aren’t. But I agree with you that the EP is probably very rarely needed in the 3D model for any purpose.
Sorry, I was editing my original post when your reply came in and I guess I didn’t switch gears so it kind of mucks up the flow.
It’s also worth considering what is important in the library level and what is not. The amount of files isn’t necessarily important. The size of the whole 3D library is.
The EP makes sense once you start to think about a future where somebody wants to do some thermal simulation.
4 Likes
Does the EP in the 3D model help with simulation?
For thermal i would imagine yes. Especially if it is implemented by use of FEM simulators borrowed from mechanical engineers.
2 Likes
@hermit sorry if i offended you in any way - not my intention!
Accuracy depends on the application. At the moment the 3D models don’t have any tolerance information defined, and in real life could be slightly larger or sightly smaller, by a lot more than the thermal pad.
@eelik If I read you correctly you are agreeing with my argument? 
As I was typing this reply 3 new replies came in! I was just about to write: “can anybody give me any reason why thermal pad should be in the 3D model?”, but @Rene_Poschl already answered with the FEM reason .
Ok then now we are getting somewhere to discuss the “3D model accuracy” question: if the 3D model needs to be used for FEM analysis then the existing models would not be sufficient as you’d also need accurate thickness of the metal pad and also the silicon chip inside: its size, how is it bonded to the thermal pad, how it is bonded to other pins in the package etc. See example below:
Source: https://www.eetimes.com/thermal-analysis-for-power-devices/
[edit: added picture]
1 Like
To add to my above points, I was just browsing the footprint library and noticed that majority of the 3D models for BGAs only have the outer rows of balls modeled. Three examples below:
Library Package_BGA
Footprint UFBGA-100_7x7mm_Layout12x12_P0.5mm.kicad_mod
Library Package_BGA
Footprint UFBGA-132_7x7mm_Layout12x12_P0.5mm.kicad_mod
Library Package_BGA
Footprint UFBGA-144_7x7mm_Layout12x12_P0.5mm.kicad_mod
Now I am not in any way saying that the above BGA footprints should have their 3D models fixed to have the correct number of balls. I actually think the 3D model that they have is perfectly valid for the two use cases that they are intended for:
- Providing a nice looking visual for rendering.
- Accurate outer dimensions for integration with MCAD systems, which allows checking if there are any collisions with other objects in the overall assembly.
The fact of having the inner balls missing from the model wouldn’t make a difference at all for above use cases. In fact any unnecessary additional features would result in a very sluggish MCAD model due to the amount of objects it needs to render as you rotate it around. The other thing is even though the above footprints are for different number of balls, all of them actually have the same outer dimensions and if you pay attention to the 3D models, they are actually identical. Therefore, they could all share a common BGA model: the 3D models are identical anyway - why have three separate files of the same thing wasting hard drive space?
Considering that the issue of different number of inner balls on BGAs is similar to different sized thermal pads in QFN packages, I would like to propose the below modification/addition to the KiCad Library Convention for 3D Models (you may change wording as you wish to ensure it is clear):
If a footprint is a simple variation that does not change the external 3D representation, the common 3D model should be used ( do not duplicate models unnecessarily )
R0805_HandSoldering.kicad_mod→R0805.wrlQFN-48_ThermalVias.kicad_mod→QFN-48.wrlThis also applies to components with identical external representation but variable features on the underside (the hidden side) - e.g. variable sized thermal pads in QFNs or variable number of balls in a BGA package:
DFN-6-1EP_2x2mm_P0.5mm_EP0.6x1.37mm.kicad_mod→DFN-6-1EP_2x2mm_P0.5mm.wrlDFN-6-1EP_2x2mm_P0.5mm_EP0.61x1.42mm.kicad_mod→DFN-6-1EP_2x2mm_P0.5mm.wrlUFBGA-100_7x7mm_Layout12x12_P0.5mm.kicad_mod→UFBGA-xxx_7x7mm_Layout12x12_P0.5mm.kicad_modUFBGA-132_7x7mm_Layout12x12_P0.5mm.kicad_mod→UFBGA-xxx_7x7mm_Layout12x12_P0.5mm.kicad_modUFBGA-144_7x7mm_Layout12x12_P0.5mm.kicad_mod→UFBGA-xxx_7x7mm_Layout12x12_P0.5mm.kicad_mod
Feel free to disagree with me on above points - maybe I am missing something?
I will say this again: I am not just arguing for the sake of arguing: I am offering my help to carry out the necessary changes to the KiCad library in order to fix at least some of these issues of missing 3D models. However, if I can fix the issues the way I am proposing, it will be significantly less work than having to create a huge number of new 3D models from scratch. Also, I am keen on reducing the 3D library size if at all possible.
Even if the models right now do not have all details we still need the option to add more detailed ones later which requires every unique package to have a separate model set in its footprint(s).
Also consider our continuous integration setup. It needs to be able to discover what a valid path is. Right now this is rather simple as we just compare the model path to the footprint path. Anything more complex is simply not in the cards right now.
Also consider that all these models are script generated. The reason some do not have models is because nobody got around to generate them from the already existing data. We could of course require every user to add a 3d model if they add a footprint but to be honest 3d models are simply a way too low priority right now to require this from our contributors. (We could make it a requirement for script generated ones but also here our scripts are not that user friendly so i am not sure this would be the right move)
What makes it even worse is that the footprints are also scritped. The long term goal is to get rid of any handcrafted footprints for standardized packages. Which is why none of these are allowed to be edited from within kicad.
And now something worse: The decision to do it the current way was made a long time ago. Such a decision of course means that a lot of infrastructure is build up under the assumption of the current rules (a lot of scripts). All of these scripts would need to be adapted and i really don’t see the point.
If you really want to help then i suggest you adapt the 3d model scripts found in https://github.com/easyw/kicad-3d-models-in-freecad to accept the size definition files used for the footprints https://github.com/pointhi/kicad-footprint-generator That way it would be really trivial to get all required 3d models.
3 Likes