Gilles said in the other thread that povray was not suitable for the
production workflow of a movie studio.

I guess I don't understand.  Couldn't you simply code-up a situation that
would be suitable?  For example, in my animations right now, I have separate
include files for each character's motion, texturing, and physical
construction.   Couldn't I hire two character animators to work on the
movement of each character in a scene,  a 3D'er to do the texturing of
costumes, and a modeller to build each character,  another to work on the
set and its lighting.   At the end of every day, I collect the latest draft
of the *.INC files they've been assigned to work on, and do a 320x240 render
overnight.   On weekends, I might do a fullscreen render.    That's sort of
how I do it now, 'cept there's one employee working on non-cash contests.

Post a reply to this message

"Greg M. Johnson" <gregj;-)565### [at] aolcom> a écrit dans le message de
news:3fe3c4b0@news.povray.org...
>
> I guess I don't understand.  Couldn't you simply code-up a situation that
> would be suitable?

In short: POV-Ray doesn't "talk" natively to other products.
1) Your modelers, animators, texturers won't be able to have their fine work
correctly and fluently translated in POV-Ray. For instance:
- models will have to be exported as polygon meshes, losing for example
NURBS information. In fact, in my experience, even translation from external
geometry to POV-Ray mesh is far from streamlined.
- shaders will have to be translated into POV-Ray materials, something that
is presently possible only for a limited subset of them.
- more generally, no development platform (where everything is put together
for rendering) can "feed" directly its data to POV-Ray so you're going lose
a lot in the translation process, including time and money.
2) Your post-process and special effects people won't be able to work on the
rendered movie because POV-Ray's output is "flat" and doesn't have separate
layers that can be processed and tweaked independently, for instance in
Adobe After Effects.
These are just examples: there are many other issues to consider such as
rendering speed, availability of POV-savvy graphic artists, tech support
etc.
Surely, POV-Ray can be morphed, through heavy coding, into something
suitable for a particular project. Some people have done this for scientific
purpose IIRC. In fact, it is already suitable for a vast number of
non-hobbyist projects (see my other post) and POV-Ray has de facto its own
niche market. However, given the vast choice of production-ready renderers
out there, there's no much point in using POV-Ray for this particular job in
a commercial environment. POV-Ray-made animations and the IMP project are,
of course, extremely cool, but this is not what we're talking about here.

G.

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

Post a reply to this message

"Gilles Tran" <gitran_nospam_@wanadoo.fr> wrote in
news:3fe42e50$1@news.povray.org: 


> POV-Ray-made animations and the IMP project are, of course, extremely
> cool, but this is not what we're talking about here. 
> 

That's because they are for fun, and don't have deadlines.  Every 
professional that I talk to, is always talking about the ever shortening 
turnaround times for productions(IMHO, Art shouldn't give you ulcers).  If 
you need it quick, POV-Ray is not the answer.


-- 
Tom
_________________________________
The Internet Movie Project
http://www.imp.org/

Post a reply to this message

> If  you need it quick, POV-Ray is not the answer.

That's probably true. But I think, that I learn more by working with
POV-Ray. I learn things, that I probably wouldn't learn if I was hired by a
company to make something as fast as possible. Many such people are
excellent artists that can draw by hand. But they aren't technical geniuses.
There seems to be an endless amount of scientific information that I find
extremely interesting (except when it requires a high skill in math). It
isn't necessary information from an artistic point of view, but I do think
it helps. I always prefer to take control of every aspect of a scene,
instead of leaving it to an automated, predefined process that I don't
understand.

Regards,
Hugo

Post a reply to this message

"Hugo Asm" <hua### [at] post3teledk> wrote in
news:3fe47505$1@news.povray.org: 

> That's probably true. But I think, that I learn more by working with
> POV-Ray. I learn things, that I probably wouldn't learn if I was hired
> by a company to make something as fast as possible. 

You are preaching to the choir ;)


> Many such people are excellent artists that can draw by hand. But
> they aren't technical geniuses. 
> 

Many(but not most) of the folks in the "industry" that I have met were an 
interesting blend of artistic and technical.  Where they fit into the 
production pipeline determines the skillsets they need.  Take a look at 
three current openings at Blue Sky Studios to see what I mean.

http://www.blueskystudios.com/jobs/ads/rnd.html
http://www.blueskystudios.com/jobs/ads/td_lighting.html
http://www.blueskystudios.com/jobs/ads/character_animator.html

The decision criteria of what tool to use is ultimately economic.  What 
is the return on investment? Maya, Adobe, Avid and others are pervasive 
because they reduce production costs, and often provide a competitive 
edge in product quality.  Simple as that.  In most cases, POV-Ray would 
be a very expensive tool to use.







