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);

(I guess comparing two floats is roughly as expensive as computing their
difference; at least this is the case for integers; and comparing a float with
zero is a piece of cake.)

I also fancy that it would be favorable from a performance point of view to pull
*signed* floats in the range of [-1..1] directly out of the random stream,
because it would just be a matter of filling in one more random bit (namely the
sign bit). It would double the chance of getting a zero, but we can probably
invest some of the time saved by the elimination of a multiplication and
subtraction to filter out negative-zero values (which would occur once in 2^24
rolls for single-precision floats).

But that's probably a RNG design thing.

Post a reply to this message

Warp <war### [at] tagpovrayorg> wrote:
>   You still have to rotate it so that the hemisphere is tangential to
> the surface. Probably requires multiplication with a matrix.

POV uses two cross-product operations for that.

Post a reply to this message

Warp <war### [at] tagpovrayorg> wrote:
> > Takes a lot of samples though to get flat and comparatively rough surfaces to
> > look good, so be prepared for overnight renders.
>
>   Not very feasible with very complex scenes which may have other
> slow-to-render elements, unless you have a couple of years to wait for
> the render to finish.

It gets less dramatic if your other slow-to-render elements can be boiled down
to jitter as well; e.g. for media effects, you can crank down the quality and
rely on a lot of jitter, too.

You'll admittedly run into problems when your slow-to-render elements are
geometric shapes, like isosurfaces for instance.

Post a reply to this message

clipka nous illumina en ce 2008-12-29 01:06 -->
> .... no, don't panic - I'll keep working on the radiosity as such.
> 
> But I definitely give up trying to get 3.7 radiosity exactly reproduce 3.6
> functionality.
> 
> I have dug through the code multiple times, discovered several discrepancies
> between 3.7.beta.29 and 3.6 causing differences in output, identified several
> others that didn't seem to make a change, stumbled across some old flaws I
> intend to fix, and for sentimentality's sake even re-introduced one flaw that
> wasn't there in 3.7 due to slight differences in the software architecture
> (don't worry, I'll take it back out again :)), all to try and re-create the
> same output as 3.6.
> 
> I have come to the point now that plowing through the whole code over and over
> again has ceased to surface any further discrepancies. And I definitely do
> *not* intend to go through *all* the POV code and revert it back to exact 3.6
> functionality (and after all, maybe some modifications may actually be in there
> for good already :)).
> 
> So I conclude that any residual differences must be rooted in changes to some
> other parts of POV-ray code: Media, photons, area lights, multi-layered
> textures - whatever.
> 
> The remaining discrepancies with the scenes I used for testing are:
> 
> - minor difference in brightness on one of the cube's corners in "cornell.pov"
> 
> - differences in brightness on the object-mapped portion of the pill containers
> in "object_pattern.pov"; tests strongly indicate that these are caused by the
> object-mapped texture, not the radiosity per se
> 
> - differences in brightness of various shadowed parts in "balcony.pov"; tests
> were not conclusive about the true origin of the differences.
> 
> - differences in a self-made scene designed to provoke black-splotch artifacts,
> probably related to differences in trace-level counting (note that the
> black-splotch artifacts will be eliminated anyway)
> 
> - differences in another self-made scene (the "Claustrophobia" shot), probably
> related to black-splotch artifacts and therefore of similar origin
> 
> - totally different results with a self-made, very demanding radiosity scene
> which hasn't actually worked as intended with any POV version at all - again,
> possibly due to differences in trace-level counting.
> 
> 
> From what I see, none of these differences do any general harm to the picture
> (except for the pill-container issus); the pictures simply look different, and
> I find it hard to judge which version is more realistic. I'd usually prefer the
> new output.
> 
> 
> Aside from visual differences, the most notable ones are differences in speed.
> Compared with the MegaPOV 64-bit Linux binaries, some scenes take a bit longer
> with the current code, some render a bit faster. It seems that overall,
> radiosity-only scenes benefit, while non-radiosity scenes all render slightly
> slower, and mixed scenes are somewhat indecisive. This is all pure CPU time
> though, and real-time speed benefits a lot on multicore systems.
> 
> 
> If it was my call, I'd say let's just fix the black-splotch thing, get a few
> details more towards the original Ward paper, make a new beta of it, and see
> what reports come in.
> 
> 
> Main remaining issues:
> 
> - Loading/saving of radiosity samples simply doesn't work yet
> 
> - Radiosity shots are currently not 100% reproduci... duca... um... I mean, you
> can't reproduce the 100% same result on every run.
> 
> 
> 
 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.

-- 
Alain
-------------------------------------------------
You know you've been raytracing too long when you have ever said "I don't need 
no steenking modellers!!!"
Stephan Ahonen

Post a reply to this message

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