Hi,

Nothing really huge here, or even artistically noteworthy. Just a largish render
of 1024 non-intersecting spheres. The calculations were sped up thanks to
neighborhood evaluation via voro++. The points were spaced iteratively over 20
frames using shellout commands in conjunction with an .ini file. For some reason
though, it doesn't really kick in until the 3rd frame :(

I thought I'd also put 3.7's radiosity to the test, as well as the new
area_illumination feature. The radiosity is working wonderfully, but the area
illuminating area_lights... not so good. Despite the fact that I threw 32x32
samples at it along with with adaptive sampling set at 2, artifacts still
appear. Maybe I should raise the adaptation value... (...) Looking at the docs,
I most certainly should raise it.

Anyway, this method is really going to come in handy!

~Sam

Post a reply to this message

Attachments:
Download 'voro-viewa-31m_35s.jpg' (270 KB)

Preview of image 'voro-viewa-31m_35s.jpg'

"Samuel Benge" <stb### [at] hotmailcom> wrote:
> Hi,
>
> Nothing really huge here, or even artistically noteworthy. Just a largish render
> of 1024 non-intersecting spheres. The calculations were sped up thanks to
> neighborhood evaluation via voro++.

Looks great Sam; I keep thinking about how really useful this technique is...
Does this method handle spheres of various sizes as well? What about a pile of
objects, say inner tubes? I guess it would be quite a bit tricker for
non-uniformly shaped objects.

-------------------------------------------------
www.McGregorFineArt.com

Post a reply to this message

On Thu, 07 Apr 2011 03:17:34 +0200, Samuel Benge <stb### [at] hotmailcom>  
wrote:

Watch out! 1024 falling eggs!

-- 
-Nekar Xenos-

"The spoon is not real"

Post a reply to this message

On 4/7/2011 5:18 AM, Robert McGregor wrote:
> "Samuel Benge"<stb### [at] hotmailcom>  wrote:
>> Hi,
>>
>> Nothing really huge here, or even artistically noteworthy. Just a largish render
>> of 1024 non-intersecting spheres. The calculations were sped up thanks to
>> neighborhood evaluation via voro++.
>
> Looks great Sam; I keep thinking about how really useful this technique is...
> Does this method handle spheres of various sizes as well?

Hey Robert. Yeah, It can deal with varying sphere sizes. At first I 
thought voro++ was mangling the order of my points, but this does not 
appear to be the case. This means I can maintain a list of sphere sizes 
(or just use the same random seed) in-POV without having to export the 
radii to voro++. Other particle-specific data can be maintained as well.

> What about a pile of
> objects, say inner tubes? I guess it would be quite a bit tricker for
> non-uniformly shaped objects.

The placement of non-spherical objects is beyond the scope of the 
current setup, though some interesting things will be possible. For 
instance, after a mass of evenly distributed cells is produced, an 
algorithm can be built to "walk" through the point/neighbor lists, with 
entries destroyed each time a cell is used. This should allow one to 
place non-intersecting cylindrical objects or sphere_sweeps within the 
cell mass.

~Sam

Post a reply to this message

> Hi,
>
>
> I thought I'd also put 3.7's radiosity to the test, as well as the new
> area_illumination feature. The radiosity is working wonderfully, but the area
> illuminating area_lights... not so good. Despite the fact that I threw 32x32
> samples at it along with with adaptive sampling set at 2, artifacts still
> appear. Maybe I should raise the adaptation value... (...) Looking at the docs,
> I most certainly should raise it.
>
> Anyway, this method is really going to come in handy!
>
> ~Sam

Interesting.

You have some dificult spots with your area_light.
You can try to reduce the dimention a little.
You can try 33x33, 65x65 or even 129x129. Those values match beter with 
the adaptive algorythm than 32x32.
Try adaptive 3 or maybe 4.
I don't know if your light is circular, but there are some case where it 
can make a difference.

The artefacts I see don't seems related to area_illumination.



Alain

Post a reply to this message

