X-Git-Url: https://git.ucc.asn.au/?p=ipdf%2Fdocuments.git;a=blobdiff_plain;f=irc%2F%23ipdf.log;h=c8c17c93ac4160223f5f0864c18104ac0dc633d1;hp=cb5ac7e45147e42a48e7abfd5625636f0c3802cb;hb=b63206e3974de26097a2c9f0e1dedeec06ea66fb;hpb=2649f785a81913757a71df990c1ef65fb25147d0 diff --git a/irc/#ipdf.log b/irc/#ipdf.log index cb5ac7e..c8c17c9 100644 --- a/irc/#ipdf.log +++ b/irc/#ipdf.log @@ -3942,3 +3942,209 @@ 17:59 < matches> Anyway there is a proper "Group" data type like with the Beziers 18:00 < matches> So if you want to cache things related to groups you can put them in that I guess 18:02 < matches> Really it should be called "PATH" not "GROUP" but I vaguely thought it might be able to be used as either +--- Day changed Mon Aug 25 2014 +10:39 < matches> I was thinking about how to do shading more +10:40 < matches> And I basically arrived at the idea Loop and Blinn have that you kept talking about +10:40 < matches> Except I didn't realise it at first because my version was all using rectangles instead of triangles +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" +--- Day changed Thu Aug 28 2014 +11:35 < sulix> What time is it? It's NaN time! +11:44 < sulix> Ah, so... horizontal lines have a height of zero in their bounds. This makes divides by zero happen in places. +11:48 * sulix apologieses profusely for his latest "break absolutely everything" commit. +11:57 < sulix> Yeah, making divide by zero crash rather than generating NaNs breaks a lot of things. +11:57 < sulix> You'd be surprised by how often we divide by zero. +11:57 < sulix> Mostly in the Quadtree code. +11:58 < sulix> Because, damnit, mathematics can't beat me. +12:20 < matches> Yes, lines have zero width... stupid lines +12:21 < matches> I stopped the segfaults in shading by adding a depth counter to FloodFillOnCPU +12:21 < matches> Which makes interesting shading patterns... +12:22 < matches> I think it's time to fall back to the "Use the second algorithm on Wikipedia" approach +12:23 < matches> I can still use a Flood Fill but hopefully a less segfaulty one +12:29 < matches> I'm not sure about ToAbsolute and ToRelative... +12:29 < matches> I thought they should be inverses but they seem not to be +12:29 < matches> Oh wait, the divide by zero would do that +12:30 < matches> That curve looks cool +12:30 < matches> You should talk about it lots in the meeting +12:31 < matches> For the whole meeting +12:31 < matches> Nothing else +12:31 < matches> Don't mention the total lack of progress I made... +12:32 < matches> How much can I trust SolveCubic? +12:40 < matches> Basically I'm going with randomly picking points until I find one inside the shape then starting a flood fill from that point +12:41 < matches> Checking the pixels for the edges is not feasable +12:42 < matches> If you scan along a bresenham line you could jump over the edge +12:42 < matches> ... I see an "if false" in SolveCubic +12:42 < matches> Slightly worrying +12:43 < matches> Ah +12:43 < matches> I approve of SolveCubic +13:31 < matches> So +13:31 < matches> Did you introduce the floating point exception or did I... +13:45 < sulix> I just did. +13:49 < sulix> SolveCubic may have small problems. +13:50 < matches> Yes I am trying to rewrite it now... +13:50 < matches> I swear we did this in CQM +13:52 < sulix> Solvecubic also sometimes tries to take the square root of a negative number. +13:52 < matches> Yep +13:54 < sulix> I've pushed slightly less broken code. +13:55 < sulix> Ny which I mean slightly more broken. +13:55 < matches> ... +13:55 < sulix> I'm avoiding divide by zeros by "if (denominator = 0) denominator = 1" style shenanigans. +13:56 < matches> I'm slightly scared by the change to Rect::TransformRectCoordinates +13:56 < matches> Oh right +13:56 < matches> Yeah +13:56 < matches> That seems... +13:56 < matches> Scary +13:56 < sulix> It works, scarily enough. +13:56 < matches> Anyway I already ifdef'd the thing out of SolveCubic +13:56 < matches> It's too slow for me though +13:57 < sulix> And by works, I mean I haven't found any issues yet. +13:57 < matches> I am brute forcing a point inside the shape +13:57 < matches> This requires finding the intersections with horizontal and vertical lines for every single bounding bezier +13:57 < matches> Then the "even or odd" test +13:57 < matches> You only have to do it once +14:05 < matches> I think SolveCubic would best be done by doing Newton Raphson or the Shooting Method between the endpoints and the turning points +14:05 < matches> I'll see +14:06 < matches> I'll try implement it and see if it's faster +14:06 < matches> You may have to demonstrate my totally broken shading for me +14:06 < matches> I haven't committed in a while +14:41 < matches> Oh +14:41 < matches> SolveCubic may not have been the bottleneck there... +14:41 < matches> -_- +14:41 < matches> The failure to update the variable for a while loop miiiight be more of an issue +14:44 < sulix> Good, 'cause I'm thinking of "upping the SolveCubic accuracy" a bit. +14:44 < sulix> Anyway... +14:44 * sulix -> CS +14:46 < matches> I've reimplemented SolveCubic +14:46 < matches> In theory it works +14:55 < matches> I reckon Binary Search is the only algorithm I am good at implementing :S +14:57 < sulix> Oooh... +14:57 < matches> What? +18:56 < matches> So, the fact that we are not solving cubics analytically is probably important in terms of precision issues +18:58 < sulix> Yeah, that's why I started trying to solve them analytically and then stopped and cried. +18:58 < matches> :( +18:59 < matches> There is a solution, it's just ugly +18:59 < sulix> Nah: for the Quadtree, it didn't matter much. As long as the error went in the correct direction, you'd just lost a tiny bit of efficiency. +19:00 < matches> Hmm +19:00 < matches> I don't expect shading using arbitrary precision arithmetic will be particularly fast anyway... +19:01 < sulix> Well, ideally most of the work in the shading will be done in screen-space anyway. +19:01 < matches> Yes +19:02 < sulix> And, of course, you don't need infinite precision for that because pixels/integers/etc. +19:03 < sulix> So, fingers crossed, things shouldn't matter too much. +19:03 * sulix realises that that is a maddeningly vague statement. +19:03 < matches> Well +19:04 < matches> I got the fill point to actually be in the correct location by actually solving the intercepts correctly +19:04 < matches> But +19:04 < matches> If you zoom *out* far enough, it can end up no longer inside the shape when transformed to screen space +19:04 < sulix> Okay, new plan. +19:04 < sulix> No zooming out. +19:05 < matches> I wish there were other people in this channel so I could justify putting that in qdb +19:20 < matches> There is a temptation to not require all those references to be const during rendering +19:20 < matches> We might want the Path to be able to alter itself based on the view +19:20 < matches> But I guess we'll take that path when we get to it +19:22 < matches> It might be worthwhile caching Path's for fonts +19:22 < matches> But I'd have to change the coordinates to be relative +19:22 < matches> Too many coord transforms +19:24 < sulix> Yup, that can be the subtitle of the thesis: "Too many coord transforms" +19:26 < matches> "A coordinated approach to graphics" +19:26 < matches> Oh wow +19:26 < matches> That should be a textbook +19:26 < sulix> "Transformers: Matrices in disguise"? +19:30 < sulix> Okay, it turns out (if denominator is zero, make denominator 1) has one flaw. +19:30 < sulix> Sometimes you should make the denominator... negative 1. +19:30 < matches> ... +19:30 < sulix> Somehow, I did not see this coming. +19:30 < matches> I'm not sure how this maths works +19:30 < matches> 1/0 != 1/-1 +19:30 < sulix> That's what they want you to think. +19:31 < sulix> (Or maybe the bug I'm having is unrelated to that, but it seems like a fun guess) +21:16 < matches> Floating Point Exception in fglrx! +21:16 < matches> glXDestroyContext +21:16 < matches> It only happens when the program is about to close +21:16 < matches> So I'll be fine +21:18 < sulix> Ah, maybe enabling floating point exceptions was a bad idea. +21:18 < sulix> ...if it causes lots of "fglrxceptions"! +21:21 < matches> Well fglrx is exceptional +21:37 < matches> I'm falling back on just testing a crap tonne of points for "inside" and adding all the ones that are to a vector +21:37 < matches> I think there are some false negatives in Path::PointInside +21:37 < matches> Also FloodFill misses some edge pixels which makes no sense +21:38 < matches> If it's next to a filled pixel it should get filled! +21:47 < matches> So the disadvantage of using a breadth first search is that when your queue gets really big instead of getting a segfault you just get OOM +21:48 < matches> segfaults are quick +21:48 < matches> segfaults are like a pistol and oom is like drowning +21:54 < sulix> There is no way a BFS floodfill should ever OOM +21:54 < sulix> How many pixels are there, and how much are you storing per one? +21:58 < matches> Probably max 256x256 pixels, 4 way fill +21:58 < matches> It does not like rabbit_simple.svg +22:04 < matches> Yeah there is *something* causing it to get in a loop +22:04 < matches> Because obviously my BFS didn't check for loops +22:14 < matches> -_- +22:14 < matches> It is in a loop +22:14 < matches> Because there is a region with fill colour of white +22:14 < matches> And the flood fill is just "If it isn't white, stop" +22:14 < matches> Maybe I should set the background to have 0 alpha or something +22:15 < matches> Alpha seems to not actually do anything at the moment +22:27 < matches> http://szmoore.net/ipdf/who-the-hell-needs-antialiasing-anyway.png +22:44 < matches> http://szmoore.net/ipdf/shady-the-fox.png +22:47 < matches> rabbit_simple.svg actually doesn't work as well as rabbit.svg +22:48 < matches> I think one of the fill points of the outer ear is inside the inner ear +22:54 < sulix> Oh my... They're beautiful! +23:07 < matches> Ah crap +23:07 < matches> I will be pushing +23:07 < matches> 8 hours in the future +23:07 < matches> I really should fix my system clock +23:07 < matches> One of these days...