in news:3fe51ea3$1@news.povray.org Micheal (Mike) Williams wrote:

> And on a side note there is not IIRC a rendering engine that renders
> NURBS directly.

Not a complete one but:

The paper
http://www.cs.utah.edu/vissim/papers/raynurbs/raynurbs.html

The code
http://www.acm.org/jgt/papers/MartinCohenFishShirley00/


Ingo

Post a reply to this message

> This seems to be an oddly persistent misconception...almost as bad as
> the "4.0 will be GPL" one. POV-Ray does not support plugins because
> there is no platform-independent way of loading them, and the plugins
> themselves would be platform dependent, making for a support nightmare.

Hm, okay. I remember someone saying something along the lines of making it
easier for the Standard-User to make some changes with POV-Ray's way of
doing things, and I immediately thought of plug-ins. Now that you mention
the "charges" against plug-ins, I can see my mistake: I always forget about
the portability problem.

> Because of it being a rewrite, it merits a full version increase. A full
> version number increase does not indicate that it's a rewrite, however,
> only that it's a major update.

I've learned at the university that you begin with 0.x until you've got the
first stable release, that'll be 1.0 then. Patches and updates to that go
along with 1.0.x and 1.x.x. If the main core of the system is exchanged with
a compete rewrite from scratch, that's when 2.x.x comes into play. But it's
a little hazy to remember, was a few years ago. Thorsten posted a link once
which explained the version-number-system POV-Ray uses. Do you have it?

> How does an update to the proximity pattern sound? A blur pattern? Or
> how about an extension to functions which lets you get the surface
> normal and ray direction in pattern functions?

That all sounds really nice. How about a ray which will output the same
color as it would when being rendered? Sort of like an inbuilt camera? If it
shoots rays at the surface where there's supposed to be the camera-pigment
itself, it could just return black, or some other texture (and black is just
default).
But my point was: several enhancements are nice, but I'm only in the
position of making suggestions. I can't code that good myself (yet, perhaps)
and I can't tell anyone what to do on a project like this. I'm grateful for
every little feature which I can use and rely on, but if, for example, the
proximity-pattern wouldn't be implemented in the first release, I wouldn't
blame anyone. Someone would surely cook some method, be it a patch or
SDL-Code, which can do it, although slower than when it had been implemented
right off the start... Or I would go out and code some little SDL myself and
experiment until I got what I needed (as I do these days on things that I
know I'm capable of...).

Regards,
Tim

-- 
"Tim Nikias v2.0"
Homepage: <http://www.nolights.de>
Email: tim.nikias (@) nolights.de

Post a reply to this message

news:3fe51ea3$1@news.povray.org...
> all of these changes and renders building this model in any other program
> would require major rebuilds for each change. But with POVRay to move the
> spicket's I just change one variable and rerender. This is the very power
of
> the SDL. Changes could be made with out rebuilding the whole model over
for
> each change.

The possibility to parametrize an object is certainly a big strength of the
SDL. Two things, however:
1) it's reserved for what you can code by yourself with the SDL only, i.e.
without an external modeller. As, we know, this is a lot and some projects
certainly can be done like this (I also know of an entire, real-life,
architectural project coded in SDL rather than with 3D Studio). But it's
also limited, if only by the amount of time you can dedicate to it.

2) let's not assume that this isn't possible in other software. Actually, in
the one I'm learning now, the user has access to the model geometry and can
parametrize them if necessary, make calculations etc.

> They are always IIRC converted to polygons before rendering. So to
> convert NURBS and out put to POVRay is not a handicap for POVRay.
> In fact POVRay handles triangles from NURBS better than most rendering
engines.

As a Rhino user I can tell that having to convert NURBS into POV-Ray is a
handicap. One has to go through the entire model and fine-tune each part so
that the whole thing doesn't end up in a 500 Mb mesh. UV mapping is often
lost in the process, so it's necessary to remap the parts. And of course, a
downsized polygonal mesh is less nice-looking than a native NURBS (or any
other parametric surface in fact).

> And on a side note there is not IIRC a rendering engine that renders NURBS
> directly.

Not all of them certainly, but some do:
Mental Ray
http://www.mentalimages.com/2_1_1_technical/index.html
Renderman
https://renderman.pixar.com/products/tools/renderman.html
Mantra
http://www.sidefx.com/products/houdini/mantra/

Of course, how it's done internally is another problem, but the idea is
still that you feed the renderer a parametric object and that it renders
something nice and smooth and not a bunch of polys.

In any case, NURBS was just an example among others and I'm not specifically
advocating NURBS support in POV-Ray. See the FBX interchange file format,
which gives an idea of what is expected in terms of compatibility :
http://www.kaydara.com/products/fbx/index.php?filename=techspecs


G.

Post a reply to this message

