Mathematics Question about the SLERP

Hi everyone,

I this pretty much has not very much to do with JOGL, but it is a mathematics question, that I want to address here because, I find it that this is a much user friendly forum than anything I have come across.

Anyhow, is the title of the topic suggest, I want to ask something about the SLERP equation which I will show below:

The SLERP equation that I am using is this: v = (1 - t)(p1) + (p2)(t), where v is the latter vector along the interpolated line, the change in time from p1 to p2, which are points in space.

I am trying to find a number, a constant per say or a scalar out of this equation that will give me the number of pixels which will have been drawn to the screen if I had ran this in a rendering loop. (Just to point out, I need to find the number of pixels without running a loop or any other computer algorithm that will loop about the change in time from t = 0 to t = 1 which will eventually trace p1 to p2 in space, without using a loop. I want to derived that number out of the same equation I just showed above, without running a loop that would count the pixel to begin with. I need to manipulate the equation so I can extract an [n] value which will be the number of pixels which would've been drawn to the screen if I had ran this in a rendering loop.

Any ideas will help.

Thank you.
thank you.

Why not using a loop? It would make it trivial to know the number of pixels using any rasterization algorithm e.g. like this

https://en.wikipedia.org/wiki/Line_drawing_algorithm

I don't know if it is feasible without a loop..

First thing I think is that you might simply calculate the distance and estimate the number of pixels based on the the deltas

For deltas I mean, if you have p0(x0, y0) and p1(x1, y1), delta is (x0 - x1, y0 - y1)

If you consider an algorithm like https://en.wikipedia.org/wiki/Bresenham%27s_line_algorithm which is guaranteed not to have "overlapping" pixels, then elect's suggestion should be correct. Assuming the line starts and ends on pixel centers, the number of pixels drawn should be (x1-x0) + (y1-y0) + 1. This disregards anti-aliasing, though :)

Any hint what you're using this for? There might be a different solution if it was more clear what problem you were solving.