Extensible 3D (X3D)
Part 1: Architecture and base components

Particle Systems (Custom)

--- X3D separator bar ---

cube Introduction

1.1 Name

The name of this component is "xj3d_ParticleSystem". This name shall be used when referring to this component in the COMPONENT statement (see ISO FDIS 19775-1:200x 7.2.5.4 Component statement).

1.2 Overview

This clause describes the particle system component as a custom extension to Xj3D. This includes how to model particles and their interactions through the application of basic physics principles to effect motion. Table 1 provides links to the major topics in this clause.

Table 1 — Topics

cube 2 Concepts

2.1 Overview

The particle system description is based around rendering fast effects for processes like fire, smoke and snow. Although various physics models are available, it is not meant to be used as a simulation engine for testing particle behaviour models. In short, these are designed for cool looking effects, not rigid analysis systems.

A particle system is a shape node type. This is because we need to know everything about appearance and texturing in order to make the particle system work. A particle system in and of itself is not geometry because it dynamically creates and destroys geometry on the fly it also has a bunch of other factors feeding into the visual output that a typical geometry node does not have - such as time-varying colour values.

The geometry node of a shape node is not used at the first level. If node supports both levels of the specification then the geometry node takes preference over the geometryType field.

The Blaxxun node used the geometry to define the particle geometry, but I really dislike that approach because you can create arbitrarily complex geometry as the particle. Put 500 of these into a system and it gets exceedingly complex and extremely CPU intensive just generating them - particularly if the user starts animating the geometry on the fly (eg IFS). There is no good reason why you should build your snowflake particle system as geometry when you can use a texture. A potential is that a higher level of support might allow custom geometry node usage, but Xj3D would probably never support it.

Many more emitter node types may be available in a full spec. These are just two simple ones allowing fire and waterfall effects. You could do area based or more.

PhysicsModel nodes: This is an interesting one. I was trying to come up with a system that allowed these to be generalised physics models nodes that may be used in other parts of the spec other than particle systems. For example we create a PhysicsGroup that has all the children nodes of that group be bound by the given phyiscs model. We get simple gravity effects etc using this approach. Not sure if what we've got here would be sufficient, but may be.

The physics models are designed to be composable. For example, use the Bounded model with an extrusion as the geometry and then a Wind model and you get cool smoke tunneling effects.

ColorRamp: This uses a variation on the normal use of a colour interpolator. It defines the colour cycle over time for the user. The key is relative time values from the start of the lifetime of the particle. There should be the same number of colours in the node as there are key values. If not, the smaller number of the two values will be used. For particles that last longer than the last time value then that colour will be continued for the rest of the time of the particle.

cube 3 Abstract Types

3.1 X3DParticleEmitterNode

X3DParticleEmitterNode : X3DNode {
  SFNode  [in,out] metadata    NULL [X3DMetadataObject]
  SFFloat [in,out] variation   0.25 [0,∞)
  SFFloat [in,out] speed       0    [0,∞)
  SFFloat []       mass        0    [0,∞)
  SFFloat []       surfaceArea 0    [0,∞)
}

Abstract definition of any emitter of particles. The shape and distribution of particles is dependent on the type of the concrete node.

The speed field is an initial linea speed that will be imparted to all particles. It does not signify the direction (ie velocity) of the particles, just an initial speed. The directional component of the velocity shall be defined by the concrete node representation.

The variation field is used as a multiplier for the randomness that is used to control the range of possible output values. The bigger the value, the more random the output and the bigger range of possible initial values is possible. A variation of 0 does not allow any randomness. Negative values are illegal.

The mass field defines the basic mass of each particle in kilograms. Mass is needed if gravity or other force-related calculations are to be performed per-particle.

The surfaceArea field defines the surface area of the particle in metres squared. Surface area is used for calculations such as wind effects per the particle. This is an average frontal area that would be presented to the wind, assuming a spherical model for each particle (ie the present surface area is the same regardless of direction).

3.2 X3DParticlePhysicsModelNode

X3DParticlePhysicsModelNode : X3DNode {
  SFNode [in,out] metadata NULL [X3DMetadataObject]
  SFBool [in,out] enabled  TRUE
}

Abstract definition of any node that will apply a form of constraints on the particles after they have been generated.

The enabled field allows end-user control about whether this physics model is currently being applied to the particles.

cube 4 Node reference

4.1 BoundedPhysicsModel

BoundedPhysicsModel : X3DPhysicsModel {
  SFNode [in,out] metadata NULL [X3DMetadataObject]
  SFNode [in,out] geometry NULL [X3DGeometryNode]
  SFBool [in,out] enabled  TRUE
}

The BoundedPhysicsModel node provides a physics model that that applies a user-defined set of geometrical bounds to the particles.

The geometry field provides a piece of geometry that models the bounds to restrict the geometry to. When a particle touches the surface of the bounds, it is reflected. This allows the geometry to either restrict the particles to an inside location, or an outside (eg, having them bounce off the ground).

4.2 ExplosionEmitter

