|
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
As you all know, PovRay supports bezier-patch surfaces.
A support of NURBS would be great! :)
see:
http://en.wikipedia.org/wiki/Non-uniform_rational_B-spline
Holger
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
H. Karsten schrieb:
> As you all know, PovRay supports bezier-patch surfaces.
>
> A support of NURBS would be great! :)
Strictly speaking, POV-Ray already /has/ built-in NURBS support, as
unless I'm totally mistaken NURBS are just one special case of the type
of patches POV-Ray supports via the "parametric" primitive.
But yes, something like the "mesh" primitive for NURBS might be neat.
Are there any standard file formats for storing NURBS data, such as .obj
is for meshes?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Building NURBS with patches in Povray, means building patches from NURBS
befor...
I don't know any tool, able to solve that problem.
The standard file format for NURBS is the IGES format. But it's week.
The best is the STEP format. Instead of IGES it works every time.
Holger
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
H. Karsten wrote:
> As you all know, PovRay supports bezier-patch surfaces.
>
> A support of NURBS would be great! :)
>
> see:
> http://en.wikipedia.org/wiki/Non-uniform_rational_B-spline
>
> Holger
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
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> The problem, of course, is getting the data in the first place. Creating
> NURBS via text editors is not easy.
POV converts the patches to triangles anyway before rendering, so in the end
what is the benefit of using POV to do the triangulation rather than the
modeller?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
scott schrieb:
>> The problem, of course, is getting the data in the first place.
>> Creating NURBS via text editors is not easy.
>
> POV converts the patches to triangles anyway before rendering, so in the
> end what is the benefit of using POV to do the triangulation rather than
> the modeller?
Scene file size and parse time?
Being able to adjust the detail level without having to re-export the mesh?
I'm also not sure whether converting to triangles is an absolute necessity.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> 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
|
|
| |
| |
|
|
|
|
| |