Hello!

I'd like to create models for PovRay, which could not be easily done
with PovRay primitives and CSG. I have version of Rhino and it's seems
to be best tool for such task. Only problem is, that Rhino models could
be used as meshes in PovRay and they tend to be quite large. So I
thought that it would be good, if PovRay could render NURBS directly,
without meshing.  McNeel provides IO toolkit, so there is possibility to
export NURBS in suitable format.
Is it possible to add NURBS support and how big effort it would be? I've
compiled bezier patch from Daniel Skarda and it seems pretty good for
start - it implements rational trimmed Bezier surfaces. Does anyone
knows, how to force PovRay to recognize NURBS?  Rhino documentation
recommends "The Nurbs Book (Monographs in Visual Communications)" by Les
A. Piegl, Wayne Tiller. Does anybody have this book and does it contains
enough information about NURBS math to implement their support in
PovRay?  If it does, then I consider to purchase this book and attempt
to patch PovRay. Or is there some other sources, suitable for this task
or is someone already working on this?

Sorry, if my ideas don't make sense, I am not firm in field of curves
and surfaces, but if I take this challenge, then things will change
(hopefully).

Post a reply to this message

ahur Krouverk wrote in message <358148A8.A516C2F7@fv.aetec.ee>...
>Sorry, if my ideas don't make sense, I am not firm in field of curves
>and surfaces, but if I take this challenge, then things will change
>(hopefully).


I am no math-wizard either and the task you are heading for would be too
much for me.

But giving POV-Ray the ability to trace NURBS as primitives (probably even
in CSGs???) would make it stand out among the competition even more than it
already does. A great to-hope-for feature! Go for it!

Johannes.

Post a reply to this message

NURBS stands for Non-Uniform Rational Bezier Splines, right?  How are
these different from the implementation of splines provided with
Skarda's patch?

Forgive me if it's a silly question...I've just been wondering this for
a while.

- Jamis Buck
  buc### [at] csbyuedu
  http://students.cs.byu.edu/~buck

Vahur Krouverk wrote:
> 
> Hello!
> 
> I'd like to create models for PovRay, which could not be easily done
> with PovRay primitives and CSG. I have version of Rhino and it's seems
> to be best tool for such task. Only problem is, that Rhino models could
> be used as meshes in PovRay and they tend to be quite large. So I
> thought that it would be good, if PovRay could render NURBS directly,
> without meshing.  McNeel provides IO toolkit, so there is possibility to
> export NURBS in suitable format.
> Is it possible to add NURBS support and how big effort it would be? I've
> compiled bezier patch from Daniel Skarda and it seems pretty good for
> start - it implements rational trimmed Bezier surfaces. Does anyone
> knows, how to force PovRay to recognize NURBS?  Rhino documentation
> recommends "The Nurbs Book (Monographs in Visual Communications)" by Les
> A. Piegl, Wayne Tiller. Does anybody have this book and does it contains
> enough information about NURBS math to implement their support in
> PovRay?  If it does, then I consider to purchase this book and attempt
> to patch PovRay. Or is there some other sources, suitable for this task
> or is someone already working on this?
> 
> Sorry, if my ideas don't make sense, I am not firm in field of curves
> and surfaces, but if I take this challenge, then things will change
> (hopefully).

Post a reply to this message

Jamis Buck wrote:
> 
> NURBS stands for Non-Uniform Rational Bezier Splines, right?  How are
> these different from the implementation of splines provided with
> Skarda's patch?

It is NonUniform Rational B-Spline, a somewhat different critter.  The
advantage and problem lie largely in the "nonuniform" part.  Advantage
because it improves accuracy and allows you e.g. to represent an
accurate circular shape, which Bezier splines simply cannot do, and
gives you generally more flexibilith and fluidity because the "knots"
are not necessarily uniformly spaced.  The drawback is that this same
nonuniformity prevents the simple matrix representation used for Bezier,
Catmull-Rom etc. splines and requires a more sophisticated (probably
slower, harder to code) method of calculating surface points.  See Foley
and vanDam for more info.  This is a very limited "close enough for
government work" once-over-lightly, but it should convey the idea.

Jerry Anning
cle### [at] dholcom

Post a reply to this message

Johannes Hubert wrote:
> But giving POV-Ray the ability to trace NURBS as primitives (probably even
> in CSGs???) would make it stand out among the competition even more than it
> already does. A great to-hope-for feature! Go for it!

NURBS are nothing without a good modeler.  It would be fairly easy to modify
the current Bezier code to handle simple NURBS surfaces... or at least
non-trimmed NURBS.  Trimmed NURBS are quite difficult, IMHO.  It all boils down
to tesselating the surface into an internal triangle representation.

However, modelers can already do the tesselation easily.  I've been working on
a compact mesh syntax with Thomas Baier for 3DS-to-POV conversions that would
also work to greatly reduce the size of any triangle mesh POV file.

-Nathan Kopp

Post a reply to this message

