ABX wrote:
> 
> [...]
> 
> Nice colors. :-)
> 

:-)

I already feared to get replies like that now, but considering radiosity
was quite commonly used recently i assumed there would be more interest in
such extensions.

Christoph

-- 
POV-Ray tutorials, IsoWood include,                 
TransSkin and more: http://www.tu-bs.de/~y0013390/  
Last updated 13 Aug. 2002 _____./\/^>_*_<^\/\.______

Post a reply to this message

Christoph Hormann wrote:
> And it's not that difficult with functions after all, you can for example
> use a df3 file to describe what parts of the scene you need high count
> for.

  That's inseresting...
 
> Another idea i have been thinking about is adaptive count.  This would
> mean when taking a sample the program shoots a minimum number of rays,
> analyzes their results and decides whether to shoot more.

  ...but that would be ideal for lazy raytracers like me. I always prefer 
these things to be automatic (because if they depend on my knowledge of 
inner working, I'm lost).

-- 
Jaime Vives Piqueres

La Persistencia de la Ignorancia
http://www.ignorancia.org

Post a reply to this message

3D74CA7E.E59ED0AA@gmx.de...

> I already feared to get replies like that now, but considering radiosity
> was quite commonly used recently i assumed there would be more interest in
> such extensions.

I guess that the lack of answers is due to the fact that demo doesn't show
off the benefit of it as some artefacts disappear but other come up (like
the brighter spots in the middle of the walls or on the underside of the
door). And the render time is longer too, which is an undesired effect I
suppose.

Still any idea about controlling the radiosity quality is interesting and
may prove to be valuable, so keep on trying !!! And like Jaime says, the
more automatic the better...

G.


--

**********************
http://www.oyonale.com
**********************
- Graphic experiments
- POV-Ray and Poser computer images
- Posters

Post a reply to this message

Jaime Vives Piqueres wrote:
> 
> > Another idea i have been thinking about is adaptive count.  This would
> > mean when taking a sample the program shoots a minimum number of rays,
> > analyzes their results and decides whether to shoot more.
> 
>   ...but that would be ideal for lazy raytracers like me. I always prefer
> these things to be automatic (because if they depend on my knowledge of
> inner working, I'm lost).

But it would not have the same effect.  With the demonstrated technique i
intended to give the user a tool to do something about specific artefacts
by locally increasing the count value.  The adaptive method would (if it
works, i have not tried yet) increase quality in general while not
increasing render time too much.  Without doubt this would be useful, but
it would not be a replacement for the other technique.

Christoph

-- 
POV-Ray tutorials, IsoWood include,                 
TransSkin and more: http://www.tu-bs.de/~y0013390/  
Last updated 13 Aug. 2002 _____./\/^>_*_<^\/\.______

Post a reply to this message

Gilles Tran wrote:
> 
> [...]
> 
> I guess that the lack of answers is due to the fact that demo doesn't show
> off the benefit of it as some artefacts disappear but other come up (like
> the brighter spots in the middle of the walls or on the underside of the
> door). And the render time is longer too, which is an undesired effect I
> suppose.

It was just a first test mainly showing two things:

- increasing quality locally by increasing count is possible.
- there is a drawback because of increased calculation time because of the
function evaluations.

The bright sports are cased by really low count in that area (i tried to
bring down the calculation time). The Door does not look good because the
function does not take account of it.

Thanks to all for the replies BTW.

Christoph

-- 
POV-Ray tutorials, IsoWood include,                 
TransSkin and more: http://www.tu-bs.de/~y0013390/  
Last updated 13 Aug. 2002 _____./\/^>_*_<^\/\.______

Post a reply to this message

I share some sentiments with the others. Automatic or a adaptive 'count'
would be the most useful to most people. But I also see your reasoning to
try and get the radiosity refined where needed most by this more direct
user-applied means. If a df3 way were possible then how would a person go
about creating it and then editing it? Render the original scene using a
sort of monochromatic media (emission-only for example) for all objects?
That couldn't be right though... it's only surfaces you'd be after. And then
I don't see any straightforward way of manipulating where to increase or
decrease the count. Object pattern seems an obvious choice, if I even knew
first that could be used for this, but there's still the question of how to
edit.

It's a nice idea but, from what I can tell, some already available settings
might do well enough when it comes to refining the radiosity results. Just a
IMHO statement there. This is a noble cause of course. I think what it comes
down to is whether or not it can be done simply enough and still be some
improvement all around. There is such a potential complexity as I see it
that only a few people would ever get real decent end results after a lot of
effort. Or maybe I'm just not seeing the whole concept right.

Post a reply to this message

"Christoph Hormann" <chr### [at] gmxde> wrote in message
news:3D7### [at] gmxde...
> Gilles Tran wrote:
[snip of Gil's intervention]

> It was just a first test mainly showing two things:
> - increasing quality locally by increasing count is possible.
> - there is a drawback because of increased calculation time because of the
> function evaluations.
> The bright sports are cased by really low count in that area (i tried to
> bring down the calculation time). The Door does not look good because the
> function does not take account of it.

I don't have all the technical background to help you with technical
criticism but I can forsee the interest of your studies.
About the drawback, for a complex scene it mustn't be that important since
your function could help POV-ray "focuses" on the areas that need lots of
treatment. If that function can be optimized to gain time in its treatment
is a question that I leave to you since I cannot unfortunately help you :-(

Suggestion (if you already thought about it, sorry :-))
Would it be possible to use a something like empties to pinpoint the place
we think wil require more work?
An empty is an object used in almost all modellers that present all
qualities of an object except that it doesn't appear at render time.
The POVdude could put those in the scene according to what he sees in the
test rendering that way for the final rendering your function will
automatically knows where to work.
I suppose that there must be a box attribute in POV that allow to define a
zone that will be treated (I'm reading in parrallel the POVdoc so forgive me
if I'm nuking some open doors). Each empty could be given a zone that it
represent and the function will work on those zones by pointing to the
empties.

Well I don't know if it makes sens but I hope that's something that could
help you by giving you a glimpse at the solution or a warning sign about the
direction not to follow ^___^

Jean-luc who has lost 800 000 neurones during that exercise -__-

Post a reply to this message

> Suggestion (if you already thought about it, sorry :-))
> Would it be possible to use a something like empties to pinpoint the
> place we think wil require more work?
> An empty is an object used in almost all modellers that present all
> qualities of an object except that it doesn't appear at render time.
> The POVdude could put those in the scene according to what he sees in
> the test rendering that way for the final rendering your function will
> automatically knows where to work.
> I suppose that there must be a box attribute in POV that allow to
> define a zone that will be treated (I'm reading in parrallel the
> POVdoc so forgive me if I'm nuking some open doors). Each empty could
> be given a zone that it represent and the function will work on those
> zones by pointing to the empties.


I never used it yet, but the object_pattern should do.
Well - function {pigment_pattern {object {...}}}, that is.
See docs: 6.7.11.23 and 6.7.11.25
E.g.


Simply declare an union with boxes covering all the area, that POV-Ray should
have a closer look, and use it as an 'object_pattern' in a function.
It seems, it's not too difficult to use Christoph's technic with those
functions...

#declare Function =
  function {
    pattern {
      pigment_pattern {
        object {
          union {
            box{...}
            box{...}
            box{...}
          }
        }
      }
    }
  }

To Christioph: Keep it up, it's always good to have the posibilitys of
POV-Ray anhanced.
One day won't want to miss it...

cukk

Post a reply to this message

Hi Christoph,

Do you think you could post the source for your test scene? And whatever
rendering parameters you use? I've been tinkering with the radiosity
code too, and I'd like to see how the results compare with your images.

I've used a simple scene for testing - I'll attach the results from the
official and custom compiles as well as the scene file.

Bye for now,
	Mike Andrews.

Post a reply to this message

Attachments:
Download 'rad_custom.jpg' (5 KB) Download 'rad_official.jpg' (5 KB) Download 'rad_tile.pov.txt' (2 KB)

Preview of image 'rad_custom.jpg'

Preview of image 'rad_official.jpg'

Michael Andrews wrote:
> 
> Hi Christoph,
> 
> Do you think you could post the source for your test scene? And whatever
> rendering parameters you use? I've been tinkering with the radiosity
> code too, and I'd like to see how the results compare with your images.

I have use a slightly modified version of one of the radiosity scenes
(rad_def_test.pov) in the distribution, changes are:

- removing the cylinders loop
- adding 'box { <2, 0, 0>, <1.9, 2, 1.6> }'
- using 'ambient 2' for the sky
- using camera:

camera {
  location    <2, -4, 1.0>
  direction   y
  sky         z
  up          z
  right       1.3333333*x
  look_at     <0.0, 0.0, 1.0>
  angle       40
}

But for recent tests i have used a different scene anyway, this one is not
that suited for demonstrating artefact problems and way too fast for
realistic speed measurements.

Christoph

-- 
POV-Ray tutorials, IsoWood include,                 
TransSkin and more: http://www.tu-bs.de/~y0013390/  
Last updated 13 Aug. 2002 _____./\/^>_*_<^\/\.______

Post a reply to this message