From LagoonWiki

Implementation Roadmap

Much of the base work is complete, some of it needs to be reworked.

Current Work

Mon 23 Jun 2008 - Thurs 26 2008:

Forgot to add progress.

The network has been polished and I've created a Python wrapper for the server and client member functions. Going to run a network test across two machines for a day and see if it fails at any point. To do so I'm going to try to remove any unnecessary libraries when compiling/linking so I have minimal libraries to install on the new machine.

Fri 20 Jun 2008:

GraphicsManager should be complete. Camera, SceneManager, Meshs are all available more robustly than in the old one and exposed to Python.

Thur 19 Jun 2008:

Worked some more on the GraphicManager.

Should probably stress test the system with as many boats as possible once the GraphicManager is in line.

Wed 18 Jun 2008:

Started work on a better API for GraphicManager.

OGRE Terrain Manager works with heightmaps, but it's nearly impossible to translate, rotate, scale the terrain it generates. Going with Editable Terrain Manager (ETM) which is designed to work with Ogre's terrain manager to create a more robust system. This should allow me to translate the terrain to the correct altitude and test out the scaling of the terrain. From there it should be possible to create boundaries through plane intersection.

Tue 17 Jun 2008:

Graphically the boat and water look ok, the cigarette boat needs better texturing though.

Ok, so I can now use the InputManager's events in Python. I've tied the Xbox controller (Joystick) events to the acceleration/decceleration and rudder control of a single boat engine. The boat engine needs to be added to the Scheduler to make things nice, I need to investigate whether this will overburden the scheduler as more tasks are added, intuition says no as long as there's processor to spare, although it could possibly be optimized better knowing how many tasks will be needed.

Xbox controller appears to work if the following is done in order:

• Boot machine without controller plugged in
• Install the xpad driver (make clean if recently upgraded kernel)
• sudo modprobe -r xpad
• sudo depmod -a
• sudo modprobe xpad

Mon 16 Jun 2008:

XBox 360 controller is acting up. Read that if it's plugged in during boot it is a known issue that the system will hang. Anyways, modprobe xpad seems to sometimes hang the system, wondering if it's because of the kernel update, but I did remake the module and install it, so I don't know.

Rudder and Throttle appear to be working correctly with the cigarette hard coded values. Going to expose methods to change the appropriate values and place such values in XML or YAML files available to Python.

Ok, the cigarette model imported via OgreBlenderExporter from Berserker/Data/Cove/Meshes/cigarette.obj seems to not export rotation/translation/scale correctly (the end .mesh file loads all the same). What I had to do and what I didn't want to do was create a rotation quaternion to correct this issue and translate the object down 19.0 units to the water level. In addition it seems the model is a bit too small for the water effects (I believe since it's 19.0 above the level, it might have to be scaled 19x up).

What needs to be done to fix this is fix the exporter or whatever the cause and allow scaling/rotation to work properly.

Fri 13 Jun 2008:

Implemented BoatEngine physics, how does the Lagoon one interface with the system? I think it just acts on the variables associated with the boatengine and the Tick() is called. All that's needed is to expose the variables properly and see if it works that way.

Ok, using ogreblenderexporter to export *.obj to *.mesh, needed to use /usr/local/bin/OgreXMLConverter on the *.mesh.xml file to convert to *.mesh.

Thur 12 Jun 2008:

Ok, so the models are in *.n3d format, there is one Wavefront format (*.obj) available under Cove for the Cigarette boat. *.n3d is not a well known format afaik, is there an original format that the models were in on the Cove system? do I need to write my own converter from *.n3d to *.mesh?

Physics is attached to models, applied forces properly on objects now display properly in the graphics.

Tue 10 Jun 2008:

Forces work, fairly fast for 1,000 objects, 10,000 objects updating physics takes ~180 milliseconds (furthermore, 100,000 objects take 1.8 seconds so it works out to 0.000015 seconds spent per object (of course this is on my machine which is I would consider the norm for specs)).

Ok, so now that the Python script doesn't complain and actually returns the position properly (indexing requires an exposed get() and __getitem___), going to try to apply some forces, if the position changes then I can work on the graphics side a bit and create a quick model in the game to actually see it working.

Fixed the GMTL Vector3 class, properly exposes gmtl::Vec3f to Python in addition to exposing the wrapper class as derived.

RigidBody required a wrapper to use the GMTL Vector3 wrapped class, PhysicsManager wrapper needed to be slightly reworked to use the proper RigidBody wrapper. Yes, it's a nice ginormous dependency chain, but only on the Python interface side, where it doesn't mess with the C++ stuff.

Mon 09 Jun 2008:

Implemented Lagoon physics after temporarily removing BulletPhysics.

Created wrapper for GMTL Vector3 class.

Fri 06 Jun 2008:

Attempting to create some sort of Object manager in Python.

The physics manager doesn't work. BulletPhysics links OK at link time, but Python complains of missing Bullet functions when imported. I'm going to try to implement straight boat physics into the C++ side and an object manager in Python.

Thurs 05 Jun 2008:

