Re: [Freetype-devel] Re: GSOC - Distance Fields
>> Thanks, too. What do you think about integrating this into (at >> least) `ftview`? > > Yes, it can be integrated into the existing demo programs, however I > think it should have a separate demo program because of the way SDF > is rendered, it has a raw and reconstruction view as well as various > properties and bilinear filtering. Because of that I think > integrating it completely into the existing programs will clutter > the programs. OK, no problem to add another test program :-) Please make it behave similar to the other ones as much as posible for the sake of orthogonality. > On the other hand It makes sense to integrate them into the existing > programs, so that we can compare them with other renderers and see > how it looks. It will require significant changes to the graphics > subsytem (adding bilinear filtering, render 16 bpp, the > reconstruction mode etc.). So, perhaps I should do it after GSoC? This would be great, of course! However, if you want to invest some time in this area please have a look at the `ftinspect` program, which is intended as a modern replacement and synthesis of all demo programs. [There are also some improvements in the 'veeki-gsoc-experimental' branch, which unfortunately don't fly, so to say. Maybe some of it is useful.] Werner
Re: [Freetype-devel] Re: GSOC - Distance Fields
>> Werner, Are you still interested in adding API to remove overlaps? > > Yes, I am. Alright, I will start reading more about it after GSoC. >> I have updated the demo to include the new algorithm to handle >> overlaps. [...] > > Thanks, too. What do you think about integrating this into (at least) > `ftview`? Yes, it can be integrated into the existing demo programs, however I think it should have a separate demo program because of the way SDF is rendered, it has a raw and reconstruction view as well as various properties and bilinear filtering. Because of that I think integrating it completely into the existing programs will clutter the programs. On the other hand It makes sense to integrate them into the existing programs, so that we can compare them with other renderers and see how it looks. It will require significant changes to the graphics subsytem (adding bilinear filtering, render 16 bpp, the reconstruction mode etc.). So, perhaps I should do it after GSoC? Anuj
Re: [Freetype-devel] Re: GSOC - Distance Fields
> Werner, Are you still interested in adding API to remove overlaps? Yes, I am. > I watched the skia code and the video on how it's done in skia. I > think it's doable, the only tricky part that I think is to find the > intersecting point of contours, because they use a 4th degree > polynomial to find the intersections. If you're still interested in > adding the API, I can start reading more about it after GSoC and > then add it. This would be really great. Thanks for the offer! > I have updated the demo to include the new algorithm to handle > overlaps. [...] Thanks, too. What do you think about integrating this into (at least) `ftview`? > And then I will write a brief description of how both `sdf' and > `bsdf' renderers work in the source files. And finally I will > create a new branch and add the code there. If there is anything > else please do let me know. Your plan sounds just fine :-) Werner
Re: [Freetype-devel] Re: GSOC - Distance Fields
Hello Alexei, Werner, >> I meant it all along but perhaps it is hard to do it on the fly. Ther >> rules seem to be as follows: >> >> 1) Both outside (both positive), choose a smaller value >> 2) Both inside (both negative), choose a smaller value as in (-5 < -4) >> not by absolute value >> 3) one inside one outside, choose a smaller value as in (-3 < 2) not >> by absolute value >> >> I.e. always choose a smaller value combining two contours so it seems > > Along with this we probably also need to find the resultant vector in case > two distances are non infinite at a same point (i.e. the distance values are > less than spread), that we can find the distance to the corner even tho > there is no actual corner in some glyphs. I've added the overlapping support according to your algorithm, however I have modified the rule as follows: -> Generate SDF for each contour in a separate bitmap. -> for combining all the SDF to one use the below rule: -> for each pixel/grid point: c = for all clockwise contours find the largest signed value. ac = for all counter-clockwise contours find the smallest signed value. final_value = smallest signed value of `c' and `ac'. It works well for all of the glyphs that I checked apart from glyphs with self intersecting contours, because they can't be separated into different bitmaps. To handle self intersecting contours I think there is only one way and that is to remove the overlaps. [ Werner, Are you still interested in adding API to remove overlaps? I watched the skia code and the video on how it's done in skia. I think it's doable, the only tricky part that I think is to find the intersecting point of contours, because they use a 4th degree polynomial to find the intersections. If you're still interested in adding the API, I can start reading more about it after GSoC and then add it. ] I have updated the demo to include the new algorithm to handle overlaps. I have also disabled all the optimization modes except the subdivision optimization (it will be the default one from now on until I find something even faster). Here is the link: https://github.com/preversewharf45/ft2sdf-demo, for help screen press '?' or F1. There is a `CascadiaCode.ttf' font which is full of overlaps, so that you can check how the new algorithm performs. And now that GSoC is almost over, I will fix the compiler warnings first. And then I will write a brief description of how both `sdf' and `bsdf' renderers work in the source files. And finally I will create a new branch and add the code there. If there is anything else please do let me know. Thanks, Anuj
