"You have got to: swing it, shake it, move it, make it - who do you think you are?"
The Spice Girls, 1998 or whatever

Ever since the dawn of time (17th of May) I have been waiting to finally find enough time to really dig deep into creative works. So that is what I will do a lot of! Because I really like learning new things and creating stuff as I do. Always with my weird bespoke idea of what something should look like, even though it is not completely in the realms of absurdity - for the most part.
With powerful and complex tools comes the need to learn so much stuff and understand the relation of things. It is not a small task learning software packages that are not supposed to be casual hobbyist tools (asterisk) in a general sense.
But I want those. 

Ever since I was a kid I always wanted to understand "how is it made" and "with what" as an extension of that line of thought. 
Getting those answers and trying to inch my way forward to get better is really my whole philosophy (now for sale at €1200 per seminar + word salad containing passive income dividends cryptocoin metaverse MLM) for most things I do.

Let me give you an example of what I mean. I am not joking around 😁

Growing up I played video games of the 8 bit variety. Especially Megaman and Mario series. You may have seen traces of that here. I loved the weirdly flickering blurry action with the kick ass music. Not like anything better than that existed yet, but you get the idea.
It would be a bit of an overstatement to say obsessed, but in the lines of that sort of.

It all really started with the famous "-1" world glitch in Super Mario Bros. that I read about in a magazine and tried myself. I was so fascinated by this. Why? How?
More important after this fascination would be: how did the games get in there in the first place? What is the magic sauce that makes the stuff happen on the fuzzy ol' telly and is depending on a cartridge?

Let's open one of those grey things up and see. I broke the Adamns Family game cart because the game was crap anyways. Obviously we have some electronic components (I was not THAT stupid) and I figured early on that someone must have constructed games by stuffing settings inside one of these multi legged components.
By sheer luck I actually stumbled upon this knowledge in a magazine I bought at a flea market about computers from the mid 1980's. It explained to me that the NES is just a computer, really. Turns out someone (often Japanese) wrote instructions down somehow and stuffed it in those electronics. These were the very early days of the internet, so we had this thing called "paper" still. An ancient relic, look it up on wikipedia.

My games machine was based on an 8 bit MOS 6502 processor. The circuits inside the cartridge is called ROM and contains the code for the game and read through by the processor. Before computers were fast enough to deal with high level languages by abstract layers coding instructions directly by accessing memory through low level was the only viable option. Us humans with our fleshy brains do not quite like to read hexadecimal strings (aka machine code) like "AD00208D8060" - though if you are a low level programmer you can read that and know what it does - but instead prefer to structure programs in subroutines using instruction mnemonics in an assembler and turn those into machine code using a compiler to them transfer to an EEROM that will later be a masked ROM for mass production. 

Then came the emulators and theory could be put into realistic practice.

It turns out 6502 assembler is actually fun and quite intuitive to learn. Especially so for game consoles of the grey variety. The address space and program counter is 16 bit. Addresses from $00 to $7ff are RAM with $100 to $1ff being the hardware stack. After that comes a bunch of mirrors, open bus hooey and registers. At $8000 the normally mapped ROM starts and fills space down to the reserved vectors @ $fffa through $ffff. On the specific hardware you have a picture processing unit (PPU) that triggers an non maskable interupt on a certain scanline on the display where the CPU abrubts what it is doing and goes to where you set the NMI vector to. Pushing current values of the A, X and Y registers onto stack (or create a software one..) and then retrieving them in reverse order is recommended as you tend to clobber registers in your main drawing routine no matter what you do.
By manually turning the NMI off by writing a #00 to the MSB of PPU init/status register $2000 (and #$80) you can hijack what happens on every frame and add as many instructions for your hacks as you want. The sei instruction does not work on the specific version of the 650x family that the NES have nor does the decimal mode, I am not sure sei works with the NMI in this case regardless. The game would not run a whole lot slower because the 6502 is a beast. There would be speed decreases eventually though.

Here is what I would do in principle. Pseudo code obviously.

nmi:
pha
txa
pha
tya
pha // In very rare instances, a new NMI may actually trigger spontaniously because of the analouge nature of old hardware, so keeping this routine above short before turning the interupt off is adviced
lda $2000
sta temp
and #$80
sta $2000
and #$ff
sta $2002
jsr myroutine
lda temp
sta $2000
pla
tay
pla
tax
pla
rti

myroutine:
// do cool stuff here
inc routinecounter // in case you need some way of controling over how much processing time you want to waste or decide if it is really worth executing your code every single frame, it may not even be needed
rts

Obviously you would need to insert the game original NMI code in there aswell with a few alterations.
I would even recommend putting a php and tsx (+txa +pla) with plp and (pla tax) txs respectively in there just in case we mess something up. You could do some even nicer trickery by setting the exact timing of a frame with combinations of reading $2002 (bpl loop), but that would require good niche code to explain why that would ever be needed.
If the game depend on sprite #00 hit (such as the top status area in SMB), then that code would need to be executed regardless of hack (or you could be naughty and get rid of it completely).

Even if you do delay the frame trigger:
Avoid jmp nesting, backwards branching and loops at all costs and use as many quick and dirty unrolled read/writes as possible. If you have the luxory of zeropage not being fully utilized, go for it. Even more badass is to write a copy of your code into the CHR RAM or WRAM when available and let it be adaptable or even self modifying. Or you could put original code there and let that be adaptable through your custom NMI sequence. Using an MMC opens up so many other options I can't even begin to go through it all. Split screen and parrallax scrolling for Ice Climber? That would be so cool. It perfectly doable - with questionable use. 

Since I haven't touched NES hacking in over a decade I may have done something some small mistakes here. 

But you get the point. This was not a coding tutorial. Making my point from earlier as absurd as humanly possible.
All of this is real by the way, I am not making sh*t up.

The philosophy "how does it work" and "how is it made". Stopping at nothing until I know - more than I should probably.

Sooo... how does one create something like this in 3d? 

Hmmm... I wonder... let's find out.

Vacation is awesome. Be prepared! See what I did there omg lol asdfasdfaaa.