In article <3fe58034@news.povray.org>,
 "Tim Nikias v2.0" <tim.nikias (@) nolights.de> wrote:

> I've learned at the university that you begin with 0.x until you've got the
> first stable release, that'll be 1.0 then. Patches and updates to that go
> along with 1.0.x and 1.x.x. If the main core of the system is exchanged with
> a compete rewrite from scratch, that's when 2.x.x comes into play. But it's
> a little hazy to remember, was a few years ago. Thorsten posted a link once
> which explained the version-number-system POV-Ray uses. Do you have it?

I don't have a reference to what Thorsten posted. However, #.#.X updates 
are bug fixes, #.X updates are minor updates with new features but no 
major changes, and X.0 updates are major updates with large additions or 
changes. A bug fix or minor update will rarely affect backwards 
compatibility, a major update is more likely to do so. A total rewrite 
is a major update, but not all major updates involve total rewrites.


> That all sounds really nice. How about a ray which will output the same
> color as it would when being rendered? Sort of like an inbuilt camera? If it
> shoots rays at the surface where there's supposed to be the camera-pigment
> itself, it could just return black, or some other texture (and black is just
> default).

It is not possible to trace a ray in the scene until after parsing is 
done. Aside from the fact that once you added something to the scene 
based on the results, you will have potentially changed those results, 
it would require doing things like radiosity, photon mapping, and other 
post-parse, pre-render steps, every time you used this feature.


> But my point was: several enhancements are nice, but I'm only in the
> position of making suggestions. I can't code that good myself (yet, perhaps)
> and I can't tell anyone what to do on a project like this. I'm grateful for
> every little feature which I can use and rely on, but if, for example, the
> proximity-pattern wouldn't be implemented in the first release, I wouldn't
> blame anyone.

Hmm, just thought I should clarify something: I don't even know if my 
updated proximity pattern or other patches will make it into the next 
MegaPOV, let alone the official POV 4.0.
BTW, I just finished another pattern: voronoi. It is basically a version 
of the crackle pattern that allows you to specify the points used to 
generate the pattern. It allows some nice effects...I'll post some 
images later, but transferring them from my development machine will be 
a pain. (Long story short: I usually have them linked by ethernet, but I 
don't have an ethernet cable.)

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: chr### [at] tagpovrayorg
http://tag.povray.org/

Post a reply to this message

>
>As a Rhino user I can tell that having to convert NURBS into POV-Ray is a
>handicap. One has to go through the entire model and fine-tune each part so
>that the whole thing doesn't end up in a 500 Mb mesh. UV mapping is often
>lost in the process, so it's necessary to remap the parts. And of course, a
>downsized polygonal mesh is less nice-looking than a native NURBS (or any
>other parametric surface in fact).
>

I am wondering, whether NURBS support is anywhere on the POV-team's current
agenda.  I've seen such a feature request come up before, and it seems like
such a generally useful modelling integration feature that I am surprised
that nobody has attacked it before.  From the posting by ingo, it does not
seem like it would be rocket science either.  I am asking because I am
considering this as an possible project (once I finish my current one, that
is :)

POV-Ray nurbs support with on-the-fly tessellation / cacheing... that would
be nice...

Andrew

Post a reply to this message

"Gilles Tran" <gitran_nospam_@wanadoo.fr> wrote in message
news:3fe5811d@news.povray.org...
>

> news:3fe51ea3$1@news.povray.org...
> > all of these changes and renders building this model in any other
program
> > would require major rebuilds for each change. But with POVRay to move
the
> > spicket's I just change one variable and rerender. This is the very
power
> of
> > the SDL. Changes could be made with out rebuilding the whole model over
> for
> > each change.
>
> The possibility to parametrize an object is certainly a big strength of
the
> SDL. Two things, however:
> 1) it's reserved for what you can code by yourself with the SDL only, i.e.
> without an external modeller. As, we know, this is a lot and some projects
> certainly can be done like this (I also know of an entire, real-life,
> architectural project coded in SDL rather than with 3D Studio). But it's
> also limited, if only by the amount of time you can dedicate to it.
>
> 2) let's not assume that this isn't possible in other software. Actually,
in
> the one I'm learning now, the user has access to the model geometry and
can
> parametrize them if necessary, make calculations etc.
>
> > They are always IIRC converted to polygons before rendering. So to
> > convert NURBS and out put to POVRay is not a handicap for POVRay.
> > In fact POVRay handles triangles from NURBS better than most rendering
> engines.
>
> As a Rhino user I can tell that having to convert NURBS into POV-Ray is a
> handicap. One has to go through the entire model and fine-tune each part
so
> that the whole thing doesn't end up in a 500 Mb mesh. UV mapping is often
> lost in the process, so it's necessary to remap the parts. And of course,
a
> downsized polygonal mesh is less nice-looking than a native NURBS (or any
> other parametric surface in fact).
>
> > And on a side note there is not IIRC a rendering engine that renders
NURBS
> > directly.
>
> Not all of them certainly, but some do:
> Mental Ray
> http://www.mentalimages.com/2_1_1_technical/index.html
> Renderman
> https://renderman.pixar.com/products/tools/renderman.html
> Mantra
> http://www.sidefx.com/products/houdini/mantra/
>
> Of course, how it's done internally is another problem, but the idea is
> still that you feed the renderer a parametric object and that it renders
> something nice and smooth and not a bunch of polys.

