 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Mon, 07 Apr 2003 21:32:24 +0200, "Thorsten Froehlich" <tho### [at] trf de>
wrote:
> In article <78b39vs5bju40d2eu1otajq7hksq0imic0@4ax.com> , ABX
> <abx### [at] abxartpl> wrote:
>
> > So there is no way to use photons data for multiplatform distributed rendering?
> > I'm surprised.
>
> Since when is "multiplatform distributed rendering" a feature of an official
> version of POV-Ray?
It's very popular to split animation into parts rendered on various machines.
6.10.5.4: "The photon map itself is view-independent, so if you want to animate
a scene that contains photons and you know the photon map will not change during
the animation, you can save it on the first frame and then load it for all
subsequent frames". Perhaps this should be extended about binary nature of this
file and portability limitations.
ABX
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <qa159vss0903hu8oms990f7nees385mv0q@4ax.com> , ABX
<abx### [at] abxartpl> wrote:
> Perhaps this should be extended about binary nature of this
> file and portability limitations.
No, because that is not of concern of, nor understandable by, users. There
is such a thing as "too much" documentation for users. Keep in mind this
document isn't a software engineering style document, but a simple user
manual. Users are not be able able to understand what is behind it because
they cannot know the technical background. Thus, it doesn't belong into a
user manual.
Thorsten
____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde
Visit POV-Ray on the web: http://mac.povray.org
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Thorsten Froehlich wrote:
>In article <qa159vss0903hu8oms990f7nees385mv0q[at]4ax.com> , ABX
><abx### [at] abxartpl> wrote:
>
>> Perhaps this should be extended about binary nature of this
>> file and portability limitations.
>
>No, because that is not of concern of, nor understandable by, users. There
>is such a thing as "too much" documentation for users. Keep in mind this
>document isn't a software engineering style document, but a simple user
>manual. Users are not be able able to understand what is behind it because
>they cannot know the technical background. Thus, it doesn't belong into a
>user manual.
>
> Thorsten
Then maybe there need to be two manuals. One for regular users, and one for
power users. The first one could be a stripped down version of the current
documentation, since it already has several topics that are covered in
graphic mathematical detail.
The second one could be a beefed up version of the current documentation,
for those who are curious about how the innards work, without having to
resort to the most in-depth documentation, i.e. the source code. I find
myself venturing into the code to see how things work that should be
documented, such as how POV-Ray handles refraction between multiple objects
(such as water in a glass bottle; see my thread a couple posts before this
one).
In fact, my latter example (refraction) is not some esoteric quirk that no
one will ever use. It is a very commonly used feature that, in my opinion,
was implemented incorrectly. Had there been better documentation, perhaps
the design team would have found the flaw earlier (nothing points out a
mistake like trying to document how something works), or someone else would
have come forward with a fix earlier.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I've cut the parse time for a single frame from 45 seconds to 6.5 seconds.
Slight improvement when doing a 1500 frame animaiton *g*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Retsam wrote:
> Then maybe there need to be two manuals. One for regular users, and one for
> power users.
You obviously have no clue what is involved in just maintaining the current
documentation and all the hard tedious work that went into getting it where
it is now.
--
Ken Tyler
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
