>>If this makes sense--to the question!

It all relates to the size/placement of the shape.
(AND--using the, say, flat setting in the sweep options)


Thanks B,
This is similar to mine and I'm having some issues with a boolean at the end. :o

Hi Danny,

> <...> you can force the sweep say in the axis direction (z direction)
> and this will control the twisting nature of the profile, is that
> something that can be implemented into MoI ?

Yes - if I understand you correctly you can get what you want with the Twist: Flat option.

The default Twist: Freeform does a kind of gradual rotation around the curve tangent, it is more suitable for a more arbitrary path swooping around all over the place.

Twist: Flat will only perform rotations of the profile around the world z axis, which keeps the profile more stabilized with respect to that direction.

Here's an example from the help file:

Given a profile and a path for the sweep:



The Twist: Freeform option will produce this:



while the Twist:Flat option will produce this:




Freeform is the default because it handles more arbitrary curves going in any direction - the flat option does not behave well on paths with curve tangents that go close to that same z axis direction, only rotating around z results in a degenerate situation when the curve tangent is also pointing in that same direction.

- Michael

Hi Michael,

I discovered what I was doing wrong, I just realised that the 'flat' option only works the way it should when the axis of the thread/spring is along the z axis, so if I do the same thing with the axis on the y direction you get funny twists, I guess if I want to orientate the sweep say along the y axis then I would have to set up the cplane to make the axis, z then reset the cplane later.

What about, when you pick the flat option, x y z tick boxes appear so you can pick what direction it will force the sweep, because we don't always model something like this in the z axis ?


---------

Burr

The SIZE is very important! (End of quote)
And, see a new thread I posted, Boolean can take time--maybe a full bottle of Coopers Stout!

What a drag!

Brian

Is this thought applicble?
(Back in my fitting and turning days, 1948!)

One gets the lathe (sweep) going before the lathe cutting tool gets to the object?

Brian

Hi Danny - re: Twist Flat option - yup having some more control over the "flat direction" is on my todo list to tune up with a batch of sweep stuff, I hope to get about a week working on improving sweep stuff later on in v2.

- Michael

< That's how I did that, Curve>sweep (circle)>Array>Boolean but if I tried to Boolean all the Array at once MoI would fail, then found that it could Boolean 3 or 4 of the arrayed sweeps at a time.
Is that what you mean ?

No :)
More than like that (here an "helix": Array Circular with vertical step, Array Dir)
Boolean>Array>Array etc...
So just one boolean inside the first component ;)
The only difficulty is find the first component ;)
After it's very speedy and no problem of boolean!

I know what he means. On a very heavy model, tried to boolean union everything at once. No Go! But I did 3 or 4 at a time 15 times and acheived the union. I think at some point the union operation starts going around in circles and wont produce a result. (at least reasonably)

Yeah, that problem of a larger number not working all at once seems to be triggered when many of the non-intersecting pieces happen to be processed with each other first in the calculation, before getting to pieces that actually cut through one another.

I have a good example of it and I have spent some time working on it before but have not yet tracked down exactly what goes wrong.

When you do it in smaller batches it tends to be more likely to combine intersecting parts earlier in the process which seems to avoid the problem.

This kind of thing tends to happen particularly with union - with difference because you pick the objects in 2 batches with a base object and then other ones that are all intersecting it, that does not happen to run across the problem.

- Michael

Maybe the fix would be to force the union to be a two part pick also? As opposed to grab all and try to combine like join. Seems logical.

Hi Burr, hopefully I can just get it fixed up to work properly rather than changing the UI to work around a bug...

- Michael

I suppose thats why I'm who I am and your who you are! :)

Hi Pilou,

>> No :)...........So just one boolean insode the first component ;)

Yeah, I thought about that, then ended up going the direction I did to get the knurled look, maybe I should of thought about it a bit more, so I've started another thread about this called 'knurling'.

Cheers
~Danny~

Re: Boolean union problem with large batches

Actually I had a pretty simple idea on how to tune up boolean union to help avoid this problem, it looks like it should solve it pretty well. I just sort the group of objects by bounding box diagonal size so that the largest one gets processed first. That will tend to make combinations that intersect each other and avoid the problem area that happens when trying to combine many non-intersecting pieces first during part of the Union calculation.

It looks pretty promising so far, looks like it could solve most of those group boolean union issues even before real bug in there is fixed up.

So there should be an improvement to this batch boolean union processing for the next beta.

- Michael

<I just sort the group of objects
Yes but when there are some many group of objects?

Does that go for Boolean Diff as well Michael ?

---------

Hi Pilou,

> Yes but when there are some many group of objects?

It is meant to sort a large group of objects - it will fix up the situation where you have one single large "main" object and you are trying to union a bunch of smaller ones on to it.

It does not fix every situation, but it should make the most common one (large + many small) work much better.

- Michael

Hi Danny,

> Does that go for Boolean Diff as well Michael ?

No - since boolean difference has you pick the "base object" as a separate stage it doesn't really run into this same problem.

Have you run into similar situations where boolean difference is not working with a large batch and it does work doing things in smaller groups? If so I could use an example of that, I don't think that is as common as with Union.

- Michael

Hi Michael,

> Have you run into similar situations where boolean difference is not working with a large batch and it does work doing things in smaller groups?

Well, I did, but trying to reproduce it come out with positive results, funny that, it was when I was modelling the knurl on that thumb screw that I have a close up of in this thread, but I can't remember which version of MoI I did it in, was there any changes to the Booleans between the betas ? It was when doing the the crossing booleans that were intersecting the previous boolean that it failed, but then tried 3 or 4 at a time then it would work, it must of been just that situation, maybe it was a full moon that night ;) , so for now don't worry, I'll let you know when it happens again.

Cheers

Hi Danny,

> but I can't remember which version of MoI I did it in, was there any
> changes to the Booleans between the betas ?

There was for the Aug-4 one, but not for the last Sep-21 one.

I'm not surprised that different arrangements or sequences of that kind of "crossing at crown point" situation would get different results, but that is a different problem than the union one that I was talking about.

I had a couple of examples of Union failing with batches even when there was not any additional difficult intersection situations like that, this new tuneup for Union helps to reduce that. It won't do anything to fix the difficult intersection type situations.

Of course it is nice to have progress of any sort! :)

- Michael