| 01:33.45 | *** join/#brlcad packrat (~packrator@99-67-225-40.lightspeed.livnmi.sbcglobal.net) |
| 02:21.20 | starseeker | hah, cool: http://ascendwiki.cheme.cmu.edu/ASCEND_overview |
| 02:24.29 | *** join/#brlcad PrezKennedy (MK@whitecalf.net) |
| 02:28.20 | starseeker | huh: http://www.google-melange.com/gsoc/org/google/gsoc2011/cse_tuwien |
| 02:29.18 | *** join/#brlcad crazy_imp (~mj@a89-182-53-208.net-htp.de) |
| 03:03.08 | starseeker | ooo - http://www.google-melange.com/gsoc/project/google/gsoc2011/carlosmn/13001 |
| 05:53.33 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) |
| 07:09.57 | *** join/#brlcad primary (debian-tor@gateway/tor-sasl/primary) |
| 07:10.05 | primary | Hot damn. |
| 07:24.54 | *** join/#brlcad kanzure_ (~goonie@neuroblastoma.cs.pdx.edu) |
| 07:25.31 | primary | Can anyone here recommend a high resolution TEMPEST resistant display monitor for use with BRL-CAD? |
| 07:37.18 | primary | what is he planning on doing |
| 08:19.11 | *** join/#brlcad mafm_ (~mafm@18.Red-88-23-77.staticIP.rima-tde.net) |
| 10:40.27 | *** join/#brlcad Stattrav (~Stattrav@111.93.134.142) |
| 10:40.27 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) |
| 11:08.08 | *** join/#brlcad archivist_emc (~archivist@host81-149-189-98.in-addr.btopenworld.com) |
| 11:25.47 | CIA-105 | BRL-CAD: 03davidloman * r44517 10/geomcore/trunk/tests/unit/utility/ByteBufferUTest.cxx: Make ByteBuffer unit test check for proper Limit settings. |
| 11:27.29 | CIA-105 | BRL-CAD: 03davidloman * r44518 10/geomcore/trunk/src/utility/ByteBuffer.cxx: Fix limit setting bugs |
| 12:00.14 | *** join/#brlcad Stattrav (~Stattrav@122.172.42.236) |
| 12:00.14 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) |
| 12:57.44 | CIA-105 | BRL-CAD: 03davidloman * r44519 10/geomcore/trunk/tests/unit/libnet/ (GeometryReqMsgUTest.cxx TypeOnlyMsgUTest.cxx): Collect common header tests into common function, only on a per class basis. |
| 13:29.45 | dloman_ | ``Erik: you around today? |
| 13:36.06 | ``Erik | ayup |
| 13:39.28 | CIA-105 | BRL-CAD: 03davidloman * r44520 10/geomcore/trunk/ (2 files in 2 dirs): Implement Unit test for GeometryManifestMsg. Fixed some bugs, should be working much smoother now. |
| 13:39.39 | *** join/#brlcad kanzure (~kanzure@131.252.130.248) |
| 13:56.08 | CIA-105 | BRL-CAD: 03davidloman * r44521 10/geomcore/trunk/tests/unit/libnet/GeometryManifestMsgUTest.cxx: Remove some accidental copy/paste vomit. |
| 14:51.27 | CIA-105 | BRL-CAD: 03r_weiss * r44522 10/brlcad/trunk/src/librt/primitives/nmg/nmg_manif.c: |
| 14:51.27 | CIA-105 | BRL-CAD: Updated functions 'paint_face' and 'nmg_shell_manifolds' within file |
| 14:51.28 | CIA-105 | BRL-CAD: 'nmg_manif.c'. There was a datatype mismatch in the function parameters and some |
| 14:52.18 | CIA-105 | BRL-CAD: 03davidloman * r44523 10/geomcore/trunk/ (2 files in 2 dirs): Fix up some inheritance problems by making GeometryChunk a direct subclass of NetMsg rather than GenericMultiByteMsg. |
| 14:55.54 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) |
| 15:01.41 | ``Erik | nice http://gaming.operationreality.org/2011/04/26/crytek-for-free-cryengine-3-sdk-and-editor/ |
| 15:03.03 | dloman_ | wow, complete code access.... that's unusual! They're lawyers must be on standby :) |
| 15:03.42 | CIA-105 | BRL-CAD: 03r_weiss * r44524 10/brlcad/trunk/src/librt/primitives/nmg/nmg_bool.c: |
| 15:03.43 | CIA-105 | BRL-CAD: Updated function 'nmg_bool' within file 'nmg_bool.c'. Moved this change from the |
| 15:03.43 | CIA-105 | BRL-CAD: triangulation prototype code to the main code. This change corrects a corruption |
| 15:03.44 | CIA-105 | BRL-CAD: problem with the class list array. This will improve the sucess of boolean |
| 15:03.44 | CIA-105 | BRL-CAD: operations on facetized cgs geometry. |
| 15:07.21 | *** join/#brlcad Stattrav (~Stattrav@117.192.157.232) |
| 15:07.21 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) |
| 15:12.52 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) |
| 15:19.33 | dloman_ | Just when I thought patriotism was dead: http://www.ihatethemedia.com/a-simple-way-to-stop-westboro-baptist-church-funeral-protesters |
| 15:19.38 | dloman_ | love it. |
| 16:24.57 | *** join/#brlcad mafm (~mafm@18.Red-88-23-77.staticIP.rima-tde.net) |
| 16:33.14 | *** join/#brlcad dli (~dli@67.55.46.44) |
| 16:46.20 | CIA-105 | BRL-CAD: 03r_weiss * r44525 10/brlcad/trunk/src/librt/primitives/nmg/nmg_class.c: Updated functions 'nmg_class_pt_e', 'nmg_2lu_identical', 'class_shared_lu' and 'nmg_classify_lu_lu' within file 'nmg_class.c'. Changes were made to compare against SMALL_FASTF instead of '0.0'. |
| 16:46.37 | dloman_ | woooo, go Rich go! |
| 16:48.41 | *** join/#brlcad Stattrav (~Stattrav@117.192.131.229) |
| 16:48.41 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) |
| 16:57.33 | dloman_ | kicks sf.net |
| 16:57.39 | dloman_ | come on... FASTER! |
| 17:00.13 | CIA-105 | BRL-CAD: 03davidloman * r44526 10/geomcore/trunk/src/libNet/NetMsgFactory.cxx: Two bug fixes. NetMsg parse was failing due to a >= being used instead of a <. Also make peeking at the MsgType remember start position instead of assuming a rewind to position:0 |
| 17:06.52 | *** join/#brlcad Stattrav (~Stattrav@117.192.131.229) |
| 17:06.52 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) |
| 17:08.05 | *** join/#brlcad Stattrav (~Stattrav@117.192.131.229) |
| 17:08.06 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) |
| 17:09.16 | *** join/#brlcad Stattrav (~Stattrav@117.192.131.229) |
| 17:09.30 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) |
| 17:38.47 | CIA-105 | BRL-CAD: 03r_weiss * r44527 10/brlcad/trunk/src/librt/primitives/nmg/nmg_tri.c: (log message trimmed) |
| 17:38.47 | CIA-105 | BRL-CAD: Updated the prototype version of function 'nmg_triangulate_fu' doing some |
| 17:39.12 | CIA-105 | BRL-CAD: cleanup and re-factoring. The re-factoring created function 'nmg_isect_lseg3_eu' |
| 17:39.12 | CIA-105 | BRL-CAD: to test if a line segment intersects with any edgeuse within a faceuse. Updated |
| 17:39.12 | CIA-105 | BRL-CAD: the function 'nmg_triangulate_rm_degen_loopuse' adding code to verify each |
| 18:12.14 | *** join/#brlcad Stattrav (~Stattrav@117.192.131.229) |
| 18:12.14 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) |
| 18:28.23 | dloman_ | okay, this is wierd. |
| 18:29.11 | dloman_ | using pkg, i have confirmed sending 350k on one end, but pkg is reporting recv-ing 25k on the other end. |
| 18:29.32 | dloman_ | digs into pkg. |
| 18:45.01 | *** join/#brlcad Stattrav (~Stattrav@117.192.131.229) |
| 18:45.01 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) |
| 18:52.24 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) |
| 19:26.41 | kanzure | <PROTECTED> |
| 19:27.01 | kanzure | http://heybryan.org/shots/2011-04-27-1357-boolean-nurbs.png |
| 19:27.02 | kanzure | http://diyhpl.us/~bryan/irc/esolid_output.txt |
| 19:27.18 | kanzure | progress! now i have a "known good" and i can slowly start to chip away at it |
| 19:41.08 | ``Erik | neat |
| 19:41.37 | ``Erik | esolid is a python thang? does that mean porting it to C, as well? |
| 19:42.34 | ``Erik | do the surfaces that touch eachother share trimming curves? are the black speckles at the seams from tesselating for ogl? |
| 19:53.54 | kanzure | esolid is written in C++ and doesn't have a LICENSE file (i should ask the guy if he could public domain it, though) |
| 19:54.02 | kanzure | i've been writing my own version in python that is "similar" to esolid |
| 19:54.57 | kanzure | surfaces that touch each other do share trimming curves |
| 19:55.11 | kanzure | also, that screenshot sucks- a union doesn't demonstrate what's going on |
| 19:55.13 | kanzure | http://heybryan.org/shots/2011-04-27-1440-boolean-nurbs-difference.png |
| 19:55.36 | kanzure | the visualizer is some wacky shit, i don't think it's using the opengl nurbs routines and is just doing its own tessellation so it probably sucks a lot |
| 19:57.42 | ``Erik | okie, impressive |
| 20:01.34 | kanzure | i also have made a swig wrapper for the C++ version to interface with python |
| 20:01.54 | kanzure | in particular so that i can slowly replace the C++ versions with my own versions, which so far i've been trying to simplify.. |
| 20:02.02 | kanzure | the C++ code base for esolid has a lot of redundancies, it's ridiculous |
| 20:02.17 | kanzure | here's an if-then block for instance.. http://diyhpl.us/~bryan/irc/refactored0.txt |
| 20:02.21 | kanzure | bottom of the file is my refactored version |
| 20:04.51 | ``Erik | too bad esolid is 'school' related, otherwise it may be worth submitting some of it to http://thedailywtf.com/ |
| 20:05.16 | kanzure | by comparison boole-1.1 is significantly worse than esolid |
| 20:05.32 | kanzure | but it makes me wonder.. did some poor human actually write this code? |
| 20:05.42 | ``Erik | of course |
| 20:05.48 | kanzure | there's maybe 10 to 20,000 LOC here... what did they do? |
| 20:05.54 | kanzure | just write it all at once and pray it works the first time? |
| 20:05.56 | kanzure | there's no unit tests |
| 20:06.02 | ``Erik | probably a couple undergrads did it |
| 20:06.51 | kanzure | code quality is fairly consistent i think it was just john keyser entirely |
| 20:07.17 | kanzure | makes sense; he's over at TAMU now running their scholastic comp sci / programming competitive action force team |
| 20:07.48 | *** join/#brlcad IriX64 (~kvirc@bas2-sudbury98-1177680420.dsl.bell.ca) |
| 20:08.10 | kanzure | next thing on my todo list is figuring out how to check my python versions against the swigged versions |
| 20:08.28 | kanzure | since swig won't accept my ArbitraryPatch against its _SWIGGED_K_PATCH object |
| 21:44.30 | kanzure | how do i make up unit tests when i don't know what the values should be? |
| 22:22.19 | ``Erik | hm, thennnnn ya don't understand the math you're trying to implement and should learn it? |
| 22:24.18 | primary | RUDE |
| 22:45.58 | kanzure | ``Erik: No, rather "nobody has ever tested any of this, so it could all be wrong anyway." |
| 22:49.39 | kanzure | and, even if you do understand the math, your code can still be wrong |
| 23:20.01 | ``Erik | 'this' being the esolid implementation? |
| 23:29.43 | ``Erik | kinda odd that the ogre guys would do "things and stuff" to their code to require xcode to build on a mac, instead of allowing a unix style build. :/ |
| 23:33.26 | ``Erik | for unit testing, is there a paper related that could help? deductive reasoning on the code comments/name/impl? I've seen "unit tests" created by simply feeding in inputs, recording the outputs, and calling those the "correct" values, not quite right... :) |
| 23:49.06 | primary | because mac |
| 23:49.07 | primary | Sorry, wrong channel. |
| 23:49.07 | primary | keyword highlighting |
