 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Is the a patch or spline->spline conversion utility that will allow
NURBS surfaces to be rendered with POV?
Thanks,
Jeff
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Jeff Garzik wrote in message <366CCE44.9BADFD78@pobox.com>...
>Is the a patch or spline->spline conversion utility that will allow
>NURBS surfaces to be rendered with POV?
>
>Thanks,
>
> Jeff
As far as I know there aren't any programs that can actually render a nurbs
surface. I've always thought they had to be converted to a mesh first.
Correct me if I'm wrong though.
I'm going to take a wild guess and say that you use Rhino3D. If so, you can
only output the scene you've made in the form of a mesh. POV can't take the
info of a nurbs surface and convert it to a mesh, and I don't think there
are any patches that will let you do this either. It would be a nice
feature though.
I'm going to take another wild guess and say that if you are using rhino,
the files it outputs are huge, and they take forever to parse. I can only
suggest that you lower the polygon count when you export them. Unless you
get up really close to your model, you can't tell if it's lost a few
thousand polygons.
Or if you really wanted all those polygons, save them for the final render.
Set your scene up in POV with a low polygon count model, and then when
you're happy, import the big mesh.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
RagWeed <mfr### [at] netwalk comnospam> wrote:
: Or if you really wanted all those polygons, save them for the final render.
: Set your scene up in POV with a low polygon count model, and then when
: you're happy, import the big mesh.
If the file sizes are a problem, he can try my triangle mesh compressor
and the compressed mesh macro by Colefax at
http://www.geocities.com/SiliconValley/Lakes/1434/pcm.html
It will not reduce parsing time, but it probably will reduce file sizes
considerably.
There will be a new version of the compressor and the macro soon. The
compressor is ready, just waiting for Colefax to finish his macro... :)
--
main(i){char*_="BdsyFBThhHFBThhHFRz]NFTITQF|DJIFHQhhF";while(i=
*_++)for(;i>1;printf("%s",i-70?i&1?"[]":" ":(i=0,"\n")),i/=2);} /*- Warp. -*/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Also, you could check out UVPov or the SuperPatch. Both include a new format
for the mesh object (named mesh2). A 3ds-to-pov converter has been developed
by Thomas Baier specifically for this new mesh syntax. Be aware that you may
run into problems if you convert Rhino to 3DS to POV. It works with most
things, but sometimes the textures get messed up.
You can find out more about UVPov (and get links to SuperPatch and
3ds-to-pov) at my web page:
http://nathan.kopp.com/patched.htm
-Nathan
Nieminen Mika wrote:
>
> If the file sizes are a problem, he can try my triangle mesh compressor
> and the compressed mesh macro by Colefax at
> http://www.geocities.com/SiliconValley/Lakes/1434/pcm.html
> It will not reduce parsing time, but it probably will reduce file sizes
> considerably.
> There will be a new version of the compressor and the macro soon. The
> compressor is ready, just waiting for Colefax to finish his macro... :)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
RagWeed wrote:
> As far as I know there aren't any programs that can actually render a nurbs
> surface. I've always thought they had to be converted to a mesh first.
> Correct me if I'm wrong though.
Actually, some programs (e.g. RenderMan, BMRT) work right from the
NURBS. They do not convert to a mesh. In any case, a NURBS patch can
be converted to a rational bezier patch by using Bohm's method to add
knots and give the NURBS a 0, 0, 0, 0, 1, 1, 1, 1 knot vector. See
Foley and vanDam. The rational Bezier could then be rendered with the
rational Bezier functions of the SuperPatch. This may not be practical
in some cases, but it can be done.
Jerry Anning
cle### [at] dholcom
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Jerry Anning wrote:
> RagWeed wrote:
> > As far as I know there aren't any programs that can actually render a nurbs
> > surface. I've always thought they had to be converted to a mesh first.
> > Correct me if I'm wrong though.
> Actually, some programs (e.g. RenderMan, BMRT) work right from the
> NURBS. They do not convert to a mesh. In any case, a NURBS patch can
> be converted to a rational bezier patch by using Bohm's method to add
> knots and give the NURBS a 0, 0, 0, 0, 1, 1, 1, 1 knot vector. See
> Foley and vanDam. The rational Bezier could then be rendered with the
> rational Bezier functions of the SuperPatch. This may not be practical
> in some cases, but it can be done.
Thanks much. I'm glad I kept my copy of Foley. :)
I am currently converting NURBS to mesh, and am looking for a method
that uses less memory, and hopefully flies on the FPU monster machine
(500Mhz Alpha) in the computer room.
Patch wizards -- are there any fundamental reasons why NURBS would be
difficult to implement in POV? Perhaps I could take a crack at working
up a nurbs patch.
Jeff
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Jeff Garzik wrote:
>
> Patch wizards -- are there any fundamental reasons why NURBS would be
> difficult to implement in POV? Perhaps I could take a crack at working
> up a nurbs patch.
>
> Jeff
I don't know about working with NURBS directly (that would be really slow,
from my experience), but converting to triangles should be pretty easy. I
actually had a version of POV that would read in NURBS. It was really just
a front-end parser to the triangle-mesh object. POV's triangle mesh object
is actually pretty efficient (both with memory and rendering speed). But
my code was really slow and may have had some bugs. I still have it lying
around (I think), so if you want it I'll send it. Also, didn't somebody
else ask for it once? I may have forgotten to give it to that person.
oops. ;-)
-Nathan Kopp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Jeff Garzik <jga### [at] poboxcom> wrote:
: Patch wizards -- are there any fundamental reasons why NURBS would be
: difficult to implement in POV? Perhaps I could take a crack at working
: up a nurbs patch.
I have absolutely no idea about the mathematics involved in NURBS
calculation, but I can speculate and say that those renderers which use
real NURBS (bmrt, renderman) are not raytracers while povray is. Maybe
calculating the intersection of a ray and a NURBS is not easy and/or fast?
I don't know...
(Note: Maybe I'm wrong with bmrt, but AFAIK renderman is not a raytracer)
--
main(i){char*_="BdsyFBThhHFBThhHFRz]NFTITQF|DJIFHQhhF";while(i=
*_++)for(;i>1;printf("%s",i-70?i&1?"[]":" ":(i=0,"\n")),i/=2);} /*- Warp. -*/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
BMRT is a true raytrace/radiosity renderer, although it also adheres to the
Renderman language standard. I am not sure, but I believe BMRT and Renderman
convert NURBS to triangle meshes internally (after all, POV does this with
bezier patches, too)
Margus
Nieminen Mika wrote:
>
> I have absolutely no idea about the mathematics involved in NURBS
> calculation, but I can speculate and say that those renderers which use
> real NURBS (bmrt, renderman) are not raytracers while povray is. Maybe
> calculating the intersection of a ray and a NURBS is not easy and/or fast?
> I don't know...
> (Note: Maybe I'm wrong with bmrt, but AFAIK renderman is not a raytracer)
>
> --
> main(i){char*_="BdsyFBThhHFBThhHFRz]NFTITQF|DJIFHQhhF";while(i=
> *_++)for(;i>1;printf("%s",i-70?i&1?"[]":" ":(i=0,"\n")),i/=2);} /*- Warp. -*/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Nathan Kopp <Nat### [at] Koppcom> writes:
> Jeff Garzik wrote:
> >
> > Patch wizards -- are there any fundamental reasons why NURBS would be
> > difficult to implement in POV? Perhaps I could take a crack at working
> > up a nurbs patch.
> >
> > Jeff
>
> I don't know about working with NURBS directly (that would be really slow,
> from my experience), but converting to triangles should be pretty easy. I
> actually had a version of POV that would read in NURBS. It was really just
> a front-end parser to the triangle-mesh object. POV's triangle mesh object
> is actually pretty efficient (both with memory and rendering speed). But
> my code was really slow and may have had some bugs. I still have it lying
> around (I think), so if you want it I'll send it. Also, didn't somebody
> else ask for it once? I may have forgotten to give it to that person.
> oops. ;-)
Did you consider to generate the triangles "on the fly" while rendering
takes place? This technique is used for Bezier patches. You can choose
between the two methods by a switch. (But probably, you already know all
this.)
In my opinion an analogous implementation of Bezier patches and NURBS
would be nice (and very useful).
Thomas
--
http://www.fmi.uni-konstanz.de/~willhalm
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Margus Ramst wrote:
>
> BMRT is a true raytrace/radiosity renderer, although it also adheres to the
> Renderman language standard. I am not sure, but I believe BMRT and Renderman
> convert NURBS to triangle meshes internally (after all, POV does this with
> bezier patches, too)
BMRT is indeed a true ray tracer. It does not at any point convert
NURBS to triangles. Neither does RenderMan. For that matter, neither
they nor POV convert Beziers to triangle meshes. POV subdivides Beziers
into smaller Bezier patches until they are flat enough to be considered
rectangles.
Jerry Anning
cle### [at] dholcom
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Jerry Anning wrote:
>
> BMRT is indeed a true ray tracer. It does not at any point convert
> NURBS to triangles. Neither does RenderMan. For that matter, neither
> they nor POV convert Beziers to triangle meshes. POV subdivides Beziers
> into smaller Bezier patches until they are flat enough to be considered
> rectangles.
>
I must disagree. (I'm guessing, but it is an educated guess.) I agree that
BMRT is a true raytracer. But doing anything with NURBS without converting
them to triangles is very time consuming. If it did not convert them to
triangles, the render time would make it so nobody would use NURBS with BMRT.
Also, I'd bet that BMRT converts the majority (if not all) of its surfaces into
triangles before rendering. I know that RenderMan does, since all scanline
renders convert all objects into triangles.
POV can subdivide Beziers on the fly into smaller and smaller beziers until
they are rectangles (the rectangle is rendered as two smooth triangles).
However, this is 'type 0', which renders quite slowly compared to 'type 1'.
Type 1 subdivides as a pre-computation step and stores the triangles in a nice,
efficient octree structure.
It should be noted that POV can only subdivide the beziers into sub-patches
because of the nature of the bezier parametric equation. There is no such
optimization that I know of when dealing with NURBS, especially trimmed NURBS.
Therefore, subdividing NURBS on the fly could end up being VERY slow.
(This is also an answer to Thomas Willhalm's question.)
IMHO, POV does a great job rendering smooth triangles (with the new mesh2
syntax that can be found in UVPov and the SuperPatch), both in memory
efficiency and speed.... so, if we can get a fast pre-processing step, I think
we'd be all set.
-Nathan Kopp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Nathan Kopp wrote:
>
> Jerry Anning wrote:
> >
> > BMRT is indeed a true ray tracer. It does not at any point convert
> > NURBS to triangles. Neither does RenderMan. For that matter, neither
> > they nor POV convert Beziers to triangle meshes. POV subdivides Beziers
> > into smaller Bezier patches until they are flat enough to be considered
> > rectangles.
> >
>
> I must disagree. (I'm guessing, but it is an educated guess.) I agree that
> BMRT is a true raytracer. But doing anything with NURBS without converting
> them to triangles is very time consuming. If it did not convert them to
> triangles, the render time would make it so nobody would use NURBS with BMRT.
> Also, I'd bet that BMRT converts the majority (if not all) of its surfaces into
> triangles before rendering. I know that RenderMan does, since all scanline
> renders convert all objects into triangles.
I'm not guessing. They don't. RenderMan doesn't use simple scanline,
it uses REYES which is somewhat different. There are reasonably fast
ways to do NURBS without triangulating. Inquire on
comp.graphics.rendering.renderman and/or comp.graphics.algorithms if you
are curious.
Jerry Anning
cle### [at] dholcom
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Jerry Anning wrote:
>
> I'm not guessing. They don't. RenderMan doesn't use simple scanline,
> it uses REYES which is somewhat different. There are reasonably fast
> ways to do NURBS without triangulating. Inquire on
> comp.graphics.rendering.renderman and/or comp.graphics.algorithms if you
> are curious.
>
Thanks! I think I'll do a search on Dejanews to see if there have been
any discussions in the past. I usually don't like to jump into a usenet
group without lurking for a while. Are there any web pages or online
papers regarding the REYES renderer? (Or is it top-secret Pixar
technology?) Also, if you know of any web pages or papers about fast
evaluation of NURBS, could you post them so that people can get started
on adding them to POV. I abandoned my earlier work mostly because it was
really slow (parsing a triangle mesh was quicker than my NURBS evaluation
code).
-Nathan
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Maybe not what you were asking for (I haven't looked at it in depth) but this
library seems like something worth looking into.
http://lowrent.org/nurbs/documentation.shtml
-Mike
Nathan Kopp wrote:
> Thanks! I think I'll do a search on Dejanews to see if there have been
> any discussions in the past. I usually don't like to jump into a usenet
> group without lurking for a while. Are there any web pages or online
> papers regarding the REYES renderer? (Or is it top-secret Pixar
> technology?) Also, if you know of any web pages or papers about fast
> evaluation of NURBS, could you post them so that people can get started
> on adding them to POV. I abandoned my earlier work mostly because it was
> really slow (parsing a triangle mesh was quicker than my NURBS evaluation
> code).
>
> -Nathan
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Hi Nathan,
> run into problems if you convert Rhino to 3DS to POV. It works with most
> things, but sometimes the textures get messed up.
>
Rhino to 3ds texture conversion works well if you switch off the weld option.
-td
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
