> 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 () {

    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