On 4/7/2011 2:35 PM, Alain wrote:

>> Hi,
>>
>> I thought I'd also put 3.7's radiosity to the test, as well as the new
>> area_illumination feature. The radiosity is working wonderfully, but
>> the area
>> illuminating area_lights... not so good. Despite the fact that I threw
>> 32x32
>> samples at it along with with adaptive sampling set at 2, artifacts still
>> appear. Maybe I should raise the adaptation value... (...) Looking at
>> the docs,
>> I most certainly should raise it.
>>
>> Anyway, this method is really going to come in handy!
>>
>> ~Sam
>
> Interesting.
>
> You have some dificult spots with your area_light.
> You can try to reduce the dimention a little.
> You can try 33x33, 65x65 or even 129x129. Those values match beter with
> the adaptive algorythm than 32x32.

Ah, that's good to know.

> Try adaptive 3 or maybe 4.
> I don't know if your light is circular, but there are some case where it
> can make a difference.

It's not...

> The artefacts I see don't seems related to area_illumination.

You're probably right.

All-in-all, the area_illumination feature is great :)

Post a reply to this message

On 4/7/2011 12:25 PM, Nekar Xenos wrote:
> On Thu, 07 Apr 2011 03:17:34 +0200, Samuel Benge <stb### [at] hotmailcom>
> wrote:
>
> Watch out! 1024 falling eggs!

I feel sorry for the bird who dropped them ;)

Post a reply to this message

>> You can try 33x33, 65x65 or even 129x129. Those values match beter with
>> the adaptive algorythm than 32x32.
>
> Ah, that's good to know.
>

Good dimentions for adaptive are 5, 9, 17, 33, 65, 129, 257, 513, 1025,...

You take the powers of 2 and add 1 to the result.



Alain

Post a reply to this message

On 4/7/2011 3:35 PM, Alain wrote:

>
>>> You can try 33x33, 65x65 or even 129x129. Those values match beter with
>>> the adaptive algorythm than 32x32.
>>
>> Ah, that's good to know.
>
> Good dimentions for adaptive are 5, 9, 17, 33, 65, 129, 257, 513, 1025,...
>
> You take the powers of 2 and add 1 to the result.

Thanks Alain! Is that in the docs? I can't seem to find it. I wonder if 
it should be mentioned somewhere...

Post a reply to this message

> On 4/7/2011 3:35 PM, Alain wrote:

>>
>>>> You can try 33x33, 65x65 or even 129x129. Those values match beter with
>>>> the adaptive algorythm than 32x32.
>>>
>>> Ah, that's good to know.
>>
>> Good dimentions for adaptive are 5, 9, 17, 33, 65, 129, 257, 513,
>> 1025,...
>>
>> You take the powers of 2 and add 1 to the result.
>
> Thanks Alain! Is that in the docs? I can't seem to find it. I wonder if
> it should be mentioned somewhere...

Not clearly in the documentations, anywhere. It should becomes obvious 
when you carefully read the explanation of the adaptive procedure. The 
illustrations do help.

For adaptive 0, you start with the corner elements. A 2x2 array: 2^0 +1 
= 2. If the elements are all shadowed or all visible, you assume that 
you are totaly in a shadow or totaly illuminated. All the points between 
the conserned points are assumed to have the same visibility of the light.

If not, you take the middle points between the elements that don't have 
the same status.
Now, a 3x3 aray: 2^1 +1.

On the next step, it becomes a 5x5: 2^2 +1, then 9x9: 2^3 +1, then 
17x17: 2^4 +1,...(2^n +1) aray.
For most of those array's elements, you don't need to make any test, 
thus the speed up.

The documentation also tell that with adaptive 1, you start with a 3x3 
aray, and a 5x5 one for adaptive 2, limited by the actual dimention of 
the defined aray. adaptive 2 have no effect on a 4x4 aray.

If the dimentions are not in the list, the subdivision becomes 
asymetrical and you get penumbrae part that no longer have the same 
number of samples for the same area.



Alain

Post a reply to this message