We seem to want our PCB design software to do everything these days, and it almost delivers. You can not only lay it all out, check electrical and design rules, and even spit out a bill of materials, but many PCB tools produce 3D models that are good enough to check parts clearance or are useful in designing enclosures. But when it comes to producing photorealistic output, whether for advertising or just for eye-candy, you might want to turn to 3D design tools.
In this workshop, Anool Mahidharia takes the output of KiCad’s VRML export, gets it rendering in Blender, and then starts tweaking the result until you’re almost not sure if it’s the real thing or a 3D model. He starts off with a board in KiCad, included in the project’s GitHub repo, and you can follow along through the basic import, or go all the way to copying the graphics off the top of an ATtiny85 and making sure that the insides of the through-plated holes match the tops.
If you don’t know Blender, maybe you don’t know how comprehensive a 3D modelling and animation tool it is. And with the incredible power comes a notoriously steep learning curve up a high mountain. Anool doesn’t even try to turn you into a Blender expert, but focuses on the tweaks and tricks that you’ll need to make good looking PCB renders. You’ll find general purpose Blender tutorials everywhere on the net, but if you want something PCB-specific, you’ve come to the right place.
Continue reading “Remoticon Video: KiCad To Blender PCB Renders”
A few years back, a company by the name of Pano Logic launched a line of FPGA-based thin clients. Sadly, the market didn’t eventuate, and the majority of this stock ended up on eBay, to eventually be snapped up by eager hackers. [Tom] is one of those very hackers, and decided to try some raytracing experiments with the hardware.
[Tom] has one of the earlier Pano Logic clients, with VGA output and a Xilinx Spartan-3E 1600 FPGA under the hood. Due to limited RAM in the FPGA, and wanting to avoid coding a custom DRAM controller for the memory on the board, there just wasn’t room for a framebuffer. Instead, it was decided that the raytracer would instead “race the beam” – calculating each pixel on the fly, beating the monitor’s refresh rate.
This approach means that resource management is key, and [Tom] notes that even seemingly minor changes to the raytracing environment require inordinately large increases in calculation. Simply adding a shadow and directional light increased core logic utilisation from 66% to 92%!
While the project may not be scalable, [Tom] was able to implement the classic reflective sphere, which bounces upon a checkered plane and even added some camera motion to liven things up through an onboard CPU core. It’s a real nuts-and-bolts walkthrough of how to work with limited resources on an FPGA platform. Code is available on Github if you fancy taking a further peek under the hood.
If you’re new to FPGAs yourself, why not check out our FPGA bootcamp?
[Greg] implemented a simple ray tracer for Arduino as a fun exercise and a way to benchmark the processor. He started out with the Moller-Trumbore algorithm, a common ray-tracing algorithm that calculates the intersection of a ray with a triangular plane without doing any pre-calculation of the planes. His code supports one static light and one static camera, which is enough to render a simple scene.
[Greg] started out with a small scene composed of a few polygons, but just finished up a scene with 505 vertices, 901 faces, and reflective surfaces (shown above). He made the above render on his PC emulator, but estimates that it would take just over 4 days to render on the Arduino. [Greg]’s project supports multiple bounces of light, which differentiates his ray tracer from some we’ve covered before (and which explains why it takes so long to render).
The ray tracer is implemented entirely with double-precision floats. This translates to a ton of software float emulation instructions, since the Arduino doesn’t have a floating-point unit. While this ray tracer can’t render anything near real-time graphics due to the slowness of the microcontroller, it’s still a great proof of concept.
The title image for this post was rendered on a modern PC, taking 263 seconds to complete. The same scene, at 64×64 resolution, was rendered on the Arduino, taking 4008 seconds to complete. That render is below.