# What am I supposed to do with the progress bar data in the Cloth Room?

• When I run a cloth simulation, the progress bar dutifully tells me how long it took to simulate the last frame right down to the MEELLIONTH of a second*. Well, OK, but what am I suppose to do with that? I guess if I sat there and stared at the bar through the whole simulation it might tell me something, but I don't know what. It might tell me that some frames take much longer to simulate than others, but even then, what am I supposed to do with that information?

(*) I think the last three digits are always either 000 or 001, so maybe it's just timing it to the THOUSANDTH of a second, not that that would have any more significance to me. A tenth of a second, maybe.

• @ElZagna I'm not sure what your problem is? Why do you have to do anything with it? What do you do with the progress bar info from downloads or render times, etc. Do that, then.

• @eclark1849 Every other progress bar I can think of tells me, at a minimum, the percent completion of the task even if it's only a rough estimate. Some, like Poser's render progress bar, tell you also what stage of the process you are in. I appreciate the difficulty in doing that with cloth simulations because the time required for each frame may vary significantly, so about all it can do is tell you what frame it's on and how long the last one took. Maybe that's all there is to it. But a millionth of a second?

What might be helpful would be some kind of log that tracked the time for each frame. That way if the sim had problems you might be able to look at the log and see where it started to break down. I say "might" because I really don't know what you could do with that information, anyway.

• I don't know why it calculates sown to such a tiny amount but knowing that frame 7 suddenly takes 20 times longer than any of the other frames, can indicate a problem with the pose at that frame. Once a cloth starts its collisions, it usually is relatively consistent in duration for each frame, only varying a small percent. If it suddenly increases drastically, and you haven't given it more things to collide with, there's a good indication there's a problem with the simulation, such as a hand passing through the body.

• I kinda agree with him. There's no benefit in showing elapsed times with too much precision; after the 1st decimal or so in seconds the rest is noise.

SM should use the space on screen to add a second field, something like "Duration: xx.x sec, x:xx:xx remaining"

To be honest I'd probably agree with Mr Lasagna if he argued the opposite too; you see, I'm biases in favor of Italian food. I love pasta! Just hope it's a meat one -- these vegetarian Lasagnas taste of nothing :(

• @fbs7 Well, yeah, but you want metaballs too, so your opinion means nothing. Nothing, I say! :)

• Hey, I changed my mind on metaballs. I wrote my own script and made it public, and I'm satisfied with it - plus I got better with Python too in the process. Now, it's true that a native implementation would be 100-500x faster, but as they say, if Moses doesn't go to the mountain.. then Fbs will go!