Look here :
 http://www.cgtechniques.com/~sibenik/

That guy is setting a GI-engine competition, giving some Roman church
model to render.  POV-Ray is on his list, but nobody has yet
submitted something.  I think that POV-Ray highly deserves its place
in the "contest", so, if some radiosity expert with some time on
his hands (not my case) listens...

Fabien.

Post a reply to this message

On Wed, 12 Dec 2001 18:31:58 +0100, Fabien Mosen wrote:
> That guy is setting a GI-engine competition, giving some Roman church
> model to render.  POV-Ray is on his list, but nobody has yet
> submitted something.  I think that POV-Ray highly deserves its place
> in the "contest", so, if some radiosity expert with some time on
> his hands (not my case) listens...

I notice that many of the entries are "freestyle."  That seems just 
wrong to me.

-- 
#macro R(L P)sphere{L F}cylinder{L P F}#end#macro P(V)merge{R(z+a z)R(-z a-z)R(a
-z-z-z a+z)torus{1F clipped_by{plane{a 0}}}translate V}#end#macro Z(a F T)merge{
P(z+a)P(z-a)R(-z-z-x a)pigment{rgbf 1}hollow interior{media{emission 3-T}}}#end 
Z(-x-x.2x)camera{location z*-10rotate x*90normal{bumps.02scale.05}}

Post a reply to this message

Why don't you give it a try?

"Ron Parker" <ron### [at] povrayorg> wrote in message
news:slr### [at] fwicom...
> On Wed, 12 Dec 2001 18:31:58 +0100, Fabien Mosen wrote:
> > That guy is setting a GI-engine competition, giving some Roman church
> > model to render.  POV-Ray is on his list, but nobody has yet
> > submitted something.  I think that POV-Ray highly deserves its place
> > in the "contest", so, if some radiosity expert with some time on
> > his hands (not my case) listens...
>
> I notice that many of the entries are "freestyle."  That seems just
> wrong to me.
>
> --
> #macro R(L P)sphere{L F}cylinder{L P F}#end#macro P(V)merge{R(z+a z)R(-z
a-z)R(a
> -z-z-z a+z)torus{1F clipped_by{plane{a 0}}}translate V}#end#macro Z(a F
T)merge{
> P(z+a)P(z-a)R(-z-z-x a)pigment{rgbf 1}hollow interior{media{emission
3-T}}}#end
> Z(-x-x.2x)camera{location z*-10rotate x*90normal{bumps.02scale.05}}

Post a reply to this message

I made an entry. Nothing really fancy, just a quick render.

-- 
#macro N(D,I)#if(I<6)cylinder{M()#local D[I]=div(D[I],104);M().5,2pigment{
rgb M()}}N(D,(D[I]>99?I:I+1))#end#end#macro M()<mod(D[I],13)-6,mod(div(D[I
],13),8)-3,10>#end blob{N(array[6]{11117333955,
7382340,3358,3900569407,970,4254934330},0)}//                     - Warp -

Post a reply to this message

On Thu, 13 Dec 2001 11:37:19 +0100, stefkeB wrote:
> Why don't you give it a try?

Because I write better C code than POV code, mostly.

-- 
#macro R(L P)sphere{L F}cylinder{L P F}#end#macro P(V)merge{R(z+a z)R(-z a-z)R(a
-z-z-z a+z)torus{1F clipped_by{plane{a 0}}}translate V}#end#macro Z(a F T)merge{
P(z+a)P(z-a)R(-z-z-x a)pigment{rgbt 1}hollow interior{media{emission T}}finish{
reflection.1}}#end Z(-x-x.2y)Z(-x-x.4x)camera{location z*-10rotate x*90}

Post a reply to this message

"Warp" <war### [at] tagpovrayorg> a écrit dans le message news:

>   I made an entry. Nothing really fancy, just a quick render.

Some important contrast and brightness adjustements could gretly enhance
the image.  Keep in mind that all these so-called "high-end" softwares
have some built-in "exposure" taken into account.

