Timestamps are in GMT/BST.
| 02:31:45 | | Akien has joined |
| 02:52:23 | | Akien Quit (Remote host closed the connection) |
| 05:17:42 | | Darrel Quit (Ping timeout: 272 seconds) |
| 05:18:03 | | Darrel has joined |
| 05:42:40 | | LordDVG has joined |
| 05:46:37 | | Darrel Quit (Ping timeout: 260 seconds) |
| 05:47:59 | | Darrel has joined |
| 07:06:26 | Nothing_Much | o.o |
| 08:27:42 | | LordDVG Quit (Ping timeout: 272 seconds) |
| 08:59:20 | | LordDVG has joined |
| 09:38:36 | | YoshiSmb_m has joined |
| 09:39:16 | YoshiSmb_m | hi guys |
| 09:39:38 | YoshiSmb_m | kaen are you there? |
| 09:42:39 | Nothing_Much | Hey YoshiSmb_m |
| 09:42:47 | Nothing_Much | I think kaen's been super busy |
| 09:42:51 | Nothing_Much | He hasn't responded to me once on Skype :( |
| 09:43:01 | YoshiSmb_m | hey |
| 09:43:26 | YoshiSmb_m | wow |
| 09:43:29 | YoshiSmb_m | do you play nethack? |
| 09:44:04 | Nothing_Much | nope |
| 09:44:11 | Nothing_Much | I'm not that good at text only games :( |
| 09:44:20 | YoshiSmb_m | and you should nm, you should... |
| 09:45:15 | YoshiSmb_m | but you can use the Native Graphical Interface? |
| 09:45:44 | YoshiSmb_m | in SlashEN |
| 09:45:46 | YoshiSmb_m | *EM |
| 09:46:11 | YoshiSmb_m | i got 2 wish, after starting the game |
| 09:46:44 | YoshiSmb_m | it's like i got lucky |
| 09:49:48 | YoshiSmb_m | 16:22:44 Nothing_Much I didn't see |
| 09:50:12 | YoshiSmb_m | sorry if i dint put it well |
| 09:50:47 | YoshiSmb_m | i just copy it using my mobile (kinda hard) |
| 09:52:14 | Nothing_Much | oh man |
| 09:52:35 | Nothing_Much | well, idk, I need some form of graphics to help me distinguish what I'm looking at |
| 09:52:50 | YoshiSmb_m | yea |
| 09:54:31 | YoshiSmb_m | what you say early, was very funny btw |
| 09:59:48 | Nothing_Much | lol |
| 09:59:49 | Nothing_Much | >.> |
| 10:00:08 | Nothing_Much | I recall that 019b was still the only one there |
| 10:00:15 | Nothing_Much | But then BF got hacked |
| 10:00:27 | Nothing_Much | >.>:; |
| 10:00:40 | YoshiSmb_m | again... |
| 10:00:43 | YoshiSmb_m | ? |
| 10:01:16 | Nothing_Much | oh no |
| 10:01:32 | Nothing_Much | that was when I only saw 019b |
| 10:01:41 | Nothing_Much | after the hack, that's when I saw 019c |
| 10:01:42 | YoshiSmb_m | ah |
| 10:01:48 | Nothing_Much | so that's a good update |
| 10:03:43 | YoshiSmb_m | yep |
| 10:03:56 | YoshiSmb_m | www.srb2.org |
| 10:05:13 | Nothing_Much | wow, that looks pretty bad :( |
| 10:05:34 | YoshiSmb_m | what? |
| 10:08:06 | Nothing_Much | it looks not that good, honestly |
| 10:09:18 | YoshiSmb_m | well |
| 10:09:30 | YoshiSmb_m | at least you could try |
| 10:15:29 | Nothing_Much | I could |
| 10:15:32 | Nothing_Much | Lemme see if it's on Linux |
| 10:16:57 | Nothing_Much | No GNU/Linux support :( |
| 10:17:02 | YoshiSmb_m | check SRB2 Ports |
| 10:17:21 | YoshiSmb_m | on download section |
| 10:22:34 | YoshiSmb_m | but sorry if you couln't use it :-( |
| 10:35:31 | | YoshiSmb_m Quit (Remote host closed the connection) |
| 10:55:09 | | Akien has joined |
| 11:13:12 | | YoshiSmb_m has joined |
| 11:21:12 | | starseeker has joined |
| 11:21:36 | starseeker | hi! is this where the bitfighter devs are, or is this a user/gamer channel? |
| 11:32:09 | YoshiSmb_m | both |
| 11:32:30 | starseeker | cool. I came across bitfighter while reading up on poly2try and clipper |
| 11:32:39 | starseeker | sorry, poly2tri |
| 11:33:00 | starseeker | it looks like some folks with bitfighter have done some fairly extensive work to combine the two |
| 11:35:46 | starseeker | was curious to chat with the folks who had done that work, but don't want to annoy the gamers ;-) Is the technical discussion section in the forum where such conversations normally occur? |
| 11:39:10 | YoshiSmb_m | yes |
| 11:39:57 | YoshiSmb_m | take in mind, everyone is busy or not (doing homework r he's afk). |
| 11:40:03 | YoshiSmb_m | *or |
| 11:41:45 | YoshiSmb_m | i almost forgot, Welcome Starseeker |
| 11:46:16 | starseeker | sure :-) |
| 11:46:37 | starseeker | thank you |
| 11:47:02 | | starseeker came looking to discuss triangulation, but now may end up trying bitfighter tonight :-) |
| 11:49:43 | YoshiSmb_m | You're Welcome :-) |
| 12:24:43 | | raptor has joined |
| 12:24:43 | | ChanServ sets mode +o |
| 12:24:57 | raptor | good day! |
| 12:25:14 | YoshiSmb_m | hi raptor |
| 12:25:21 | raptor | hello |
| 12:25:37 | raptor | starseeker: I am one of the devs that worked with poly2tri quite a bit |
| 12:25:46 | raptor | if you have questions |
| 12:26:00 | raptor | also, welcome! |
| 12:48:59 | | YoshiSmb_m Quit (Remote host closed the connection) |
| 13:09:22 | Nothing_Much | hey, a new guy! |
| 13:09:24 | Nothing_Much | woo! |
| 13:09:28 | Nothing_Much | starseeker: welcome! |
| 13:09:43 | Nothing_Much | (I'm a gamer though, so don't pay attention to me :P) |
| 13:18:20 | | YoshiSmb_m has joined |
| 13:31:07 | starseeker | Nothing_Much: thanks :-) |
| 13:32:06 | starseeker | raptor: I read various comments on the poly2tri website and stackoverflow, and from the sound of things you guys have had pretty good luck with using clipper to "clean up" input before feeding it to poly2tri |
| 13:32:31 | raptor | yes |
| 13:32:34 | raptor | we love clipper |
| 13:32:49 | raptor | I think it's one of the best libraries I've ever worked with |
| 13:33:46 | starseeker | I am interested in trying something similar, but the projects I work with can't use GPL code (long story). As near as I can tell with a casual search, it looks like the bits in bitfighter that pipe data from bitfighter->clipper->poly2tri->bitfighter are part of the GPL codebase? |
| 13:34:19 | raptor | yes |
| 13:34:38 | raptor | we have several GeomUtils methods that call clipper |
| 13:34:51 | starseeker | I was wonder if a) those pieces are generic enough that they might be of wider interest to the computer graphics community as a whole, and b) whether the folks who did that work might consider licensing just those bits under a license like that of clipper or poly2tri |
| 13:35:07 | raptor | hmmm |
| 13:35:26 | starseeker | not proposing re-liecensing all of bitfighter, of course |
| 13:35:44 | raptor | well, i probably did most of the latest work in getting clipper to use poly2tri |
| 13:35:55 | starseeker | it's cool if the answer is no, but I figured it was better to inquire before going down the road of do-it-yourself |
| 13:36:10 | raptor | and the other devs that helped out are pretty cool with the code... especially since you asked nicely :) |
| 13:36:17 | raptor | so I would say take whatever you want |
| 13:36:33 | raptor | although some it is hightly specific to bitfighter functions, etc. |
| 13:36:41 | | starseeker nods |
| 13:37:22 | starseeker | what I was thinking was to identify the bits that might be generally applicatable (I'm guessing the floating point data -> clipper, clipper->poly2tri, and (maybe) poly2tri back out) |
| 13:37:40 | raptor | so for a) I think the methods could easily be made more generic, but probably still tied to c++ |
| 13:37:50 | | starseeker nods - C++ is cool |
| 13:38:23 | raptor | I'm not sure how much you've looked at the code, but the workflow is for generating 2D robot navigation zones |
| 13:38:36 | raptor | and it goes like this: |
| 13:39:58 | raptor | floating point data -> clipper -> more custom cleaning for really wacky use cases -> poly2tri -> Recast (customized for 2D) -> floating point data |
| 13:41:11 | | starseeker nods - that definitely sounds like the general problem most people are hoping to solve with poly2tri |
| 13:41:28 | starseeker | heh - is this you? http://www.gamedev.net/page/resources/_/technical/artificial-intelligence/generating-2d-navmeshes-r3393 |
| 13:43:17 | starseeker | ah, here's the stackoverflow link: https://code.google.com/p/bitfighter/source/browse/zap/GeomUtils.cpp?spec=svnb9286436e08332dd50d7302bb111a6cf6654ad1a&r=b9286436e08332dd50d7302bb111a6cf6654ad1a#1046 |
| 13:45:53 | raptor | taht first link is not me... but I admit that we probably did most of the pioneering work in getting these libraries to work together |
| 13:46:28 | | starseeker nods |
| 13:49:01 | starseeker | raptor: I guess what I should do is put together the pieces that are needed for a library under an API, and then post the result in the forums to make sure all the devs with a hand in it are OK with the results? |
| 13:50:33 | raptor | Actually, you can use whatever you want with permission |
| 13:50:51 | raptor | we use a custom container 'TNL::Vector' |
| 13:50:59 | raptor | which you'll have to change to std::vector |
| 13:51:22 | raptor | and a Point object |
| 13:52:01 | | starseeker nods |
| 13:52:21 | raptor | i mean use whatever you wish with our full permission :) |
| 13:53:03 | starseeker | raptor: cool - thank you! |
| 13:54:47 | starseeker | raptor: I just want to be sure (part politeness, part lawyer vaccination) to do my homework and make sure everyone's cool. Y'all have done some really cool work here |
| 13:55:17 | | starseeker was also favorably impressed with fontstash |
| 13:56:33 | | starseeker gets the sense that robust triangulation of polygons is a *very* common problem in the gaming world... |
| 13:56:58 | starseeker | raptor: do you guys convert poly2tri output into triangle strips, or is that not necessary for your application? |
| 14:01:42 | raptor | hi again, sorry I'm at work, and people keep coming into my office... |
| 14:02:05 | raptor | starseeker: what do you mean by 'triangle strips'? |
| 14:02:06 | starseeker | raptor: no problem - I'm used to IRC conversations :-) |
| 14:02:28 | starseeker | http://users.telenet.be/tfautre/softdev/tristripper/ |
| 14:02:50 | starseeker | raptor: if you'd rather I can return later tonight - don't mean to bother you at work |
| 14:03:28 | starseeker | triangle strips (as I understand the term) are used to more compactly represent triangles for display |
| 14:03:37 | raptor | ah i see |
| 14:03:39 | raptor | no |
| 14:03:49 | raptor | we use a custom version of RecastNavigation |
| 14:04:02 | raptor | it merges all the triangles into efficient convex polygons |
| 14:04:14 | | starseeker nods - that makes sense |
| 14:04:26 | raptor | because convex polygons are what's needed for good bot nav zones |
| 14:05:13 | starseeker | so you're actually using them for geometry interaction - right, strips wouldn't make sense for that (rather the contrary) |
| 14:05:53 | raptor | the output polygons are used for pathfinding |
| 14:07:56 | raptor | technically, the triangles themselves could be used for pathfinding since they're guaranteed to be convex |
| 14:08:17 | raptor | but that adds huge overhead for pathfinding with having so many zones |
| 14:08:26 | | starseeker nods |
| 14:08:40 | starseeker | hadn't heard of recastnavigation before - neat stuff |
| 14:10:56 | raptor | so triangle stripping would probably be good in rendering situations, but not at all for bot navigation |
| 14:11:42 | | starseeker nods - looks like the rendering is vector graphics based on the screenshots, so it was a silly question - my bad |
| 14:12:30 | raptor | no not a silly question at all |
| 14:12:54 | raptor | at first glance no one would know how we use these at all without extensive code searching :) |
| 14:13:48 | starseeker | how old is bitfighter? I don't remember it from my early Linux exploration days |
| 14:14:00 | raptor | hmmm... maybe 6 years or so? |
| 14:14:10 | Nothing_Much | starseeker: It used to be known as Zap! and ZAP |
| 14:14:20 | Nothing_Much | Bitfighter was made in 2010, right? |
| 14:14:21 | raptor | watusimoto is the head developer who started it - he'll be back in a couple days, i think |
| 14:14:32 | starseeker | ah, yeah - that would put it after my "exploring linux gaming" phase |
| 14:14:53 | Nothing_Much | Zap! was released in 2004 and was only on Windows and Mac, sadly :( |
| 14:15:09 | raptor | one year we'll get into debian... |
| 14:15:34 | starseeker | heh - getting into Debian is like climbing Mount Everest for software |
| 14:15:40 | Nothing_Much | raptor: I would've done it, but kaen said he'd do it because Debian has extremely high standards |
| 14:16:01 | Nothing_Much | and I probably wouldn't be the best.. person to get BF on Debian |
| 14:16:12 | raptor | we got so close the last time kaen put effort into it - i think the issue was a bug in a debian font package |
| 14:17:03 | starseeker | do they make you use debian packages for clipper/poly2tri/recastnavigation/fontstash/etc.? |
| 14:17:12 | raptor | oh yeah |
| 14:17:12 | Nothing_Much | https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=705303 |
| 14:17:15 | Nothing_Much | A response!! |
| 14:17:19 | Nothing_Much | Automated though |
| 14:17:24 | Nothing_Much | But a response nonetheless |
| 14:18:00 | raptor | ha! |
| 14:19:59 | starseeker | we had to add some extensive CMake logic to manage build with both system and bundled versions of libraries based on either user settings or system detection results |
| 14:20:20 | kaen | hi all |
| 14:20:24 | starseeker | someday I'm going to polish that up and try to get the CMake guys to stick it in the standard macro package... |
| 14:20:49 | kaen | erm, yes... the debian package |
| 14:20:58 | Nothing_Much | Hey kaen, how've you been? |
| 14:20:58 | raptor | kaen! welcome back! |
| 14:21:14 | kaen | I halfway ran out of steam and halfway got abducted by people giving me money to keep their websites functioning |
| 14:21:25 | raptor | haha |
| 14:21:27 | kaen | I've been very well :) |
| 14:21:35 | raptor | how is the money front going? |
| 14:21:38 | Nothing_Much | Awesome dude! |
| 14:21:50 | kaen | much better than it ever has :D |
| 14:21:57 | raptor | oh great! |
| 14:21:59 | kaen | I got hired on full-time by one of my contracting clients |
| 14:22:10 | kaen | I've got a salary and benefits now, like a big boy \o/ |
| 14:22:21 | Nothing_Much | you're so lucky kaen |
| 14:22:24 | raptor | and the money arrives on time and everything? |
| 14:22:29 | kaen | yes indeed |
| 14:22:44 | kaen | to both |
| 14:23:20 | kaen | I think the last roadblock for the debian package is the font package problem |
| 14:23:21 | raptor | excellent |
| 14:23:30 | raptor | I was thinking about the font problem - |
| 14:23:43 | raptor | i think we should just use the system font, ugly and all |
| 14:23:43 | Nothing_Much | Dude, there's an automated message regarding the lack of activity in that bug report |
| 14:23:49 | raptor | and that might get them to fix it faster |
| 14:23:55 | Nothing_Much | Does that mean you have to go through the process all over again? :( |
| 14:23:56 | kaen | I don't remember exactly, but iirc there should be a (functioning?) script to build a n official debian package |
| 14:24:05 | kaen | oh, no |
| 14:24:09 | kaen | I just have to resubmit it |
| 14:24:15 | raptor | we have a debian branch, i think |
| 14:24:30 | kaen | yeah, the original "intent to package" report was opened like two years ago |
| 14:24:32 | raptor | off of 019c |
| 14:24:37 | kaen | so I that autoresponse isn't surprising |
| 14:24:39 | kaen | ah, that's right |
| 14:24:45 | raptor | 019c might be around for a while... |
| 14:24:48 | kaen | erm, we're still on 019c right? |
| 14:24:49 | kaen | ok |
| 14:24:57 | Nothing_Much | Oh by the way, there's been a hack too |
| 14:24:57 | kaen | worried I had missed a release :P |
| 14:25:03 | Nothing_Much | sadly |
| 14:25:07 | kaen | I caught that :/ |
| 14:25:08 | raptor | 020 is broke and I cannot even begin to guess what all the problems might be... |
| 14:25:14 | kaen | oh no |
| 14:25:21 | raptor | i mean, it runs... |
| 14:25:26 | kaen | hmm |
| 14:25:32 | raptor | there's at least 2 major refactors going on right now |
| 14:25:37 | kaen | I guess the refactoring got more involved |
| 14:25:39 | kaen | ah, yep |
| 14:26:00 | raptor | one with game settings, one with Level parsing/loading |
| 14:26:08 | kaen | yuck |
| 14:26:20 | raptor | sam686 will show up every once in a while and fix our crashes we introduced... |
| 14:26:33 | kaen | heh |
| 14:27:12 | raptor | also, with windows 9 around the corner, and the possibility that 32bit support will be dropped, we'll probably have to do a win64 port |
| 14:27:28 | kaen | I see |
| 14:27:43 | kaen | should just be a matter of recompiling the dll's right? |
| 14:27:44 | raptor | which actually isn't so bad, except for the libraries |
| 14:27:48 | raptor | yes |
| 14:28:23 | raptor | oh, and all this is happening at a snail's pace - we've mostly been vacationing and taking it easy for the summer |
| 14:28:36 | kaen | good :) |
| 14:30:07 | kaen | I've been doing some ninja advertising |
| 14:30:10 | kaen | mostly on reddit |
| 14:30:14 | raptor | ninja? |
| 14:30:22 | kaen | taking out ads without telling you guys :P |
| 14:30:26 | raptor | ohhh, haha |
| 14:30:53 | kaen | I feel bad for leaving you hanging :/ |
| 14:30:55 | Nothing_Much | by taking out you mean putting on ads on facebook and stuff? |
| 14:30:57 | raptor | nah... |
| 14:30:59 | raptor | you didn't really |
| 14:31:06 | raptor | you gave us notice :) |
| 14:31:31 | raptor | and the summer happened anyways |
| 14:38:41 | kaen | interesting. I didn't realize we were breaking ground with poly2tri |
| 14:38:45 | raptor | oooo... freeorion is going to release soon |
| 14:39:16 | raptor | kaen: oh yeah, we totally pioneered with it |
| 14:39:28 | kaen | I have definitely noticed a lot of people interested in automatic bot navigation |
| 14:39:34 | kaen | I see it on reddit pretty frequently |
| 14:40:08 | raptor | i had several discussions with the head developer and got him to suggest clipper |
| 14:40:35 | kaen | really cool |
| 14:40:58 | raptor | the main issue is that poly2tri is free, super fast, but the algorithm itself doesn't allow for certain robustness |
| 14:41:15 | raptor | and there isn't really a fast alternative with such liberal licensing |
| 14:41:19 | kaen | yes |
| 14:42:32 | raptor | actually, starseeker may have a good idea - maybe I should just pull out our code and make a simple library with our code that combines clipper/polytri |
| 14:42:45 | raptor | post it on github in the public domain |
| 14:43:01 | starseeker | raptor: that would be even better - someone who knows what they are doing :-) |
| 14:43:24 | starseeker | if it gets enough momentum from lots of projects, everyone can benefit from robustness improvements |
| 14:43:37 | kaen | interesting |
| 14:43:51 | starseeker | kinda what's happened with clipper itself, actually |
| 14:44:47 | raptor | clipper is just amazing |
| 14:45:17 | raptor | every single time i thought clipper was doing something wrong... it turned out to be me instead |
| 14:47:49 | kaen | it also outperforms boot::polygon and boost::geom |
| 14:47:55 | kaen | which is still baffling to me |
| 14:48:21 | raptor | yeah, me too |
| 14:49:07 | kaen | I talked to some guys who use it for PCB layouts and trace routing |
| 14:49:17 | kaen | they said it's meant for really large N |
| 14:50:59 | raptor | boost:geom? |
| 14:51:09 | raptor | ::geom |
| 14:51:36 | | LordDVG Quit (Remote host closed the connection) |
| 14:52:13 | kaen | yes, where the more complicated polygon operations live |
| 14:52:23 | kaen | templatized beyond usability, of course |
| 14:52:50 | starseeker | not to mention requiring all of boost to be there... always fun on Windows machines |
| 14:53:19 | kaen | I think those two are header-only, although I don't remember anyway |
| 14:53:29 | kaen | we actually have header-only stuff in bf already |
| 14:53:47 | kaen | but, at any rate, clipper beats it from every angle |
| 14:54:06 | starseeker | even boost headers (in my experience) tend to require a lot of other headers... best use of a self contained boost subset I know of is the gecode constraint solving library's floating point support |
| 14:54:55 | | starseeker nods - if clipper hasn't won some kind of free software award, it's because someone isn't paying attention |
| 14:55:50 | kaen | starseeker: what's your project? |
| 14:55:55 | kaen | is it a game as well? |
| 14:56:03 | starseeker | kaen: nope, cad - BRL-CAD |
| 14:56:11 | kaen | awesome! |
| 14:56:16 | raptor | i don't know what that is... |
| 14:56:25 | | YoshiSmb_m Quit (Remote host closed the connection) |
| 14:56:26 | starseeker | computer aided design |
| 14:56:28 | kaen | I don't know what the BRL part is |
| 14:56:31 | starseeker | http://brlcad.org |
| 14:56:52 | kaen | oh cool! |
| 14:56:55 | kaen | we do gci too :) |
| 14:57:14 | starseeker | we're using poly2tri for NURBS surface shading right now (generating triangles from the parametric surfaces) but we don't have clipper hooked into the loop for clean-up |
| 14:57:51 | starseeker | looking into what was available in that department led me to raptor's work with clipper+poly2tri |
| 14:58:07 | kaen | very cool |
| 14:59:51 | starseeker | if raptor is willing to put together a small github public domain lib that encapsulated the clipper+poly2tri processing subsystem, it should (fingers crossed) slot in where we currently have poly2tri and avoid the nasty fun of crashing the app due to inputs poly2tri can't handle |
| 15:02:51 | raptor | we had to do many complex things like handle holes in a poly-tree structure |
| 15:03:16 | starseeker | and such a lib would also be a logical focal point for anyone wanting to improve poly2tri robustness as well - the poly2tri devs don't want to add too much complexity because they like the idea of having implementations in many languages: http://code.google.com/p/poly2tri/issues/detail?id=74 |
| 15:03:22 | raptor | so our code may be too complex for many cases... |
| 15:03:32 | raptor | well actually |
| 15:03:38 | raptor | about poly2tri robustness |
| 15:03:46 | raptor | i had some long discussion with one of the devs |
| 15:04:26 | raptor | and some of the robustness problems are due to the nature of the algorithm and cannot be changed without severely hampering the speed of the algorithm |
| 15:04:41 | starseeker | raptor: understood |
| 15:05:07 | raptor | yeah, it was actually startling to find out that the algorithm itself required certain things to be a certain way |
| 15:05:21 | raptor | because, believe me, we went through a lot of robustness problems with them... |
| 15:05:50 | starseeker | is that part of the intermediate clean-up step between clipper and poly2tri? |
| 15:05:54 | raptor | I think kaen's and mine stubborness was really got us to where we are today |
| 15:05:59 | kaen | heh |
| 15:06:09 | raptor | starseeker: yes |
| 15:06:33 | kaen | and I guess they don't want to maintain a cdt->TriangulateSafely() method, since that would be 2*(numberoflanguages) implementations to maintain |
| 15:06:56 | raptor | we have some crazy cases in our game and I had to add some point-tweaking to get them to work |
| 15:07:29 | starseeker | raptor: I suspect some of the NURBS surfaces out there are likely to generate crazy stuff too - real world data can do that |
| 15:07:43 | starseeker | are your tweaks specific to your individual data sets? |
| 15:08:45 | | Nothing_Much Quit (Quit: Konversation terminated!) |
| 15:09:05 | | Nothing_Much has joined |
| 15:09:17 | raptor | not really, but specific to polygons for botzones |
| 15:09:31 | starseeker | hmm |
| 15:10:14 | | starseeker wonders if it might prove to be the case that botzone restrictions and NURBS trimming loop restrictions have some similarities |
| 15:11:31 | raptor | not sure what NURBS is |
| 15:11:44 | starseeker | Non-Uniform Rational B-Splines |
| 15:11:49 | starseeker | one sec... |
| 15:12:11 | starseeker | http://en.wikipedia.org/wiki/Non-uniform_rational_B-spline |
| 15:13:04 | kaen | so I guess you rasterize the splines (with a grid)? and send the polys to p2t? |
| 15:13:21 | raptor | i' not sure our stuff can do 3d... |
| 15:13:37 | starseeker | raptor: the parametric domain (where the trimming happens) is 2D |
| 15:14:41 | starseeker | trimming loops are defined in the 2D space to denote "void" areas. When a point in 2D is evaluated to get the final 3D point, we check to see if the 2D point is inside a trimming loop |
| 15:15:09 | starseeker | so for poly2tri, we take the loops (which are usually parametric curves) and generate polylines from them |
| 15:15:29 | kaen | oh, ok |
| 15:15:36 | raptor | this is some computational geometry I haven't dealt with before |
| 15:15:45 | raptor | but if it's in 2d, then great! |
| 15:15:50 | kaen | and you end up with arbitrary 2D polylines? |
| 15:15:56 | raptor | we know 2d over here at #bitfighter :) |
| 15:16:00 | starseeker | :-) |
| 15:16:13 | kaen | that's pretty much exaclyt what we have to deal with as well |
| 15:16:19 | | starseeker nods |
| 15:16:43 | starseeker | when I saw the description of bitfighter's problem domain, it sounded almost exactly like the kind of data we deal with in 2D |
| 15:18:08 | starseeker | we already use bare poly2tri and get fairly nice shaded displays, but we experience the same weaknesses as well with the poly2tri algorithm's limitations |
| 15:18:59 | starseeker | and those fun asserts in the error case code mean if we *do* hit a bad case, the application goes down with a thud |
| 15:19:33 | | starseeker is trying to teach poly2tri to return an error code or NULL rather than fail, but that touches a lot of the code |
| 15:19:52 | kaen | there are comments around those that use exceptions instead of asserts |
| 15:19:57 | kaen | so you could catch them |
| 15:19:58 | kaen | iirc |
| 15:20:06 | raptor | yeah... my advice is to not touch poly2tri |
| 15:20:17 | kaen | also I think assert.h has a define you can use to make it raise instead of abort |
| 15:20:20 | raptor | just guarantee good input |
| 15:20:34 | kaen | ^ we had much better luck with this |
| 15:20:46 | raptor | we played with poly2tri a little once, got it to not crash... then proceeded to get weird output |
| 15:21:21 | | starseeker nods - I can live with weird output instead of not crashing, but I suppose properly handling the asserts would be better - then we could fall back on a wireframe view |
| 15:21:29 | kaen | ah, that's right |
| 15:21:35 | raptor | i have to go for a few hours... back later! |
| 15:21:42 | starseeker | raptor: cool - thanks! |
| 15:21:46 | | raptor Quit () |
| 15:22:00 | kaen | I've done a lot of work on the triangulation as well |
| 15:22:08 | kaen | if you have anymore questions, fire away |
| 15:22:16 | starseeker | kaen: so you see my interest in the possibility of a shared library that encapulates what you have achieved :-) |
| 15:22:39 | kaen | yes indeed |
| 15:23:03 | starseeker | kaen: I'm hoping that I can do exactly that - use pre-processers to guarantee good input (as poly2tri defines good) and avoid ever getting to the abort cases in the first place |
| 15:23:06 | starseeker | much better all around |
| 15:23:18 | kaen | I guess the only hesitation is that we've only addressed the problems in our specific domain, and have also made assumptions that are probably only valid for us |
| 15:23:39 | kaen | not to mention that our transformations are tied to our own data types (our point class, for example) |
| 15:23:50 | starseeker | kaen: so far, your domain sounds pretty similar |
| 15:23:59 | starseeker | is your point class very complex? |
| 15:24:18 | kaen | no, very simple in fact |
| 15:24:35 | kaen | but maybe a little weird when it comes to method names |
| 15:25:21 | starseeker | kaen: I think that's probably a surmountable problem then - after all, clipper and poly2tri also have their own point classes |
| 15:25:57 | starseeker | couldn't you just define a separate point class (if need be) that provides the methods needed? |
| 15:26:07 | kaen | true |
| 15:26:26 | kaen | probably better would be to put them into either p2t or clipper classes, and do our custom cleanups in those datatypes |
| 15:26:40 | | starseeker nods |
| 15:26:43 | kaen | p2t is probably the better choice, clipper datatypes are a bit... strange |
| 15:26:51 | starseeker | heh - agreed |
| 15:27:17 | starseeker | what assumptions do you see as being problematic? |
| 15:28:10 | kaen | hmm I'll have to take a look to refresh my memory. I worry more about the implicit assumptions we didn't realize we were making |
| 15:28:25 | kaen | we didn't do any sort of formal analysis, of course :D |
| 15:28:41 | kaen | just lots of punk rock and coffee, for me |
| 15:28:46 | kaen | and a few sundays |
| 15:28:47 | starseeker | <snort> I doubt any such code has that behind it, unless that explains how clipper is so bulletproof... |
| 15:29:01 | starseeker | hey - it's the reciepe that created Linux :-) |
| 15:29:02 | kaen | haha |
| 15:29:43 | starseeker | kaen: can you think of any such assupmtions you have made that a) you want to keep making rather than address and b) aren't safe assumptions for similar use cases? |
| 15:30:39 | | starseeker got the impression based on what he saw in the various discussions and bug reports that your inputs are actually quite general within this category of geometric problem |
| 15:30:53 | | Nothing_Much Quit (Quit: Konversation terminated!) |
| 15:31:10 | | Nothing_Much has joined |
| 15:32:29 | kaen | looking over it right now. I'm at work too, it will be a few minutes |
| 15:32:30 | kaen | sorry |
| 15:32:41 | starseeker | kaen: no problem |
| 15:34:29 | starseeker | kaen: I should stress that I don't want to push y'all towards doing something you aren't interested in doing |
| 15:42:18 | kaen | wow, funny how c++ looks like chicken scratch after six months of writing ruby |
| 15:42:32 | kaen | anyway, I guess we aren't really making any explicit assumptions |
| 15:42:42 | kaen | other than the inputs not crashing clipper, which is pretty safe |
| 15:43:04 | starseeker | heh |
| 15:43:34 | kaen | other than that it's just simple data transforms between bf, clipper, and p2t with some scaling mixed in |
| 15:43:52 | starseeker | plus the input validity between clipper and p2t? |
| 15:44:01 | starseeker | s/input validity/input checking |
| 15:44:07 | kaen | right |
| 15:45:09 | starseeker | so in principle then, a bf->p2t container translation, and a p2t->clipper translation, would allow all the point logic to live in p2t space? |
| 15:45:32 | starseeker | (presumably a p2t->bt conversion already exists...) |
| 15:52:06 | kaen | hmm |
| 15:52:25 | kaen | I think we could templatize it to operate on anything with an x() and y() method |
| 15:52:45 | kaen | oh, and size() and [] for the polygons |
| 15:52:46 | starseeker | ah. that would be very general |
| 15:53:07 | kaen | or maybe just use an iterator since we're using stl vectors now |
| 15:53:25 | kaen | that would save the user at least two manual data transformations |
| 15:53:32 | starseeker | speed++ |
| 15:54:11 | kaen | I think speed-- but usability++ |
| 15:54:21 | kaen | so, it actually seems pretty straightforward |
| 15:54:37 | starseeker | hmm - wouldn't avoiding data trasformations be a good thing for speed? |
| 15:55:00 | kaen | it would still be doing the transforms, just that it would save the user from coding it themself |
| 15:55:11 | starseeker | oh, gotcha |
| 15:55:21 | kaen | since it would be datatype-agnostic as long as those methods exist on the source/target |
| 15:55:37 | starseeker | yeah, if they're going to have to the conversions anyway, then it's a definite usability win |
| 15:55:54 | kaen | hmm, I need to turn this over in my head a bit |
| 15:56:11 | kaen | but I was wrong about the assumptions at least, so I think it makes sense to break this out a bit |
| 15:56:26 | kaen | if it saves even one coder from data transform hell, it's worth it |
| 15:56:31 | starseeker | :-) |
| 15:56:40 | starseeker | my least favorite part of mesh/triangle programming |
| 15:57:26 | starseeker | no, scratch that - second least favorite |
| 15:57:27 | | Nothing_Much Quit (Quit: Konversation terminated!) |
| 15:57:57 | starseeker | least favorite is trying to see which of the 10,000 possible issues is at play when the OpenGL window isn't showing what I told it to show. |
| 15:58:05 | kaen | oh god |
| 15:58:08 | kaen | I know that pain |
| 15:58:18 | starseeker | but data transformation is definitely up there |
| 15:58:58 | starseeker | "so, what was your accomplishment today?" uh... discovering 142 ways to create a blank OpenGL view? |
| 15:59:05 | kaen | hahaha |
| 16:00:05 | starseeker | kaen: gotta run myself, be back later this evening most likely. Thank you (and raptor) for taking the time to consider this |
| 16:00:16 | kaen | no problem, see you around |
| 16:00:19 | kaen | thanks for dropping by :) |
| 16:04:55 | | Nothing_Much has joined |
| 16:31:23 | | Nothing_Much Quit (Quit: Konversation terminated!) |
| 16:31:43 | | Nothing_Much has joined |
| 17:30:27 | Nothing_Much | Can somebody test out my server? :) |
| 17:30:35 | Nothing_Much | Should be the 24/7 BM and CTF Server |
| 17:37:10 | Nothing_Much | Hey |
| 17:37:17 | Nothing_Much | I have a Bitfighter .deb |
| 17:37:19 | Nothing_Much | Anybody need it? |
| 17:45:37 | Nothing_Much | Everybody's gone now! D: |
| 18:24:04 | | kaen Quit (Read error: Connection reset by peer) |
| 19:15:27 | | Akien Quit (Remote host closed the connection) |
| 19:25:45 | | Nothing_Much Quit (Ping timeout: 240 seconds) |
| 19:29:37 | | Nothing_Much has joined |
| 21:49:34 | | raptor has joined |
| 21:49:34 | | ChanServ sets mode +o |
| 21:49:42 | raptor | good evening |
| 21:52:10 | | YoshiSmb_m has joined |
| 21:53:07 | YoshiSmb_m | hi guys |
| 22:03:58 | Nothing_Much | evenin' |
| 22:04:04 | Nothing_Much | got my server up 'n runnin'! |
| 22:11:25 | YoshiSmb_m | and, nickserv just fucked up my registered nick |
| 22:33:18 | | starseeker yawns |
| 22:33:59 | starseeker | busy day |
| 22:34:18 | YoshiSmb_m | yea |
| 22:35:02 | YoshiSmb_m | same here, i just got to my new house |
| 22:35:44 | YoshiSmb_m | (and took me like 7 - 8 hours to get everything here) |
| 22:36:04 | starseeker | hmm - "A great event hosted by sky_lark" - is it coincidence or does an E.E. Doc Smith fan lurk among the bitfighters? |
| 22:36:29 | starseeker | YoshiSmb_m: my sympathies - I've had to move several times, and none of them were fun |
| 22:36:49 | starseeker | Nothing_Much: I see your server |
| 22:36:59 | YoshiSmb_m | same here |
| 22:37:05 | YoshiSmb_m | im tired |
| 22:37:21 | YoshiSmb_m | but i will not stop! :-D |
| 22:40:16 | raptor | I'm working on posting the clipper -> poly2tri code |
| 22:41:09 | starseeker | raptor: cool! kaen took a look at what was involved after you left earlier |
| 22:42:51 | starseeker | ah, I see your irc logs are pretty much immediately updated - nevermind :-) |
| 22:43:27 | starseeker | (that's nifty, btw - used to seeing logs appear only the next day for some reason on other projects) |
| 22:44:51 | raptor | yeah... i spent a lot of time on that :) but I stole much of the ideas/code from the naev project |
| 23:55:40 | | YoshiSmb_m Quit (Remote host closed the connection) |