Thanks Michael!

The Flow tool system has the potential to become a major design staple with MoI.
Especially in streamlining workflows to produce more complicated structures.
I've got a few things in mind for future projects already.

Mike

=Michael=

You may have some difficulty with using revolves in this particular way though because of the compression in UV space that happens as you near the pole area. Possibly the new "Projective" option in the next v3 beta would be easier to do that kind of thing that you're showing.

 

I can't wait next beta..so i'm working on a model by a complex pattern flowed on a revolved solid (i'll post soon..)
i got compression on the pole areas and i hope next beta can solve this distorsion

Magic..it's true..FLOW is slow when you use complex surfaces to flow (in my case i wait 4 minutes each pattern row but i got time to wait if the results are these ..!! )
hope will benefit multiple cores in the future

my hardware:
INTEL QUAD CORE 9450 overclocked 3.203 Mhz
8 Giga RAM
NVIDIA GTX 460 1Giga video mem
HD WD RAPTOR 10000 RPM
S.O. WINDOWS 7 PROFESSIONAL 64 bit

you see this is strong workstation

Hi Mauro,

> so i'm working on a model by a complex pattern flowed
> on a revolved solid (i'll post soon..)
> i got compression on the pole areas and i hope next beta
> can solve this distorsion

The surface-to-surface mapping Flow will just follow the structure of the target surface.

So if there is compression in the target surface's structure like there is with a default sphere then that causes compression of the pattern.

If you want to avoid that, you would need to work with a surface that does not compress its top or bottom areas to a single point which is what a default sphere surface will do.

Maybe you need to use a rounded surface dome that is constructed in a different way than a sphere, something like a sweep of a profile and a rail like this:





- Michael

Or if you have a pattern that repeats at certain intervals maybe you can trim out a small section the middle area of a sphere where it is not so highly compressed as at the poles and then repeat that around, something like the attached sphere.

Although that may not quite work right because each sector has some trimmed away area in the corners, and Flow will be working on the underlying full surface. But it depends on what kind of pattern you are trying to create.

- Michael

Thanks Michael for suggestions
almost tried many solutions,i think you cannot flow everything you want..at the end
i'll post it
check out this screenshot i made during flow operation
CPU's behavior : you see 4 cores but only one at 100% computation

Hi Mauro,

> Thanks Michael for suggestions
> almost tried many solutions,i think you cannot flow everything
> you want..at the end

Yeah not every design has a 2D element to it - if your pattern does not map well to a 2D pattern then Flow won't really be a help for that particular case.


> CPU's behavior : you see 4 cores but only one at 100% computation

Yes, that's normal behavior. It takes special and careful work to make an algorithm make use of multiple CPU cores, it is not something that happens automatically. Implementing a parallel version of Flow could be possible in the future at some point but for v3 the main focus is just on making Flow give a good result.

- Michael

Behold!




(This is a rough screen capture shown with a little Photoshop)

Here, I was able to wrap multiple surfaces trimmed with a pattern, around the revolved target surface.
The center was crudy as was expected, so I did a little work on it.

The total surface took about 25 minutes in calculation time with Flow. However, when I tried a solid version with some depth, I started last night and when I came home tonight, there was still no result.
Which leads me to believe that for every single surface or curve, Flow has to make a separate calculation, noting that the time seems exponential.
I can't fathom the workings of the logarithms behind Flow, but I imagine this to be so.

Since the resultant Flow were single layer surfaces I performed a simple extrusion on them to give them a little thickness.

I could have simply trimmed the hexagons from the target shape in one direction, but the point here was to be able to accomplish this result on surfaces oriented in many directions.

Now I'd like to build upon this object.

Not to ask a dumb question, but for geometry like the one shown, have you tried doing a small section and then making the rest of the model with a cirular array?

Hi Mike,

> Which leads me to believe that for every single surface or
> curve, Flow has to make a separate calculation,

Yup, that's correct - each surface or curve goes through a fitting process that reconstructs it.

On something like you're showing there where each little hole is not really deformed so much you could try something like use the "Rigid" option for Flow to just replicate a planar hexagon over all those areas and then use boolean difference and use all those planar hexagons as cutting objects.

The "rigid" option only takes a point at the bounding box center of the object and deforms only that point to determine where to move and rotate the object, so it positions the object along the target surface but does not actually deform it when that option is enabled.

- Michael

Yes MJS, Rotational array can produce beautiful results.

In this case I wanted to establish a method to use Flow to "wrap" a pattern of objects along a rotated of non-conventional surface.

Here's a good example: ... And I finally achieved a design effect on my wish list. :-)

This woven metal basket was made by flowing each strand to the bowl shape by referencing them off of a flat rotate shape with the same control point spacing:



The grid pattern maintains it's relative shape as it is translated across U and V.

The wire object used in each run was made from one single sweep of a circle.
A wavy curve was made for the sweep rail, repeated multiple times, joined and Rebuilt to form a "seamless" object - so that Flow would work quicker. As two surfaces of half length take twice as long as one of a single length.
The wire mesh here is ad-hoc and nothing really lines up like a mesh should, but the process worked well to show.


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.

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.

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?
But I'm not a programming expert, just a humble fan of MoI. ;-)

Great Magic !!

it's touching or pentrating between elements of the grid?

The wires of the grid in this model are most likely colliding everywhere. This was a rough layout.
I'd like to make a cleaner one later.

Each wire or sets of wire were Flowed on separate instances.

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

Thanks Michael,

Yes, I understand... and I hope you have increased success with V3's developments of course - we're there to test them out for ya. ;-)

At work I'm using Win7pro, 16 gig of DDR3 on an ASUS P8Z68 64bit system with an i7 - 4 core x2 with hyper-threading (8), and a GeFore GTX 560 Ti with 4 gig
ram. The HD is a WD Black, 7200rpm ??? A modest system where MoI kicks serious butt, even using one core. With Flow running, It barely registered. ;-)

