Stoke looks a lot like Ember, but without the field editing. Is is going to be a subset of Ember or is it going to provide distinct functionality?
- Chad
Stoke MX provides the particle reflowing component we planned to add to Ember anyway. But then we realized that if we took some core technologies from Krakatoa and Ember, we could create an entry level product that is as easy to use as Frost and would expose artists to Ember workflows without the steep learning curve. It would be easy to operate for someone who already owns Krakatoa, FumeFX and related products, but could not wrap his head around Ember flows. Our experience with Frost shows that a product that solves a particular problem really well (and fast) and is easy to use literally sells itself without marketing efforts. So that’s our target audience.
We took some particle generation capabilities from PRT Volume, added PRT Loader-like but memory-cached playback with retiming, cubic interpolation and display options, took some of the Ember advecting code and created something you can operate with just a few clicks. At the same time, you can plug it in within the pipeline to use all PRT objects to create dynamic particle clouds, apply Magma modifiers to its stack, render its particles in Krakatoa 2.1.7 and higher, mesh its particles with Frost (new Frost build coming soon), and save the particles as PRTs for all the obvious reasons. So if you want any of the advanced capabilities of Ember, you can always pick the SIM Ember grid as velocity field source and run with it - in fact we prototyped most of what Stoke does using that approach. But for 90% of the everyday needs, Stoke should be able to produce the desired results with less effort.
Stoke development is also enhancing our other products - Krakatoa got the PRT Surface object as a side effect of Stoke development, and we just finished refactoring the time channels to use Float Seconds for Age and LifeSpan instead of Ticks; Ember is getting a new node to produce velocity fields from any particle system without using Radius sampling and so on. We hope to inherit some other technologies from it, for example the memory caching and playback of particles could be very useful in the Krakatoa PRT Loaders.
Last but not least, with Krakatoa MY about to be released next week, we need some of this technology over in Maya to produce the particle counts Krakatoa needs to be successful. So don’t be surprised if a Stoke MY comes along later…
Stoke provides a foundation for more particle system tools in the future - our PRT streams can now be simulated, our code is multi-threaded, and we have the basic birth and integration covered. We have node-based channel editing, what is missing is Event or Rule-based logic to affect particles and move them between containers. You can extrapolate the future possibilities from there… 
So to answer your specific question, Stoke started as a sub-set of Ember, became a distinct entry-level product that shares core technologies with Ember and Krakatoa, and might be part of the Ember package when Ember is released (but this is not clear yet).
to pull back the curtain - ember is a larger-scale product which, by it’s nature, will take longer to complete. we had a lot of requests for the particle reflow concept within ember, so I ordered the troops to design a tool that solves that problem [as well as others] we can get out to market faster, and hopefully generate some revenue on. the idea is that rather than educate people why they need a system like ember, we can convince them by giving them something that does useful things earlier.
cb