squarefeet / shaderparticleengine Goto Github PK

Hi,

Is it possible to add emitters dynamically after adding a ParticleGroup to the scene? I tried simply doing:

particleGroup.addEmitter( NewEmitter );

But it doesn't show up in the scene. Perhaps I have to mark something as dynamic/needsUpdate?

Also I will need to remove them dynamically too... I saw an issue about that (#13) is still open. I can call particleGroup.removeEmitter(...) OK, but it just freezes it in the scene, as opposed to removing it. Would I also need to remove the whole particleGroup mesh from the scene? In which case I would need to put each emitter in its own particleGroup?

Thanks very much for your library by the way! I'm using it to create an Oculus Rift WebVR demo for fire safety - already got some cool fire and foam extinguisher effects going!

I remembered my old quantum mechanics course and realized it would be nice to visualize probability density of He atom. Maybe we can add it to the demos section. This is how it looks like in 2D There is an old java applet, see how it looks.

Now, what I will do is pretty straightforward: pick a point, place it somewhere according to a probability function like P(r,ν,φ)

Is there any chance to say emitter to randomize points according to a function?

Suggest adhering to a more or less 80 column guideline

The type checking of parameters might be overkill and lead to silent failures and confusing users when it ignores their input:

that.radiusScale            = options.radiusScale instanceof THREE.Vector3 ? options.radiusScale : new THREE.Vector3(1, 1, 1);`

Could be simply

$.extend( that, {
   sizeStart: 10,
   // (other default parameters)
}, options );

The current way is not the threejs way, which also does no type checking ( https://github.com/mrdoob/three.js/blob/master/src/lights/Light.js#L10 )

This style (while entirely personal preference) is super jenky and has low adoption

    }
    else if( ...

And is more commonly } else if ( ... ) { Indirectly influenced by http://robertnyman.com/2008/10/16/beware-of-javascript-semicolon-insertion/

These are just suggestions, with the motivation of helping this library get more popular.

This is a dedicated issue for a subject that was started in #18: the type checking of options.

What are people's thoughts on this (@stemkoski and @delvarworld in particular)?

There are a few ways we could do this:

• Keep it as it is.
• Keep it as it is but throw errors or warnings whenever an option is invalid.
• Use an 'extend' method to copy whatever is passed as options to the group or emitter (as suggested by @delvarworld), no type checking or validation.
• Use an 'extend' method but ensure the options are type checked and values validated.

Any other ideas welcome.

Another api discussion.

As a user, all I want to do is create an emitter, let it do its thing, and then destroy it. Is it necessary to have a ShaderParticleGroup for every single one?

What is the benefit of having one group and multiple emitters? This is something I am unclear about. Do we get shared geometry or something similar?

I've been thinking about using this new and improved particle engine in a game, to create explosions when objects are destroyed.

(1) I noticed that for emitters with a maximum age, after that age is reached, the alive field is set to false and the age is reset to 0 so it is "ready to go again if required". How should a particular emitter be restarted? I naively tried something along the lines of
myParticleGroup.emitters[0].alive = 1;
to no effect.

(2) I don't have an upper bound on the number of potential simultaneous explosions, so even if I could restart them I might run out. So I was also considering the following strategy: adding a flag variable named something like "removeOnCompletion", false by default, but when set to true removes the emitter in question from the particle group. At the same time, adding a clone() method to the emitter class, creating a base instance and cloning it (and adding a few parameter tweaks for variety) every time I need a new explosion effect.

Thoughts?

Hi squarefeet, Is there a way to have the particles already created. I have some smoke particles being created. When a user first visits the page I want the smoke to already be there rather than watch it begin created from nothing. Cheers

Hi there, just wondering about the compatibility of this awesome repo with r68, as I get a warning when initialising saying that THREE.ParticleSystem has been renamed to THREE.PointCloud, I'm guessing this is called within the source by either SPE.Group or SPE.Emitter. Would it be safe to replace the calls to THREE.ParticleSystem constructors?

Edit Welp, looks like THREE handles this for me. Sorry.

Hey thanks for the great library, I've already put it to good use to render star dust in a space sim I'm building:

movitto/omega@7956c17

I'm now working on creating an emitter to generate galaxy graphics and figure I'd reach out. To do so I'm relying on the density wave theory as explained here:

http://beltoforion.de/galaxy/galaxy_en.html

I adapted your library to support another emitter type, 'spiral', which will generate particles on a series of rotated ellipses. The velocity components acts in a sort of reverse manner, moving the particles towards the spiral center incorporating a tangential component to that as well. Since this code is still rough / in conceptual stages I tossed the diff up via a gist:

https://gist.github.com/movitto/8549607

I've captured a simple video of the effect here:

https://www.youtube.com/watch?v=7aKzEoBkOA8

Would be interested in any thoughts you may have as I continue to play around with this. Some work needs to be done at the edges of the galaxy to make the ellipses less apparent and I'd like to vary the z-axis a bit so as to produce a bulge towards the galaxy center. I'd be happy to send a PR request if you'd rather discuss the code there.

Am planning on using it next to generate some explosion effects when ships are destroyed. Am thinking this will entail sequencing a few emitters at particular points in time, though am all ears for alternate solutions.

Again thanks for the awesome lib,
-Mo

particleEmitter.alive should (conceptually) represent the fraction of particles that are emitted; if alive is 0.5, the number of emitted particles should be cut in half. Does this seem like a good idea? Is it hard to implement?

(Reason: rocket engines do not have an "on/off" switch; they have variable thrust, and I'd like to change the number of particles as a result.)

Hi,

This is related to the sprite sheet animation issue but is probably good to mention separately since it is for a different use.

Having different particles share the same texture implies adding UV options such as texture coordinates, width and height.

I'd guess this feature is a subset of spritesheet animation so one would have to keep in mind the linked issue when implementing this.

Here is information on GPU particle performance concerns. It's explained in a way beginners can understand but it's still possible that you can find hindsight for improvements on SPE. If not it is quick enough to skim through the page, pictures and titles are self explanatory :)

When I add a emitter to my scene with the type of disk it always faces the same direction. Now I have noticed that you can rotate the hole mesh the particle system is applied to but that messes up my position settings. I'm trying to have the disk always face the camera of my three.js scene. Which Is often located at vector{0,0,0}. Any help would be greatly appreciated.

Since there are quite a few functions shared between ShaderParticleGroup and ShaderParticleEmitter, I've been experimenting with putting these functions into a shared object, currently called ShaderParticleUtils. Each one of these functions is then attached the to *Group and *Emitter prototype objects. It's nice and DRY.

I think this is a good route to go down, but my question is about whether this utils object should be exposed/accessible or not. I'm currently thinking of wrapping the build versions (both minimised and not) within an anonymous function ((function() { ... }());) so the utils are not exposed but the Group and Emitter are.

I'll put these changes as they are into the dev branch and reference it here when its done, then we can work from there; I'm aware my use of git needs to improve, so I'll have separate feature branches going forward.

Thoughts @stemkoski and @delvarworld?

Hi,

I tried to change the velocity on a running emitter.
Changing the position or particlesPerSecond works, e.g.:

particleGroup.emitters[0].position.add(new THREE.Vector3(11,15,10));

But velocity/velocitySpread/size wont take the changes.

I tried to break down the code and it looks like the velocity is created on addEmitter, but I cant figuere out why position change works buw velocity dont.

Can you give me a clue how I could add that feature or is it a bad idea (performance)?

greets

After looking at the first video on http://gamedevelopment.tutsplus.com/tutorials/make-a-neon-vector-shooter-in-xna-particle-effects--gamedev-10111 - particle gravity emitters with definable positions, strengths, and radiuses of influence would be AWESOME.

So would the ability to define simple collision planes (but that may be a bit too much)

Currently looks like there's no way to remove particle emitters?

Interesting problem. Culling is done using geometry bounding volume, and that's not computed propely for particle emitters, so if point "x:0, y:0, z:0" is not in camera's view - whole emitter gets culled. Need to address this by using infinite volumes or recomputing volumes every simulation tick (which is probably not practical?)

Here's original topic link:
http://stackoverflow.com/questions/26747759/ugly-render-on-clouds/26748408?noredirect=1#comment42098284_26748408

this bit should fix things:
https://github.com/mrdoob/three.js/blob/1769fbfc6c994b51a54c15a5c096855fd3cb8a1a/src/renderers/shaders/ShaderChunk/logdepthbuf_fragment.glsl

It seems that dev is out of room when I try to add new properties:

ERROR: Implementation limit of 16 MAX_VERTEX_ATTRIBS (e.g., number of generic plus conventional active vec4 attributes) exceeded, shader uses up to vec4 attribute 16.

Could we implement a clever solution, like pass in some values as vectors, arrays or matricies? Squashing colorStart, colorMiddle, colorEnd into one mat3 for 3 colors?

This issue reflects the same problem described in #58, which was closed because the author found a workaround. The original problem raised about the behavior of addEmitter and removeEmitter still stands -- these features don't behave the way they are named. Using addEmitter some time after I've added the mesh of my SPE.Group to my scene has no effect; nothing is rendered. Calling removeEmitter just freezes the last state of the removed emitter in the scene.

Thanks!

Hey what were your thoughts on supporting emitters that emit fewer that 1 particles per second. The current Group#addEmitter implementation defines particles per second like so (when duration isn't specified):

emitter.particlesPerSecond = emitter.particleCount / that.maxAge | 0

When particleCount > maxAge (eg more than one particle per second) the bitwise-or clears the decimal / rounds the pps down to the nearest int (was this intended or should it be a ||?)

If particleCount < MaxAge this gets rounded to 0, resulting in no particle generation. Removing the bitwise-or in that case results in the intended effect, with the particles being generated at < 1 pps.

As always, thx for all the recent updates, they look great!

Particle speeds are currently calculated as a percentage of the maximum age of the emitter. These need to be decoupled.

Following incredibly valid points from @Usnul and @cihadturhan, in order to get this library into the state that it deserves, a rewrite would appear to be necessary. This thread is for anyone to add their 2-cents/pennies/other-currency worth of thoughts on improvements, new features, etc. The more critical, the better (IMHO) - that's one of the major ways to ensure the new version is as easy-to-use and performant as possible.

I do ask that any requests/comments should follow the same format as below: one feature per bullet-point, and grouped into either Required or Nice-to-Have (or both, if you're feeling generous).

Thanks!

Required

• Sprite-sheet support for both animated textures and shared texture maps.
• < 1 particle per second.
• A much more intuitive API (at the moment, there are just far too many options. These need to be grouped, or...??)
• Dynamic, and efficient, creation/destruction of emitters.
  • Choice of immediate destruction vs. stopping the emitter and waiting for existing particles to die before being removed.
  • Removal of static emitters.
• Remove the 'Group' constructor, and have only one constructor for the entire library.
  • 'Group' constructor should be replaced by internal logic that groups emitters by texture.
  • A user shouldn't have to create a group manually.
• Runtime adjustment of all parameters.
• Efficient callback/event system that allows users access to individual particle parameters on a per-frame basis.
  • This could (read: probably will) have a negative performance impact, so will have to be thoroughly thought-out.
• "Spiral" emitter type
• An implementation of 'angleAlignVelocity' that actually works when particles are not starting from vec3(0,0,0) position.
• A more intuitive way of setting options. At the moment, it's pretty crappy.
• More efficient JS and GLSL code. It's currently not quite as performant as I'd like, and I know that there are places to squeeze!
• Improved documentation and examples. Maybe a few tutorials.
• It's own website to hold the documentation and examples. I'm not sure that gh-pages is public-facing enough.

Nice-to-haves

• Gravity-well or general "gravity" support.
• Vector-field support.
• Angular velocity and/or acceleration instead of/as well as the current angleStart/Middle/End properties.
• An incredibly difficult one, this: a way to generate fairly realistic smoke. Would require a very high particle count, and either vector-field support, particles interacting with other particles, or a dynamic 'wind' system. Maybe all three and yet more still...

for example, parseInt is the one that takes a radix, not parseFloat, smartypants

Request to remove one, or better document both

Hello,
i tried to implement the basic particle emitter example using the latest three.js r68.
I build a demo where the emitter stays in front of the camera and is pointed at it, which only seems to work with r65.

With r68 the emitter is disappearing when moving the camera and pops back in unpredictable.
Any ideas?

Hi there,

I've been working on an explosion effect mostly from your pool example, but am running into a timing variables problem. I would like to instantly init all of the particleGroup, but then allow the particles to last for 60 seconds. Right now they last for 60 seconds, but it inits the 1000 particles over all of the 60 seconds. Here is a jsFiddle of my scene (using the jsFiddle logo just for the example): http://jsfiddle.net/e65rpc2k/

Am I mixing up the API variables or something? Thanks for the help!

A sizeEnd value of -1 is required to get particles to shrink to 0 size.

I don't see any instance of rotate nor spin in the documentation

Using a variable timestep (rather than fixed) causes pauses in the emitter (to be expected).

What isn't expected is that these pauses (if occurring during the first 'cycle') continue throughout an emitters lifetime.

Hi,

I'm experiencing some problems with SPE last version.
When my emitter cube is behind the screen border, its tail instantly disappears.

Image is more explicit than a long speech:

• Emitter at the screen border
• Few pixels later, emitter just behind the border

I have another problem with SPE if you're interested : http://stackoverflow.com/questions/26723575/three-js-shaderparticleengine-spe-group-tick-bad-delta-argument
Is SPE hating last Three.js revision or am I doing so much things wrong?

I wonder why are we extending default options here with so long way

How about if we define an extend function

SPE.extend = (target, source) {
    target = target || {};
    for (var prop in source) {
        if (typeof source[prop] === 'object') {
            target[prop] = extend(target[prop], source[prop]);
        } else {
            target[prop] = source[prop];
        }
    }
    return target;
}

and then use it like how jquery does

SPE.Emitter = function(options) {
    var defaults = {
        particleCount: 100,
        type: 'cube',
        position: new THREE.Vector3(),
        radius: 10,
        radiusSpread: 10,
        radiusScale: new THREE.Vector3(1, 1, 1),
        colorStart: new THREE.Color( 'white' )
        // other defaults and internal variables
    };

    SPE.extend(defaults, options);
    SPE.extend(this, defaults);

}

So, would it be a cleaner approach and easy to read ?

EffectHub is a particle effect repository originally destined to Away3D. Anyone can put particle effects in there for the world to use.

They made a pretty good particle editor accessible both online and as an Air app, and a JSON file format, AWP, that is exported out of the editor.

Then they use an AS3 library to translate this and plug the effect into Away3D at runtime.

The Air editor and parser library can be found here.

While a JS interpreter for the AWP format would be pretty good already, it would perform better to make a small app that converts AWP files directly to SPE compatible particle setup code, and output either a JS file or JS code to copy and paste. (so that there's no loading and parsing of AWP files at runtime)

I would be happy to do it for you but sadly I can't afford making this on my free time, so only if you hire me or in the distant future. Apologies ^_^', especially since I really appreciate your work on SPE.

Finally, looking into the editor functionality could prove useful to find out features that are yet to be supported in SPE. The editor is not open source, but all that matter really are the features and the output. (Also eventually the parser, but that one is open source)

Hi,

Just a quick question/note. The readme.md states:
"This project requires THREE.js revision 58 to revision 65."
Does this mean, that it will not work with THREE.js revisions higher than 65?
(Current stable three.js is rev 70)

If those are just the minimum required version, it should state that.
I am a little confused. (I'll now just try to get it to work with rev 70 :) )

So I really like the idea of putting GPU to work on those particles, so I love what this project is trying to do. That being said, I'm having mixed feelings about it's usability for anything semi-realistic in terms of use-cases. I'm writing a wrapper around this library for my purposes, and I couldn't figure out why an emitter i add to the group doesn't show up - looking into the code it's obvious now why, because the vertex buffer is modified, but threejs isn't going to find out about it, instead you have to re-generate the geometry, even then you need to set update flags. In short - just pushing vertices to the geometry in Group implementation only works until you actually pass the mesh to scene, once THREEjs gets hold of it and does it's chunky chunky magic - adding emitters to the group is about as useful as writing code in unary. Next up is the API itself, what you would want ideally is a piece of logic that removes need for "group" all together, because a "group" is something to allow texture re-use, we can create an abstraction which will keep "groups" itnernally, but it will create/destroy them on the fly, as emitters get added/removed. Just by looking at "texture" attribute of an emitter, you could assign it dynamically to one group or another if you wanted that texture re-use. Having an API which would handle the inherent dynamic behaviour that comes with use of particle systems would make it potent and useful, as it stands though - the API is arbitrarily convoluted and doesn't even do what it should. My frustration is with the API, I still respect all the work that went into this project, but as it stands - i don't really see a way forward for this code-based, without major overhaul. The only supported usecase here is pre-defined emitter pools. If your setup is not static - this library doesn't assist you directly. One can probably get around that by just spawning groups for every new emitter, but this defeats the whole idea behind them and is a workaround for what API should support via addEmitter at least.

I think that for a spherical emitter, particles should be moving away from the center of the emitter, so the calculation of the particle velocity depends on the position of the particle. However, in the _resetParticle function in ShaderParticleEmitter, only positions are recalculated -- it seems that particles are reusing their previous velocity value.

I'm not sure how this should best be fixed -- my initial thought would be to pass the index of the particle (instead of the particle's position) as the argument to the _resetParticle function -- then access and change the velocity attributes of the particles.

I've found a guy on youtube which very cool 3D Music Visualizer using particle dynamics.

If you look first and fourth one, it seems very doable with this library.

However, I'm not sure how to make particles behaves like smoke as you see in examples. Any ideas how to make it possible?

How to control the opacity of a emitter in my render loop, setting the opacityStart = 0 has no effect,

setting the velocity and acceleration to a new Vector works fine!

A continuation of @movitto's points on increased memory usage in FF with the latest release from issue #22.

After upgrading to this new release. This amazing particle engine no longer works =[

More than likely due to: mrdoob/three.js#5805

I'm taking some inspiration from this page: http://webglsamples.googlecode.com/hg/sprites/index.html

I have made some progress here: http://andrewray.me/shader-animation (ignore the bubble stuff, this is my test bed)

The commit for that is here, which contains some of the modifications i'm making to this library: AndrewRayCode/Big-Bubble@1adcb9c

Is this something we might want in core? It's very rough right now. One issue is that it requires external driving JS to tell the shader what tile each sprite is on. This could be modified to be in the shader library.

hi,

I am using typescript to create my game.
(Typescript compiles down to javascript and can use typescript definitions to use pure javascript libs such as three.js or the ShaderParticleEngine.)

For three.js there is a definition available at definitelyTyped on github (they gather definitions for libs that don't provide them themself).

I made a minimal ShaderParticle.d.ts definition file, which enables use of groups and emitters in typescript.

It's only a few lines, would you be interested to host it in this project?

(It's ok if you are not, I'll then look into getting it into definitelyTyped - but I have not yet looked into their policies regarding size of projects or how to get definitions there.)

If you would just like to include it, here is the file:
http://jppresents.net/static/files/ShaderParticles.d.ts

Correct me if I'm off but from what I gather the Emitter#tick operation will reset vertices and create vertices independently of one another. eg the maximum particle buffer size is computed based on age and emitter count before hand and on each run the vertices that are no longer alive are reset after which a number of vertices determined by the count and interval duration are created.

Would it be possible to extend the tick method and/or add an alternate that will only create the number of vertices to satisfy a fixed amount after the ones no longer alive are retired? Thus the developer could set a threshold for the number of particles created without manually balancing / tweaking maxAge & particlesPerSecond

Sound sane? If so I can look at implementing it at some point (that is of course unless someone gets to it first!)

http://www.unrealengine.com/files/misc/The_Technology_Behind_the_Elemental_Demo_16x9_(2).pdf
In general, this is a more flexible model, and one which has a good mapping to GLSL (approach is described in the slides on abstract level).

I couldn't help but notice how fast the API seems to grow, while it's nice to add flexibility, I feel better structure is lacking. Having an explosion of API parameters may help derive performance during initialization of an emitter, but that ultimately is not the bottleneck; unless you are creating/destroying emitters thousands of times each frame, and then you particle system is probably a wrong solution to your problem.
It would be nice to see a more structured, simpler API such as one in "sparks" project, admittedly sparks API has its own limitations, but the idea is quite appealing.
https://github.com/zz85/sparks.js

Hello,
I updated to 0.7.7 today and my smoke emitters doing some crazy stuff now 👻

They disappeared, so I checked the new examples and added the time delta to particleGroup.tick( dt ); which was running without it before. Is this necessary/recommended now?

It led me to another problem, where it looks like the emitter is "running out of particles" after some seconds of emitting. This happens to me below a particle count of 710.
(This only happens when using delta-time)

See demos here:
http://three.thiele-medien.de/emitter/examples/basic.html
http://three.thiele-medien.de/emitter/examples_v75/basic.html

if your emitter is not at origin the angular align points to the origin, not the emitter. Heyo @stemkoski

I might be wrong but it seems that there is an issue with scaling. When I test with the examples things look very different when full screened compared to 1/4 screen. It seems like the particle sizes are not being scaled.

The speed / velocity setting on dev seems to be a bit off, particles are being sucked into the center of emitters I create

js/ShaderParticles.js states version 0.7.7 in comment while js/ShaderParticles.min.js says 0.7.8