My home system however... sigh... the newest part on it was made before 2004.
There's only 1 gig of ram on it... and three empty ram slots... hmm.

:-/ ...But I've made some killer MoI models on it, none the less.

Hi Mike, so I'm not quite following though - are you making that complex wire mesh thingy on your work computer or on your much older home computer?

- Michael

That was here at work...

...ick, I wonder it it would even work at home, I'll get spoiled if I'm not careful.

I'll have to try it later at home.

Hi Mike I see - I had just heard you mention your old machine before, and since the kind of thing you're showing there is going to consume a lot of memory it might require an upgrade on an old machine in order to not run out of memory too easily.

Possibly on your new machine it's not so much running out of memory that makes things exponentially slower when more pieces are selected - probably when you start selecting some of the shapes that are approaching the pole area of the revolved surface it could be possible that those ones are taking much longer to process because of trying to deal with the compression or expansion of 3D to UV space that occurs around those areas of the surface.

- Michael

I know, the machine at home nearly bogs down to a halt if I leave MoI running too long without a restart.
It's some kind of service, maybe for IE that shows a huge number of IO reads.

You said that the Beta version uses less or none of the IE implements. It is an independently running app now?

Yes, if anything is set near the poles, it does some nasty things. I made sure that the wire thingys were not on the line or in the center, so this thing turned out nice without any major glitches.

There's a nice cloverleaf pattern on the bottom as the "icing" was spread on the cake plate and adjoining table.



Well, all this is good for conforming objects to revolved things, but I cant wait to try out the projected flow.

Ahh... one thought about your projection flow option:
From what I could see on your examples, the objects, I think, maintain their width from the front to the back of the objects as it is conformed.
Or in other words, like the sides of an extrusion, for instance, maintain parallel angles.
If the surface has a sharper angle, the projected shape might look really warped.

Perhaps the shape of the object can conform to the surfaces normal, as they do when done with regular flow?
This example shows what I can't describe adequately...



So it would really look like you took a cookie from the cutter and carefully placed it on the target surface.
Just a thought.

Hi Mike,

> You said that the Beta version uses less or none of the IE
> implements. It is an independently running app now?

Yup, that's correct - the v3 beta version doesn't use any pieces of IE anymore.


> Perhaps the shape of the object can conform to the surfaces
> normal, as they do when done with regular flow?

Yup, there's an "Straight" option for projective mode - when Straight is unchecked, then the objects come off of the surface normal of the projected base surface which behaves like the current flow similar to surface offsetting. When Straight is checked, the objects come off only in one direction like an extrusion (and like the constrained direction idea that you mentioned back a while ago).

The previous examples I posted are actually all going off of the surface normal - but if the surface is not very curvy in that general area you won't see too much difference between these modes.

The projective mode won't work too well if the object being projected on to is curved too steeply in relation to the projection direction - it shouldn't approach too close to being 90 degrees away from the projection for example. It's more meant for beaming an object on sort of like a decal to a localized area of the object rather than wrapping across the entire surface.

- Michael