Get Info: #openscad

OpenSCAD to Sprite Sheet workflow

by Matt Sephton — Wed, 04 Oct 2023 15:19:00 +0000

I just released the “OpenSCAD to Spritesheet” workflow I created for Daily Driver:

github.com/gingerbeardman/openscad-spritesheet

It’s a Frankenstein mish-mash of a Makefile and several shell scripts that evolved over many months/years. Initial rendering is done using OpenSCAD, and post-processing is done using ImageMagick. Model poses and rendering variations are controlled by variables in either the shell script or passed through to the model. The whole process is optimised to do as much in parallel as I could figure. More info at the link above! 🚗💨

Post Processing

After exporting all frames there is some image magick work to process the files as follows:

stitch frames together into a single sprite sheet
split sprite sheet into RGBA channels
process channels to recolour and dither as required
recombine processed channels into new sprite sheet image

You can read about that in a previous blog post.

Benchmarks

A full build of 36 cars is as follows:

3GHz 6-core Intel Mac mini 32GB
- 100% CPU for ~26 minutes
M1 Pro 10-core MacBook Pro 16GB
- 70% CPU for ~9 mins
- about 3x speedup
- approx 16 seconds per car

That’s parallel 3D rendering, PNG writing & compositing & processing, and copying of ~140K files (which takes up ~0.5GB of disk space).

Example Model

Not to scale! Sizes of features are exagerated to allow for them to appear correct when rendered at a very small size.

Example Output

990 frames each for car and shadow, total of 1980 frames per sprite sheet. Each sprite sheet takes up about ~400KB of RAM on Playdate, and only one is loaded at a time.

Daily Driver: Club GTi

by Matt Sephton — Tue, 08 Mar 2022 12:32:00 +0000

My GTi Club: Supermini Festa! obsession has bled into my game Daily Driver… the “Club GTi” car features smaller wheels than the standard size, more roll during turning, and lots of detail and decoration to show off the rendering workflow I spent so many hours on. A good choice for the autotesting/motorkhana/gymkhana stages.

Here’s the 3D model, created in OpenSCAD.

Daily Driver: Pseudo-HDR

by Matt Sephton — Fri, 21 May 2021 00:00:00 +0000

I love OpenSCAD “the programmer’s solid 3D CAD modeller”, despite its idiosyncrasies. One of the quirks that causes me most pain is the lack of controls for scene lighting in the Preview render. Unfortunately, I use that very Preview render as my main output!

This lighting issue manifests as shadows cast on the model. As I rotate the car some white “highlight” elements become darker. At this point the model is made up of many more shades of grey than I’d like.

The problem escalates when I take the Preview renders and convert them to 1-bit (black and white) ready for display on Playdate. I use a simple threshold conversion where any pixels darker than the threshold value become black, and any lighter become white. The highlight elements that have been cast in shadow are now grey and in many cases after the threshold conversion they end up as black pixels when they should be white. The net visual result is a loss of detail as well as flashing elements as they disappearing on certain frames.

My first attempt at solving this problem was to set model-specific threshold levels. This worked to a degree but there were still elements that would flash on and off as the car rotated, with headlights being the most noticeable. Whilst I lived with the issue for a long time it always bothered me as it did make the sprite feel buggy. Deep down I knew that the results could be better. However, looking at the OpenSCAD development roadmap made it clear that any improvements would have to come from me.

One day, out of the blue, I realised that if black pixels are more reliably rendered then why don’t I take advantage of that and render the model in opposite colours so that the highlights are now black. After rendering I could simply negate the colours in the resulting image and the highlights would become white again. I tried a quick test and the results were good!

Of course this means an additional render stage is added to my workflow, but that’s of little consequence since the Makefile is doing all the hard work. I also had to make some changes to my render scripts so that the normal and negative images are composited together into the final image. The resulting sprites have no flashing elements, maintain more fine detail, and appear a lot more solid as a result. Excellent!

Afterwards it struck me that this process is similar to HDR photography where multiple photographs are combined to increase the dynamic range in the final image. So, just for kicks, I’m referring to this technique as HDR 1-bit rendering.

Daily Driver: Pre-rendering Ranger

by Matt Sephton — Tue, 18 May 2021 00:00:00 +0000

