I will try to write something up. But the most important idea is that you need to have the plugin installed in your Blender as it does not only export the PCB from KiCad into a Blender file but it also helps with the rendering itself in the Blender…
2 Likes
Installing such plugins in Blender (and their origins) is of course part of such a tutorial / faq article.
But don’t feel too much pressure. Writing good tutorials is an art in itself, and quite often no tutorial is better then a bad tutorial that seems plausible.
having something easy and native in kicad would be very nice… Altium has this function internally.
I remember I asked something at the forum years ago…
Edit:
I did this Video awhile back. It uses Kicad’s 3D-Viewer.
In the video, I’m repeatedly clicking the Icon show, BUT, I just now set a 3D-Viewer Hot-Key to Rotate - thus, only need to hold the Hot-Key down… Works great!
I plan to enable GLTF export (it’s already there as part of opencascade we just aren’t using it), which will allow easy import into Blender.
Also FYI, python has no ability to access the 3d viewer to do anything
2 Likes
For simple movements it’s also doable to just use screen recording software, move your model in KiCad’s 3D viewer and then later edit the video. Just keep the interesting parts, render out the mouse cursor and such.
Screen recording is how I do it (QuickTime is built into the Mac) and I have Launch icons to do this stuff (I screen record many, many movies from the 1940’s this way then, re-encode them to MP3 using HandBrake and do the same thing for the Vid’s I post here… (otherwise the files are Gig’s…)
the focus is in script the movement, not in recording the play (which is achievable in many ways).
Oh, ah yes…
Also, in reading the first post again, he is not asking for help, but stating that he already wrote a python program do generate such scripted movements by feeding keystrokes into KiCad. Not elegant, but simple and functional.
Yes, but AFAIK only for win…
Moreover some function to interact with 3d viewer inside kicad would be a plus IMO.
I noticed that too. Even though I do not like python much *1) it is a pretty platform independent language. Quite a shame people write platform dependent libraries for it in the first place. There are 38 matches for the string “win32” in that 94 line python script.
*1).Two things I especially dislike is it’s whitespace dependency, and that it (most often) just invents a new variable on a simple typo. C compilers catch that instantly. For me that is the difference between 10s of correcting the typo and a recompile, or 10+ minutes of debugging. A third thing is that python seems to attract sloppy people, or at least people who are discouraged by compilers and the many compile time checks they do, while I am the opposite. I make lots of silly mistakes (other topic) and am very glad with a compiler and strict syntax checking that helps me a lot to write correct code.
I think python simply offers a friendly environment to approach coding and it is mainly cross platforms.
That is why it is so diffused IMO.
I think it’s important to bring this conversation back to what @makingdevices did: he identified a missing feature and then built it in the most direct way possible (i.e., manipulate the mouse through Python and grab screens). That illustrates two fundamental qualities of humans: 1) We’re the only things on this planet that can envision something that doesn’t exist and then build it, and 2) We don’t want it to be harder than it has to be.
Notice what he didn’t do:
- Download the KiCad source.
- Setup a build environment.
- Locate the 3D viewer code.
- Identify whatever classes, structs, and functions were needed to modify the 3D view.
- Create the user interface for specifying the rotations/translations of the PCB.
- Even more steps …
A lot of people have probably thought of screen recording the 3D view. Probably at least a few tried to follow the steps to integrate it into KiCad. Obviously none of them made it, possibly because all the obstacles and side issues just make it too costly in time and effort and so they gave up.
But @makingdevices succeeded, maybe because he had a language that hides a lot of details combined with some well-defined interfaces (Python-mouse communication along with the 3D viewer’s rotation and PNG export buttons). It isn’t perfect, but it is accessible so others can look at it and possibly make improvements. How many would do that if they also had to follow the six steps I listed above?
That’s what pains me about the somewhat knee-jerk impulse to integrate every feature into the KiCad monolith: it makes it harder to build new features. And because it’s harder, there are fewer people who can or want to do it. And with fewer people, fewer ideas get built. And with fewer ideas, there will be fewer good ideas because the way to have good ideas is to have a lot of ideas.
Right now, the path for new ideas begins by raising an enhancement issue on Gitlab. Then wait for lightning to strike and maybe one of the developers will take an interest and build it. Or not, and then the idea dies.
So I salute @makingdevices for essentially saying “Imma make this feature using whatever.” We need more of that.
4 Likes
I’m not saying his tool is useless, but unfortunately it is only on win… it is still limited by the ability of 3D viewer to be driven by keys…
I consider this feature an improvement for KiCAD (as a feature included in Altium) and it would be nice to have something natively developed (as I was dreaming in 2017!).
Moreover having some ability to remote the 3D viewer from python would facilitate a way to present a pcb, adding a python plugin.
you know I moved StepUp outside KiCAD because of the lack of internal interest in integrating FreeCAD libs in KiCAD (which would have donate a mechanical kernel to KiCAD)…
But when something is easy to implement internally (as the main developer of the 3D code said) the best approach, IMO, is to build it natively inside the sw.
1 Like
if we are talking about a professional application, then we need at least 2D integration and a gerber editor without this, displaying pictures does not make sense … if under win64 this is solved by third-party applications, then under Linux they simply do not exist at all … and even if the developers go according to this direction then everything will be limited to win64 …
I think you get lost in the process…
is this relevant to this thread?
any add-on for integration is related to the topic … the end-to-end design system tells you what? The world around is much wider, as is electronics design… there are two ways, either you do integration with a third-party application or you do it inside the program itself… in the case of Linux, both of these options are not suitable within kicad… I gave an example for understanding such integration across platforms is not possible
Why? any kicad plugins just work (or can work) in all OSes
That’s true and it’s obvious to anyone who looks at it. And more people will look at it because they can just pop the code open on Github and scroll through the massive 94-line source file. And the more people who look, the more likely someone will say “I can do that on linux!” Things like that won’t happen if the code is encased in the Monolith and any potential beneficial modifications will have to be done by someone from a much smaller population of core developers.
Yes, you envisioned doing this in 2017. But it never got done, by you or anyone else. It’s worth wondering why we had to wait until 2023 for one lone guy with a handful of Python to do it.
If you’re deep in the guts of something, it always seems easier to do it yourself using all the capabilities you’re already familiar with. And that’s fine, but you then also have to take the sole responsibility for supporting/improving the feature going forward. And that’s the core problem: too many things to do, to few developers. How many feature requests on this forum get replies containing the phrase “… but there are limited developers”. So more developers are needed! Obviously they haven’t been flocking to work on the Monolith, so maybe create more interfaces that give more casual developers an easier/quicker path to feature implementation. But there doesn’t seem to be much enthusiasm for that, so we’re left to rely on guys like @makingdevices who are willing to hack things together.