Nathan Kopp wrote in message <35817EBF.B5331009@ltu.edu>...
>Johannes Hubert wrote:
>> But giving POV-Ray the ability to trace NURBS as primitives (probably
even
>> in CSGs???) would make it stand out among the competition even more than
it
>> already does. A great to-hope-for feature! Go for it!
>
>NURBS are nothing without a good modeler.  It would be fairly easy to
modify
>the current Bezier code to handle simple NURBS surfaces... or at least
>non-trimmed NURBS.  Trimmed NURBS are quite difficult, IMHO.  It all boils
down
>to tesselating the surface into an internal triangle representation.
>
>However, modelers can already do the tesselation easily.  I've been working
on
>a compact mesh syntax with Thomas Baier for 3DS-to-POV conversions that
would
>also work to greatly reduce the size of any triangle mesh POV file.


I agree that you would need a modeler. I wasn't thinking to program NURBS
without one (yuk!). I was more thinking along the lines, that the mesh-files
exported by modeleres like Rhino are often huge. Exporting a direct NURBS
description in some POV-Ray format where NURBS would be a primitive-type,
would cut down this size immensely.
Like you wrote: The modelers to the tesselation, and the result is often
huge. The idea is to keep the file-size small and let POV-Ray do the
tesselation.
And then again (and here my math-incompetence shines through :-) - why
tesselate at all? Couldn't POV-Ray use the direct mathematical functions for
intersection tests?
As I understand it, spheres for example are not tesselated internally, but
instead intersected directly. Would something like this be possible for
NURBS too?

Johannes.

Post a reply to this message

Jerry Anning wrote:

> See Foley
> and vanDam for more info.  This is a very limited "close enough for
> government work" once-over-lightly, but it should convey the idea.

I have this "brick" from Foley and van Dam and currently I'm trying to get
to basics of curves and surfaces. But does anybody know references for
implementation model?

Post a reply to this message

Nathan Kopp wrote:

> NURBS are nothing without a good modeler.

Rhino? It will be available soon.  If there is easier way to integrate it with
PovRay than meshes, then I consider of purchasing it, but I don't want spend money,
if  I have to fiddle with huge file sizes.

> It would be fairly easy to modify
> the current Bezier code to handle simple NURBS surfaces... or at least
> non-trimmed NURBS.  Trimmed NURBS are quite difficult, IMHO.  It all boils down
> to tesselating the surface into an internal triangle representation.

> However, modelers can already do the tesselation easily.  I've been working on
> a compact mesh syntax with Thomas Baier for 3DS-to-POV conversions that would
> also work to greatly reduce the size of any triangle mesh POV file.

Can You explain Your work? What do You mean by "reduce the size of any triangle
mesh file"? I've tried by myself patching PovRay to be able to read binary mesh
files (my custom format, where textual representation was replaced with direct
binary representation of float numbers). This drop parsing time for my scene from
80 to 30 second and files were smaller as well (by 40 % if I remember correctly).

May-be it's easier to use converter instead of patching PovRay. I don't know, how
long it will take to patch Povray, for as I said, I'm not expert in this field. And
I don't know, whether it will produce better outcome (parsing time will be
supposedly smaller, but if rendering time goes high, then it is useless).

P.S. May-be it would be better, if there is some repository of PovRay patch (and
utility) ideas and if someone works with something, then he makes entry to this
repository, so people will know, what's going on.

Post a reply to this message

> And then again (and here my math-incompetence shines through :-) - why
> tesselate at all? Couldn't POV-Ray use the direct mathematical functions for
> intersection tests?
> As I understand it, spheres for example are not tesselated internally, but
> instead intersected directly. Would something like this be possible for
> NURBS too?
> 
> Johannes.

Possibly. Not knowing much about NURBS mathematically, I couldn't say
for sure, but doing this tends to be computationally prohibitive - you
can tesselate enough that you can't tell the difference and still be a
hell of alot faster than direct intersection tests, in many cases. This
is presumably why POV uses a tesselated form for the current bezier
patches.

Michael Smith

Post a reply to this message

I don't think trimmed NURBS would be a priority anyway.  My understanding is that
Max's original implimentation of NURBS didn't include trimmed surfaces or curves.
Trimmed NURBS are considered bad news anyway, as they are not as easy to texture or
deform, and so I tend to avoid using them in Rhino.  They can be excluded by
planning ahead a bit.

Something that has recently got my attention, however, is that there is a new beta
of hash animation master that is able to import dxf files and create patches from
them.  The problem with it is that they create 3 point patches, which crinkle and
create holes badly.  How hard would it be to convert a triangle mesh into a
polyface mesh with 4 point polygons and then use the vertex info to create bezier
patches?   Provided that the number of points were reduced and evenly distributed,
perhaps that could be something easier manage than NURBS.

-Mike

Nathan Kopp wrote:

> NURBS are nothing without a good modeler.  It would be fairly easy to modify
> the current Bezier code to handle simple NURBS surfaces... or at least
> non-trimmed NURBS.  Trimmed NURBS are quite difficult, IMHO.  It all boils down
> to tesselating the surface into an internal triangle representation.
>
> However, modelers can already do the tesselation easily.  I've been working on
> a compact mesh syntax with Thomas Baier for 3DS-to-POV conversions that would
> also work to greatly reduce the size of any triangle mesh POV file.
>
> -Nathan Kopp

Post a reply to this message