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 |