Rhino for Windows
tone at July 19th, 2013 03:22 — #1
I came across a tutorial showing a method of dealing with pipe junctions and thought I would give it a try. When it came to blending the surfaces, despite selecting curvature, the results were mostly G1 (or at least an error that returns G1). Despite several attempts with varying results, I have failed to get G2. Is there a setting somewhere I am missing or am I misunderstanding the results?
absolute tolerance 0.001: relative tolerance 1% angle tolerance 1 degree. Rhino V5 64bit SR4.blend or what 2.3dm(381.4 KB)
pascal at July 19th, 2013 10:27 — #2
Hi Tone- make sure you check the surfaces (Zebra, with a very fine anlaysis mesh) not the edge curves.
tone at July 19th, 2013 11:27 — #3
I did check with the zebra stripes but it was seeing a test render that made me check the 'G' on the edge curves. The shadows in the render are wrong for something that is supposed to be smooth. It looks like there is a bump followed by a dip (G3 and G4 too). What's wrong with checking the edge curves?
pascal at July 19th, 2013 12:00 — #4
Hi Tone- nothing wrong exactly with checking edge curves, but it does not tell you anything about the surface continuity- it is perfectly possible and even common to have edges that meet at an angle when the surfaces are nice and G-whatever and vice-versa.
tone at July 19th, 2013 12:34 — #5
Yes, I understand that but I think in this particular case they should read G2 (the curves sit on the same plane). Anyway the shadows look visually wrong.
pascal at July 22nd, 2013 13:14 — #6
Hi Tone - Well, the the normal to the blended edge there is not, quite, in the plane of the long, straight adjacent edges, so there is no way for the blend surface edge curve, which pays no attention to the adjacent edges at all, only to being normal to the input edge by default, is going to be G2 to those edges, Does that make sense?
tone at July 23rd, 2013 14:54 — #7
I made an assumption that the axis of rotation for the straight section lay on the same plain as the axis of rotation for the blend. From what you are saying, there is no actual axis of rotation for the blend therefore the profile isn't necessarily true at the cutting plain (edge). As for the shadows (which started all this) I get the same effect in Lightwave which means, I suppose that renderers have problems dealing with shadows when straight and curved surfaces meet even though there relationship is G2. I don't usually come across this stuff much. Most of my modelling when I get around to it is walls and windows.
djnelson75 at July 23rd, 2013 16:34 — #8
Can't you use the sweep2 command with the Preserve first shape to keep G2 at the edge crv.
I would attach the file, but don't see anywhere on how to do it?
djnelson75 at July 23rd, 2013 22:43 — #9
@tone I also would have expected the same thing, that the edge curve blend would have been same continuity as the surface bend since the both edges are straight, lay on the same plane, and both pipe surfaces are have the same curvature. Still trying to wrap my brain around how they can't be.
djnelson75 at July 23rd, 2013 23:12 — #10
@pascal I think I understand your post now. If the blend edge of the pipe was straight, or perpendicular (normal) to the curvature of the pipe, then it would and it does create a G2 edge curve. Like this
But since the edge of the pipe surface has been trim across the surface (slightly) then the blend curve curvature isn't normal to edge curve. If that makes any sense.
So when you run the blendSrf command, like you said, it doesn't pay attention to adjacent curves, but if you put a G2 blend edge curve there and run the sweep2 command then you can achieve it.
pascal at July 23rd, 2013 23:36 — #11
Hi Dennis- that is what I was getting at, yes- you can achieve it but not (directly) because of anything BlendSrf is doing...
jimcarruthers at July 23rd, 2013 23:50 — #12
Of course what you're talking about with 'shadows' isn't actually shadows but highlight shading, "stuff that's facing the lights more directly is brighter." It's not really surprising since renderers are kinda designed to produce smooth-looking results from the extremely rough meshes, really 'exact' input might be more than it can actually represent. That's why we don't generally use renderings to check surface quality. Heck for all I know the 'incorrect' dark areas aren't even really there, it could just be an optical illusion caused by my brain looking for contrast, highlighting some infinitesimal rounding error difference.
brianj at July 24th, 2013 09:17 — #13
That happens to me all the time