X-Git-Url: https://git.ucc.asn.au/?p=ipdf%2Fdocuments.git;a=blobdiff_plain;f=irc%2F%23ipdf.log;h=6b3f2e28faea8ef4dfc7561488477e1f3373db6e;hp=1649e774ea34cb6d47dd718a351069b5e781cfcd;hb=23895a200aa9ae4e64a0a66e158f7a0a9693ca7d;hpb=dc85acc6c84b5e72e5be4e2cc99d4318c97df221;ds=sidebyside diff --git a/irc/#ipdf.log b/irc/#ipdf.log index 1649e77..6b3f2e2 100644 --- a/irc/#ipdf.log +++ b/irc/#ipdf.log @@ -3492,3 +3492,271 @@ 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.