Reactor wrote:
> Would you mind making the source available?

He can't. Redistribution of 3.7 beta code isn't allowed.

Post a reply to this message

"Samuel Benge" <stb### [at] hotmailcom> wrote:
> Hey clipka (and everyone else who might be interested),
>
> There's a quick workaround for 3.7 radiosity.

I'm actually not interested in quick workarounds, but getting the thing to
ultimately work fine without them :)

> 3.7's radiosity doesn't seem to like high count values,

That's very interesting for me to hear. Can you describe what's wrong with it,
and maybe post a sample scene?

> so to get more detail you can apply a small-scale
> global surface normal to all objects in your scene like so:
>
> #default{
>  finish{ambient 0}
>  normal{bumps .25 scale .001}
> }
>
> You can now get away with lower (<300) count settings. It's a hack--I admit
> it--but it's worth it for difficult scenes. This works just fine with custom
> pretrace_start/end and low error_bound settings as well. You'll need good
> antialiasing settings to go along with it:

Hm - sounds to me like you're actually using the normals to force more samples
to be taken. Does this any good to rendering time?

Post a reply to this message

Nicolas Alvarez <nic### [at] gmailcom> wrote:
> Reactor wrote:
> > Would you mind making the source available?
>
> He can't. Redistribution of 3.7 beta code isn't allowed.

Sorry, I meant the scene source code, not the binary.  My tests will be on the
scene with another method of adjusting radiosity under version 3.6 (official)
and MegaPov 1.2.1

Reactor

Post a reply to this message

"Reactor" <rea### [at] hotmailcom> wrote:
> Would you mind making the source available?  I have been experimenting with
> radiosity under 3.6 recently, and I've run into an odd, non-intuitive way of
> getting certain difficult to render scenes to trace correctly.  I also want to
> see how the recursive sampling does under MegaPov 1.2.1.

Whoops - somehow this post of yours slipped past me...

Tell me about those experiments - it may help me identify some more quirks in
the radiosity code.


> Since the images is still not very accurate and your settings seem to be fairly
> high (in comparison to what I use for most scenes), I think this would be a
> good test of some alternate methods.

Sure, give it a try. But promise to tell me about your results ;)

As it is now, it needs a texture named "Parquetry_plain.png", but I guess that
doesn't really matter, so you may want to replace it with a uniform pigment.
The original texture I use is too large to post it.

Post a reply to this message

Attachments:
Download 'the_secret.zip' (291 KB)

"clipka" <nomail@nomail> wrote:
>  See for yourself what 3.6 and the
> 3.7.0.beta.29 make of it.

I would if the image weren't 5 times bigger than my monitor.

Post a reply to this message

"clipka" <nomail@nomail> wrote:
> "Reactor" <rea### [at] hotmailcom> wrote:
> > Would you mind making the source available?  I have been experimenting with
> > radiosity under 3.6 recently, and I've run into an odd, non-intuitive way of
> > getting certain difficult to render scenes to trace correctly.  I also want to
> > see how the recursive sampling does under MegaPov 1.2.1.
>
> Whoops - somehow this post of yours slipped past me...
>
> Tell me about those experiments - it may help me identify some more quirks in
> the radiosity code.
>
>
> > Since the images is still not very accurate and your settings seem to be fairly
> > high (in comparison to what I use for most scenes), I think this would be a
> > good test of some alternate methods.
>
> Sure, give it a try. But promise to tell me about your results ;)
>
> As it is now, it needs a texture named "Parquetry_plain.png", but I guess that
> doesn't really matter, so you may want to replace it with a uniform pigment.
> The original texture I use is too large to post it.


Well... basically, when you start to run into the 1600 count limit or the count
vs patience limit, I've found that some scenes can actually be made to work
with a lower count than usual by lengthening the pretrace step and dropping the
error bound very low.  Since one usually sees splotches when the count is too
low for a given error_bound, if the error_bound is dropped low enough, the
splotches become very small and distributed such that the shadows and shading
start becoming reasonably accurate again.
Depending on the scene, this method can work fairly well.  I have had some
degree of success on scenes that are indoors and involve sharper shadows and
rapid changes of light.  Outdoor, architectural scenes involving slower changes
of light and softer shadows seem to do better with the usual approach.

