X-Git-Url: https://git.ucc.asn.au/?p=ipdf%2Fdocuments.git;a=blobdiff_plain;f=irc%2F%23ipdf.log;h=ddae826a40214702772bc2181de90090d71db364;hp=c6349a61628c7d6d27d3fc781b413ee9ea13512d;hb=0744a3cd8d1a772c1948a0412e7aef914b1ed50a;hpb=d568948eb40780f3c76bb825e864fad557d9f50c diff --git a/irc/#ipdf.log b/irc/#ipdf.log index c6349a6..ddae826 100644 --- a/irc/#ipdf.log +++ b/irc/#ipdf.log @@ -3364,3 +3364,867 @@ 22:33 < sulix> But it works, even if it's still a tad slow. 22:45 < sulix> Okay, memory use is not a problem at all if we delete out GMP integers after we're finished with them. 22:46 < sulix> (There was a TODO: to that effect) +--- Day changed Fri Aug 08 2014 +16:11 < matches> Wait you just did the things *I* was supposed to do for this week :P +16:11 < matches> I hope you don't want me to fix quadtrees... +16:13 < matches> Ah sorry about the GMP +16:14 < sulix> I gave the QuadTrees another go as well, but random half-letter-"b"s were everywhere. +--- Day changed Mon Aug 11 2014 +10:56 < matches> Ok I think I need to throw all design principles out the window adding a keyboard handler +10:57 < matches> I know you were keen on having a mouse handler independent of the Screen class +10:57 < matches> But the Screen class detects the events +10:57 < matches> It really makes sense for the event handlers to just be member functions +10:57 < matches> Maybe virtual in the unlikely event that there are ever different types of Screen +10:58 < matches> Probably the View should handle the events +10:58 < matches> Then we wouldn't have this convoluted thing where View has a reference to a Screen but Screen has a pointer to a View... +10:59 < matches> But I need to let that go and actually do useful things +10:59 < matches> So KeyboardHandler is now a member of Screen +10:59 < matches> Delicious spaghetti +11:02 < sulix> I think I can bring myself to forgive you. :) +--- Day changed Tue Aug 12 2014 +13:48 < matches> I can draw rabbit_simple.svg +13:48 < matches> ! +13:48 < matches> Almost +13:50 < matches> IT IS BEAUTIFUL +13:52 < matches> Wait I think quad trees are enabled +13:53 < matches> Nope they aren't +13:53 < matches> Oh wel +13:54 < matches> http://szmoore.net/ipdf/infinite-precision-document-FOX.png +13:54 < matches> That didn't take very long +13:55 < matches> I suspect the wierd bits in the wrong spot are because there are translations applied to things +13:55 < matches> Because inkscape +13:57 < matches> Hmm yeah +13:58 < matches> I wonder why there are random straight lines between things though +13:58 < matches> They are filled regions of the same colour and no stroke but obviously we just read the beziers and draw the outlines +14:50 < matches> Dammit SVG +14:50 < matches> So the y coordinate of text refers to the bottom +14:50 < matches> The y coordinate of *everything* *else* refers to the top +14:51 < matches> It's alright this is ipdsvg we aren't constrained by stupid standards +14:59 < matches> Ergh somehow fonts are broken in eye of mate... +14:59 < matches> How did I even... +15:00 < sulix> Fonts are usually handled with y=0 being the "baseline" of characters. +15:10 < matches> There are a few wierd things going on with straight lines +15:11 < matches> Hmm only at the default zoom +15:11 < matches> Horizontal lines on both cpu and gpu are kind of wobbly +17:23 < matches> Ok I am suffering from an attack of matrix algebra +17:23 < matches> It was bound to happen sooner or later I guess +17:24 < matches> The spaghetti is cooking nicely +17:26 < matches> The fact that our document is all in GL coordinates and SVGs are not is causing me way more confusion than it really should be +17:27 < matches> All I need to do is set an initial transformation matrix then everything else should Just Work +17:27 < matches> Of course it does help if you actually use matrices instead of Rect's +17:29 < matches> Also I think functions that modify arguments passed by references is one of the things that tpg hates +17:29 < matches> But there are a lot of them here +17:29 < matches> They are so convenient! +22:03 < matches> If I can get transforms and groups actually working properly, we can probably hack some sort of recursive thing together and use view reparenting +22:03 < matches> Somehow +22:05 < matches> I'm thinking putting the fox in the rabbit's eye and so on recursively would actually be pretty damn awesome +22:05 < matches> It is easy to say these things though... +22:06 < sulix> So, I have view reparenting "working" in the quadtree code. +22:06 < matches> :O +22:06 < matches> Cool +22:06 < sulix> (The rest of the quadtree doesn't work, so the point is somewhat moot, though) +22:06 < matches> Wait you already had that working, but you have rendering bugs +22:06 < matches> Yeah +22:06 < matches> :P +22:08 < sulix> I will push that now, actually. +--- Day changed Wed Aug 13 2014 +00:34 < matches> Yes +00:34 < matches> I have defeate +00:34 < matches> d +00:34 < matches> Basic matrices +00:36 < matches> So it is pretty ugly and inefficient but meh +00:36 < matches> We have translate, scale and matrix +00:37 < matches> skew will be pretty easy to add but probably useless +00:37 < matches> rotate is a bit harder +00:38 < matches> Also the skewing operations obviously don't work on rectangles +00:38 < matches> Or anything that isn't defined in terms of bezier paths I guess +00:38 < matches> But translating and scaling will +00:40 < matches> Ok, so SVG has a "defs" thing that lets you define groups without drawing them +00:41 < matches> And a "use" thing that lets you insert a group +00:41 < matches> Actually element in general +00:41 < matches> Doesn't have to be a group +00:41 < matches> So +00:41 < matches> I wonder if doing recursive magic with that works +00:48 < matches> Not in normal svg viewers it would seem +00:49 < matches> Hmm +00:51 < matches> (eom:7883): librsvg-WARNING **: Circular SVG reference noticed, dropping +00:51 < matches> That's just boring! +00:52 < matches> So I think we will need some fairly major changes to our Document structure to get much more SVG stuff working +00:53 < matches> I wonder if we actually need to store a DOM if we want that to work +00:53 < matches> Also I thought I fixed transformations but they still break for fox-vector.svg :( +00:58 < matches> I think "broken" will probably be the most commonly occuring word in our git commit messages +11:05 < matches> Oooh +11:06 < matches> svg-tests/recursive.svg is slightly recursive viwed in firefox +16:10 < sulix> The QuadTree works again! +16:10 < sulix> (I have finally worked out how to multiply by two, it seems...) +16:11 < sulix> Also s/ again// +17:23 < matches> Project complete! +18:05 < sulix> Man, nVidia has an OpenGL extension where you can just pass the "d" attribute of SVG paths in and have it render them for you. +18:05 < matches> Oh +18:05 < matches> Welp +18:07 < sulix> It's like: glPathStringNV(path, GL_PATH_FORMAT_SVG_NV, strlen(d), "M100,180, L40,10, etc...") +18:08 < matches> Presumably you could just replace 90% of the SVG stuff with that then :S +18:09 < sulix> It only works on nVidia hardware, though, so it's not really practical. +18:10 < matches> I think I need to actually do the Bezier's bounding rectangles correctly +18:10 < sulix> I was just about to add that, actually. +18:10 < matches> But its not just (x0,y0,x3-x0,y3-y0) +18:10 < matches> Ok +18:10 < matches> Go ahead then +18:10 < sulix> Nah, you have to take the x and y components separately and solve for min and max. +18:11 < matches> Yes google is a lot faster than actually doing maths +18:13 < matches> I can add that unless you've already written it? +18:13 < sulix> Sure. +18:13 < sulix> The internet seems to claim that you should use newton-raphson to find the roots of the derivatives, but I'm not really comfortable with doing that for cubic béziers, +18:31 < matches> I just differentiated the parametric formula +18:31 < matches> And got a quadratic +18:31 < matches> Unfortunately there is a slight problem with Real +18:31 < matches> Since we don't have a general "sqrt" +18:31 * matches adds that to the growing list of "fix later" +18:32 < matches> It doesn't compile for Rational anymore anyway +18:38 < matches> I am writing code that sjy would probably not consider elegant +18:50 < matches> Well that totally broke everything +18:53 < sulix> So it turns out that the view reparenting was only working by chance. +18:55 < matches> :( +19:20 < matches> Hmm it turns out finding the bounding box of a bezier has really annoying edge cases +19:43 < sulix> Okay, automatic generation of new quadtree nodes "works" when zooming in. +19:44 < sulix> It doesn't do any fancy clipping, so the actual rendering code hits precision issues, but it's still pretty cool. +19:48 < sulix> It also get a bit buggy if you try to pan over the edges of quadtrees, as it only renders one node at a time. +19:59 < matches> Nice +21:14 < sulix> I have just achieved infinite precision with the quadtree! +21:14 < sulix> Only on rectangles, only when zooming in, and only when the camera doesn't cross a quadtree boundary, but it works! +--- Day changed Thu Aug 14 2014 +09:50 < matches> cool +10:37 < matches> I'm beginning to suspect whoever said to use the Newton Raphson method to find Bezier bounding boxes was right +10:43 < matches> I love how the sites I looked up said "Obviously there is a problem if a = 0 or b^2 - 4ac < 0, but we can just make sure we always pick beziers that don't cause those problems +10:44 < matches> Ok +10:44 < matches> I have at least got an algorithm that returns finite sized bounding boxes now +10:45 < matches> I think it even works! +10:45 < matches> But only on the CPU +10:45 < matches> Presumably the GPU does something to cope with the fact that the bounding boxes were totally wrong before? +10:53 < matches> Oh it wasn't doing anything because they were {0,0,1,1} +10:54 < matches> I have to transform the Bezier coefficients before they are uploaded to the GPU +10:54 < matches> Blergh +10:55 < matches> What I've basically done is change it to be the opposite of how it was designed +10:55 < matches> -_- +10:56 < matches> So before, the Bezier control points were relative to some bounding rectangle but when I parsed the SVG I just made it always {0,0,1,1} so the coordinates were absolute +10:56 < matches> Now I have changed the Bezier control points to be absolute and then calculated a bounding rectangle from them +10:56 < matches> I can maths +10:57 < matches> So I could make the Beziers still have the {0,0,1,1} bounds which will fix the GPU renderer without having to transform the coefficients +10:57 < matches> And just leave this "SolveBounds" function in for actually getting the bounds +10:58 < matches> Except SolveBounds is disgusting +10:58 < matches> And slow +10:58 < matches> So I could add a Bounds member variable to the Beziers +10:58 < matches> And then we have two bounds +10:58 < matches> I seem to have coded myself into a catch 22 "No matter what you do it is terrible" situation +10:59 < matches> Adding a Bounds member variable to the Bezier struct sort of defeats the whole point of the "Object of Arrays" idea +10:59 < matches> You know what +11:00 < matches> I think the "Object of Arrays" approach has caused more problems than it solved :P +11:02 < matches> (Probably not actually) +11:09 < matches> Spaghetti +11:09 < matches> I'm going to transform the coordinates before uploading to the GPU shaders +11:09 < matches> Because I think that is the least objectionable? +11:09 < matches> I don't know +11:09 < matches> I still don't like any of the solutions +11:10 < matches> But having more than one bounding rectangle definitely seems dumb +11:10 < matches> Especially if the other is *always* {0,0,1,1} +11:11 < matches> I hope this doesn't totally break your quad tree +11:15 < matches> Actually looking at the quad tree it seems that is the best way to make it more likely to work +11:21 < matches> I feel like we should use SVGMatrix more and Rect less +11:21 < matches> But oh well +11:29 < sulix> Ah: so the Quadtree kinda relies on the Bézier coordinates being relative to the bounding rectangle. +11:29 < matches> Yep +11:29 < matches> I'll do that +11:29 < matches> It's easier to do the transform when the coordinates are uploaded to the GPU +11:29 < matches> Although probably less efficient +11:30 < matches> On the other hand, the CPU renderer relies on having absolute coordinates +11:30 < matches> Two renderers +11:30 < matches> TWICE the matrices +11:30 < matches> TWICE the confusion +11:31 < matches> And Rects are not really convenient because they aren't a proper transformation matrix +11:31 < matches> I can't just multiply some Rects together +11:31 < matches> Or calculate an inverse +11:32 < sulix> Yeah, there are problems there. +11:34 < matches> Hmm +11:34 < matches> I *almost* fixed it +11:34 < sulix> Rects are really good for the QuadTree, though. +11:34 < matches> We should leave it as rects +11:34 < matches> You just manually work out what it needs to be anyway +11:35 < matches> I think the inverse of the equivelant matrix will always work as a rect +11:35 < matches> So there are random lines missing from the beziers now +11:35 < matches> But the ones that are there are in the right spot! +11:36 < matches> (On the GPU) +11:36 < sulix> So, I looked at that. I see random missing lines on Intel, not on nVidia. +11:37 < matches> Oh were they missing before? +11:37 < matches> Well I don't recall them being missing before +11:37 < matches> Oh +11:37 < matches> I know what it is +11:38 < matches> When the bounding rectangle has width or height of zero +11:38 < matches> Sigh +11:38 < matches> Wait that can't be it +11:38 < matches> Most of the missing lines aren't straight horizontal or vertical +11:38 < matches> :S +11:39 < sulix> I think it's just dodgy rounding on the GPU. +11:40 < matches> I will push what I have I guess +11:40 < matches> I have nice pretty debug rectangles (in *colour*) around the beziers when they are rendered on the CPU +11:40 < matches> Somehow I don't think that is going to be sufficiently impressive progress in the meeting +11:41 < sulix> Oooh... I'm looking forward to trying that. +11:41 < sulix> I have an impressive Quadtree demo to do! +11:41 < sulix> Assuming the bezier stuff doesn't suddenly break. +11:41 < matches> ... it might +11:41 < matches> Ok, I will `git stash` and then `git pull` as opposed to merging +11:42 < matches> Yes, there are definitely not randomly missing beziers in your code +11:44 < matches> Wait, was your quad tree working with beziers before? +11:44 < matches> It wouldn't have been? +11:44 < matches> All the bounds were wrong +11:48 < matches> Ooh +11:48 < matches> H and V +11:48 < matches> What are they +11:49 < sulix> Horizontal and Vertical lines +11:49 < matches> Ah +11:50 < sulix> The QuadTree works with beziers, but doesn't increase precision. +11:52 < matches> Hmm, now to work out which of the 5 or 6 edge cases is breaking the Bezier bounds algorithm +11:53 < matches> It's kind of hard to debug +11:53 < matches> The edge cases apply seperately to the y and x directions +11:53 < matches> So you can't tell just by looking at a curve that it is an edge case +11:54 < matches> Unless you are a mathemagician I guess +11:55 < matches> I don't understand +11:55 < matches> The bounds for the beziers that disappear look right +11:59 < matches> Maybe I'm not uploading the data correctly anymore +12:03 < matches> Ok now it only breaks for the horizontal and vertical lines which I at least understand +12:03 < matches> I was iterating over the object bounds and uploading the ones that had a type of BEZIER +12:03 < matches> Oh +12:03 < matches> Oh +12:04 < matches> Yeah because I added a GROUP as well +12:04 < matches> And every gets a GROUP now +12:04 < matches> So the order of indexes must be off +12:14 < matches> Face palm +12:14 < matches> This is why we have objects.data_indices +12:19 < matches> I wish I'd added the SVG stuff earlier +12:19 < matches> It makes it a lot easier to do stuff when you can mess around with actual documents +12:42 < matches> I have pushed some stuff +12:43 < matches> Mostly it just looks like I added a bunch of colourful rectangles to the CPU rendering +12:43 < matches> I think I broke the Quad tree too +12:43 < matches> Go team +12:43 < matches> Oh and there are a bunch of not so colourful GPU rectangles +12:43 < matches> Due to the "GROUP" object just using the outline rectangle shaders +12:44 < matches> So part of the quad tree seems to work on the GPU but not all of it +12:44 < matches> And none of it seems to work on the CPU? +12:48 < matches> Also instead of rendering a slightly broken fox it now renders a segfault +12:48 < matches> Similarly for the koch snowflake +12:48 < matches> It's alright we can still draw Humphrey +12:53 < matches> Oh +12:53 < matches> It's just the quad tree that segfaults on the more complicated svgs +13:38 < sulix> I have returned from the committee meeting, and that stupid 2/3rds majority thing has been revoked! +13:38 < matches> Hooray! +13:39 < matches> I should head towards University for the project meeting +13:39 < matches> It is tempting to just stay home +13:40 < matches> But that would probably not be wise +13:41 < sulix> You should come. +13:41 < sulix> I'm going to see if I can fix the Quadtree, but it looks like your changes have thoroughly broken it. +13:41 < matches> Sorry! +13:41 < sulix> By which I mean, it probably was only working if everything had bounds (0,0)-(1,1) +13:41 < matches> Haha +13:42 < matches> You can just undo my changes to demonstrate it if you want +13:42 < matches> To the bus +13:43 < sulix> I may yet do that... +14:54 * sulix -> CSSE +19:08 < matches> So shading on the CPU sort of totally breaks +19:08 < matches> But it exists +19:08 < matches> Progress! +19:10 < matches> Bezier bounds are not as good as I'd hoped +19:10 < matches> I think they only work if the end points form the bounds +19:17 < sulix> Ah... +19:21 < sulix> Btw, in the default "c" glyph, there are _two_ curves with bounds (0,0)-(1,1) +19:21 < sulix> Numbers 9 and 18 +19:22 < matches> Yeah I found the wierd ebounds +19:22 < matches> It's in the font code +19:22 < matches> There is an AddBezierData with (0,0,1,1) instead of AddBezier (which automatically works out the bounds) +19:22 < matches> For vlines +19:22 < sulix> That'd do it. +19:23 < matches> shape.svg seems to lose part of the curve now +19:23 < matches> I've made the bezier control points relative +19:23 < matches> Things mostly sort of work +19:23 < matches> But the quad tree still looks fantastically broken +19:25 < sulix> It always looks broken if you pan around or zoom out: it's my ugly baby. +19:28 < matches> http://szmoore.net/ipdf/brokenbeziers.png +19:28 < matches> To be fair the beziers are actually fine +19:28 < matches> It's just the bounding rectangles that are broken +19:28 < matches> Also shading should probably not be turned on unless it is actually a closed path +19:29 < sulix> Hmm... +19:29 < matches> Wait +19:29 < matches> The beziers are rendering fine +19:29 < matches> But the bounding rectangles are wrong +19:29 < matches> Does this mean +19:29 < matches> If I *fix* the bounding rectangles +19:29 < matches> It will break something +19:29 < matches> :-( +19:29 * matches forges ahead nevertheless +19:30 < matches> It does look suspiciously like it is only ever using P0 and P3 for the bounds +19:30 < matches> Despite all that horrible solving for the turning points +19:31 < sulix> Yeah. +19:31 < matches> Oh +19:32 < matches> I suspect if I fix this it will totally break the absolute to relative bezier transform then +19:35 < matches> The file for those beziers is kind of interesting +19:35 < matches> inkscape has used absolute commands for all except one of the beziers +19:35 < matches> Why? +19:35 < matches> The first one was copied and pasted with the control points moved +19:35 < matches> Also for some reason random "translate" applied to the whole group +19:36 < matches> It might make some sense if it caused the coordinates of the actual paths to come out as integers maybe +19:36 < matches> But they don't +19:37 < matches> There is translate and then the initial "moveto" is not 0,0 +19:37 < matches> I guess we shouldn't be trusting an svg editor that segfaults if you try recursion anyway +19:59 < matches> Ok, high school maths:1, 5th year science/engineering student:0 +20:15 < matches> Also my amazingly clever shading algorithm has +20:15 < matches> ... +20:15 < matches> issues +20:15 < matches> When the paths are not in the view +20:16 < sulix> Ah... +20:18 < matches> In fact it has many issues in many cases +20:27 < matches> Hmm +20:27 < matches> I wonder if this is what causes problems with evince/atril +20:27 < matches> Ok not this +20:28 < matches> I mean, if they use a similarly terrible except actually working shading algorithm +20:28 < matches> And just draw everything to a really big texture so they can use it +20:28 < matches> As opposed to clipping things +20:28 < matches> That seems a little unbelievable though +20:29 < matches> Surely that would crash long before you even got to >1600% +20:30 < matches> I suppose what I should really do is look up some papers on shading +20:30 < matches> Blergh +20:35 < matches> Things are pushed +20:37 < matches> Ah crap +20:38 < matches> Things will be pushed in 8 hours according to my clock +20:38 < matches> Just don't do anything until after 4am tomorrow and everything will be in the right order +20:38 < matches> :P +20:39 < sulix> That shading is _amazing_ +20:40 < matches> Try replacing the colour with rand()%255 for even more amazingness +20:40 < sulix> If you zoom in _just_ the right amount, all hell breaks loose. I love it! +20:40 < matches> Haha +20:40 < sulix> Slowly panning across it is also magical! +20:41 < matches> Try it on rabbit_simple.svg +20:42 < sulix> I think Humphrey might have come down with a case of stripey binary myxomatosis. +20:43 < matches> So I will have to think about shading a bit more :P +20:43 * sulix braves the unholy combination of shading and quadtree. +20:43 < matches> Oh I didn't try that +20:44 < sulix> It actually doesn't look any different. +20:44 < sulix> I think the quadtree only breaks w/ the GPU. +20:44 < matches> Yes +20:45 < matches> You lose the debug message if the node # > 9 it seems too +20:46 < matches> At least the quad tree works on the CPU +20:46 < matches> But why doesn't it work on the GPU they are now using the same bounds +20:47 < matches> So should I prepare a report for Tim? +20:47 < matches> Progress Report: Arbitrary precision numbers are unsurprisingly, totally infeasible +20:47 < matches> Therefore, we implemented random bits of SVG +20:47 < matches> Figure 1: A totally broken shading algorithm +20:48 < sulix> You should include this image of the quadtree: http://davidgow.net/stuff/ipdf-humphreys-ghost-face.png +20:48 < matches> Yes +20:48 < matches> I wonder if since we're allegedly engineers we should document what bugs go with what images +20:48 < matches> Hmmm +20:49 < sulix> That's why I name the screenshots like that, I know this goes with the "Humphrey's Ghost Face" bug. +20:49 < matches> Haha +20:49 < matches> So we have the svg-test images +20:50 < matches> Would it be worth while to have a commit script that automatically drew them and did screnshots +20:50 < matches> It might be tricky though because you have to test panning and zooming and things +20:50 < sulix> Yeah... perhaps videos? +20:51 < matches> We'd need to be able to control the view automatically +20:51 < matches> Which is actually required for that list of things in the proposal we are supposed to do anyway +20:52 < sulix> I think we'll want that feature at some point anyway for doing proper performance tests +20:54 < matches> I kind of want some sort of debug overlay for things like the bounding boxes too +20:54 < sulix> Hmmm... the bounds look right: http://davidgow.net/stuff/ipdf-humphrey-bounds-ahead.png +20:54 < matches> And a menu system +20:54 < matches> And the ability to "insert SVG here" +20:54 < matches> And open a file browser +20:54 < matches> And... +20:54 < matches> And... +20:54 < matches> Yeah +20:54 < sulix> I've been seriously considering doing a menu system. +20:54 < matches> Too bad christmas is after the thesis is due +20:54 < matches> Do it! +20:55 < matches> We're running out of mouse buttons to toggle things :P +20:55 < matches> Are there any SDL based menu systems that we can use easily? +20:55 < sulix> There are a couple of OpenGL-y ones that might work. +20:56 < matches> Let's not port the project from SDL -> FreeGlut +20:56 < sulix> No. +20:56 < sulix> Let's not. +20:57 < sulix> (I'm looking for an SDL/OpenGL menu system so that I can replace FreeGLUT in the Graphics project( +20:57 < matches> Could we use Qt or is that overkill? +20:57 < sulix> I suspect it's probably overkill. +20:59 < sulix> I've got a couple of old GUI libraries for SDL/OpenGL I wrote in high school I could dig up as a last resort. +20:59 < matches> ... I have seen your high school code +20:59 < matches> :P +20:59 < sulix> (I think one of them uses a tiny bit of boost, though, so I'd rather avoid it) +21:03 < matches> I kind of want to look at Qt at some point +21:03 < matches> Maybe if we have the menu in a seperate window... +21:03 < matches> Then we need threads... +21:03 < matches> Then we have two problems... +21:09 < matches> All the links to SDL libraries are broken +21:34 < sulix> I'm not sure what changed, but now ipdf crashes my OpenGL debugger. +21:42 < sulix> The QuadTree/GPU code works again! +21:42 < sulix> Somehow the bug I fixed last night reappeared, but I've added the needed *2s back in. +--- Day changed Fri Aug 15 2014 +08:43 < matches> So it seems to work well but things still go wierd on the GPU +08:44 < matches> I'm in Quadtree node 32 looking at the tip of Humphrey's eyebrow +08:44 < matches> The bottom line moves normally +08:44 < matches> Vertically only sorry +08:44 < matches> It doesn't move horizontally +08:44 < matches> The top line stays still and every so often jumps to a new (wrong) position +08:45 < matches> On the CPU it appears fine though +08:45 < matches> Although on the CPU it doesn't show the "Current View QuadTree Node: 32" +08:46 < matches> Hrm, I should add a 2d view of a car to the svg-tests +08:47 < matches> Then I can be like "IT IS RELEVANT TO MECHANICAL ENGINEERING BECAUSE BEZIERS" +08:47 < matches> In the conference/thesis offense +08:48 < matches> My concern is actually more how I'm going to present the arbitrary precision number representations because they don't even work +08:49 < matches> Well I should probably try Gmp rationals and Gmp floats before totally giving up I guess +08:49 < matches> And also those p-adic things +08:50 < matches> I never looked them up +--- Day changed Sun Aug 17 2014 +14:38 < matches> Hey Qt has a lot of stuff in it +14:38 < matches> They have their own iostreams that seem identical to std::iostream +14:39 < matches> It's kind of cool I guess except there are "Qs" everywhere +14:41 < matches> Ok we need a window icon +14:41 < matches> This is vital +15:54 < sulix> I've got SDL2 window icon setting code if you want it: https://github.com/sulix/omnispeak/blob/master/src/icon.c#L555 +16:04 < matches> Cool +16:39 < matches> I'm bringing in spaghetti +16:39 < matches> I mean Qt +16:40 < matches> In theory this means the Debug functions should have a mutex if we want to debug things in the Qt stuff +16:40 < matches> But in practice screw it +16:40 < matches> What could go wrong? +16:41 < matches> (Don't worry, I have a CONTROLPANEL_DISABLED define) +16:42 < matches> This View/Document/Screen thing could probably be tidied up a lot +16:42 < matches> But effort +16:42 < matches> I think I'll just give ControlPanel direct access to document, screen and view +16:42 < matches> Currently everything has to go through view +16:43 < matches> Which would make more sense if some of screen was in view maybe +16:43 < matches> Bah screw design +16:51 < matches> So now we have 4 main classes! +16:51 < matches> 4 x the fun! +17:29 < matches> Bargh Qt needs its own version of make +17:29 < matches> That's stupid +21:09 < matches> So +21:10 < matches> I have a mysterious LMS deadline that suddenly appeared +21:10 < matches> "Progres Report" +21:10 < matches> Description +21:10 < matches> "asadf" +21:10 < matches> Due +21:10 < matches> 19th August, 11:01PM +21:10 < matches> What +21:14 < sulix> Oh dear. +21:15 < matches> I have sent an email +21:15 < matches> I hope that's not the conference abstract +21:15 < matches> I also really hope we're allowed to use our own computer and things in the conference +21:16 < matches> Also I really hope that if I can use my own computer it doesn't decide to shit itself anyway just to spite me +--- Day changed Mon Aug 18 2014 +17:06 < matches> Good news and bad news! +17:07 < matches> The kerning now appears to kern in the right direction +17:07 < matches> But this means "BleedingCowboys.ttf" works +20:30 < sulix> It's a pain to look up clipping of beziers, because there's a separate technique for doing something else called "bézier clipping" +20:40 < matches> Baha +20:41 < matches> I'm basically just procrastinating with Qt +20:41 < matches> I mean +20:41 < matches> Doing *awesome* things with Qt +20:48 < sulix> I am looking with considerable envy at SolveQuadratic(). +20:49 < sulix> SolveCubic() will get very ugly. +20:49 < sulix> Assuming I don't just sample the cubic at 100 points and look for roots. +20:49 < matches> Haha +20:49 < matches> Newton Raphson? +20:50 < sulix> Very tempting. +20:50 < matches> Then you can solve any bezier! +20:50 < matches> Then we can put in Quintics! +20:50 < sulix> Solving cubics exactly is not fun. +20:50 < sulix> Dear god no. +20:50 < matches> Imagine how many loops a quintic could have... +20:51 * sulix cries quietly in the corner. +20:53 < matches> So I'm calling AddText with sane values and nothing is happening :( +20:56 < sulix> With or without quadtree? +20:56 < sulix> With quadtree, everything is broken if you try adding things. +20:56 < sulix> Because they won't be added to a node. +20:57 < matches> No quad trees I think +20:57 < matches> Yeah no quad tree +21:00 < matches> Wait I think we need to rebuild the buffers or something +21:07 < matches> Ah, ForceRenderDirty() +21:14 < matches> I don't think the scale of our text is quite right? +21:14 < sulix> Well, the scale of everything is wrong, but it's entirely possible that the text is _extra wrong_ +21:16 < sulix> In theory, the "scale" input to addText is the "height" of a character. +21:19 < matches> Mmm +21:19 < matches> I'm trying to add text relative to the current view +21:19 < matches> But it isn't consistent +21:19 < matches> When I go to a different view it is definitely not adding it in the same relative place +21:20 < matches> The scale and positions aren't *already* relative are they? +21:22 < sulix> Not to the view... +21:24 < matches> What are they relative to? +21:24 < matches> Anyway instead of fixing that bug I'm adding more +21:25 < sulix> Umm... The bounding box maybe? +21:25 * sulix investigates. +21:26 < sulix> Scale and position should (I think) be normal, document coordinates. +21:26 < matches> Odd +21:26 < matches> Oh well +21:26 < matches> Having Qt is totally worth it by the way +21:27 < matches> Although it is still slightly embarrassing that it has its own SVG parser +21:27 < matches> Ours is better! +21:27 < matches> It has Reals everywhere! +21:27 < matches> Except where it constructs Real from floats... +21:27 < matches> And converts them to floats... +21:28 < sulix> Thesis title should be "Keepin' it real: Staying afloat on the sea of document precision" +21:31 < matches> Bahaha +21:31 < matches> That is brilliant +21:32 < matches> The Qt stuff is never deleting anything +21:32 < matches> I suppose I should fix that at some point +21:33 < matches> So basically it is a state machine and you use the menu to change the state +21:33 < matches> Pressing OK does something depending on the state +21:34 < matches> And there is a single text edit you can type stuff into +21:34 < matches> In theory it can hide/show different widgets depending on the state +21:34 < matches> I feel like I should add a "Generate Thesis Title" widget now... +21:35 < matches> Also I can sort of see the appeal of lambdas for GUI programming now +21:35 < matches> But I have a feeling they would totally break Qt anyway +21:49 < matches> ... +21:49 < matches> Ok sometimes the text gets added upside down... +21:49 * sulix disclaims any and all responsibility for that. +21:51 < matches> Yes! +21:51 < matches> I finally did that thing I was saying I'd do for like 3 weeks +21:51 < matches> Zoom in to floating point limit +21:51 < matches> Add SVG +21:51 < matches> Watch it explode! +21:52 < sulix> Oooh... +21:52 < matches> It is glorious +21:54 < matches> We need to be a bit careful with thread safety in qt +21:55 < matches> Really we should be able to request that the qt thread call UpdateAll itself +21:55 < matches> Rather than calling it directly from the viewer thread +21:55 < matches> But I'm not sure how that's done +21:55 < matches> There's all this stuff about "Cross thread signals" on the internet +21:56 < matches> It seems you can hide/show things but not much else +22:47 < matches> Bah you pushed things! +22:55 * sulix proclaims the new features as excellent and promptly goes to bed. +--- Day changed Tue Aug 19 2014 +18:08 < matches> My conference is in the week starting 13th October +18:08 < matches> Is Tim back then? +18:08 < matches> "your supervisor will be invited to attend and mark your presentation" +18:09 < matches> So if he can't go... I don't get a mark? +18:12 < matches> It sounds suspiciously like they are going to get everyone's supervisors to mark them and then just scale everyone :S +18:13 < matches> Surely at least one other person is going to read the final report... +18:13 < matches> I've heard bad things about the engineering scaling system +18:14 < matches> Your mark becomes inversely proportional to how well your supervisor's students did the previous year or something like that +18:15 < matches> Anyway, two months left to accomplish something! +20:05 < sulix> Worked out why the font bounds were weird. +20:06 < sulix> AddText takes (msg, scale, x, y) not (msg, x, y, scale), so the coordinates were all bunk. +20:09 < sulix> Fonts looks _amazing_ with floating pt errors, too. +20:09 < sulix> http://davidgow.net/stuff/ipdf-i-think-you-mean-comic-fail.png +20:29 < sulix> The Art of Computer Programming briefly mentions the Stern-Brocot tree, btw. +20:29 < sulix> I can't see it being really useful, though. +21:06 < sulix> My difficulty clipping bézier paths may be because it is actually impossible. +21:06 < sulix> I think I've just found a paper saying that it is only possible for béziers which happen to be straight lines. +22:55 < sulix> Never mind, it is possible, it's just very nasty. +23:15 < sulix> Also C++14, because we need more lambdas: https://isocpp.org/blog/2014/08/we-have-cpp14 +--- Day changed Wed Aug 20 2014 +12:05 < matches> I guess we've accomplished the goals for this week's meeting then! +12:05 < matches> (That shading algorithm totally counts as a "first attempt") +12:07 < sulix> I'm about 2/3rds of the way through deriving the reparametrisation of béziers. +12:08 < sulix> It basically just boils down to pages and pages of rearranging polynomials. +12:38 < sulix> I managed to get the qt4/qt5 monstrosity compiling on my laptop. +12:38 < sulix> It has a "moc-qt4" program, which works, whereas "moc" is qt5. +16:28 < matches> I think I need to stop adding this log to git... +23:08 < sulix> matches: But then, how would history record that I've finally got a maybe-correct derivation for cubic bézier reparametrisation: http://davidgow.net/stuff/cubic_bezier_reparam.pdf +23:08 < sulix> (Code is in git) +--- Day changed Thu Aug 21 2014 +12:57 < sulix> So it turns out that quadtrees are hard, and reparametrising béziers is why. +13:03 < matches> I don't seem to see anything anymore with the quad tree enabled +13:10 < sulix> The quadtree doesn't let you add things in realtime. +13:10 < sulix> Quadtree nodes are immutable once created. +13:12 < matches> Ah +13:35 < sulix> debug: ReParametrise (bezier.h:190) - (0.000000,0.000000),(1.000000,1.000000),(1.000000,1.000000),(1.000000,1.000000) -> (-nan,-nan),(-nan,-nan),(-nan,-nan),(-nan,-nan) +13:36 < sulix> Looking good! +13:54 < sulix> Clearly, the quadtree rendering is now perfect: http://davidgow.net/stuff/ipdf-this-is-definitely-a-fox.png +--- Day changed Sun Aug 24 2014 +17:51 < matches> ... +17:51 < matches> I am parsing CSS in the SVGs +17:51 < matches> WHAT HAVE I DONE +17:52 < matches> Blame inkscape for always using css to control the properties +17:57 < matches> http://szmoore.net/ipdf/death-by-shading.png +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... +--- Day changed Mon Sep 01 2014 +17:05 < matches> The wobbly lines on things are irritating me +17:10 < matches> There doesn't seem to be anything wrong with Bresenham, which means the actual line endpoints are wrong +17:11 < matches> The GPU does everything from floats and magically they go to the right spot in the buffer +17:11 < matches> The CPU has to calculate integer pixel coordinates +17:16 < matches> I need a magnifier I can't see the pixels that are in the wrong spot +17:16 < matches> I know they are there +17:21 < matches> ... ok maybe the Bresen Ham was a little past its use by date +19:48 < matches> The more I try and get these lines to not look dumb, the more convinced I become that glDrawLines is doing something fancy +19:56 < matches> You end up with wiggles in the line because the end points round to a different pixel to what you end up at by drawing the line +19:57 < matches> If you make sure you start from where the last line ended, you still get a bend because of the left over error from the last line +19:58 < matches> ... +19:58 < matches> Drawing a single line when you know the Bezier is actually a single line is probably going to be less rage inducing than trying to fix this +21:01 < matches> The Beziers are now classified according to Loop and Blinn +21:01 < matches> Well +21:01 < matches> Maybe +21:01 < matches> It at least knows what lines are +21:01 < matches> ... +21:02 < matches> Ok all the ttf beziers are SERPENTINE and LOOP so that's probably wrong +21:43 < matches> Ah, floating point precision strikes again +21:43 < matches> That's kind of annoying +21:47 < matches> But I suppose it's relevant +21:47 < matches> Unless I'm totally screwing something up +21:48 * matches adds in arbitrary fabs(x) < 1e-6 checks +21:58 < matches> On the other hand, if you use DeCasteljau and stop the sub dividing whenever you get to something that classifies as a line, it's actually pretty cool +21:59 < matches> But if you zoom in too far it starts to get classifications totally wrong +22:02 < matches> Yeah I have an abstract due in 2 weeks +22:02 < matches> so screwed +--- Day changed Tue Sep 02 2014 +13:42 < matches> Ok, let's not use floating point values for colours +13:42 < matches> Baad +13:43 < matches> Bad bad +13:43 < matches> Bad sheep +13:43 < matches> The project isn't about precision of representable colours +13:44 < matches> So I'm perfectly OK with using uint8 for colour components +18:53 < matches> Is it too late to change the aim of the project to "render svg-tests/fox.svg but without antialiasing" +18:54 < matches> "Or using the GPU" +18:55 < matches> Well, I understand why shading doesn't usually use flood fill now anyway +18:55 < matches> But I still kind of think flood fill is better at high resolutions +18:56 < matches> Not parallelisable I guess +18:56 < matches> ... Or is it +18:57 < matches> I was going to try and do arbitrary precision stuff but it seems we can no longer compile unless Real == double or float +--- Day changed Wed Sep 03 2014 +17:26 < matches> It would seem Mr Munroe has beaten us... +17:28 < matches> In Javascript +17:28 < matches> We should die of shame +17:29 < matches> Hahaha +17:29 < matches> "// there is no elegance here. only sleep deprivation and regret" +17:31 < matches> On the bright side, we now have a reason to reference xkcd +17:31 < matches> I guess? +17:59 < sulix> I just saw that, and had planned to use that comment as my next commit message. +--- Day changed Thu Sep 04 2014 +10:59 * sulix sulix also engages panic mode. +11:00 * sulix apparently also needs to engage sleep mode. +11:00 * sulix almost engaged sheep mode by mistake. +11:49 < sulix> How sure are you that SolveCubic works? +18:37 < matches> Well, sure within 1e-4 +19:40 < matches> Rational compiles again +19:41 < matches> It just takes... several minutes... to load "The quick brown fox jumps over the lazy dog" +21:04 < matches> I have a new ingenius plan +21:06 < matches> This will probably not work but hopefully it won't take me too long... +21:06 < matches> Oh dear what am I saying +21:06 < matches> It's going to take a month now +22:24 < matches> I really should be integrating one of those two libraries Rowan suggested into the project +22:24 < matches> As opposed to implementing what I like to call the "Paranoid Number" +22:25 < matches> It starts as a float +22:25 < matches> It checks each operation for an exception, and if it does it adds the operation to a linked list instead +22:25 < matches> After trying to simplify the next elements in the list +22:26 < matches> This is going to be awful +22:26 < matches> But it's been a while since I wrote a good linked list +22:32 < matches> ... I think the last linked list I wrote had a nasty tendency to randomly segfault... +22:32 < matches> Nevertheless we shall forge ahead +23:14 < matches> You know you haven't had enough sleep when you start to terminate lines with ':' instead of ';' +23:14 < matches> I blame python +23:14 < matches> Not that it was valid python syntax either +23:15 < matches> But it's a good scapesnake +23:42 < matches> Oh recursive list based functions +23:42 < matches> How I have missed you +23:42 < matches> void Foo() {if (m_next != NULL) m_next->Foo();} +23:42 < matches> <3