Since very early on shadows in Daily Driver have just been simple rectangles: one size fits all, rendered from a single 3D model, and post-processed to add dithering. MVP, you know? Over time I decided to do multiple shadows, one each for short cars and long cars.

Sometime later I threw caution to the wind and decided to render per-car shadows. However, the OpenSCAD projection() command that I was using was so slow! In fact it zapped my desire to finish implementing the feature. Instead, I let it sit for many months.

Recently, I picked things up again to get the a new trailer and demo out. And then it hit me, that if I flatten a car on the z-axis—as if Looney Tunes dropped a heavy weight on it—then that flat thing will be a close enough equivalent of a shadow for my use. So I did just that and the results were great, and more importantly very quick to render!

So I went all in and decided to not only render one shadow per-car but to render shadows for each individual frame. So now the direction of the front wheels and details of the body shape are reflected in the shadow. It might sound like a small thing but it really makes a big difference. You can see old vs new shadows in the image carousel below.

It’s in situations like these that I’m really proud I put a ton of early effort into the tooling and build process that generates my sprites.

Result!

Daily Driver: Automation Improvements

by Matt Sephton — Fri, 09 Oct 2020 00:00:00 +0000

The recent automation was really just help with organisation. As soon as I started looking at running OpenSCAD from the shell/command-line it became obvious that I could do the rendering and organisation in one step without having to use external apps like Hazel.

So, that’s now done. I render all the frames, with more sensible filenames, to a single folder.

If I run all the renders one after the other, maxing out a single CPU core (99% CPU usage), time taken:

~17 seconds 🐢

But, using the & directive and wait command, I can run the renders in parallel (well, technically it’s one process each; and batches of 32 works best) using all 6 CPU cores (~485% CPU usage), time taken:

~10 seconds 🐇

…the beauty of the command line!

Note to self: don’t publish a post about an automation breakthrough until the dust has settled.

Daily Driver: Automation

by Matt Sephton — Wed, 07 Oct 2020 00:00:00 +0000

In preparation for regenerating my many cars with x3 the number of sprites, I thought I’d try to sort the rendered frames automatically into named folders because this is fiddly manual work I really don’t enjoy, and a bit of a bottleneck in my asset generation. For each pose I have to render the frames then group the new image files into a folder that describes that pose, as these multiple folders are later be used for batch processing.

I could use macOS Folder Actions for this, but I’ve been using an app called Hazel for many years to do this sort of thing, so that was my first choice.

The hard work is done with a shell script, as I’m quite comfortable writing those.

Flow

get most recently saved .scad file
parse filename to capture car name
parse file contents for left/right/forward/backward tilt values
concatenate all this information as our new folder name
create new folder
move matching file into new folder

This means that the folder name will change based on the render settings in the file—perfect!

I still have to make 9 small sets of manual text changes to render each car pose, so that’s the next thing I’ll try to automate by running OpenSCAD from the command line.

Daily Driver: Post-processing workflow

by Matt Sephton — Mon, 10 Aug 2020 00:00:00 +0000

My post-processing to 1-bit is fairly simple. I use a bespoke tool that allows me to have “live” (realtime) manual control over a bunch of image filters so I can see the results immediately.

But essentially it’s:

convert to greyscale, using one of many algorithms
reduce colours to 1-bit, decide on dithering or threshold level on case-by-case basis

The grey shades that I applied to my model in OpenSCAD give an element of control during this conversion process. Greys can be pushed either way, towards black or white, depending on my need with the specific model I am working on.

In this instance I desaturated the greys which blows them out to nearer white. And then I chose to threshold to reduce to b/w.

I also have the wheels as a separate finished image so I don’t have to worry if their detail is lost during this phase, I can just paste over the accurate/finished wheels.

Final result, unedited:

I would later touch up the sprite by hand to reinforce any details I think have been lost. I use Piskel for edited sprites because it has really nice sprite sheet support, drag and drop loading, and quick and versatile exporting.

Aside: 32 is a number that is a leftover from a different prototype and it’s stuck. I guess it should really be 36? or 24? or 18?. But it’s too late now! Actually it would be relatively easy to change but I have bigger fish to fry.