I opened the file in 3DS Viz we have here, but couldn't find a light
source !  Maybe you could guess it by looking at other pictures.
Did you use a sky sphere ?

Fabien.

Post a reply to this message

fabien <fab### [at] skynetbe> wrote:
: Some important contrast and brightness adjustements could gretly enhance
: the image.

  Please tell me how to enhance contrast in the image. I tried. I failed.

: I opened the file in 3DS Viz we have here, but couldn't find a light
: source !  Maybe you could guess it by looking at other pictures.

  The direction of the light source is well defined in the rules page.

: Did you use a sky sphere ?

background { rgb 1 }

-- 
#macro N(D,I)#if(I<6)cylinder{M()#local D[I]=div(D[I],104);M().5,2pigment{
rgb M()}}N(D,(D[I]>99?I:I+1))#end#end#macro M()<mod(D[I],13)-6,mod(div(D[I
],13),8)-3,10>#end blob{N(array[6]{11117333955,
7382340,3358,3900569407,970,4254934330},0)}//                     - Warp -

Post a reply to this message

Warp wrote:
> 
>   Please tell me how to enhance contrast in the image. I tried. I failed.
> 

Most important would be to decrease 'error_bound' in the radiosity
settings, of course you will have to raise 'count' to avoid artefacts and
everything will get much slower.  Another thing that might help is to
reduce recursion_limit to 2, this can lead to better contrasts too.

As a side note, i think this kind of scene is not particularly well suited
for POV-Ray, With procedural textures and CSG instead of meshes the
appearance could be much improved and would suffer less at higher
resolutions (in some of the other renders the mesh facets are really
strongly visible).   

How did you convert it BTW?

Christoph

-- 
Christoph Hormann <chr### [at] gmxde>
IsoWood include, radiosity tutorial, TransSkin and other 
things on: http://www.schunter.etc.tu-bs.de/~chris/

Post a reply to this message

Christoph Hormann <chr### [at] gmxde> wrote:
: Most important would be to decrease 'error_bound' in the radiosity
: settings, of course you will have to raise 'count' to avoid artefacts and
: everything will get much slower.  Another thing that might help is to
: reduce recursion_limit to 2, this can lead to better contrasts too.

  Reducing the recursion_limit hit the spot (although I realized that before
reading your suggestion). The render time also reduced from 1.5h to 1h.
  I made a second entry which looks much better.

: As a side note, i think this kind of scene is not particularly well suited
: for POV-Ray, With procedural textures and CSG instead of meshes the
: appearance could be much improved and would suffer less at higher
: resolutions (in some of the other renders the mesh facets are really
: strongly visible).   

  Well, speedwise I think that meshes and imagemaps are quite ok. If that
same scene would have made with primitives and procedural textures, the render
time could perfectly be several hours...

: How did you convert it BTW?

  3DWin4 did a damn good job at converting the 3ds file given in the page
to mesh2's (with the original uv-information, of course; without that it would
have been impossible to render the scene).
  As the 3ds file didn't have the actual imagemaps, I had to search and
set the proper images in proper places, but that wasn't too difficult.

-- 
#macro N(D,I)#if(I<6)cylinder{M()#local D[I]=div(D[I],104);M().5,2pigment{
rgb M()}}N(D,(D[I]>99?I:I+1))#end#end#macro M()<mod(D[I],13)-6,mod(div(D[I
],13),8)-3,10>#end blob{N(array[6]{11117333955,
7382340,3358,3900569407,970,4254934330},0)}//                     - Warp -

Post a reply to this message

By the way, if anyone is interested in the scene, I can put it somewhere
to download.

-- 
#macro N(D,I)#if(I<6)cylinder{M()#local D[I]=div(D[I],104);M().5,2pigment{
rgb M()}}N(D,(D[I]>99?I:I+1))#end#end#macro M()<mod(D[I],13)-6,mod(div(D[I
],13),8)-3,10>#end blob{N(array[6]{11117333955,
7382340,3358,3900569407,970,4254934330},0)}//                     - Warp -

