As the latest client data hierarchy draft revealed a gaping hole regarding the exact use and requirements of "effects", I've spent those past days diving into the tediousness of "particle systems" - those are the core of CS effects since they are used to simulate rain, snow, explosions, fires, fountains etc. On the bright side, particle systems are actually explained in a bit more detail than other things in the CS manual, mainly because they have been apparently changed quite significantly so the manual's author felt the need to provide examples for using the new code. On the darker side, they are stuffed into the clunky system of various plugins + xml + factories + meshes + shaders + 1001 attributes to set for the smallest thing, so that 3 drops of rain get you sweating and swearing through the usual multiple layers of all-possible-things in slightly-different-ways.

To start with, trying to find a proper place where those particle systems belong in a sane hierarchy of CS items is rather dubious because particle systems are a combination of almost everything in there plus "emitters" and "effectors". And ~everything has to do the dance of factory+instance although each time pretty much everything gets re-set anyway¹ so it all feels like an exercise in bureaucratic-coding, to make one's stomach heave anew. Anyway, the core components of particle systems are those:

1. A non-moving mesh that is the "particle". Like all other non-moving meshes, this can naturally have one or several materials/textures and shaders (with the load of shader variables) but unlike all other non-moving meshes, the geometry is not something one sets explicitly via vertices and triangles and all that - instead, the geometry is fixed and set by the provided "plugin"² for particle systems! Setting various parameters allows one to tweak this geometry to some extent but that's about it. According to the manual, the existing plugin simply makes all particles rectangles - you can set however their size and their orientation with respect to the camera.
2. Any number of emitters. As the name suggests, the emitters create and launch about new particles according to another set of parameters. For the same particle system, one can in principle add any number of emitters but there has to be at least one emitter for anything to happen, of course. There are a few types of emitters that differ mainly in the shape that is covered by the launched particles: sphere, box, cylinder, cone.
3. Any number of effectors. From my tests, those are not even mandatory. They provide some ways to influence the existing particles (usually their movement but supposedly any aspect of them; the manual says that effectors "put different kinds of effects" on particles, "be it physical or non-physical effects"). There are only three available types of effectors: force, lincolor (interpolates the colour of each particle between two values based on the remaining time to live) and forcefield.

Once a particle system is created, the way it works is relatively straightforward: the engine calls on every frame the update loop of each particle system that is visible to the user; the update loop deletes old particles, polls all emitters to emit new particles, polls all effectors to apply their effects and then performs the final transformations if/when such are required. Basically a particle system is designed as a sort of predefined show happening at some place in the world for some specified interval of time with rectangle-shaped actors only (but possibly various costumes via materials).

For practical tests, I've created from code several types of particle systems including "rain", "fountain" and "fire". While the general mechanics of it all seem to work fine and the parameters seem to do indeed what is expected, there is still some weird issue with the materials - all the stuff looks brown-ish, no matter what texture or material is loaded. Since otherwise a material is just a material and it's clearly loading fine for anything else, I quite suspect that the trouble here is the shader: although in principle any shader could be used, there is a specific particle_shader that is used but not really documented anywhere (ie there is the xml of course but that has some variables and possibly references and it is *one* area that I rather avoided to fully get into, so far). Added on top of all previous experience, I'd rather say that sooner or later I will still have to dig shaders too, what can I do. Anyways, at the moment I am mostly interested in having the mechanics in place and figuring out the parameters, so in this sense it's a success, here's some snow and rain falling down on naked girl, at times with erupting particles too:

Euloran Snow - it's more brown than white!

Undisturbed euloran woman among erupting stuff and pouring rain.

Let it rain with brownish nothings.

Given the above, I'll mark the "particle systems (Air)" as explored for now and move on to procedural textures (Water) to see what further catralliard of parameters I find there too. The test of movement for effects (ie following a char or something) is still on the list too but I see it as more general really - since the whole particle system is simply a mesh, having it follow another mesh should be just a matter of giving its position as relative to that rather than absolute. At the moment I'm not sure where exactly would be the best place to do this but I think it requires a bit more consideration because it's possibly a more generally useful thing to have - some items/characters might simply follow others at some point/for some time, anyway.

1. It would even be hard to keep track of what is same and what is different given how many darned setThis and setThat one calls. ↩

2. The plugin's code can be found in CS/plugins/mesh/particles/object/. ↩

Category: Eulora

Comments feed: RSS 2.0