I’m trying to extract NURBS data from a Rhino file using openNURBS. My approach usually goes well, but I have run into a surface on which the trimming curves look slightly off. In fact, I have found that the problem seems to apply to all “revolved” surfaces. Investigating the data, I was surprised to find that the domain of the U and V seem to have been swapped!
To take a concrete example, let’s say I make a vertical line from (50,0,0) to (50,0,20). Using the Revolve command, I make a surface by setting the revolve axis to (0,0,0)-(0,0,20) with default angles. I now have a broad, uncapped cylinder.
When extracting NURBS data from this object, I would expect it to have a domain which is broad on one side, representing the 360 degree sweep of the revolve, and narrower on the other, presumably from 0 to 20, representing the height of the “cylinder”. Any trimming curves on the surface would therefore have their u,v coordinates in this domain.
When I extract the NURBS data from the surface in question, this is the domain I find:
u: 0.000000-20.000000, v: 0.000000-314.159265
So on the face of it this makes sense. 0-20 matches the height and 0-100pi the direction of revolution.
The problem becomes apparent when I trim the surface. Let’s say I make a closed polyline between these points:
(0,0,10), (0,0,15), (0,5,10)
This describes a triangle in the center of the cylinder. Then I use the Trim tool to cut the majority of the cylinder, leaving me with two curved triangles. For sake of simplicity, I’ll delete one of them. When I get the uv control points for the remaining surface, I get the following:
Trim 0:
Point 0: 0.000000, 235.619449, 0.000000
Point 1: 0.000000, 157.079633, 0.000000
Trim 1:
Point 0: 0.000000, 157.079633, 0.000000
Point 1: 0.106281, 157.079633, 0.000000
Point 2: 0.212562, 157.079633, 0.000000
Point 3: 0.318843, 157.079633, 0.000000
Trim 2:
Point 0: 0.318843, 157.079633, 0.000000
Point 1: 0.212205, 183.259570, 0.000000
Point 2: 0.106103, 209.439510, 0.000000
Point 3: 0.000000, 235.619449, 0.000000
Now, the triangle starts halfway up the surface and is a quarter of the height. If the U (0-20) domain is the vertical, we would expect the U-coordinates to range betwen 10 and 15. Similarly, if the V (0-314) domain is the revolved length, we would expect the V-coordinates to lie somewhere in the start of this interval, say 0-10.
These values do not. Instead it becomes apparent that 0-20 represents the width and 0-314.15926 the height!
For comparison, here’s an identical-looking surface made from an extruded circle, rather than a revolved line:
Object 0 (on Default):
BREP 0:
Domain: u: 0.000000-314.159265, v: 0.000000-20.000000
Loop 0:
Trim 0:
Point 0: 0.000000, 15.000000, 0.000000
Point 1: 0.000000, 10.000000, 0.000000
Trim 1:
Point 0: 0.000000, 10.000000, 0.000000
Point 1: 1.818104, 10.000000, 0.000000
Point 2: 3.636207, 10.000000, 0.000000
Point 3: 5.454311, 10.000000, 0.000000
Trim 2:
Point 0: 5.454311, 10.000000, 0.000000
Point 1: 3.656060, 11.674260, 0.000000
Point 2: 1.841413, 13.342146, 0.000000
Point 3: 0.000000, 15.000000, 0.000000
Much better!
Now, all of this is puzzling, but not necessarily wrong. These two representations could well be creating the same surface. The problem is that they don’t. Visualizing these NURBS in the our own program, I found that the odd revolve trims are ever so slightly off in relation to the triangle data (and the extruded version), which is the real problem.
It’s a little hard to describe and, of course, you’d be forgiven for thinking that we’re simply misinterpreting the data on our end. So I have made a Rhino file to illustrate the problem:
First I create a square from two corners: (0,0,0) - (20,314.15926)
Then I create a closed polyline from three points: (0.000000, 235.619449, 0.000000), (0.000000, 157.079633, 0.000000), (0.318843, 157.079633, 0.000000)
Then I create two cylindrical surfaces like in the previous example. One from a revolve and one from an extrude.
Finally, I apply the curves to the surfaces using _ApplyCrv.
The result shows the problem I’m talking about. The triangle is slightly narrower on the revolve feature:
(Screenshot from Rhino)
I would have expected these curves to give rise to the same shape on the surface when mapped onto it as UV-values. Bizarrely, they do not. This would seem to indicate that there is some special case with revolve features that our own program is not taking into account.
So in short, my questions are:
Why is the domain of a revolve feature shifted in this way?
Am I doing anything wrong in retrieving the trim data? Can the process be improved?
Could it instead be the way we display NURBS data in our program that is at fault? Are we falling into some common trap, perhaps?
Thanks in advance,
- Sean
I have attached the following files:
“revolveTest.cc” - a very simple test file showing how I retrieve the above data with openNURBS.
“revolvesurf.3dm” - A file containing two triangles produced as above. Running the revolveTest program with this file as argument produces the data shown above.
revolveTrims.rar (15.4 KB)