Post a reply to this message

Warp wrote:
> 
>   Well, speedwise I think that meshes and imagemaps are quite ok. If that
> same scene would have made with primitives and procedural textures, the render
> time could perfectly be several hours...
> 

Hours? Everything below one day is not even worth the work... ;-)

Seriously, i think a mesh that's accurate enough for a realistic render
would not be that fast either. Just have a look at the reference
photographs...

One thing about your render: I think the red carpet should be removed, it
makes the whole front part look very red.

> 
>   3DWin4 did a damn good job at converting the 3ds file given in the page
> to mesh2's (with the original uv-information, of course; without that it would
> have been impossible to render the scene).
>   As the 3ds file didn't have the actual imagemaps, I had to search and
> set the proper images in proper places, but that wasn't too difficult.
> 

How about bump mapping of the brick structures like in some of the other
renders?

Christoph

-- 
Christoph Hormann <chr### [at] gmxde>
IsoWood include, radiosity tutorial, TransSkin and other 
things on: http://www.schunter.etc.tu-bs.de/~chris/

Post a reply to this message

maybe it is worth a try for me.
is there a way to post the converted v3.1-code?
i would download it too (please only via http).
thank you.

BTW: the rendered pic from Vladimir Koylazov looks very realistic. does it 
depend on predefinitions on VRay or on his code?

Post a reply to this message

Christoph Hormann <chr### [at] gmxde> wrote:
: Seriously, i think a mesh that's accurate enough for a realistic render
: would not be that fast either.

  Why not? The rendering time of meshes is quite independent of the number
of triangles in it (yes, there *is* a dependency, but the rendering time of
a mesh grows *very slowly* in relation to the number of triangles; you can
double the number of triangles without the rendering speed slowing down almost
at all).

: One thing about your render: I think the red carpet should be removed, it
: makes the whole front part look very red.

  There is a red carpet in the other images. I think it's part of the original
model, but 3Dwin4 didn't export the color correctly (or alternatively there
was no color information in the 3ds file). I had to set the red color myself
for that (perhaps it's too red, but it's too late to change that).

: How about bump mapping of the brick structures like in some of the other
: renders?

  I used bump mapping with the given bump-map images. It may not be too
visible, but it is there (eg. you can see it in the reflections in the
floor, and in some of the column tops).

-- 
#macro N(D,I)#if(I<6)cylinder{M()#local D[I]=div(D[I],104);M().5,2pigment{
rgb M()}}N(D,(D[I]>99?I:I+1))#end#end#macro M()<mod(D[I],13)-6,mod(div(D[I
],13),8)-3,10>#end blob{N(array[6]{11117333955,
7382340,3358,3900569407,970,4254934330},0)}//                     - Warp -

Post a reply to this message

"Warp" <war### [at] tagpovrayorg> schrieb im Newsbeitrag
news:3c18ea1b@news.povray.org...
> Christoph Hormann <chr### [at] gmxde> wrote:
> : Seriously, i think a mesh that's accurate enough for a realistic render
> : would not be that fast either.
>
>   Why not? The rendering time of meshes is quite independent of the number
> of triangles in it (yes, there *is* a dependency, but the rendering time of
> a mesh grows *very slowly* in relation to the number of triangles; you can
> double the number of triangles without the rendering speed slowing down
almost
> at all).

And YOU call yourself a perfectionist ?
You should be able to tell us, that the time will grow with the logarithm of
the
number of the triangles (if they are saved in octrees, then probably
logbase=8)
;)

>
> : One thing about your render: I think the red carpet should be removed, it
> : makes the whole front part look very red.
>
>   There is a red carpet in the other images. I think it's part of the
original
> model, but 3Dwin4 didn't export the color correctly (or alternatively there
> was no color information in the 3ds file). I had to set the red color
myself
> for that (perhaps it's too red, but it's too late to change that).

to late to change that ? I thought you can send in as many pictures as you
want ?

