I’m really just now starting to dig into Stoke. I have a spline rig made in Naiad that I wrote out PRTs from, then I used Stoke to run lots more particles through the velocities. All good here, some particles end up getting 0 velocities because they move out of the velocities of the naiad written PRTs but not worried about that as I’ll just delete them in a PRT Loader later (although advice on avoiding that would be great – I think I can add the same PRT source and just use a more diffuse grid spacing to perhaps catch the particles). Problem is that once I’ve run Stoke (latest version, and latest StokeUI.ms) and I try to click the icon next to the “disc cache” to create a PRT Loader, Stoke crashes “local loaderObject = KrakatoaPRTLoader name:(uniquename (“PRTL_”+selection[1].name + “_”))”. If I create a PRT Loader manually and load the PRT files from Stoke, I only get every 4th frame visible or renderable.
The one parallel I see is that I set the Velocity Scale from the Velocity Field I am reading (the Naiad PRTs) to 0.25. But if I set the velocity scale to 0.5 I still get the same issue (every 4th frame). Looking at the PRT sequence, all frames are there but 3 out every 4 frames have a Stoke.####,#.prt instead of the Stoke.####.prt that every fourth prt file has. There’s a pattern to it as well, Stoke.####,8.prt, Stoke.####,6.prt, Stoke.####,4.prt, Stoke.####,2.prt, Stoke.####.prt.
Misc Info:
Cache nth: 1
Cache threads: 0
Simulating from 1 to 300
Sub Steps: 1
If I quickly rename the Stoke PRT sequence using Total Commander, all works fine. I can send you a file if you want to your e-mail.
Update: Change Stoke.####.#.prt to Stoke.####,#.prt in the above report as that was a mistake on my end.
It almost sounds like sub-frames are being saved, but nowhere in Stoke did we actually intend to do that.
The format ####,# is the standard format we went with for sub-frame sampling, for example in XMesh, but PRTs are not supposed to support that.
What are the FPS settings of the scene? Are you running Frames or SMTP/Ticks in the time line?
Anything related to the scene time settings that is out of the ordinary might be helpful…
Also, when you say that Stoke crashes when creating a PRT Loader, can you please also post the Error report from the Listener? It has never crashed for me in that line, but I have seen stranger things happen in MAXScript
Also, it does seem like some of my stuttering is coming from this issue once I rename the sequence. I’m going to try to see if this is a Naiad specific issue, the way it writes PRTs perhaps.
So I noticed that if I reevaluate the scripts, the bug goes away.
Also, if I reevaluate, sim at 24 fps, and then switch back to 30fps and sim, I also get a wrong output with decimal times.
Then I figured out that reevaluating StokeSimulator.ms fixes the problem, so I knew where it was.
Finally, I located it in this line:
-- We have moved the particle data through time to the next frame, so update it here.
simTime = simTime + 1f
Simply modifying it to
-- We have moved the particle data through time to the next frame, so update it here.
simTime += 1.0
fixes the problem.
Why? It looks like MAXScript is calculating internally what 1f means in term of Ticks at the time the script is evaluated. That gets stuck in the parser tree and when you switch the FrameRate, the value goes out of sync with the real TicksPerFrame value that represents 1 frame. Since Max defaults to 30 fps at boot time, when that script is loaded at Max start it gets initialized to the equivalent of 30 fps for the value of 1f (160 Ticks). When you load a Max file with 24 fps, the TicksPerFrame is 200, but the 1f in the script still remembers 160 unless you reevaluate the script. Thus, on each frame, it advances by 160 ticks instead of 200, and you get the wrong time stamps in the PRT files… Since this is off by 40 ticks, every 5 iterations you get a full 5160=800 ticks which is precisely 4200=800 ticks and a correct full frame!
But when you change it to 1.0, MAXScript has to do the time conversion at runtime because simTime is already a Time Value internally, but the 1.0 isn’t. So it is converted on the fly according to the current FrameRate and TicksPerFrame values. Which fixes the problem.
I fixed the crash you reported when creating a PRT Loader - it was happening in 2014 because you probably had Krakatoa installed after Stoke.
So when Stoke initialized its scripts, the KrakatoaPRTLoader and KrakatoaDeleteModifier scripted plugins were not defined yet, and the StokeUI.ms created local variables instead. I have now pre-declared these as global in StokeUI.ms, so the order of installation should not affect Stoke anymore.
