KiCad 3D Models :)
1. This is awesome, btw: https://github.com/tscircuit/kicad-viewer
2. https://kicad-mod-cache.tscircuit.com/ https://kicad-mod-cache.tscircuit.com/kicad_files.json these are also awesome and I'm much happier to use these compared to the equivalent thing I was recently spinning up this week.
Is there a github repo for the script or project that creates this? Or is it a private behind the scenes runner? Given this commit https://github.com/tscircuit/circuit-json/commit/beddab68c88961d456134b366b0fbdaae424a1f9 it seems like the pieces are coming together. Is it a plan to also cache the kicad 3d models repo and add the STEP paths to the kicad_mod circuit json files? 🙂
Is there a github repo for the script or project that creates this? Or is it a private behind the scenes runner? Given this commit https://github.com/tscircuit/circuit-json/commit/beddab68c88961d456134b366b0fbdaae424a1f9 it seems like the pieces are coming together. Is it a plan to also cache the kicad 3d models repo and add the STEP paths to the kicad_mod circuit json files? 🙂
GitHub
GitHub - tscircuit/kicad-viewer: View all the official kicad librar...
View all the official kicad library files on the web - tscircuit/kicad-viewer
59 Replies
The only computationally heavy part of this I can think of is that STEP models are not directly web compatible so you'd have to convert them to OBJ/ GLTF/ GLB whichever format is best for the web viewer. Mostly a one time thing to get it caught up, could probably run on a decent desktop computer in a day or so.
From https://gitlab.com/kicad/libraries/kicad-packages3D
I think opencascade should handle WRL, it would refer to it as VRML
From https://gitlab.com/kicad/libraries/kicad-packages3D
WRL files must be exported from its mechanical model counterpart. WRL files are used for photo-realistic rendering using KiCad's raytracing rendering engine. This format supports more complex material properties, allowing various common component materials to be accurately rendered.Using the provided WRL files could possibly be a much computationally lighter conversion of WRL --> OBJ/ GLTF/ GLB and those are going to be more photorealistic for you.
I think opencascade should handle WRL, it would refer to it as VRML
GitLab
KiCad / KiCad Libraries / KiCad Packages3D · GitLab
Official KiCad 3D model libraries for rendering and MCAD integration
yea we can run a fly cluster w/ GPUs (or possibly do it via CPU if supported because that is easier to scale with smaller CPU units
if we have to run a STEP conversion cluster with KV-caching (...this is kind of likely) we'd use a separate repo, because one criteria for splitting repos is deployable unitsBy KV-caching do you mean "if this source model has already been processed and it hasn't changed, don't process it again" ?
yea, via redis or a proper keystore rather than cloudflare's builtin CDN cache header mechanism
if the processing is cheap, it's much better to just use cloudflare's CDN cache for everything
do you know how long the conversion took? <5s on a desktop?
ok I'll learn up on that more I guess.
I thought that just looking at the source gitlab kicad repos and using commit history or file last modified date or computing a hash would be ok ways of determining "here's where the state from last time, here's the files that changed, let's just run the script on these files with overwriting" Or maybe I'm misunderstanding cuz it sounds like you're talking about serving the results out of the repo???
I thought that just looking at the source gitlab kicad repos and using commit history or file last modified date or computing a hash would be ok ways of determining "here's where the state from last time, here's the files that changed, let's just run the script on these files with overwriting" Or maybe I'm misunderstanding cuz it sounds like you're talking about serving the results out of the repo???
we don't have a KV store w/ the kicad-mod-cache right now, it relies on cloudflare's standard cache headers
so we don't really need to worry about storing anything
it's not a big deal, the hardest part isn't the cache mechanism but the actual conversion haha
This is the part I'm going to proof of concept and test first. (Might be a quick tonight thing or in the next few days thing)
I'll test converting the STEP and WRL files to OBJ+MTL, GLTF, and GLB.
My gut feeling is that we want to use the WRL whenever possible and fall back to the STEP if the WRL is not available. And I think the GLB will be the most efficient format to work with, which is why I brought it up the other day in the GLTF support conversation.
yea @shibo has done a bunch of work on glb and we should have it no problem
there seem to be two ways of doing the STEP conversion programmatically, via OpenCascade C++ bindings or via FreeCad headless. We just need to get it working in a docker container that responds to HTTP requests
@Rishabh added footprint support for kicad although i think there's still some configuration on our end to get it fully working end to end, but when specifying a kicad footprint we'd like to automatically load the relevant cad component without the user needing to specify
cadModel (we can handle all of this, just saying this is how it will probably work)
(we = rishabh and I for kicad <> core integration)This is the one I was using before to do my OBJ conversions, the concern is that I know OpenCascade should support working with VRML files but no mention in the docs there:
https://www.npmjs.com/package/opencascade-tools
npm
opencascade-tools
Easy-to-use wrapper around OpenCASCADE Technology. Latest version: 0.0.9, last published: 3 years ago. Start using opencascade-tools in your project by running
npm i opencascade-tools. There are no other projects in the npm registry using opencascade-tools.yea that looks like a great pick
last publish 3 years ago is a bit worrying
My gut feeling is that FreeCad headless is just extra bloat - it just uses OpenCascade under the hood (I'm pretty sure I saw that written somewhere) so going right to the source seems the best move to me.
OpenCASCADE, the open source CAD kernel FreeCAD uses...
yes but fwiw we're not super concerned about bloat for server clusters, i've run 4gb containers on docker before, the only marginal downside is ~2s extra time to boot per gb
*4gb containers on fly.io via firecracker before
yea the benefit is freecad maybe has all the sane defaults
since many of the STEP models were originally created in freecad
🤷
I'm aware I should dig into this, in the case of what the docs show here, it's just a matter of figuring out what level of detail we want in the conversion. I think kicad should document that for the WRL's somewhere, perhaps in the 3D Model contribution guidelines, so I'll dig into it.
https://www.npmjs.com/package/opencascade-tools
sg, yea that's the hardest part. we spin up lots of fly compute clusters so the server mgmt is the easy part for sure
btw for the clusters, doesn't have to be TS. Of course we prefer TS but if the codebase is small it's nbd. We only do this for relatively small servers tho
when we integrated freerouting we had to deal in Java, nbd as long as it's isolated to a server
I'm most comfortable scripting in nodejs anyways, that's why I default to that, not cuz your project is mostly TS 🙂
Sidenote: https://gltf-viewer.donmccurdy.com/
https://www.donmccurdy.com/
https://github.com/donmccurdy/three-gltf-viewer
We found this a while ago and this guy Don seems to be the defacto expert on GLTF/ GLB file processing on the part of the internet that we have access to 🙂
glTF Viewer
Drag-and-drop preview tool for glTF 2.0 3D models.
Don McCurdy
Don McCurdy
Developer working on climate data, graphics, data visualization, and web technologies.
GitHub
GitHub - donmccurdy/three-gltf-viewer: Drag-and-drop preview for gl...
Drag-and-drop preview for glTF 2.0 models in WebGL using three.js. - donmccurdy/three-gltf-viewer
Im getting info bombed
I'm looking at everything now.
https://gitlab.com/kicad/libraries/kicad-packages3D
-->
WRL Material Properties
https://gitlab.com/kicad/libraries/kicad-packages3D/-/blob/master/Vrml_materials_doc/KiCad_3D-Viewer_component-materials-reference-list_MarioLuzeiro.pdf
WRL Illumination model
https://gitlab.com/kicad/libraries/kicad-packages3D/-/blob/master/Vrml_materials_doc/KiCad_3D-Viewer_Illumination_model_and_materials-MarioLuzeiro.pdf
They put a lot of effort into how to "appearance" the WRL models and my gut instinct is to try to take advantage of the work that was already done and convert WRL --> GLB (or whichever)
GitLab
KiCad / KiCad Libraries / KiCad Packages3D · GitLab
Official KiCad 3D model libraries for rendering and MCAD integration
GitLab
Vrml_materials_doc/KiCad_3D-Viewer_component-materials-reference-li...
Official KiCad 3D model libraries for rendering and MCAD integration
GitLab
Vrml_materials_doc/KiCad_3D-Viewer_Illumination_model_and_materials...
Official KiCad 3D model libraries for rendering and MCAD integration
we might be able to load wrl directly into threejs
we should probably to that to avoid the expensive STEP process
Model Scaling The STEP file format includes model scaling information, and so the 3D model scaling parameter must always be set to 1:1 in mm The WRL file format does not specify absolute dimensions. KiCad normalizes WRL model dimension to units of 0.1 Inches, and the internal units of the WRL files should be scaled accordinglyAh Christ, the WRL no internal units and KiCad treating it as 0.1 inch thing. This has tripped us up at dayjob so many times.
yea stl and obj also have "unit by convention"
as long as kicad is internally consistent it should be ok
I'd be so happy if everything was just mm by default. But yes, we can expect all WRL from KiCad to be 0.1inch by default
@shibo we should probably add
wrlUrl to the list lol (sorry)whirl irl
RE: wrlUrl, we may need to include something in the circuit-json cad_component definition like
model_unit_to_mm_ratio, i will configure our kicad loader to automatically set the appropriate 0.1in ratio
oh nvm... that's already included since there's some properties related to sizeran the opencascade-tools CLI to do some conversions from the STEP model, each one appeared to take 3 seconds of the CLI loading the OCCT webasm followed by the actual conversion, so I'd say the GLB took maybe 3-5 seconds in total while the OBJ may have taken 5-7 seconds. Just in human perception units time.
An interesting thing is that the .gltf comes with a .bin, and Don's viewer needed both to render successfully. Whereas the GLB is self-contained.
Default settings in the converter look nice enough, no chunky edges or anything. Interesting size comparisons though: the source STEP is 398KB, the KiCad WRL is 67 KB, the GLB is 154 KB, adn the OBJ is 206 KB. So they've def optimized the WRL size down or cut down on the level of detail in it.
yea we'll want glb for simplicity
shibo was dealing with that issue earlier. Technically gltf can be self-contained but in practice often isn't
"told you so" ? 🙂
Meanwhile, I agree with your earlier assessment:
https://www.npmjs.com/package/opencascade-tools
is pinned to an old version of the underlying library, has not been updated or touched in quite some time, and I am concerned.
is pinned to an old version of the underlying library, has not been updated or touched in quite some time, and I am concerned.
npm
opencascade-tools
Easy-to-use wrapper around OpenCASCADE Technology. Latest version: 0.0.9, last published: 3 years ago. Start using opencascade-tools in your project by running
npm i opencascade-tools. There are no other projects in the npm registry using opencascade-tools.it's pretty easy with
bun to wrap a local executable, it's not too bad with child_process also. As long as the impl is contained in a docker container we could do that, not the worst thing
STEP doesn't change very often either so it's also nbd to ship a 3 year old converterThe actual OpenCascade code is a doozy, I started digging into the docs: https://dev.opencascade.org/doc/overview/html/occt_user_guides__de_wrapper.html
This is not a good use of any of our time, trying to wrangle a converter from scratch. Zalo literally has their name on one of the projects that uses OpenCascade under the hood, they know this stuff inside out 🙂
haha yes we could recruit zalo haha, i'm not completely sure we need to parse STEP files though if the wrl is available
i didn't realize wrl was a mesh-based representation- that's exactly what the 3d viewer should be loading
the npm above has a js function as well so we don't need to acess it via CLI like I am doing now. My "concern" is that opencascade should be able to take WRL as input for a conversion, but the npm project does not support it. I am looking into it.
But yes, I am warmed up to the idea, if you can directly use the KiCad provided WRL models, yes please!
the STEP representation is only needed for constraints which we don't support (yet)
we're doing a separate project for pcb assembly which will have a lot of sophisticated STEP handling and a dedicated parser
I am warmed up to the ideaTranslation: I suffered for some hours trying to do my own suggestion, and I suffered.
it's all relevant in the long run, the small step is just loading meshes and the larger step is to analyze the STEP and actually parse it
OK so the edge case now is when I'm designing a PCB in the web interface and I'm adding some footprint that isn't in KiCad's library (or the footprint IS in the library but with no 3D model, this is common) and I manually want to provide a STEP model for the preview.
ahh yea ok that makes sense
yea ok we do want to handle that
yea it's quite tricky to do that because if the STEP converter doesn't live on the user's machine but the STEP file does you'd actually need to upload it somewhere, which just kind of stinks because the user would assume a local file will not make web requests when using
tsci dev 🤔
makes me want to have something like tsci extensions install step
but idk, maybe i can figure out a weird solution
this is why i want to parse STEP files directly haha
part of the reason i built a 3d renderer was to tee up STEP file parsing, but the STEP specification is massive and requires a CAD kernel generally speakingYeah. This problem is the same as a decade ago, unfortunately.
and xkcd 927 is timeless
I'm concerned about you having to pay for servers for your users to upload step and get converted to "whatever we use under the hood"
sidenote: ideally we would also keep the originating step model for the future plans above, exactly how kicad has the .step and .wrl files of the same name alongside each other.
Your concerns are valid as well, people not expecting/ wanting tsci dev to call out to 3rd party APIs, hence the local conversion script.
Unfortunately, solving all of that does sound like a "implement in web: ts/ webasm" so it can work in all these cases and now we're back to https://github.com/donalffons/opencascade.js which is some years out of date and not maintained
GitHub
GitHub - donalffons/opencascade.js: Port of the OpenCascade CAD lib...
Port of the OpenCascade CAD library to JavaScript and WebAssembly via Emscripten. - donalffons/opencascade.js
yea plans are measured in decades w.r.t. STEP parsing, I used to work for STEP Tools (the company that invented STEP) and I want to write a new manifold-based kernel, so something not OpenCascade based
but we might have to do some short term solutions
Yeah I'm deep in the OpenCascade stuff rn trying to figure something out that also supports WRL for now, it sounds like you'd be ok with a short term solution that might be a little kludgy but doesn't pin us into a corner long term?
yep yep
probably if we detect a user has a step file we automatically convert it and put it in
.tscircuit/models/${hash}.wrl or somethingI appreciate that you're taking this problem seriously. I always try to have 100% 3D Modeled PCBs when I work.
Mayo https://github.com/fougue/mayo
performed both conversions in 12 and 13 ms (self-reported)
not a web thing, local app, uses OpenCascade actual under the hood.
GitHub
GitHub - fougue/mayo: 3D CAD viewer and converter based on Qt + Ope...
3D CAD viewer and converter based on Qt + OpenCascade - fougue/mayo
hell yea
yea this looks great
There's a CLI, it works. It's fast. I like it.
hell yea
so this involves server side processing every time, but put some basic constraints on it so someone doesn't come abuse it and I think we have a winner.
agree
the binary size isn't too bad, around 100MB, so we could eventually support bundling it with the local CLI if there's a lot of demand for it
i'm sure some companies have secret STEP files 😁
very super secret.
I meant "no comment" 😆
which "the binary" are you looking at, and does it address the different platforms your users might be on?
you'd create a package like
mayo-bin on npm that dynamically selects the appropriate binaries for the user's system in a postinstall step
there are other ways to do it but postinstall is fairly straightforward. Then you also ship some bindings in the js packageAh, very coolio
Whelp, let's not criticize how I f'ed up the paths rn. 129 files converted from STEP to GLB in around 1 minute.
mayo cli, bare minimum, no special parameters, just the input file path and --export
give the output filepath (same basename + .glb desired ext) and it works.
Awesome