LOL as simple as that huh BurrMan, That'll teach me to apply logic, my thinking was that they would need to be merged from the same view to help with normals orientation... Never trust a garden designer to design a tyre :¬)

Many Thanks

Martin Spencer-Ford

Hi Martin,
Well, thats not something that would/should be obvious! I think Michael plans on tuning this up to not have to be in that flat plane direction to work. It was just a limitation of the first, original implementation of the new flow command... Should get better in the next couple releases as these types of things arise...

(The normals are read from the surfaces, not the viewport. A better way to understand it)

Good luck.

Hi Martin & Burr - so with a surface-to-surface flow the particular orientation of the objects does not really matter (whether they're on the world "Front" plane or on the world "Top" plane or whatever) - the one that you're thinking of Burr was a problem in the first v3 beta with curve-to-curve flow (curve backbone to a different curve backbone rather than surface backbone to surface backbone), but that should be fixed now.

However, with surface-to-surface flow the spot that you click on each surface is significant, so you will get weird results if you do not pay close attention to making sure you click on corresponding parts of the base surface and the target surface - it will rotate your shape to match to the spots that you click on and if you don't click carefully you can introduce improper rotation.

Check out here for a description on the pick areas:
http://moi3d.com/forum/index.php?webtag=MOI&msg=4795.10
http://moi3d.com/forum/index.php?webtag=MOI&msg=4442.24

This should get better when there is a proper help entry for Flow.

- Michael

OIC. I suppose my rearranging the position of the surfaces thinking of the old issue, just caused a natural "selection point" on the surfaces that worked. I do understand the placement of the pick in relation to the surfaces, which I thought was a very powerful addition! Thanks for clarifying.

Thanks for the help guys - It's done and dusted for this part of testing. Next time round i will try and go higher with the detailing, fillet the tread and side-wall onjects, but or now this is good. Next I suppose i should try and see what Blender and cycles can do with it.

TpwUK

Hi TpwUK, wow it looks really great!

- Michael

Bravo!
Cool result of this "Made in France" ;)

Evidence of efficiency with MOI - Over 300 objects in the tyre model being joined up as a boolean solid, the cpu and the ram are not over stressed despite the slow process of calculating ..

TpwUK

Actually Martin, MoI only makes use of all cores during meshing when exporting one of the poly formats, all other calculations use only one core, the task manager is showing it's using 25% of your total processing power, you have four cores so really one core is at 100%.

~Danny~

Ewww - Yugh several expletives and all that other stuff. That's gonna be a bummer with the Bulldozer chips then it has 2 mins left to complete this task before i hit cancel button - Very nearly an hour and it's still calculating.

TpwUK

Hi TpwUK, if you're going to be producing a rendering as the final output, you don't really need to actually boolean union all the little bits together into a single solid, it's ok for rendering purposes to have them as separate solids that just happen to be sticking through each other.

- Michael

I have gotten up to all kinds of tricks with rendering in order to save computing time and to speed things up Michael, and i still do. This was just to try the stability of version 3 beta, it was stable, but i quit the boolean process after 1hr and 20 mins on a quad core @ 3.2Ghz and 8gb. Any chancr you can tweak the code to be multi-threaded when needed. All the best and thanks for producing a wonderfully intuitive app!

Martin

Hi Martin, I do want to add more multi-threading to MoI in the future but it's a very complex task to manage multiple threads well, and it tends to be easier to implement for things where the stuff that is being calculated is totally separate from each other.

When you are doing a boolean you are often combining things into a single object, and so that aspect involving combination is pretty much the opposite of isolated calculation.

There are probably some aspects that could be calculated in isolation from each other, but just in general it is quite difficult to restructure existing code to be multi-threading friendly, and multithreaded code is notorious for being easy to create all sorts of timing related synchronization bugs, so it has to be approached very carefully, it's not something that you just slap together quickly.

I do want to add it to some particular targeted areas, and in version 2 I did do that for the polygon mesh export, but it's a difficult and time consuming process.

- Michael

I totally understand and appreciate the complexities of multi-threading, I have several attempts and failures with that and Delphi (Showing my age again) ...

Martin