-- 
Tom
_________________________________
The Internet Movie Project
http://www.imp.org/

Post a reply to this message

POV has its strengths and weaknesses. One of POV's strengths is that it is a
very good tool to use to learn about math, and programming. One of POV's
greatest weaknesses is that it doesnt export to other renderers or modelers.
When we learn POV, we must invest a lot of time and energy into learning the
program. Once we learn the program, we can do some powerful and gratifying
things with it. However, currently, the things we make with POV can only be
rendered with the POV raytracer. I think there may be many POV users out
there who would like to take the investment of time and energy that they
made in learning POV, and use it to make or help make large or important
projects, such as commercial movies, scientific documentaries, etc. In order
to do this, I believe that POV must be able to export to commercial
rendering, modelling, and animation packages. For me, this would be one of
the most important wish list features for a new version of POV.


In the mean time, I have been experimenting with writing a set of POV
macros, which export a few basic shapes to .OBJ file format. Initial results
are encouraging. I submitted a drawing to the IRTC, where all the models
were made with POV macros, and the scene was rendered with my favorite
renderer, Vue d'Esprit 4.

If a new version of POV could export models, (and even textures), to other
renderers and modellers, this would open up POV to a much wider world of CG.
This might also make POV much more important and well known in the CG
community.
It would also be gratifying to those who struggle hard to learn POV, that
their knowledge of POV could be well used and appreciated by the wider CG
community.

Maybe this post would be more appropriate in another thread, but it seemed
relevant here also.


sinc.

Nathen Watson

Post a reply to this message

"Gilles Tran" <gitran_nospam_@wanadoo.fr> wrote in message
news:3fe42e50$1@news.povray.org...
>
> In short: POV-Ray doesn't "talk" natively to other products.
> 1) Your modelers, animators, texturers won't be able to have
>  their fine work correctly and fluently translated in POV-Ray.
>

I suppose I was suffering from a myopia that if I have done some modelling
in povray blobs, everyone ought to be able to do it professionally. and a
blind optimism that one day someone will make a boning sytem for bicubic
patches that can be easily handled in povray.

> These are just examples: there are many other issues to consider
> such as rendering speed, availability of POV-savvy graphic artists,
> tech support etc.
>

So where's 4.0 headed?  Will the future development process for povray
simply involve introduction of new MegaPov features, or will it ever get to
a much faster rendering engine?  (Hey, I'm not disparaging its rendering
speed or demanding a feature request: I don't even know enough about the
engine to know whether a manyear of volunteer effort could make "povray" a
faster renderer.)

Post a reply to this message

> So where's 4.0 headed?  Will the future development process for povray
> simply involve introduction of new MegaPov features, or will it ever get
to
> a much faster rendering engine?  (Hey, I'm not disparaging its rendering
> speed or demanding a feature request: I don't even know enough about the
> engine to know whether a manyear of volunteer effort could make "povray" a
> faster renderer.)

What I've read on these groups so far seems to suggest that POV-Ray 4 will
be more flexible on the "modding" side, for example stuff like *real*
plug-ins, not just include-files. The new number shows that it'll be a
complete rewrite, and if I recall correctly, there were numerous times when
someone mentioned that the new texturing model in 4 might be completely
different from what we have today, to make room for a much more flexible
texturing. Making POV-Ray faster might be nice, though I don't really know
how that could be achieved. To me, it seems like the way things are done
right now are as efficient as they can get with this model (bounding boxes,
vista buffers, light buffers, etc), and I don't really expect a speed-up,
though maybe certain aspect might be made faster (media, isosurfaces, but I
don't know what I'm talking about here, I just know that they're slow most
of the time :-).
Notice though that I do not speak for the POV-Team and these are just my
thoughts and things I believe to remember, maybe I'm completely wrong (aside
the fact that 4 is a rewrite, duh! :-).

Anyways, I do think the POV-Team does lurk around and not only listen to
these newsgroups, but keep an eye on other software as well. And the ones
doing the programming are very likely the ones having discussions about what
to do with what feature, how to change it or if to leave it out for
something completely new. I trust their expertise and experience. As far as
I'm concerned: as long as POV-Ray is as stable as it is now, I can't
complain. Some guru will come along and add the next feature I need. :-)

Regards,
Tim

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

Post a reply to this message

