clipka wrote:

> Would you mind e-mailing the scene to "christoph (at) lipka-koeln (dot) de"? As
> of now, it's the only scene I've seen so far that shows this effect.
> 
> Maybe you can strip it down to just the room and the tiles.
>

Will do so, but may take a little time.


> Another thought that just crossed my mind is "gamma": what if 3.7 interprets the
> sky sphere differently with respect to gamma? (Then again, that would probably
> look much different.)
> 
> At the moment I'm suspecting the floor to pick up light from below for some
> reason. What is the floor made of, geometrically speaking?
> 

I will also do some experiments to see if I can narrow down the problem.

-Ive

Post a reply to this message

clipka wrote:

> At the moment I'm suspecting the floor to pick up light from below for some
> reason. What is the floor made of, geometrically speaking?
> 

  Just a box ;)


#declare W = 500.0;
#declare L = 664.6;
#declare H = 323.6;

//==============================================================
// room
//==============================================================

union {
// floor
   box { <0,0, 1> <W,-1,-L-1>  texture {T_Floor} }

  ... and a lot of more stuff


But here is the interesting thing:


#declare T_Floor = texture {
   material_map { png "Floor#2"
     texture {T_FloorMortar}
     texture {T_FloorWhite}
     texture {T_FloorBlack}
     texture {T_FloorBlack translate  79}
     texture {T_FloorBlack translate 255}
   }
   rotate x*90
   rotate y*45
   scale 117.2/2
   translate <-20.0, 0, 0>
}


where each of the separate textures is a quite complicated layered 
texture. Suspicion was that either the heavy layered textures or the 
material_map statement did mess up things.
So a quick simplification:

#declare T_FloorWhite_simple = texture
{
   pigment {rgb 0.55}
   finish {ambient 0  diffuse 1}
}

#declare T_FloorBlack_simple = texture
{
   pigment {rgb 0.05}
   finish {ambient 0  diffuse 1}
}

#declare T_Floor = texture {
   checker
   texture {T_FloorWhite_simple}, texture {T_FloorWhite_simple}
   rotate x*90
   rotate y*45
   scale 117.2/2
   translate <-20.0, 0, 0>
}

and the result is still weird! See picture 1.

But then:

#declare T_Floor = texture {
   texture {T_FloorWhite_simple}
   rotate x*90
   rotate y*45
   scale 117.2/2
   translate <-20.0, 0, 0>
}

works perfectly as expected (low quality aside). Picture 2.

This effect can be easily reproduced in any other scene.


So it seems to me that the problem is maybe not even related to 
radiosity but it is to patterned textures. Maybe it has something to do 
with he post by me to p.beta-test from 4/25/2008 "texture_map vs. 
pigment_map" - that never got a response ;(


-Ive

Post a reply to this message

Attachments:
Download 'musiclesson-simple1.jpg' (50 KB) Download 'musiclesson-simple2.jpg' (77 KB)

Preview of image 'musiclesson-simple1.jpg'

Preview of image 'musiclesson-simple2.jpg'

Ive <"ive### [at] lilysoftorg"> wrote:
> So it seems to me that the problem is maybe not even related to
> radiosity but it is to patterned textures. Maybe it has something to do
> with he post by me to p.beta-test from 4/25/2008 "texture_map vs.
> pigment_map" - that never got a response ;(

Now THAT is interesting; in fact, some - albeit less prominent - differences
between 3.6 and beta.30-rad1 I never got resolved do involve patterned
textures:

- The checkered floor in the balcony scene, which got brighter, uses basically
the same construction as your scene.

- The object_pattern scene, which shows some strange artifacts, uses an
object_map on textures.


I guess these are insofar radiosity related as they only show in radiosity
shots. There seems to be an issue with how the indirect illumination intensity
returned by the radiosity code is "post-processed".

Internally, the indirect illumination intensity is referred to as "ambient";
maybe this led to some mixup of variables, causing this indirect illumination
intensity to be mistakenly used as ambient term for additional texture layers -
or something along these lines. Or it is just summed up for layered textures,
instead of being weighted properly.

Post a reply to this message

clipka wrote:

> Internally, the indirect illumination intensity is referred to as "ambient";
> maybe this led to some mixup of variables, causing this indirect illumination
> intensity to be mistakenly used as ambient term for additional texture layers -
> or something along these lines. Or it is just summed up for layered textures,
> instead of being weighted properly.
> 

