Circle intersect face *ugs

brookefox

FYI maybe some help?? http://forums.sketchucation.com/viewtopic.php?f=18&t=677

There is some info there, and it's appreciated, but not regarding this issue, which does not concern components and cutting out but rather proper intersecting of naked ungrouped geometry.

Thanks for the chime, Chris.

mac1

@brookefox said:

When circles are placed on a face through explosions of other entities (they themselves are not exploded), sometimes they intersect properly with the face on which they are coincident, often not.
This is the orginal OP and the "other entities" they them selves are not exploded imply you are dealing with components
SU behaves oddly with regard to them. If I try to explicitly intersect the entities so as to be able to delete an unwanted face of the circle, the operation fails to intersect but doesn't return an error msg. If I redraw the circle nearby and move to the same problem location, it usually results in the circle face being distinct as I want it, but if I copy/move it does not (the face is whole across the circle edges)!!!

I apologize for not explaining the images in detail but I thought it likely that experienced users are well familiar with this phenomenon. I'll get back if that is not the case.

Wo3Dan

Brooke, do you mean this issue (no proper intersecting) will occure even when placing the circle (or whatever shape) right in the middle of a face, not touching the face's perimeter? (I do understand the "explode" part of your explanation, to bring both shape and face in the same level (context).

Wo3Dan

brookefox

No, I don't recall it ever occurring on an initial, naked draw, if I understand you correctly; just when the circle is released there via an explosion.

Seems like intersect elsewhere is not foolproof either (where it should be - on perfect (coplanar), ungrouped stuff), but this may also have to do with entities previously bound up and released.

brookefox

@mac1 said:

@brookefox said:

When circles are placed on a face through explosions of other entities (they themselves are not exploded), sometimes they intersect properly with the face on which they are coincident, often not.
This is the orginal OP and the "other entities" they them selves are not exploded imply you are dealing with components

Not to me, though it could have been clearer. 'They themselves' refers to the circles themselves, and that they were not exploded.

Chris Fullmer

or via a pushpull that brings multiple circles up to intersect with a flat face.

Wo3Dan

Sorry for the misunderstanding. What I meant to say is that this issue is "(ab-)normal" and reproducible behaviour in SU when creating a second smaller coplanar shape on a larger face (inside its perimeter) where the smaller perimeter touches the larger perimeter with just one single endpoint. I can't recall this happening when the smaller face is coplanar inside the larger face and NOT touching the larger perimeter.

The issue occures with newly created smaller faces in the same context or by exploding a coplanar component, as long as both faces share only one endpoint.
Intersect will not divide the larger overlapping face. Z-fighting remains on the smaller face.
The remedy is to delete the larger overlapping face and next trace a single edge of one of both perimeters. Both faces are now divided, no overlap.

Wo3Dan

brookefox

@unknownuser said:

I can't recall this happening when the smaller face is coplanar inside the larger face and NOT touching the larger perimeter.
I'm still a little confused, but not significantly I think. In my cases there was no touching.

@unknownuser said:

The issue occures with newly created smaller faces in the same context or by exploding a coplanar component, as long as both faces share only one endpoint.
A circle (say 24 edges) inside a square face: they share 24 edges? or one curve? but seemingly more than one endpoint.

@unknownuser said:

The remedy is to delete the larger overlapping face and next trace a single edge of one of both perimeters.

Well, thanks, and I appreciate that, even if the scrooge in me can't help but re-characterize it as: when confronted with buggy behavior, delete and redraw until satisfied. I will try to remember.

Wo3Dan

@brookefox said:

@unknownuser said:

I can't recall this happeningwhen the smaller face is coplanar inside the larger face and NOT touching the larger perimeter.
I'm still a little confused, but not significantly I think. In my cases there was no touching.

That's what I was looking for. Perimeters/outlines not touching. I can't recall the issue here. But I'm not saying it didn't happen in your model.

@unknownuser said:

@unknownuser said:

The issue occures with newly created smaller faces in the same context or by exploding a coplanar component, as long as both faces share only one endpoint.
A circle (say 24 edges) inside a square face: they share 24 edges? or one curve? but seemingly more than one endpoint.

The perimeters/outlines might not share a single endpoint, even with coplanar faces on top of eachother. Result: no z-fighting.(at least for me, so far)
(One outline shared endpoint -> result: allways z-fighting (a definite bug))

@unknownuser said:

The remedyis .....

I'll refrase: a remedy is.......

I was just looking for clear reproducible situations for this bug to occure.
Thereby explaining one situation.

Wo3Dan

pyroluna

I get the same thing sometimes. Not only with circles. All kinds of shapes.
My solution is usually to draw a line over one of the edges of the shape that needs to be cut out.. this usually solves the problem. if it doesn't, I draw a line from one side to the other, crossing the new face. sometimes this does solve the problem, sometimes it doesn't...