I'm now starting to play around with V3 Beta's Flow command, and I tested a theory today:

- Flowing objects on a revolved surface.

Yes, usually when you think of flowing objects onto a revolved surface like a cylinder or sphere, you take the objects you want to flow and place them on a simple rectangle as the reference surface.
The result is as expected - it starts the objects at the seam line and sweeps them around like a record (axially) until it reaches the line again.

But the flow command works by matching points in the reference surface's "grid structure" to that, by percentage of the target's.
With that being said, why not consider matching a reference surface THAT IS ALREADY IN THE FORM OF THE TARGET?

Consider a simple revolved profile: You simply start off with a revolve profile made from a free-form spline.
Not just considering the control points, but how much distance is in between each control point or relative control point on the surface or curve.
- Considering the resultant U/W layout if everything was "unwrapped"

Now draw another line for the reference revolve profile, but straight and making each control point spaced out to represent the true distance along the target's profile curve.
Distance horizontally is considered, but remember if the curve moves downward or at an angle or in an arc - there is a distance there too.
Represent these distances in the spacing between control points along the reference profile.



Note: Ensure that the directions and orientations of the revolves and control profiles are in the same directions so that the Flow command will match them as you desire.
Also: Your flat profile curve for the reference revolve has to have a few of it's control points slightly offset from the straight line, or MoI will generate a planar surface with no swept control points.

Now Revolve each profile, using the same orientation. You have a revolve with a nice shape of your liking, and one that is relatively flat.
Take the flat-like reference revolve in a side view and make it "Flat" using the handle bars. It will now be perfectly flat, but retain the knots and surface information.


Now work the Flow command with the original objects on the surface or relatively spaced to the reference surface.
Since each corner of the swept surface's control cages will line up, the original objects will be translated to the characteristic shape of the target surface.




Notice how these objects are NOT sweeping in a rotational manner on the target surface!

Issues:
In this beta edition there is a problem with the flow result curves and surfaces "rippling" as the distance increases relative to some point of origin.
This is an issue that I think Michael said he was working on for the next beta release. I tried the telephone chord spiral along a path thing and got the same strange ripple that increase in severity more to one end.
You must also consider that the Flow command does not have supernatural powers and will flow well over seams, tight bends and the degenerated center point on a revolve as shown above.
But it will get you in the ball park.

Also - Flow is sloooooooooow.... eesh. My goal was to make a speaker grill with well placed holes and other detail, as such would be done if a metal sheet of grill metal was stamped into a shape.
I gave up after it sat for two hours and nothing happened... I'll take it to work and try on the faster PC.
BTW, Michael, I thought it was cute when my brother was looking at the Task Manager's Performance graphs on the work PC - while I was working with MoI, and asked me why only one of the cores was the only one working.... Well, someday. ;-)

From what we can learn from my experiment is that there may be some power in considering the original reference surface with the Flow command as well as the target.

Hi Mike, yup you can actually use any surface as the base surface - it doesn't have to be a plane although mapping from a plane as the base tends to be the most simple one.

But the way Flow works is every point that is evaluated on the base object is dropped to the closest point on the surface. That then gives a UV location and an offset distance - then that same UV and offset distance is evaluated on the target surface.

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. Also as a side note, when the new "Projective" option is enabled there will also be a "Straight" option that will do the kind of shaping that you had asked about a while ago where the shaping is constrained in one direction. It turned out to be a good fit with that option since in that mode there is a particular direction set up for projection already which could be used without any extra picking required. When that option is set the result of the projection will expand like an extrusion rather than like an offset.


> In this beta edition there is a problem with the flow result curves and
> surfaces "rippling" as the distance increases relative to some point of origin.
> This is an issue that I think Michael said he was working on for the next beta release.
> I tried the telephone chord spiral along a path thing and got the same strange
> ripple that increase in severity more to one end.

Are you talking about using base curve to target curve flow here? There is a bug right now where curve to curve flow (meaning using curve backbones rather than surface backbones) doesn't work properly unless both curves are flat in the world X/Y plane. If the curves are in some other orientation like standing up vertically you'll get that weird rippling effect. I've been working on fixing that just recently here and almost have it tracked down.

But for now lay both your base curve and target curve down in the world x/y plane and it should behave better.


> Also - Flow is sloooooooooow.... eesh. My goal was to make a speaker grill
> with well placed holes and other detail, as such would be done if a metal
> sheet of grill metal was stamped into a shape.

Yeah basically every single surface and edge in the model is reconstructed with a new refitted version, and it goes in and refines each of those rebuilt surfaces until it is within a good tolerance.

If you have a complex model with a whole lot of little surface pieces in it it may take a while to crunch through it all.

You can reduce the amount of time taken by reducing the number of surfaces in the model that you are deforming.


> BTW, Michael, I thought it was cute when my brother was looking at the
> Task Manager's Performance graphs on the work PC - while I was working
> with MoI, and asked me why only one of the cores was the only one
> working.... Well, someday. ;-)

Unfortunately things that are coded in the most straightforward manner only work with one core - it takes a considerable amount of special work and special attention to make an algorithm work well with multiple cores, it doesn't just happen on its own.

Flow could be a good candidate for using multiple cores in the future at some point though. In the current v3 time frame I'm much more focused on just getting it to generate a good result.

- Michael

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