POV-Ray : Newsgroups : povray.general : POV-Ray just doesn't fit in a production workflow : Re: POV-Ray just doesn't fit in a production workflow Server Time
3 Aug 2024 22:16:15 EDT (-0400)
  Re: POV-Ray just doesn't fit in a production workflow  
From: Micheal (Mike) Williams
Date: 22 Dec 2003 00:58:26
Message: <3fe68802$1@news.povray.org>
"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

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.