Why don't I see tile-based 3D graphics? As we know, tiles can make it quicker to update large portions of the display at once, as compared with a bitmap. To put, say a letter, on the screen, the Commodore 64 typically does two writes (the screencode and the attribute), but the ZX Spectrum typically does 9 (eight bytes which make up an 8x8 bitmap, plus 1 for the attribute).
Recently, a demo for the SEGA Genesis was released called Red Eyes. My understanding is that the 3D scenes were rendered on a PC, and some kind of program converted these animations to a tileset so that each frame can quickly be written into VRAM.
But, however hard I search I cannot find any contemporaneous games for these retro systems which use a tileset to render (an approximation of) three-dimensional graphics. So is there a technical reason for that?
I am asking because of a game I'm trying to write for the Commodore 64. My choice of platform has meant that the compute budget really is quite miserly, so of course I need to cut down on the amount of time spent pushing pixels to the framebuffer, and tile-based graphics are an obvious solution to that problem on this platform. Also I need to keep in mind the amount of time spent in 3D projection, and I believe this problem can also be solved with tile graphics, since for example a raycaster could cast one ray tile instead of one ray per pixel. But I'm unsure about that.
So the camera in my game is restricted to movement in one plane in the same way that the camera in DOOM is. It pans left and right only, and moves forward and sometimes backward. Plus I know that the walls in my game always are East-West or North-South. No diagonal walls. I think that this will mean that a manageably small number of pre-computed tiles will be enough to show the walls at various angles depending on how the camera is positioned.

The nature of this question is such that it could be answered in the following ways:

It wouldn't work because ...
You obviously weren't looking hard enough because here's an example of a game that does that. Here's a disassembly or source code so you can figure out how it worked
It might be possible, but you'd have to watch out for ...
This is not really an answer to the latter parts of your question but more to address

As we know, tiles can make it quicker to update large portions of the display at once, as compared with a bitmap. To put, say a letter, on the screen, the Commodore 64 typically does two writes (the screencode and the attribute)

What you are effectively describing is a compressed framebuffer where you are directly writing/storing compressed data and letting the display pipeline decompress on the fly.
I would say that such things &quot;still exist&quot; in today's games/hardware, but not perhaps in form you are expecting.

Compressed frame buffers do still exist. Mobile devices certainly do (for example Imagination/PowerVR have PVRIC, and I believe ARM devices have their own scheme)
These compression schemes are generally &quot;transparent&quot; to the programmer, but it does mean the GPU and display pipeline does less reading and writing of external memory.


A display decompression system like PCG  (Programmable Character Generator) is effectively a precursor to (and effectively a subset of) some texture compression schemes, e.g. such as S3TC/DXT1. In that sense, therefore it still exists, but users don't typically write directly to them, but certainly take advantage of the bandwidth savings.