In article <3fe4d404$1@news.povray.org>, "Greg M. Johnson" <gregj;-
)565### [at] aolcom> says...
> 
> "Gilles Tran" <gitran_nospam_@wanadoo.fr> wrote in message
> news:3fe42e50$1@news.povray.org...
> >
> > In short: POV-Ray doesn't "talk" natively to other products.
> > 1) Your modelers, animators, texturers won't be able to have
> >  their fine work correctly and fluently translated in POV-Ray.
> >
> 
> I suppose I was suffering from a myopia that if I have done some modelling
> in povray blobs, everyone ought to be able to do it professionally. and a
> blind optimism that one day someone will make a boning sytem for bicubic
> patches that can be easily handled in povray.
> 
> > These are just examples: there are many other issues to consider
> > such as rendering speed, availability of POV-savvy graphic artists,
> > tech support etc.
> >
> 
> So where's 4.0 headed?  Will the future development process for povray
> simply involve introduction of new MegaPov features, or will it ever get to
> a much faster rendering engine?  (Hey, I'm not disparaging its rendering
> speed or demanding a feature request: I don't even know enough about the
> engine to know whether a manyear of volunteer effort could make "povray" a
> faster renderer.)
> 
> 
Someone is currently in the process of converting a patch to C (so it can 
be used in the current versions) that seems to have to potential to make 
*major*, lets repeat that, *major* speed increases with scenes that have 
large amounts of CSG. This would probably produce minimal speed ups for 
most scenes that only have a few dozen objects and minimal CSG, but for a 
large scale project it will make a lot of difference. One example is a 
project called POV-City. While I haven't heard much about it for a while, 
it would have used lots of user created SDLs to generate the layout of a 
city when viewed from various places. This would have been 100% certain 
to exceed the small number of CSG used in the average scene. Same with 
anything else that someone wanted to do which required any significant 
scale and number of objects.

There are bound to be additional speed improvements and things get 
cleaned up or better methods are found. A lot of fine tuning will still 
probably be done 'after' the first V4.0 design though, but it will almost 
certainly end up being faster right from the beginning.

-- 
void main () {
  If Schrödingers_cat is alive  
    call functional_code()
  else
    call crash_windows();
}

Post a reply to this message

Tim Nikias v2.0 wrote:
> though maybe certain aspect might be made faster (media, isosurfaces, but I
> don't know what I'm talking about here, I just know that they're slow most
> of the time :-).

Well, with version 3.5, the adding of method 3 gives an enormous
speed and quality boost to media...^_^

Post a reply to this message

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

> What I've read on these groups so far seems to suggest that POV-Ray 4 will
> be more flexible on the "modding" side, for example stuff like *real*
> plug-ins, not just include-files.

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. 
This will not change when POV 4.0 is released. It would be possible to 
load platform-independent bytecode files like Java does, but there's no 
real reason to do so...you might as well just generate the bytecodes 
from source, and loading precompiled bytecode would not add any 
capability. It would be slightly faster, but source compiling won't be a 
speed bottleneck like scene parsing currently is...and even now, only 
include files that do heavy processing cause any slowdown.


> The new number shows that it'll be a complete rewrite,

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.


> and if I recall correctly, there were numerous times when
> someone mentioned that the new texturing model in 4 might be completely
> different from what we have today, to make room for a much more flexible
> texturing.

Any redesign and rewrite of the code will make it far easier to add this 
sort of thing.


> Making POV-Ray faster might be nice, though I don't really know
> how that could be achieved. To me, it seems like the way things are done
> right now are as efficient as they can get with this model (bounding boxes,
> vista buffers, light buffers, etc), and I don't really expect a speed-up,
> though maybe certain aspect might be made faster (media, isosurfaces, but I
> don't know what I'm talking about here, I just know that they're slow most
> of the time :-).

There are some changes that can be made. Better bounding systems, 
cleaning up of some of the current hacks...multi-processor systems are 
becoming more common, support for multi-thread rendering would give a 
big speedup on those machines.


> As far as
> I'm concerned: as long as POV-Ray is as stable as it is now, I can't
> complain. Some guru will come along and add the next feature I need. :-)

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?

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

Here is just an example of POVRay being used in the real world to produce
Graphic Design. I got a project where a small company needed illustrations
of a prototype but in final production stage. The final design of the
product was not fully decided. This meant I would build one illustration and
present it. After evaluation of the model I would receive a list of changed.
Like whether the threaded lid should go on the outside or if it should go on
the inside of the body of the product. There was a group of drain spicket's
that got moved from on end of the product to the other and back again. With
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.



It sounds to me from reading this thread and my own experience that it is
not really the render engine that makes POVRay so powerful. It is the SDL.
Those that are embedded in the shader method of texturing clash with
POVRay's method. Yes the SDL could be updated to add more control over the
textures but one could still do anything in POVRay now that is done in any
other program. It just takes learning and spending time coding. Perhaps
someone could write another engine that used the SDL but in a different way.
Just like all those renderman compliant renderers. The POV SDL is a
standard.



And on a side note there is not IIRC a rendering engine that renders NURBS
directly. 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.



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.



