Panda3d on the RaspberryPi2 with GLES2


#1

Hi folks!

It’s been quite a while for me to get active on panda3d again.
After my inital attempts at bringing panda3d to the raspberrypi(1) back in 2012, I decided to revisit the topic with the RPI2. I got first babystep results but it’s at a point worth sharing.

What works:
-Setting up an environment to compile panda on a regular Ubuntu Desktop (it still takes me 2h on my quad-core i5, I don’t think it’s worth trying to compile on the pi itself)
-Panda as we know it, with a few limitations on the render backend. TinyGL works, so does GLES2 (but it still needs a lot of bugfixing ,GELS1 still segfaults atm, we’ll come to that later)
-pstats is working nicely,too.

Performance you may ask? TinyGL can run most Samples at around 10Fps, not massive but good enough for debugging. GLES spits out 60FPS for most. Some samples like Roaming ralph are a bit cpu-limited, collision traversing on the very unoptimized terrain takes it down to 30fps (but about 70% of the time is spend with collisions so, go figure)

https://drive.google.com/file/d/0B48XgkYBTqDlTkVId3B4LW5KZHc/view?usp=sharing
For those who just want to give it a spin. It was build on raspian jessie 2015-09-24.

For everyone to replicate the steps so far, assuming you’r running a somewhat recent x/ubuntu/debian linux on your development machine:
Setting up your build environment would be the preparations.

  1. Get an SD-card big enough to install raspian on it + a few spare gigs for compiling, i used an 8GB card.
  2. Install raspbian on it (basically follow the instructions on the raspberry pi website)
  3. Boot the system once in the Rpi, set up your screen, expand the filesystem, maybe enable ssh, download the panda3d-master branch (i used the git version from 2015-09-25) and unpack it into the home directory, install all build dependencies as stated on the panda3d-git website (excluding nvidia-cg), download my patch from http://home.arcor.de/positiveelectron/files/pandaprpi2.patch and apply it
patch -s -p0 < pandaprpi2.patch

preparations for the rpi should be done so far. panda source should now be in /home/pi/panda3d-master/…
4. Put the SD-card back into your main Development machine.
5. Install qemu on your development machine.

apt-get install qemu binfmt-support qemu-user-static
  1. mount the sd-card’s / partition with exec rigths. in my case the card’s partition was on /dev/sdd2, and i mounted it to /mnt
sudo mount /dev/sdd2 /mnt -t ext4 -w -noload -o exec
  1. copy the qemu file onto the sd card, it’s just magic , no clue how it makes everything work
sudo cp /usr/bin/qemu-arm-static /mnt/usr/bin 
  1. open the file /etc/ld.so.preload from your sd card, (it should be on /mnt/etc/ld.so.preload)
    comment the line so it won’t get loaded, safe and close. be careful to not accidently do that to your dev-system’s file.

you only have to do steps 1 to8 once. (except for mounting the sd-card every time you want to work with it ofc)

so everytime you pop your sd card into your pc you should mount it with the command from step 6, then proceed:
9. more magic as i don’t exactly know why it’s required but qemu didn’t really work for me, nor did chrooting when i skipped this step. you basically bind some mountpoints.

mount -o bind /dev /mnt/dev
mount -o bind /proc /mnt/proc
mount -o bind /sys /mnt/sys
  1. chroot into your sd card’s system
sudo chroot /mnt
  1. set up some compiler things to make the build not stop on a certain error, execute:
export LDFLAGS="-Wl,-allow-multiple-definition"
  1. cd into /home/pi/panda3d-master
  2. start the build process (I like to nice the process so i can continue using my pc as usual, while the build only takes up free processing power)
nice -n 2 python2.7 ./makepanda/makepanda.py --verbose --everything --installer --threads=4 --no-eigen --gles-incdir=/opt/vc/include --gles-libdir=/opt/vc/lib 
  1. after a few hours of compiling (took about 2h on my quad core i5 or about about 6h on a 2.4ghz dual-core laptop) you should have a package ready for install
dpkg -i panda3d1.10_1.10.0_armhf.deb
  1. (only need to do this once), edit your /etc/Config.prc
load-display pandagles2

, comment the default pandagl line. if you run into gles errors, try using

load-display p3tinydisplay

instead.
you may want to enable threading,too.

threading-model Cull/Draw
  1. safely unmount your sd-card and the 3 binds from step
sudo umount ./mnt/proc
sudo umount ./mnt/sys
sudo umount ./mnt/dev
sudo umount ./mnt/
  1. pop the sd card out of your dev-pc, back into the raspberry, and give pview or any of your samples a spin.