>
> : How about bump mapping of the brick structures like in some of the other
> : renders?
>
>   I used bump mapping with the given bump-map images. It may not be too
> visible, but it is there (eg. you can see it in the reflections in the
> floor, and in some of the column tops).

of course, you have normals turned on, in the radiosity-block ... , haven't
you ?


--
Jan Walzer <jan### [at] lzernet>

Post a reply to this message

Warp wrote:
> 
>   Why not? The rendering time of meshes is quite independent of the number
> of triangles in it (yes, there *is* a dependency, but the rendering time of
> a mesh grows *very slowly* in relation to the number of triangles; you can
> double the number of triangles without the rendering speed slowing down almost
> at all).

But don't forget that the mesh has to be generated somehow, this can be
very slow too.  I have actually never seen a complex scene filling
geometry like this modelled with with a mesh with sufficient accuracy.

> 
> : One thing about your render: I think the red carpet should be removed, it
> : makes the whole front part look very red.
> 
>   There is a red carpet in the other images. I think it's part of the original
> model, but 3Dwin4 didn't export the color correctly (or alternatively there
> was no color information in the 3ds file). I had to set the red color myself
> for that (perhaps it's too red, but it's too late to change that).
> 

I suppose it is a much darker red in most other pictures, at least none
has this strong color bleed.

Christoph

-- 
Christoph Hormann <chr### [at] gmxde>
IsoWood include, radiosity tutorial, TransSkin and other 
things on: http://www.schunter.etc.tu-bs.de/~chris/

Post a reply to this message

Christoph Hormann wrote:

> But don't forget that the mesh has to be generated somehow, this can be
> very slow too.  I have actually never seen a complex scene filling
> geometry like this modelled with with a mesh with sufficient accuracy.


Accuracy of this scene, architecturally speaking, is pretty low, indeed.
CSG could give better results with more flexibility.  OTOH, meshes are
very efficient in POV-Ray rendering...

Fabien.

Post a reply to this message

Jan Walzer <jan### [at] lzernet> wrote:
: of course, you have normals turned on, in the radiosity-block ... , haven't
: you ?

  Yes. It's just that the poor radiosity quality settings don't really
highlight the normal features.
  I'm making a 20-hour render with higher quality to see what happens.

-- 
#macro N(D,I)#if(I<6)cylinder{M()#local D[I]=div(D[I],104);M().5,2pigment{
rgb M()}}N(D,(D[I]>99?I:I+1))#end#end#macro M()<mod(D[I],13)-6,mod(div(D[I
],13),8)-3,10>#end blob{N(array[6]{11117333955,
7382340,3358,3900569407,970,4254934330},0)}//                     - Warp -

Post a reply to this message

"Fabien Mosen" <fab### [at] skynetbe> a écrit dans le message de news:
> Accuracy of this scene, architecturally speaking, is pretty low, indeed.
> CSG could give better results with more flexibility.  OTOH, meshes are
> very efficient in POV-Ray rendering...

...and uv-mapping complex CSG is a nightmare.
But it's true that CSG in that case could be more scalable.

To be frank, I find the Lightscape pics much better-looking (if not more
realistic) than anything else. Pure effect perhaps, a little overdone but
nice indeed.
I did have a try last night, but got hit with ugly artefacts (as expected
with a checkered floor) and then with looong render times. I've not
submitted it because it's really bad.
I'll see if I can improve it, but that won't happen soon.

G.

--

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

Post a reply to this message

Warp wrote:
> 
>   By the way, if anyone is interested in the scene, I can put it somewhere
> to download.

That would be nice. The download didn't work for me and I got
some CSS errors and blank pages.


_____________
Kari Kivisalo

Post a reply to this message

Warp <war### [at] tagpovrayorg> wrote:
:   I'm making a 20-hour render with higher quality to see what happens.

  As I thought: A lower error_bound (and higher count) gives a more accurate
lighting, but horrible stains of dark/light areas. Aargh!

