New Light Manager and Deferred Rendering

I haven’t had as much time to work on Ion over the last few days, however I put in a few solid hours of coding today and finished the first version of my light manager. It’s only hooked into the deferred renderer at the moment, since I still need to finish the code that’ll allow the forward render to pull a limited number of lights based on some input factors. At the moment lights can have custom position, color, intensity and a variety of different fall-off equations. I’d like to add support for lens flares and cubemap masks later on, to add some extra visuals.

For the deferred renderer, the light values are stored in a pixel buffer which is passed into the final deferred shader. Unfortunately I’m doing something wrong with glTexSubImage2D and isn’t working properly, so I haven’t been able to add light animation to the system quite yet.

The scene setup I’m using to test things out has 7 lights in it; a white light at the center, four colored lights at the four sides of the cube stack, and then two small, bright lights (pink and cyan) directly next to the stack. I setup the scene to be in a 0-gravity space environment as well, so the effects of the lighting were more obvious. Here are a handful of screenshots of the test scene:

I also recorded a video, however QuickTime dropped the FPS down a bit. In the video each click adds another 6x6x6 group of physics cubes; at the end of the recording there are several thousand floating around. At one point there’s a bit of visual lag since I added several groups in quick succession, and the physics and render loop are tied together. Anyways, here’s the video: http://vimeo.com/28528048.

That’s it!

T

Python Support for Ion

I’ve been a bit quiet on the Ion Engine front for a few day now, mainly because I’ve been reacquainting myself with Python. As I mentioned before, I picked up a book on the language as I was considering using it as the scripting language for my engine. I’ve decided that it’s the route I want to take, so I took a look at it today to see what sort of work would have to be done.

There are two ways to integrate Python with a C++ application: compile the application as a Python module and load it into Python, or compile Python into the application and run it as an embedded interpreter. The Torque MMOKit, a package I used extensively a few years back, makes use of the first method. It caused a lot problems with packaging, since end users expect an .app or .exe file to run, not a .py file. The tool chain used a Python utility called Py2Exe to solve this, but it wasn’t without its problems and was often challenging to set up correctly. I eventually ended up moving over to the second method, which required significant work upfront but greatly simplified the overall distribution process. I plan to use the embedded method again for Ion Engine.

On the Windows platform, Python is extremely straightforward to integrate. There are pre-built .lib files included in the binary package, so no source building is required. The Mac platform is kinda in between. Apple provides Python support as part of the default libraries, but unfortunately it’s a little bit outdated at this point. I intend to use Python 3.2.x, while Snow Leopard shipped with version 2.7.x. It was fairly easy to upgrade though,and a Python.Framework is provided so I won’t need to compile source in this case either. The iPhone is a huge pain in the ass.The iPhone has very little support for Python at all; in fact until recently the App Store wouldn’t even allow embedded Python in any apps.

I haven’t been able to find compiled versions of Python 3.2 for the iPhone, so I decided to try compiling it myself. Python’s make compile settings worked just fine on my Mac, but I have no idea how to set up make to compile an iPhone library. I had to move everything over to Xcode to do this, which turned to be a lot more tedious than I expected. Eventually it all worked out though, and I was able to test a very basic “hello world” Python script in the iPhone simulator.

I intend to start integrating the Python stuff into Ion tomorrow. The end goal is to be able to control most of the game logic and world building with Python, leaving networking, rendering, scene management, etc to the core C++ engine. Since it’s a pretty big task and I’m not sure how long it will take, I plan to develop it in parallel with some of the other components I’m working on. That way I won’t get sucked into working on the one thing and burn out.

T

Dabbling with Deferred

In my last post about the new rendering system, I mentioned that one of my tests involved some basic deferred rendering. I only went as far as splitting the color, position and normals into separate targets, so today I decided to actually do something with them. I looked into some basic lighting equations and wrote a new shader to combine the render output. There are still some artifacts and incorrect spots as I’m not well versed on the topic, but I’m satisfied with my progress.

I ended up including five lights in the test scene: red/magenta, blue, purple, yellow and green. I don’t have a proper lighting system in place so they were simply hardcoded. Here are the results, from the Mac client of course:

This code won’t run on the iPhone, since there isn’t MRT support on it. It is possible to run a form of deferred rendering on the device using a variant of Wolfgang Engel’s method, as pointed out to me by a developer from Supermono Studios. Their team managed to produce a pretty impressive demo of the tech; a video of it can be seen on YouTube. This is another rendering technique I’d like to try at some point, but before that I need to finish the render manager and move the code over into the iPhone build.

