Muzzle Flash

I've just been asked a question by way of a comment to this blog.  It's easier to reply by way of a new post.  I also haven't had anything to update on the blog for a while so this does two jobs in one.

State of Play

I haven't had anything to say for a while because at the moment my code is broken.  By that I mean I'm in the middle of changing something fundamental and it won't compile, let alone run.

I don't like it when the code is in this state.  I prefer to make small changes and at the end of every day the code compiles and I can test it.  For the last few weeks it has been a mess.

I am in the process of separating the client processes from the server processes and adding all the messages to communicate between the two.

I am concentrating on just the messages to get to a state where I can compile and run the game again but just to spawn a character in to the world, the state of every part of the world needs to be sent from the server to the client and the message to say what and where to spawn.

There's been a fair bit of design and redesign but now it's mainly a lot of typing.  I'm nearly there but not quite.

The Question

As mentioned, this post is to specifically answer a question.

"I've been working on a project in which you've helped me out a lot and now I'm at point at which I'm experimenting with particles. I've seen the muzzle flash screenshots on your blog and wanted to ask how did you go about positioning the exact spot to your weapon for the muzzle flash effect."
It was asked by 49ers94 from the Xbox Live developer forums.

It refers not only to the muzzle flash shown in a previous post, but to the start of the projectile particle effects shown in several of the screen shots.

The answer is simple.  I store the relative position of the muzzle in relation to the origin of the weapon.  That position is transformed by the direction the weapon is aimed in to calculate the position of the muzzle at any point in time.

 /// 
 /// Get the muzzle location in world space. 
 /// Grenades will return the hand position because the offset is zero.
 /// 
 public Vector3 MuzzleLocation()
 {
     // Vector3 MuzzleOffset - relative to the weapon origin
     // Matrix WorldPosition - position and rotation of the weapon model
     return Vector3.Transform(MuzzleOffset, WorldPosition);
 }

The above code is within the weapon model wrapper class that I use.  The weapon is already moved by whichever bone the weapon is attached to.

If you calculate that relative muzzle offset position manually for each weapon, that is all you should need to do.

One note on the particle effect.  The muzzle moves quickly as the character does but to make a nice effect the flash is not instantaneous.  I found that if the particle effect stayed still for its duration it looked odd when the weapon moved away from the still visible flash. 

The solution I used was to have very short duration particles and create new particles at the new position of the muzzle each frame.  This is not how a real flash would happen but this is what I found looked best.

Coding my own Tools

I've taken it a bit further to make it easier to create and edit more weapons.  I included a visual method to adjust the muzzle position in to the model viewer that I use for my game.

To make my life even easier I create all my weapons facing the same way and at the same scale.  I have not created all my own models but I take the model in to Blender, change its position and scale and output the model to FBX for use in my model viewer and in my game.

I save the relative muzzle position in to a text file for each weapon which is loaded in the content pipeline.

I think that covers everything on that topic.  Back to coding my client server architecture...  After an all day breakfast that is.

Multi-Threaded Code Is Hard

I know that title is probably stating the obvious to anyone who has tried it but it bears repeating.  I have other articles that refer to the same in different ways.

Nearly a month ago I thought I was nearly finished with the change to the physics to get it ready for networking, just a few peculiarities to sort out.  Little did I know how long some of those 'peculiarities' would take to find. 

Today I have finally confirmed that one of the hardest problems to find was, yet again, caused by multi-threading.  When the player shot towards another character sometimes but not always the shot would fire, the muzzle flash would display but no projectile trail was shown and the enemy was not damaged.

Lots of debug code and head scratching later I narrowed it down to the line of sight intersect code with the enemy bounding spheres was returning a distance of zero from the muzzle of the shooting weapon.

In my head and all the maths I did and all the debug code said this was an impossible situation but there it was on my output window, length zero to target and the shot in reverse!  Aaaaah!

I got so frustrated I started looking at Unity3D and the possibility of re-writing from scratch and targeting the Xbox One instead of the Xbox 360.  After installing Unity3D and taking a quick look at that I decided all I would be doing was moving from one frustrating problem to a different set of frustrating problems. 

The break from XNA gave me some time to think and I eventually noticed that the spheres I use to intersect with are updated in a different thread to where I calculate collision.  I am not sure how I prove this next statement but all the elements of the position of the spheres update atomically (in one operation) and therefore cannot be out of sync on an individual level but my guess is that as each vector contains three floating point numbers any one could be out of sync with the other two.

Anyway, I've changed the code to lock the changes to the spheres and I can no longer reproduce the problem.  At last :-)

Just when you thought this article was over, sorry... moments before writing this up I have come across another error.  This time with particles.  At least this time I can see immediately it is also caused by multi-threading.

My last word on this today...  That particle code has been unchanged for a very long time but threading problems can hit you at any time and may not be easily repeatable!

New Weapons New Effects

After having completed modelling the new alien sci-fi weapons and getting them in to the game I wanted to complete them with their own sounds and visual projectile effects.

I am pleased with the results.  The picture above is just one of them.  I have three weapons ready and two particle effects.  Two of the weapons share the same ammunition so the same effect.

The effects are created with particles and I use a tool I wrote for myself to help adjust the effect until I am happy with it.  I created the tool as open source so anyone can use it: https://gpuparticles.codeplex.com/

I find it takes a while to edit the 2D images used for the particles.  It's not that the particle textures need to be complicated it's just that it is difficult to visualise what they will look like in the effect until you try them.  There's a lot of back and forth getting things as I want them.

That's the texture from the other effect I have created.

Now for the sound effects.  I was able to find some public domain and creative common licenced sounds that are just right for the sci-fi sounding shots.  At the moment I have used them 'as is' but they need some minor adjustments.  The main change and my next task is to normalise all the volume levels so they are all the same volume relative to each other.

That's a job for next weekend I think.

GPU Particles Tool

I have done some additions to Diabolical:The Shooter but there is not much that I can easily show yet.  The additions are a few more animations but they need a bit of adjustment before they are ready to show.  These are the actions for changing weapon, reloading, melee and throwing grenades that needed to be merged in to whatever other animation was playing at the time.

The throwing grenades needed some additional work to line up the point at which the grenade leaves the hand with the moment when the particle effect starts to show the grenade in motion in a nice arc.

I was pleased with that and it leads me on to what else I have been working on...  A tool to help create particle effects.  If you are not a game developer you may not be familiar with what Particle Effects are.  This is really a technique for producing things like smoke and explosions, usually using lots of copies of the same image shown many times in different positions.

Combining that in different ways can produce some very interesting and realistic visual effects.

For performance I have elected to use particle effects that are mainly calculated by the GPU, the graphics card, rather than the CPU of the computer or in this case the Xbox 360.

The disadvantage of using the GPU is that the effects cannot be changed once they have started.  They rely entirely on mathematical formulae setup in advance.  The advantage is that they have less of an impact on performance of the rest of the game.


There are several CPU particle engines available with editors to help create the effects but I struggled to find even one tool to help design GPU particle effects... So I created one and put it on CodePlex:
https://gpuparticles.codeplex.com/

It's nothing grand but will do the job for me and I hope a few others may find it useful.