-- 
#macro N(D,I)#if(I<6)cylinder{M()#local D[I]=div(D[I],104);M().5,2pigment{
rgb M()}}N(D,(D[I]>99?I:I+1))#end#end#macro M()<mod(D[I],13)-6,mod(div(D[I
],13),8)-3,10>#end blob{N(array[6]{11117333955,
7382340,3358,3900569407,970,4254934330},0)}//                     - Warp -

Post a reply to this message

Warp wrote:
> 
> Warp <war### [at] tagpovrayorg> wrote:
> :   I'm making a 20-hour render with higher quality to see what happens.
> 
>   As I thought: A lower error_bound (and higher count) gives a more accurate
> lighting, but horrible stains of dark/light areas. Aargh!
> 

That's life...

Cou can try even higher count or tweaking the other parameters, but
probably things will get really hard with such a scene.  

Christoph

-- 
Christoph Hormann <chr### [at] gmxde>
IsoWood include, radiosity tutorial, TransSkin and other 
things on: http://www.schunter.etc.tu-bs.de/~chris/

Post a reply to this message

Christoph Hormann <chr### [at] gmxde> wrote:
:>   As I thought: A lower error_bound (and higher count) gives a more accurate
:> lighting, but horrible stains of dark/light areas. Aargh!

: That's life...

  No, I personally think that it's a bug.
  To me it looks a lot like there's a coding mistake, or else some
algorithmic mistake in the radiosity code. It could perfectly be something
really, really simple (eg a '<' when it should be a '<=' or something similar),
although it could also be something a lot more complicated.
  In theory, lowering 'error_bound' and increasing 'count' should give a more
accurate lighting (at the cost of a longer render). The lighting should still
be smooth, not splotchy. There has to be some bug somewhere...

-- 
#macro N(D,I)#if(I<6)cylinder{M()#local D[I]=div(D[I],104);M().5,2pigment{
rgb M()}}N(D,(D[I]>99?I:I+1))#end#end#macro M()<mod(D[I],13)-6,mod(div(D[I
],13),8)-3,10>#end blob{N(array[6]{11117333955,
7382340,3358,3900569407,970,4254934330},0)}//                     - Warp -

Post a reply to this message

> There has to be some bug somewhere...

Hunt it down and kill it, Warp. We believe in you! :)

Post a reply to this message

Kari Kivisalo <ray### [at] engineercom> wrote:
:>   By the way, if anyone is interested in the scene, I can put it somewhere
:> to download.

: That would be nice. The download didn't work for me and I got
: some CSS errors and blank pages.

  Ok, you can download it at:

http://www.cs.tut.fi/~warp/sibenik/sibenik_pov.zip

(2477379 bytes)

  By the way, here is the result of the 23.5-hours render:

http://www.cs.tut.fi/~warp/sibenik/sibenik3.jpg

  It looks quite "dirty". Should I submit it or not? I think that it may not
be worthy.

-- 
#macro N(D,I)#if(I<6)cylinder{M()#local D[I]=div(D[I],104);M().5,2pigment{
rgb M()}}N(D,(D[I]>99?I:I+1))#end#end#macro M()<mod(D[I],13)-6,mod(div(D[I
],13),8)-3,10>#end blob{N(array[6]{11117333955,
7382340,3358,3900569407,970,4254934330},0)}//                     - Warp -

Post a reply to this message

Result is quite good, but it doesn´t look very realistic.
Judging from the angle between cathedrale and the "sun", it should be
midday.
But in this case the church interior seems too dark.
There should also be much more contrast.
Since yesterday I try to do the same model, but it seems very difficult to
get really realistic results.
Architecture of gothic and romanic cathedrals are a hobby of mine, therefore
I might be prejudiced...

Norbert


"Warp" <war### [at] tagpovrayorg> schrieb im Newsbeitrag
news:3c1a63e8@news.povray.org...

>   By the way, here is the result of the 23.5-hours render:
>
> http://www.cs.tut.fi/~warp/sibenik/sibenik3.jpg
>
>   It looks quite "dirty". Should I submit it or not? I think that it may
not
> be worthy.

