I have switched from working on TrueAxis plugin for OPAL to designing some basic AI, because it was taking a bit too much time. And I feel that it is more important and productive to construct some basic scene and start working on the game play.
The thing about game play is that it is really hard to develop it unless there is an enemy to fight with. Here, I had two choices, either implement networking or develop some AI. Network is kind of ready for further developing, but I decided to go with AI. I had a few ideas ready to go.
At the moment I am working on navigation for AI. The current implementation does not require static environment, which is perfect for destructible physics of Ukrainian Rumble 2. It also does not require precomputation. The drawback is the luck of scalability, since at the large number of objects, navigation may become CPU-intensive. This however should only appear at a really large scale environments. It could be resolved though via use of octrees.
The navigation is near its finish. Vehicle control from the navigation recommendation is still being tested and fixed, but it is operational nonetheless. Once it is done, the easy step will be control of a tank tower to aim at the target and fire. This will be much simplier than navigation, though.
Soon, the scene creation will begin: the campus of the University of Louisville, KY.
Friday, September 16, 2005
Tuesday, August 30, 2005
TrueAxis as a new physics engine
Lately, I have been working on new physics engine to replace a rather outdated ODE physics engine. ODE did a good job of starting the project, but its limitations have started to bog down the performance of the game.
What are those limitations? The main ones are inability to handle a lot of sleeping objects. That is, let's say we have 1000 boxes laying around the scene, while we control a tank moving around. A decent engine will be able to quickly parse out which objects need to be tested against, but in ODE collision detection is not optimized, so the product is poor performance. This is important, since I do expect all scenes to be like that: lots of sleeping objects. The second reason is instability: sometime ago I had to tweak things nicely to have more or less stable environment. But still I am running the simulation at 100 times per second, just to keep things from bouncing too much, yet it is still visible in demos. This is not only annoying but also eats up CPU.
Why TrueAxis? I had several requirements when choosing an engine. First of all, it has to be stable and perform well. Most engines other than ODE already do that (although not always for free). Second, it must support Linux. It is really hard to give up ability to develop under Linux. ;-) This cuts options down to two engines: Newton and TrueAxis. Now, this choice was easy since two engines seem to have gained a certain personality: Newton with correct physics (but slower?) and TrueAxis with handling of fast moving objects (but less correct?). My choice was a better performance for a price of less precise simulation and with an option of using super fast objects for missiles.
Any programmer out where will think: "Gee, moving to a different API, good luck on migrating your project." Luckily, I have foreseen this, and so used an abstract physics layer: OPAL. This way all I need to do is write a plugin for OPAL, without changing a single line of code in Ukrainian Rumble. Well, maybe some parameters would need to be changed around but that is handled in XML configuration files.
So, for the past 3 weeks I have been working on this plugin. It is not really hard but is time consuming. OPAL provides a lot of features, and I do use a lot of those features, so even though I implementing only stuff that I need, it will still take a bit. But I am getting close to a certain milestone: just a few things left to do.
What are those limitations? The main ones are inability to handle a lot of sleeping objects. That is, let's say we have 1000 boxes laying around the scene, while we control a tank moving around. A decent engine will be able to quickly parse out which objects need to be tested against, but in ODE collision detection is not optimized, so the product is poor performance. This is important, since I do expect all scenes to be like that: lots of sleeping objects. The second reason is instability: sometime ago I had to tweak things nicely to have more or less stable environment. But still I am running the simulation at 100 times per second, just to keep things from bouncing too much, yet it is still visible in demos. This is not only annoying but also eats up CPU.
Why TrueAxis? I had several requirements when choosing an engine. First of all, it has to be stable and perform well. Most engines other than ODE already do that (although not always for free). Second, it must support Linux. It is really hard to give up ability to develop under Linux. ;-) This cuts options down to two engines: Newton and TrueAxis. Now, this choice was easy since two engines seem to have gained a certain personality: Newton with correct physics (but slower?) and TrueAxis with handling of fast moving objects (but less correct?). My choice was a better performance for a price of less precise simulation and with an option of using super fast objects for missiles.
Any programmer out where will think: "Gee, moving to a different API, good luck on migrating your project." Luckily, I have foreseen this, and so used an abstract physics layer: OPAL. This way all I need to do is write a plugin for OPAL, without changing a single line of code in Ukrainian Rumble. Well, maybe some parameters would need to be changed around but that is handled in XML configuration files.
So, for the past 3 weeks I have been working on this plugin. It is not really hard but is time consuming. OPAL provides a lot of features, and I do use a lot of those features, so even though I implementing only stuff that I need, it will still take a bit. But I am getting close to a certain milestone: just a few things left to do.
Thursday, August 11, 2005
Clean up stage.
After having added particle effects for any broken joint, and thus any destructive event, I have distributed the link to the latest demo around Internet to get some feedback. Maybe people are just nice, but the comments were generally positive. What is more important is that I have received a number of suggestions about the direction of the effects and features that I should push in. Many thanks to those folks.
One of those ideas have led to think of a way to overcome GPU bus bottleneck. Here is what it was: GPUs have been developed and optimized to handle large chunks of mesh, however, it does hot handle well, large number of meshes. 10000 triangle in one mesh is MUCH better than 10000 meshes with one triangle. Here's a link that describe this in more depth.
Why is this important to URumble? Because the physical simulation is bound to have many independent objects, thus meshes. So, this is has to be dealt with somehow. Luckily, the framework allowed an easy implementation of the idea. Tanks in the recent demo are represented as a complex object consisting out of a dozen independent objects. Here is what happens now: once a tank goes to sleep (all its bodies stop moving around) its meshes are build into static mesh, and this new mesh replaces old separated meshes. The only downside is extra memory usage, and slow downs when builds large meshes.
Overall, the approach brought a huge performance boost, sometimes it doubles the frame rate! At the moment I am considering bringing this method to a large scale, when the entire parts of the scene will be built into static meshes. This will require some special division of the environment, possibly via use of octrees.
Other than that, a lot of time has been spent into cleaning up the framework and its interfaces, which led to creation of a few minor tools. More are scheduled to come as they approach a certain level of usability.
One of those ideas have led to think of a way to overcome GPU bus bottleneck. Here is what it was: GPUs have been developed and optimized to handle large chunks of mesh, however, it does hot handle well, large number of meshes. 10000 triangle in one mesh is MUCH better than 10000 meshes with one triangle. Here's a link that describe this in more depth.
Why is this important to URumble? Because the physical simulation is bound to have many independent objects, thus meshes. So, this is has to be dealt with somehow. Luckily, the framework allowed an easy implementation of the idea. Tanks in the recent demo are represented as a complex object consisting out of a dozen independent objects. Here is what happens now: once a tank goes to sleep (all its bodies stop moving around) its meshes are build into static mesh, and this new mesh replaces old separated meshes. The only downside is extra memory usage, and slow downs when builds large meshes.
Overall, the approach brought a huge performance boost, sometimes it doubles the frame rate! At the moment I am considering bringing this method to a large scale, when the entire parts of the scene will be built into static meshes. This will require some special division of the environment, possibly via use of octrees.
Other than that, a lot of time has been spent into cleaning up the framework and its interfaces, which led to creation of a few minor tools. More are scheduled to come as they approach a certain level of usability.
Saturday, July 30, 2005
After CGAIMS
The conference was actually quite a lot of fun. If nothing else, it is nice to meet people who speak and think on about the same wave lentgh as you. There was one physics related paper and a few on computer graphics, but most of them were on AI in games and just in general. So, I got a few ideas to look for when I get to coding in AI into Ukrainian Rumble.
Unfortunately, network did not make it to the conference. We had only an off-line (singleplayer) version to show.
Couples of demos were created: a hammer and a line scene. For more info about them, check this page.
At the moment, I plan to release this version onto Ogre forums, but before I do that, however, I would like to make a few graphical improvements to localize it for the Ogre community (my guess is that guys and gals there like graphics ;-) after all it is a forum for a graphics engine). The new feature that I want to add is actually quite simple, which is why I am willing to do it right now: add a particle effect for any joint break not just ones caused by a missile collision. This should greatly improve visual look of the hammer falling down on top of vehicles.
Unfortunately, network did not make it to the conference. We had only an off-line (singleplayer) version to show.
Couples of demos were created: a hammer and a line scene. For more info about them, check this page.
At the moment, I plan to release this version onto Ogre forums, but before I do that, however, I would like to make a few graphical improvements to localize it for the Ogre community (my guess is that guys and gals there like graphics ;-) after all it is a forum for a graphics engine). The new feature that I want to add is actually quite simple, which is why I am willing to do it right now: add a particle effect for any joint break not just ones caused by a missile collision. This should greatly improve visual look of the hammer falling down on top of vehicles.
Friday, July 15, 2005
CGAIMS
The paper work has been completed. The Ukrainian Rumble is coming to CGAIMS 2005 at Louisville, KY, USA. The conference's website is right here.
Long story short, I have two weeks before the conference. There is plenty of stuff I want to show on the conference. Most main features have already been implemented, but there are a few rough corners that stick out, mainly vey poor ground - nothing but bunch of plains stuck together in order to form a ground.
The reason this sticks out is because the robots have decent models with couple of different particles to represent smoke and small explosions.
Of course, network are still coming, the client side is mostly done. It still needs to be connected to the server, though. At the moment the server does not anything other than ignoring all incoming packets but the ones that are send during the connection and disconnection of a client.
Summer semester is almost over, and the free time is here to help me.
Long story short, I have two weeks before the conference. There is plenty of stuff I want to show on the conference. Most main features have already been implemented, but there are a few rough corners that stick out, mainly vey poor ground - nothing but bunch of plains stuck together in order to form a ground.
The reason this sticks out is because the robots have decent models with couple of different particles to represent smoke and small explosions.
Of course, network are still coming, the client side is mostly done. It still needs to be connected to the server, though. At the moment the server does not anything other than ignoring all incoming packets but the ones that are send during the connection and disconnection of a client.
Summer semester is almost over, and the free time is here to help me.
Wednesday, July 13, 2005
Blog has been created.
This blog will be a journal of my development of Ukrainian Rumble 2: "Heritage", a Multiplayer Mechanical Shooter.
For details, visit the homepage of the project.
For details, visit the homepage of the project.
Subscribe to:
Posts (Atom)