Falling Object Simulator – Simulation & Concurrency

Featured

 

As part of my MSC Computer Science degree, the Simulation & Concurrency module was probably the most intense module on the course, tasking us to produce a physics engine from scratch with robust network and multi-threading integration in order to implement a simulation of balls falling into a box, with removable trays and also a cloth simulated net.

Having done only a little previous physics programming for ‘The Column’, I set about researching the topic since implementing a solid and robust physics engine is no trivial task, even without a networking element. Although I found several good sources, for specific elements, Ian Millington’s ‘Game Physics Engine Development’ was an excellent book that covered many aspects of getting a basic physics engine up and running. I promptly devoured about a third of the book during this project though it lacks any real depth on collision detection and doesn’t real cover cloth simulation as I recall.

In the end I received 87% for the ACW which I’m pleased with. With more time I would have implemented rigid body motion but this second semester of the MSc has been pretty insane in terms of work load, mainly due to the fact that the UK carries out MSc degrees in a single year, rather then 2 like everywhere else in the world! Additionally, the University of Hull’s MSc degree is extremely practical, which although I find preferable to more theoretical based degrees (how better to learn then via implementation?) does result in a heavy work load. The good side is that if you put the work in, your get an extensive portfolio at the end of the degree.

Project Description:

The result of the project was a multi-threaded interactive falling object simulator developed from scratch using C++ and DirectX 11. The physics engine is a mass aggregate system using particles i.e. no rigid body motion. It features simple sphere and plane based collision detection and interpenetration resolution.

Each tray features different friction and elasticity attributes as per the specification.

An advanced feature is the cloth simulation for the net made using a lattice of spring constraints (Hook’s law) with four anchored corners.

Net collision detection is made using small spheres mapped to the vertices of the net, this however means I had to make the springs quite rigid to stop balls from forcing their way in-between the vertices hence the cloth is not very fluid or fluttery.

Without rigid body dynamics to get the cube rotations I used rod constraints connected to each vertex of the cube. This is a simple way to get rotations using just particles.

Rendering and physics integration are performed on separate threads, with an additional 3 threads for handling network. Rendering frame rate is hence independent from the simulation and both can be changed to run at a specific target rate.

Not shown in the video, but being a significant part of the project is the peer-to-peer network aspect. The program can be run on 2 peers, each peer will communicate and synchronise the simulation using linear interpolation of the scenes physics data. Each peer can be interacted with i.e. camera can be moved independently (think multiplayer) and commands such as open/close tray and spawn ball is communicated across the network to each peer. Network coding was done using Winsock. UDP broadcasting was used purely for peer detection and TCP for data transmission. Packet loss and latency resilience was also implemented.

Solar System Orrery – HTML5 Canvas

Featured

Orrery Zoom

For quite a while I’ve been trying to get around to arranging some web hosting and putting my solar system Orrery online for people to access, I’m pleased to say I’ve finally got around to doing it.

(Click here to go to the Interactive Orrery)

The project was part of the 2D Graphics module course work for my Computer Science degree. It’s written in Javascript and utilizes the powerful HTML5 canvas for rendering.

It’s not an accurate scientific representation, however the planets distances are to scale in relation to each other (not in relation to the sun) and the frequency each planet completes a full orbit (year) is also accurate to real life. There are two orbit modes ‘circular’ and ‘elliptical’ and also two simulation modes where acceleration and velocity is calculated based on the mass each object and thus the force of gravity. One simulation mode keeps the Sun centered while the planets orbit around, the second mode allows the sun to be affected by it’s orbiting bodies.

elliptical

It’s really a bit of fun and you can create new planets of enormous size by simply holding down your mouse on the simulation until your happy with the size and let go and watch how all orbiting bodies are affected. You can also flick the planet when your holding it at the same time of release to set its starting velocity (seems to work much better in chrome then IE). I also highly recommend running it in full-screen mode by pressing ‘W’ if you have a reasonable spec system.

Another cool thing is the zoom feature, if you pause the program via ‘P’ you can scroll around with the cursor keys and take a look at some of the relatively hi-res images I used for each planet. The Earth and orbiting Moon is pretty cool to zoom right into as pictured above.

Detailed instructions are available on the page. Please check it out here and have a play around: www.alexrodgers.co.uk/orrery

simulation

The Column: 3D Graphics Simulation

Featured

As the single fully weighted piece of work for the 3D Graphics module during my second year of my Computer Science degree at Hull University I had to create an OpenGL graphics simulation. Despite having had little prior experience of using 3D graphics frameworks, I am very pleased with the outcome and look forward to continuing to spend a lot more time with both the OpenGL and DirectX API’s; in particular my final year project looks to be a ray-tracing renderer (potentially CUDA) which should give me additional exposure to what is becoming a more and more promising technology for gaming.

I created a report accompanying the finished program which I’ll simply include bits of below to explain the project and how the simulation works.

The Column

The Column

The Column is a 3D graphics simulation designed around a series of stacked boxes containing cylinders. Balls are emitted at the top of the stack and interact with both the geometry and each other via way of collisions and response. In addition, the simulation features a “Sphere of Doom”, a large sphere near the bottom of the stack that absorbs balls, shrinking their size and mass. A portal lies at the bottom of the stack that transports any balls that enter, back to the top of the column. The entire simulation is made using OpenTK (OpenGL) in C#. All geometry and physics are rendered mathematically.

The specification determined that one emitter should emit balls with the approx density of aluminium, the second one, copper and the third, gold.

The program simulates a dynamic system through various means. The balls use an Euler integration method with a gravitational constant that combined with calculated velocity, mass and density of each ball, simulates the motion of the balls falling down the column.

Ball to ball collision response is handled via “elastic collisions” based on the mass of balls and perpendicular velocities from the collision point, thus a heavier ball will knock a lighter ball out of the way. Additionally the angle of impact effects the amount of force transferred.

Rendering is performed via OpenGL using version 3.1 and Vertex Buffer objects. All primitive 3D models have been constructed manually or mathematically. I use GLSL vertex and fragment shaders for “Phong Shading” based ambient, diffuse and specular lighting calculations that provide interpolated lighting of geometry between vertices. My scene uses 3 point light sources and has built in support for both directional and spot lights if desired.

I have implemented a particle system object that emits particles of a given shape. I have used simple quad planes for the simulation for performance optimisation and rotate them for added effect combined with the lighting. The particles are highly customisable in lifetime, movement, scale and quantity and can be added for any desired event. I use them specifically for collisions with the Sphere of Doom and upon spawning of balls from emitters.

My portals use a Frame Buffer Object which renders the scene from the desired camera position to a texture. I then switch to the Display Frame Buffer and render the entrance and exit portals using the respective textures to give the effect of seeing through the portals to their destination, which in turn is updated in real-time.

Bottom-Up

I have spent considerable time optimising the simulation to maximise the overall frame rate. Much of this has been achieved by streamlining the shader structure to avoid dynamic branching, specifically with the avoidance of “IF” statements , the use of step functions and moving as many calculations as possible to the vertex shader. The fragment lighting calculations are easily the most intensive part of the simulation and reducing my lights to a maximum of 3 per fragment has also helped greatly.

With a simulation such as this, there is always something that could be improved on, tweaked, optimised or added. Suffice to say I am very satisfied however with the quality of the finished product which has more than surpassed my initial expectations and I feel I have learned very useful and contemporary skills that will be essential for the future. Perhaps most importantly, I have thoroughly enjoyed the assignment.

I’ll get a video uploaded of it in motion at some point. I’m currently looking at improving my portals a bit by potentially using an asymmetric frustrum.

Sphere of Doom