New Water

Gloomy Dublin and Traffic - Version D

Video of Self-Training Vehicles

Virtual Viking Tours, Trinity College Dublin

Amphibious Vehicle Simulation

DUKW Viking Tours

Working on amphibious vehicles...I have swimming ones already...

Fog

looks much more realistic, and improves the perception of distance

Omaha: Easy Red

Evaluating Some Alternative Libraries

Evaluation of High-Level Open-Source Cross-Platform Graphics Wrapper Libraries:

Abstract

For solo-developer projects all of these graphics libraries are bad. The drawbacks are many, but varied between libraries.

The ideal solo development framework is a Linux or Mac development environment using all of the powerful Unix tools and open-source compilers and programmes. Development speed is much much faster in this arrangement; ideally you would develop on Linux and then recompile to more popular target Operating Systems.

After evaluation of all of these options, the one thing that becomes clear is that it is exceedingly difficult to develop reliable, up-to-date 3D programmes for Mac and Linux platforms, and cross-platform development hugely compounds the problems. The big guns; Ogre3D and Delta3D are ideal for my type of project in terms of packing a lot of graphics punch, but set-up and maintenance of these libraries on Linux/Mac is clearly an afterthought and has already wasted a vast amount of time that could have been used in more productive areas.

After several years experience with cross-platform Ogre3D and native Direct3D development one feature becomes desirable over all others - ease and small footprint of set-up (i.e. a library with very few dependencies). In this respect two options stand out - Irrlicht and jMonkey. Irrlicht is small, lightweight, super-fast and C++. jMonkey is chunkier (in terms of code verbosity and set-up), slower, and Java. Irrlicht is not quite up to spec with modern technology on all the machines that I've tried it on, but it's significantly faster and leaner than the nicer-looking jMonkey.

OGRE3D - http://www.ogre3d.org/
big, most powerful, ugly

the good:

• most modern feature set
• fast
• huge user community
• multiple platform support
  
• has a brilliant user-built terrain plug-in (ETM)
  

the bad:

• a phenomenal amount of mostly unnecessary dependencies
• Linux is maintained, but not with enough support (lots of development time wasted on upgrades that break)
• horrendous overuse of pointers, STL, and C++ inheritance (the worst bits of C++) - this infects your own code
• native GUI support is abysmal, and user-built plug-in GUIs are worse
• mouse-picking (for selecting 3D objects with the mouse) worse than native DirectX
• is strictly graphics-only - a lot of time wasted with external plug-ins to perform extra tasks that are usually handled by DirectX
• code gets very bloated, and much time is spent on unnecessary engine-level programming
• scene node manipulation is too time consuming and over-complicated
• incredibly hard to maintain programmes for multiple platform deployment
• no useful linux packages (debs etc) available
• takes a fair amount of violence before it conforms to your architecture (tries to make you use its over-developed and extremely messy frame listener architecture)
• code a bit sloppy - doesn't conform to gcc-4.3 standard

Delta3D - http://www.delta3d.org/
military simulation framework

the good:

• targets simulation development
• multiple platform support
• entire framework - sound, network (via HawkNL), physics, etc etc all integrated
• has some great design tools (mostly Windows based-though)
• lots of pre-built content ready to go (explosions, special effects, and other time-consuming bits and pieces)
• very refreshing attitude from developers (good documentation and support)
• outrageous number of useful plug-in components available (weather, animation, physics)
• brilliant terrain engines (including infinate procedural terrain)
• has a particle editor AND a very involved game editor tool
• has an extensive free library of military models and content, scenery, foliage etc
  

the bad:

