|
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Alain <ele### [at] netscapenet> wrote:
> From version 3.6 for any radiosity scene: (also for photons)
> "Cleanup Parse Warning: This rendering uses the following experimental
> feature(s): radiosity. The desing and implementation of these features is likely
> to change in future version of POV-Ray. Full backward compatibility with the
> current implementation is NOT guarenteed."
>
> This tells me that, in future versions, the way to handle radiosity may change.
>
> This also tels me that the result may change from version to version, even if
> the parameters do stay the same.
>
> So, after seeing that warning, if any scene using radiosity, or photons, don't
> give the same final image between 3.6 end 3.7, i'd say that it's NORMAL and
> EXPECTED.
Basically yes - that's why I give up on trying to get 3.7 exactly the same.
However, differences may also be an indicator that something is broken, so
getting 3.7 to behave almost exactly like 3.6 would have given confidence that
the code is "not more broken than 3.6" - meaning that anything damaged in the
transition from C to C++ would have been repaired.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
clipka wrote:
> andrel <a_l### [at] hotmailcom> wrote:
>> I think a relevant question here is: what is a distribution of source.
>> If clipka sends the source or a binary by regular mail to e.g. Thomas is
>> that distribution?
>
> I bet it is.
>
> I could send diffs though, because those portions are all my own work...
>
>> Another one: if clipka had started from the 3.16 source would that have
>> made a difference?
>
> If it was in the current state: No; there's too much functionality missing
> (compared to 3.6) in the current stuff I have, and reduced-functionality
> versions may not be distributed either.
>
>
>
Except that diffs contain itty-bitty bits of the source files in them.
:)
-Mike
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"andrel" <a_l### [at] hotmailcom> schreef in bericht
news:495### [at] hotmailcom...
>>
>> The redistribution of the beta source code is prohibited. There won't be
>> a permission for anyone to distribute the beta source code or binary in
>> any other form. The purpose of making the beta source code available is
>> to get submissions of bug fixes that will be added to the official beta
>> source code and beta binaries - assuming they work, of course ;-)
>>
>
> I think a relevant question here is: what is a distribution of source. If
> clipka sends the source or a binary by regular mail to e.g. Thomas is that
> distribution? or must it be publicly available to be one. If it is the
> first then collaboration to implement and test improvements of beta source
> is effectively impossible. I can think of reasons to do it that way. One
> would be that source in this beta (double beta?) stage should be
> coordinated by a POV team member. But, which one should that be? In this
> specific case of radiosity: who is coordinating that and would that person
> in this case give permission to create a test version for a selected group
> to use?
>
> Another one: if clipka had started from the 3.16 source would that have
> made a difference?
Right. The Real World is tougher than I imagined (and rightly so, I suppose)
:-)
We need a creative solution to solve this conundrum, because it would be too
absurde if, for legal reasons, improvement testing of beta elements could
not procede one way or another. I suppose that the best way to go would be
to implement Clipka's work in some beta, have it tested and reported back by
the community. Following which, decisions can be made about further
implementation or trashing.
My world view is simple, I know, but we have to start somewhere.
Thomas
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 29-Dec-08 23:58, Warp wrote:
> clipka <nomail@nomail> wrote:
>> So yes, that should do: A loop typically taking less than two iterations (the
>> most expensive part probably being the RNG) and a square root. Quite
>> inexpensive after all.
>
> When you project the point to the hemisphere, you'll probably need three
> multiplications and a square root. That's going to be much more expensive
> than the RNG. (High-quality RNGs are very fast. They are faster than a LCG,
> which consists of one integer multiplication and addition.)
but sin and cos are (much?) more costly than sqrt and multiplication is
comparatively negligible.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
andrel <a_l### [at] hotmailcom> wrote:
> On 29-Dec-08 23:58, Warp wrote:
> > clipka <nomail@nomail> wrote:
> >> So yes, that should do: A loop typically taking less than two iterations (the
> >> most expensive part probably being the RNG) and a square root. Quite
> >> inexpensive after all.
> >
> > When you project the point to the hemisphere, you'll probably need three
> > multiplications and a square root. That's going to be much more expensive
> > than the RNG. (High-quality RNGs are very fast. They are faster than a LCG,
> > which consists of one integer multiplication and addition.)
> but sin and cos are (much?) more costly than sqrt and multiplication is
> comparatively negligible.
I was commenting to his estimation that the RNG would be the most
expensive part of the calculation. Certainly not true. I would estimate
that one single sqrt() call will be several times slower than pulling a
value from a high-quality RNG.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
clipka wrote:
> Severi Salminen <sev### [at] NOTTHISsaunalahtifiinvalid> wrote:
>> double x,y,z;
>>
>> do{
>> x = 2.0 * rNG.randomNumberClosed() - 1.0;
>> z = 2.0 * rNG.randomNumberClosed() - 1.0;
>> }
>> while(x*x + z*z > 1.0);
>>
>> y = sqrt(1.0 - (x*x + z*z));
>
> This can be optimized to:
>
> double x,y,z,rSquare;
>
> do{
> x = 2.0 * rNG.randomNumberClosed() - 1.0;
> z = 2.0 * rNG.randomNumberClosed() - 1.0;
> rSquare = x*x + z*z;
> }
> while(rSquare > 1.0);
>
> y = sqrt(1.0 - rSquare);
>
> Or maybe this is even a bit faster (and actually a tiny bit more defensively
> coded):
>
> double x,y,z,ySquare;
>
> do{
> x = 2.0 * rNG.randomNumberClosed() - 1.0;
> z = 2.0 * rNG.randomNumberClosed() - 1.0;
> ySquare = 1.0 - (x*x + z*z);
> }
> while(ySquare < 0.0);
>
> y = sqrt(ySquare);
>
No need to optimize the code, that's the job of the compiler. Any modern
compiler will notice the common subexpressions and optimize them. I just
did a small test with all three versions above compiled with "gcc -S
-O2" (gcc 4.1.2 on x86_64 linux). The produced assembly is virtually
identical for all three cases, the last one actually has the most
instructions generated (extra moves mostly).
The thing to learn from this, and it's my experience from work too, is
that you should write code that is easy to read and maintain rather than
try to be clever with optimizations.
When I'm on the subject of optimization I like to mention that profile
based optimizations can boost the performance of povray quite a bit.
Look at the -fprofile-generate and -fprofile-use options to gcc.
Sorry for going a bit off-topic. I'll go back to lurking now. I'm
following the development of the radiosity code with excitement. Keep up
the good work.
Oh, and happy new year!
--
Daniel Nilsson
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Daniel Nilsson <pov### [at] daniel-nilssoncom> wrote:
> The thing to learn from this, and it's my experience from work too, is
> that you should write code that is easy to read and maintain rather than
> try to be clever with optimizations.
IMO this:
variable = someLengthyCalculation;
useVariable(variable);
useVariableForSomethingElse(variable);
is more readable than:
useVariable(someLengthCalculation);
useVariableForSomethingElse(someLengthCalculation);
especially if "someLengtyCalculation" is even a bit complicated. (Basically
the variable makes it very clear that the two expressions are, in fact, the
one and same, something which might not be visually obvious if the expression
is repeated.)
As a bonus, you'll make absolutely sure the compiler won't calculate
it twice. (In some cases it might be that the compiler is forced to
calculate it twice because it can't know if some called function has
side-effects.)
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 30-Dec-08 13:00, Warp wrote:
> andrel <a_l### [at] hotmailcom> wrote:
>> On 29-Dec-08 23:58, Warp wrote:
>>> clipka <nomail@nomail> wrote:
>>>> So yes, that should do: A loop typically taking less than two iterations (the
>>>> most expensive part probably being the RNG) and a square root. Quite
>>>> inexpensive after all.
>>> When you project the point to the hemisphere, you'll probably need three
>>> multiplications and a square root. That's going to be much more expensive
>>> than the RNG. (High-quality RNGs are very fast. They are faster than a LCG,
>>> which consists of one integer multiplication and addition.)
>
>> but sin and cos are (much?) more costly than sqrt and multiplication is
>> comparatively negligible.
>
> I was commenting to his estimation that the RNG would be the most
> expensive part of the calculation. Certainly not true. I would estimate
> that one single sqrt() call will be several times slower than pulling a
> value from a high-quality RNG.
>
sqrt has at worst N/2 iteration, with N the number of significant bits.
That is a naive implementation. I thought there are even faster
algorithms. Cheap calculators often have a button for sqrt, implying
probably that they have a (naive) hardware implementation. I don't know
if it is available also on more complex processors.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 30-Dec-08 9:00, Thomas de Groot wrote:
> "andrel" <a_l### [at] hotmailcom> schreef in bericht
> news:495### [at] hotmailcom...
>>> The redistribution of the beta source code is prohibited. There won't be
>>> a permission for anyone to distribute the beta source code or binary in
>>> any other form. The purpose of making the beta source code available is
>>> to get submissions of bug fixes that will be added to the official beta
>>> source code and beta binaries - assuming they work, of course ;-)
>>>
>> I think a relevant question here is: what is a distribution of source. If
>> clipka sends the source or a binary by regular mail to e.g. Thomas is that
>> distribution? or must it be publicly available to be one. If it is the
>> first then collaboration to implement and test improvements of beta source
>> is effectively impossible. I can think of reasons to do it that way. One
>> would be that source in this beta (double beta?) stage should be
>> coordinated by a POV team member. But, which one should that be? In this
>> specific case of radiosity: who is coordinating that and would that person
>> in this case give permission to create a test version for a selected group
>> to use?
>>
>> Another one: if clipka had started from the 3.16 source would that have
>> made a difference?
>
>
> Right. The Real World is tougher than I imagined (and rightly so, I suppose)
> :-)
>
> We need a creative solution to solve this conundrum, because it would be too
> absurd if, for legal reasons, improvement testing of beta elements could
> not proceed one way or another.
The issue only raised it's head now because the beta source is
available. Precisely for the reason that it can be improved by others
that the regular POV team. It seems that they did not completely think
through what the consequences would be if someone would actually do it. ;)
I'd be very interested in what Chris has to say about it. He seems a bit
quite.
> I suppose that the best way to go would be
> to implement Clipka's work in some beta, have it tested and reported back by
> the community. Following which, decisions can be made about further
> implementation or trashing.
>
> My world view is simple, I know, but we have to start somewhere.
There are a number of ways to solve it, roughly in order of (my) preference:
- as you suggest, put it in a regular beta 3.17
- create a working group of clipka and a select group of beta testers to
tackle this radiosity issue under supervision of a team member.
- give clipka (and future similar cases) permission to do so for a
limited time and only for this specific test (I think the legal wording
allows for special permissions from the POV team)
- add clipka (temporarily) to the team.
- handle everything by regular (encrypted) mail and don't tell anyone.
Any more alternatives?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Alain <ele### [at] netscapenet> wrote:
> "Cleanup Parse Warning: This rendering uses the following experimental
> feature(s): radiosity. The desing and implementation of these features is likely
> to change in future version of POV-Ray. Full backward compatibility with the
> current implementation is NOT guarenteed."
>
> This tells me that, in future versions, the way to handle radiosity may change.
>
> This also tels me that the result may change from version to version, even if
> the parameters do stay the same.
>
> So, after seeing that warning, if any scene using radiosity, or photons, don't
> give the same final image between 3.6 end 3.7, i'd say that it's NORMAL and
> EXPECTED.
That message was part of 3.5 as well and perhaps earlier. An "experimental"
feature that has been around for, what?, 10 years. That's even longer than
Google eternal betas... :))
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|