Post a reply to this message

"Cousin Ricky" <ric### [at] yahoocom> wrote:
> "clipka" <nomail@nomail> wrote:
> >  See for yourself what 3.6 and the
> > 3.7.0.beta.29 make of it.
>
> I would if the image weren't 5 times bigger than my monitor.

:) no scroll bars or zoom on your browser / image viewer / whatever?

Post a reply to this message

"Reactor" <rea### [at] hotmailcom> wrote:
> Well... basically, when you start to run into the 1600 count limit or the count
> vs patience limit, I've found that some scenes can actually be made to work
> with a lower count than usual by lengthening the pretrace step and dropping the
> error bound very low.  Since one usually sees splotches when the count is too
> low for a given error_bound, if the error_bound is dropped low enough, the
> splotches become very small and distributed such that the shadows and shading
> start becoming reasonably accurate again.
> Depending on the scene, this method can work fairly well.  I have had some
> degree of success on scenes that are indoors and involve sharper shadows and
> rapid changes of light.  Outdoor, architectural scenes involving slower changes
> of light and softer shadows seem to do better with the usual approach.

I see... so what you're basically doing is "de-bundling" the sample rays.

Theoretically this should be somewhat slower, as you probably use the same
number of sample rays (total, not per sample), and just distribute them more
evenly across the whole scene, so the lookup will be slowed down.

However, I can also see how this might smoothen the look of the scene.


Which reminds me... I guess I should check whether the re-used samples are
actually weighted according to the distance to the point in question...

(*digs through the code*)

.... hum... well, there is some weighting according to distance, but judging from
the way that some splotchy images look, this might be implemented poorly. I'll
have a closer look at this.

Post a reply to this message

clipka wrote:
> "Samuel Benge" <stb### [at] hotmailcom> wrote:
>> Hey clipka (and everyone else who might be interested),
>>
>> There's a quick workaround for 3.7 radiosity.
> 
> I'm actually not interested in quick workarounds, but getting the thing to
> ultimately work fine without them :)

Yeah, once you start using tricks to get what you want, you lose 
flexibility.

>> 3.7's radiosity doesn't seem to like high count values,
> 
> That's very interesting for me to hear. Can you describe what's wrong with it,
> and maybe post a sample scene?

No, I cannot. Recent tests don't seem to be showing any black splotches. 
Maybe 3.7's radiosity has been fixed somewhat after all. It used to 
happen when I rendered meshes with high-count radiosity. Strange black 
patches would appear, and higher count values only made it worse. If I 
run into it again, I'll post the relevant code.

>> #default{
>>  finish{ambient 0}
>>  normal{bumps .25 scale .001}
>> }
> 
> Hm - sounds to me like you're actually using the normals to force more samples
> to be taken. Does this any good to rendering time?

Yes, that is what I'm doing. If you're having a hard time getting rid of 
  radiosity's artifacts, the method can save the day. The render times 
generally tend to be a bit higher, and you'll always see some of the 
surface normal. Overall, the result is on par with many other types of 
radiosity you see out there. You know, the ones with visual noise :)

Sam

Post a reply to this message

nemesis wrote:
> "Samuel Benge" <stb### [at] hotmailcom> wrote:
>>
>> You can now get away with lower (<300) count settings. It's a hack--I admit
>> it--but it's worth it for difficult scenes.
> 
> BTW, Samwise is one of our resident wizards -- Jaime and Gilles too but they
> seem to be a bit off in other planes of existence -- and is well versed in
> povray black crafts.  Heed his magic words. :)

It's a cheap trick, and it makes you lose flexibility in your scene. It 
might be a good thing to keep in mind though, if in case some day you 
have a particularly stubborn scene :/

Sam

Post a reply to this message