POV-Ray : Newsgroups : povray.general : POV-Ray just doesn't fit in a production workflow Server Time
3 Aug 2024 22:13:09 EDT (-0400)
  POV-Ray just doesn't fit in a production workflow (Message 21 to 30 of 33)  
<<< Previous 10 Messages Goto Latest 10 Messages Next 3 Messages >>>
From: Gilles Tran
Subject: Re: POV-Ray just doesn't fit in a production workflow
Date: 22 Dec 2003 06:45:13
Message: <3fe6d949$1@news.povray.org>

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

From: ABX
Subject: Re: POV-Ray just doesn't fit in a production workflow
Date: 22 Dec 2003 06:50:14
Message: <ofmduvslridk481imh2tpvstm0otcpqpej@4ax.com>
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

From: Giuseppe Luigi Punzi
Subject: Re: POV-Ray just doesn't fit in a production workflow
Date: 22 Dec 2003 07:45:44
Message: <3fe6e778$1@news.povray.org>
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

From: Gilles Tran
Subject: Re: POV-Ray just doesn't fit in a production workflow
Date: 22 Dec 2003 08:27:24
Message: <3fe6f13c$1@news.povray.org>

news:web.3fe65e6134356787611ee4e60@news.povray.org...
> 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.

One issue is that there are not many free/unexpensive modellers that
supports NURBS (I see that Nurbana is being integrated in the Blender code
though), so that having native NURBS support in POV-Ray would be useful only
to the smart people who can code them in SDL or to those who have Rhino and
other expensive tools. Of course, macros can do the trick, but frankly, a
GUI is best suited for this (and even with a GUI it's no so easy). On the
other hand, this could encourage developers of free/unexpensive modellers
(such as Moray) to include them. After all, bezier patches have been
supported by Moray, sPatch and all for a long time.

G.

-- 

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


Post a reply to this message

From: ABX
Subject: Re: POV-Ray just doesn't fit in a production workflow
Date: 22 Dec 2003 09:06:49
Message: <kauduvkv6jcp98snamuammugtm7j0ta28f@4ax.com>
On Mon, 22 Dec 2003 13:45:44 +0100, Giuseppe Luigi Punzi <glp### [at] onocom>
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
> 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).

I have no experience in professional design 3D at all so I can't judge but I
think there is nothing to understand in my post :-) I just posted link to
point how NURBS macros mentioned earlier could be found by those not aware
when and how it appeared.

ABX


Post a reply to this message

From: Gilles Tran
Subject: Re: POV-Ray just doesn't fit in a production workflow
Date: 22 Dec 2003 15:12:15
Message: <3fe7501f$1@news.povray.org>

news:3fe6e778$1@news.povray.org...
>
> 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).

Unfortunately, most of us do not have much experience there.

For what it's worth, here's an account of an entire professional project, in
this case an animation sequence for Canon (about photo lenses) created with
Rhino, Cinema 4D, Photoshop, Illustrator and others:
http://home.t-online.de/home/abdul_alhazred/Desireable%20Objects.doc (MS
Word file, sorry).

It gives a good idea (I guess) of what is involved in relatively simple
professional production (5 months though) and of the problems people have to
face. The example is interesting because nothing there seems to be
impossible to do with POV-Ray.

Modelling: POV-Ray' lenses are perfect since mathematically defined. The
casings, however, have lots of filleted edges and organic-looking parts so
they would require an external modeller like Rhino. In POV-Ray, the same
work would involve trial and error and result in a complex mix of
slow-rendering isosurfaces, beziers, lathes and regular CSG: lots of fun for
SDL lovers, but not for people with a deadline. Also, some unwanted
compromises with reality would be necessary: a CAD modeller, on the other
hand, would result in the exact representation of the original object and we
can note that they didn't use C4D's own modeller as it doesn't offer the
same amount of control as Rhino does.
Even going the mesh way, some of the illumination artifacts issues that
POV-Ray has with meshes could be a problem: they can be brushed off on
stills, but not in an animation. Note that C4D does only marginally better
here: it fixes some NURBS conversion problems and doesn't have artifact
issues, but it doesn't import Rhino Nurbs natively.

