Hi Yenmonger - the booleans will probably have a hard time at the very tip where there are kind of many tiny fragments overlapping over top of each other.

What I would recommend would be to draw a small sphere at the top and bottom poles, then select your longitudinal sections and use boolean difference and subtract the 2 small spheres away from them.

This will prevent them from all intersecting in a confusing way at the top and bottom areas, and should allow for a cleaner boolean with the main body.

Those "pole spheres" don't have to be very large, just big enough to stop all those lines from running right over top of each other.

If that doesn't work or doesn't make sense, could you please post the .3dm model file of what you've got so far? It is always easier to make suggestions when the actual model file is available to work with.

- Michael

The polar approach helped with one set of lines, for sure...





But then I tried with the others, and got some more wackiness.

Hi Yenmonger, I'm sorry I'm not quite following along when looking at the model that you posted.

Was there an additional longitudinal section that you are using that was not included with the model you sent?

Check to see if the problem piece was still running into some of its neighbor sections at the top, if so you may need to make that top sphere "clear area" slightly larger.

- Michael

By the way when you do the latitude lines you'll probably run into a similar problem with the equator line, its edges happen to be very nearly flush with the longitude lines, those kinds of things where edges run very closely along each other can confuse things.

To make the equator latitude line work you should try using a just slightly larger square to sweep along that particular one.

- Michael

I also have this problem and am guilty of simply being to lazy to report it.... Now that someone else has thrown the first rock... I am happily joining.
Most of the time when I try to achieve something similar I have success when I preform a boolean diff 'one by one'. Selecting many objects at once leads almost in any situation to funny results.

Even when all is well, firing off a 'multi diff' is most likely to result in some sort of strangeness like parts are vanishing, or the inverse of what is expected happens. The wrong geometry vanishes and the unexpected results remain. Sometimes elements remain and have to be deleted manually to 'peel' the desired result out of the 'waste geometry'.

Once there is overlapping geometry all bet's are off. It is clear to me WHY but when it happens, based on the general lack of feedback by MoI3D, backtrackign to find the reason starts. A tiny overlap, almost within the numeric precision, is enough to ruin one's day. Again, a red flickering MoI button and/or a buzzer would be good enough to recognize that something fouled up. No need for a fully fledged exception handler with auto problem solving AI in the background (Homers Voice: Hmmmm AI......).
Lemo

Hi Lemo, the biggest problem is when you have an overlap that is not totally precise.

Like for example when you do a sweep, the geometry is the result of a fitting process. When you have a shape like that hugging along something another shape that is just very slightly different, it causes the pieces to kind of dip in and out from each other. It makes it hard for the boolean code to determine a clean intersection.

If you run into these, please send them to me, it is hard for me to make improvements without having examples to work with.

- Michael

Thinking outside the square?

You could, maybe, think in terms of a completely different approach.
Here is an example of one of the "EnhanceC" shaders, applied to a sphere, in Carrar6Pro.

Brian

And some showing off examples!
ps I should point out that the Enhance C shaders are a plugin set---they do not come with Carrara!

Hi Guys,
I used this approach starting with a segment of a sphere then circular array it,
worked quiet well, you could even do every second one with different panelling pitch.
Hope this helps.






Cheers

Definitely Danny's method is the way to go - that keeps things way more simplified for the booleans.

- Michael

Mr. Gibson - the 3DM file should contain everything necessary to recreate the problem. Note that I am using the beta V1, if that would make any difference.

Brian - those are really snazzy looking, but my needs are for a true 3D model for printing. Someday I hope to combine my modest designs with some really attractive shading/bumpmapping.

Danny - thanks, I'll give that a try as well.

Hi Yenmonger,

> Mr. Gibson - the 3DM file should contain everything necessary
> to recreate the problem. Note that I am using the beta V1, if
> that would make any difference.

Sorry - I had thought you were talking about another one of those vertical "longitude" pieces.

But I guess you are talking about the equator line one instead?

