3D Rendering on Teensy

Had to implement a speedomeneter gauge of course :D This uses a background image and renders a texture quad over top for the needle. It's using tiled rendering and consumes 20kb of RAM.

 
Going higher res and ported the 3D lib to this cheap 3.5" Kuman ILI9488 320x480 display w/ 8-bit parallel data interface :D On this display I was able get 49fps fullscreen color fill on Teensy 4.0. It's advertised as a pin compatible Uno/Mega display, but it was quite easy to get it working on Teensy as well. So if you are looking for a bit higher resolution display than ILI9341 to play with, this could work for you.

 
JarkkoL said:
Had to implement a speedomeneter gauge of course :D This uses a background image and renders a texture quad over top for the needle. It's using tiled rendering and consumes 20kb of RAM.

Click to expand...

Wow, that is smooth.

Would it be possible for you to share the code ?
 
Squeezed the 3D lib to run on Teensy LC, not so flashy but it works! :D
- Consumes 4.5kb of RAM
- Uses 32x32 pixel tiles (8-bit grayscale frame buffer, 8-bit depth buffer)
- 128 triangles, 64 vertices
I'm using the standard Arduino SPI interface, which is pretty slow. Not sure if there's more optimal way to update the screen for Teensy LC (Kinetis doesn't seem to be supported).

 
Here's a video about meshlet Hi-Z occlusion culling I added to the rasterizer. The occlusion culling is able to eliminate parts of the model as they are occluded by other models prior to any vertex and pixel processing thus reducing the rendering cost. In the video, when the bunny model dips into the cup the part occluded by the cup are eliminated. The culling is using meshlet bounding spheres which are tested against Hi-Z (low-res version of the depth buffer).

 
I'm thinking of buying these 3 displays and porting the lib to them:
- 5" 800x480, 24bpp, SSD1963, 16bit parallel bus
- 4" 320x480, 16bpp, ST7796S, 8/16bit parallel bus
- 4" 320x480, 16bpp, ST7796S, 4-wire SPI
However, what would be a good way to connect the 40/34 pin connectors in the first two to Teensy (3.6/4.0)? Obviously you can't just connect these to breadboard and hook with wires. I only need the display support, not SD card/Touch.

Also, is there other widely used displays on the market I should consider porting the lib to? For now I have ported it to:
- 3.5" 320x480, 16bpp, ILI9481/ILI9488, 8bit parallel bus
- 2.8" 320x240, 16bpp, ILI9341, 4-wire SPI
 
Last edited:
Well you can do it with breadboards, it is just not optimal.

What I've done in the past is solder up a prototype board with female headers for each of the Teensy pins (usually 2x12 for the Teensy 3.5/3.6 and the Teensy 4.0 with the carrier shields). And then I bring out the wire connections to a fixed order. For SPI, I originally used the order of one of the displays, but now I tend to break it out into 10 pins:
  • Power
  • Ground
  • SCLK
  • MOSI
  • MISO
  • CS pin
  • D/C pin
  • Reset pin
  • Alternate CS pin
  • Alternate CS pin

Then I make a custom wire setup going from the standard layout to each of the devices. I use the custom crimp pin setup from Pololu to make the custom wire assemblies. One problem I've had in the past is sometimes the male pin gets pushed out of the housing, so when I make new custom cables, I plan to put a dab of glue to hold it in place.

I put several links in the wiki:

<edit>
Another thing I've done in the past is lay out a breadboard or prototype board with the female headers for the Teensy, and then male headers placed in the right spot to mount the display. This way, you just move the Teensy from prototype board to prototype board. One example is the Adafruit featherwing displays aren't compatible with some feather processors (some you just cannot mount the display, some you would need to mount the display under the board), so I wired up a board to switch the around:

The prototype board I used was from robot50.net. That person is no longer selling the board, he/she has made the PCB files available that you can make your own version:

But if I was redoing it now, I might use this prototype board from Electrocookie that has two sets of 30 pin boards:
 
Last edited:
Ah yes, I think I could make proto boards for each display which maps from the display pins to some standard pin setup, and then another set of proto boards for each MCU to map from that standard pin setup to the MCU pins. This way I could swap MCU's and displays around without worrying about manually wiring them up every time I need to test different combinations.

"All problems in computer science can be solved by another level of indirection" .. "except for the problem of too many layers of indirection", so I hope the wire length wont be an issue :D
 
Last edited:
Added bilinear texture sampling support for smoother texturing :) In the video it's toggling between point and bilinear sampling to show the difference. I'm currently supporting 23 different texture formats, so it required some template code magic to avoid code redundancy while having fairly efficient implementation.

 
Just wanted to say this looks like a great software renderer.

I wanted to ask if you had any connection to the demoscene at all?
 
I can not believe the frame rate your getting for drawing anything to that screen. My ILI9341 takes seconds per frame. It drives me nuts! Who is this kurt and his ILI9341 library?

-jim lee
 
JarkkoL said:
Here's a video about meshlet Hi-Z occlusion culling I added to the rasterizer. The occlusion culling is able to eliminate parts of the model as they are occluded by other models prior to any vertex and pixel processing thus reducing the rendering cost. In the video, when the bunny model dips into the cup the part occluded by the cup are eliminated. The culling is using meshlet bounding spheres which are tested against Hi-Z (low-res version of the depth buffer).

Click to expand...

Quantum physics! Nothing exists without an observer. :D

-jim lee
 
Finally got my order of few different SPI & parallel interface LCD's from China for porting the renderer to :D Designed unified 26pin interface to quickly swap MCU's & LCD's
  • 1.3", 240x240, SPI, ST7789
  • 3.5", 480x320, SPI, ILI9488
  • 4", 480x320, SPI, ST7796S
  • 5", 800x480, 16bit parallel, SSD1963
  • 3.5", 480x320, 8bit parallel, ILI9486
  • 2.8", 320x240, SPI, ILI9341
lcds.jpg
Some more soldering to do to wire the interfaces :)
 
Ironically I've just got an HX8357D 480x320 display which isn't in that list - very impressed with the rendering, would like to join the party!
The HX8357D is ILI9341 clone I think but supports more rows&columns
 
jim lee said:
I can not believe the frame rate your getting for drawing anything to that screen. My ILI9341 takes seconds per frame. It drives me nuts! Who is this kurt and his ILI9341 library?

-jim lee
Click to expand...

First there is the ILI9431_t3 library written by Paul Stoffregen:

FrankB added DMA optimizations:

KurtE has his version (ILI9341_t3n):

Note, all of these libraries require you to use special pins for the CS and D/C pins based on the hardware capabilities. This pins are different depending on whether you are using a Teensy 3.x or Teensy 4.x processor.
 
You must log in or register to reply here.
Back
Top