All three rendering systems you mentions (Mentalray, PRman, Mantra) use
tessellation to map polygons onto the surface of a nurbs just before
rendering. They actually render the poly's not the nurbs. So 500M of poly's
is still 500M of poly's regardless of when they are created. In fact it
would seem faster to have already processesed the NURBS to creat the 500M of
poly's before render time so this is not done every time a frame is
rendered. Is not speed the real issue.


>
> In any case, NURBS was just an example among others and I'm not
specifically
> advocating NURBS support in POV-Ray. See the FBX interchange file format,
> which gives an idea of what is expected in terms of compatibility :
> http://www.kaydara.com/products/fbx/index.php?filename=techspecs
>
NURBS could be written as a macro. In fact I think someone has been working
on that already. Same with subdivisions.

Post a reply to this message

"Mike Williams" <nos### [at] econymdemoncouk> wrote in message
news:2sWFHEA$bS5$EwIK@econym.demon.co.uk...
> Wasn't it Another Micheal (Mike) Williams who wrote:
>
> >Now a question of my own. Smooth_triangles and 3 norms. Do other programs
> >use Norms at the vertex or is POVRay unique in this aspect. Lightwave
seems
> >to calculate based on a center norm. I have seen where Lightwave fails
and
> >POVRay triumphs because of this difference.
>
> I notice that the OBJ file format associates normals with vertices, so
> any program that uses OBJ files, or any format that's interconvertible
> with OBJ format, would have normals at the vertices.
>
> I don't see how centre normals could work. Surely the normals at the
> centres of the triangles of an icosahedron are exactly the same as the
> normals of a sphere based on the same triangles.

I was not sure how it would work either but I can tell you there is a
differance and that Lightwave shows the Norms as being in the center of the
Poly. If there a lot of long nerrow triangles lightwave will mess up the
smoothing. POVRay gets them perfect. I was only guessing at the idea that it
must be the difference in how each handles Norms.

>
> -- 
> Mike Williams
> (A different one)
It has always amazed me how many "Mike Williams" there are in the world.
Sure makes it hard to feel unique.

Post a reply to this message

news:3fe68802$1@news.povray.org...

> All three rendering systems you mentions (Mentalray, PRman, Mantra) use
> tessellation to map polygons onto the surface of a nurbs just before
> rendering. They actually render the poly's not the nurbs.

Perhaps I'm putting my foot in my mouth here, but isn't this done on-the-fly
and adaptative ? In a car modelled with Rhino for instance, the car body and
the gearshift are both complex objects requiring a lot of polys when seen in
close-ups. However, they may not need the same number of polys depending on
the view of the model. In an animation doing a fly over from the exterior of
the car into the interior, I imagine that the renderer would "decide" on the
optimal number of polys, depending on what objects are visible and close to
the camera, thus saving a lot of RAM.

> In fact it
> would seem faster to have already processesed the NURBS to creat the 500M
of
> poly's before render time so this is not done every time a frame is
> rendered. Is not speed the real issue.

I don't know. Possibly tesselating NURBS and rendering the polys is faster
than rendering them in a native form.

G.


-- 

**********************
http://www.oyonale.com
**********************
- Graphic experiments
- POV-Ray and Poser computer images
- Posters

Post a reply to this message

On Mon, 22 Dec 2003 00:06:36 -0600, "Micheal \(Mike\) Williams"
<mic### [at] quixnetnet> wrote:
> NURBS could be written as a macro. In fact I think someone has been working
> on that already.

See Tor's posts at http://news.povray.org/search/?s=nurbs

ABX

Post a reply to this message

ABX wrote:
> On Mon, 22 Dec 2003 00:06:36 -0600, "Micheal \(Mike\) Williams"
> <mic### [at] quixnetnet> wrote:
> 
>>NURBS could be written as a macro. In fact I think someone has been working
>>on that already.
> 
> 
> See Tor's posts at http://news.povray.org/search/?s=nurbs
> 
> ABX

I do not know if I have understood it.  Then you think that Pov-Ray is 
not a good tool for the professional design 3D? (Images,Animations,Movies).

Post a reply to this message