Some of the known bugs and limitations currently existing:
-the code takes the window dimensions and sets up the video-core output to it. due to driver limitations it’s (at least i think) not possible to bind the gles output to the window, it’ll just draw ontop of the desktop with the size of the specified window (and not taking the window-decoration into respect when positioning). tinygl works properly
-there are issues with transparency, errors occur, things aren’t rendered correctly, like fonts etc they are all squares.
-there are issues with textures. not sure what, maybe texture formats, or the default shaders, anyway colors are a bit messed up and require fixing.
-gles1 segfaults due to some transparency thing. only gles2 gets past that error apparently.

There’s still lots of work to do to make it work all smoothly and correctly, but basically it’s proven to work.
Big thx to rdb for helping me debugging even silly issues.
For now i’ll need a bit of sleep.

oh if you guys set up ssh on the raspberry and want to start panda stuff ,be sure to issue this command befor executing anything

export DISPLAY=:0.0

this way your application knows to open panda on the raspberry’s screen and won’t error out. you still get the debug output via ssh.


#2

Yes! I’ve been hoping to see this happen, thank you for sharing your results. Please do keep up the good work.
If this was done a month ago I’d use the Pi2 instead of the non user friendly and expensive Gizmo 2 for my embedded device powered by Panda. However I have another project in mind and I might finally use a Pi this time.

What about 3rd party libraries like Bullet? Have you just compiled panda3d.core or those as well?

About fonts rendering as squares, I have a feeling it has to do with non-power-of-two textures.

For sharing files, just upload them to Google Drive or OneDrive.


#3

google-drive link (altho i sorta dislike google services):
https://drive.google.com/file/d/0B48XgkYBTqDlTkVId3B4LW5KZHc/view?usp=sharing

about 3rd party libs, here’s the makepanda status output:

Makepanda Final Status Report
Makepanda: Regular build
Makepanda: Compiler: GCC
Makepanda: Optimize: 3
Makepanda: Keep Pkg: PYTHON DIRECT GL GLES GLES2 TINYDISPLAY EGL OPENAL VORBIS ODE BULLET PANDAPHYSICS ZLIB PNG JPEG TIFF FREETYPE OPENSSL VISION GTK2 MFC WX FLTK X11 XF86DGA XRANDR XCURSOR PANDATOOL PVIEW DEPLOYTOOLS SKEL PANDAFX PANDAPARTICLESYSTEM CONTRIB SSE2 NEON
Makepanda: Omit Pkg: DX9 NVIDIACG EIGEN FMODEX FFMPEG SWSCALE SWRESAMPLE PHYSX SPEEDTREE SQUISH MAYA6 MAYA65 MAYA7 MAYA8 MAYA85 MAYA2008 MAYA2009 MAYA2010 MAYA2011 MAYA2012 MAYA2013 MAYA20135 MAYA2014 MAYA2015 MAYA2016 MAX6 MAX7 MAX8 MAX9 MAX2009 MAX2010 MAX2011 MAX2012 MAX2013 MAX2014 FCOLLADA ASSIMP VRPN FFTW ARTOOLKIT OPENCV DIRECTCAM ROCKET AWESOMIUM CARBON COCOA TOUCHINPUT

So according to that, bullet should be in there.I have not tested it tho.

Textures have quite some problems and require fixes but let’s solve one problem at a time.


#4

Hm, so FFmpeg and Collada is omitted? That’s unfortunate. Are there any video or audio formats Panda can open natively?


#5

There is no technical reason why they are omittet. I just didn’t have the dev-libs of those two installed.
For audio playback you can use vorbis(ogg). For video decoding you’d have to build with ffmpeg support. which shouldn’t be too much of an issue. Tricky with video playback is probably the lack of cpu power for decoding and color-converting the video. You may get away with some codec which gets away with bigger filesize and lower cpu power but for serious applications you’d probably have to drag in the videocore and integrate it more thightly with panda. just my 2 cents tho. i could try to compile with ffmpeg soonish (after setting up my hardware again).
Does the package itself work for you?

[edit] you might be able to use a webcam device as video stream, not sure but could work.


#6

I see.
I’m sorry, I don’t have a Pi2 at the moment to try it out, none of my projects need it so I don’t have one at hand, only bunch of Arduinos. The project I’m talking about I’ll probably working after a month or so.
Hope someone else can try it out before me and share their results.


#7
pi@raspberrypi ~ $ sudo dpkg -i panda3d1.10_1.10.0_armhf.deb
(Reading database ... 96026 files and directories currently installed.)
Preparing to replace panda3d1.10 1.10.0 (using panda3d1.10_1.10.0_armhf.deb) ...
Unpacking replacement panda3d1.10 ...
running ldconfig
ldconfig: /usr/lib/arm-linux-gnueabihf/panda3d/libp3framework.so.1.10 is not a symbolic link

