David <smu### [at] ameritechnet> wrote:
: A tar.gz file is a source archive for Linux.

  No, it isn't.

-- 
#macro N(D,I)#if(I<6)cylinder{M()#local D[I]=div(D[I],104);M().5,2pigment{
rgb M()}}N(D,(D[I]>99?I:I+1))#end#end#macro M()<mod(D[I],13)-6,mod(div(D[I
],13),8)-3,10>#end blob{N(array[6]{11117333955,
7382340,3358,3900569407,970,4254934330},0)}//                     - Warp -

Post a reply to this message

Nekar Xenos <j-p### [at] citywalkcoza> wrote:
: Maybe this is a stupid question, but why doesn't Pov use real radiosity?

  There's no such a thing as "real" radiosity.

  There's an algorithm called "radiosity" which calculates the
inter-reflection of light between flat polygons. This algorithm is usable
only if your scene consists of polygons.
  POV-Ray uses a monte-carlo raytracing method in order to calculate
the inter-reflection of light between surfaces. The advantage of this
method is that it works with any object you can raytrace.

  Both methods have their advantages and disadvantages. Usually the first
method is faster but more limited. It's also a bit unoptimized (it has
to be calculated for every surface, even those which are not seen and do
not contribute to the global illumination in any way). And as said, it only
works with polygons.
  The second method is usually slower, but can give as good results as the
first, and even better. AFAIK Radiance uses monte-carlo raytracing for
the radiosity calculations, and its quality is well known.

  The implementation of this in POV-Ray just suffers from some problems
(probably bugs), which makes it problematic in some cases.

-- 
#macro N(D,I)#if(I<6)cylinder{M()#local D[I]=div(D[I],104);M().5,2pigment{
rgb M()}}N(D,(D[I]>99?I:I+1))#end#end#macro M()<mod(D[I],13)-6,mod(div(D[I
],13),8)-3,10>#end blob{N(array[6]{11117333955,
7382340,3358,3900569407,970,4254934330},0)}//                     - Warp -

Post a reply to this message

Warp wrote:
> 
> David <smu### [at] ameritechnet> wrote:
> : A tar.gz file is a source archive for Linux.
> 
>   No, it isn't.

Mostly true.

-- 
Ken Tyler

Post a reply to this message

This is an interesting "our program is better than POV-Ray but it isn't".
Fancy words, but mostly crap.

  "zRcube aims to be more modern than pov, using more recent algorithms."

  This resumes the whole crap: It assumes that POV-Ray is old, that it
uses old algorithms and is not developed anymore.
  What is old in POV-Ray? Take any modern raytracer and its basic algorithms
will be the same as in POV-Ray.
  Moreover, POV-Ray even uses more modern and efficient algorihtms than many
other raytracers (such as LightFlow etc). These include vista buffers, light
buffers, automatic bounding, polynomial objects, adaptive antialiasing and so
on. The upcoming 3.5 will have even more sophisticated features, such as
functions, isosurfaces and photon mapping. Most opimizations in POV-Ray
make it often faster than other raytracers with similar scenes.

  "The idea behind this project is that most of available free
rendering software were designed a long time ago, when computers were
really slower than now, and consequently these engines were a
compromise between rendering quality and speed. But now, our computers
are fast, maybe too fast for what we use them for... I don't care if I
spent 40 seconds or 25 secs for my final rendering if the final result
is better for the longer rendering..."

  The crap continues.
  For some reason they assume that image quality was compromised in order
to get faster rendering. I really don't understand where did they get that
idea.
  What I understand of that paragraph is that they think that the developers
of POV-Ray thought something like "ok, we could do this to look better, but
it would be very slow, so we'll just rip off something from the quality in
order to get more speed". This makes no sense. I would like to hear some
examples of POV-Ray where this kind of compromise was made. Which feature
could look better if we don't worry about the rendering time (and you have
no way of tuning its quality so that you can get the better result)?

  They also have this funny conception that in current computers the
scenes made by people take usually much less than 1 minute to render.
What a crap. You can look at almost any high-quality image (no matter
which renderer) and see how much time it took to render: The render
time of a final rendering is usually several hours, no matter what
computer was used. For example most IRTC images take many hours to
render (often the rendering times can be even several days).
  What they are saying in the paragraph above is "as in current computers
