Actually it works with surfaces.
The problems arises when you extrude the original curve as a solid. Then when you split off the end cap as a surface it’s already too late for the “long-part”.
You need to extrude the curve without making it solid. End caps have to be produced separately using Solid operations that are later on split into one joined end-cap.
Then the sub-object moving works fine. Nothing breaks.
I know, but look at the video again; I scale (instead of move) the center portion - that keeps the iso’s from messing up.
-Jakob
But you see the method I’m using in my video. It works as well, and it is much simpler in a way, because you do not need to trim stuff. You can more or less treat it as a pseudo-solid object.
Or maybe I just stumbled upon a happy version of the geometry that worked moving back and forth. Because now when I’m trying, it’s not working again.
Awful mess this.
It’s simply not a good idea to rely on methods that move edges and the like unless you are working with principally planar-surfaced objects.
i disagree, i would prefer Rhino helping rather than constraining the user with weird unresolved matters.
Would it work to split the object into left-middle-right sections (joined into a single polysurface) so that only the simple middle surfaces get affected by the moveedge commands?
EDIT: seems to work for me with several moveedge commands the isocurves remain clean
mullion problem 01 260430.3dm (5.7 MB)
In an ideal world, yes. I was simply stating a workflow based on the current state of affairs.
Uhh, how about one of those old-fashioned commands no-one mentions any more?
Good 'ol Stretch - applied to the middle of the mullion, nowhere near the ends:
May need a couple of helper lines and a quick calculation to get the distance right, but seems functional. If you don’t like all the control points Stretch adds you can explode the mullion, rebuild the longitudinal faces points 2 degree 1 in the lengthwise direction and then join everything back together.
Another, solid modelling 
, approach that could work if you do lots of these would be to have a long standard mullion profile to copy and a die for each end which you would place at the appropriate points and boolean subtract from the profile.
A third approach would be to use grasshopper to produce parametric mullions.
But what about the approach of McNeel fixing the bug instead?
I can elaborate exactly on how intolerably unnecessary and extra complicated all these workarounds are… I need not only to fix mullions… I have glass edges, putty edges, frame edges, inner casement edges and outer casement edges. All nicely solid geometry that can be used for many purposes, like material calculations.
And with MoveFace or MoveEdge all those “edges”
can be moved in one go. It takes 1 sec. If it
works, that is.
And yes, we have been battling these geometrical
Issues for a long time now. It must be possible to fix!
You’re assuming it’s a “bug”… that with some virtual screwdrivers and wrenches can be “fixed”.
As has been explained above, this is a limitation based on how the current NURBS surface geometry code is written. And it basically needs a heavy-duty re-write to extend that functionality to work on a larger group of geometry types.
well i had a brief look, and isolating the trouble maker it seems that this edge which is split at 1.5 mm in might be causing the faces to phase out of tolerance when pulled outwards, just a theory of course. if you merge the edge it then behaves. that of course is not a good solution.
i often ping pong faces around in that manner it does not happen very often that i see artefacts like this. still this kind of workflow is very convenient and even if the tool was initially never meant for it the modifications made clear that its an essential tool now and fixing it is probably pretty relevant.
No I did not assume it being a “simple” bug.
I rather assumed that it was a mathematical representation problem. I’ve been using Rhino since v3 and it has always been like this, but it has become a bit better. But never good enough.
There must a point when these things are rewritten so that they work 100%.
I’m all for it… it’s mainly a question of where it falls in the priority list and how much time/money it takes to “fix” it.
I’m continuing my odyssey into the weird geometries here (see enclosed file).
Both these are self-intersecting curves (they are copies of each other). Don’t ask me how they self-intersect. Maybe it is not important for what happens below.
Now explode the right one. And join it. Well … it becomes a closed not intersecting curve. Extrude it and it is solid. Sweep1 it and it is possible to Cap.
The poor left one - sweep 1 it along a line. It becomes an open surface. Cap does not work. Now use the same left curve and create a planar cap. It works fine. Add the cap to both ends. And Join it. I becomes a perfectly valid solid object.
Defies me. Can someone explain what is going on here?
/Erik
self-intersecting curves - what is going on 260504.3dm (5.5 MB)
Both curves select if you run SelSelfIntersectingCrv. If you run IntersectSelf on both curves, it will put a point where it considers them self-intersecting:
If you undo that and turn on control points, you will see that you have two stacked control points at that corner. How they got that way, I don’t know.
Exploding/rejoining them fixes that (probably some automatic correction routine)
ExtrudeCrv (solid=yes) seems picky about the self-intersections. If you extrude them the objects end up inside-out and make bad objects.
Gumball Extrusion does not do this (probabably also some automatic correction routine)
PlanarSrf also doesn’t seem to care.
Sweep1 is a surface operation and makes an open polysurface. It is considered valid (questionable) because the stacked control points have indeed caused a problem that prevents it from capping. Exploding and rejoining the surfaces from Sweep1 will allow it to cap afterwards.
Great to know IntersectSelf. Thanks.
Now the question arises … How can a curved have two points that coincide ? I understand that there can be two points on the same point in space. But can a curve go from 0,0,0 to 0,0,0 and still be a curve? Without any length?
Trying to do a crv starting and end at the same point is not possible.
Trying to move a point on a crv to another point at that curve is also impossible.
Projecting a 2 point curve (z differs) does not work either.
So a 0-length crv seems impossible. But it does not constitute a “BadObject”. This is a BUG. It should go under the “SelBadObjects” umbrella.
Something seems broken here. Tomorrow I’ll play around a bit with the mullion MoveFace/MoveEdge to see if removing that (hidden extra) point changes anything.
But, again, it seems to me that there is some kind of flaw in the geometric system, causing these errors. If you sweep1 a crv, then use the same crv to create endcaps and the join it to a solid object, it should be clear to the user what is going on. Doing hidden housekeeping removing parts of the geometry without telling is confusing at the least.
If it wasn’t for you I would never had found that extra point. I did not even think this was possible (well, and it might actually be impossible to create a 0-length curve in Rhino, waiting for instructions on how to do it) to create such an entity.
/Erik
It’s not a zero length curve. There is no zero length segment in your profile. What you have there is an open curve that should be closed. The “stacked” control points there are actually the start and end point of the curve. Normally they are “fused” into one point, but that failed somehow. If you set the display precision to max and select the two points and ask for details, you get this:
Point at (-1281.52982773,678.40225635,-15.00004378)
Point at (-1281.52982773,678.40225253,-15.00004378)
Notice the difference in the Y coordinates last three digits? (635 vs. 253)
How it got that way I don’t know. It’s definitely below the file tolerance so it should have closed. Any kind of manipulation like Explode/Join will actually close it. Even CloseCrv works.
It would be interesting to know how it came about, especially if it’s repeatable.
It is easy enough to recreate artificially. In the file below, run ProjectToCPlane or SetPt>Z to flatten the curve. It will be an open curve that looks closed. If you Explode/Join or CloseCrv, it will close. The end points are 0.0000001 apart after flattening.
OpenClosedCrv.3dm (2.7 MB)
Hello,
thanks for explaining.
It would be great in Rhino somehow informed the user about these quirks as they cause problems.
Or if the coding of these things changed.
I think the two points originated in a dwg-file. Is there a way to “make sure” that the content of a dwg-file is geometrically usable/correct for Rhino? So that these problems do not arise and go unnoticed?
/Erik
Well, there are obviously some spots like in my example above where the automatic detection/error correction for objects like this isn’t activated. That could be tuned up.
This stuff does happen relatively infrequently, though.
When you select the curves, Properties does tell you they are open. So if you see that and you think the curves should be closed, that is cause for checking the geometry right away.
I create a YouTrack issue, just in case…
