All I have to say is I paid $200 for Hash animation Master and wrote a plugin
for it that can export POV-Ray bicubic patches.  Simple and easy. :)

One thing I've noticed is that NURBS appears to have been a fad.  They can
accurately represent some objects that bezier patches cannot, yet from an
artistic point of view there is no real advantage.  The latest thing is
subdivsion surfaces;  NURBS are yesterday's news (if you buy into that malarchy)

-Mike

Post a reply to this message

>   What are the advantages of NURBS (or should I say NURBSes?) over
>  bicubic pathces?

Wha....? I thought bicubic patches *were* a specific subset of NURBs?
General NURB support, therefore, would be more flexible, by doing
anything a patch can do but being more adaptable? Wouldn't it? Okay,
If I'm wrong, blame it on being tired. I shouldn't be allowed near
a keyboard when I'm tired. 

As to the matter of smaller file size... yeah, guess so, although I'd
be more concerned with render-time memory savings than stored file
sizes. Bezier patches, if I remember rightly, have (or at least had?)
an option to choose between patch types that preprocessed to triangles
or on-the-fly control point calculations. This traded off memory size
for computation speed depending on your needs. I imagine if 
generalized NURBs were implemented, it would have similar options. 
Nowadays, with faster processors, computations speed would probably
be less of a concern than available memory with huge models. Could 
be nice in that case.


Charles
-- 
http://www.enter.net/~cfusner
"...Then darkness took me, and I strayed out of thought and time,
 and I wandered far on roads that I will not tell..." 
                              -The Two Towers, JRR Tolkien

Post a reply to this message

> Wha....? I thought bicubic patches *were* a specific subset of NURBs?
> General NURB support, therefore, would be more flexible, by doing

Sorry, I just want to clear up one thing. NURBS is not plural for NURB.
NURBS is the acronym for Non-Uniform Rational B-Spline. The correct
pluralization is NURBSs, no matter how ulgy it sounds.

--
Anthony L. Bennett
http://welcome.to/TonyB

Non nova, sed nove.

Post a reply to this message

Felix Petriconi <fel### [at] ruhr-uni-bochumde> wrote:
: (I know that there is
: a utility by Chris Colefax which reduces the number of triangles.)

  If you are talking about the triangle mesh compressor, two points:
  1) It doesn't reduce the number of triangles, it just stores them in a
more compact format.
  2) The macro by Chris just reads the compressed data into povray (and
creates the mesh), it doesn't generate it.

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

Vahur Krouverk <vah### [at] fvaetecee> wrote:
: Seems like this subject will be good candidate for
: FAQ (or VFAQ, how about it, Warp?).

  I can add it if someone gives me a question and an answer (which should be
comprehensive and correct).

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

Well, it depends what you're doing.

The main advantage I find in using NURBSs is adaptive generation and
degradation of the final rendered mesh and also vastly more modelling
methods compared to patches.  A good example of the AG/D of NURBSs is when
using really complex models.  If you render the model based on mesh patches
you could end up with a massive amount of triangles.  With NURBS models you
can simply set the restraint angles and distances so it adaptively generates
the surface.

The other thing as I mentioned was the flexibility of modelling.  For
example with NURBSs it's very easy to just trim up and blend two surfaces
together seemlessly.

This issue has come up a few times in regard to POV-Ray and it seems there
is the same problem.  POV-Ray isn't a modeller, and modellers are needed to
make NURBS surfaces.  Making up the keyword description for POV-Ray would be
near impossible considering the number of specialised surface triming and
blend functions along with all the point and CV splines.  I personally have
no idea how it would be possible to make a tokinised description for NURBSs.

Someone also mentioned subdivision surfaces.  This has become an offshoot of
NURBS modelling and uses a method called "soft selections" (the term changes
from modeller to modeller).  Basically it works the same way only it allows
you to add weights to all NURBS points (even if it's a CV spline).  While
NURBSs already support this, subdivision surfaces do it differently because
they work on existing models (they "subdivide" <- thus the name; the
surface).

Anyway, I think I said this the last time the NURBS issue came up:  NURBSs
would be near impossible to impliment into POV-Ray and considering the
computational and programming overheads, it really isn't worth it.

Anyway, back to work, just thought I'd stop in.

--
Lance.


---
For the latest 3D Studio MAX plug-ins, images and much more, go to:
The Zone - http://come.to/the.zone
For a totally different experience, visit my Chroma Key Website:
Colorblind - http://listen.to/colorblind
Nieminen Juha wrote in message <37c3e249@news.povray.org>...
>  What are the advantages of NURBS (or should I say NURBSes?) over bicubic
>pathces?
>
>--
>main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
>):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

Nieminen Juha wrote:
> 
> Felix Petriconi <fel### [at] ruhr-uni-bochumde> wrote:
> : (I know that there is
> : a utility by Chris Colefax which reduces the number of triangles.)
> 
>   If you are talking about the triangle mesh compressor, two points:
>   1) It doesn't reduce the number of triangles, it just stores them in a
> more compact format.
>   2) The macro by Chris just reads the compressed data into povray (and
> creates the mesh), it doesn't generate it.

