Jerry Anning wrote:

> See Foley
> and vanDam for more info.  This is a very limited "close enough for
> government work" once-over-lightly, but it should convey the idea.

I have this "brick" from Foley and van Dam and currently I'm trying to get
to basics of curves and surfaces. But does anybody know references for
implementation model?

Post a reply to this message

Nathan Kopp wrote:

> NURBS are nothing without a good modeler.

Rhino? It will be available soon.  If there is easier way to integrate it with
PovRay than meshes, then I consider of purchasing it, but I don't want spend money,
if  I have to fiddle with huge file sizes.

> It would be fairly easy to modify
> the current Bezier code to handle simple NURBS surfaces... or at least
> non-trimmed NURBS.  Trimmed NURBS are quite difficult, IMHO.  It all boils down
> to tesselating the surface into an internal triangle representation.

> However, modelers can already do the tesselation easily.  I've been working on
> a compact mesh syntax with Thomas Baier for 3DS-to-POV conversions that would
> also work to greatly reduce the size of any triangle mesh POV file.

Can You explain Your work? What do You mean by "reduce the size of any triangle
mesh file"? I've tried by myself patching PovRay to be able to read binary mesh
files (my custom format, where textual representation was replaced with direct
binary representation of float numbers). This drop parsing time for my scene from
80 to 30 second and files were smaller as well (by 40 % if I remember correctly).

May-be it's easier to use converter instead of patching PovRay. I don't know, how
long it will take to patch Povray, for as I said, I'm not expert in this field. And
I don't know, whether it will produce better outcome (parsing time will be
supposedly smaller, but if rendering time goes high, then it is useless).

P.S. May-be it would be better, if there is some repository of PovRay patch (and
utility) ideas and if someone works with something, then he makes entry to this
repository, so people will know, what's going on.

Post a reply to this message

> And then again (and here my math-incompetence shines through :-) - why
> tesselate at all? Couldn't POV-Ray use the direct mathematical functions for
> intersection tests?
> As I understand it, spheres for example are not tesselated internally, but
> instead intersected directly. Would something like this be possible for
> NURBS too?
> 
> Johannes.

Possibly. Not knowing much about NURBS mathematically, I couldn't say
for sure, but doing this tends to be computationally prohibitive - you
can tesselate enough that you can't tell the difference and still be a
hell of alot faster than direct intersection tests, in many cases. This
is presumably why POV uses a tesselated form for the current bezier
patches.

Michael Smith

Post a reply to this message

I don't think trimmed NURBS would be a priority anyway.  My understanding is that
Max's original implimentation of NURBS didn't include trimmed surfaces or curves.
Trimmed NURBS are considered bad news anyway, as they are not as easy to texture or
deform, and so I tend to avoid using them in Rhino.  They can be excluded by
planning ahead a bit.

Something that has recently got my attention, however, is that there is a new beta
of hash animation master that is able to import dxf files and create patches from
them.  The problem with it is that they create 3 point patches, which crinkle and
create holes badly.  How hard would it be to convert a triangle mesh into a
polyface mesh with 4 point polygons and then use the vertex info to create bezier
patches?   Provided that the number of points were reduced and evenly distributed,
perhaps that could be something easier manage than NURBS.

-Mike

Nathan Kopp wrote:

> NURBS are nothing without a good modeler.  It would be fairly easy to modify
> the current Bezier code to handle simple NURBS surfaces... or at least
> non-trimmed NURBS.  Trimmed NURBS are quite difficult, IMHO.  It all boils down
> to tesselating the surface into an internal triangle representation.
>
> However, modelers can already do the tesselation easily.  I've been working on
> a compact mesh syntax with Thomas Baier for 3DS-to-POV conversions that would
> also work to greatly reduce the size of any triangle mesh POV file.
>
> -Nathan Kopp

Post a reply to this message

Michael Smith wrote:
> Possibly. Not knowing much about NURBS mathematically, I couldn't say
> for sure, but doing this tends to be computationally prohibitive - you
> can tesselate enough that you can't tell the difference and still be a
> hell of alot faster than direct intersection tests, in many cases. This
> is presumably why POV uses a tesselated form for the current bezier
> patches.

Yes, that's true.  Doing an actual intersection with spheres, boxes, and other
such polygons is one thing, but bicubic surfaces (uniform or non-uniform) is
really, really slow.  Tesselating during parsing increases parse time, but
produces overall savings in total render time.

