Full Version: Troubles with solids

Show messages: All  1-3  4-9

re:
> went back to the original model (joined surface with naked edges)) and tried a boolean
> union with a solid (IMHO nonsense) and guess what happened?
> I have got a a perfect solid object (despite the naked edges)....

You can sometimes get lucky with non manifold geometry if you got these pieces connecting together:



And not like this:



Also if if for containment analysis if it doesn't happen to fire a test ray very nearby the non manifold area it may not trigger any problem at that moment.

But this type of self-intersecting shapes can behave unpredictably.

- Michael

Image Attachments:
non_manifold_join1.png  non_manifold_join2.png 

---

Hi Michael,

thank you for you answer, explanation and suggestion.

But I am still curios:
I am designing the model, adding details, checking if the solid is "healthy".
In one step, adding a detail the solid is "broken" to a joined surface... despite the operation does NOT affect the areas which are now marked as naked edges.
And separating the joined surfaces and re-joining them creates a solid again(!) - which is not "healthy" anymore (i can identify it only by a next boolean operation which fails, and the stl exported from that solid cause the slicer is crashing) So it means there is something wrong with faces... Is there a way how to identify it and prevent such situation?

Is there an the explanation why in some cases the "boolean Union" end up as Boolean Difference? , and the similar object with same geometry (being a joined surface) in boolean union with solid ends up as a healthy solid (allowing subsequent operations)?

I don't want to bother you and waste your time, if my questions are obsolete and I am alone asking such things, just leave them... :-) . I will take more care at design...

---

Hi Michael,

Reading through this thread, particularly the notion of "Healthy" objects prompts a thought:

First, is it reasonable to think in terms of MOI having a hierarchy of object types ranging in complexity from, say, the lowly point up to solids? If so, would it be reasonable (possible) for MOI to warn when an operation produces object(s) whose "type" is lower in the hierarchy than they were when the operation commenced? Maybe this would only be appropriate for operations like the Booleans & others that are dealing with the more complex types. My thought being that clearly MOI knows the object type(s) before and after an operation, and the ability to warn users that types have degraded, thus prompting the user to pause before forging ahead with another operation. Perhaps an option in moi.ini "warn on type degredation"?

This probably belongs in the V5 wish list, but this thread provides the context.

--Larry

---

Hi jki,

re:
> In one step, adding a detail the solid is "broken" to a joined surface... despite the operation does NOT
> affect the areas which are now marked as naked edges.

Non-manifold or self intersecting geometry can affect operations on other areas of the model too. Particularly mechanisms that involve traversing connected faces.


> So it means there is something wrong with faces... Is there a way how to identify it and prevent such situation?

Is this on the same model that you posted above? Because like I wrote above, the thing that is wrong there is having places where 4 surfaces are touching at a single edge making a non-manifold structure.


> Is there an the explanation why in some cases the "boolean Union" end up as Boolean Difference?

One of the things that non-manifold/self-intersections can mess up is the algorithm that identifies which side of a closed skin is the outside.

If it ends up classifying the wrong side as the outside it can invert which pieces are kept and discarded in booleans.

- Michael

---

Hi Larry,

re:
> If so, would it be reasonable (possible) for MOI to warn when an operation produces object(s) whose
> "type" is lower in the hierarchy than they were when the operation commenced?

It would be hard to do this for everything because there are some functions (Edit > Separate, Trim) where their job is specifically to produce a "lower" result.

It could be good for booleans though.

The complication is that there is not an established UI mechanism for reporting a command specific error.

I have some ideas on making a command "epilogue" dialog that could work for that, I hope to be able to experiment with it in v6.

Thanks,
- Michael

---

Thanks Michael,

Sounds like this would make a good wish-list item combined with your command "epilogue" dialog to check for degraded object types from certain ops like the booleans.

--Larry

---

Show messages: All  1-3  4-9