scenes take less than a minute to render, it doesn't matter if it takes
a half minute or one minute". This is crap. If you are making a good-quality
final render, it will usually take hours to render.
  Besides, this has a funny drawback: What they are actually saying is
that their renderer is 1.6 times slower than POV-Ray. This means that
something that takes 1 hour to render with POV-Ray will take more than
1 hour and a half to render with their program. Not too positive. Not
something that encourages you to switch to their program.

  "When we began to think about this project, we first said:
'radiosity is a great algorithm for illumination, it makes no
compromises and the pictures rendered using it are really realistic'.
So we have to use it. Then, one of us said 'But we cannot handle refraction
and reflexion with radiosity, only ray-tracing can do that'."

  I really don't understand why everyone speaks about "radiosity" as if
it was a _rendering_ algorithm. That is, you _render_ a scene with the
"radiosity" algorithm and you get a final image.
  I know how the "radiosity" algorithm works and I have seen how it is
calculated (at mathematical formula level).
  "Radiosity" is _NOT_ a rendering technique. I just don't understand why
everyone speaks about it as if it was.
  What "radiosity" does is to calculate the illumination of the surfaces.
That is, it calculates how a surface (or a point on the surface, depending
on how accurately it is implemented) is illuminated by all the other
surfaces in the scene.
  That is, "radiosity" just calculates illumination values. It does _NOT_
project the surfaces on screen, it does _NOT_ write anything to the screen
(or an image file for that matter). You _DON'T_ get a final image from
the radiosity calculations, just illumination values (for example in
the form of a light map or something similar).
  In order to get the final image from the polygons you have to use a
rendering algorithm. The most viable ones are scanline rendering (which
is the most commonly used) and raytracing (which isn't very rare in
radiosity renderings either).
  That is, the polygons are rendered with scanline rendering or raytracing
and taking into account the lighting values given by the radiosity algorithm.

  (People who talk about "radiosity" as a rendering technique often oppose
it to raytracing, as if they were equal techniques and mutually exclusive.
This is just plain laughable. Radiosity just calculates illumination values;
it couldn't care less what is the actual rendering algorithm used to
draw the polygons on screen; it can be scanline rendering or raytracing;
it doesn't care.)

  I personally think about these kind of people as ignorants. And it seems
that these guys fall into this category.


  By the way, looking at their "complete features" list is quite funny.
  Their "modern" raytracer lacks most of POV-Ray's "old" (and perhaps
obsolete?) features, such as CSG, media, matrix transformations, most
objects, most camera types, normal modifiers, antialiasing and almost every
flow control feature of the POV-Ray SDL (ie. #if, #while, #switch, #macro
and so on).

  Many of those are probably explained with the fact that they probably
use polygons and some things are quite hard to tesselate (eg. CSG).

  Modern my ass.



  PS: Yes, every time someone makes a stupid claim of something being "better"
than POV-Ray, I see red.
  This is not because I think POV-Ray is perfect and the best renderer
possible in every aspect, but it's because I consider it completely stupid
to start comparing different renderers and say that one is better than
the other. Every renderer is good in its own field of expertise and every
renderer is good for certain things. There's no such a thing as a renderer
which is better than another renderer.
  Specially "I have made a renderer better than POV-Ray"-type of people are
extremely irritating.

-- 
#macro N(D,I)#if(I<6)cylinder{M()#local D[I]=div(D[I],104);M().5,2pigment{
rgb M()}}N(D,(D[I]>99?I:I+1))#end#end#macro M()<mod(D[I],13)-6,mod(div(D[I
],13),8)-3,10>#end blob{N(array[6]{11117333955,
7382340,3358,3900569407,970,4254934330},0)}//                     - Warp -

Post a reply to this message

Ken <tyl### [at] pacbellnet> wrote:
:> : A tar.gz file is a source archive for Linux.
:> 
:>   No, it isn't.

: Mostly true.

  I'm sorry about my minimalist and rude answer :)

  Firstly, a .tar.gz has nothing to do with source archives. It's just
a packing format completely equivalent to .zip, .arj or .rar. It couldn't
care less about what's packed inside it. Unix program sources are usually
distributed in this format, but that's just because it's the most common
packing format in Unix; everything else is usually packed with this format
as well. The format itself has nothing to do with sources or anything.
  (If we are pedantic, a .tar.gz file is actually packed with _two_ programs:
first tar and then gzip, although the gtar program supports both at the same
time.)

  Secondly, .tar.gz has nothing to do with Linux. In the same well as .zip