I have NURBS 2D curve code and it should be easy to convert it into 3D stuff. 
I actually started working on a NURBS patch for POV about a year ago, but then
when I saw how difficult trimmed NURBS would be, I stopped.  I'm working on
some other POV improvements (uv mapping) currently, but I'd be happy to help if
someone else wants to work on this.

-Nathan

Post a reply to this message

Vahur Krouverk wrote:
> Can You explain Your work? What do You mean by "reduce the size of any triangle
> mesh file"? I've tried by myself patching PovRay to be able to read binary mesh
> files (my custom format, where textual representation was replaced with direct
> binary representation of float numbers). This drop parsing time for my scene from
> 80 to 30 second and files were smaller as well (by 40 % if I remember correctly).

The new syntax is still in text format, but it uses indices & vertex lists, similar
to how 3DS files work.  I'm not sure of how much space is saved, but it should be
OK.  Being able to read a binary format might also be good, but I don't think that
introducing ANOTHER 3D format would be such a good idea.  Maybe if we could get
POV to read DXF... but then there are copyright issues to deal with.

> May-be it's easier to use converter instead of patching PovRay. I don't know, how
> long it will take to patch Povray, for as I said, I'm not expert in this field. And
> I don't know, whether it will produce better outcome (parsing time will be
> supposedly smaller, but if rendering time goes high, then it is useless).

Patching POV with non-trimmed would involve quite a bit of stuff (but should be
possible if a few people work on it).

-Nathan Kopp

Post a reply to this message

Nathan Kopp wrote in message <3582764D.9CB05720@ltu.edu>...
>OK.  Being able to read a binary format might also be good, but I don't
think that
>introducing ANOTHER 3D format would be such a good idea.  Maybe if we could
get
>POV to read DXF... but then there are copyright issues to deal with.


Copyright? There are lot's of programs out there that can read/write DXF
(including Thomas' 3DWin). I don't suppose they all asked Autodesk for
permission. As I see it DXF is a open format.

Anyway. Standard DXF is ASCII too. DXF-files with meshes are even larger
than POV-files with meshes.

Johannes.

Post a reply to this message

Johannes Hubert wrote:
>
> As I see it DXF is a open format.

Thanks for clearing that up.
 
> Anyway. Standard DXF is ASCII too. DXF-files with meshes are even larger
> than POV-files with meshes.

Interesting... I never compared file sizes. Is there a good standard binary
format, though?

In other news... I pulled my NURBS code out of mothballs and looked it over. 
I've got a DJGPP/Allegro C++ file that can evaluate a NURBS surface value for
any given (u,v) vector.  I'll try to make it tesselate a NURBS surface into a
POV mesh file.  If I get that working, I'll try to build it into a new POV
primative.

When adding NURBS to POV, I'll probably just store the tesselated triangles in
a regular triangle mesh.  This would not require much additional code. 
However, in the future we would probably want the data to be stored in a
bounded quad-tree format (similar to POV's bezier surfaces) to speed up
rendering.

-Nathan Kopp

Post a reply to this message

Nathan Kopp wrote in message <35845704.D72788F5@ltu.edu>...
>Johannes Hubert wrote:

>
>Interesting... I never compared file sizes. Is there a good standard binary
>format, though?

None that I know of, but that doesn't mean anything :-)
There is a binary version of the DXF format also (at least I have read about
it), but it doesn't seem to be in much use. All the programs I know that
export to (or read) DXF use the ASCII DXF.

Johannes.

Post a reply to this message

On Sun, 14 Jun 1998 17:04:36 -0600, Nathan Kopp <nk8### [at] ltuedu>
wrote:

>Johannes Hubert wrote:
>>
>> As I see it DXF is a open format.
>
>Thanks for clearing that up.
> 
>> Anyway. Standard DXF is ASCII too. DXF-files with meshes are even larger
>> than POV-files with meshes.
>
>Interesting... I never compared file sizes. Is there a good standard binary
>format, though?
>

I'm not sure if this will help or not, but 3DS mesh files are binary
and they save a LOT of space. I'm not sure if the format is free to
use, and I'm not sure if the format actually supports NURBS directly.
You might have to convert to meshes to store a NURBS model, I don't
know. Many programs will support the 3DS format, I do know that.

Later,

Glen Berry
777### [at] ezwvcom    Remove the "777" to reply via email.

Post a reply to this message