Yeah - that one is just barely grazing the vertical segments, it is difficult for the booleans to process intersections where surfaces kind of barely skim past each other.

If you scale that equator band either in or out by a slight amount, or use a larger sized square to sweep that particular one, it should create a slightly deeper or shallower groove which will more clearly push through the vertical surfaces instead of barely skimming along them. That kind of "clear push through" should allow the booleans to complete.

I did a quick test just now, and scaling that middle band from the origin by a scale factor of 1.01 seems to do the trick.

- Michael

I reported this kind of problem some time ago.


>>>Definitely Danny's method is the way to go

Well, that depends,.. if the user is happy with the segments then yes,.. but as when I reported the problem, I needed a single solid when finished, and trying to boolean union those segments is not always possible.

Hi Steve, you should always be able to get the segments into a solid - if boolean union gives you a problem you should be able to use Edit/Separate to break parts into their surfaces, delete any overlaps, and then use Edit/Join to glue the surfaces that have all touching edges into a solid.

Of course the segments need to be created precisely so that the pieces align well when you replicate them.

- Michael

Hi Steve,

> I needed a single solid when finished, and trying to boolean union those segments is not always possible.

Yes, that was a problem at first but then found that I could only boolean union 1 segment with the next then
when that was done I union that with the next segment and so on until I got a single solid piece. It wouldn't union in one go
if I picked all pieces, it gave MoI a brain strain ;)

Cheers

Hi Micheal,

>>if boolean union gives you a problem you should be able to use Edit/Separate to break parts into their surfaces

For a simple object as being put forward, then yes, but as at the time of my first report on this, the main problem came from the overlapping swept solids, I posted a very simple example to show you, and your reply was:-

>>The problem is with the surface/surface intersection part of the boolean,

so the first problem can be to actually get a segment with correct surface boolean, of course it can depend on the complexity.

Also:-

Surface booleans on a sphere may not be symmetrical, so splitting is not always an option.

Not all surface booleans are actually from a sphere.


- Steve

Hi Danny,

>>Yes, that was a problem at first but then found that I could only boolean union 1 segment with the next

I have looked at very many ways, but do find it "hit or miss",.. (sometimes it will/ sometimes it wont)


- Steve

Hi Steve,

> For a simple object as being put forward, then yes,

I was referring to this:

Any time you have a symmetrical segments like this, it should be possible to form them into a solid because you don't need to use boolean union to do this, you can have the segments be surfaces that have open edges and then use Join to form a solid.

That will be quite a lot more robust than boolean union because it will not attempt to find any surface/surface intersections between the pieces and will only attempt to join unattached edges together.

That should generally work to solidify any kind of symmetrical segments like this.


> but as at the time of my first report on this, the main problem came
> from the overlapping swept solids, I posted a very simple example to
> show you, and your reply was:-

Yes, correct - that was a situation with 2 surfaces crossing over each other and touching at a kind of crown point at the top.

That's a totally different situation than gluing segments like this into a solid.


> Not all surface booleans are actually from a sphere.

Certainly that's true - just to clarify, my comment was meant to be applied to the topic of this thread which is about booleaning things from a sphere.

If something does not have a kind of radial symmetry to it, then I would not recommend this method.

If it does have a radial symmetry, then I would recommend it, it cuts down on the lot of kind of crossing pieces that tend to be problematic, the smaller number of those the more likely that things will go smoothly.

I would not really worry about the final segment joining which you seemed to say was a potential problem - it you have any problem with boolean union there I would definitely think that Join can be used instead to solve that part.

- Michael

Hi Steve,

> I have looked at very many ways, but do find it "hit or miss",..
> (sometimes it will/ sometimes it wont)

If you have the situation where boolean union is not working and you have pieces that are touching each other edge-to-edge, then that is the situation where you can switch to Edit/Separate, discard the common pieces, and then use Edit/Join to glue together the pieces into a solid.

That method should not have any hit-or-miss about it. But the edges have to be matched up with each other for that way to work.

- Michael