I figured since this has happened to me more than a few times (on the rare occasion that I actually drag the spacing spinner instead of keying it in), it would be certainly be handy if one could do something to stop the PRT Volume from calculating the spacing size to restore functionality.
Max’s memory usage is currently 8.6 gig and stuck and single core pegged
Hell anything would be good, even a little popup to confirm dialog stating that I did something stupid (like going below 0.1) do I want to proceed!
Still at 8.6 gig and a pegged core, no change in mem allocation
Well that was strange, I killed the process and restarted, loaded the last Autobak (with the PRT Volume at that minuscule setting), the thread is no longer blocked and the scene actually loaded ! after only a about a minute and consumed nearly all of my phys memory 23 gig.
So maybe something else happening that blocked it.
If you were spinning the spinner, it is possible that it was getting to lower values than what ended up in the autobak. Each change of the spinner causes a rebuild of the level set and the particles, so it might have come to a point where an impossible memory request was made that no swapping could satisfy. In general, it is a better idea to use the subdivision / multiple particles per region to increase the particle count. Decreasing the spacing causes smaller voxels which requires a lot more memory. Note that subdivisions are by default not shown in viewport mode, and that the particle count is also limited in the viewport. So we have tried to prevent slowdowns of the previews by adding these limits. The viewport voxel size is determined automatically based on the bounding box size if you use the PRT Volume icon/menu item and there shouldn’t be a big reason to tweak it much - the render value is what matters in the end, but it does not affect the viewports anyway…
Of course, if the Esc. handling code from Frost could be added to PRT Volume, I would be all for it.
I did need a ridiculous low number and it really hadn’t occurred to try a semi-excessive subdivision instead, thanks for the tip.
I had just noticed that the other night and was ecstatic, if functions fantastically (at least so far) it makes fast iterating much less frustrating when I screw up the values. Great plugin, having a ton of fun/good luck with it. pWrapper was killing me, and meshing in realfow although it gives wonderful results it is slow to iterate.
PFlow could use this too soooo bad, esc handling has been hit and miss for a few versions now. If your quick it will escape if not you stare at the white-screen-of-pause-and-reflection, before overwhelming anxiety kicks in and you annihilate the process via taskman.
This is something I am curious about and would appreciate some assistance with.
Would you be willing to create a low and moderate (say, 10K and 100K) particles simulation in RealFlow and stop the meshing time for whatever the frame range is, then load the BIN file in Frost and try to get a similar result and benchmark that?
I would love to see some numbers
