Hi Mike, cool use of Flow!

That is definitely getting to a very high level of surface complexity though so it will be normal to expect for a lot of number crunching to happen for that kind of a thing.


> Michael, I noticed that after selecting more than a dozen or so surfaces to
> Flow, the flow time was not incremental but seemed exponential.
> ...Or even as if it was stuck.

There isn't anything in particular about Flow that would cause it to be exponential - but as you select more objects you are probably using up more memory and when you hit the point of running out of all physical available memory the virtual memory system of Windows will kick in and start swapping chunks of memory out to your hard disk to free up more space. Unfortunately your hard disk is several orders of magnitude slower than RAM is so once that happens there can be a severe slowdown.

If that's what's happening to you then you might try adjusting the display mesh density to be coarser, as described here:
http://moi3d.com/forum/index.php?webtag=MOI&msg=4196.2

A coarser display mesh setting can help a lot to reduce memory consumption on high detailed models.

Also if you're going to be making really complex results like this you'll be best off on a high horsepower machine - a 64-bit machine with at least 4GB of RAM will help to make more memory available for MoI to use.


> May I suggest placing a simple curves counter on the script to tell you
> how far along it is? Such as: "Object: 23 of 400"
> It could also be divided into the time spent to estimate a "remaining" time.

Right now I don't have any general mechanism set up for doing that, but that could be a good improvement in the future.


> Also, you did talk about the intricacies of using multiple processor cores - for
> future thought, could the total objects to flow be simply divided up and batched
> into separately spawned running instances of the Flow command script?

The problem with that is it wouldn't give any improvement for the case where you're deforming one big solid, since that is just one object that gets input into the command.

In order to give an improvement for that kind of a case, the threading needs to be handled more internally to the command where different edges and surfaces are separated out into a work item queue which then is processed by a pool of threads. However, a high degree of care must be taken when dealing with multiple threads to make sure that the different threads are not tromping over the same memory structures when they access them simultaneously. It tends to be a particularly delicate and error-prone type of programming so stuff involving multi-threading is just generally time consuming and difficult work.

- Michael