ExplosionEmitter : X3DParticleEmitterNode {
  SFNode  [in,out] metadata    NULL   [X3DMetadataObject]
  SFVec3f [in,out] position    0 0 0
  SFFloat [in,out] variation   0.25   [0,∞)
  SFFloat [in,out] speed       0	  [0,∞)
  SFFloat []       mass        0      [0,∞)
  SFFloat []       surfaceArea 0      [0,∞)
}

The ExplosionEmitter node is an emitter that generates all the available particles from a specific point in space at the initial time. Particles are emitted from a single point in all directions at the given speed.

4.3 GravityPhysicsModel

GravityPhysicsModel : X3DPhysicsModel {
  SFNode  [in,out] metadata  NULL      [X3DMetadataObject]
  SFVec3f [in,out] gravity   0 -9.8 0  (-∞,∞)
  SFBool  [in,out] enabled   TRUE
}

Physics model that applies a constant gravity value to the particles. Gravity may act in any given direction vector at any strength.

The gravity field is used to indicate the strenght and direction the force of gravity that should be applied. Force is values in metres per seconds squared (m/s2).

4.4 ParticleSystem

ParticleSystem : X3DShapeNode {
  SFNode   [in,out] appearance        NULL       [X3DAppearanceNode]
  SFBool   [in,out] createParticles   TRUE
  SFBool   [in,out] enabled           TRUE
  SFNode   [in,out] metadata          NULL       [X3DMetadataObject]
  SFInt32  [in,out] maxParticles      200        [0,∞)
  SFFloat  [in,out] lifetimeVariation 0.25       [0,1]
  SFFloat  [in,out] particleLifetime  5          [0,∞)
  SFVec2f  [in,out] particleSize      0.02 0.02	 [0,∞)
  SFBool   [out]    isActive
  SFVec3f  []       bboxCenter        0 0 0
  SFVec3f  []       bboxSize          -1 -1 -1
  SFNode   []       colorRamp         NULL       [X3DColorNode]
  MFFloat  []       colorKey          NULL       [0,∞)
  SFNode   []       emitter           NULL       [X3DParticleEmitterNode]
  SFString []       geometryType      "QUAD"     ["QUAD"|"TRIANGLE"|"LINE"|"POINT"|"SPRITE"]
  MFNode   []       physics           []         [X3DPhysicsModelNode]
  SFNode   []       texCoordRamp      NULL       [TextureCoordinate]
  MFFloat  []       texCoordKey       NULL       [0,∞)
}

The ParticleSystem node represents a complete particle system.

The geometryType field is an indicator for the type of geometry that should be used to represent individual particles. Typically a particle is calculated as a point in space, and then the geometry is moved to the point's location and then rendered using the appearance attributes.

The types of geometry are defined to render in the following way:

The emitter field defines the type of emitter geometry and properties that the particles are given for thier initial positions. After being created, the individual particles are then manipulated according to the physics model(s) defined in the physics field.

The colorRamp and colorKey fields describe how to change the base colour of the particle over the lifetime of an individual particle. The colorKey field represents the time of the particle in seconds, while the colorRamp field holds a series of colour values to be used at the given key points in time. Between keys, colour values are interpreted in a linear HSV space, using the same rules as the ColorInterpolator node. These are defined is per-vertex colour values, so if an appearance node with material is provided, the material properties will override the colour ramp.

The isActive outputOnly field indicates whether the particle system is currently running, based on the setup of the node. For example, using an explosion emitter that generates all of its particles at the first time and has them all die at a fixed time later, the particle system will only run for a short amount of time. After that, nothing is visible on-screen or the particle geometry does not need updating any more. This field will send a value of FALSE when activity has stopped occurring. A particle system without an emitter set can never be active. If the emitter is defined by an externproto that has not resolved yet, isActive shall initially be false, until the point the externproto has loaded and is verified as being a correct node type. If these validity checks pass, isActive is set to true and this defines the local time zero to start the particle effects.

The enabled field allows end-user control about whether this physics model is currently being active and rendering particles this frame. Setting this value to false will immediately remove all visible particles from the scene from the next frame, onwards. Setting the field to TRUE will start the system again from a local time zero. It does not start off from where it was previously. In doing so, it will issue another value of TRUE for isActive. If the user sets a value of FALSE for enabled, isActive will also be set to false.

The createParticles field is used to control whether any further new particles should be created. This allows the user to stop production of new particles, but keep those already existing in the scene to continue to animate. This differs from the enabled field that would immediately remove all particles, where this field keeps the existing particles around until the end of their lifetime. If there are no particles left in the scene, the system is still considered both active and enabled.

The particleSize field describes the dimensions in metres of the width and height of the particle. Changing this value dynamically will only change new particles created after the change. Particles created before this timestamp will remain at the old size. This field only effects particles using "QUAD", "TRIANGLE", "SPRITE" and "LINE" geometry types.

The texCoordRamp and texCoordKey fields are used to control the texture coordinates of the provided texture(s) in the Appearance node, over time. Particle systems frequently like to change the texture on a particle as it changes age, yet there is no good way of accomplishing this through standard interpolators because they have no concept of particle time. This pair of fields hold time-dependent values for the texture coordinates to be applied to the particle. When a particle reaches the next time stamp it moves to the next set of texture coordinates. There is no interpolation of the texture coordinats, just sequenced according to the times defined by texCoordKey.