• incredibly involved to set up and compile (I'm 2 hours in and still going)
• uses the worst GUI system of all time (from my experiences with Ogre) - CEGUI

Irrlicht3D http://irrlicht.sourceforge.net/
small, ridiculously fast, well written - perfect for small, quick projects

the good:

• even runs fast in OpenGl on the Asus EEE - this is the fastest 3D graphics library ever
• require no dependencies - just compiles in one go, on anything - total compiler support
• the best 3D GUI that I've ever used is integrated
• natively (without exporters or converters) loads just about every model format imaginable
• has a nice sound library plug-in
  
• very very good multi-platform support
• has some nice software renderers as alternatives

the bad:

• a bit behind the lead in terms of the latest technology
• lots of extra plug-ins but they are mostly Windows-only
• lacklustre terrain support (relative to Ogre and Delta)
• also uses horrible frame listener architecture

Lightfeather http://lightfeather.de/
like Irrlicht but newer and uglier

the good:

• easy to compile (although much bigger than Irrlicht), no dependencies
• has probably the best terrain engine and terrain design tools available
• has a capable GUI integrated (not having a good one is a huge development time waster...Ogre)
• huge selection of design tools (also a huge time-saver)

the bad:

• messy
• very small community

jMonkeyEngine http://www.jmonkeyengine.com/
Java
the good:

• Java - just runs, on anything with Java. No dependencies. Works.
• Uses the Java Swing, SWT, and a 3D GUI (finally a decent GUI set)
  
• Incredible water and cloth effects built-in (see screen captures)
  
• Just runs - very easy to use and to distribute
• Easy to set up - just include the jar, good IDE selection available
  
• Wraps 2 Java OpenGl implementations
• There is an incredible terrain editor may be released for public use eventually
  
• Can make use of Java sound, music, networking, physics etc libraries
• Very good 3D picking, collisions and other high-level features not avail. in other libs
• Can be turned into Java Webstart applications
• Isn't Panda3D
  
• Is fast! Surprisingly

the bad:

• Smaller community, poor documentation
  
• Code to do simple things like loading textures is overly verbose - far too many lines of code used for very simple processes (i.e. a wrapper would have to be custom-made, which defeats the purpose of JME itself being a wrapper)
• CPU-intensive code may be very slow if programmed in Java
  

Playing with Water

Very simple water system added to simulation. When added by scenario water level is at a set level throughout environment. Creating valleys below this level in the editor will fill them with water.
Although there are a couple of very realistic water options for Ogre (Ogre's Fresnel demo, animated mesh water, and the Hydrax plug-in). I had a look at all of them - they will all be a bit of a pain to integrate - so I have gone for a Keep-It-Simple approach to start with.

The water level rises and falls around a meter, which provides a nice lapping waves effect, and should also allow us to simulate buoyant objects (boats, vegetation, debris etc) that bob up and down.

As for the graphical bits I've made a very simple script that sets the texture to about 30% transparent. This allows you to somewhat see partially submerged objects and some underwater geography without looking too much like something from Quake. The other simple trick was to make it extremely reflective of sunlight - by just amping-up the specularity.

This is the result - simple, cheap, quick, reasonably realistic-looking water. The pictures are all taken from my Asus EEE (yes, I actually built an OpenGl programme on it) so I had to turn off the terrain rendering. Better pictures to come...

I've also created a pre-processor that augments a map of the environment with the topography, and marks all of the regions that are covered by water. The current water level is also available This can then be used by:

• boats that travel on the surface and can only move on water, bobbing up and down
• amphibious vehicles that float and can drive onshore
• land vehicles that can submerse and drive along the riverbeds
• floating things that can be sunk
• land-based things that can't move through water

Dumping Unreliable Libraries

Fmodex ->> OpenAL
RakNet ->> OpenTNL

Zombie Game Completed

Made a zombie massacre game in 2 days using the markiv engine. You can get it under "downloads".

Left click on a zombie to aim your shotgun at it. Right click on the road to move there.

B-Grade sound effects, animation and models, eerie lighting and long shadows; it's a 3D shoot em-up (sort of side-scrolling).

Zombies

I call the one with bugs for a face "Graham" (Graham Grub) and the other one is "Larry".

v0.80 Alpha-1 Released: Playable Network Game

It is now possible to play a complete network tank combat simulation between two players. All of the main features are there.
The project is still under construction and some bits are just place-holders.
The pictures show a complete network game running from start to finish.

The server is the window on the left, the client on the right.

In order of pictures:
1) Server starts and opens game lobby. Client starts programme.
2) Client joins server by entering server address.
3) Client has joined, and enters lobby. Server browses through available scenarios.
4) Scenario has change is reflected on client. Client types some chat to server.
5) The server player moves a Jagdpanther, the client moves one of his T-28Es towards the town.
6) Server tells a T-70 to enter the town, and it plans a path to drive in around all of the houses. Client has moved up a T-28 near the town, and is hiding it behind the small houses.
7) Server tells T-70 to fire at T-28. T-70 indicates that it can not see the target as it is blocked by a small house. Client starts to move T-28 out of cover.
8) The T-70 has been waiting and now opens fire, knocking out the T-28 with a hit to its side armour. The simulation physics calculations for armour penetration are shown in the text output below.
9) The remaining tanks belonging to the client have been destroyed, and a "game over/summary" box appears.

Scenario Editor Improvements