From b63206e3974de26097a2c9f0e1dedeec06ea66fb Mon Sep 17 00:00:00 2001 From: C R Onjob Date: Fri, 29 Aug 2014 01:00:02 +0800 Subject: [PATCH] Automatic commit of irc logs You prefer the company of the opposite sex, but are well liked by your own. --- irc/#ipdf.log | 145 ++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 145 insertions(+) diff --git a/irc/#ipdf.log b/irc/#ipdf.log index 60fd46c..c8c17c9 100644 --- a/irc/#ipdf.log +++ b/irc/#ipdf.log @@ -4003,3 +4003,148 @@ 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... -- 2.20.1