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.
Robot
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.
Ninja
The ninja demo adds lighting, shadows, and a textured plane,
and handles input of the Esc key to quit the app.
Listening ninja
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.
Buffered ninja
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.
Space SkyBox
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.
Dark SkyPlane
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.
Robot animation
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.
Robot dance
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?)
Camera tracking
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.)
Particle Effects
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.
Skeletal animation
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.
Terrain
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.
Directional demo
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.
Doppler demo
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.
