Warp wrote:

> fabien <fab### [at] skynetbe> wrote:
> : I hope that this dynamic range stuff will be implemented in POV-Ray
> : someday.
> 
>   I suppose that it would take about 10-20 lines of code to implement it
> (plus the code needed for a new keyword in global_settings...). And perhaps
> not even that much.


OK.  Now you know what will make your weekend busy :-)

(and, while you're hands in it, add a switch to ignore reflection and
  refraction in radiosity samples !!!!)

Fabien.

Post a reply to this message

Warp wrote:

> show quite clearly that the light should be coming from a direction which is
> -1 unit in the x-axis, 3 units in the y-axis and 5 units in the z-axis. Thus
> the light should be located at <-1,3,5>*Distance.
>   It does not specify the distance, but as it should be the Sun, a distance
> large enough should be used. This is what I did (I used <-1000,3000,5000>).


Just an idea : shouldn't Y and Z be swapped ?

Fabien.

Post a reply to this message

Fabien Mosen <fab### [at] skynetbe> wrote:
: Just an idea : shouldn't Y and Z be swapped ?

  Nope.

  The camera is not the default povray camera. It is set up so that those
are the right coordinates.

-- 
#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

Fabien Mosen <fab### [at] skynetbe> wrote:
: (and, while you're hands in it, add a switch to ignore reflection and
:   refraction in radiosity samples !!!!)

  Why?

-- 
#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

Warp wrote:

> Fabien Mosen <fab### [at] skynetbe> wrote:
> : (and, while you're hands in it, add a switch to ignore reflection and
> :   refraction in radiosity samples !!!!)
> 
>   Why?


IMO, it's the source of many artifacts (as it causes important
variations in a surface's visible colors).

IMO, in reality, refl. and refr. doesn't contribute much to
diffuse interreflection, if at all.  Especially slightly reflective
surfaces, such as a wooden table, metallic computer case...

Look at Jaime's office images in pbi., for a great demonstration.

AFAICT (also based on quick tests I asked to their users), commercial
radiance packages *doesn't* take that in account.  That's probably
an important explanation of the wonderful speed and absence of artifacts
seen in stuff like Brazil, Mental Ray, Final Render, etc...

Fabien.

Post a reply to this message

Fabien Mosen <fab### [at] skynetbe> wrote:
: AFAICT (also based on quick tests I asked to their users), commercial
: radiance packages *doesn't* take that in account.

  But is it intentional or because the algorithm it uses does not support it?

-- 
#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
[1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -

Post a reply to this message

Fabien Mosen wrote:
> Look at Jaime's office images in pbi., for a great demonstration.

  In my case, I needed to define an alternative version of each texture. 
Fortunately, they were all on one file! :)

  At least for low radiosity settings (the only ones I use, I'm not very 
patient), saved data from the same scene rendered with "dummy" textures, 
can be used later (if posible with exactly the same geometry) with great 
success, IMHO. 

  But  I don't know if this is enough to justify a feature request, or what 
feature to request... only reflections/refractions on/off in radiosity{}?

-- 
Jaime Vives Piqueres

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

Post a reply to this message

Warp wrote:

> Fabien Mosen <fab### [at] skynetbe> wrote:
> : AFAICT (also based on quick tests I asked to their users), commercial
> : radiance packages *doesn't* take that in account.
> 
>   But is it intentional or because the algorithm it uses does not support it?


In case of radiosity-finite-elements-... (as in LightScape), these are 
limitations of the algorithm.  As you can see, this doesn't prevent a 
very good light simulation.

In case of monte-carlo/photons/...  algorithms (as in MRay, Brazil,..),
it must be (well, I'm not 100% sure, but close) intentional, since it
causes a great speedup.  Definitely worth a try.

Fabien.

Post a reply to this message

Jaime Vives Piqueres wrote:

> 
>   In my case, I needed to define an alternative version of each texture. 
> Fortunately, they were all on one file! :)


I imagine this could be somewhat automated.  Why not use the old 
"quick_color" keyword to specify the plain color that should be used
in radiance samples ?

(note : these are not requests for the official version, just some
  toughts about how the radiance algorithm could evolve towards
  better quality and speed).

Fabien.

Post a reply to this message

I made a third entry to the competition. Check it out.

-- 
#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