ldconfig: /usr/lib/arm-linux-gnueabihf/panda3d/libpandaai.so.1.10 is not a symbolic link

ldconfig: /usr/lib/arm-linux-gnueabihf/panda3d/libpandaegg.so.1.10 is not a symbolic link

ldconfig: /usr/lib/arm-linux-gnueabihf/panda3d/libpandaode.so.1.10 is not a symbolic link

ldconfig: /usr/lib/arm-linux-gnueabihf/panda3d/libpanda.so.1.10 is not a symbolic link

ldconfig: /usr/lib/arm-linux-gnueabihf/panda3d/libpandaskel.so.1.10 is not a symbolic link

ldconfig: /usr/lib/arm-linux-gnueabihf/panda3d/libp3vision.so.1.10 is not a symbolic link

ldconfig: /usr/lib/arm-linux-gnueabihf/panda3d/libpandafx.so.1.10 is not a symbolic link

ldconfig: /usr/lib/arm-linux-gnueabihf/panda3d/libp3dtoolconfig.so.1.10 is not a symbolic link

ldconfig: /usr/lib/arm-linux-gnueabihf/panda3d/libp3dtool.so.1.10 is not a symbolic link

ldconfig: /usr/lib/arm-linux-gnueabihf/panda3d/libp3interrogatedb.so.1.10 is not a symbolic link

ldconfig: /usr/lib/arm-linux-gnueabihf/panda3d/libpandabullet.so.1.10 is not a symbolic link

ldconfig: /usr/lib/arm-linux-gnueabihf/panda3d/libp3direct.so.1.10 is not a symbolic link

ldconfig: /usr/lib/arm-linux-gnueabihf/panda3d/libpandaexpress.so.1.10 is not a symbolic link

ldconfig: /usr/lib/arm-linux-gnueabihf/panda3d/libpandaphysics.so.1.10 is not a symbolic link

ldconfig: /usr/lib/arm-linux-gnueabihf/panda3d/libp3tinydisplay.so.1.10 is not a symbolic link

dpkg: dependency problems prevent configuration of panda3d1.10:
 panda3d1.10 depends on libbulletcollision2.82; however:
  Package libbulletcollision2.82 is not installed.
 panda3d1.10 depends on libbulletdynamics2.82; however:
  Package libbulletdynamics2.82 is not installed.
 panda3d1.10 depends on libbulletsoftbody2.82; however:
  Package libbulletsoftbody2.82 is not installed.
 panda3d1.10 depends on libjpeg62-turbo (>= 1.3.1); however:
  Package libjpeg62-turbo is not installed.
 panda3d1.10 depends on liblinearmath2.82; however:
  Package liblinearmath2.82 is not installed.
 panda3d1.10 depends on libode1; however:
  Package libode1 is not installed.
 panda3d1.10 depends on libstdc++6 (>= 4.9); however:
  Version of libstdc++6:armhf on system is 4.8.2-21~rpi3rpi1.
 panda3d1.10 depends on libtiff5 (>= 4.0.3); however:
  Package libtiff5 is not installed.

dpkg: error processing panda3d1.10 (--install):
 dependency problems - leaving unconfigured
Processing triggers for desktop-file-utils ...
Processing triggers for shared-mime-info ...
Processing triggers for man-db ...
Errors were encountered while processing:
 panda3d1.10
pi@raspberrypi ~ $

#8

Using dpkg to install packages won’t resolve dependencies correctly. Try “sudo apt-get install -f” to resolve these issues.


#9

Hi! Very good work! Here are my questions:

1/ Do you have any experience with Raspberry Pi 3?

2/ Do you know if Panda3D could be GPU accelerated, as the pi3d project?

3/ What are the “few limitations on the render backend”?

4/ Would you recommand this binary to develop projects, or is it an experiment at this point?

Thank you :slight_smile:


#10

1: i have no raspberry pi 3 to test it against.
2: it is GPU accelerated already using GLES2 (as stated in the topic headline)
3: it doesn’t integrate with the windowing system, texture colors may still be off etc. tons of things to iron out.
4: very experimental. certainly not for production use.


#11

Hello; I was able to build and run Panda on a Raspberry Pi 3 using your instructions. It works! I did run the build on the Raspberry Pi itself, on an Arch Linux ARM installation (the armv7l one, not the AArch64). I used 2GB of swap space in addition to the 1GB of RAM on the Pi 3.

