Proposed Features for Milestone II?

[zz85]

I have written on some thoughts on features for development to the next milestone.

https://github.com/zz85/sparks.js/wiki/Roadmap-to-Milestone-II

If anyone have any comments, feel free to comment and discuss here.

[jeromeetienne]

https://github.com/jeromeetienne/sparkseditor/issues/1 here are notes i took in the past.

In short and from memory.

• it should be made object oriented.
  • Proper inheritance
  • suitable sanity check
• plugins should not be included in core
• plugins should be streamlined
  • Current api is inconsistent

Main issue: it will break backward compatility main adantage: core much cleaner, smaller. Easier to maintain

This was my reasoning 3month ago at least

What do you think?

[renegademaster88]

I agree you should define a proper abstract base class for Actions and Initializers etc. that all inherit from.

If you truly want to de-couple from THREE or any other library, then you should define an Interface between the Sparks and the rendering API. At the moment its a bit of a mess. I finally figured out the particle pool you used for WebGL renderer, but still haven't fully converted between Canvas and WebGL.

So much of the cool stuff in the examples is actually outside of Sparks at the moment. so its hard work to make your particles do the cool things you can see - copying shaders, setting up Pools, etc. etc.

Setting up the Sparks Emitter and adding Actions & Initializers is so easy, so we should make joining it to THREE just as easy. If you define an interface then someone can build a class to joining to Copperlicht for example too.

If i finish my webGL sparks object i will upload for you to have a look at (its like the Pool, but also handles THREE objects).

[jeromeetienne]

when coding https://github.com/jeromeetienne/sparkseditor i did a threex trying to make it easier to link with three.js.

• the threex https://github.com/jeromeetienne/sparkseditor/blob/master/vendor/js/threex.sparks.js
• it is based on sparks example. maybe a better handling of the particle size. i remember fixing a bug to make particle smaller based on Z position.

You init the threex like that

threexSparks    = new THREEx.Sparks({
    maxParticles    : 400,
    counter     : new SPARKS.SteadyCounter(300)
});

Then you config the particules

var emitter = threexSparks.emitter();

// the initializer
emitter.addInitializer(new initColorSize());
emitter.addInitializer(new SPARKS.Position( new SPARKS.PointZone( new THREE.Vector3(0,0,0) ) ) );
emitter.addInitializer(new SPARKS.Lifetime(0,0.8));
emitter.addInitializer(new SPARKS.Velocity(new SPARKS.PointZone(new THREE.Vector3(0,250,00))));

// the actions
emitter.addAction(new SPARKS.Age());
emitter.addAction(new SPARKS.Move());
emitter.addAction(new SPARKS.RandomDrift(1000,0,1000));
emitter.addAction(new SPARKS.Accelerate(0,-200,0));

// once initialized you start the emitter like that

    // start the emitter
    threexSparks.emitter().start(); 
    // add the container to THREE.scene
    scene.add(threexSparks.container());

after that you update at each render loop iteration like that https://github.com/jeromeetienne/sparkseditor/blob/master/js/main.js#L70

    threexSparks.update();

[renegademaster88]

Hi Jerome, that looks really great (much better than my version!)! I'm going to look at more closely today to see if i can implement it to solve my current problem of converting from Canvas to WebGL.

I notice there is a shader there. Could we extend this class to allow easy use of a Shader lib? What i really want to be see is

THREEx.sparks ( parmaters ...)

add some actions & initializers

choose a shader

GO!

To get some cool results. Something that simple would open up SPARKS to a much wider audience. Plus it makes Sparks about choosing your components and tuning them to get the result you want rather than doing time consuming 3D programming. It makes it about visual creativity and not so much about math / coding.

[jeromeetienne]

• yes material could be made tunable in the constructor
• thus the user can setup his own if he see fit
• and people who doesnt care, can use the default one

[renegademaster88]

Yes that's it. If we used a standard set of attributes like size and colour for our shaders, then we could provide a shader lib along side that we knew worked within those parameters.

part of the interface should allow change and update of the shaders.

[zz85]

Seems like inheritance is a much requested feature. I can work on this after I've fix some stuff in three.js.

[jeromeetienne]

Any feedback on the rest?

[zz85]

I don't get that part about plugins. What do you define as the core and plugins?

[jeromeetienne]

i meant something like

• core == the engine itself. aka the mechanics
• plugins == all the initializer and actions

Thus it show the flexibility and encourage people to code their own

[zz85]

I see. I wouldn't call them plugins as it would sound like a complicated system. For now we could follow something similar to how three.js does it - we will have a build with everything included by default, and anyone is free to create custom build with perhaps bare minimal.

I hope I won't be falling into a second system effect (http://en.wikipedia.org/wiki/Second-system_effect) here, so I'm trying to make things simple, while ironing the issues we have. After a few more iterations, the API should be better and more consistant :)

[jeromeetienne]

currently several initializer/actions stores their data in the global object tho. It increase the risk of conflict. to enforce a clean distinction between core and plugins may reduce the risk of conflict. Thus increase the extensibility. This was my line of reasoning when proposing this.

About three.js extensibility, im trying to make it happen with tQuery and it isnt trivial :)

[renegademaster88]

Hi guys, after having worked with both your systems over the past 2 weeks I cant help but stress the problems caused by differences between 2D context and 3D context rendering. Using Particle for 2D context is certainly more straight forward, and Jeromes threex.sparks certainly goes along way in helping put together a 3D context solutions. However there are differences that affect the core as Jerome calls it. Most significantly Size (and Colour). Size and Colours have to be handled differently depending on which system you use, and hence Initialisers / Actions will break if used with the wrong context. I know you want to keep the core renderer dependent and you can do that if an interface is defined that specifies how a renderer interacts with the core. However i think that you may have to change the callback mechanism. I would suggest something like

AbstractRenderer{

this.createParticle() //returns something for particle.target to point at, and replaces onParticleCreated

this.destroyParticle() //frees up the particle

this.setSize(particle,size)

this.setColour(particle,size)

}

I would like to thank you both for your great work, apart from one bug where my particles flicker annoyingly and intermittently that i have to tackle today, my star system is coming together nicely (not a single mesh used!). Please take a look:

http://www.nickfallon.net/3D/Sun_3x.html

[zz85]

added some support for type checking

https://github.com/zz85/sparks.js/compare/4eb759fd894943e9f13b4e4a5cc0313538690aeb...m2