You'll notice something very unsettling about the green ball...

It's the other feature of my patch (currently engeniusly titled GE-POV) -- 
no_radiosity. This feature works in the same way as no_shadow or no_image 
only it affects radiosity calculations.
What is the use of this you might ask? If you want to have a visible light 
source as a bright ambient object but still have a conventional light 
source inside and use radiosity, the light from the ambient object and the 
conventional light source would conflict resulting in overexposed lighting. 
This effect is especially dramatic when you use really bright objects (eg. 
ambient 10) to create visible "dings" on objects as opposed to the 
unrealistic specular component. Using no_radiosity on the ambient object 
for the visible light source would fix this issue completely.
no_radiosity is used not only on the green ball but also on the ceiling 
light ambient object to prevent the double lighting conflict issue.

PS. dispersion_jitter, the first feature of GE-POV is demonstrated in my 
guessing game article posted yesterday.

Post a reply to this message

Attachments:
Download 'no_radiosity-test.png' (76 KB)

Preview of image 'no_radiosity-test.png'

Greg Edwards <edw### [at] hotmailcomremovethis> wrote in
news:5uo4aatm80da.1vz81td2bfk8o$.dlg@40tude.net: 

> You'll notice something very unsettling about the green ball...
> 
> It's the other feature of my patch (currently engeniusly titled
> GE-POV) -- no_radiosity. This feature works in the same way as
> no_shadow or no_image only it affects radiosity calculations.


  Does this also result in a decreased render time if used on Isosurfaces?  
I have a scene that uses Iso-rocks, which kill the render time if radiosity 
is used.  The rocks themselves get little to no benefit from the radiosity 
calculations, so being able to label them with no_radiosity would be ideal 
if that negated the increased render time.

Rich Allen

Post a reply to this message

On 2 Mar 2003 10:55:38 -0500, Rich wrote:

> Greg Edwards <edw### [at] hotmailcomremovethis> wrote in
> news:5uo4aatm80da.1vz81td2bfk8o$.dlg@40tude.net: 
> 
>> You'll notice something very unsettling about the green ball...
>> 
>> It's the other feature of my patch (currently engeniusly titled
>> GE-POV) -- no_radiosity. This feature works in the same way as
>> no_shadow or no_image only it affects radiosity calculations.
> 
> 
>   Does this also result in a decreased render time if used on Isosurfaces?  
> I have a scene that uses Iso-rocks, which kill the render time if radiosity 
> is used.  The rocks themselves get little to no benefit from the radiosity 
> calculations, so being able to label them with no_radiosity would be ideal 
> if that negated the increased render time.
> 
> Rich Allen

It may, but the no_radiosity keyword means that the no_radiosity object 
will not affect the radiosity of other objects. In the scene I posted, the 
green ball had no_radiosity but it still had radiosity lighting. The 
difference it made was that the no_radiosity green ball had no little dark 
shadow on the ground like the yellow ball did. no_radiosity should prevent 
self-casting radiosity (similar to self-casting shadows) which may speed up 
your isosurface render and the rendering of the surrounding objects should 
have a slight speed increase. Just keep in mind the funny shadows that 
no_radiosity objects have. (like the green ball)
Another speed issue is that the current binary (compiled with Visual C++ 6 
Pro) runs noticeably slower than the original POV compiled using the Intel 
compiler. I'll try and address this when I make a public release. I'll be 
sure to post the source too.

Post a reply to this message

> It may, but the no_radiosity keyword means that the no_radiosity
> object will not affect the radiosity of other objects. In the scene I
> posted, the green ball had no_radiosity but it still had radiosity
> lighting. The difference it made was that the no_radiosity green ball
> had no little dark shadow on the ground like the yellow ball did.
> no_radiosity should prevent self-casting radiosity (similar to
> self-casting shadows) which may speed up your isosurface render and
> the rendering of the surrounding objects should have a slight speed
> increase. Just keep in mind the funny shadows that no_radiosity
> objects have. (like the green ball) Another speed issue is that the
> current binary (compiled with Visual C++ 6 Pro) runs noticeably slower
> than the original POV compiled using the Intel compiler. I'll try and
> address this when I make a public release. I'll be sure to post the
> source too. 

Sounds promising, I'm looking forward to seeing what it can do.

Rich

Post a reply to this message