Hello Alexi, Suzuki,
I can't decide which format to use for storing the SDF(signed distance
fields). I think using floating-point values (fixed-point in this case) for
generation will be more accurate than using integer, but then saving the
SDF to a file will require a conversion.
So there can be
> I can't decide which format to use for storing the SDF(signed
> distance fields). I think using floating-point values (fixed-point
> in this case) for generation will be more accurate than using
> integer, but then saving the SDF to a file will require a
> conversion.
>
> So there can be few t
I'll just add references below.
On Tue, May 12, 2020 at 4:15 PM Werner LEMBERG wrote:
> > I can't decide which format to use for storing the SDF(signed
> > distance fields). I think using floating-point values (fixed-point
> > in this case) for generation will be more accurate than using
> > int
Dear Anuj,
I agree with Werner's comment.
It might be uncomfortable for you to leave an untested question, something
like "if I use a floating point calculation, the result could be better?".
Please use a floating point in your initial draft (if you want),
and let's discuss about the trade-off
Thank you all for the comments.
I too agree with Werner.
I think comparing both the types seems to be a good option, So, I'm gonna
do as Suzuki suggested
and use floats for my initial draft and later without floats.
And I'm not gonna focus on the saving part because the user can always do a
conver
Dear Anuj,
I think you can use *float* directly in the initial draft.
When we merge the implementation using the float type into
the official public release, we should discuss the design.
There are already FT_F2Dot14 (16bit), and FT_F26Dot6 (32bit)
and FT_Fixed (16Dot16, 32bit). But yet we don't
Hello Suzuki,
> There are already FT_F2Dot14 (16bit), and FT_F26Dot6 (32bit) and FT_Fixed
(16Dot16, 32bit).
I think using FT_F2Dot14 will be a good option because the signed distance
field will have a range [-1.0, 1.0].
But for now I'll stick with *float* as you suggested.
> BTW, the most bigges
Dear Anuj,
Anuj Verma wrote:
> Hello Suzuki,
>
>> There are already FT_F2Dot14 (16bit), and FT_F26Dot6 (32bit) and FT_Fixed
>> (16Dot16, 32bit).
>
> I think using FT_F2Dot14 will be a good option because the signed distance
> field will have a range [-1.0, 1.0].
> But for now I'll stick with *
> Oh, I see the value to be stored is in a range [-1.0, 1.0].
> I want to hear the comments from other developers :-),
> whether the initial implementation should be FT_F2Dot14 (16bit)
> or float (32bit, at least).
Well, we have dropped 16bit support already, so it's only a question
about storag
Dear Werner,
Werner LEMBERG wrote:
>> Oh, I see the value to be stored is in a range [-1.0, 1.0].
>> I want to hear the comments from other developers :-),
>> whether the initial implementation should be FT_F2Dot14 (16bit)
>> or float (32bit, at least).
>
> Well, we have dropped 16bit support alr
10 matches
Mail list logo
