Author Archives: alex

Particle System

I have added many features to the space project over the last few months. But one feature that I have been looking forward to adding for a long time has finally come to fruition. It’s a feature that adds a small touch of life to the game and is useful for countless dynamic graphics effects. By now you probably have guessed it (not to mention the blog title)… Particles!

Set the controls for the heart of the sun!

The space project’s Particle System faces many of the same precision issues that have made conventional approaches more difficult. These particles must be able to be emitted at very high relative speeds, and in many different reference frames and coordinate systems. By making use of double precision on the CPU-side, and emulated double precision on the GPU-side, I am able to accurately render many billboard particles at a wide range of velocities and distances throughout the entire Star System.

The Particle System itself is based on a pool (underlying deque) of IDs that point to Particle objects in a constant-size array. Active particles are moved from the pool to a list where they are updated every frame. An active particle has a life cycle that is directly related to its current “alive time,” which measures how long in seconds the particle has been alive. During this life cycle, particle parameters can be adjusted based on functions or simple interactions to create interesting graphical effects. Once a particle has reached its end-of-life, it is transferred back into the pool where it can flag that it is available for use again.

On the graphical side of the house, the particle position and parameters are stored in a dynamic Vertex Buffer Object (VBO) which is updated after any change is made. Like other graphical objects in the game, positions are assumed to be relative to eye (or camera) to conserve precision close to the viewpoint at the expense of precision far from it. This results in a very stable simulation with minimal apparent jitter. The Particles are sorted by the square of their relative to eye position for correct alpha blending of translucent objects.

This is the most stable and efficient launch profile for this spacecraft.

The Particle System is far from compete and currently only supports smoke trails. However, the bulk of the implementation is out of the way. New Particle types can be rapidly added to support all kinds of graphical effects. But for now, what other than smoke does a space game need to support? Yeah, yeah, fire and… explosions of course! Stay tuned.

Solid Rocket Software

In the spring of 2017, just before I graduated from school, I began a small C++/Allegro project to predict solid rocket motor performance. This project started as a simple 0-D ballistic model based on basic primitives, but quickly grew into something more as I continued adding features. By the end of the summer, I had a program that could take arbitrary 2-D solid rocket propellant and case geometry, and simulate ballistic performance in real time.

The software takes an input file that defines the geometry and solid propellant characteristics. The initial as-cast propellant boundary is input by a series of coordinates and indices. This will define the bounding volume that the gaseous products will initially burn into. Propellant parameters can be found with a thermochemistry code such as NASA CEA. The final section of the input file defines nozzle throat and expansion data that is used for thrust and pressure calculations. These assume the 1-D isentropic nozzle flow equations for simplicity.

After the program reads in an input file, it computes a level-set that represents the data. This level-set is internally held as a non-uniform signed distance field. To speed computation, the level-set is maintained as a quadtree with the highest resolution clustered about the burning “interface” between the solid propellant and free volume. The level-set is recalulcated as it diverges from the typically slow-moving interface. This does not usually need to be performed every time step, which saves some computer cycles.

For each time step, the level-set is recalculated using a Lagrangian scheme. A burning “flow field” is computed against the level-set using the interface normals. The next interface is extracted from the current level-set using an algorithm based on Dual-Contouring. The surface area can then be found by computing the length of the lines composing the contour, and then scaling that value by the input length of the motor. Moving to a 3-D regression simulation, the surface area of the triangles that compose the contour will be used instead.

From the current burning surface area, which is found via the previously described algorithm, the internal ballistics of the motor may now be calculated. The mass flow rate of the propellant grain, and therefore the pressure of the motor, can be found using parameters from the last time step. The current burn rate can be found using the chamber pressure and St. Robert’s burning rate law. Once the motor pressure is known, it is a trivial task to compute the current thrust using the isentropic nozzle relations.

This brief blog post does not cover all of the features of this software, or all of the details of its implementation. I would like to go into detail about some of its inner workings, and maybe even one day extend the functionality to 3-D. I have included some sample output clips from two solid rocket performance runs: an 11-point star, and a double anchor shape. I hope that these make some of the methodology described in this post a little more clear. Thanks for reading!

Space Simulator Progress

Over the last few weeks I have made significant progress on the core parts of the space simulator engine. Although some changes were made under the hood (more sensible organization and rendering), the most noticeable are the addition of model material support and shadow mapping.

Model materials are a feature that have been a long time coming. Models used to support only one mesh and a clunky and simplistic shading model. With this latest update, models can have an arbitrary number of meshes (performance-limited) and can compile flexible shaders on the fly. Although the current demo shader continues to use the Phong shading model, I am looking into implementing a more complex Physically Based Rendering (PBR) model. Textures are also implemented, but have a few bugs associated with them. Check out a rendered scene with multiple materials below!

A new system was needed to provide high fidelity shadows both on the ground and at altitude. I had started the skeleton of Cascaded Shadow Maps (CSM) nearly a year ago and was finally able to get the feature implemented. Although it still has some bugs that will need to be ironed out, shadows give the rendered scene a greater sense of depth.

These are just a few of the most obvious updates. A rudimentary cockpit system is in place that will allow the player to have a first person view from the spacecraft. I am currently working on improving the rendering model a bit, and then I will move on to adding fidelity to the planet and surrounding solar system. Stay tuned for some exciting updates and a possible official public demo release soon!

Welcome!

After migrating from my previous host, I’ve reset the blog again. I’m thinking this time around I will make this blog a lot more free-form, and not strictly related to certain topics. I’ll be posting my thoughts, adventures, or software development updates here.

For now, the focus will likely mostly be on my space simulator that has been in development for a long time. And likely will be that way for a while.