It should also be noted that the mesh compressor utility while reducing
file sizes also has a minor disadvantage of increasing parsing times and
adds a bit of overhead to the memory usage of the program. I have not found
it considerable enough to worry about yet but with extremely large mesh
files this extra burden could exceed your memory capabilities.

-- 
Ken Tyler

See my 850+ Povray and 3D Rendering and Raytracing Links at:
http://home.pacbell.net/tylereng/index.html

Post a reply to this message

Lance Birch wrote:
> 
> Well, it depends what you're doing.
> 
> This issue has come up a few times in regard to POV-Ray and it seems there
> is the same problem.  POV-Ray isn't a modeller, and modellers are needed to
> make NURBS surfaces.  

The same could be said about bicubic patches, and all we need is tools
to generate them (SPatch, Moray,...).  Same apply for NURBS.  If they
get implemented, they will work as patches work : subdivided into smooth
triangles before the rendering.

>Making up the keyword description for POV-Ray would be
> near impossible considering the number of specialised surface triming and
> blend functions along with all the point and CV splines.  I personally have
> no idea how it would be possible to make a tokinised description for NURBSs.

The Renderman specifications include NURBS.  RIB files are just text
files,
so it's perfectly possible to have such an implementation in Pov.  BMRT
is
also a-renderer-not-a-modeler and uses NURBS (and much probably
subdivides
them into small triangles before rendering).

Fabien.

Post a reply to this message

>The same could be said about bicubic patches, and all we need is tools
>to generate them (SPatch, Moray,...).  Same apply for NURBS.  If they

Good point actually... but NURBS are much more complex.  I don't see a
problem in normal surface generation but if you want to impliment full point
and CV spline -> surface generation things could get tricky.

>The Renderman specifications include NURBS.  RIB files are just text
>files,

It's also a rather large renderer :)  It's not impossible, just a lot of
work.  If someone is willing to work out the spacial and/or
normalised-tension surface generation, by all means :)  I just thought that
maybe the POV-Team might wish to work on media or something like that at the
moment rather than trying to impliment NURBS which would be a rather large
thing to do.

Some interesting ideas though, maybe similar specifications to RIB could be
used in the parsing of NURBSs (the keywords that is).

--
Lance.


---
For the latest 3D Studio MAX plug-ins, images and much more, go to:
The Zone - http://come.to/the.zone
For a totally different experience, visit my Chroma Key Website:
Colorblind - http://listen.to/colorblind

Post a reply to this message

> Some interesting ideas though, maybe similar specifications to RIB could be
> used in the parsing of NURBSs (the keywords that is).

Parsing shouldn't be a problem.  The hard part is figuring out how to render the
surface.  This is the example given in the Renderman Interface Specification:

RIB BINDING

        NuPatch nu uorder uknot umin umax nv vorder vknot vmin vmax
parameterlist

EXAMPLE

        NuPatch 9 3 [ 0 0 0 1 1 2 2 3 3 4 4 4 ] 0 4
        2 2 [ 0 0 1 1 ] 0 1
        "Pw" [   1  0  0 1  1  1  0 1  0  2  0 2
                -1  1  0 1 -1  0  0 1 -1 -1  0 1
                 0 -2  0 2  1 -1  0 1  1  0  0 1
                 1  0 -3 1  1  1 -3 1  0  2 -6 2
                -1  1 -3 1 -1  0 -3 1 -1 -1 -3 1
                 0 -2 -6 2  1 -1 -3 1  1  0 -3 1 ]

The hardest part of deciding on a POV-Ray interpretation is keeping it compact.
My quick idea:

nurbs_patch {
points <u, v> order <u, v> u_knot {} v_knot {} range <u_min, v_min>, <u_max,
v_max>
control_points {}
}

nurbs_patch {
points <9, 2>
order <3, 2>
u_knot {0, 0, 0, 1, 1, 2, 2, 3, 3, 4, 4, 4}
v_knot {0, 0, 1, 1}
range {<0, 2>, <4, 2>
control_points {
<1, 0, 0, 1>, <1, 1, 0, 1>, <0, 2, 0, 2>,
<-1, 1, 0, 1>, <-1, 0, 0, 1>, <-1, -1, 0, 1>,
<0, -2, 0, 2>, <1, -1, 0, 1>, <1, 0, 01>,
<1, 0, -3, 1>, <1, 1, -3, 1>, <0, 2, -6, 2>,
<-1, 1, -3, 1>, <-1, 0, -3, 1>, <-1, -1, -3, 1>,
<0, -2, -6, 2>, <1, -1, -3, 1>, <1, 0, -3, 1>
}

}

And you would probably want a trim_curve section inside nurbs_patch.  Anyway,
someone feel like coding this up real quick? ;)

-Mike

Post a reply to this message