Post a reply to this message

Norbert Kern <nor### [at] t-onlinede> wrote:
: But in this case the church interior seems too dark.

  It would be really easy to lighten it up. However, I don't want to spend
other 24 hours to render it again...

-- 
#macro N(D)#if(D>99)cylinder{M()#local D=div(D,104);M().5,2pigment{rgb M()}}
N(D)#end#end#macro M()<mod(D,13)-6mod(div(D,13)8)-3,10>#end blob{
N(11117333955)N(4254934330)N(3900569407)N(7382340)N(3358)N(970)}//  - Warp -

Post a reply to this message

>   It would be really easy to lighten it up. However, I don't want to spend
> other 24 hours to render it again...

i like it darker - looks more moody - i would submit it


--

Rick

Kitty5 WebDesign - http://Kitty5.com
POV-Ray News & Resources - http://Povray.co.uk
TEL : +44 (01270) 501101 - FAX : +44 (01270) 251105 - ICQ : 15776037

PGP Public Key
http://pgpkeys.mit.edu:11371/pks/lookup?op=get&search=0x231E1CEA

Post a reply to this message

Warp wrote:
>
> http://www.cs.tut.fi/~warp/sibenik/sibenik_pov.zip

Thanks. I should be really working like, right now!, but I just
have to try this :)


_____________
Kari Kivisalo

Post a reply to this message

Here is my 1st try with the simulation just to see if
it would benefit from tonal range modification. Maybe
later.

The white sources were replaced by realistic colors and
intensities for sun and sky. I used diffuse 0.6 for the
linearised sandstone texture maps and diffuse 0.8 for the
floor. Other textures were diffuse 0.6. I assumed the maps
to be sRGB.

http://www.pp.htv.fi/kkivisal/church1.jpg

Took 25 minutes on 1GHz AMD without the glass objects.

global_settings{
  assumed_gamma 1.0
  radiosity{
    pretrace_start 0.04
    pretrace_end 2/400
    count 200
    recursion_limit 2
    nearest_count 3
    error_bound 0.5
  }
}

_____________
Kari Kivisalo

Post a reply to this message

It's looking good.

  What are those white artifacts near the center of the image?

-- 
#macro N(D)#if(D>99)cylinder{M()#local D=div(D,104);M().5,2pigment{rgb M()}}
N(D)#end#end#macro M()<mod(D,13)-6mod(div(D,13)8)-3,10>#end blob{
N(11117333955)N(4254934330)N(3900569407)N(7382340)N(3358)N(970)}//  - Warp -

Post a reply to this message

Oh, wow. Excellent.

Post a reply to this message

very good and better than mine, which isn´t ready up to now.
One question: what is the reason for nearest count 3?
Will you increase the value for the final render?

Norbert

> global_settings{
>   assumed_gamma 1.0
>   radiosity{
>     pretrace_start 0.04
>     pretrace_end 2/400
>     count 200
>     recursion_limit 2
>     nearest_count 3
>     error_bound 0.5
>   }
> }
>
> _____________
> Kari Kivisalo

Post a reply to this message

Warp wrote:
>
>   What are those white artifacts near the center of the image?

Sunlight through the windows. Where is the sun supposed to be?
The rules don't explicitly specify it. Do I have to dig out
a solar system simulator and calculate the position :)


_____________
Kari Kivisalo

Post a reply to this message

Norbert Kern wrote:
>
> One question: what is the reason for nearest count 3?

No reason. My plan was that in case of artefacts with
hifi rad settings I would try 10 instead :)


_____________
Kari Kivisalo

Post a reply to this message

Kari Kivisalo wrote:

> Here is my 1st try with the simulation just to see if
> it would benefit from tonal range modification. Maybe
> later.


Pretty good !  As I said earlier, commercial packages have
built-in exposure/tonal correction, and it's just right to
process the image.

Too bad it isn't possible to turn reflection off for
radiosity samples.  Commercial packages does that,
and thus gain much speed without noticeable difference.

