![](/i/fill.gif) |
![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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'
![voro-viewa-31m_35s.jpg](/povray.binaries.images/attachment/%3Cweb.4d9d10aec2af4450b86cffc90%40news.povray.org%3E/voro-viewa-31m_35s.jpg?ttop=443866&toff=2000&preview=1)
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
"Samuel Benge" <stb### [at] hotmail com> 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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
On Thu, 07 Apr 2011 03:17:34 +0200, Samuel Benge <stb### [at] hotmail com>
wrote:
Watch out! 1024 falling eggs!
--
-Nekar Xenos-
"The spoon is not real"
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
On 4/7/2011 5:18 AM, Robert McGregor wrote:
> "Samuel Benge"<stb### [at] hotmail com> 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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
> 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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
On 4/7/2011 12:25 PM, Nekar Xenos wrote:
> On Thu, 07 Apr 2011 03:17:34 +0200, Samuel Benge <stb### [at] hotmail com>
> wrote:
>
> Watch out! 1024 falling eggs!
I feel sorry for the bird who dropped them ;)
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
>> 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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
> 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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |