I have just completed a project, by which I downloaded, compiled and installed the 3D-game / 3D-application development software named Panda3D, on the powerful Linux laptop I name ‘Klystron’. That laptop is not to be confused with the less-powerful Web-server I name ‘Phoenix’.
This game-development kit started out years ago as a much-simpler project from Carnegie-Mellon University, which at the time I called a toy. But as it stands today, the level of sophistication and power available through Panda3D has grown tremendously. It is no longer a toy by any means, and is also one of the few game-dev platforms I know of, that can be scripted directly in Python.
One of the new features that make it interesting, is the ability to use Bullet Physics, especially since the simpler ODE (Open Dynamics Engine), game-physics engine, is broken on some platforms.
Another new feature is the support for a browser plug-in, that will allow games etc. to be deployed as Web-content, as long as the browser has the run-time plug-in installed. The actual embedded applet will then take the form of a ‘.p3d’ File.
One aspect of compiling this software that takes some getting used to, is that its python-based make-commands accept an ‘–everything’ parameter, which essentially tells the make-script to find all the relevant dependencies on the local computer, and then to configure the version of Panda3D we are compiling, to link only to the dependencies which were found, thereby either including some features or leaving them out.
I found that my only way to process that information, was to run the make command a first time as a dummy-run, and then to interrupt it. At the top of its build-log, it will show the power-user which libraries / dependencies it did not find, as if the intention was not to include those. After having interrupted this first run, I next went through my package-manager and installed all the packages named, which I felt might add some value to my build of Panda3D.
And so, after I checked out the GIT version of the software to a folder named ‘~/Programs/panda3d’ , and after ‘cd’ -ing to that directory, I felt that the following recipes were of use to me:
python makepanda/makepanda.py --everything --installer --no-artoolkit --no-egl --no-gles --no-gles2 --no-opencv --threads 2 python makepanda/makepanda.py --everything --runtime --distributor *yourname* --installer --no-artoolkit --no-egl --no-gles --no-gles2 --no-opencv --threads 2 /usr/lib/x86_64-linux-gnu/mozilla-firefox/plugins/nppanda3d.so /usr/lib/mozilla/plugins
Line 2 above configures the game-editing software, but the run-time must also be built, for two reasons:
- If a game has been developed, it must next be deployed to a recipient, without deploying the development-platform as well,
- The installation of the development-platform is not complete, without the run-time platform.
And so, Line 4 above builds the run-time platform. Both these lines have the ‘–installer’ parameter set, which means that they will each build a separate .DEB package, the second being much smaller than the first. We use whatever package-manager we have, to install the packages to our system, which we have compiled ourselves.
There is something to watch out for however, in the configuration of the run-time package. In order to obtain the browser plug-in, we need to make sure that we have the package ‘npapi-sdk-dev’ installed from the package-manager. And unlike how it went with the other missing libraries on ‘Klystron’ the Pythonic make-script did not warn me about that. Further, the .DEB package that results, will install the actual browser plug-in to the location I wrote in Line 6 above, as well as to put some additional symlinks to that .SO File, which actual Firefox browsers do not find. I needed to put a symlink manually into the location I’ve written as Line 8 above, which pointed to the same plug-in, before my Firefox browser actually recognized the plug-in.
This runs counter to the spirit of what the run-time package is supposed to do, which is, when we give it to our recipient, together with his package-manager, it should lead to a setup that runs our game out of the box, on his computer. When we need to tell the recipient that some assembly is required before this will run, it kind of spoils the show.
Also, when looking to use platforms such as Panda3D on free Linux-builds, the need is entirely not taken care of, of model creation. What the game-engine will allow the author to do, is write scripts in Python, that refer to Model Files and Scene Files, and to bind those together to animate as desired. But the actual model- and scene-files must first be sculpted using a model-editor, if not also, using a scene-editor. Panda3D offers a simple model viewer, but no graphical editor.
And so on Open-Source Linux, our best bet for this service, is the trusty application “Blender“. But, Blender does not export to the native file-format out-of-the-box, that Panda3D expects. Those files, believe it or not, are called .EGG Files, and we need to install a Blender add-on, that exports them. And so I also did the work today, of installing ‘YABEE‘ (“Yet Another Blender, Egg Exporter”), to the Blender version I have on Klystron.
Obviously, after having done all that work, I test many of the tutorials that come with the game-development kit. Below is a sample screen-shot:
And, given how I have written elsewhere, that the whole point of these programs is to allow the GPU to perform most of the graphics-output work, instead of leaving it up to the CPU, I suppose that a fair question a reader might have could be, ‘Why then, is it still so easy to use software, to take a screen-shot?’
The answer to that question is the fact, that even though the rendering of a 3D-scene-description to a 2D virtual-camera-position, has been carried out externally from the main CPU, that same rendering is nevertheless output to a frame-buffer, which the CPU can read pixels from…
(Edit : )
One fact which I clearly recall, is that hardware-rendering actually made a shift several years ago, away from the more-traditional Pixel-Buffers, towards using Framebuffer Objects (FBOs) instead. And the main reason seemed to be, the fact that FBOs are more-flexible, in the scenario of Render-To-Texture. The way consumer graphics-cards work, the display device – i.e. the monitor – just happens to be fed from one Framebuffer, which is special, among numerous possible Framebuffers, where any other FBOs are just not rendering to the screen.
Even hardware-rendering – by the GPU – needs to have a memory-location to output its results to.
Apropos Panda3D, on my computers ‘Klystron’ and ‘Phoenix’, I have Python versions 2.7 and 3.4 installed side-by-side, where under Debian 8, Python 2.7 is the default. When I used Python 2.7 to compile Panda3D, I also needed to have the package ‘python2.7-dev’ installed, without which the Python compile-script apparently fails to find Python – which is easy for a human programmer to overlook in the build log – so that Panda3D gets built without Python support.
What this means in more-normal logic, is that individual shared libraries are still linked, but that no Python Packages are installed, thus rendering Panda3D completely useless.
The Carnegie-Mellon specialists recommend we compile Panda3D with Python2.x , but some people experiment by compiling it with Python 3.y . In order for Panda3D to work at all for those people, they would need to have the package ‘python3.y-dev’ co-installed, likewise.
In such a case, I fail to see what advantage using Python 3 should bring.