It’s hard for me to formulate this into something that isn’t gonna sound confusing, so I’ll write the repro steps (also the image attached displays the issue)
Mirror Cube
create a cube
offset the cube from the center on the X
move the cubes’ origin to the center
add a mirror modifier (duplicate cube appears on the other side)
“APPLY” mirror modifier
Bridge Faces
Shift select top faces of both cubes
right click menu, select ‘Bridge Faces’
In the ‘Bridge Edge Loops’ popup, change the number of cuts to something like 5
BUT…
If you create a cube, duplicate a cube and then Bridge Faces, it works as expected. So I’m not sure what is going on with a mesh that has been created from a Mirror modifier. I checked that all the Normals were correct, and it appeared they were.
In Conclusion (refer to image attached)
What I expected, something that looks like an arch (A in the image)
What I got, something that looks twisted (B in the image)
If anyone has any ideas/answers, that would be appreciated
After some quick searches and youtube vids, the interpolation explanations are pretty straight forward. Which leaves me still wondering why a cube created from "Apply’-ing the Mirror Modifier doesn’t behave like a cube made from scratch or duplicated? I’m only fixated on this in case this is an issue with other modeling functions or modifiers.
Mirror modifier duplicates and transforms duplicate by doing a negative scale, then recalculate normals.
Everything seems fine.
But order of indices of generated faces are not the same according to technique used.
So what should the indices look like to have both “blend path” and “blend spaces” work on the cube that came from a mirror modifier? Both those interpolations work on cubes created normally or duplicated.
*turned on indices view for vertex. Also apologies for not understanding, i’m still fairly new to modeling.
Your screen capture is showing indices of vertices.
Easiest indices are edges indices (visible when edge selection is activated).
When you look at edges connected to face that will be selected for bridge, what is important is to order them from lowest index to highest one.
The progression of four indexes indicates a clockwise or anticlockwise rotation around the face.
When you duplicate, sense of rotation is the same for both selected faces of bridge.
When you do a scale -1 or a mirror, senses of rotation are opposite.
Here. If you look at progression of indices, Z pattern described is the same for 17,19,21,23 and 1,3,5,7.
But for 9,11,13,15, it is an S.
happened to be before , one time it work and the other time it didn’t,
a wild guess would be that mirror or all modifiers in general are not 100% accurate.
there is that one 0.000000001% off.
maybe
The indices order is not important here. The problem you have is sort of handmade, as your bridging produces/consists of coplanar faces. Try lowering the inner edges of the two open edge loops and the problem should be fixed.
Making a bridge from coplanar faces is a valid request.
Your solution, implying to change geometry, results in another shape than the one expected.
That is not a valid answer.
Piranha4d solution is satisfying, coplanar faces case, without modifying geometry.
My solution to just Sort Mesh Elements is also satisfying this case.
It would also be valid to abandon Bridge operators, but to use Spin tool instead.
The important is to obtain desired shape, not an approximated one.
Sheesh, its simply as @Format64 said, its just a nonintended behaviour of the operator and it seems that this bug is already queued to be sorted out. But to be clearer here for you, sure is it useful to be able to bridge coplanar edgedrings aswell. When I said its sort of handmade, I said that because its the specialcase of coplanarity, whats causing the numerical swap in the calculation. Not much to discuss about IMO.
And an infinitesimal change that holds up against the given floating point precision is meanwhile enough to solve it and should also have just an as minimal effect on the result. If you don’t find that suitable…fine, but to me its rather contextsensitive if its suitable or not. Strange comment.
Well, the case of the first .blend file is supported.
If you sort correctly mesh elements, loop pairs is giving a satisfying result.
The second .blend file has a selection too complicated.
It was never mentioned during operator creation that it would handle such case.
Any issue is context sensitive.
I did not want to sound aggressive.
But if you skip a condition enunciated (screen capture is part of question), it is cheating.
In fact, that kind of small change that user thinks imperceptible may be source of future problems of precisions.
Using an edge that you think perfectly aligned as custom transform orientation or snapping target, and you end-up elsewhere, with noticeable offset, without understanding why.
I meant the judgement about the usefulness of a workaround.
Yeah for sure.
If you have problems with the angle between the edgerings than simply correct that afterwards or simply stick with your solution. Phrases like “not valid” and “cheating”… , come on, really ? I even dont see, what additional criterias you’ve read into the screenshots yourself. He said he’s new to modeling and wanted a quick solution to stop the inversion. And you want to start a discussion about numerical stability.
Efficient quick and good habits have to be taught to people new to modelling.
That is not necessary to spread inefficient, slow and bad ones.
And the question was about finding a satisfying solution, but understanding an unexpected behaviour.
Knowing that duplicating cube could provide to correct shape, he already had a solution.
