I think it is worthwhile to put Clipka's Voodoo from 2008 under the 
attention of the users again. :-)

It probably should be done at regular, ten years or so, intervals.

-- 
Thomas

Post a reply to this message

Attachments:
Download 'clipkas pov-ray voodoo - radiosity.pdf' (119 KB)

THANK YOU for posting this; it is a real motherlode of useful information. If I
ever read Clipka's original discussion back then, I had forgotten it. I'm
curious: Did you put together this PDF file, or did Clipka do it? In any case,
thanks.

The mention of upping globle_settings{max_trace_level...} for radiosity is an
interesting bit of info; I didn't know about that, but I had come to the same
conclusion after looking at my test renders' message panes.

It seems that a *few* details in the article are out of date: radiosity's COUNT
is no longer limited to 1600 (which Alain's later comments there make clear);
and I *think* that the mention of  global_settings{ambient .001} is no longer
valid, because radiosity use in v3.8xx (and also 3.7?) turns OFF any ambient
values in a scene -- to 0.0. Please correct me if I'm wrong.

Alain's comments, especially about the new  'importantce'  term, are extremely
useful.

The discussion has many interesting technical points and important formulae that
I'm still absorbing :-)

Post a reply to this message

BTW, something Clipka mentioned seems to be at odds with how radiosity currently
works, at least in v3.8xx:

" The algorithm should be non-random, to be suitable for animations.(For certain
reasons it would be desirable to have a certain random element in the
distribution of rays; however, this typically collides with multiple of the
above criteria and is therefore ignored in POV-Ray.)POV-Ray uses a precomputed
table of directions specially designed to meet all of the above."

My own tests so far show that the rad 'light patches' in animation *are* random
from frame to frame (although that can be minimized to a degree, by using a
saved rad file.) However, perhaps I'm still doing something wrong with my
radiosity settings; I need to carefully re-read your PDF, to see if there are
clues to a solution.

Post a reply to this message

Le 2020-11-25 à 02:35, Thomas de Groot a écrit :
> I think it is worthwhile to put Clipka's Voodoo from 2008 under the 
> attention of the users again. :-)
> 
> It probably should be done at regular, ten years or so, intervals.
> 

This is a very good explanation about how radiosity worked up to version 
3.6 and the early beta of version 3.7.

Several of the points mentioned have changed in the later betas and the 
final release version.

The count value is no longer limited to 1600. The nearest_count can now 
take two values. The ambient is always set to zero when radiosity is in 
use. Introduction of the emission in the finish. Introduction of the 
importance object parameter. And several more changes.

Post a reply to this message

Op 25/11/2020 om 17:45 schreef Alain Martel:
> Le 2020-11-25 à 02:35, Thomas de Groot a écrit :
>> I think it is worthwhile to put Clipka's Voodoo from 2008 under the 
>> attention of the users again. :-)
>>
>> It probably should be done at regular, ten years or so, intervals.
>>
> 
> This is a very good explanation about how radiosity worked up to version 
> 3.6 and the early beta of version 3.7.
> 
> Several of the points mentioned have changed in the later betas and the 
> final release version.
> 
> The count value is no longer limited to 1600. The nearest_count can now 
> take two values. The ambient is always set to zero when radiosity is in 
> use. Introduction of the emission in the finish. Introduction of the 
> importance object parameter. And several more changes.

I have not followed closely all the changes since the Voodoo. It is 
probably worthwhile to get an overview of what has changed; I can then 
make update the Voodoo and turn out a new pdf-file.

I find it a big problem that all information is scattered over the years 
and the newsgroups. So much is lost and sometimes re-discovered several 
times. There is the Documentation of course which represents the basic 
foundation of POV-Ray, but the extra info and expertise of individual 
users is not or hardly brought together comprehensively. It takes time, 
energy, availability, understanding. Not always present together for us 
poor users! ;-)

-- 
Thomas

Post a reply to this message

Thomas de Groot <tho### [at] degrootorg> wrote:
> I find it a big problem that all information is scattered over the years
> and the newsgroups. So much is lost and sometimes re-discovered several
> times. There is the Documentation of course which represents the basic
> foundation of POV-Ray, but the extra info and expertise of individual
> users is not or hardly brought together comprehensively. It takes time,
> energy, availability, understanding. Not always present together for us
> poor users! ;-)

It certainly has been a long-standing issue that many of us have mused about.

Mr. Henderson seems to have methods to search the site.  That would be useful
for quickly digging through it all to uncover what one might be looking for
without resorting to an hour of searching and clicking a profusion of links.

We are where we are, with the state of the software, the development, and the
user-base.  And some of the topics and the expertise have been rendered outdated
by revisions in both software and methods.

As we have issues with accessibility for editing material (spam prevention, etc)
it might be useful to make a copy of the documentation onto a site where it CAN
be edited, and then create extra links and sections that help string it all
together.

I'm a fan of signs and checklists and spreadsheets - because you get all of the
organizational stuff out of the way and then the static object provides its own
directions.  It would be useful to come up with an efficient strategy to sift
through all of the posts and files and cull out any material that doesn't
provide important usage information.   Then a finer sifting and method of
organization could be designed.   People could follow along and review, tag, and
edit posts and files as they had time and inclination.  Very much like a WIKI.

That would be a part of the task dealing with preservation of the existing data
and expertise, with helpful cross-indexing links to make the old posts more
useful.  Maybe tag each added comment with a username and time/date.
That way everything could be sorted and processed in place, while preserving the
entirety of the original record.  Very often the valuable _history_ of the
development is lost, which might offer valuable clues to understanding purpose
and possible solutions/updates.

Another part might be just taking one specific topic - like radiosity, and
writing a user-generated documentation page, along with some working code to
illustrate the usage.  I like the code approach, because it's something that the
end-user/reader can get their hands dirty with, adjust settings and get
instantaneous feedback from, isn't purely speculative - since the parser and
software enforce its accuracy, and can encapsulate a wide number of variations
and combinations through #switch and #if.

Good, extensively commented code is probably the most efficient way to dispel
any misconceptions and get right down to the heart of USING whatever it's about.
 We've all had that section of documentation that we've read 30 times and are
still no closer to implementing a working line of code from.
The primary goal is not to have code that is efficient, or fast - but
instructive and explanatory.  Extra versions / #switch blocks can show how to
make the fundamental operation faster and more efficient, but those are in
addition to the primary code.

Post a reply to this message

Op 26/11/2020 om 16:11 schreef Bald Eagle:
> 
> Thomas de Groot <tho### [at] degrootorg> wrote:
>> I find it a big problem that all information is scattered over the years
>> and the newsgroups. So much is lost and sometimes re-discovered several
>> times. There is the Documentation of course which represents the basic
>> foundation of POV-Ray, but the extra info and expertise of individual
>> users is not or hardly brought together comprehensively. It takes time,
>> energy, availability, understanding. Not always present together for us
>> poor users! ;-)
> 
> It certainly has been a long-standing issue that many of us have mused about.
> 

[snip]

I am not commenting in detail, but I fully agree with what you have 
written. Implementation....

-- 
Thomas

Post a reply to this message