> Regarding your proposed patch - if it is fast, that would be nice.  POV
> currently subdivides bicubic patches.  It has an option to subdivide only
> as needed (practically 'direct rendering') but this is much slower than
> pre-computed subdivision.  If you have a technique that is fast, that
> would be great.
>

I should mention that I will be trying to implement code written by Sean Graves
in 1990, so I really wouldn't be writing anything original.  It uses the
newtonian method, which I hear is pretty fast but can have problems with
returning wrong intersections.  If I can get it to work, then I may be able to
improve it by including bezier clipping and bounding volume heirarchy.  This is
my first attempt at an actually useful patch, so I don't know yet if it's
beyond my abilities.

The main impulse for doing this is that I find the u and v steps annoying in
the current implementation.  No matter what the screen resolution, POV-Ray will
always use the same number of subdivisions.  The results are not only slow, but
rather jagged around the edges with some of the scenes that I've tried
rendering with large numbers of bicubic patches.  It seemed to me that to alter
the code to tesselate down to a pixel in size would make rendering unbearable.

The photon patch has also been a factor as to why I'd like to do this.  Even if
you could subdivide to pixel size, you would have to do it twice for photons,
and how would you know how small to dice the geometry for those?  Hmm...

> The recursive definition for NURBS is a bit more complicated than the
> definition for bezier surfaces, which makes subdivision computation a
> bit more costly.  I've been told that there are efficient ways to do
> the subdivision, but I have not investigated the matter closely.
>

The code I'm basing this on seems to use a basis matrix for rendering different
types of curved surfaces, one of which is bspline.  My understanding is that it
is possible to redefine any NURBS surface as a piecewise bspline surface using
knot insertion.  That should make it possible to render them using this code.

> The really slow NURBS code that I wrote (just to see if it could be done)
> is simply a parser front-end to the triangle mesh object.  In other words,
> if you make a NURBS surface with what I did, it is a mesh object
> internally.  If you want the code, let me know where to email it to.
>

Yeah, it would be great if you could send it to pov### [at] aolcom.  One of my
biggest problems is that I can understand a lot of theory, but I'm clueless
without code examples.

Even if it turns out to be so incredibly slow that no one would want to use it,
I still think it would be a nice thing to have just as an example.  It gets
asked about often enough.

-Mike

Post a reply to this message