Am 19.10.2017 um 14:11 schrieb Bald Eagle:

> Le_Forgeron <jgr### [at] freefr> wrote:
>> It is not slow with a polynomial.
> 
> But now check this out:
> http://www.povray.org/documentation/view/3.7.1/74/
> 
> "Note:Since version 3.5, POV-Ray includes the new isosurface object which makes
> the polynomial object more or less obsolete. The isosurface is more versatile
> (you can specify any mathematical function, not just polynomials), easier to
> use. You can write the function as is, without needing to put values in a
> gigantic vector.
> Isosurfaces often render considerably faster than equivalent polys."
> 
> Whaaaaat?

I'd expect this to depend on both the order and "density" of the
coefficient matrix, i.e. how many coefficients are non-zero. If you have
many zero coefficients, it may be faster to execute a corresponding
user-defined function than to compute the full set of polynomial terms
and then multiply most of them by zero.

For example, given the function

    f(x,y,z) = x^2 + y^2 + z^2

and

    f(x,y,z) = x^10 + y^10 + z^10

this should require roughly the same effort when using an isosurface,
but when using a polynomial the second function will require a much
higher effort to solve.


> Also, considering that quintics are apparently of ridiculous complexity to
> solve, and higher order polynomials rapidly become more insane,  I'd like to get
> a little insight as to how POV-Ray deals with 15th order polys and, if the
> version of the docs I'm reading is right - _35th_ order.
> 
> http://www.povray.org/documentation/3.7.0/t2_3.html
> 
> "Note: A maximum of 35th degree polynomial can be represented with the poly
> object. If a higher degree polynomial or other non-polynomial function has to be
> represented, then it is necessary to use the isosurface object."
> 
> (When did the limit go from 15 to 35?   WHO recoded that in the source??)

This is defined by the `MAX_ORDER` constant in the source code, which
was "recently" increased by Jerome Grimbert (aka Le_Forgeron).

The previous limit of 15 was rather arbitrary; the current limit of 35
is imposed by the `binomials` precomputed table in `polynomial.cpp`,
which would require more than 32 bits per entry if the limit was
increased above 35.

Post a reply to this message