Just to make it clear. The layered textures did not cause this problem, 
(maybe they cause artifacts if the max_trace_level is not high enough, 
but this is another story). It is just the patterned texture statement.

texture {
   checker // or anything else
   texture {T1}, texture {T2}
  ...
}

And as mentioned in my other post, something strange does happen with 
texture maps even when no radiosity is involved.

-Ive

Post a reply to this message

Ive <"ive### [at] lilysoftorg"> wrote:
> #declare T_Floor = texture {
>    checker
>    texture {T_FloorWhite_simple}, texture {T_FloorWhite_simple}
>    rotate x*90
>    rotate y*45
>    scale 117.2/2
>    translate <-20.0, 0, 0>
> }

Ta-ding!

You know what? That stupid Trace::ComputeLightedTexture() code passes the wrong
co-ordinates to the radiosity code!

Instead of "world co-ordinates" it actually passes the co-ordinates with the
texture translations applied. Incredibly stupid error. And a one-liner to fix.
In file "trace.cpp", locate the line reading:

radiosity.ComputeAmbient(ray, *ipoint, rawnormal, layNormal, ambCol, weight *
max_Radiosity_Contribution, ticket);

replace with:

radiosity.ComputeAmbient(ray, Vector3d(isect.IPoint), rawnormal, layNormal,
ambCol, weight * max_Radiosity_Contribution, ticket);


This actually gets both the "balcony.pov" and "object_pattern.pov" scenes
perfectly back to 3.6 look.


Thanks for your help! Your scene and experiments provided essential input for
fixing this issue.

Post a reply to this message

Ive <"ive### [at] lilysoftorg"> wrote:
> And as mentioned in my other post, something strange does happen with
> texture maps even when no radiosity is involved.

Can you provide a sample scene for that, too?

I bet if there is *one* mixup of ipoint vs. isect.IPoint (IPoint and
Intersection->IPoint in the 3.6 code), then chances are there's more of this
kind to be found...

Post a reply to this message

clipka escreveu:
> Ive <"ive### [at] lilysoftorg"> wrote:
>> #declare T_Floor = texture {
>>    checker
>>    texture {T_FloorWhite_simple}, texture {T_FloorWhite_simple}
>>    rotate x*90
>>    rotate y*45
>>    scale 117.2/2
>>    translate <-20.0, 0, 0>
>> }
> 
> Ta-ding!

Good.  But his previous texture definition used a finish block with 
diffuse 1 and that is too high, I guess.  The default is 0.6 if I'm not 
wrong...

Post a reply to this message

nemesis <nam### [at] gmailcom> wrote:
> clipka escreveu:
> > Ive <"ive### [at] lilysoftorg"> wrote:
> >> #declare T_Floor = texture {
> >>    checker
> >>    texture {T_FloorWhite_simple}, texture {T_FloorWhite_simple}
> >>    rotate x*90
> >>    rotate y*45
> >>    scale 117.2/2
> >>    translate <-20.0, 0, 0>
> >> }
> >
> > Ta-ding!
>
> Good.  But his previous texture definition used a finish block with
> diffuse 1 and that is too high, I guess.  The default is 0.6 if I'm not
> wrong...

Not an issue here, as the color is only rgb 0.55.

And the culprit for the weird look has been clearly identified and successfully
eliminated.

Post a reply to this message

clipka wrote:
> Ive <"ive### [at] lilysoftorg"> wrote:
>> And as mentioned in my other post, something strange does happen with
>> texture maps even when no radiosity is involved.
> 
> Can you provide a sample scene for that, too?
> 
> I bet if there is *one* mixup of ipoint vs. isect.IPoint (IPoint and
> Intersection->IPoint in the 3.6 code), then chances are there's more of this
> kind to be found...
> 
> 

Attached is a simple SDL file.

 From my understanding T1 and T2 have to look identical, and they do in 
3.6.1.

-Ive

Post a reply to this message

Attachments:
Download 'us-ascii' (1 KB)

clipka wrote:
> Thanks for your help! Your scene and experiments provided essential input for
> fixing this issue.
> 

You're welcome. Glad to be of any help, finally it's in my own interest ;)

-Ive

Post a reply to this message