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