|
 |
Hi guys:
Sorry if this an already known issue: I did my best to find a reference to
it in the newsgroups, but found nothing.
This could be a nice way to accelerate rendering of quartic surfaces
(including tori, and this means a better world for H. Simpson). When you
use the analytical solver instead of the Sturm solver, no matter what exact
method you use, you need to solve an auxiliary cubic equation. A cubic
equation always has one or three roots... and as far as I know, it doesn't
matters which root you use, so you could always use the first root.
The quartic solver, instead, solves cubic equations via the general cubic
solver. It means that, in a great number of cases, the cubic solver will
have to compute two innecesary roots... and worse, this implies two
unnecesary calls to trascendental functions and a couple of floating point
divisions. This makes room for further optimizations, if you add an
additional specialized cubic solver for this special case. For instance,
the multiplier for the cubic term is always 1.0. You don't need to supply
an array to receive any roots, so you end up with a very simple prototype:
// Sorry :), this is simplified C# syntax
double Special3Solver(double a2, double a3, double a4) { }
I have test this change in a highly simplified C# ray tracing prototype...
and it pays. Since I'm not an expert in floating point operations, I'm not
sure whether this change could have any implications on precision (but it
seems it won't). Even in that case, I would check the performance of an
additional iteration of the Newton-Horner method to enhance the solution.
Since the original root would be very near to the exact root, I think this
could be faster than a raw Sturm solver.
Am I missing something?
Regards,
Ian
Post a reply to this message
|
|
|
|
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
IanM wrote:
> Hi guys:
don't be so sexist :-)
[Snip an interesting idea]
> Am I missing something?
I say, but I have absolutly no authority : "
- You take the source,
- make a reference image-set with original source code for all the
pov-scene you can find (start with the ones delivered with the source:
allanim and allscene (as well as portfolio...)), at a decent size.
- make your patch to use your simpler solver
- recomputes the whole image-set with your new code.
Then compares if there is any difference in the pictures (imagemagick
has tools for that), and what is the gain or loss of performance
(both on a specific scene and on average)
IF and ONLY IF there is no difference on the images, and there is a real
time-gain, then you might want to push your faster code in think like
megapov... and make a lot of advertisement about it so it get taken by
the pov-team..."
Now I'm always afraid of mathematical ideas applied to computational
performance. (the notion of precision that can be achieved on a computer
is something that most abstract mathematicians do not understand.
For instance, 0.1 x 10 is NOT 1.0000 !
(well in fact, there is no way to represent 0.1 exactly with classical
floating point convention). So beware of idea that works fine on paper,
but fails for some computational values.
Moreover, when you said that 2 of the 3 roots are not needed, a full
revue of the relevant code should prove that. Same goes for the cubic
term being always 1... make a web page (with two columns of code) to
explain the changes you are suggesting.
- --
Eifersucht ist die Leidenschaft, die mit Eifer sucht, was Leiden schafft.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFDHuEDs/YJ43cSjHIRAkPGAJ9aggqoJTsF7aMgll622DHyGZQnHQCfQElh
uhD4G1Td8KYoAfUs1rcd7aE=
=TCZ7
-----END PGP SIGNATURE-----
Post a reply to this message
|
|
