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.
-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)
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.
- Get an SD-card big enough to install raspian on it + a few spare gigs for compiling, i used an 8GB card.
- Install raspbian on it (basically follow the instructions on the raspberry pi website)
- 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
- 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
- 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
- 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
- chroot into your sd card’s system
sudo chroot /mnt
- set up some compiler things to make the build not stop on a certain error, execute:
- cd into /home/pi/panda3d-master
- 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
- 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
- (only need to do this once), edit your /etc/Config.prc
, comment the default pandagl line. if you run into gles errors, try using
you may want to enable threading,too.
- 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/
- 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
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.