Texturing: it looks like most of the work could be done easily with POV-Ray.
I'm wondering about the Oren Nayar bit but I guess a good enough
approximation would be OK. Some of the stuff mentioned (Fresnel,
angle-dependent reflection) is native to POV-Ray. Pasting on labels can be
done without a GUI, including with text objets in POV-Ray, but there are
many of them and it's a lot of trial and error to get right: a GUI would
make this much much much faster, even if it means using Illustrator and
Photoshop. Playing with uv-mapping will require an external utility anyway.

Animation: it seems to be only non-flexible, non-articulated objects so
that's quite straightforward in POV-Ray. However, the text mentions a lot of
spline control (F-curves) and that would be faster to handle with a GUI. In
POV-Ray, the animator would have to re-render the animation again and again
and create a movie to see the changes. With a GUI it's just a matter of
moving the animation slider to and fro and see how the spline changes affect
the animation (I don't know how Moray handles animation though).

Rendering : as the main objects of the animation are lenses, it would depend
on how fast POV-Ray would manage those (refraction, particularly) vs Cinema
4D and I haven't run comparisons on this yet. Also, we don't know what sort
of non-raytracing effects were applied: if they used focal blur, the "fake"
one in C4D (similar to the one in the former Megapov) is much faster than
the "true" one in POV-Ray and more suited to animation. The same effect can
be obtained in regular POV-Ray using gradients and post-processing, but it's
not a streamlined procedure. Ditto for faked volumetrics and faked soft
shadows, which are fast and easy to set up in commercial packages.

The distributed rendering could be done with a POV-Ray patch (if not using
caustics and radiosity).

Post-processing : could be handled from the POV-Ray output as it's only the
image files with an alpha channel (nothing fancy here).

G.

-- 

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


Post a reply to this message

From: Patrick Elliott
Subject: Re: POV-Ray just doesn't fit in a production workflow
Date: 22 Dec 2003 21:52:02
Message: <MPG.1a51591f9e12b49d989959@news.povray.org>
In article <3fe6f13c$1@news.povray.org>, tra### [at] inapginrafr says...

> news:web.3fe65e6134356787611ee4e60@news.povray.org...
> > 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.
> 
> One issue is that there are not many free/unexpensive modellers that
> supports NURBS

Considering the wide range of programs people do use with POV-Ray, 
including Poser that are not exactly free, is this really an issue. I 
would prefer some support for things found in expensive programs frankly. 
I would much rather, if forced to buy something, buy one program that has 
all (or most) of the features needed, instead of the usually method of 
trying to find 50 different cheap of free programs that all do one thing 
fairly good (though not always as well as needed), but can't do anything 
else worth shit. NURBS is one of those things I have tried to fiddle with 
and wish was supported in some native fashion.

-- 
void main () {

    call functional_code()
  else
    call crash_windows();
}


Post a reply to this message

From: Giuseppe Luigi Punzi
Subject: Re: POV-Ray just doesn't fit in a production workflow
Date: 23 Dec 2003 04:36:53
Message: <Xns945A6BFADC382lordzealon@204.213.191.226>
"Gilles Tran" <tra### [at] inapginrafr> wrote in
news:3fe7501f$1@news.povray.org: 


> news:3fe6e778$1@news.povray.org...
>>
>> 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).
> 
> Unfortunately, most of us do not have much experience there.
> 
> For what it's worth, here's an account of an entire professional
> project, in this case an animation sequence for Canon (about photo
> lenses) created with Rhino, Cinema 4D, Photoshop, Illustrator and
> others: 
> http://home.t-online.de/home/abdul_alhazred/Desireable%20Objects.doc
> (MS Word file, sorry).
> 
> It gives a good idea (I guess) of what is involved in relatively
> simple professional production (5 months though) and of the problems
> people have to face. The example is interesting because nothing there
> seems to be impossible to do with POV-Ray.
> 
> Modelling: POV-Ray' lenses are perfect since mathematically defined.
> The casings, however, have lots of filleted edges and organic-looking
> parts so they would require an external modeller like Rhino. In
> POV-Ray, the same work would involve trial and error and result in a
> complex mix of slow-rendering isosurfaces, beziers, lathes and regular
> CSG: lots of fun for SDL lovers, but not for people with a deadline.
> Also, some unwanted compromises with reality would be necessary: a CAD
> modeller, on the other hand, would result in the exact representation
> of the original object and we can note that they didn't use C4D's own
> modeller as it doesn't offer the same amount of control as Rhino does.
> Even going the mesh way, some of the illumination artifacts issues
> that POV-Ray has with meshes could be a problem: they can be brushed
> off on stills, but not in an animation. Note that C4D does only
> marginally better here: it fixes some NURBS conversion problems and
> doesn't have artifact issues, but it doesn't import Rhino Nurbs
> natively. 
> 
> Texturing: it looks like most of the work could be done easily with
> POV-Ray. I'm wondering about the Oren Nayar bit but I guess a good
> enough approximation would be OK. Some of the stuff mentioned
> (Fresnel, angle-dependent reflection) is native to POV-Ray. Pasting on
> labels can be done without a GUI, including with text objets in
> POV-Ray, but there are many of them and it's a lot of trial and error
> to get right: a GUI would make this much much much faster, even if it
> means using Illustrator and Photoshop. Playing with uv-mapping will
> require an external utility anyway. 
> 
> Animation: it seems to be only non-flexible, non-articulated objects
> so that's quite straightforward in POV-Ray. However, the text mentions
> a lot of spline control (F-curves) and that would be faster to handle
> with a GUI. In POV-Ray, the animator would have to re-render the
> animation again and again and create a movie to see the changes. With
> a GUI it's just a matter of moving the animation slider to and fro and
> see how the spline changes affect the animation (I don't know how
> Moray handles animation though). 
> 
> Rendering : as the main objects of the animation are lenses, it would
> depend on how fast POV-Ray would manage those (refraction,
> particularly) vs Cinema 4D and I haven't run comparisons on this yet.
> Also, we don't know what sort of non-raytracing effects were applied:
> if they used focal blur, the "fake" one in C4D (similar to the one in
> the former Megapov) is much faster than the "true" one in POV-Ray and
> more suited to animation. The same effect can be obtained in regular
> POV-Ray using gradients and post-processing, but it's not a
> streamlined procedure. Ditto for faked volumetrics and faked soft 
> shadows, which are fast and easy to set up in commercial packages. 
> 
> The distributed rendering could be done with a POV-Ray patch (if not
> using caustics and radiosity).
> 
> Post-processing : could be handled from the POV-Ray output as it's
> only the image files with an alpha channel (nothing fancy here).
> 
> G.
> 

