Current Features:
Display List acclerated uniform tree:
We all know that irrlicht is slow with scenes with large geometry. Since high polygon counts are needed for tracks in this game a more effcient method of tranfering data from the cpu to the gpu was required, static data such as a track does not need to be sent every frame and since the test tracks can reach upto 50 000 polygons; sending this much data every frame can quickly bottle neck the game. The solution to this problem is either Display lists or VBO's where data is cached from the cpu onto certain high speed memories of the gpu at certain busy times so the transfer time is "masked".
Display lists were used in the game because of their low requirements and free optimisation, data is optimised on compile so things like cache alignement are no longer a problem. Our tests in a transform limited case gave us > than double frame rate increase using display lists, the benfit also increased at a smaller size after rendering sevral meshes since render display lists uses less calls. Another advantage of display lists is that the data is 100% stored on the gpu, so after compilation we simply delete the mesh data resulting in a saving of around 2 - 3 megs of ram per track.
Enter the second problem realted to tracks, octrees. Octree generation was very slow, so slow that it took around 2-3 minutes per track on a Athlon 2600xp. Also the octree resulted in alot of uneeded view culling tests, since the nature of the track geometry is very dense but has high visiblity (dense but not compact, oxymoron hehe). Thew new octree generator takes around 800ms on the same cpu including mesh loading and display list compile time (out of my hands in regards to optimisation).
Camera system:
The Camaera system is a camera that follows the ship (3rd person view), the camaera is flexible and responds realistically to the ship movements.
The camera system is based on a mass class made for this project, it works by using a spring system to fix the camera to a certain relative position to the ship, diffrent combinations of springs cause the camera to behave diffrently, now we have two camera modes:
-gameplay mode ( a camera which follows the ship in a dyanamic manner)
-Cutscene mode, where the camera does a small cinematic, directed automatically by setting the camera position and a spring setup.
here is an example of a spring setup (dashed lines = springs)
Physics and entity system:
For High speed collision detection we used bullet for speed and stability reasons. The track is loaded as a tree'd trimesh while the ships are convex hulls. Convex hulls generated directly from ship models cast too many colldetect rays and also proved to be unstable gameplay wise, so we modelled collision meshes for each ship and used that as a shape for the hull generator. We also have a compound mesh exporting and loading pipeline for blender but these compound meshes seem buggy and dont work on all cpu's.
WIP:
Water simulation:
I am currently coding a simple plane water simulation for a secret gameplay mechanic (not eyecandy
), its not finished yet but here ar a few tips i can give.Most softbody simulations use springs as a way to simulate the physics of these bodies
(>www.gamasutra.com/features/gdcarchive/2 ... Mathew.ppt<); using lots of rigid particles interconnected with springs. Even though spring physics is very simple applying it to many vertices each vertex being connected by 8 springs (for a grid) the expensive distance calculations accumulate making it slow. Also using a spring system for water is wrong due to two things:
- Water waves are tranverse waves, this means particles transmitting the waves only ocscilate 90 deg to the wave direction of travel. This means water particles in a flat plane should only vary their y axis position. A spring system will move the particles in all directions if any particle is moved on any axis meaning any rounding/displacement errors will eventually cause slight wobbling in a non water like fashion. Computing the values for all three x,y and z coords is a waste since physicaly correct water will only need the y coord values.
- is slow due to many square root operations.
So how do we get away from using 3d springs and expensive square roots? Well after playing with some numbers in excel i made the following graphs, if the spacing between each particle is small, the distance between the two particles is almost = to the real distance computed by the square root and full 3 coord calculation; this means we must simulate lots of particles at a high density for the simulation to work, but since the y displacement is now = real spring distance we have allot less calculations to do which makes using more particles feasible.
black circles are water particlesm dx and dy are distances.
red line = fast method, blue line is true values
lots and lots of shaders
I hope you enjoyed reading this, and it has sparked intrest into the project (that means join the project if you want =p)
and here is some pretty art to allieviate the symptoms of reading horrible text.
, ill get rid of that using dynamic exposure.