I took screenshots of all the Perl Ogre demos. It gives an indication of how the project has progressed over the past few months. Although screenshots are insufficient for animation or sound demos, I give explanations and you can use your imagination. If you want to try them, install the Ogre modules from CPAN. Most of these demos are originally from OGRE tutorials or the samples that come with OGRE, OgreAL, and the OGRE wiki, so you could just install those as well.
This is the first thing I made work in Perl with OGRE 3D. It loads a robot mesh and attaches it to a scene node, then rotates and scales it. It's a minimal app that doesn't even handle input, so in order to exit you have to close the window then Ctrl-C.
The ninja demo adds lighting, shadows, and a textured plane, and handles input of the Esc key to quit the app.
This is the same scene, so the same screenshot, but the demo shows how to use the FrameListener interface to listen for user input events (still only the Esc key). It does this through "unbuffered" input, which means that events are processed by callbacks immediately.
The same ninja but no distracting background, and now we see his back. This demo shows how to do "buffered" input, and was the first one to use the Ogre::ExampleApplication and Ogre::ExampleFrameListener framework (used by the C++ OGRE tutorials). You can move the camera around with the arrow keys (and PgUp/PgDown) and the mouse when you hold the right mouse button. Pressing 1 or 2 toggles the camera position between two locations.
A SkyBox is a texture that's applied to a big box in the background. This demo shows a space scene with planets and stars. In the foreground there's a terrain that has shadows. The camera can move about freely as before.
A SkyPlane is the same idea as a SkyBox, but the texture gets applied to a plane instead. If you can never see below a terrain, then you don't need a whole box. This one is really evil looking and reminds me of Oblivion. There is also a dark, exponentially increasing fog.
This was the first demo where objects in the scene actually moved without moving the camera. The robot has a "Walk" animation which he does on the way to the first waypoint, at which point he gets rotated with a Quaternion to face the last waypoint and continues walking. After reaching the last waypoint, he executes the "Idle" animation, which is what you see in the screenshot. Except it's not moving.
This is meant to demonstrate adding an Ogre render window to a Gtk2-Perl application. It's a neat idea in principle, but isn't working too well yet. Whenever you click the Gtk2::Button labeled "Dance!", the camera toggles to the opposite side of the robot, giving the impression that the robot flipped around. Sorry to spoil it if you thought the robot really danced. (One step forward and two steps back?)
Here the camera zooms around, while always tracking (looking at) the ogre head. The interesting part is setting up the camera movement. To do that, an animation is created with a few "key frames" (waypoints at a certain time), and the animation does a spline interpolation between those points. It therefore swooshes around like a bird rather than jumping from point to point as in the robot dance demo. (The reason the background gets white is there is a fog applied.)
This is the most spectacular demo. There are two "fountains" rotating around beneath the ogre head, showering particles; flat, smoky rings rotate and rise up around him; rain is falling (easier to see when you point the camera upward); and bright green blobs of light bubble up from him.
This has ladies, called "jaiquas", sneaking around wearing some kind of futuristic diving suits. They start out around a circle rotated by 60 degrees each one with respect to the next. Each animation is started at a slightly (randomly) different time, and moves at a slightly (randomly) different rate, giving more of a choatic feel as opposed to if they all did the same animation in lockstep. If you press the 'r' button (which you can do with any demo based on ExampleFrameListener), everything is shown in wireframe, giving a kind of Tron-like appearance.
Normally I'd put this after the SkyBox demos, but I want to keep things chronologically ordered here. In the sky demos, you can move the camera freely about, as if it was mounted on a helicopter; you can even pass through the terrain. In this demo, the camera is constrained to always be 10 units above the terrain, so it is more like the camera is mounted on a (very smoothly riding) land vehicle. It reminds me of the 3D battle scenes in the game Medieval: Total War. The way it works is by using a RaySceneQuery. The ray (long arrow starting from a point) starts at the camera and goes downward, at some point intersecting with the terrain. The scene query part tells you where this intersection is, so you can then update the camera position to always be 10 units above it. It's not as inefficient as it sounds; as you can see in the screenshot, the scene is being updated 330 times per second (with a terrain and fog).
Lighting and ribbon trails
The ogre head again, now floating in outer space, with shiny lights slowly buzzing around him. The animation of the lights is similar to the camera track demo above, with spline interpolation. The lights are so-called RibbonTrails, which are a stream (trail) of small Billboards. (It's a surprising fact that particle effects are mostly based on billboards: lots of little billboards.)
At this point I made Ogre::BetaGUI (more accurately, I ported it to Perl from C++), which is used in the following three demos merely to provide a mouse pointer.
Robots on a terrain
(There's a pun I'll make related to a movie featuring snakes and a "plane" if I can ever figure out how to create a snake mesh in Blender.)
This demo builds on the terrain demo. First of all, there is now a mouse cursor that you move around. When you click the left button, a robot appears there. If you hold the button down, you can even drag the robot around. Keep in mind that the mouse is moving in a 2D plane while the robots are being placed in 3D, so we end up using a "getCameraToViewportRay" method to do a RaySceneQuery similar to the one for clamping the camera to the terrain.
Robots and ninjas on a terrain
Robots versus Ninjas! This demo works the same as the previous one if the mouse is not over a robot; however, if the mouse is over a robot, the robot will be selected and you can drag it around again. It's the same story with RaySceneQueries. A white box shows which one is selected. In addition, you can toggle (with the space bar) whether to place ninjas instead of robots, though the ninjas are scaled wrong so they're like three times the size of the robots.
Robot selection by volume query
Unknown to the ninjas, the robots are building a clone army. This demo shows the PlaneBoundedVolumeQuery and also how to make a good old rubberband box used for selecting multiple objects with a mouse. In the screenshot, I show the scene after I've already made one selection of robots, and I'm now dragging a box around to make another selection (but haven't let up the mouse button yet). (Note: the implementation of the Perl binding is currently a little sucky if you look in performSelection of examples/itute4.pl.)
At this point I made Ogre::AL (binding for OgreAL C++ library). The following three demos are of that, though of course you won't be able to hear the sounds.
OgreAL basic demo
Background music is playing, something by or for or from "ZeroFactor". The ogre head, floating in mid-air as always, is "roaring". Whereas the music stays at the same volume and appears to come from nowhere, you'll notice the roaring comes from the ogre. If you turn the camera to the left, the roar moves to the right. If you move the camera back, the roar gets quieter like it's moved off in the distance.
There is a siren, which you can turn on and off. It rotates when it's on, and the sound gets weaker when the horn points away from you. To be honest, it doesn't seem realistic at all. Basically it suddenly decreases in volume when the direction it's pointing in is inside the 180 degrees half circle facing away from the camera, then it suddenly increases again when it's within the 180 degrees facing the camera. I don't know if the demo just isn't finished yet, or if the OpenAL library sucks on Linux, or what. UPDATE: the author of OgreAL, Casey Borders, says that this is a Linux-specific problem.
This demo is also disappointing. The car goes around in a circle, but the sound isn't very....dopplery. When I think of a doppler effect, I think of race cars whizzing by or police sirens as the cop car speeds past. (Again, I don't know if it's the demo itself or the OpenAL library or my particular system. UPDATE: see update for previous demo.) This demo also has a more involved example of using Ogre::BetaGUI, which you can see in the upper-right corner. Clicking the arrow buttons adjusts the doppler effect and speed of sound (in principle, at least...).
Manually drawing shapes
Now back to Ogre, not Ogre::BetaGUI or Ogre::AL. I haven't even uploaded this one to CPAN yet. It shows how you can draw shapes "by hand" rather than creating them in Blender (not that I know how to do that). There is a square, a line, a circle, and an annulus (disk with a hole in it). The first three are pretty basic, you just give the positions of the vertices and that's about it (ok, for the circle you have to give a lot of vertices, but the idea is the same). The annulus, on the other hand, is slightly more involved; you have to draw triangles (in fact, quads made of two triangles each) to create the thickness. If you look behind the annulus, you'll see that it's only visible from the front. That's because the "normals" to the triangles are pointing toward the front, and the light only reflects that way. (You can easily adjust the "circle_thick" function in examples/manualobject.pl to also add all the triangles in reverse, then it will be visible from both sides.)
And that's all the demos for now. In the next few months I hope to continue wrapping more of the Ogre API and clean up that module a bit (it's starting to get out of hand, I need to factor out some of the typemapping at least, and figure out how to load each module separately if that's possible). I'm also looking around at physics/collision engines, in particular ones with Ogre bindings such as nxOgre (PhysX), OgreODE, and OgreBullet. The simpler the API the better, and they have to work on Linux.
There was also a guy on the #ogre3d IRC channel who mentioned that he was embedding perl into his (otherwise C++) game engine and then basically wrapping some useful parts of Ogre in XS. It's something I've been thinking about, whether it's worth it to continue wrapping so much in Perl when in fact I'm not sure if I would ever use it myself if I actually made a game.