Some notes:

  • The original patch no longer works with the git master branch. I used commit cf105f2 and several hunks failed, so I went through and applied the changes manually. The atomicAdjust and deletedBufferChain modifictions are no longer necessary; the changes actually exist now in the git repository. As for the EGL tweaks - I just carefully read your patch, found the appropriate locations and typed the modifications myself.

  • On Arch Linux ARM, the same dependencies you’d need on a distro using apt-get do exist, just named without ‘-dev’. Also make sure to install gcc. You can’t use --installer on Arch, so it’s necessary to just use installpanda.py after the build. Running

ldconfig

was also needed after running installpanda.

  • Using pandagles2, in my experience, caused graphical glitches and missing textures. When I used pandagles (as it originally appears in Config.prc), things worked very nicely.

  • Everything runs at a very solid 60fps at 1280x720, and about 50fps at 1920x1080. (Resolution can be set in Config.prc; the ‘fullscreen’ option does not work though, likely due to the lack of proper windowing support.)

Using pandagles, all of the samples (that don’t use Cg) look good, except for Asteroids, in which the asteroids are all white blocks. That’s the only graphical anomaly I can see (although there appear to be many more graphical problems with pandagles2). In pandagles2, for example, the maze model in the Ball-In-Maze sample does not render at all. With pandagles, it’s perfect.

The VideoCore IV is a nice little GPU. I’d say that Panda is the best (and the only, really) option for a 95%-working 3D library / game engine on the Raspberry Pi. The lack of windowing support didn’t bother me, since just putting your command in the .xinitrc file and using ‘startx’ at a terminal works well to launch a Panda application outside of a desktop environment. (And, again, resolution can be set in Config.prc).


#12

Hey! I got the precompiled version (panda3d1.10_1.10.0_armhf.deb) by ThomasEgi to work on a Raspberry Pi3. That’s already fantastic!
It runs the examples - however when I maximize the window most stuff slows down / stutters quite a bit. It does not look like the >= 60fps that user aedancullen observed.

Starting any example shows me these errors at the start (and then continues to run):
libGL error: MESA-LOADER: failed to retrieve device information
AL lib: (WW) alc_initconfig: Failed to initialize backend “pulse”

Any ideas on how to make things faster (/ solve the startup errors)?

(P.S.: I enabled the GL Driver under raspi-config - don’t know if that makes any difference)


#13

I am really surprised the old precompiled binary still works (more or less, as i have doubts about 3D acceleration being used).

I ordered a RPi3 for myself this weekend so I can get back to testing things. With the release of the OpenGL driver there’s a whole new playground. Panda should (in theory) now compile with no modifications or hacks prior required to work around the GLES setup steps. So yeah, lots of stuff to try out. And thanks for pointing me to that OpenGL driver development, I would’ve totaly missed that myself.


#14

Wait, pure OpenGL? Interesting. Do keep us updated when you get your Pi3 and test this.


#15

A couple of days passed and my RPi3 was starting to collect dust on my desk. But now (and thanks to rdb for fixing some ARM-build bugs) i finally managed to give it a spin. I decided to build with python3 support just because the waaaave of the fuuuutuuuure~~~

The procedure is almost identical to the one I posted on the very beginning of this thread, except you don’t need to apply any patches as it’s pure opengl now. Instead you want to activate the opengl driver in the raspi-config tool (others=>opengl=> thingy with full kms, maybe try fake kms too). And of course you invoke the makepanda script with python3 (if you want to).

Without any further optimization roaming ralph runs around at 21 to 27 fps in fullHD. Carousel demo runs a tad faster. On 800x600 resolution things settle at around 40fps. software rendering is about 2 to 4 fps for comparison.

There still are a couple of things to try to make it run faster (compiler optimisations, enable threading etc). Given this is just a beta-driver there may be quite some improvement on the driver end too. It’s certainly a promising platform to toy with.


#16

Nice work!! If I get a Pi, I’ll definitely try this :smiley:


#17

I want to run Panda on an Asus Tinkerboard. Should the compilation process be the same?
It has a ARM Cortex-A17 CPU and Mali-T764 GPU.


#18

Hi Shifr, iirc on any board supported by github.com/ptitSeb/gl4es.
with --use-gles2 and maybe --no-eigen options.
still for onboard build you would need 3GiB ram so maybe add 1 or 2 GiB swapfile.


#19

3 GB ram? why?


#20

@Shifr, that’s for gcc it is memory hungry for building some parts of panda3d, it is a one time use no problem swapping on sdcard ( dd if=/dev/zero of=tempswap bs=1M count=2048; mkswap tempswap; sudo swapon tempswap ).