I have a NURBS surface. How can I render an offset surface, with this surface as a base. I want an exact representation- I could approximate the offset as another NURBS, but I don’t like the idea. I want to just specify a normal direction and a thickness. Sample applications could be metal thickness or cutter offset for an N/C machine.
Marvin E Walden
When you say you want the exact surface I’m not quite sure what you mean? You say you don’t want to use another NURBs surface - why not? You can simply extrude the control points of the first surface, then use the edges of both patches to generate new patches to stitch everything together - taking care to flip normals as appropriate.
[This message has been edited by UncleBuck (edited 12-05-2000).]
The suggestion to create new control points might be a good approximation for small offset values. I observe however that it will create yet another NURBS surface.
Unless the NURBS surface happens to be mathematically equivalent to a pythagorean polynomial, an offset surface of a NURBS surface is not a nurbs surface- it is irrational. No NURBS surface exists which is mathematically equivalent to the offset of the original.
So, for example, an offset of a NURBS surface describing a sphere is certainly another sphere, and of course is a NURBS. But pick one which isn’t any kind of simple quadric or NURBS, for example. To calculate a point on the offset, you can:
It is the division by the magnitude of the normal which creates the irrationality. Algebraic geometry considerations can show that in general the resulting function cannot be piecewise rational polynomial. I note that NURBS surfaces are nothing more than a convenient way to represent piecewise rational polynomials.
These considerations are what lead me to hope that some api or extension of OGL can be made which give an offset rendering capability. As I observed, not much in the evaluator would need to be enhanced- I described the extension above. I also know that the rendering process might be more baroque, because if the offset value is greater than the minimum radius of curvature of the surface, the offset surface will cross itself, and strange looking results may appear, which I would accept if I were a responsible user.
Marvin E Walden
I used to just fix broken splines, but now I am a NURBalist! My friends tell me that I became more rational.
[This message has been edited by walden (edited 12-07-2000).]
[This message has been edited by walden (edited 12-10-2000).]
With the vertex program extension, one way to implement this would be to compute your vertex position as V + tN, where V is the original vertex position, N is the normal, and t is the thickness. t could either be a constant or it could be computed with another patch.
Thanx, to McC. That may be what I end up doing.
Further reservation I have is this:
My client already has his own wireframe display mechanisms, using old fashioned windows DC
techniques. Included in these are quite sound NURBS evaluators for curves, trimmed surfaces, and offset
surfaces. One advantage in going to OGL is shading, and one other main advantage for me is that for just
surface values all I need to do is define the surface, using gluNurbsSurface, and then tell OGL to go get it,
in a declarative fashion, sort of. To do the offset vertex by vertex, I have to write lots of procedural code,
and my client already has this. So much of the declarative value of OGL is lost for offset surfaces. I could
just as well write my own raytracing functions, and ignore OGL. What do you (or anyone) think about such
tradeoffs?
Actually, this all leads me to suspect that some group of users might profitably push for implementation of
offset surface capability on OGL. Perhaps even more, general “procedurally defined” surfaces (see
footnote). I recall that in a very old version of APT, a numerical control cutting system, circa 1970, there
was a feature where you could add your own surface evaluator. APT wasn’t even an object oriented system-
I don’t think object oriented concepts were well defined at the time. I, a man from yesterday, say that
certainly a generalized surfacing feature should not be difficult to add in today’s world. We don’t
necessarily need the full power of Fahrenheit. I also have some reservation about using Mesa and
modifying it, even though I have the skill, since then I have to support the modification, and my client is
not big enough to support it, either.
(footnote) I quail at the term “procedurally defined”, even though I was one of the first to use it. NURBS
things are “procedurally” defined. The order, cps, knots, stride, etc, themselves aren’t enough to be useful.
One needs an algorithm, a procedure- be it E.Lee, Cox- deBoor, or whatever. So, an evaluation of offsets is
just a little bit longer algorithm. I would allow that maybe there is a significant difference if I have to
evaluate an implicitly defined surface by iterative methods, where the procedure can’t tell in advance how
many cycles must be done before algorithm termination, or even whether the algorithm won’t ever
converge.
Marvin E Walden
You can still feed evaluators into vertex programs, so the GLU NURBS interface should still work, I think. At minimum, the GL evaluators interface should continue to work.
So it should be relatively simple to add a surface offset in.
Can you point me to an example?
Thanx,
///
Seeing as the extension in question is not shipping, no… 
You people have already taught me a lot. It seems that there were some concepts which I needed, and they weren’t exactly of the nature of how to program, or mathematics, but rather about the status of OGL and what I can expect from it. Thanx very very much.
///