>> I could be wrong about this, but I think Rhino uses NURBS, which POV
>> does not support, so it just exports them as triangles, so there isn't
>> anything you can do about this.
>You're right. But if you're REALLY set on getting a
>non-triangle output you might be able to write a converter
>from IGES to Pov-Ray bicubic_patch(es). It wouldn't work
>too well though because it would be a bicubic patch not a
It's going to be extremely difficult to get all of Rhino's NURBS
surfaces into bicubic patch objects..
While any NURBS surface can be broken down into a collection of
bezier surfaces, there are several obstacles that make it difficult
to do this between Rhino and POV.
One big problem is that POV only supports degree 3 ( "bicubic")
beziers. Rhino can have any degree surface. For degree 1 or 2
surfaces, there is an algorithm to raise the degree without
changing the geometric form, but there is no way to reduce
the degree of a surface and not change the geometry. It would
take a sophisticated adaptive cubic surface fitter to approximate a
high degree surface down with a cubic. That's not easy.
An even bigger problem is that Rhino not only uses NURBS surfaces -
it uses _trimmed_ NURBS surfaces. There isn't any way to trim a POV
bicubic patch in the normal way that a NURBS surface is trimmed -
with a NURBS curve that lies on the surface.
Those are really big obstacles that prevent a direct spline surface
export from Rhino to POV-Ray.
It would be possible to export untrimmed cubic NURBS surfaces to
bicubic patches, but that's only a subset of the kind of surfaces
that Rhino uses..
Also, even if you were able to get all of Rhino's surfaces into
bicubic patches, it might actually mean less quality of
rendering inside of POV, because POV internally will convert
those bicubic patches into meshes anyway, but I think it isn't as
careful in the mesh conversion as Rhino is, so you can end up with
little gaps and cracks in between adjacent surfaces, which
is a very common problem with spline patch stuff. Rhino carefully
meshes objects so that the meshes exactly match up between
adjacent surfaces that are joined together into a solid. So, the
quality will probably be better if you export to a mesh from
Rhino anyway instead of exporting to a spline patch when your
model is composed of many surfaces.
In the next beta version of Rhino, though, Rhino will directly export
a POV-Ray mesh object, so you won't have to go through any sort of
other conversion steps.
Also, when Rhino exports smooth_triangle objects to POV, it gets the
shading normals from the true NURBS surface instead of averaging
them between polygon face normals like a normal polygon converter has
to do. Using the true surface normals for shading really improves the
shading quality of the rendered mesh objects, so that's pretty cool.
The next Rhino beta release with direct POV mesh export should be
ready in a few weeks..
p.s. I really wish that POV had a binary compiled form, so that I could
export a binary file that could be directly read by POV. I think that
it's logical to split POV into two separate parts - a compiler that
takes POV Scene Description Language source code and compiles it into
a binary POV file, and then the renderer that just reads binary POV
files. That would save a huge amount of time when you need to render
large objects because POV wouldn't have to parse them and would
just be able to read in the binary information directly....
Robert McNeel & Associates