Just what it is brute-force rendering? an inverse raytracing? (following 
the light ray from the light source?)

The following my sound childish, even ridiculous but... screw you 
Indigo! Long live POV-Ray! THE BEST RENDERER EVR!!!

I warned you, didn't I? :D

Post a reply to this message

On a second thought... *sighs* yeah Indigo renders pretty realistic 
scenes maybe as good or even better tha POV-Ray...... O.O! Just what did 
I said?! just shoot me!! :)

Post a reply to this message

"Saul Luizaga" <sau### [at] netscapenet> wrote in message 
news:4797e672@news.povray.org...
> On a second thought... *sighs* yeah Indigo renders pretty realistic scenes 
> maybe as good or even better tha POV-Ray...... O.O! Just what did I said?! 
> just shoot me!! :)

take a look at the rendertimes on those images before you let someone shoot 
you :)

Post a reply to this message

Once again: All classic features should be availible in PovRay 4.
The decision of choosing the algorithm is up to the user.

Every discussion about the time of rendering is mean less: A look of the Indigo
side shows everyone, that there ARE people who like to wait the time its needed
for the image.

Now one has to wait longer then he like to. Just turn back to classic algorithm
if you like to.

-holger-

Post a reply to this message

> Once again: All classic features should be availible in PovRay 4.
> The decision of choosing the algorithm is up to the user.
>
> Every discussion about the time of rendering is mean less: A look of the 
> Indigo
> side shows everyone, that there ARE people who like to wait the time its 
> needed
> for the image.

I'm sure several years, or even decades, ago, people were waiting the same 
times for POV to render.

Post a reply to this message

"scott" <sco### [at] laptopcom> wrote:
> I'm sure several years, or even decades, ago, people were waiting the same
> times for POV to render.

yes, but the difference is that at the time there was no other option to obtain
very detailed and realistic results.  Both photon mapping and radiosity
generate are capable of delivering very realistic and accurate results without
the huge performance penalties associated with the bruteforce methods...

Post a reply to this message

nemesis skribis:
> yes, but the difference is that at the time there was no other option to obtain
> very detailed and realistic results.  Both photon mapping and radiosity
> generate are capable of delivering very realistic and accurate results without
> the huge performance penalties associated with the bruteforce methods...

But let us not forget that the _are_ things that povray is unable to render.
Imagine a room with a window. The window will act as a light source, making the
objects in the room cast shadows and generate caustics. Even if no direct
sunlight passes through the window. Radiosity can make the window illuminate
the room, but cannot generate (decent) shadows.

One could also imagine two walls that appear to have the same colour under a
broad-spectrum white light (such as an incandescent bulb), but have different
colours when observed under an emmissive-spectrum light (such as an LED). Such
effects would require a renderer to maintain hundreds of wavelengths instead of
just the three colours, and AFAIK no renderer can do this. (Still, it would be
cool if povray were the first.)

Long story short: realism is subjective. When the film Tron came out it had
amazing CGI. Nowadays we think it has very bad CGI. Today we think povray 3.6
generates amazing CGI. In ten years, http://xkcd.com/338/

Hymyly.
And there was light.

Post a reply to this message

"Hymyly" <chr### [at] hotmailcom> wrote:
> Radiosity can make the window illuminate
> the room, but cannot generate (decent) shadows.

funny you say that.  I recently was testing radiosity and meshes and the image
bellow is radiosity-only:  2 very bright ambient objects above providing the
"light".  The ground shadow is very much smoother than one generated by
area_lights in another test.  The shading in the body, though, seems to suffers
a bit.  I don't know if radiosity has some trouble with meshes...

Post a reply to this message

Attachments:
Download 'bunny-wip2.jpg' (19 KB)

Preview of image 'bunny-wip2.jpg'

nemesisskribis:
> funny you say that.  I recently was testing radiosity and meshes and the image
> bellow is radiosity-only:  2 very bright ambient objects above providing the
> "light".  The ground shadow is very much smoother than one generated by
> area_lights in another test.  The shading in the body, though, seems to suffers
> a bit.  I don't know if radiosity has some trouble with meshes...

Wow. I have tried the same, but even with crazy high settings (count 1600,
error_bound 0.001, etc) the best I have managed to render was a slightly
grayish patch behind my obstacles. (And long rendering times, of course.) Could
you perhaps show me the code, please? I have tried for quite long to achieve
these effects.

Still, my previous statement remains valid: there are things that povray cannot
render. And there are things that no rendering software can render (yet).

Hymyly.
And there was light.

Post a reply to this message

there you go.  You can find the bunny model in my scene 
radiosity_and_bunnies.  I posted the source in 
povray.binaries.scene-files...

You know, ridiculously low error_bound values don't really help much. 
Fiddling with lower pretrace steps gives far better results IMO...


#local HQ = 0;
#local GI = 1;
#local GIgather = 0;
#local CAD = 0;
#local CAMS = 1;

#if (GI)
#local LF = .5;
#else
#local LF = 1.1;
#end

global_settings {
    #if (GI)
    radiosity {
        brightness 1.2
        always_sample no
        #if (!GIgather)
            load_file "bunny.rca"
        #else
            save_file "bunny.rca"
            #if (HQ)
            count 200*4 //1400
            error_bound .2
            low_error_factor .2
            adc_bailout .01/.4
            nearest_count 14
            recursion_limit 3
            #else
            count 80*10
            error_bound .2
            adc_bailout .01/.7
            low_error_factor .2
            nearest_count 18
            recursion_limit 3
            #end
        #end

        pretrace_start .04
        pretrace_end .006
        gray_threshold .7
    }
    #else
    ambient_light 1.4
    #end
}


background { rgb 0 }


union {
    plane { y, 0 pigment { rgb 1 } finish {ambient 0} }
    #if (0)
    sphere {y*.7,.7 
        texture {
            //pigment {rgb 1} 
                pigment{ marble turbulence 1.2 octaves 5 lambda 4 scale 
1.4 color_map {[0 rgb 1][.7 rgb 1][.77 rgb .8][1 rgb .6]} }
            finish {ambient 0 diffuse .62}
        }
    }
    #else
    object {#include "meshstandford_bunny.inc" scale 10 rotate -y*120 
translate -y*.08 }
    #end
    #if (!GI)
    light_source { 20*(4-z*8) .8
        #if (HQ)
        area_light x*50,z*50,18,18 jitter adaptive 0 circular orient
        #end
    }
    light_source { 20*(4-z*4) .8
        #if (HQ)
        area_light x*60,y*60,18,18 jitter adaptive 0 circular orient
        #end
    }
    #else
    box { -30, 30 translate 20*(4-z*8) pigment {rgb 1} finish { ambient 9 
diffuse .8 } }
    box { -30, 30 translate 20*(4-z*4) pigment {rgb 1} finish { ambient 9 
diffuse .8 } }
    #end
 
    rotate -y*50
    rotate -x*20
    translate z*3-y/2
}

#if (!GI)
light_source { -z*2+y/3+x .56 shadowless }
#end

camera { aperture .2 blur_samples 40 focal_point y*.15+z*2.2 }

Post a reply to this message

Attachments:
Download 'us-ascii' (7 KB)