Tag Archives: Ion Engine

Mesh loader

I’ve started to work on fleshing out a proper set of mesh classes for handling mesh instancing, animation and whatnot. I scrapped my old .obj loader and wrote a new one that’s more compliant with current codebase. Here are a few shots of the space scene running with different meshes:

Given that I do my modeling in Blender 3D, I felt obligated to include Susanne, a.k.a the “Blender monkey” as one of my test objects. I haven’t setup trimesh collisions for Bullet yet, so Susanne is stuck with (rather poorly sized) bounding box. The tori use a cylinder. I’m really happy with how the lighting is working on smoother objects though, and with the scene’s performance in general.


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!


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.


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.


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.


Mac Client Good to Go!

I finished porting my engine to Mac earlier this morning. Only a small amount of work was required as most of the engine code is already platform agnostic. There were a few iOS-specific calls in the resource manager, such as use of UIImage, but changing them to OS X equivalents wasn’t a big deal. Those areas are in the bug tracker for refactoring though, especially for when the time comes to start putting out Windows versions. The other change was to use GLUT instead of the iPhone’s EAGL to actually display the OpenGL context.

To test things out, I ran an updated Server Build and connected to it with my iPhone, Mac and iPad simulator:

Running the whole simulation locally is also possible, and fully functional. Just one more screenshot for good measure, this time with the physics running on the client:

From here I plan to start working on a Windows client and server build as well. Stay tuned!


%d bloggers like this: