Stephen <mca### [at] aolcom> wrote:
> One of the best methods of fault finding (trouble shooting, for those
> west of the Western Isles) is to explain the problem, out loud. It often
> becomes clear. :-D

I'm glad you clarified the terminology.  "Fault finding" has a pejorative
connotation on this side of the pond.  (The trouble with us sharing a universal
language is that it ain't so universal.)

Post a reply to this message

On 31/10/2014 20:14, Cousin Ricky wrote:
> Stephen <mca### [at] aolcom> wrote:
>> One of the best methods of fault finding (trouble shooting, for those
>> west of the Western Isles) is to explain the problem, out loud. It often
>> becomes clear. :-D
>
> I'm glad you clarified the terminology.  "Fault finding" has a pejorative
> connotation on this side of the pond.  (The trouble with us sharing a universal
> language is that it ain't so universal.)
>
>
I know, I had that discussion with Darren New, if you remember him, a 
few years ago. In Britain "Fault finding" in the technical sense does 
not mean apportioning blame. But just finding the fault. In the sense 
that you know. We would say "finding fault (with)".

As George Bernard Shaw said. "England and America are two countries 
separated by a common language."

-- 

Regards
     Stephen

Post a reply to this message

Stephen <mca### [at] aolcom> wrote:

> As George Bernard Shaw said. "England and America are two countries
> separated by a common language."

And whose fault is that?  Huh?


:D

Post a reply to this message

On 1-11-2014 1:18, Bald Eagle wrote:
> Stephen <mca### [at] aolcom> wrote:
>
>> As George Bernard Shaw said. "England and America are two countries
>> separated by a common language."
>
> And whose fault is that?  Huh?
>

Well, as a geologist I would say, the fault running through the middle 
of the Atlantic Ocean ;-)

Thomas

Post a reply to this message

On 31-10-2014 16:46, Bald Eagle wrote:
> Found it.
> Parameter (l)user_error was set to "ON".   :\

My problem is that I cannot set it to 'off' and somehow I lost that part 
of the Docs explaining its function. I must have tore out that page in a 
moment of frustration. :-)

Thomas

Post a reply to this message

On 01/11/2014 00:18, Bald Eagle wrote:
> Stephen <mca### [at] aolcom> wrote:
>
>> As George Bernard Shaw said. "England and America are two countries
>> separated by a common language."
>
> And whose fault is that?  Huh?
>
>
> :D
>
Probably mine going by the tone of the question. ;-)

-- 

Regards
     Stephen

Post a reply to this message

I'm currently experiencing a major bottleneck in the radiosity-enabled render.
It seems to me to be hanging up on the heightfield frame of the big round mirror
on the left.

I'll try to pore over the docs again, but I'd appreciate it if someone could
suggest a quick (heh) fix to get past those sticky spots.  It went fairly fast
until it hit that, and now it's 12 hours later and still struggling.
WHAT is it _doing_??!

Also, is there a _short_ concise explanation of this file that radiosity can
generate?  If I suffer through this once, does it make subsequent renders vastly
faster?

Thanks!

pretrace_start 0.08
pretrace_end 0.04
count 35
nearest_count 5
error_bound 0.5
recursion_limit 3
low_error_factor 0.5
gray_threshold 0.0
minimum_reuse 0.015
maximum_reuse 0.2
brightness 1
adc_bailout 0.01

Post a reply to this message

On 1-11-2014 15:39, Bald Eagle wrote:
> I'm currently experiencing a major bottleneck in the radiosity-enabled render.
> It seems to me to be hanging up on the heightfield frame of the big round mirror
> on the left.
>
> I'll try to pore over the docs again, but I'd appreciate it if someone could
> suggest a quick (heh) fix to get past those sticky spots.  It went fairly fast
> until it hit that, and now it's 12 hours later and still struggling.
> WHAT is it _doing_??!
>
> Also, is there a _short_ concise explanation of this file that radiosity can
> generate?  If I suffer through this once, does it make subsequent renders vastly
> faster?
>
> Thanks!
>
> pretrace_start 0.08
> pretrace_end 0.04
> count 35
> nearest_count 5
> error_bound 0.5
> recursion_limit 3
> low_error_factor 0.5
> gray_threshold 0.0
> minimum_reuse 0.015
> maximum_reuse 0.2
> brightness 1
> adc_bailout 0.01
>
>

Does the height_field have some reflections enabled? You try do switch 
that off. As far as the radiosity is concerned, I do not see anything 
that really slows down a render; I use those settings currently myself. 
You can increase error_bound to 1.0 and try with recursion_limit 2.

Thomas

Post a reply to this message

"Bald Eagle" <cre### [at] netscapenet> wrote:
> I'm currently experiencing a major bottleneck in the radiosity-enabled render.
> It seems to me to be hanging up on the heightfield frame of the big round mirror
> on the left.
>
> I'll try to pore over the docs again, but I'd appreciate it if someone could
> suggest a quick (heh) fix to get past those sticky spots.  It went fairly fast
> until it hit that, and now it's 12 hours later and still struggling.
> WHAT is it _doing_??!
>
> Also, is there a _short_ concise explanation of this file that radiosity can
> generate?  If I suffer through this once, does it make subsequent renders vastly
> faster?
>
> Thanks!
>
> pretrace_start 0.08
> pretrace_end 0.04
> count 35
> nearest_count 5
> error_bound 0.5
> recursion_limit 3
> low_error_factor 0.5
> gray_threshold 0.0
> minimum_reuse 0.015
> maximum_reuse 0.2
> brightness 1
> adc_bailout 0.01

These settings are pretty low quality IMO, as you mention the files I am
guessing you are generation radiosity data with AA switched on?

You will get a big increase in speed by saving the rad data to a file with no AA
on this pass of your image, you can then load this data and use AA or I prefer
focal blur with a low aperture setting, and the image will trace much faster.

I usually use some variables to control radiosity a variable to control the
quality and another to determine if data should be loaded or saved. You also
have to use the command line switches +RF"filename.rad" to specify a file name
and either +RFO when saving or +RFI when loading data.

Most scenes I have uploaded to the scene files threads will have settings in
them you can copy. Not on my PC at the moment or I would provide an example.

Also I often use simple textures when saving the radiosity data again using a
variable to switch on/off test textures, you can save the data with a very
simple quick texture the use real textures for the final render.

Sean

Post a reply to this message

"Bald Eagle" <cre### [at] netscapenet> wrote:
> I'm currently experiencing a major bottleneck in the radiosity-enabled render.
> It seems to me to be hanging up on the heightfield frame of the big round mirror
> on the left.

I am running into radiosity problems with height fields, but the problem is
severe, scene-destroying artifacts, not render times.  At this time, I haven't
been able to pinpoint exactly what triggers the problem (and therefore have not
reported it), but the presence of height fields together with reflective and/or
metallic objects in the scene seems to be a variable.

> Also, is there a _short_ concise explanation of this file that radiosity can
> generate?  If I suffer through this once, does it make subsequent renders vastly
> faster?

I can't help with the internals of the file, but it can be used with two-pass
radiosity.  The idea is that you generate the radiosity file using a simplified,
fast-rendering scene, then read it back in for the final render.  For some
scenes, these two passes combined will take less time than a one-pass render.
Your mirror sounds like a good candidate for elimination from the simplified
scene.  Jaime explains the technique at his Web site:

   http://www.ignorancia.org/en/index.php?page=Two_Pass_Radiosity

Beware of the parameters that need to be identical for both passes.  Failure to
sync them will result in an /increase/ in render time.

> pretrace_end 0.04
> count 35

These are pretty low quality settings.  But if you're satisfied with the
results, then of course you don't have to change them, especially if the scene
is getting bogged down.

> recursion_limit 3

For most scenes, recursion_limit 2 is sufficient.

Post a reply to this message