The lion kingdom set to the task of porting the Bill Budge 3D graphics system to the commodore, manely to try to improve the glxgears demo.  It was apparently never released in source form.  There's only a disassembly.

https://6502disassembly.com/a2-budge3d/MODULE.SHIP.CUBE.html

A character generator was added at some point, probably for debugging without an emulated printer.  

The journey began with painstakingly pasting all the block hex codes into a converter to generate .byte tables.

He starts local variables with ].  Wherever  there's  a dfb, it's reserving a byte of program memory & setting it to the given value the same as .byte in cc65.  Lions put those in  zero page or made them literals.

A lot of variables are stored in zero page addresses which happen to also be unused in C64 assembly.  He only draws in the 1st 256 columns, the same way lions did.  The Apple II stored 7 pixels per byte with the MSB on the right.  Each row was 40 horizontal bytes. 

The pixel drawing is built into the line function where lions used a separate plot function.  It only recomputes the row pointer when it has to so horizontal lines draw faster.  Vertical lines still recompute the column pointer for every pixel.

It takes self modifying code to the point of overwriting opcodes.  Despite this, he still ores the row table with the current bitmap start address to get addition without clearing the carry bit.  He could have self modified 3 uses of the row table.  The biggest speed gain might come from XORing  the image instead of clearing the entire screen.  XOR was something unique about pinball construction set, along with neglecting the multicolor pixel codes.

At the same time, the lion program used line optimizations made 15 years later.

The  budge disassembly doesn't contain enough to  run it.  It's definitely not a simple porting job.  It needs an applesoft BASIC program which creates a bunch of arrays of opcodes.  Then it runs the opcodes.  That part is described in

https://www.apple.asimov.net/documentation/applications/misc/Bill%20Budges%203-D%20Graphics%20System%20and%20Game%20Tool.pdf

You had to be pretty motivated to dig through that document in 1980.  It's kind of like the instructions for a modern AI framework.  As one who depended on the source code to learn how to use it, it's hard to imagine anyone got very far without source code in 1980.

After much contemplation, the decision was made to keep the original CRUNCH API & move the applesoft arrays to assembly language tables.  As bloated as the CODE opcodes are, it seems to be a  more abstracted way than manually calling the transform & draw commands.  The trick is the applesoft arrays were uint16's while the assembly language arrays are bytes.

Set the scale or rotation above maximum & it'll skip that step to aid in debugging.

The next problem was .align in ca65 wasn't aligning the tables on 0x100 bytes because the linker put it at 0x080d.  The linker & assembler don't talk to each other.  Getting ca65 to properly align the tables took random tweeks to the .align  tags & eventually just abandoning alignment for some tables.  Some of the alignments burned a lot of memory to save a couple instructions & gained no speed. 

All that arrived at a simple demo.  Sadly, the source code for McFadden's video was not easily found so just made some simple rotation demos.  The budge library rendered a cube at 9.1fps & the mclionhead library rendered a comparable cube at 6.6fps.  That was memsetting the entire bitmap to clear instead of using XOR.   XOR was slower in the budge library for an object as large as the cube.

A 37% speed improvement was a big deal.   The only glaring defect was the rotation being  limited to 28 steps.  The rotation tables actually have 256 steps but he indirected them through a 28 entry table for some reason.  The lack of perspective might require some adjustment to the glxgears model.  Since most of the speedup is in the line routine, it might be better to just copy the line  routine.  The resolution is so bad, orthographic mode might work if the angles are tweeked.