Timestamps are in GMT/BST.
| 00:01:39 | | Skybax has joined |
| 00:08:12 | FoOtloOse | sky! *poke* hows bittown coming along? |
| 00:09:11 | fordcars | lol footie |
| 00:09:20 | fordcars | night guys, off to bed |
| 00:09:24 | FoOtloOse | aw :c |
| 00:09:24 | | fordcars Quit (Quit: http://www.kiwiirc.com/ - A hand crafted IRC client) |
| 00:09:25 | FoOtloOse | night |
| 00:21:17 | | koda Quit (Quit: koda) |
| 00:23:05 | Skybax | It's coming along good FoOtloOse lol |
| 00:23:24 | FoOtloOse | i predict duckys house will crash the map. |
| 00:23:31 | FoOtloOse | :D |
| 00:23:34 | Skybax | His house in insane |
| 00:23:37 | Skybax | *is |
| 00:23:42 | FoOtloOse | can i see? c: |
| 00:23:55 | Skybax | Just a sec.. have to add another house that I got |
| 00:23:59 | FoOtloOse | las? |
| 00:24:05 | Skybax | Yeup |
| 00:24:11 | FoOtloOse | SWASTIKAAAAAAAAAA |
| 01:06:06 | | koda has joined |
| 01:18:17 | | Invisible1 has joined |
| 01:24:20 | | Skybax Quit (Ping timeout: 248 seconds) |
| 01:34:40 | | watusimoto has joined |
| 01:34:40 | | ChanServ sets mode +o |
| 01:35:46 | | HylianSavior Quit (Quit: Leaving) |
| 01:46:08 | | kaen Quit (Ping timeout: 240 seconds) |
| 01:54:04 | | kaen has joined |
| 02:13:35 | | FoOtloOse Quit (Quit: Page closed) |
| 03:00:19 | | Invisible1 Quit (Ping timeout: 248 seconds) |
| 03:22:30 | | kaen Quit (Ping timeout: 256 seconds) |
| 04:16:33 | | Darrel has joined |
| 05:05:38 | | Darrel Quit (Ping timeout: 268 seconds) |
| 05:05:55 | | Darrel has joined |
| 05:32:57 | | Darrel Quit (Ping timeout: 246 seconds) |
| 05:52:03 | | Watusimoto_ has joined |
| 06:31:37 | | Watusimoto_ Quit (Ping timeout: 240 seconds) |
| 07:33:19 | | Nothing_Much Quit (Ping timeout: 240 seconds) |
| 07:56:09 | | Nothing_Much has joined |
| 08:22:19 | | kaen has joined |
| 09:22:32 | kaen | so, I've finally gotten boost.poly all the way to building connected meshes, only to find that its "trapezoids" are actually polygons of arbitrarily many vertices with a trapezoidal convex hull. Further, no boost library (checked Graph, Geometry, and Polygon) currently has a triangulation api. Finally, none of these libraries support a "merge to convex polys" operations. This means that using Boost.Polygon would still require triangulation and convex poly |
| 09:22:32 | kaen | merging support from our existing libraries. |
| 09:23:14 | kaen | therefore, I'm going to try again with CGAL, which explicitly lists APIs for all three of these functions, and could single-handedly replace all of our geometry libraries (although that's what I thought about Boost, too) |
| 09:36:22 | watusimoto | Good grief... what a bummer! |
| 09:37:40 | watusimoto | just to beat this to death, we are not using triangle because of the license, which keeps us from being listed in the default Debian package manager |
| 09:38:08 | watusimoto | But if we sucked the triangle code into our codebase, would that fix (or obscure) the issue? |
| 09:39:08 | watusimoto | because we are distributing the ensemble under a compatible license (glossing over the potential for disagreement between us and the triangle authors) |
| 09:47:40 | | raptor has joined |
| 09:47:41 | | ChanServ sets mode +o |
| 09:52:28 | raptor | good morning! |
| 09:52:42 | raptor | man, what on earth is going on at work this morning - everyone is gabbing in the hallway |
| 09:55:02 | raptor | kaen: that's sad! (regarding boot.polygon) |
| 09:55:08 | raptor | *boost |
| 09:55:22 | kaen | Debian actually has a legal review team that look at submitted packages before the technical and security teams review it |
| 09:55:46 | raptor | also, for what it's worth, I think you did right with removing Circle |
| 09:55:53 | kaen | so I mean could try to slip one by them, but that doesn't sit well with me |
| 09:55:56 | kaen | thanks, raptor |
| 09:56:06 | kaen | I've been getting a lot of grief about it ._. |
| 09:56:06 | raptor | nah - let's do things the 'correct' way |
| 09:56:25 | kaen | I got boost.poly down to 29 seconds on celtic arena |
| 09:56:43 | kaen | but I think that's the limit, so we'd be looking at potentially massive decreases in speed anyway |
| 09:56:45 | raptor | oh good! that's probably close to correct (since my test was on an i7) |
| 09:56:49 | kaen | CGAL is older and more venerable |
| 09:57:19 | kaen | hopefully more robust, less picky, and more performant since it doesn't do this templatized concept/trait dance that boost does |
| 09:57:46 | raptor | wait wiat... boost.polygon says it does triangulation |
| 09:57:54 | kaen | where? |
| 09:58:26 | kaen | I does voronoi decomposition which *uses* delauney triangulation, but doesn't expose that api afaik |
| 09:58:30 | kaen | It does* |
| 09:58:32 | raptor | ahhh |
| 09:58:35 | raptor | ok that's it... |
| 09:58:39 | kaen | yeah, that's a real bummer, btw |
| 09:58:47 | kaen | oh, interesting tidbit: |
| 09:58:58 | kaen | poly2tri was submitted for inclusion into boost as a triangulator |
| 09:59:06 | raptor | oh?? |
| 09:59:07 | kaen | then it was torn to bits by the boost maintainers :) |
| 09:59:33 | raptor | ha! |
| 09:59:41 | kaen | yeah, they said it is neither numerically nor algorithmically robust |
| 09:59:51 | raptor | well stink |
| 10:00:00 | raptor | actually |
| 10:00:28 | raptor | if we found a fast triangulation library just to replace poly2tri, and maybe that uses integers, that would be goog |
| 10:00:30 | raptor | *good |
| 10:00:47 | kaen | yep, that would be good at this point too |
| 10:01:02 | kaen | I really don't want to release with the triangulator segfaulting on bad inputs |
| 10:01:09 | kaen | granted, those inputs are few and far between |
| 10:01:16 | kaen | so maybe it wouldn't be so bad |
| 10:02:03 | kaen | but I can just imagine quartz' wrath when he's been working on a level for hours straight without saving, goes to test a new crazy-looking polywall fixture, and segfaults. |
| 10:02:19 | raptor | yeah, any segfault is a critical error |
| 10:02:29 | kaen | (that happened to me when working on biosynthesis) |
| 10:02:34 | raptor | :( |
| 10:02:46 | | kaen shrugs |
| 10:04:12 | kaen | cool! CGAL has a CMakeLists |
| 10:04:26 | kaen | I *love* untarring a project and finding one ready to use |
| 10:04:36 | raptor | ha! |
| 10:04:53 | raptor | oh interesting, I think i found the mailing thread on using poly2tri in boost |
| 10:05:06 | kaen | very probably |
| 10:06:23 | kaen | Andrii (the guy who deposes it) is one who implemented Voronoi in boost poly |
| 10:06:30 | kaen | is the one* |
| 10:16:41 | | Canseco has joined |
| 10:18:32 | | Watusimoto_ has joined |
| 10:36:13 | kaen | hmm |
| 10:36:26 | kaen | CGAL requires GMP and MPFR |
| 10:36:56 | kaen | I don't know how we want to proceed |
| 10:39:57 | kaen | I think it'd be easiest for now to try just replacing poly2tri, since that's the culprit for the segfaults |
| 10:43:34 | | koda Quit (Ping timeout: 268 seconds) |
| 10:54:46 | | Canseco Quit (Quit: Leaving) |
| 10:55:50 | | watusimoto Quit (Ping timeout: 256 seconds) |
| 11:11:36 | raptor | kaen: could we make poly2tri more robust somehow? |
| 11:12:37 | raptor | like replace floats with ints |
| 11:12:38 | kaen | possibly, although I don't know the specifics of the algorithm |
| 11:12:48 | kaen | well, that's not what's causing the segfaults |
| 11:12:50 | raptor | I wonder if just doing floats -> ints would work |
| 11:12:59 | kaen | eh, it's worth a shot |
| 11:13:15 | raptor | I know there is some algorithmic problem with floats really close together |
| 11:13:33 | raptor | actually |
| 11:13:55 | kaen | but the segfaults come from holes that share verts with their containing polygon, and I was able to make a repro case using only integers |
| 11:14:02 | raptor | maybe I should post the input to poly2tri from Insignia to their bug tracker? |
| 11:14:12 | kaen | yes, that might help |
| 11:14:17 | raptor | oh really!? |
| 11:14:23 | kaen | the poly2tri guy seems to have checked out somewhat |
| 11:14:52 | kaen | there's a patch someone submitted to remove the using namespace std from the public header, it's been four months and he still hasn't merged it |
| 11:15:08 | raptor | I've gotten responses from him, however |
| 11:15:19 | kaen | well, it can't hurt to try |
| 11:16:09 | kaen | what I'm doing right now is trying to wire polypartition into your poly2tri adapter |
| 11:16:23 | raptor | why does that sound familiar? |
| 11:16:29 | raptor | did we try that one before? |
| 11:16:30 | kaen | because pp's only problem was with nested holes, which you solved for poly2tri |
| 11:16:31 | kaen | yes |
| 11:16:44 | raptor | ah ok |
| 11:17:01 | kaen | I figure if your tree-traversal worked for poly2tri, it might work for polypartition |
| 11:20:06 | raptor | do youw ant me to post the data to poly2tri? I would like to use your reproduction case (the one with ints) |
| 11:22:02 | kaen | bah |
| 11:22:08 | kaen | looks like I didn't commit it to the test battery |
| 11:22:13 | kaen | I lost it with the wipe |
| 11:24:48 | raptor | noooo |
| 11:30:05 | kaen | oh, they already know about the stack overflow: https://code.google.com/p/poly2tri/issues/detail?id=34 |
| 11:31:02 | raptor | is that the same? |
| 11:32:18 | kaen | that's the same ultimate error, judging by the stack trace |
| 11:32:40 | raptor | i'm reading the whole thing... trying to understand |
| 11:32:41 | kaen | one of the two that I've hit |
| 11:33:00 | kaen | the other one (the one I wrote the repro for) hits an assertion |
| 11:33:44 | kaen | whoa, "This is an algorithmic issue. Yes is fail due to precision but a slightly different algorithm should handle these cases." |
| 11:33:59 | kaen | near the last comment |
| 11:35:02 | raptor | that figure wth the abcd is exactly the problem with insignia (causes by bad float precision in the level file) |
| 11:35:14 | kaen | so... maybe we just need to floor our points? |
| 11:36:50 | kaen | for the bot zone triangulation, that doesn't sound so bad. The maximum error that will introduce is 1, and if we do it after the scale then the ultimate error visibile to the user should be close to nil |
| 11:37:46 | kaen | actually 1 is the *limit* of the error, if we're being rigorous. |
| 11:38:30 | raptor | i'm considering changing the inputs to just be ints... but, would debian allow an altered library like that? (is poly2tri in debian?) |
| 11:39:23 | kaen | looks like it is not |
| 11:39:42 | kaen | but, if we floor the inputs from our side then we'll get the same result |
| 11:39:53 | raptor | oh good - because then we can hack away! Did he say that his better algorithm was in the java version? |
| 11:39:59 | raptor | no no |
| 11:40:11 | kaen | yes, the java version |
| 11:40:14 | raptor | I'm thinking about throwing in the upscaled clipper points |
| 11:41:25 | kaen | wait a second... if we're getting the inputs from the clipper already, we should already have integers |
| 11:41:33 | raptor | yep |
| 11:41:34 | kaen | ohhhh, we downscale them before passing them to p2t |
| 11:41:37 | raptor | yep |
| 11:41:51 | raptor | maybe it should be done afterwards instead |
| 11:41:59 | kaen | I think it certainly should |
| 11:44:40 | raptor | maybe if we did that, we could leave poly2tri alone |
| 11:44:56 | | Watusimoto_ Quit (Ping timeout: 245 seconds) |
| 11:44:59 | kaen | I'm giving it a shot at this very moment |
| 11:46:19 | raptor | I wonder about the S64 -> F32; that should probably be OK, F32 should cover our limits, right? |
| 11:46:34 | raptor | it would be more like F32 / 1000 |
| 11:46:50 | raptor | so ~2 million |
| 11:47:18 | raptor | we'd only be able to triangulate up to +/- ~2000000 |
| 11:47:23 | raptor | grid points |
| 11:47:51 | kaen | that seems fine |
| 11:48:22 | raptor | oh... of course it is - recast can only handle up to like 32767 or something |
| 11:53:11 | kaen | well, just moving the scaling outside of the triangulation loop didn't solve it |
| 12:07:25 | | Watusimoto has joined |
| 12:10:27 | raptor | rats |
| 12:12:39 | | Watusimoto Quit (Ping timeout: 272 seconds) |
| 12:21:53 | | Watusimoto has joined |
| 12:24:32 | kaen | IT WORKS, raptor ! |
| 12:24:34 | | koda has joined |
| 12:24:45 | kaen | celtic arena and insignia both triangulate properly |
| 12:24:49 | kaen | and fast |
| 12:25:05 | raptor | oh? |
| 12:25:07 | raptor | what did you do? |
| 12:25:22 | kaen | I tore out p2t and replaced it with pp |
| 12:25:25 | kaen | super easy |
| 12:25:29 | raptor | ha! |
| 12:25:34 | raptor | using floats or ints? |
| 12:25:35 | kaen | wish I would have thought of that a week ago ... |
| 12:25:40 | raptor | upscaled or not? |
| 12:25:43 | kaen | upscaled |
| 12:25:48 | kaen | I think floats, honestly I don't know |
| 12:25:52 | raptor | heh |
| 12:26:07 | kaen | I'm seeing if it fixes the clipPolygons crashes, too |
| 12:28:47 | raptor | whoa... PP has a convex partition part? |
| 12:29:14 | raptor | I wonder if that could replace triangulation + recast? |
| 12:30:12 | kaen | indeed, it seems that it could |
| 12:30:57 | kaen | so ... should I commit ? |
| 12:31:01 | raptor | well... |
| 12:31:20 | raptor | can you get me the patch? also which algo did you use? |
| 12:31:48 | kaen | sure, and Triangulate_EC |
| 12:32:43 | raptor | yeah looks like floats |
| 12:32:54 | raptor | double, actually |
| 12:33:00 | kaen | Triangulate_MONO dropped a section from Celtic, but EC works fine afaict |
| 12:33:21 | raptor | jsut one .cpp file?? |
| 12:34:11 | raptor | i'd like to do some tests with the various algos, in conjunction with possible replacing recast |
| 12:34:22 | raptor | and compare with current timings |
| 12:34:53 | kaen | http://hastebin.com/kahopaxaho.coffee |
| 12:35:24 | kaen | I got scared after looking at the connectivity graph extraction, so I haven't even touched recast yet |
| 12:35:37 | | Watusimoto Quit (Ping timeout: 260 seconds) |
| 12:35:39 | raptor | it is very scary |
| 12:36:00 | raptor | oh, hmm... i wonder if connectivity exists with PP |
| 12:37:10 | raptor | i forgot about that.. |
| 12:37:57 | kaen | honestly this is a massive win as far as I'm concerned |
| 12:38:14 | raptor | hunk #3 failied of GeomUtils.cpp |
| 12:38:18 | kaen | I still haven't crashed clipPolygons yet |
| 12:38:29 | kaen | wha ?? |
| 12:38:43 | | koda Quit (Quit: K Thx Bai) |
| 12:39:06 | raptor | are you rebased to latest? |
| 12:39:45 | kaen | eaea9d29ac0e |
| 12:39:47 | kaen | yes |
| 12:40:35 | raptor | oh, oops, i'm not |
| 12:40:39 | raptor | one moment |
| 12:41:47 | raptor | there we go... ok testing |
| 12:43:59 | raptor | Timings with CelticArena using Triangle (017b): Timings: 666 39 716 |
| 12:44:09 | raptor | that's about average over 4 tests |
| 12:45:06 | kaen | I get 2.3s on my machine for CA |
| 12:45:12 | kaen | using pp |
| 12:45:35 | raptor | ok, that means your new computer is much faster |
| 12:45:37 | raptor | :) |
| 12:45:46 | kaen | hehe |
| 12:46:07 | kaen | well, it's the same one that couldn't finish CA using boost |
| 12:46:16 | kaen | although I eventually got it down to 29s |
| 12:46:41 | raptor | OK with PP: Timings: 676 1021 682 |
| 12:46:50 | raptor | tikes |
| 12:46:52 | raptor | yikes |
| 12:46:55 | kaen | hmm |
| 12:47:07 | raptor | that's almost 2 orders of magnitude slower |
| 12:47:21 | raptor | but the inputs into recast are better |
| 12:47:32 | | thread_ has joined |
| 12:47:56 | thread_ | wow, crowded in here today *sarcasm* |
| 12:48:42 | kaen | it was packed last night :P |
| 12:49:35 | kaen | raptor: mono has the best complexity. maybe we could use pp.RemoveHoles on the input first |
| 12:49:53 | raptor | did you hook into the polytree? |
| 12:50:01 | raptor | then we don't need to use holes? |
| 12:50:16 | raptor | oh wait, yes we do.. |
| 12:50:18 | kaen | uh, your algorithm specifically uses holes |
| 12:50:23 | kaen | heh :) |
| 12:50:24 | raptor | yeah, sorry |
| 12:50:32 | kaen | nbd, it's fresh in my mind |
| 12:50:40 | kaen | also, if we could guarantee orientation we could save a lot of processing from SetOrientation |
| 12:50:56 | kaen | orientation of the polytree I mean |
| 12:50:57 | raptor | i think clipper guarantees that |
| 12:51:01 | raptor | but not sure |
| 12:51:03 | | Watusimoto has joined |
| 12:52:39 | thread_ | raptor: you are just one small typo away from going from orienting a polytree to orienting a palm tree, which, in some ways, is more interesting |
| 12:53:14 | Watusimoto | hi |
| 12:53:15 | kaen | my dad has palm trees in his back yard |
| 12:53:22 | kaen | in washington state |
| 12:53:33 | kaen | I have pictures of them in a foot and a half of snow |
| 12:53:54 | kaen | hi Watusimoto, we fixed the triangulator |
| 12:54:03 | Watusimoto | is it good? |
| 12:54:04 | kaen | by replacing it with polypartition |
| 12:54:04 | raptor | but it's slow... |
| 12:54:10 | kaen | ^ |
| 12:54:11 | Watusimoto | mmmm |
| 12:54:13 | raptor | 39ms vs 1021ms |
| 12:54:23 | kaen | but, that's on CA |
| 12:54:27 | Watusimoto | whoa |
| 12:54:32 | Watusimoto | what is the 39? |
| 12:54:36 | raptor | yes, but we'll need to handle crazy maps like that |
| 12:54:36 | Watusimoto | poly2tri? |
| 12:54:46 | raptor | Triangle/poly2tri, yes |
| 12:55:12 | kaen | which has 2600 polygons *after* merging, which really exacerbates the O(n^2) complexity of the EC algo |
| 12:55:51 | kaen | anyway, it's WIP |
| 12:56:03 | Watusimoto | ok, so the problem with poly2tri is that it crashes |
| 12:56:05 | raptor | but it's not crashing on kaen's cases |
| 12:56:20 | Watusimoto | does poly2tri work on ints or floats? |
| 12:56:24 | raptor | floats |
| 12:56:31 | Watusimoto | could it work on ints? |
| 12:56:43 | kaen | easily |
| 12:56:46 | Watusimoto | (ie some libs let you specify the type with a #define or something) |
| 12:56:52 | kaen | oh, no, not like that |
| 12:56:57 | Watusimoto | could we try poly2tri with int inputs? |
| 12:57:10 | kaen | but if you pass it ints within some specific range they are expressed precisely as floats |
| 12:57:23 | raptor | I'm considering hacking it up a bit to do that... |
| 12:59:09 | | Flynnn has joined |
| 13:02:04 | raptor | kaen: have you looked at this?: http://www.geom.at/fade2d/html/ |
| 13:02:26 | kaen | nope |
| 13:02:39 | raptor | oh... huh... it is bi-licensed |
| 13:03:32 | kaen | wow that looks great |
| 13:03:39 | raptor | rats, I gotta go... back later! |
| 13:04:37 | kaen | later |
| 13:04:43 | | raptor Quit () |
| 13:04:45 | kaen | fade2d requires GMP and appears to be closed-source |
| 13:07:19 | Watusimoto | yes. the license appears more of a problem than triangle's\ |
| 13:20:55 | | thread_ Quit (Ping timeout: 250 seconds) |
| 13:34:06 | | HylianSavior has joined |
| 13:44:48 | | HylianSavior Quit (Quit: Leaving) |
| 13:44:55 | | Flynnn Quit (Quit: This computer has gone to sleep) |
| 14:09:21 | | Flynnn has joined |
| 14:19:48 | kaen | compiling in release mode cut the triangulation time to about 25% |
| 14:20:27 | kaen | I'm about to callgrind it to see if there's some low hanging fruit |
| 14:23:02 | | Flynnn Quit (Quit: This computer has gone to sleep) |
| 14:30:56 | | HylianSavior has joined |
| 14:57:45 | | Skybax has joined |
| 15:16:02 | | raptor has joined |
| 15:16:02 | | ChanServ sets mode +o |
| 15:16:09 | Skybax | Hellos |
| 15:16:34 | raptor | hi |
| 15:17:32 | kaen | hi raptor |
| 15:17:36 | raptor | hi |
| 15:17:46 | raptor | I'm toying with making poly2tri work with S64 |
| 15:17:59 | kaen | compiling with -O3 took me from 2800 for triangulation to 800 |
| 15:18:10 | kaen | I'm using callgrind right now to profile polypartition |
| 15:19:21 | kaen | some interesting results -- nearly all of the processing time is spent on a set of ~4 multiplications |
| 15:19:24 | raptor | wait wait... do we not have an S64?? |
| 15:19:28 | kaen | at least for _EC |
| 15:19:37 | kaen | we do have S64 |
| 15:20:03 | kaen | it's in the poly2tri triangulation adapter |
| 15:20:07 | raptor | oh yes, ok, we do |
| 15:21:39 | raptor | ok, it's algorithmically impossible to just convert double to signed long long in poly2tri :-/ |
| 15:21:45 | raptor | sadness |
| 15:22:51 | kaen | hmm |
| 15:23:50 | raptor | oh wait... actually |
| 15:24:01 | raptor | the algorithm doesn't use some of these methods... |
| 15:25:02 | raptor | maybe this is still doable.. |
| 15:26:07 | Watusimoto | so arc wants projects |
| 15:26:20 | raptor | give 'im ours! |
| 15:33:42 | raptor | or do you mean he wants tasks? |
| 15:34:08 | kaen | so, PP spends half of its time on this line: tmp = (p3.y-p1.y)*(p2.x-p1.x)-(p3.x-p1.x)*(p2.y-p1.y); |
| 15:34:22 | kaen | testing if p1, p2, p3 are a convex subset of vertices |
| 15:34:44 | kaen | and I think the multiplication is unnecessary. |
| 15:36:14 | kaen | I also tried making _MONO work but I run out of memory on CelticArena |
| 15:36:22 | raptor | oh yuk |
| 15:36:33 | raptor | I posted here: https://code.google.com/p/poly2tri/issues/detail?id=34#c60 |
| 15:38:36 | Watusimoto | I mean tasks |
| 15:38:54 | | Flynnn has joined |
| 15:39:12 | | Flynnn Quit (Client Quit) |
| 15:48:16 | raptor | I think I got poly2tri changed to signed long long |
| 15:48:40 | kaen | does it work!? |
| 15:48:47 | raptor | it does on celtic arena... |
| 15:48:57 | kaen | ohboyohboyohboy :) |
| 15:49:03 | raptor | I'm going to do Insignia... what can you give me to test? |
| 15:49:15 | kaen | celtic arena and insignia :P |
| 15:49:26 | kaen | /dlmap kaen_biosynthesis |
| 15:49:32 | kaen | that one is kind of crazy |
| 15:50:57 | raptor | ok |
| 15:51:09 | raptor | was it known to segfault on that one? |
| 15:51:14 | kaen | no |
| 15:51:38 | raptor | had to change another header... recompiling.. |
| 15:51:46 | kaen | another idea is to use my clip polygons plugin and cut holes out of polywalls |
| 15:51:52 | kaen | I got tons and tons of crashes like that |
| 15:52:04 | kaen | especially with xor |
| 15:54:59 | raptor | segfault!! |
| 15:55:03 | raptor | what the crazy |
| 15:55:16 | kaen | :| |
| 15:55:39 | raptor | similar to before?: http://pastie.org/pastes/8428043/text |
| 15:55:55 | kaen | that's the one |
| 15:57:06 | raptor | but i got like a 5% speed increase on Celtic Arena with the signed long long |
| 15:57:45 | kaen | interesting |
| 16:00:06 | raptor | in other news SDL 2.0.1 has released |
| 16:00:17 | raptor | now I feel like we're taking too long for our release! |
| 16:00:21 | kaen | hehe |
| 16:00:42 | kaen | though I have to agree :) |
| 16:02:02 | kaen | so, raptor, release mode reduced the triangulation timing to about 25% of debug mode for me using PP |
| 16:03:16 | raptor | but now triangulation is the slowest part of whole operation |
| 16:03:48 | raptor | and I'm sure people will invent levels that are worse than celtic arena |
| 16:03:59 | raptor | and also, people have older computers |
| 16:04:55 | kaen | true, but PP is the only library that has a compatible license, gives us usable triangulations, and doesn't segfault on pathological inputs (as far as we know) |
| 16:05:21 | kaen | and imo the "artsy" parts should really be lineitems, which don't get passed through the triangulator |
| 16:05:47 | kaen | and also, after I ran aggressive RDP simplification on your walls, I took it down to 75% without visual distortion |
| 16:06:11 | kaen | so there are lots of tools to help level designer make performant levels. |
| 16:06:30 | kaen | and I value having a safe algo over having a fast one, personally |
| 16:06:43 | raptor | yes... I want both :) |
| 16:06:58 | kaen | then maybe it's time to try CGAL ? |
| 16:07:07 | raptor | did that have dependencies? |
| 16:07:19 | kaen | GMP and some other stable float math lib |
| 16:07:48 | kaen | I think we're running out of triangulation libs :P |
| 16:07:58 | raptor | yeah... |
| 16:08:37 | raptor | I wonder what Watusimoto thinks? Maybe we should keep that PP patch as a fallback in case we can't solve it with poly2tri or other library... |
| 16:09:17 | raptor | that rdp reduction script is great! |
| 16:10:53 | kaen | I think it's my favorite of them all :) |
| 16:11:25 | Watusimoto | do you know what the problem with poly2tri is? like what about the input makes it crash? |
| 16:11:58 | raptor | start reading: https://code.google.com/p/poly2tri/issues/detail?id=34 |
| 16:12:00 | raptor | :) |
| 16:12:32 | kaen | wait a second ... |
| 16:12:34 | raptor | oh hey, the author already responded! |
| 16:12:53 | kaen | we have another, seemingly distinct segfault |
| 16:13:03 | raptor | wait, yes |
| 16:13:06 | raptor | wait wait wait |
| 16:13:09 | kaen | the one in that thread is stack overflow |
| 16:13:12 | raptor | one with the SO |
| 16:13:14 | raptor | yes |
| 16:13:16 | kaen | the one you posted is a null dereference |
| 16:13:17 | raptor | and that last one of mine? |
| 16:13:42 | kaen | which I've also experienced with unmodified poly2tri |
| 16:14:17 | kaen | so there are at least two known segfaults in p2t, along with at least one assert(0) I've been able to hit |
| 16:15:21 | | amgine123 has joined |
| 16:15:26 | amgine123 | hey anything new |
| 16:15:41 | amgine123 | btw adjsut the captvhas some of them are so fuzzy they are unreadable |
| 16:16:10 | raptor | kaen: do you have a reproducible test for the stack overflow one? |
| 16:16:23 | kaen | not on hand |
| 16:16:31 | amgine123 | what stack overflow? |
| 16:17:06 | kaen | just some crashes we've been chasing around, amgine123 |
| 16:17:16 | kaen | like the clip polygons ones you saw last night |
| 16:17:29 | amgine123 | uhoh how coiuld i miss the crashes m i getting lazy? |
| 16:17:46 | amgine123 | I think im getting laz....... |
| 16:17:47 | raptor | kaen: if you could somehow find a test case for the SO, then try it with this diff: http://sam6.25u.com/upload/poly2tri-integer.diff |
| 16:18:03 | raptor | because I can't seem to get it... |
| 16:18:05 | raptor | also |
| 16:18:08 | | Flynnn has joined |
| 16:18:20 | raptor | do you think I should open a new issue on that 2nd segfault? |
| 16:19:44 | kaen | I do, it's the same one you get without your patch |
| 16:20:03 | raptor | OK, I'll do that |
| 16:20:46 | amgine123 | uh is putting a object halfway in a object then using XOR on clip polygons crash a new one or old one |
| 16:20:56 | amgine123 | im forgetfull |
| 16:21:51 | kaen | that's the very same one we're working on |
| 16:21:58 | amgine123 | oh lol |
| 16:22:07 | kaen | all clip polygons crashes are known :P |
| 16:27:20 | amgine123 | what part of that code is the Xor part of the bullion |
| 16:28:07 | raptor | the sweep-line algorithm is pretty nifty |
| 16:29:06 | kaen | eh, it's kind of lame as far as triangulation algorithms go |
| 16:29:18 | kaen | PP's is much lamer though |
| 16:29:21 | raptor | but it's fast |
| 16:29:27 | kaen | BST is even faster :) |
| 16:29:46 | raptor | really? n log n |
| 16:29:56 | kaen | lower C |
| 16:29:58 | raptor | I mean, with holes |
| 16:31:40 | kaen | I think worst case for sweep line is n^2, but expected is nlog(n) |
| 16:32:07 | kaen | BST has worst case n log n |
| 16:32:17 | raptor | oh really.. |
| 16:32:17 | amgine123 | logarihims XD |
| 16:32:29 | | Flynnn Quit (Quit: This computer has gone to sleep) |
| 16:32:34 | raptor | man, i'm still disappointed a triangulation algo isn't in boost |
| 16:32:47 | amgine123 | why not? |
| 16:32:57 | kaen | afaict it's there in at least two places, just not exposed |
| 16:33:30 | kaen | you usually get a voronoi from a CDT, and then I think Boost Graph uses it for partitioning too |
| 16:37:10 | raptor | kaen: the auther responded: https://code.google.com/p/poly2tri/issues/detail?id=34#c61 |
| 16:37:33 | | Flynnn has joined |
| 16:42:25 | | Flynnn Quit (Client Quit) |
| 16:44:11 | | Flynnn has joined |
| 16:50:04 | raptor | kaen: do you know of a quick way to plot lots of points to see shape it makes, in an online web app? |
| 16:50:23 | kaen | I've looked and looked, haven't found any |
| 16:50:53 | kaen | I wrote a python script using matplotlib for it though |
| 16:51:09 | raptor | ooo, where is that? |
| 16:52:00 | kaen | http://pastie.org/8428151 |
| 16:52:29 | kaen | each poly goes on a separate line, the points are like 0 0 1 1 2 2 3 3 |
| 16:53:19 | raptor | ok, thanks |
| 16:53:23 | kaen | and the input comes on stdin |
| 16:53:56 | raptor | oh wow! it's 55MB to install matplotlib |
| 16:54:12 | kaen | yeah :/ |
| 17:00:29 | raptor | issue opened!: https://code.google.com/p/poly2tri/issues/detail?id=88 |
| 17:00:59 | raptor | also, that script is great! (thanks!) |
| 17:02:59 | kaen | my pleasure :) |
| 17:06:07 | Watusimoto | going to bed |
| 17:06:08 | Watusimoto | but |
| 17:06:13 | Watusimoto | in that case you just opened |
| 17:06:21 | raptor | what did i forget? |
| 17:06:24 | Watusimoto | are you sure you didn't have any colinear points |
| 17:06:27 | Watusimoto | i.e. flat triangles |
| 17:06:35 | Watusimoto | that was the issue in the other case, no? |
| 17:06:44 | raptor | this was a different issue |
| 17:06:53 | raptor | this is output from clipper - one polygon, one hole |
| 17:07:02 | Watusimoto | ok, so the points are known good |
| 17:07:10 | raptor | I... I hope so... |
| 17:07:14 | Watusimoto | ok |
| 17:07:15 | raptor | clipper hasn't let us down before |
| 17:07:19 | Watusimoto | no |
| 17:07:23 | Watusimoto | it's an old friend |
| 17:07:28 | Watusimoto | good night! |
| 17:07:42 | raptor | night! |
| 17:08:02 | kaen | night! |
| 17:12:07 | | Watusimoto Quit (Ping timeout: 272 seconds) |
| 17:32:54 | amgine123 | just call mer if you need me :) |
| 18:02:21 | amgine123 | let me know if your ready ok raptor :) |
| 18:03:28 | raptor | hi |
| 18:03:31 | raptor | ready for what? |
| 18:04:43 | amgine123 | for further testing Xd |
| 18:05:01 | amgine123 | hope you can swolve the clip polygon and the dre4aed DB issues |
| 18:05:01 | raptor | ah, probably nothing new for a while - we need to just fix bugs now |
| 18:05:18 | amgine123 | heard there was issues with the db =p |
| 18:06:31 | raptor | could be, not sure |
| 18:10:51 | amgine123 | btw will the DB caching issue ever be fixed |
| 18:15:45 | raptor | who knows |
| 18:16:11 | amgine123 | its a rather annoying bug me thinks |
| 18:19:31 | | Flynnn Quit (Quit: This computer has gone to sleep) |
| 19:00:50 | | kaen Quit (Ping timeout: 252 seconds) |
| 19:14:52 | amgine123 | lurk |
| 19:28:39 | | BFLogBot Commit: d783c46d977e | Author: buckyballreaction | Message: Fix dedicated build |
| 19:29:44 | amgine123 | ?? |