T

Render Manager

I started working on implementing a proper render manager today. The scene graph will handle culling and checks to make sure an object should be rendered, at which point it will submit the object to the render manager’s queue. The queue is broken into several groups, such as Sky, Terrain, Mesh, Translucent and a Post based on what the object is. The Sky group, which will contain the skybox itself and any star fields or sun objects, will always be rendered first. Terrain is rendered second, then meshes, then translucent objects and then finally any post effects are applied.

The basic setup is complete, and I’ve all my existing renderable objects over to the new system. The system is designed to be extensible and new groups can be slotted in to suit the needs of the application. To test this out, I added in support for some basic deferred-style rendering that stores depth, color and normals from the scene to a gbuffer and then displays them in the post render group:

Deferred rendering is a feature I’d like to support on capable platforms, so I’m definitely going to be working this more in the future.

T

Ion Engine

I didn’t do any coding today since I’ve been putting a lot of hours into my game engine over the last few days. It’s nice to have  a break some times, after all.  I’m still aiming for a preliminary demo by Sunday, so I’ll probably start working on a basic UI system tomorrow. In the off time I also though several things I’d like to starting working on, most of which are going to involve some new programming concepts so they’ll probably have to wait. A terrain engine is one of them.

I did start working on a logo today, with one of the names I have in mind:

It’s not final by any means, nor is the name really, but I would like to be able to call my project something. Preferably sooner rather than later, too. I like the name “Ion Engine” since it’s short, catchy and easy to remember. I also can’t find any other active game engines under that name, unlike one of the other names I liked (Axiom). The science nerd in me also got a bit of a laugh out of the fact that my Abstract graphics layer could be stylized as the silver ion Ag+. Ha.

T

RakNet Take Two

I made my first pass at integrating RakNet into my engine today. I ended up going with the following class inheritance structure for bringing it into the mix:

Red is RakNet and Purple are components of my own engine. So far the only class that actually makes use of the functionality in NetObject is my PhysicsCube that I’ve been using in the last few posts, but it’s very easy to extend any SceneObject derived class to be networkable.

To test out the integration I decided to try running my physics simulation entirely on the server. For ease of use I temporarily forked my codebase into two separate Xcode projects: one for the server and one for the client. All of the rendering code was stripped out of the server build, and physics disabled on the client build. The server handled all the physics simulation and would send updated positions/rotations to the client. In addition to testing RakNet’s basic networking features, the setup also allowed me to use RakNet::Replica’s syncing feature that keeps new clients up to date with the scene as they join. Here are a few shots of the system in action on the iPad simulator:

And one from my iPhone, just as new cubes were added to the scene on the server:

Overall I’m very happy with how RakNet is functioning. In the next few days I’m going to try to get some more interesting things in the scene, as I’m getting a bit tired of the cubes. I’m hoping to have some basic player-like functionality in place by the end of the week and hopefully a functional Mac and Windows client to go with the iPhone one.

T

Rak ‘em Up…

I’m at the point in my engine development where I need to start integrating some net code before I go any further. Like the physics support, networkable objects and net code in general are components I’d like to have as part of the engine’s core functionality rather than tacked on later. I’ve worked with a few network solutions in the past (OpenTNL and RedDwarf), but I decided to use RakNet this time. It’s free to use up to a certain revenue cap, and it’s cross-platform. Perfect!

RakNet only comes with projects for Visual Studio, not Xcode, so I started by loading it onto my desktop machine first. Everything worked out of the box and I was able to run some of the sample use cases without any problems. Setting up Xcode projects for Mac and iPhone were equally straightforward, and I was able to run a chat server on the PC and have my Mac and iPhone connect to it:

I haven’t started to integrate anything into my engine code base yet, but I’m going to start work tomorrow. I did take a look at RakNet’s ReplicaManager though, which sounds extremely useful and will definitely be something I use. It’s essentially a set of classes that will handle replicating objects from the server to the client, or between peers. It’ll be a good foundation for the networked objects in my engine.

All in all, I’m very impressed with RakNet so far.

T

Optimizations and Physics

I’ve been doing a lot of optimizations recently, including tracking down a few memory leaks and increasing VertexBuffer performance. To put it numerically, I was only able to simulate ~64 physics cubes on the iPhone pre-optimization, but now I can have close to 300 active cubes and still maintain a solid frame rate. At one point the bottleneck was actually my rendering code, but I fixed the issue and now Bullet’s speed is the limiting factor. The Simulator still out performs the device a bit in this case, but that’s to be expected.

