From 94d3032325102627ae940d259e0f43bca9a39d67 Mon Sep 17 00:00:00 2001 From: C R Onjob Date: Wed, 27 Aug 2014 01:00:02 +0800 Subject: [PATCH] Automatic commit of irc logs Writing is turning one's worst moments into money. -- J.P. Donleavy --- irc/#ipdf.log | 44 ++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 44 insertions(+) diff --git a/irc/#ipdf.log b/irc/#ipdf.log index eed94bc..0fa3017 100644 --- a/irc/#ipdf.log +++ b/irc/#ipdf.log @@ -3949,3 +3949,47 @@ 10:40 < matches> I think I will try to get my scanline fill to work first though 13:03 < matches> It sort of works 13:15 < matches> ... or not +--- Day changed Tue Aug 26 2014 +14:25 < matches> I wonder if I'm going to end up just reverse engineering an algorithm that I was too lazy to understand properly +14:26 < matches> I really like the idea of flood fill better than doing insane triangulation maths +14:26 < matches> Surely GPUs can flood fill +14:28 < sulix> I think they can, but either very slowly or only on very new hardware... +14:28 < sulix> I think you'd need to do it in several passes, maybe? +14:28 < matches> The problem I had with flood fill was working out where to start +14:28 < matches> I have something that almost works +14:28 < matches> That requires no clever maths... +14:29 < matches> But it is CPU only +14:29 < matches> And probably breaks in a bunch of special cases +14:30 < matches> It doesn't have precision problems though (once you've drawn the boundary that is) +14:31 < matches> It would still be cool to go through the Loop/Blinn algorithm on CPU and GPU +14:31 < matches> Because that is going to have floating point maths in it +14:31 < matches> flood fill has no floats +14:31 < matches> Therefore it is infinite precision +14:31 < matches> Objective complete +14:32 < matches> Actually I don't think my algorithm is proper flood fill, it's sort of scanline flood fill but not? +14:32 < matches> When in doubt write random code +14:34 < sulix> How are you handling the case where, due to a path being half offscreen it becomes two paths? +14:34 < matches> ... I am not +14:35 < matches> If part of the path is offscreen it is annoying +14:36 < sulix> Hopefully, once some of the quadtree code is more functional, the path clipping code can be used to clip paths to the screen. +14:39 < matches> Compositing is also totally broken because the fill just looks for black pixels +14:40 < matches> But if I can get it doing fonts then that's sort of not totally useless +18:35 < matches> I am very tempted to implement a "Please click on the location to fill this path from" interface at the moment +18:39 < matches> Alright, I have shading somewhat stack overflowing +18:39 < matches> I mean +18:39 < matches> Working +18:39 < matches> * +18:39 < matches> ******** +18:49 < matches> http://szmoore.net/ipdf/shading-the-only-svg-that-doesnt-segfault.png +20:43 < matches> Argh +20:43 * matches stabs coordinate transforms +20:43 < matches> stab stab stab +20:44 < matches> My filling algorithm is to find the 4 extrema of the path +20:44 < matches> And try and flood fill inwards from each one +20:45 < matches> But the extrema pixel coordinates keep transforming to *outside* of the path +20:45 < matches> By one pixel +20:45 * matches stabs +21:52 < matches> I guess I should just actually implement loop and blinn shading +21:52 < matches> Flood fill is not as easy as I had hoped +21:53 < matches> I have to start doing annoying geometry maths to work out what point I can start the flood fill at +21:55 < matches> Sigh -- 2.20.1