I’m doing a lot of tests with Ember and starting to get the hang of Magma to generate all kinds of predictable velocities which is awesome. Do you think there are going to be any general speed improvements or is this what we can expect in the final product? Using Pflow and EmberFollow or EmberForce is pretty slow. Not unusable, but definitely not as fast as I’d like it to be. I had a “duh” moment and decided to move my velocities into the initial state instead of sim and I saw a big increase in speed and I am now able to use it with FumeFX and get somewhat reasonable simulation times. Still not as fast as using regular Spacewarps but I am sure there’s a good reason for that? So as long as I don’t need my velocities to change on every frame I can stick with initial state which so far is very useful for me. I haven’t used Stoke in conjunction with Ember just yet but I was wondering about the speed issue. Even at a coarse grid I feel it’s somewhat slow. But if that’s the way it has to be, that’s the way it is and it doesn’t change my opinion about how awesome Ember is, it just means I’ll have to factor that in when using it.
There has been no speed optimization work done on Ember. In its current state it is brute force and probably as slow as it gets. It is more or less a prototype we wrote for last Siggraph.
There are several optimizations planned for Ember, including adaptive grid (don’t process voxels where there is no data!), and caching.
Stoke on the other hand already has an adaptive grid for particle velocities (in fact you don’t have to set a grid at all, it figures it out based on the velocity field sources’ bounding boxes). It demonstrates how fast things could be, at least in the case of splatting velocities on a grid and advecting by velocity.
Stoke also just added an asynchronous cache a few days ago (not released to Beta yet) which lets you simulate to memory AND write to disk in the background, so you can sim in 10 seconds and let Stoke save the resulting PRT data to disk in the following minutes via a background thread without affecting your interactive work. When you re-load the Max scene, Stoke will repopulate its memory cache from the the disk cache. The memory buffer size can be limited and if you run out of memory, it will start dropping data from previous frames and load data for the current frame. If you set the buffer to 0, it will only hold the current frame, but you can still drag and it will behave like a PRT Loader, constantly re-reading from disk as you scrub.
All this knowledge gathered from the Stoke development will certainly help improve the Ember experience in the future. Imagine if simulating in Ember once would cache the data in both memory and on disk and would allow you to scrub in real time back and forth. In other words, think of how both Stoke and FumeFX work…
Awesome, that makes me happy to hear. I got my twister FumeFX/Ember sim times down to 14 minutes per frame but that’s still a lot for a 6gb sim. Can’t wait until you’ve had a chance to optimize Ember. In fact, I can’t wait until you get back to releasing new builds of Ember 
. It’s my favorite tool right now.
Do you have an estimate of when you think another build will come out? Weeks or months?
It really depends on Stoke’s progress. We just posted a new build today and we have a few minor tweaks planned for it - direct picking of PFlow Sources, possibly direct emission from FumeFX, and sub-frame sampling.
After that, we should go back to active Ember development. I guess weeks is the right answer, but it is mostly in Darcy’s hands.
Ok, thank you. For me personally, Ember is the big deal so I can’t wait. I’ll admit that Stoke is a lot more useful than I initially thought when I frst started playing with it but Ember is just so awesome.