Fabien.

Post a reply to this message

"Kari Kivisalo" <ray### [at] engineercom> wrote in message
news:3C1BBA3A.EA4AD09E@engineer.com...
>
> Where is the sun supposed to be?
You can guess it from the 3DMAX screen shot on the web page. Some where
near <-12.0, 28.0, 48.0> (the previous post had a wrong x value).

Ari-Matti

Post a reply to this message

"Fabien Mosen" <fab### [at] skynetbe> wrote in message
news:3C1### [at] skynetbe...
> Too bad it isn't possible to turn reflection off for
> radiosity samples.  Commercial packages does that,
> and thus gain much speed without noticeable difference.

http://www.students.tut.fi/~leppane6/pics/sibenik_25m.jpg
http://www.students.tut.fi/~leppane6/pics/sibenik_20m.jpg

These aren't good looking, just testing this trick.
The first is a one trace image (25min ??s). The second is traced in to
steps. First commented out reflections and added save_file to the radiosity
block. After the trace (19min 27s) reflections were uncommented and in the
radiosity block save_file was replaced with load_file, pretrace_start and
pretrace_end were set to 1 and added always_sample off. This trace took 1min
16s, total time 20min 43s.
They look quite the same and later saved about 4 minutes. Looks like that in
the 20 minute version the red bleeds more.

Ari-Matti

Post a reply to this message

ingo wrote:
>
> There is sunpos.inc in the 3.5 distribution.

Maybe I should read the manual again :) 

Anyway, I need at least 256MB more RAM to be able to render this
one with good rad settings. I'll try again in January.


_____________
Kari Kivisalo

Post a reply to this message

Ari-Matti Leppanen wrote:

> These aren't good looking, just testing this trick.


Is what you did *really* equivalent to bypassing the reflection in 
radiance samples ?

There is one thing I'm absolutely sure of : LightScape, which renderings
are found great by most everyone, *doesn't* account reflection for it's
radiance solution calculation.  In fact, due to it's algorithm, it 
*can't* !  Energy transfers can't take specular reflection into account.
Also, please note it doesn't even take *textures* in account (for the
same reason), only a plain diffuse color.  Finally, it doesn't render
bumps, but that's another issue.

As far as I could gather information, other radiance engines, 
monte-carlo/bidirectional/photons/... based, also *don't* take specular
reflection into account.

Fabien.

Post a reply to this message

"Fabien Mosen" <fab### [at] skynetbe> wrote in message
news:3C1### [at] skynetbe...
> Ari-Matti Leppanen wrote:
>
> > These aren't good looking, just testing this trick.
>
>
> Is what you did *really* equivalent to bypassing the reflection in
> radiance samples ?
>

The documentations says: 6.11.11.1 "..provides a way to replace the last
term - the constant ambient light value - with a light level which is based
on what surfaces are nearby..".
By that I would say that reflections don't affect the result so it's *not
really* equivalent.
Then speed difference is probably from the fact that always_sample is off in
the second case. I should check if there's a difference when it's on.

Ari-Matti

Post a reply to this message

Fabien Mosen wrote:
>
> Also, please note it doesn't even take *textures* in account (for the
> same reason), only a plain diffuse color. Finally, it doesn't render
> bumps, but that's another issue.

So this is why those Lightscape entrys look cartoony!


_____________
Kari Kivisalo

Post a reply to this message

Ari-Matti Leppanen wrote:

> The documentations says: 6.11.11.1 "..provides a way to replace the last
> term - the constant ambient light value - with a light level which is based
> on what surfaces are nearby..".


Which is the basic principle of any radiance engine.


> By that I would say that reflections don't affect the result so it's *not
> really* equivalent.


It does.  POV-Ray takes reflection of surfaces into account when taking
radiance samples.  I've done a test scene to check that.  IMO, we 
should, at least, have an option to disable it.

Fabien.

Post a reply to this message

Kari Kivisalo wrote:

> So this is why those Lightscape entrys look cartoony!


