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
+--- Day changed Wed Aug 27 2014
+22:33 < sulix> Suddenly: ToAbsolute on ToRelative does not give original Bezier
+22:34 < sulix> I may need to rethink what my quadtree code is doing to those poor curves.
+22:51 < sulix> Never mind, that assertion happens _whenever_ trying to load cubicbeziers.svg.
+23:03 < sulix> Oh wow: you should see what happens if you start splitting and reparametrising beziers with bad precision.
+23:03 < sulix> 'tis "whacked"
+23:08 < sulix> http://davidgow.net/stuff/ipdf-a-slight-curve.png
+23:15 < sulix> And the Quadtree infinite precision for béziers now works*
+23:15 < sulix> *for some beziers.
+23:15 < sulix> * for some large finite value of "infinite"
git.ucc.asn.au / ipdf / documents.git / blobdiff
UCC git Repository :: git.ucc.asn.au