> Ok. This means that square-distance might need [...]
I agree that 181 is enough in a typical SDF grid, and anyway
if we generate a 8bit SDF bitmap it won't be able to represent
more than 127 signed values.
And I also agree that closer distances are more important than
distant distances if the user is simple using the SDF from simple
reconstruction. But, if we want to generate something like this:
then I think both types of distances are equally important.
By truncating do you mean normalizing in a range of [0, 181] or clamping
the values? In both cases I don't see any problem.
>
As I said above, the distant grid points contain [...]
So, basically we subdivide the curve into small lines and use them to
generate the SDF, so as to make the process faster.
I will try to implement this tomorrow and see how it looks. And if it
works here is what I propose:
First for the squared distances. While generating SDF, I am using a `spread'
parameter which defines the max distance which will be present in the final
output (basically the output will have a range [-spread, spread]). So, In case
the spread is small (< 181), we can use the squared distance to generate the SDF.
And in case it is greater than 181 we simply use `FT_Vector_Length'.
Second if the subdivision method works and is both faster and doesn't differ much from
the method I am currently using, then we will use it to generate SDF if the glyph size
is small, because I think if the glyph size is large then there might be too many
subdivisions and it will make the whole process slow. And if the glyph if large then
we will use the current method. (of course this will depend if the subdivision method
doesn't differ much from the actual SDF)
So we use separate implementations depending on the spread and the size of the glyph.
How does it sound?
> Looks alright, including modules.mk. Have you checked if it compiles?
Thanks for checking it out. Yes, it does compile,
Anuj