Ok, but you can use Blender with PovAnim. Blender is a great 3D Software 
and with PovAnim you can export the "scene" (and animation) of blender 
to povray, then with povray add some details and render.


Post a reply to this message

From: Fabien Mosen
Subject: Re: POV-Ray just doesn't fit in a production workflow
Date: 23 Dec 2003 13:20:20
Message: <3fe88764$1@news.povray.org>
Giuseppe Luigi Punzi wrote:

> Ok, but you can use Blender with PovAnim. Blender is a great 3D Software 
> and with PovAnim you can export the "scene" (and animation) of blender 
> to povray, then with povray add some details and render.

And you call that "streamlined" ?

Gilles is right, and, anyway, POV-Ray was never intended to be used in
production.  Of course, some "production" features could be of great
benefit (separate "layer" outputs, nurbs, subdivision surfaces,
displacement...), but you should realise that POV-Ray has it's own
"personality", and don't try to make it compete with commercial
products.

Fabien.


Post a reply to this message

From: Christopher James Huff
Subject: Re: POV-Ray just doesn't fit in a production workflow
Date: 27 Dec 2003 21:36:28
Message: <cjameshuff-A6FAF0.21363527122003@netplex.aussie.org>
In article <3fe68984$1@news.povray.org>,
 "Micheal \(Mike\) Williams" <mic### [at] quixnetnet> wrote:

> 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.

It may just be that LW just calculates the vertex normals from the face 
normals...to do otherwise would seem to be a lot of work for little or 
no reward.


> 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.

Vertex normals aren't perfect in all situations either. Consider a cone 
formed of a fan of triangles. Each triangle has only one vertex at the 
point of the cone. You will have as many normals as triangles at that 
point, and no interpolation between them...

-- 
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

<<< Previous 10 Messages Goto Latest 10 Messages Next 3 Messages >>>

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