Mipmapping is a good way to add a lot more detail to a 3D scene without overburdening the rendering hardware with detail that won’t be seen by the user. This level-of-detail rendering technique was demonstrated on the N64 console hardware a few years ago by [James Lambert] with [Michael Biggins], also known as [PhonicUK], now demonstrating it on the ESP32-S3 using his own Jet rendering engine.
Although level-of-detail rendering really speeds things up, it does also require far larger texture sizes, with [James]’s N64 demo taking up 40 MB of a 64 MB cartridge. To fit it on an ESP32-S3 with 16 MB of PSRAM and no SD card expansion or such the textures were further compressed to use 8-bit indexing, resulting in a mere 5.01 MB of textures.
There’s a demonstration video over on the associated Reddit thread, which shows the camera moving through the scene. Even if not as exciting as the Wipeout port by [Michael] that we previously covered, it does make clear that even without a proper 3D GPU the ESP32-S3 is already a pretty capable gaming machine that can go toe-to-toe with some 1990s consoles.
i guess everyone likes the s3 now. im evaluating it as a replacement for the arduino pro micro ive been using for control projects, because the high resolution sensors im using tend to slow down the sampling rate. but im not sure i like its usb stack, which i need to push high res sensor data to the usb stack on the host.
unrelated i have been considering the possibility of replacing raster textures for vector ones. such that you always can get the best possible detail at all zoom levels, and without consuming egregious quantities of ram. this might be of use for rendering engines on low spec hardware, but also in lieu of ram shortages.
Along the same lines
https://techxplore.com/news/2026-09-ai-generated-scenes-properly-user.html
https://techxplore.com/news/2026-09-ai-generated-scenes-properly-user.html
Esp32s3 has enough power to do this but psram is bottleneck. Next one esp32s31 solve slow psram hogher speed more bits and separate bus from flash . So it solve all problems
For comparison:
ESP32S3: Octa(8)-SPI PSRAM running at 80 MHz (or 120 MHz in experimental mode and only with 120 MHz Flash)
ESP32P4: Hexa(16)-SPI PSRAM running at 250MHz
ESP32S31: Octa(8)-SPI PSRAM running at 250MHz
So the ESP32P4 should be the fastest.
The code seems to be still prepared for the P4:
“the shared runtime contains P4 code but this project does not ship a tested P4 configuration.”