Hi.

I have the following scene:

#version 3.7;

global_settings{ assumed_gamma 1.0 }

camera{
 orthographic
 location <0, 4, 0>
 look_at 0
 sky z
 up 4*z
 right 4*x
}

light_source{ <1, 2, 1>*100000 color srgb 1 }

plane{y, 0 pigment{ color srgb 0.75 } }

cylinder{ <0, 0, 0>, <0, 2, 0>, 0.5 pigment{ color srgb <0.4, 0.2, 0.3> } }

Let's say the z vector/axis is the north direction (the middle finger too) and
the x axis (the west and the thumb of your left hand if I'm not saying any
mistakes ?). With the above code, povray renders me a image with the cylinder
shadow on the plane that goes to the south east. But given the camera settings
and the light_source coordinates, I should have a shadow that is cast to the
south west direction. When I add the following line in the camera block:

direction -4*y

I get the wanted result. I'm sure I'm missing something but I don't know what.
I'm asking your help because I'm a little lost :-(.

Ps: from my point of view, the above camera settings (without the 'direction'
line) should make a camera without any mistaking for povray , I mean povray
shouldn't need to append default settings because it has everything it needs to
make the render ?
Thank you.

Post a reply to this message

Am 25.09.2018 um 19:55 schrieb Warren:

> camera{
>  orthographic
>  location <0, 4, 0>
>  look_at 0
>  sky z
>  up 4*z
>  right 4*x
> }
...

> Ps: from my point of view, the above camera settings (without the 'direction'
> line) should make a camera without any mistaking for povray , I mean povray
> shouldn't need to append default settings because it has everything it needs to
> make the render ?
> Thank you.

Without the `direction`, POV-Ray has no idea whether you want a
left-handed or right-handed coordinate system.

Remember, the `look_at` mechanism works as follows:

(1) POV-Ray first sets up the camera as specified by your `up`, `right`
and `direction` vectors, as if the `look_at` statement wasn't there.
This defines the handedness of the coordinate system, the aspect ratio,
and (depending on camera projection) the zoom (unless you also specify
`angle`).

(2) Once that is done, POV-Ray re-orients the camera (rotating it around
its location) in such a manner that the `look_at` point is in the center
of the image (for most projections at any rate).

So specifying `look_at` is no replacement for specifying `direction`.

Post a reply to this message

> Clipka has wrote:
>
> Without the `direction`, POV-Ray has no idea whether you want a
> left-handed or right-handed coordinate system.
>
> Remember, the `look_at` mechanism works as follows:
>
> (1) POV-Ray first sets up the camera as specified by your `up`, `right`
> and `direction` vectors, as if the `look_at` statement wasn't there.
> This defines the handedness of the coordinate system, the aspect ratio,
> and (depending on camera projection) the zoom (unless you also specify
> `angle`).
>
> (2) Once that is done, POV-Ray re-orients the camera (rotating it around
> its location) in such a manner that the `look_at` point is in the center
> of the image (for most projections at any rate).
>
> So specifying `look_at` is no replacement for specifying `direction`.

Thank you for your answer. I have learned something new with your message :-D.
In fact, most of my knowledge related to POVRay come from the following site :
http://users.skynet.be/bs936509/povfr/index.htm

In this site, they explain lot of things, and even if it is based on POVRay 3.6
it is still relevant but there is no sign of what you explain about the camera
in the appropriate section :-(. And there's nothing about radiosity...
By the way... I'm looking for a tutorial that explains in details how radiosity
works (Or is it to complicated ?). My current skills with the radiosity are the
following:
I render a radiosity scene in two pass, a first render with something like :
+W80
+H50
+RFO
+RF"radio_samp.rad"
Output_To_File=Off
Display=Off

Then a render with
+Wfinal width and +Hfinal height
+RFI
+RF"radio_samp.rad"

Of course, I save lot of time by doing this. I don't know much more about
radiosity and I'd like to know the details of this technique :-D.

Thank you.

Post a reply to this message

"Warren" <nomail@nomail> wrote:

> And there's nothing about radiosity...
> By the way... I'm looking for a tutorial that explains in details how radiosity
> works (Or is it to complicated ?).

http://www.povray.org/documentation/view/3.7.1/270/
http://www.ignorancia.org/wp-content/uploads/zips/rad-save-load.zip
http://www.nolights.de/galleries/povray_reviews/radiosity.html

There are also some sample radiosity scene files in the standard POV-Ray
installation subdirectories, as well as an include file for facilitating
different levels of radiosity {} block settings

#include "rad_def.inc"

Post a reply to this message

Am 26.09.2018 um 11:53 schrieb Warren:

> By the way... I'm looking for a tutorial that explains in details how radiosity
> works (Or is it to complicated ?).

Before I take a long deep breath and then exhale an excessively long
post - are you interested in details how to use it (i.e. which knob to
turn in which situation), or do you genuinely want to know the details
of what's going on under the hood?

> My current skills with the radiosity are the
> following:
> I render a radiosity scene in two pass, a first render with something like :
> +W80
> +H50
> +RFO
> +RF"radio_samp.rad"
> Output_To_File=Off
> Display=Off
> 
> Then a render with
> +Wfinal width and +Hfinal height
> +RFI
> +RF"radio_samp.rad"
> 
> Of course, I save lot of time by doing this.

Mmmm... um... nyyeeeh... I'm not so sure about that. As a matter of
fact, I doubt it.

If you're running the first pass once, and then the main render multiple
times for some reason - then yeah, that'll save time. But why would you
render a scene multiple times without changing the scene? And if you're
changing the scene, you need to re-run the first pass as well.

If however you're running the main render just once, all you're
effectively doing is going through POV-Ray's regular radiosity pre-trace
twice.

At best, this just compensates for a poor choice of pre-trace quality
settings. At worst, your pre-trace quality settings are good enough and
you're letting POV-Ray do pointless extra work.


In older versions (v3.6 and earlier) radiosity had some nasty conceptual
flaws causing artifacts that were difficult to eliminate, and IIRC the
save-restore approach helped avoid at least some of them, so it had its
use back then. But those flaws have been eliminated in v3.7, and from
both a quality and performance standpoint the save-restore approach is
pointless. It only makes sense if you do indeed save once and load
multiple times.


> I don't know much more about
> radiosity and I'd like to know the details of this technique :-D.

Let me know the general direction of your curiosity, and I guess I can
spew out some long-winded mix of useful and useless information about
it. I'm not the original author of the radiosity code, but I gave it a
thorough overhaul for v3.7, and although that's been a while now, I
might actually remember a thing or two about it ;)

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
> Am 26.09.2018 um 11:53 schrieb Warren:
>
> [..]

I take what you say into account , but I must let you know some things :
First, I learned the two pass method with this site : http://www.nolights.de

And In my main scene file (pov file) I have those lines (I put comments to be as
accurate as possible, that wasn't the case in my precedent post, I apologize.
:-(

#version 3.7;

// RadStep is defined in the ini files (rendering configuration)
//If RadStep == 0 : no radiosity
//  RadStep == 1 : radiosity first pass (save radiosity data to file)
//   RadStep == 2 : radiosity second pass (use saved radiosity data from file)

#declare p_start = 64 / Final_Width;//With 1280 as image weight that yields :
0,05
#declare p_end_tune = 8 / Final_Width; //For tuning radiosity (purpose: finding
good values)
#declare p_end_final = 4 / Final_Width;//With 1280 as image weight that yields :
0,003125

//Final_Width could be 'image_width' but for the first pass 'image_width' equals
80 pixels so I pass the Final_Width value '1280' most of the time even for the
first pass

global_settings{ assumed_gamma 1.0
#switch(RadStep )
 #case( 1 )
           //First pass block
  radiosity{
    pretrace_start p_start //0.08 basically
    pretrace_end   p_end_final //0.004 basically
    error_bound 0.1
    minimum_reuse 0.0025
    nearest_count 8
    count 117 //This value could be higher hence a two pass render interest
    recursion_limit 2
    always_sample off
    low_error_factor 1
    gray_threshold 0.6
    brightness 1.25
    normal on
  }
 #break
 #case( 2 )
           //second pass block
  radiosity{
    pretrace_start 1
    pretrace_end   1
    error_bound 0.8
    minimum_reuse 0.0025
    nearest_count 8
    count 117
    recursion_limit 2
    always_sample off
    low_error_factor 1
    gray_threshold 0.6
    brightness 1.25
    normal on
  }
 #break
#end
}

#if( RadStep >= 1 )
    #default{finish{ambient 0} }
#end

-------------------------
I remember some years ago, I rendered the well known scene of Gilles Tran :
'glass' in WIndows 7 in one pass , and with a count of 200 , that took me about
6 days in 1280x1024 or so and then in two pass in Ubuntu 16.04 with this time a
value of count of 400 with the same resolution of 1280x1024 and the same other
radiosity values that took me 5 or 6 hours for the first pass and less than 10
hours for the second pass (I'm sure it took  one day at most for the two pass
renders , and compared with the six days in one pass...).

Now I just wonder if your answer is the same with those informations. :-D.

Post a reply to this message

Am 26.09.2018 um 18:04 schrieb Warren:

> I take what you say into account , but I must let you know some things :
> First, I learned the two pass method with this site : http://www.nolights.de
> 
> And In my main scene file (pov file) I have those lines (I put comments to be as
> accurate as possible, that wasn't the case in my precedent post, I apologize.

Two things I'm noticing about your radiosity settings:

(1) You're turning off the pre-trace almost entirely in your main pass.
That does indeed avoid doing any double work.

(2) Aside from the pretrace settings, the radiosity settings are
identical, with the exception of `error_bound`. You should be able to
achieve the same effect - both quality- and speed-wise - by setting
`low_error_factor` to the ratio of the two values, and using just one
pass with full pretrace.


> -------------------------
> I remember some years ago, I rendered the well known scene of Gilles Tran :
> 'glass' in WIndows 7 in one pass , and with a count of 200 , that took me about
> 6 days in 1280x1024 or so and then in two pass in Ubuntu 16.04 with this time a
> value of count of 400 with the same resolution of 1280x1024 and the same other
> radiosity values that took me 5 or 6 hours for the first pass and less than 10
> hours for the second pass (I'm sure it took  one day at most for the two pass
> renders , and compared with the six days in one pass...).

A different OS makes me wonder whether different hardware was also
involved, and maybe also different versions of POV-Ray. The Ubuntu 16.04
render can't have been much more than 2 years ago, Windows 7 might have
been as much as 9 years ago.

> Now I just wonder if your answer is the same with those informations. :-D.

In general, yes. I can think of a ton of things that may have played a
role - including the possibility that by applying your approach you
might have inadvertently compromised the radiosity quality, or
inadvertently cut short an excessive pre-trace.

I might make some controlled experiments to verify your claims, but for
now I stick to my current understanding of the inner workings of the
radiosity algorithm, according to which there should be no such effect
that couldn't be achieved by other means.


(There /is/ another approach to improve performance via a separate
radiosity pass, which is to replace some complex objects in the scene
with faster-rendering stand-ins; but it comes with its own pitfalls, and
the same effect should be achievable by making use of the `no_radiosity`
and related keywords.)

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
> Am 26.09.2018 um 18:04 schrieb Warren:

> I might make some controlled experiments to verify your claims, but for
> now I stick to my current understanding of the inner workings of the
> radiosity algorithm, according to which there should be no such effect
> that couldn't be achieved by other means.
>

The 2 renders of 'Glass' ; Windows 7(2013-2014)  + Ubuntu 16 (after 2016) were
done on the same CPU architecture, a core i5 2500 in my bedroom I bought in
august 2011. I will try to make a render again during the week end in one pass
if I have enough time to spend. If the render takes more than , let's say 12
hours I will stop the render, to sleep in peace, even if I have a ventirad for
my CPU). Actually, I'm not so sure about the parameters used with the render
under Windows 7, I 'm must say that 6 days is quite long (I have a strong
feeling that rendering 'Glass demo' under 'Windows 7' took at least 6 days). I
know that sometimes the human brain can compose recollections ( 'souvenirs' in
good french ) and you think you lived something or did something in the past but
that that's not true or the memory is altered faking what someone can remember.

So to conclude, you suggest me to not make two-pass rendering anymore but stick
to one simple pass rendering with radiosity, right ?

Post a reply to this message

Am 26.09.2018 um 21:18 schrieb Warren:

> So to conclude, you suggest me to not make two-pass rendering anymore but stick
> to one simple pass rendering with radiosity, right ?

I think you're better off with the standard single-pass procedure in the
long run, yes. The two-pass approach makes things unnecessarily complex
and difficult to understand.

Post a reply to this message