"Greg M. Johnson" <gregj;-)565### [at] aolcom> wrote in message
news:3fe3c4b0@news.povray.org...
> Gilles said in the other thread that povray was not suitable for the
> production workflow of a movie studio.
>
> I guess I don't understand.  Couldn't you simply code-up a situation that
> would be suitable?  For example, in my animations right now, I have
separate
> include files for each character's motion, texturing, and physical
> construction.   Couldn't I hire two character animators to work on the
> movement of each character in a scene,  a 3D'er to do the texturing of
> costumes, and a modeller to build each character,  another to work on the
> set and its lighting.   At the end of every day, I collect the latest
draft
> of the *.INC files they've been assigned to work on, and do a 320x240
render
> overnight.   On weekends, I might do a fullscreen render.    That's sort
of
> how I do it now, 'cept there's one employee working on non-cash contests.
>
>

Post a reply to this message

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.

-- 
Mike Williams
(A different one)

Post a reply to this message

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

"Micheal (Mike) Williams" <mic### [at] quixnetnet> a écrit dans le message de
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...
>
> "Micheal (Mike) Williams" <mic### [at] quixnetnet> a écrit dans le message de
> 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

"Micheal (Mike) Williams" <mic### [at] quixnetnet> a écrit dans le message de
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

"Andrew Clinton" <ajc### [at] uwaterlooca> a écrit dans le message de
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

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

"Giuseppe Luigi Punzi" <glp### [at] onocom> a écrit dans le message de
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

In article <3fe6f13c$1@news.povray.org>, tra### [at] inapginrafr says...
> "Andrew Clinton" <ajc### [at] uwaterlooca> a écrit dans le message de
> 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 () {
  If Schrödingers_cat is alive  
    call functional_code()
  else
    call crash_windows();
}

Post a reply to this message

"Gilles Tran" <tra### [at] inapginrafr> wrote in
news:3fe7501f$1@news.povray.org: 

> "Giuseppe Luigi Punzi" <glp### [at] onocom> a écrit dans le message de
> 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

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

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

Wasn't it Christopher James Huff who wrote:

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

There's no reason why a mesh can't have several vertices at a single
point in space. Modelling programs split vertices at places where
there's a discontinuity in the normals (like where the side of the cone
meets the base) and the same thing can be done for the apex of the cone. 

If the cone mesh is uv-mapped, then the apex point has to be split into
multiple vertices anyway.

I had a quick look at a cone object generated by Poser5, and it turns
out that the vertices at the point of the cone aren't exactly
coincident. What it appears to so is take a cylinder and shrink one end
until it's *almost* a point. It actually uses 4-sided polygons for the
surface. Each polygon has two vertices on the base and two vertices at
the apex of the cone.

-- 
Mike Williams
Gentleman of Leisure

Post a reply to this message

In article <uCVIPAAGvl7$EwpE@econym.demon.co.uk>,
 Mike Williams <nos### [at] econymdemoncouk> wrote:

> There's no reason why a mesh can't have several vertices at a single
> point in space. Modelling programs split vertices at places where
> there's a discontinuity in the normals (like where the side of the cone
> meets the base) and the same thing can be done for the apex of the cone. 

I don't think you understood what I said. Each triangle has only one 
corner at the point of the cone, and one normal for that point. This 
makes it impossible to properly interpolate the normals. It would need 
for the cone-point vertex of each triangle to have *two* normals, one 
associated with each edge of the triangle, and for normals to be 
interpolated between the edges rather than the corners. Essentially a 
quad with one side zero-length.


> I had a quick look at a cone object generated by Poser5, and it turns
> out that the vertices at the point of the cone aren't exactly
> coincident. What it appears to so is take a cylinder and shrink one end
> until it's *almost* a point. It actually uses 4-sided polygons for the
> surface. Each polygon has two vertices on the base and two vertices at
> the apex of the cone.

Right, that's what you have to do if you want smooth normals on a cone. 
You can still put the point on, if it's small enough that the normal 
transitions are unnoticeable and still large enough to matter, but it 
adds a lot of triangles to the cone for very little benefit.

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

On Tue, 23 Dec 2003 19:22:10 +0100, Fabien Mosen <fab### [at] skynetbe>
wrote:
> POV-Ray was never intended to be used in production.
> [...]
> POV-Ray has it's own "personality"

On the other hand thinking about "production" as "high quality art" and
observing quality of average image nowadays and 5 years ago in
povray.binaries.images I think POV-Ray's personality allows it to be used in
production succesfuly. I can easy imagine book, pictures in art-museum,
decorations and illustartions in newspaper made only with POV-Ray. Every tool
has its masters and its newbies.

ABX

Post a reply to this message