Greetings! Its been a while since the last update (ok, so maybe not), but we’re really excited with the progress we’ve made so far. During my last post I mentioned that I would be tackling terrain rendering and this is exactly what Ive been doing. During our previous tech demo we we using multiple layer overlays to build the terrain. This approach not only limited the level design process so much by making it impossible for the designer to see the results of their work until the whole level was built, but, also takes a ton of time to load. We could literally (1)have the level load, (2)have lunch, and (3)have idle chatter before the level (or any level) would load. More painful is the fact that we needed several layer overlays to make the map look like a real map and each layer overlay extended the loading time by an exponential amount. In addition to this, despite our ultra patience during the loading process, and godlike imagination during the blind level designing phase, the terrain felt lacking.

After looking around the internet and reading articles about terrain rendering as well as getting suggestions from the team (it sounded more like scolding though) I’ve figured out a way to make our terrain rendering faster, easier, and more detailed. Terrain processing in the previous tech demo was done on the CPU which took a lot of time. This process though it allowed virtually unlimited overlays took too long to load. By limiting the overlays to just 4 and transferring the processing to the GPU I was able drastically reduce the loading time (though now it really depends on the GPU of the computer loading the map). In case you’re wondering what my reason was for limiting the overlays to just 4, its because I decided to use the 4 color channels (RGBA) to carry the information for the overlays. As for the ease of level design issue, I recreated the tool, hopefully, the level designer will be happy. I also decided to implement normal maps on the terrain so that the emptiness will go away. All in all I think its a pretty decent render.

Hey everyone! I’ve been tinkering around the particle system adjusting stuff here and there. Needless to say it became quite a chore after a while when I need to compile everything just to see how the particles would look like. I decided to create a tool which allows me to adjust the particles using a user interface, and render the new settings on the spot. Below is a video of the new tool I created. I finally managed to improve the recoding quality but it is still far from stellar.

Some adjustments are in the pipeline to make this tool more useful. These include adding camera controls so that I can actually pan around and look at the particles from different angles, and importing 3D assets so that I can properly determine the scale of the particles. It will probably take me a few hours to get this done before I can proceed to the other areas that need improvement. Next I will be tackling terrain.

Last August 15, 2011 we uploaded 2 videos of our tech demos for Phlyndir. Needless to say we had so much negative feedback we had to run back to our holes and think of a way to make things better. It was emotionally and mentally scarring for us, but, despite the trauma, we decided to give it another go because we wont be able to go far with out feedback, positive or negative, after all. Looking at our work we’ve identified some areas which we can drastically improve; particles, terrains, and *sigh* almost everything. Anyway, I’ll be talking about our improvements to the particle system, like the title of this post states.

Our previous particle system only had one controller with a ton of parameters, around 30 or so, to control the characteristics of the particles the system throws out. It seemed OK because the tons of parameters allowed us to make the basic particle configurations; fire, rain, smoke, etc. It became painfully clear, however, that making the more advanced particle configurations was impossible. The different particle configurations from the basic to the more advanced ones have common properties, however, there are properties that are specific depending on the desired characteristics of the particles.

Here is where this post becomes a little technical. What I did is to abstract the particle system into 3 parts; the particle, the emitter, and the controller. The emitter would contain information regarding the number of particles and the texture used by those particles. The controller would contain information regarding the parameters that will control the particle’s characteristics, and the particle would contain information regarding its characteristics at a given point in time. I also further abstracted the controller into a base controller and child controllers which inherit from the base controller. This allowed me to define the common properties in the base controller and the specific properties in the child controllers. Since the child controllers are inheriting from the base controller it becomes easy to extend the characteristics of the particles by defining more complex child controllers. As a result, we now have a more dynamic and extensible particle system. Below is a demo of the new particle system. The lag is due to the recording and converting of the video.