The animations alone could run at 99fps—it’s anything that causes more drawing which slow things down. Collisions, not because they are computationally heavy, but because they cause a lot of sprite updates - which means drawing moving things - to happen. I’m working hard to maintain 60fps on device (50fps in simulator for… reasons) and am excited I’ve managed to get here.

Daily Driver: OpenSCAD workflow

by Matt Sephton — Sat, 08 Aug 2020 00:00:00 +0000

I took the plunge and upgraded to a Mac mini and 4K display so had to migrate my setup and then figure out why my workflow was broken (spoiler: retina!) compared to my old rMBP with non-retina display.

So, my workflow uses the following apps:

OpenSCAD “The Programmers Solid 3D CAD Modeller”
Retrobatch “a unique application for automating actions on multiple images at the same time”
post-processing “greyscale and dithering tool” (I use my own realtime tool, but any image editor would do it to a degree, see this other thread)

This is so I can re-run a workflow at any point (maybe in a make file) which I often do during development. These become executable assets, of sorts, in my project.

OpenSCAD

define 3D models (I get a feeling like coding CSS in a strange way)
animate the model spinning through one 360-degree rotation
dump frames out as PNG files

Here’s the model definition to try out:

I love building 3D this way, it’s kind of like LEGO. I use basic geometric building blocks (cube, sphere, cylinder, polygon, etc) and some boolean operations (difference, intersection, union). There are some other cool things (hull, minkowski). I have the commands in Dash.appalongside the Playdate SDK docs.

In the image 2 you can see what the model looks like with all the blocks I have used to make it visible at once.

My particular approach is subtractive— kind of like sculpting—I start with large blocks and cut away at them using other shapes and the difference function. When finding the exact placement for a block I use the # precedent which makes the blocks show up as semi-opaque red blocks. See main image.

I colour each block in a one or two shades of grey, black and white. This is to help with the conversion to 1-bit later on. It’s not so obvious here as the lighting makes the colours look many different shades - for example the wheels are black with white centre but look grey here. See image 3.

Using some simple programming constructs and variables I can add booleans to trigger different states, I use this for angled front wheels and tilted car body. See image 4.

And also to set the distance and rotation of the camera relative to the model when in animation mode. In this mode I enter a speed (doesn’t matter but higher the better) number of frames = 32, and the tick the box to dump the images. The tick disappears when the images are all done. See image 5.

I also rendered the skid marks, car shadow, and some other elements.

There is a lot that is annoying about this app

not retina-optimised (so I run it in Low Resolution, set using Get Info on the app)
runs maxed out on a single core
doesn’t have configurable lighting (I’d prefer uniform or no lighting)
Qt Framework app, so not really macOS-native
etc

…but I still use it! I am not aware of anything else quite like it.

Daily Driver: from 3D to 2D

by Matt Sephton — Wed, 27 May 2020 00:00:00 +0000

At this point, the only thing that remained of the prototype was the car sprite so I wondered about creating a new one myself. It uses 32 different images of the car with different rotations, making for smooth animation and movement on screen.

Whilst I could draw all those frames by hand, I decided to go down a path that could produce assets on demand. That way if I change my mind I can reprocess the assets whenever I feel like it. The initial process was easy to setup, but I’ve been taking and simplifying the automation process ever since.

I’d previously used OpenSCAD to create 3D models, so it was a natural and easy choice. Also, it’s the only 3D app I’ve ever used—not even Blender! Models are created using a definition language (think of it as a bit like CSS) where you can define shapes and how they interact. I also use the animation function to set the viewpoint and rotate the car whilst automatically saving the images.

In OpenSCAD I lock the view angle and zoom. I tie rotation to the animation value $t. Then I run the animation and click a box to have the app spit out all the rotated images for me.

The output images need a little post-processing, so I use a single Retrobatch workflow to: crop, add transparency, invert, a few other things, and finally stitch the 32 images into one long sprite sheet. (On Windows you can use Photobat)

Finally, I run the sprite sheet through a bespoke dithering tool that allows for “live” manual tweaking to convert the greyscale images to 1-bit.

That’s good enough for my current requirements. Later on I would want extra detail in the renders, either through texturing or by hand.

29 May 2020. Soon after I would start rendering the wheels turning and after that the body so it rocks from side to side.