 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
A long time ago someone mentioned that they had written a preliminary
patch for NURBS. I think it was Nathan but the messages I have don't
seem to go back far enough.
Anyway, the person offered to share it with anyone interested. If I can
find the time, I plan on writing a patch to do direct rendering of
bicubic patches, and it seems it should be possible to include NURBS. I
could use any help I could get, so it would be great if whoever has that
code could forward it to me. :)
I hear that the direct approach causes rendering artifacts, but I'd like
to try it just the same.
-Mike
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Mike <Ama### [at] aol com> wrote:
: Anyway, the person offered to share it with anyone interested. If I can
: find the time, I plan on writing a patch to do direct rendering of
: bicubic patches
What's the difference between this and the bicubic patch rendering in
the official povray? (the povray method is 10 times faster? ;) )
--
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Yes, that was me. I sent my code to somebody, but I don't think they ever
took it farther than I did. I intended at one point to read some info
on better ways to subdivide NURBS, but then I got working on photon mapping
and that's kept me busy for a while (and will continue to in the near
future, at least).
Regarding your proposed patch - if it is fast, that would be nice. POV
currently subdivides bicubic patches. It has an option to subdivide only
as needed (practically 'direct rendering') but this is much slower than
pre-computed subdivision. If you have a technique that is fast, that
would be great.
The recursive definition for NURBS is a bit more complicated than the
definition for bezier surfaces, which makes subdivision computation a
bit more costly. I've been told that there are efficient ways to do
the subdivision, but I have not investigated the matter closely.
The really slow NURBS code that I wrote (just to see if it could be done)
is simply a parser front-end to the triangle mesh object. In other words,
if you make a NURBS surface with what I did, it is a mesh object
internally. If you want the code, let me know where to email it to.
-Nathan
Mike wrote:
>
> A long time ago someone mentioned that they had written a preliminary
> patch for NURBS. I think it was Nathan but the messages I have don't
> seem to go back far enough.
>
> Anyway, the person offered to share it with anyone interested. If I can
> find the time, I plan on writing a patch to do direct rendering of
> bicubic patches, and it seems it should be possible to include NURBS. I
> could use any help I could get, so it would be great if whoever has that
> code could forward it to me. :)
>
> I hear that the direct approach causes rendering artifacts, but I'd like
> to try it just the same.
>
> -Mike
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> Regarding your proposed patch - if it is fast, that would be nice. POV
> currently subdivides bicubic patches. It has an option to subdivide only
> as needed (practically 'direct rendering') but this is much slower than
> pre-computed subdivision. If you have a technique that is fast, that
> would be great.
>
I should mention that I will be trying to implement code written by Sean Graves
in 1990, so I really wouldn't be writing anything original. It uses the
newtonian method, which I hear is pretty fast but can have problems with
returning wrong intersections. If I can get it to work, then I may be able to
improve it by including bezier clipping and bounding volume heirarchy. This is
my first attempt at an actually useful patch, so I don't know yet if it's
beyond my abilities.
The main impulse for doing this is that I find the u and v steps annoying in
the current implementation. No matter what the screen resolution, POV-Ray will
always use the same number of subdivisions. The results are not only slow, but
rather jagged around the edges with some of the scenes that I've tried
rendering with large numbers of bicubic patches. It seemed to me that to alter
the code to tesselate down to a pixel in size would make rendering unbearable.
The photon patch has also been a factor as to why I'd like to do this. Even if
you could subdivide to pixel size, you would have to do it twice for photons,
and how would you know how small to dice the geometry for those? Hmm...
> The recursive definition for NURBS is a bit more complicated than the
> definition for bezier surfaces, which makes subdivision computation a
> bit more costly. I've been told that there are efficient ways to do
> the subdivision, but I have not investigated the matter closely.
>
The code I'm basing this on seems to use a basis matrix for rendering different
types of curved surfaces, one of which is bspline. My understanding is that it
is possible to redefine any NURBS surface as a piecewise bspline surface using
knot insertion. That should make it possible to render them using this code.
> The really slow NURBS code that I wrote (just to see if it could be done)
> is simply a parser front-end to the triangle mesh object. In other words,
> if you make a NURBS surface with what I did, it is a mesh object
> internally. If you want the code, let me know where to email it to.
>
Yeah, it would be great if you could send it to pov### [at] aolcom. One of my
biggest problems is that I can understand a lot of theory, but I'm clueless
without code examples.
Even if it turns out to be so incredibly slow that no one would want to use it,
I still think it would be a nice thing to have just as an example. It gets
asked about often enough.
-Mike
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Sat, 12 Jun 1999 16:57:15 -0500, Mike <Ama### [at] aolcom> wrote:
>> Regarding your proposed patch - if it is fast, that would be nice. POV
>> currently subdivides bicubic patches. It has an option to subdivide only
>> as needed (practically 'direct rendering') but this is much slower than
>> pre-computed subdivision. If you have a technique that is fast, that
>> would be great.
>
>I should mention that I will be trying to implement code written by Sean Graves
>in 1990, so I really wouldn't be writing anything original. It uses the
>newtonian method, which I hear is pretty fast but can have problems with
>returning wrong intersections. If I can get it to work, then I may be able to
>improve it by including bezier clipping and bounding volume heirarchy. This is
>my first attempt at an actually useful patch, so I don't know yet if it's
>beyond my abilities.
>
>The main impulse for doing this is that I find the u and v steps annoying in
>the current implementation. No matter what the screen resolution, POV-Ray will
>always use the same number of subdivisions. The results are not only slow, but
>rather jagged around the edges with some of the scenes that I've tried
>rendering with large numbers of bicubic patches. It seemed to me that to alter
>the code to tesselate down to a pixel in size would make rendering unbearable.
The superpatch and the isosurface patch have code for a "type 2"
rendering method for bicubics that takes an accuracty parameter
instead of u_steps and v_steps. It also has support for rational
bicubics and trimmed bezier splines.. You might want to look at that
and see how close it gets to NURBS before you set off across strange
new territory on your own.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I wasn't aware of that particular feature. It appears to use the clipping method
developed by Nishita. I couldn't find the original paper that discusses it on the
net, and I'm suprised someone had done that and I hadn't heard of it.
I got interesting results with a test scene rendered at 512x384 with no AA:
type 0 = 38 sec
type 1 = 18 sec
type 2 = 10 sec!
I'll be looking at it some more tonight.
-Mike
Ron Parker wrote:
> The superpatch and the isosurface patch have code for a "type 2"
> rendering method for bicubics that takes an accuracty parameter
> instead of u_steps and v_steps. It also has support for rational
> bicubics and trimmed bezier splines.. You might want to look at that
> and see how close it gets to NURBS before you set off across strange
> new territory on your own.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Hi,
would it be possible raytrace NURBS direct without tesslating to
faces?
I think i have seen some hints for a ray NURBS intersection in
comp.graphics algorithms.
If it possible rendering NURBS would be image size independent.
I have some code to convert NURBS (Rhino) to triangles with dynamic
subdivision. If you are interessted please mail me: thb### [at] ibmnet
But the key feature would be "trimmed NURBS". It means that a NURBS
curve cuts a hole into the NURBS surface.
The NURBS curve is usally given in uv coordinates.
If there is a NURBS ray hit test, it would be possible to test for a
trimming curve.
Usally all CSG operations with NURBS are done with trimmed NURBS.
>A long time ago someone mentioned that they had written a preliminary
>patch for NURBS. I think it was Nathan but the messages I have don't
>seem to go back far enough.
>
>Anyway, the person offered to share it with anyone interested. If I can
>find the time, I plan on writing a patch to do direct rendering of
>bicubic patches, and it seems it should be possible to include NURBS. I
>could use any help I could get, so it would be great if whoever has that
>code could forward it to me. :)
>
>I hear that the direct approach causes rendering artifacts, but I'd like
>to try it just the same.
>
>-Mike
-tb
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
It appears that the superpatch already has a very good implementation of
'direct' rendering of bicubic patches, so I guess my mission (should I chose
to accept it), is to come up with a way to convert a NURBS surface into a
bezier representation. :)
I think I have some references that cover this. I would base the syntax for
NURBS on how it's laid out in the renderman interface specification, since
that seems to be a comprehensive approach that includes trimmed surfaces.
I also have some papers that discuss how it's possible to speed up bezier
clipping by about 20% by including some other methods. I'll see if I can get
anywhere with that too.
I'll be more than happy to dump this project on someone once I fail
miserably. :)
-Mike
Thomas Baier wrote:
> Hi,
>
> would it be possible raytrace NURBS direct without tesslating to
> faces?
> I think i have seen some hints for a ray NURBS intersection in
> comp.graphics algorithms.
> If it possible rendering NURBS would be image size independent.
>
> I have some code to convert NURBS (Rhino) to triangles with dynamic
> subdivision. If you are interessted please mail me: thb### [at] ibmnet
>
> But the key feature would be "trimmed NURBS". It means that a NURBS
> curve cuts a hole into the NURBS surface.
> The NURBS curve is usally given in uv coordinates.
>
> If there is a NURBS ray hit test, it would be possible to test for a
> trimming curve.
> Usally all CSG operations with NURBS are done with trimmed NURBS.
>
> >A long time ago someone mentioned that they had written a preliminary
> >patch for NURBS. I think it was Nathan but the messages I have don't
> >seem to go back far enough.
> >
> >Anyway, the person offered to share it with anyone interested. If I can
> >find the time, I plan on writing a patch to do direct rendering of
> >bicubic patches, and it seems it should be possible to include NURBS. I
> >could use any help I could get, so it would be great if whoever has that
> >code could forward it to me. :)
> >
> >I hear that the direct approach causes rendering artifacts, but I'd like
> >to try it just the same.
> >
> >-Mike
>
> -tb
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Mike wrote:
>
> A long time ago someone mentioned that they had written a preliminary
> patch for NURBS. I think it was Nathan but the messages I have don't
> seem to go back far enough.
>
> Anyway, the person offered to share it with anyone interested. If I can
> find the time, I plan on writing a patch to do direct rendering of
> bicubic patches, and it seems it should be possible to include NURBS. I
> could use any help I could get, so it would be great if whoever has that
> code could forward it to me. :)
>
> I hear that the direct approach causes rendering artifacts, but I'd like
> to try it just the same.
>
> -Mike
See todays post in c.g.r.r. Subject: RenderMan compatible "front end"
from a gentlman looking to incorporate nurbs possibly into Pov ? He
states he has some working code and is looking for help with his project.
Perhaps the two of you can work out a colaborative effort of sorts.
--
Ken Tyler
mailto://tylereng@pacbell.net
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
