CadQuery Editor

3D printing has brought many of us into contact with Computer Aided Design (CAD) when we might otherwise have remained ignorant, or perhaps have kept our 3D-modeling ambitions to Blender. As a result, Linux now has several excellent CAD tools that range from point-and-click 3D construction (Blender) and parametric modeling (FreeCAD), to programmable solid 3D modeling (OpenSCAD) and even Python libraries (CadQuery). Programmable 3D modeling is particularly well suited to 3D printing because it's often easier to describe what you want algorithmically than it is by dragging and dropping shapes into a canvas. You might start with a cube, for example, but then carve exact shapes out of it using intersection operators with a programmable set of instructions. This allows for objects to be created exactly in code, according to measurements and requirements, and also for parametric modification of a single element without affecting any other elements in the construction.

CadQuery editor is a great way to visualize the results of your Python code and debug the output as you build 2D and 3D objects.

Blender and even FreeCAD offer their own programmable interfaces to achieve the same thing, but CadQuery has been developed solely around this ability. It's similar to OpenSCAD, which is also entirely driven through a programmable interface with an editor and 3D preview so you can see what you're creating. OpenSCAD uses its own functional programming language with a JavaScript syntax that's easy to learn but can't be used anywhere else. As CadQuery is a Python library, however, you obviously use Python, and that means Python from your favorite editor or development environment. All it takes to create a rectangle, for example, is:

cadquery.Workplane("front").box(2.0, 2.0, 0.5)

This is more portable and reusable than a custom code engine, but it does have the downside of not having a 3D preview to help with your coding. This is where CadQuery editor helps. It's a GUI application that brings together Python coding with the visual output, in much the same way OpenSCAD does. Alongside a 3D preview of the object you're building, there are panels to provide an interpreter, a traceback and log viewer, and a variable and object explorer. These work a little like debuggers for your own code, and they're useful when what you expect to happen doesn't happen. While modeling, the 3D view updates each time you run your changes, and you can step into or through individual lines in your code much like a debugger to see how an object is constructed, which is something you can't do in OpenSCAD. When you've finished modeling, objects can be exported from the editor as either an STL or STEP file without any further programming.

Writing in Python with CadQuery can make more sense than using OpenSCAD because the scripts you build are fully functional without the editor. This means they can be run independently when you've finished your modeling. One example of this is the brilliant CadQuery VS Code extension, which is almost equivalent to the editor when it comes to capabilities and 3D preview and is a great alternative if you're already using VS Code. Either way, CadQuery very much feels like the next generation of modeling for 3D printing and all kinds of Computer Aided Design.

Project Website

https://github.com/CadQuery/CQ-editor

The CadQuery editor is really an IDE for Python: You can step through your scripts and watch how your models are constructed.

Flight simulator

FSHistory

Despite the CPU and RAM limitations of 1980s home computers, they were capable of remarkable things. And nowhere was this more evident than in the video games they ran. Games developers were able to push computer capabilities way beyond what was ever expected from a decade that started off with Breakout and ended with Ghouls 'n Ghosts. The most impressive games threw entire 3D worlds at the CRT, all from 8-bit integers stored in just 32,768 bytes of RAM. There was no better example of this than Elite, and then Microsoft Flight Simulator, first released in November 1982. Flight Simulator let you fly a variety of aircraft between various real-world airports in 3D with a moderate degree of instrument and flight mechanics realism, especially for the time. Sometimes you only got a few frames a second, and at other times the simulator became completely unresponsive, but it nevertheless felt like the future – something the 2020 edition of Microsoft Flight Simulator is only truly getting close to when you use a HOTAS and virtual reality headset (and a $2,000 graphics card).

Amazingly, especially considering the publisher, the decompiled version of Flight Simulator 4 is available under an MIT license, and FSHistory adds the supporting code and infrastructure necessary to make this build on modern hardware. In a humbling indication of progress, it takes just a few seconds to build FSHistory, and launching it takes an instant longer. The game now runs at hundreds of frames a second and is unlikely to ever become unresponsive, but it still feels like an authentic experience, requiring careful mouse and keyboard control to get anywhere. Because the code is identical, so too is the game, from the clunky menu system to the controls, graphics options, and windows configuration. You can't even resize the window because you couldn't in 1989 either. But if you can adapt your system to make it fit and you used to play Flight Simulator, it's the perfect nostalgia trip, virtually, from Oakland International runway number 28.

Project Website

https://github.com/s-macke/FSHistory

FSHistory is a version of Flight Simulator 4 from 1989 that will build on modern hardware. It is even hidden as an Easter egg in the 2020 version of Flight Simulator.