The Drag[en]gine is a fully customizable game engine and game development environment designed with modularity and extensibility in mind not requiring expensive licenses.

Post news Report RSS More about Particles

Some additional improvements on the particle system before tackling the next part.

Posted by on

Before venturing on to the next construction sides some more improvements have been made on the particle system to increase their use. This includes especially an editor, additional parameters and controllers.

Changes on Parameters

First some new parameters have been added in addition to the existing ones from the last news post. This includes:

  • Time To Live
  • Interval
  • Cast Angle X
  • Cast Angle Y
  • Roughness
  • Elasticity

Roughness and elasticity are two new physics parameters for cast particles. The influence how particles act upon colliding with world geometry. Elasticity defines how much of the impact energy is conserved. Hence a particle with an elasticity of 1 bounces of a surface with the same velocity as it had before the impact. With a value of 0 particles immediatly stick to the surface they hit. You can also use larger values which would cause particles to increase their velocity upon impact but that should be used moderately. Roughness influences how uneven the particle is. In general the material property of the texture of the hit object determines in what direction the particle is deflected. Using roughness this can be done on a particle basis too. Hence a particle hitting a flat mirror like surface with a roughness of 0 would bounce off the surface perfectly as it would be a flat sphere. On the other hand a roughness of 1 causes the particle to bounce unpredictably off the surface. This allows to add some more credibility to surfaces.

Time to live, Interval, Cast Angle X and Cast Angle Y have been direct parameters so far. Now they are true particle parameters with all the bells and whistles except a progress curve as these are cast time parameters. Cast Angle X and Cast Angle Y define now the direction relative to the emitter orientation the particles are cast. Especially using the new curves and controllers this yields some interesting properties.

Controllers

Controllers have been added similar to the ones in the Animator class. These controllers can be used as input for curves. The good thing on controllers is that they allow to influence many parameters at once but in different ways. Particle systems can altered with them on the fly at run time without the limitations other game engines tend to have. You can use as many controllers as you want... that is... more than there are curves obviously doesn't make sense as you can only assign one controller at max to a single curve. This aside though you can assign any kind of value to the controller including incrementing the controller using elapsed time. The controller takes care of clamping or wraping the values.

Cast Curves

In the last news post the cast part of parameters have been shown. These have now been improved using an additional curve as well as using controllers to define the input value for the curves. Parameters have now the following components:

  • float castValue
  • float castSpread
  • Curve curveValue
  • Curve curveSpread
  • Controller controllerValue
  • Controller controllerSpread
  • Curve curveProgress

You might notice that the cast value is now defined using castValue and castSpread instead of castLower and castUpper. Hence you define now the cast value range using the middle value and a spread around this middle value. This definition has the advantage that the middle value as well as the spread can be controlled individually if required. The sample video contains an example of this. The particle parameters are now calculated like this:

ParamValue = value OR curveValue( controllerValue )
ParamSpread = spread OR curveSpread( controllerSpread )
CastValue = ParamValue + ParamSpread/2 * random()
RenderValue = CastValue * progressCurve( particleTime )

This might look now a bit complicated but it's actually quite simple. The birth value of a particle is ParamValue plus a random ParamSpread around it. Spread actually defines the entire range of the spread hence the actual range of the value is (value-spread/2) to (value+spread/2). ParamValue and ParamSpread can now be either defined by a constant value (value, spread) or by a curve (curveValue,curveSpread). The curve is used if it has points and has a controller assigned. As you can see you can precisely define the middle value and/or spread for new born particles to your hearts desire. The progress curve works as before. More changes will not be done to this system as now you should have all you need to make interesting particle systems.

Particle Emitter Editor (IGDE)

As stated in the last news post a Particle Emitter Editor has been created. It works rather simple as you can see from the image below. You can define exactly one emitter in this editor. This is different than other game engines where you edit entire particle systems composed of emitters. This choice has been done as this way the logic of a particle system is entirely defined by the game scripts instead of hardwired into the game engine. You have therefore all possibilities available that your script module of choice provides you. The particle emitter is stored as an XML file and can then be used to build an actual engine particle emitter with it. The DragonScript module is going to get some helper classes to allow you handle such particle emitters easily in an actual game. More is though always possible if you are not shy of a bit of coding.

Particle Emitter Editor

Multi-Layer Transparency

In the last news post I forgot to talk about the rendering of particles. Most particles are transparent to a smaller or larger degree. Rendering these particles can be done using Deferred Rendering with Transparency as mentioned in an older news post. While this works with particles the amount of overdraw would still cause slowdown which is not required since particles have special properties. Due to this the Drag[en]gine handles particles differently than transparent objects. They are rendered using a modified Forward Rendering. Why modified? It's a forward rendering variation which uses deferred rendering properties. It's therefore a mix between the two combining the advantages of both worlds. Particles are therefore rendered back to front while taking two depth buffers into consideration. This allows to render particles correctly in front, behind and mix in between transparent objects while rendering them with the speed of forward rendering but with proper transparency like deferred rendering.

The video below shows everything mentioned in this news post. Don't forget to enable your speakers as this time 'round voice over is in the video.


Miscellaneous

As you might have noticed it's MOTY time again. If you would like to show support for this game project and game engine project you can do so using a vote. You might notice that there is no vote button you can use on this profile. This is because game engines can not be voted for. If you want to vote you have to do so in the „Epsylon" game profile. There you'll find a vote button.

Outlook

Particles should be now wrapped up enough for a first release. Now I can „really" go on to tackle improving collision using Bullet. Also planed are some other improvements but more will not be disclosed right now.

Post a comment

Your comment will be anonymous unless you join the community. Or sign in with your social account: