> Being able to adjust the detail level without having to re-export the 
> mesh?

I find it easier to do that in the modeller, there you can interactively see 
the size of the triangles and adjust the detail until it looks good without 
too much overkill.  Of course if you radically change the viewpoint or 
something you might need to re-export, but overall I find that faster than 
tweaking with parameters in POV (which is usually quite a slow process).

> I'm also not sure whether converting to triangles is an absolute 
> necessity.

Being able to render the patches directly without triangulating would be 
cool!  I guess you "just" need a ray-patch intersection formula - does such 
a thing exist?  Or use some kind of sampling method like media to find the 
surface?  I have no idea if that will be any faster than splitting up into 
pixel sized triangles.

Post a reply to this message

On Tue, 17 Nov 2009 15:57:30 +0100, scott <sco### [at] scottcom> wrote:
>
> Being able to render the patches directly without triangulating would be  
> cool!  I guess you "just" need a ray-patch intersection formula - does  
> such a thing exist?

Yes, such a thing exists, but the math is a bit complicated, and  
performance is likely to be underwhelming.

http://www.google.com/search?q=nurbs+ray+intersection



-- 
FE

Post a reply to this message

"scott" <sco### [at] scottcom> wrote:
...
> Being able to render the patches directly without triangulating would be
> cool! I guess you "just" need a ray-patch intersection formula - does such
> a thing exist? Or use some kind of sampling method like media to find the
> surface? I have no idea if that will be any faster than splitting up into
> pixel sized triangles.

The Pixar Renderman is rendering NURBS and Patches without triangulation in
before.
Its very fast, saves times and space.

Holger

Post a reply to this message

Chambers <Ben### [at] gmailcom> wrote:
....
> It's easy enough to write a macro to handle streams of patches for you,
> if you already have the data. The last time I wrote one, I think I
> finished it in under an hour.
>
> The problem, of course, is getting the data in the first place.
> Creating NURBS via text editors is not easy.
>
> ...Chambers

Then, it shouldn't be a problem to compile such a feature into PovRay.

I don't know, how to write such a Macro, but rendering a NURBS-surface in
PovRay, without any problems for the user would still be a cool thing.

Post a reply to this message

scott schrieb:

>> I'm also not sure whether converting to triangles is an absolute 
>> necessity.
> 
> Being able to render the patches directly without triangulating would be 
> cool!  I guess you "just" need a ray-patch intersection formula - does 
> such a thing exist?

You actually need a ray-patch intersection /algorithm/. Which may be 
based on a formula of course.

You also need an algorithm to compute a bounding box.


 > Or use some kind of sampling method like media to
> find the surface?

That would probably be difficult. It's hard to tell which side of the 
patch you're on.

I guess it'll probably boil down to something like computing a polynom, 
and then solving it for zero.

 > I have no idea if that will be any faster than
> splitting up into pixel sized triangles.

I have no idea. At least it'll be more memory-efficient.

Post a reply to this message

Fredrik Eriksson schrieb:

>> Being able to render the patches directly without triangulating would 
>> be cool!  I guess you "just" need a ray-patch intersection formula - 
>> does such a thing exist?
> 
> Yes, such a thing exists, but the math is a bit complicated, and 
> performance is likely to be underwhelming.
> 
> http://www.google.com/search?q=nurbs+ray+intersection

The very first entry /looks/ promising though.

Post a reply to this message

scott wrote:
> Being able to render the patches directly without triangulating would be 
> cool!  I guess you "just" need a ray-patch intersection formula - does 
> such a thing exist?  Or use some kind of sampling method like media to 
> find the surface?  I have no idea if that will be any faster than 
> splitting up into pixel sized triangles.


Sure, they exist.  I used to expand functions like that by hand for fun 
(yes, I was weird... actually, I'm *still* weird :) ).  I think a 
bicubic patch filled most of an 8.5x11 page if you wrote small ;)

...Chambers

Post a reply to this message

"H. Karsten" <h-karsten()web.de> wrote:
> "scott" <sco### [at] scottcom> wrote:
> ...
> > Being able to render the patches directly without triangulating would be
> > cool! I guess you "just" need a ray-patch intersection formula - does such
> > a thing exist? Or use some kind of sampling method like media to find the
> > surface? I have no idea if that will be any faster than splitting up into
> > pixel sized triangles.
>
> The Pixar Renderman is rendering NURBS and Patches without triangulation in
> before.
> Its very fast, saves times and space.
>
> Holger

https://renderman.pixar.com/products/whats_renderman/2.html

On the contrary, Pixar turns all surfaces into triangles based on pixel space.
This is how it is able to render displacement so well

Post a reply to this message

"H. Karsten" <h-karsten()web.de> wrote:
> Chambers <Ben### [at] gmailcom> wrote:
> ....
> > It's easy enough to write a macro to handle streams of patches for you,
> > if you already have the data. The last time I wrote one, I think I
> > finished it in under an hour.
> >
> > The problem, of course, is getting the data in the first place.
> > Creating NURBS via text editors is not easy.
> >
> > ...Chambers
>
> Then, it shouldn't be a problem to compile such a feature into PovRay.
>
> I don't know, how to write such a Macro, but rendering a NURBS-surface in
> PovRay, without any problems for the user would still be a cool thing.

I once made a lot of NURBS macros for POV-Ray.

Here's an image made with some of them:
http://home.online.no/~t-o-k/POV-Ray/NURBS-Bivariate_Mesh.jpg

Some more of my NURBS images can be found here:
http://home.online.no/~t-o-k/POV-Ray_Images/

I guess that the average user would find that using using NURBS (and get full
control over them) is somewhat difficult, especially with a textual user
interface.

I.e.: They would have to learn about about different types of knot vectors and
about the effects of changing the weights for the control points.

With at text interface it may also be a lot of work to get the control points in
the control mesh positioned so that the NURBS surface gets the desired shape.

--
Tor Olav
http://subcube.com

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
> scott schrieb:
>
> >> I'm also not sure whether converting to triangles is an absolute
> >> necessity.
> >
> > Being able to render the patches directly without triangulating would be
> > cool!  I guess you "just" need a ray-patch intersection formula - does
> > such a thing exist?
>
> You actually need a ray-patch intersection /algorithm/. Which may be
> based on a formula of course.
>
> You also need an algorithm to compute a bounding box.
....

A good start for a bounding box for a NURBS surface would be a bounding box that
contains all the points in its control grid

--
Tor Olav
http://subcube.com

Post a reply to this message