and .rar are universal formats, so is .tar.gz. It's just a system-independent
packing format.
  The fact that it has become popular in the Unix world does not make it
a Linux format.
  (I smell a say-Linux-when-should-say-Unix phenomenon in the original
article as well, which is rather irritating...)

-- 
#macro N(D,I)#if(I<6)cylinder{M()#local D[I]=div(D[I],104);M().5,2pigment{
rgb M()}}N(D,(D[I]>99?I:I+1))#end#end#macro M()<mod(D[I],13)-6,mod(div(D[I
],13),8)-3,10>#end blob{N(array[6]{11117333955,
7382340,3358,3900569407,970,4254934330},0)}//                     - Warp -

Post a reply to this message

>   (People who talk about "radiosity" as a rendering technique often oppose
> it to raytracing, as if they were equal techniques and mutually exclusive.
> This is just plain laughable. Radiosity just calculates illumination values;
> it couldn't care less what is the actual rendering algorithm used to
> draw the polygons on screen; it can be scanline rendering or raytracing;
> it doesn't care.)

Thanks for clearing this for me. I really got quite confused about this by just
looking at their site :-P

Nekar

Post a reply to this message

Only nitpicking... do not take too seriously :-)


Warp wrote:
>   The crap continues.
>   For some reason they assume that image quality was compromised in order
> to get faster rendering. I really don't understand where did they get that
> idea.
>   What I understand of that paragraph is that they think that the developers
> of POV-Ray thought something like "ok, we could do this to look better, but
> it would be very slow, so we'll just rip off something from the quality in
> order to get more speed". This makes no sense. I would like to hear some
> examples of POV-Ray where this kind of compromise was made. Which feature
> could look better if we don't worry about the rendering time (and you have
> no way of tuning its quality so that you can get the better result)?
> 


The 'sturm' keyword is such a case (probably the only one), where the default
choosen was speed against accuracy (it apply to sor, some lathe, blob, cubic,
poly,
some prism and quartic).

Post a reply to this message

>> examples of POV-Ray where this kind of compromise was made. Which feature
>> could look better if we don't worry about the rendering time (and you have
>> no way of tuning its quality so that you can get the better result)?
>> 
>The 'sturm' keyword is such a case (probably the only one), where the default
>choosen was speed against accuracy (it apply to sor, some lathe, blob, cubic,
>poly,
>some prism and quartic).

Likewise media parameters and perhaps the default radiosity parameters.  But
you seem to have ignored the parenthetical part of the question.

-- 
#macro R(L P)sphere{L F}cylinder{L P F}#end#macro P(V)merge{R(z+a z)R(-z a-z)R(a
-z-z-z a+z)torus{1F clipped_by{plane{a 0}}}translate V}#end#macro Z(a F T)merge{
P(z+a)P(z-a)R(-z-z-x a)pigment{rgbt 1}hollow interior{media{emission T}}finish{
reflection.1}}#end Z(-x-x.2y)Z(-x-x.4x)camera{location z*-10rotate x*90}

Post a reply to this message

Warp wrote:
> 
>   They also have this funny conception that in current computers the
> scenes made by people take usually much less than 1 minute to render.
> What a crap. You can look at almost any high-quality image (no matter
> which renderer) and see how much time it took to render: The render
> time of a final rendering is usually several hours, no matter what
> computer was used. For example most IRTC images take many hours to
> render (often the rendering times can be even several days).

My Rusty animations take about twenty minutes per frame for final
rendering, and I generally draw the line at about thirty.  But since
there are usually over a thousand of them in each animation, I have to
draw the line somewhere.

The only ones that take less than a minute are the very dark parts of
the fades...  As for the others, I assume I'm leaving stuff out if
they take less than ten minutes per frame in the final rendering.

Regards,
John
-- 
ICQ: 46085459

Post a reply to this message

In article <3B15F9CD.DB43743C@gmx.de>,
 Christoph Hormann <chr### [at] gmxde> wrote:

> I had a quick look, the program uses gtk and therefore will not be
> compilable straight away with cygwin.

Or OS X...I don't know about any GTK port projects for OS X.
POV-Ray, on the other hand, compiles fine...

-- 
Christopher James Huff - chr### [at] maccom, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tagpovrayorg, http://tag.povray.org/

<><

Post a reply to this message