Alex Goldring

hey @squarefeet thanks for creating this thread. I read SuckerPunch presentation on their particle engine for their ps4 game "infamous". The slides are at: http://www.suckerpunch.com/images/stories/SPP_Particles_Full.pptx they are some 500MB thanks...

I don't really see this as an issue @cihadturhan, there is an option of creating a library of these parameterizable Emitters, something along the lines of: ``` var BasicPhysicsEmitter =...

Hey @squarefeet, I like your reasoning. Let me try and address some issues: - 2 buffers are to go around the issue of reading and writing at the same time...

here's a promising thread from three.js on the similar concept of using double buffering: https://github.com/mrdoob/three.js/issues/1183

@cihadturhan I'm a little confused on this point. if we use an FBO - then vertex shader is pretty much excluded, you have a quad and that's it, each fragment...

@cihadturhan here's a basic rundown: ``` set fbo1 as texture for lookup set fbo2 as render target (where we draw to) begin render ... render done swap fbo1 and fbo2...

I'd say a SPE mark.2 would make sense :) As a possibility we could bind that engine to this one's API as well, though not as a primary API target...

could make a mapping mechanism for variables, something along the lines of: int -> ... float -> ... v3 -> rgb v4 -> rgba let the mapping mechanism pack/unpack several...

that looks pretty good @squarefeet. Regarding groups, i suggest using a hash of sprite URLs: ``` javascript var sprites = {}; function Particles(url){ var texture; if(sprites.hasOwnProperty(url)){ texture = sprites[url]; }else{...

yup :) besides that, not all operations might end up as assignments, and some "variables" may only need to be temporary