Plan for Charles Savage
by Charles Savage · 03/18/2004 (5:02 pm) · 2 comments
The spline particle system is composed of three parts.
You have your spline, object 1.
You have your nodes, object 2.
You have your particles, object 3.
1. Spline is a general purpose name for what this can look like. If you ever saw the makings of Xmen with the tornado's, forget if it is X1, or X2. The tornado has a spline or backbone.
2. The spline is made up of nodes, these can be arbitrary points in the object space, or they can form a thread/backbone/spline. These points can have independent animation or movement within the spline. Ie, a tornado the nodes move in a circle, back-n-forth, etc. And all the particles attached to the node move like the skin of any animated object.
3. The particles, like nodes, can have independant motion. Ie spin in place, rotate around node, and/or any other predefined behavior. But they stay relative to the node, IE keep the same position relative to the node if the node moves.
What makes this system different than the current particle engine is that there is no generation of new random particles. Of course that could be added, but it isn't inherent in the system. The idea, a tornado, is to have a set number of particles continually repeating a set of motions. A waterfall is another perfect example. Set the nodes, set the particles to cycle in a curve and/or straight line/plane.
At least in the beginning iteration of this SPS is to have particles remain with one node, but I would like to add the ability to migrate particles. That way you could get a 3rd demension of particle motion. IE, not just around a node, but migrate from bottom to top node, say of the tornado the particles rotate wider and wider (greater radius from spline) as they get higher up. Still following the spline.
Somewhere along the line is to make sure collisions work, because this is needed for my game.
Lastly to incorporate this with physics, perhaps the ODE, though I havn't even begun to look at this.
-----
My current problem is figuring out what is to be script side. I _want_ all behavior to be defined script side. What I need help with is determining the best method of doing this, because the best use of this technology is not to make predefined behavior that scriptors have to accept. I'd prefer to make an OnTick() event call that gets handled on the client that makes the spine act the same on every client, or relatively close enough so that no one can really tell there is a difference. But someone told me 'do not' call script every 32ms, as OnTick() could be made too, so I have no real answer to this deliema, other than perhaps making pre-defined algorithms of behaviors, and the scriptors can chose to use them, and these would be hard coded C++, called based on flags and ugly switch/ifs inside a long nasty OnTick().
-----
Credits to date: Mathew Fairfax (ideas & code)
Melv May (fxRenderObject)
You have your spline, object 1.
You have your nodes, object 2.
You have your particles, object 3.
1. Spline is a general purpose name for what this can look like. If you ever saw the makings of Xmen with the tornado's, forget if it is X1, or X2. The tornado has a spline or backbone.
2. The spline is made up of nodes, these can be arbitrary points in the object space, or they can form a thread/backbone/spline. These points can have independent animation or movement within the spline. Ie, a tornado the nodes move in a circle, back-n-forth, etc. And all the particles attached to the node move like the skin of any animated object.
3. The particles, like nodes, can have independant motion. Ie spin in place, rotate around node, and/or any other predefined behavior. But they stay relative to the node, IE keep the same position relative to the node if the node moves.
What makes this system different than the current particle engine is that there is no generation of new random particles. Of course that could be added, but it isn't inherent in the system. The idea, a tornado, is to have a set number of particles continually repeating a set of motions. A waterfall is another perfect example. Set the nodes, set the particles to cycle in a curve and/or straight line/plane.
At least in the beginning iteration of this SPS is to have particles remain with one node, but I would like to add the ability to migrate particles. That way you could get a 3rd demension of particle motion. IE, not just around a node, but migrate from bottom to top node, say of the tornado the particles rotate wider and wider (greater radius from spline) as they get higher up. Still following the spline.
Somewhere along the line is to make sure collisions work, because this is needed for my game.
Lastly to incorporate this with physics, perhaps the ODE, though I havn't even begun to look at this.
-----
My current problem is figuring out what is to be script side. I _want_ all behavior to be defined script side. What I need help with is determining the best method of doing this, because the best use of this technology is not to make predefined behavior that scriptors have to accept. I'd prefer to make an OnTick() event call that gets handled on the client that makes the spine act the same on every client, or relatively close enough so that no one can really tell there is a difference. But someone told me 'do not' call script every 32ms, as OnTick() could be made too, so I have no real answer to this deliema, other than perhaps making pre-defined algorithms of behaviors, and the scriptors can chose to use them, and these would be hard coded C++, called based on flags and ugly switch/ifs inside a long nasty OnTick().
-----
Credits to date: Mathew Fairfax (ideas & code)
Melv May (fxRenderObject)
About the author
Torque 3D Owner Chris "DiGi" Timberlake