PhysicsManager implemented over BulletPhysics. To test this system I needed to create Scarab::Entity::Object and ObjectManager to contain the Engine's objects. Do I leave this in C++ or as I think it should be, move it to python as it's higher level logic (and any future work that uses the engine may not necessarily need an object manager)? Plus the objects have to be tied to the physics to test this, so it creates an ugly dependency chain.

Reviewed the Lagoon physics again, and began work strictly on the Physics system.

Wed 04 Jun 2008:

Preliminary physics framework added.

Ocean water from the Ogre demo renders properly.

Quirks with MY system: 173.x NVIDIA drivers borked the graphics bad, they just don't work. This could be a mipmap issue reported on the Ogre forums (although they mention 175.x drivers). Sticking with 169.x seems to be best.

Tues 03 Jun 2008:

Python function callbacks are now working in the communicator.

Added a Doxygen configuration file to the ./docs folder. Need to update the premake script to run the doxygen and generated latex Makefile automatically.

Mon 02 Jun 2008:

Reworked folder structure and fixed premake script.

Wrapped Channel functionality into python class to use PyObject callback functions.

Fri 30 May 2008:

Fixed Xbox360 controller issue: xpad driver module needs to be rebuilt on each kernel update against the new kernel headers.

Added a python script to run scarab python modules. $ python scarab/bin/debug/main.py

Thur 29 May 2008:

Python wrapper for input system and graphics system working.

Xbox360 having an issue with showing up.

Wed 28 May 2008:

Wrapped graphics/input/time into Python.

Tues 27 May 2008:

Singleton classes working in Boost Python, a wrapper is needed to expose them properly.

Functions that take function pointers are causing trouble: http://www.boost.org/doc/libs/1_35_0/libs/python/doc/v2/faq.html Need to work on a solution for this, may have to create an object that holds it.

Fri 23 May 2008:

More work on the Python interface - trouble with my singleton class TimeManager and exposing classes (constructor and destructors are protected).

Thurs 22 May 2008:

Initial boost python interface working.

Reviewed physics of Lagoon (Berserker). Gcc4.2 fix for Berserker: http://lagoon.cse.unr.edu/~lagoon/index.php/Gcc4x

Wed 21 May 2008:

Reviewed physics of Lagoon (Berserker). A few problems with gcc4.2 and compiling Berserker.

Tues 20 May 2008:

Imported Hydrax library (OGRE water) into premake system.

Recoded Hydrax demo on top of the Scarab engine, works fine except that input isn't tied in and work machine is sluggish (home machine it works fine).

Added OGRE and Hydrax media to svn and the additional test program of Hydrax demo.

Mon 19 May 2008:

InputManager working correctly with OIS on the backend.

Graphics working properly, nearly independent of OIS (a few inject methods required for MyGUI and UI stuff).

Graphics and Joystick parsing still having problems on Ubuntu with permissions (nvidiactl permission error cropped up recently, could be due to 7.10 to 8.04 upgrade, or a botched system altogether).

Implemented a small memory dump to stdout on location of size n to aid in debugging the following.

Chase and flock appear to broken, data is sent incorrect across the graphics client and game, probably a bad memory location due to the communication channel changes.

The engine should be more stable and robust in regards to channel communication and additional components added in the future.

Thur 15 May 2008:

Forgot to info day of.

Joystick works under sudo, /dev/input/js* permission read/write required.

Graphics problem cropped up with permission error, fix with sudo run - driver or Ubuntu problem?

Bug fixes in the communicator

Fixed up the inputmanager and graphics towards the goal of separation.

Wed 14 May 2008:

Run OIS ConsoleApp demo as root allows it to read the events correctly from the Xbox 360 controller.

Xbox 360 USB controller recognized under Ubuntu, used the the tutorial at: Install and configure Microsoft® Xbox™ and Xbox 360™ controllers under Ubuntu 7.10 to set it up. Note: I tried the same tutorial under Ubuntu 7.10 and it hung after sudo modprobe xpad, but it appears to work fine on 8.10. This could be due to the fact I installed all the packages mentioned under optional packages.

Notes

Problems with the current platform:
  Maintainability:
    clean up the API
    produce documentation for the entire engine
  Technical:
    fix OGRE window/OIS to move
    look into scalability problems, threading work
    resource monitor
    * possibly rework the Windows side to ensure capability
    more logging and crash information
    look into the time simulation, ensure it is working correctly

Models working in OGRE, look into Resource management
Ability to "drive" boats via keyboard and USB Controller
How do I represent Maps/Terrain?

Testing:
  Test across multiple linux distros (32/64bit), multiple cores/CPUs, and Windows side
  Stress test the critical components on low resources over several days, find a dedicated machine, ability to create logs to debug the cause of any crashes
  How clean is the API? are there sufficient tutorials for people to use the system out of the box without any issues?
   Get feedback on documentation and API

Create:
  Data dump/retrieval for saving large data
  Crash logs - Stack trace, resources, memory map, core dumps

Extras:
  Client graphics:
    Entity tooltips
    Interface enhancements