Yep !  The engine is pretty incomplete, texture-wise.  No bumps, not 
even slightly complex procedural texturing.

However, on has to admit the obvious quality of light in these images.

Fabien.

Post a reply to this message

Dynamic range compression test with half resolution
image and radiosity solution that fits in 256MB RAM.
Sun position from the sunpos macro. I used count 1200
and it seems it's not enough. The noise may also result
from my poor choice of clipping intensity.

http://www.pp.htv.fi/kkivisal/church2.jpg


_____________
Kari Kivisalo

Post a reply to this message

Kari Kivisalo wrote:
> http://www.pp.htv.fi/kkivisal/church2.jpg

 :O  Even at half resolution, it's the most artistic and realistic of all. 
Light is almost perfect for me.

-- 
Jaime Vives Piqueres

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

Post a reply to this message

Kari Kivisalo wrote:
> 
> Dynamic range compression test with half resolution
> image and radiosity solution that fits in 256MB RAM.
> Sun position from the sunpos macro. I used count 1200
> and it seems it's not enough. The noise may also result
> from my poor choice of clipping intensity.
> 
> http://www.pp.htv.fi/kkivisal/church2.jpg
> 

Looks good from what you can see at that size.  I think you should try to
render it in full size with slightly weaker radiosity settings if
necessary.  

Christoph

-- 
Christoph Hormann <chr### [at] gmxde>
IsoWood include, radiosity tutorial, TransSkin and other 
things on: http://www.schunter.etc.tu-bs.de/~chris/

Post a reply to this message

Oh, wow... This is definitely the best so far.

Post a reply to this message

"Kari Kivisalo" <ray### [at] engineercom> wrote in message
news:3C1F34F2.2961A5C5@engineer.com...

> Dynamic range compression test with half resolution
> image and radiosity solution that fits in 256MB RAM.
> Sun position from the sunpos macro. I used count 1200
> and it seems it's not enough. The noise may also result
> from my poor choice of clipping intensity.
Looking good.. what was the trace time? The quality suggests that a full
size might take ages. See you made the same mistake with the SunPos as I
did. The scene looks better that way but:

// Lstm:  Meridian of your local timezone (+1 hour =  +15 deg)
//        in degrees (east = positive, west = negative)

so I guess Lstm should be +15 not +1. Hope you haven't started a new trace
yet. Somehow after 13,5h I don't want to re-start anymore.

Ari-Matti

Post a reply to this message

"Kari Kivisalo" <ray### [at] engineercom> a écrit dans le message news:
>
> Dynamic range compression test with half resolution
> image and radiosity solution that fits in 256MB RAM.
> Sun position from the sunpos macro. I used count 1200
> and it seems it's not enough. The noise may also result
> from my poor choice of clipping intensity.

That's impressive.  The light quality is, by far, the best I have
seen amongst every other rendering of that church (including
lightscape, mental ray, etc...).

I hope the final rendering will do justice to it.

I hope that this dynamic range stuff will be implemented in POV-Ray
someday.

Fabien.

Post a reply to this message

"Kari Kivisalo" <ray### [at] engineercom> a écrit dans le message de news:
3C1F34F2.2961A5C5@engineer.com...
>
> Dynamic range compression test with half resolution
> image and radiosity solution that fits in 256MB RAM.
> Sun position from the sunpos macro. I used count 1200
> and it seems it's not enough. The noise may also result
> from my poor choice of clipping intensity.
>
> http://www.pp.htv.fi/kkivisal/church2.jpg
>
--
Certainly the best so far... It certainly helps a lot knowing about lighting
like you do. I'm wondering about the light position, though, as the sun
seems lower in your image than in the other ones. I've been using these
parameters :
//    SunPos(Year, Month, Day, Hour, Minute, Lstm, LAT, LONG)
    SunPos(2001, 6, 1, 14, 0, 15, 45.44, 15.53)

How much memory is required, BTW ? Is it possible to render it in chunks, as
this can reduce greatly the necessary memory ?

G.



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

Post a reply to this message