So,

I imported a mesh tree (from LightWave, through PoseRay), and attempted 
to render it with radiosity. Wouldn't you know it, there was that 
unfortunate bug resurfacing, causing certain polygons to render black 
with only a few light sparkles as a poor concession for such a great 
lack of result.

Tracking down the reason, I concluded that the main contributing factor 
was surely the application of a UV-mapped texture. Removal of said 
surface with the application of a cheap substitute brought radiosity 
back in full force. It's a quick fix which leaves me without the benefit 
of conforming UV-mapped textures.

POV-Ray 3.7b25
WinXP Home

Submitted for your consideration~

Sam

Post a reply to this message

[To avoid a beating, I state here and now for the benefit of anyone it might
concern that I fully understand that radiosity in 3.7 is alpha quality only. I
will not respond to comments that do nothing but point this out. I'm doing
nothing but investigating the only major issue I've found with it in my
renders. It's not as if I've shot your dog. Ta]


stbenge <stb### [at] hotmailcom> wrote:

> Tracking down the reason, I concluded that the main contributing factor
> was surely the application of a UV-mapped texture. Removal of said
> surface with the application of a cheap substitute brought radiosity
> back in full force. It's a quick fix which leaves me without the benefit
> of conforming UV-mapped textures.

I wonder if it's connected with the apparent radiosity/UV-mapping problem
apparently demonstrated by the appended scene. I had a problem with polygons in
uv-mapped meshes seemingly being illuminated by ambient light sources even when
they should be shadowed.

After some work I found that this particular problem at least is not
mesh-specific, and in the scene below you can see that the inner, ambient green
sphere, is (according to 3.7 radiosity) managing to illuminate the exterior
surface of the outer, diffuse-shaded sphere.

It only happens (that I've found) if you place the uv_mapping keyword outside
the pigment/normal definition. If, in the scene below, you comment out the
existing uv_mapping line and uncomment the uv_mapping line in the pigment, you
get a UV-mapped pigment but without the radiosity artefacts.

I am investigating in the code but have not had much time; so far all I've found
is that the UV mapping for texture and for pigment get evaluated in different
places in the code (surprise! no) and that they probably end up producing
different perturbed points at which radiosity is sampled. I have not had time
yet to work out whether this actually means anything.

Tom

///////////////////////// SDL BEGIN

sphere {
  0, 1
  texture {
    pigment { green 1 }
    finish { ambient 1 diffuse 0 }
  }
}

sphere {
  0, 1.5
  texture {
    uv_mapping
    pigment {
    //  uv_mapping
      checker scale 0.1
    }
    finish { ambient 0 diffuse 1 }
  }
}

radiosity {}

camera {
  location 5*z
  look_at 0*z
}

///////////////////////// SDL END

Post a reply to this message

Really, do not bother testing radiosity. Nothing a user can discover is of 
_any_ help in getting radiosity working again. Testing it, you are just 
wasting your time. Sorry!

	Thorsten

Post a reply to this message

Thorsten Froehlich wrote:
> Really, do not bother testing radiosity. Nothing a user can discover is 
> of _any_ help in getting radiosity working again. Testing it, you are 
> just wasting your time. Sorry!
> 
>     Thorsten

Thanks for letting me know! It's hard not to play with it, since I'd 
rather not resort to using 3.6 for final renders.

Sam

Post a reply to this message