With the scene chugging along quite well, I decided to add accelerometer input to the mix. I’m using the accelerometer to set the gravity vector for the scene, so flipping the phone will flip the gravity. The only issue so far is that Bullet will not “wake up” sleeping physics objects when the gravity vector changes, so only active objects are affected by the accelerometer. It’s still pretty cool, so I decided to put up a video:

http://vimeo.com/27951382

I’ve also uploaded a few videos from the Simulator showing the progress of the physics performance:

http://vimeo.com/27829407 - Poor performance

http://vimeo.com/27872952 - First pass at optimization

http://vimeo.com/27921243 - Fixed the rendering bug.

Also, on another note I’ve decided to drop the “OpenGL ES Adventure” from my engine posts. It’s no longer just a rendering engine project, so I don’t think it’s suitable anymore. I still haven’t decided on a name for it yet, but when I do that’ll probably start popping up in the post titles instead.

T

What the frustum!

I started working on writing a frustum culler (a thing that makes sure only objects in view are rendered) yesterday. I figured the hardest part would be the math for setting up the frustum shape, as it does require some linear algebra foo. It turned out to be much easier than I thought, as the ViewProjection matrix happens to have everything needed already in it. The frustum culling checks themselves were also pretty straight forward.

Everything was good until I ran the iPhone app. My scene of 64 physics cubes would initially load correctly, but as soon as I started to pan the camera groups of cubes would be randomly culled off the screen. This was at around 10:00pm. Since my ViewProjection matrix had worked flawlessly for all other rendering tasks, I assumed the issue must have been with the way the frustum was being generated. By around 12:00am I had tried every possible combination of creating my frustum, including treating the matrix as left/right-handed, row/column major and turning on and off normalization of the output planes. Nada. Rendering the planes in Graphing Calculator, minus the far plane, looked right:

So if the frustum construction code is right, then the ViewProjection matrix must somehow be wrong? Or maybe the frustum checks? Enter several more hours of no success, and an acceptance of defeat at 2:30 AM.

This morning I realized that my cubes’ position variables were not being set. The physics update code was copying the new positions directly into their mTransformMatrix variables and leaving the mPosition value at its starting position. The culler uses the position variable to determine where the object is. Dammit.

Needless to say, the frustum culler is now working. In fact, it’s the frustum culler from 10:00pm last night that works correctly.

T

An OpenGL ES Adventure – Part 6

I’ve been a bit slack lately with blog updates, mainly because I’ve spent the last few days relaxing/recovering from my wisdom tooth surgery. The resulting discomfort made it surprisingly hard to stay focused long enough to do any programming. I’m almost back to normal now though and was finally able to concentrate on getting some work done today. I haven’t started on my UI system yet as there’s still some planning I’d like to do, so I decided to play around with the Bullet Physics library to see how it would work with the iPhone.

I’m quite fond of game physics, as my first large programming project was writing a complete PhysX implementation for Torque Game Engine Advanced. Unfortunately PhysX is closed-source, and since nVidia doesn’t offer an iPhone version it’s not an option. There are a few other good libraries out there, e.g. Newton and ODE, but I went with Bullet for no real compelling reason. I’m still not completely sold on it being the best solution though, as the API is quite complex and there’s a ton of stuff I won’t need. Something lightweight like Tokamak or True Axis might be better,especially for mobile development. But I digress, back to Bullet!

I wanted to compile Bullet as a Framework to make it easy to include in the Xcode project. Unfortunately Bullet is only setup to compile with MS Visual Studio by default, so I had to do some fiddling/learning CMake to generate myself an Xcode project to compile the Frameworks. Of course, once they were compiled I discovered that the target CPU architecture was wrong and the Frameworks wouldn’t work with the iPhone. I’ve actually yet to figure out how to compile a Framework targeted for the iPhone, so for the time being I’ve just dumped the necessary Bullet source files right into my GL Engine project. It’s not the solution I’d hoped for, but it did allow me to finally get going and actually use the damn thing.

I haven’t done anything overly fancy yet, but Bullet did integrate into my engine without a lot of trouble. I wrote a simple singleton Physics class, which is essentially an implementation of the Bullet HelloWorld program. SceneObjects can then plug into that class and add/manage a Bullet rigid body. Right now I’ve only used it to create a ground plane and a few spheres though.

I intend to work with physics quite a bit more in the future, and possibly even use a physics library to handle collision detection in the engine. That’s all for now though.

T