Hi Stokers, here’s Stoke MX beta build #3.
(Attachments removed)
[size=150]Asynchronous Cache Improvements[/size]
The Memory Limit is now used to define the TOTAL memory to be used for both Memory Cache and Write Buffer.
Let’s discuss these a bit so things become a bit clearer.
Since Beta 2, Stoke uses a quite sophisticated caching system with the following components:
*Memory Cache - this was there in Beta 1, too, but it did not provide a size cap and did not integrate with the Disk Cache in any way.
*Disk Cache - this was also in Beta 1, but it was used more as a PRT saving option. It could not be used to repopulate the Memory Cache.
*Write Buffer (aka Serialize Queue). This is a dedicated memory buffer which is filled during simulation from the Memory Cache and is used to write PRTs to disk in a separate thread. In other words, it is decoupled from the main thread of Max/MAXScript/Stoke simulation and can run in the background for as long as it takes to save the PRTs.
In Beta 2, these were already in place and would interact as follows:
*When simulating, the particles on each frame would be written to the Memory Cache. If the Disk Cache was also checked, they would be sent to the Write Buffer for saving to PRTs.
*If the Memory Cache would get full, frames that are already cached on Disk could be unloaded to make room for more simulation data.
*If both Memory Cache and Write Buffer are full, the simulation would slow down and wait for memory to become available.
There were a few bugs in Beta 2 that have been fixed in Beta 3. The Memory Limit was not enforced correctly due to a MAXScript memory leak. The Write Buffer was set to 512MB and could not be changed. These have all been fixed in Beta 3:
*Ideally, during simulation without Disk Cache, ALL the memory specified by Memory Limit would be used for Memory Cache. If your particles are expected to use about 2GB of RAM, you could set the Memory Limit to 2048MB and all particles would end up in memory.
*When simulating with Disk Cache on though, the majority of the memory should be allocated to the Write Buffer, with the Memory Cache set to hold just a few frames before passing them on for saving. This way, the saving and simulation can run at maximum speed, and in the end of the simulation most of the data will be already on disk. As the saving continues in the background, the Write Buffer usage will go down until it reaches 0, and the Memory Cache will grow until it reaches the Memory Limit value. Scrubbing the time line will repopulate data from disk as needed, and if the Memory Limit is too low, frames will be dropped again to accommodate the current frame’s display.
*Even setting the Memory Limit to 0 will work reliably. When simulating, 1GB of memory will still be allocated for the two buffers, with the majority of the memory used for the Write Buffer, and only 128MB for the Memory Cache. Once the saving is done, both memory buffers will go down to 0 and scrubbing will constantly reload the current frame (or current two frames when Playback Interpolation is on) like the PRT Loader does. This is not recommended though.
*If you simulate without Disk Cache enabled and with too low Memory Limit, only the last few frames will remain in memory after the simulation (the rest will be dropped). That would be Your Fault though 
*If you simulated into Memory Cache only and all frames are in memory and you like the result, you can press the >Save Disk Cache button - you will be prompted whether you want to CLEAR the memory and use whatever data is on disk (if any), or FLUSH the memory to disk first, thus baking the data to PRTs that can be reloaded in the future.
*Of course, if you save a scene that was cached to disk, next time you launch Max and open the scene the cache will be repopulated like in Beta 2.
*If you have multiple cache versions, you can type in the version name in the respective field and the cache will be reset to point at that location. So you can quickly look at various simulations using the same Stoke object.
The Stoke UI will now show both the memory usage of the Memory Cache and the usage of the Write Buffer in a single line. In addition, a usage graph will display the memory status per frame. A single row contains 150 frames shown as vertical bars. Blue means the data exists on disk but not in memory. Green means the data is in Memory. Red means missing data (neither in Memory nor on Disk, e.g. when simulating with every Nth). Gray means no data (usually regions beyond the simulation range).
If there are more than 150 frames, more lines will be drawn in the same graph.
As you move the time slider after simulation, you will be able to see the green and blue lines loading/unloading data depending on the size of the Memory Limit.
If your simulation took a long time and saving is still going on in the background, but you don’t like the results of the frames that are already visible in the viewport, you can click on the [X] button and select the RESET option to stop the saving after the current PRT file. Selecting FLUSH will instead force the saving of all unsaved memory to disk and will lock up 3ds Max until the saving is done. In some cases, if both caches are too small for the data amount, it is possible that not all frames will be saved to disk initially. You might have to Flush the Memory Cache to force their saving.
Note that there are NO features in Stoke for DELETING the actual PRT files. It is up to you to clean up your cache folders, copy them to other locations etc.
The [X] button also provides an option to save the whole simulation to a different path using a new name. Note that this will NOT be done in the background and will, like flush, lock up 3ds Max until the saving is done.
[size=150]Other Features[/size]
- Picking a PFlow Source will now add ALL Events of that PFlow to the list. You can uncheck some to disable them, or remove them permanently. We feel this is a better approach than having two modes - whole PF Source / specific Events as in Frost. This works in both Distribution objects and Velocity Sources lists.
- A Viewport Display On switch has been added to quickly turn the particle display on and off in the viewports.
Just a note that if you are using Stoke with Krakatoa MX or Frost MX, you MUST download the latest builds from the Open Beta folders:
Krakatoa MX 2.1.8.50654 or higher:
thinkboxsoftware.com/krakato … ilds-beta/
Frost MX 1.3.5.50464 or higher:
thinkboxsoftware.com/frost-d … -releases/
The Krakatoa build provides a Stoke option in the sources list of checkbuttons, accepts Stoke particles as valid sources, supports Stoke objects in Particle Data Viewer and uses the same Float data format for time channels like Age and LifeSpan that Stoke uses.
The Frost build accepts Stoke as a valid source for direct meshing, so you don’t have to create an intermediate PRT Loader to mesh the simulation results.