Very nice! I don't think I'll be able to update the GUI though (I'm busy with other things), but you have the code and it's not very difficult. I suggest you make a polynom editor dialog and put a button that opens it in the main dialog, sort of like the colour selector, otherwise everything will get too crammed....

I just took a look at your new version, since I found the new screenshot nice and yet weird.

Digging into your code, I found what I was quite sure to find : in distance_to_ca3, if you have a CA_POLYNOMIAL, you don't really compute the distance to the polynomial ca, hence the weird shape of your polynomial gradients. For the other types of ca, you actually compute the true distance to the objects.

If your polynomial is called P, distance_to_ca3 returns P(x) - y, whereas the distance the polynomial should be the minimum of all the distances from (x,y) to any point on the polynomial curve. That will be quite slow to compute. I don't know if there's an easy way to get such a distance, like there is for lines.

Well, it still looks good that way, but I just felt like pointing this out, to stay consistent with the first versions of your algorithm.

Then, a few remarks about your make_plut function, where you compute the lookup table.

First, why do you compute cy using -= instead of += ? Please explain, I must be missing something.
Also, it seems that for each monomial (does this word exist in english ? ), you compute x^j using pow. That's a naive and slow way to do polynomial computations. Take a look at the Horner algorithm. It's easy to code, and does less calculations than the naive way (although the difference would be hardly noticeable with degree 2 or 3... but it's just an habit ). Well, I do not have links right now, but google is our friend, or I can even write the code for you, it won't take much time.

Yeah, I know exactly what you mean. Anyway, another small update from me: v1.10 now has LUT optimized effect modifier function again (exp and p in range 0.0-4.0, definable with sliders, not editboxes) and a randomize function. That last thing is really fun. A lot of times it generates a totally black or white image or something else equally uninteresting, but if you press the "Random" button for long enough, you're bound to find something goo looking...

Sorry, I didn't incorporate test v3 yet

Glad you like it. There's just one question now: which one to use as my new wallpaper?

Hi,
I liked the thing...Can't run that now, since I don't have a compiler on this machine:(
The problem of distance to a polynomial curve got my interest, I spent some three hours with pencil and paper, but to me (I might be missing something, I still have not left high school) it seems that you can't directly (without calculating distance to all points on the screen) compute a distance to a polynomial of n-th degree (hope, that's the right terminology) without solving an equation of (2n-1)th degree - that would mean that for a cubic curve you would have to solve an equation of 5th degree, which is impossible. (if anyone's interested in the math background to this, I can send it here, but it seems most people here don't like math too much)
But you can in quite a fast way compute the 'distance map' for whole screen - the idea is this. The closest distance of a point to a curve is always at right angle to the tangent at the closest point of the curve (hope that's right premise, otherwise everything below is crap). So for each point of the curve you calculate the distance to all points lying on the normal to tangent in this point, which would be quite fast. If the distance to any point on the normal has already been computed, you overwrite it in case the new one is lower.
Mathematically: (too bad I don't have a scanner at home, it's hard to rewrite the math formulas)
let's have a polynomial of n-th degree
f(x)=a(n)*x^n + a(n-1)*x^(n-1)+ ... + a(1)*x + a(0) , where a(b) is the factor for x^b
the tangent in a point of a curve is defined by the derivative of the curve, which is
f'(x) = n*a(n)*x^(n-1) + (n-1)*a(n-1)*x^(n-2) + ... + 2*a(2)*x + a(1)
so the tangent in point X is defined as
t: y = f'(X)*x + c
after conversion to a common line formula:
t: f'(X)*x - y + c = 0
we chose a line p so that p is at right angle to t
p: x + f'(X)*y + d = 0
point [X,f(X)] lies on p so:
X + f'(X)*f(X) + d = 0
and thus
d = -X -f'(X)*f(X)
so the complete formula for p stands:
p: x + f'(X)*y -X -f'(X)*f(X)
we qualify x coordinate:
p: x = -f'(X) + X + f'(X)*f(X)
so now, for each point on y axis we can find a point lying on p
now the distance d from point [X,f(X)] to point A[-f'(X) + X + f'(X)*f(X), y] on p is described by point's A y - coordinate as follows:
d(y) = abs( (y - f(X)) / cos(alpha) )
where alpha is the angle between p and y axis:
alpha = atan(-f'(X))

Hope It was not totally confusing. I would implement that myself, but I don't have a compiler on this machine and won't have acces to one probably for next few days (the other PC broke) I'll try to write the code without compiling it:

Well that should be it... Hope there are no mistakes.
Maybe my effort was totally useless, but it was fun to me.

And yes, I love math.

That would be awfully slow, as even for a simple x*x polynomial, every pixel position above the curve would unnecessarily be used at least twice(lots of tangent normals crossing in that area) in distance computations.

It would be much faster(yet still painfully slow) for every pixel to just compute the distance from that pixel to all points on the polynomial(which are already stored in a lookup table) and then just pick the smallest.

That would always lead to a constant number of (width*height)*width distance calculations, no matter what type of polynomial used.

But still it would not make sense to store those distances to the polynomial for all pixels in a lookuptable, because in one go of the algorithm, every pixel is just once processed so there would be no gain from that at all.

I disagree - in the algorithm as I implemented it, there are NO distance calculations using pythagora's theorem. For every point on the curve, you evaluate two polynoms,compute two goniometric functions and do SCREEN_H * 2 floating point operations, plus SCREEN_H * comparison.

But maybe it would be better, not to count so much normals (bigger steps), and if a pixel was left untouched, aproximate it's distance linearly from two closest neighbours.

Than the resulting difficulty would be about SCREEN_W * SCREEN_H for linear function up to SCREEN_W * SCREEN_H^2 for a polynomial covering every pixel on the screen...

Without a lookup table, this method won't be possible, so that's the reason for the table.

And the number of operations in your method would have been also a bit bigger, because there could be more than one point of the curve for a pixel in x-axis, so you get SCREEN_W^2 * SCREEN_H up to SCREEN_W^2 * SCREEN_H^2 operations. I win

As far as I remember, my math teacher told me, there is a formula to solve 4th degree equations. And yes, solving numerically would be painfully slow... I don't have much time now, but I could send you my sketches for the distance computing...

Oh no - you misunderstood.
If you have y=x^2, then between point [2,4] and [3,9] which are one pixel far away on x axis lie 5 pixels of the curve, so five distances have to be calculated, not one.

OK, I haven't read the source code, so you do not count whole curve, but only the points where x is a whole number? So if you have curve x^4, then the distance of point [1,6] to the curve would be 5 (Nearest points are [1,1],[0,0] and [2,16])? Because that's obviously not true, for the distance is less than 1.

EDIT: Sorry for others, my argument with DB is getting a bit off-topic.

I understand that - but while I was asleep I found out what my first reply should have been. If you calculate the distance to all points on the curve, you get num_points_on_curve * width * height. My algorithm uses num_points_on_curve * height. Well, my step is maybe a bit slower than yours (you have two multiplications, addition and a square root for a loop, I have two additions, two multiplications and an if)
I don't think that lots of normals crossing is a problem, the speed of algorithm is not affected by that - no matter how many times the normals cross, you count the same amount of them. And it won't be too much, for I think that any point can't have more than polynom_degree + 1 normals crossing it - well a pixel covers more than one point, but still...
Yes, I think we had just communication problems.

The argument before was about the fact, that num_points_on_curve may vary from width to width * height, depending on the complexity of the curve - with which I hope you agree.

Sorry, don't have any place to upload the image to, so it's attached.

If you count only one point of the curve for a point on x-axis an x^2 curve would contain only pixels that are black on the image. But it should also contain those green pixels - if you would count distance only from black pixels, you'll get that red pixel's distance from the curve is 2 (nearest point would be [2,4]) but that's obviously stupid, since red pixel's distance to the curve is 1. Do you follow me?
So instead of width pixels (7 on the image) the curve has to contain 17 pixels. So you have to count (in both yours and mine algorithm) more than width steps.

The picture definitely is not a proof ... I wish I had a scanner or a digital camera... MS Paintbrush sucks. But well I have an image. Look, there is a point A and it's distance to curve's peak P. But because AP is not at right angel to the tangent, a circle with center in A and r = |AP| has to have more than one intersect with the curve - C (unmathematically : in a very close place around a point the function value is nearly equal to the tangent. Since the tangent is not at right angle to the distance, you get closer to A by moving right over it, so by moving right a bit on the curve you also get closer to point A) the closest point then lies between those two - B. I understand that's not a mathematical proof, but I think one could base the proof upon this idea.
Was I clear?

EDIT:
The problem with "spaces" between pixels is not limited to drawing - as I've shown, if you omit them, than the distance calculation is inaccurate. But yes, basically both algorithms can omit them with a slight loss of precision (mine would loose more)