The node placed in texCoordRamp shall have enough values to work with the numbers required by geometryType. The following numbers and rules for mapping texture coordinates to the quad shall be used:

4.5 PointEmitter

PointEmitter : X3DParticleEmitterNode {
  SFNode  [in,out] metadata    NULL   [X3DMetadataObject]
  SFVec3f [in,out] direction   0 1 0   
  SFVec3f [in,out] position    0 0 0
  SFFloat [in,out] variation   0.25   [0,∞)
  SFFloat [in,out] speed       0      [0,∞)
  SFFloat []       mass        0      [0,∞)
  SFFloat []       surfaceArea 0      [0,∞)
}

The PointEmitter node is an emitter that generates particles from a specific point in space. Particles are emitted from a single point in the given direction and speed.

The direction field defines a specific direction for the particles to be emitted along. If the vector is zero length (a value of (0,0,0) then particles are emitted in random directions from this point in space.

4.6 PolylineEmitter

PolylineEmitter : X3DParticleEmitterNode {
  SFInt32 [in]     set_coordIndex []
  SFNode  [in,out] coords         NULL     [X3DCoordinateNodeType]
  SFVec3f [in,out] direction      0 1 0    [-1, 1]
  SFNode  [in,out] metadata       NULL     [X3DMetadataObject]
  SFVec3f [in,out] speed          0        [0,∞)
  SFFloat [in,out] variation      0.25	   [0,∞)
  SFInt32 []       coordIndex     []	   [-1,∞)
  SFFloat []       mass           0        [0,∞)
  SFFloat []       surfaceArea    0        [0,∞)
}

The PolylineEmitter node emits particles along a single polyline. The coordinates for the line along which particles should be randomly generated are taken from a combination of the coords and coordIndex fields. Particles should be randomly distributed over this line as their starting point, and given the initial speed and direction. If no coordinates are available, this shall act like a point source located at the local origin.

4.7 VolumeEmitter

VolumeEmitter : X3DParticleEmitterNode {
  SFInt32 [in]     set_coordIndex 
  SFNode  [in,out] coords         NULL   [X3DCoordinateNodeType]
  SFVec3f [in,out] direction      0 1 0  [-1, 1]
  SFNode  [in,out] metadata       NULL   [X3DMetadataObject]
  SFVec3f [in,out] speed          0      [0,∞)
  SFFloat [in,out] variation      0.25	 [0,∞)
  SFInt32 []       coordIndex     []
  SFBool  []       internal       TRUE
  SFFloat []       mass           0      [0,∞)
  SFFloat []       surfaceArea    0      [0,∞)
}
Emits particles from a random position confined within the given closed geometry volume.

4.8 WindPhysicsModel

WindPhysicsModel : X3DPhysicsModel {
  SFBool  [in,out] enabled    TRUE
  SFNode  [in,out] metadata   NULL     [X3DMetadataObject]
  SFVec3f [in,out] direction  0 0 0    (∞,∞)
  SFFloat [in,out] gustiness  0.1      [0,∞)
  SFFloat [in,out] speed      0.1      [0,∞)
  SFFloat [in,out] turbulence 0        [0,1]
}

Physics model that applies a wind effect to the particles. The wind has a random variation factor that allows for the gustiness of the wind to be modelled.

The direction field indicates the direction in which the wind is travelling. This should be a normalised, unit length vector of the direction.

The speed field describes the current wind speed in metres per second. From the wind speed, the force applied per unit-area on the particle is calculated using the following formula:

pressure = 10^(2 * log(speed)) * 0.64615

The gustiness describes how much the wind speed varies from the average value defined by the speed field. The wind speed variation is calculated once per frame and applied equally to all particles.

The turbulence field defines how much the wind acts directly in line with the direction, and how much variation is applied in directions other than the wind direction. This is determined per-particle to model how the particle is effected by turbulence.

cube 5 Support Levels

The Particle Systems component defines two levels of support as specified in Table 2.

Table 2 — Particle Systems component support levels

LevelPrequisitesNodes/FeaturesSupport
Level 1 Core 1
Grouping 1
Shape 1
Rendering 1
X3DParticleEmitterNode n/a
X3DParticlePhysicsModelNode n/a
ExplosionPointEmitter All fields fully supported
GravityPhysicsModel All fields fully supported
ParticleSystem All fields fully supported, except SPRITE geometry type
PointEmitter All fields fully supported
PolylineEmitter All fields fully supported
WindPhysicsModel All fields fully supported
Level 2 Core 1
Grouping 1
Shape 1
Rendering 1
Texturing 1
BoundedPhysicsModel All fields fully supported
ParticleSystem All fields fully supported
VolumeEmitter All fields fully supported
--- X3D separator bar ---
[ Xj3D Homepage | Xj3D @ Web3d | Screenshots | Dev docs | Dev Releases | Contributors | Getting Started ]
Last updated: $Date: 2004-10-13 17:30:23 $