| 00:01.05 | Maloeran | Does the OSX bug occur on ia32 using the x87 instruction set? FPU stack conversions to and from 80 bits will cause differences |
| 00:10.05 | IriX64 | may i ask a question re shared libs thing? |
| 00:10.19 | brlcad | that is very much related to the issue, but is exactly the sort of problems that I was referring to that are predominantly accounted for now |
| 00:10.39 | IriX64 | the autoconf thing then? |
| 00:11.07 | brlcad | ~ask |
| 00:11.14 | ibot | hmm... ask is Questions in the channel should be specific, informative, complete, concise, and on-topic. Don't ask if you can ask a question first. Don't ask if a person is there, just ask what you intended to ask them. Better questions more frequently yield better answers. We are all here voluntarily. See also http://catb.org/~esr/faqs/smart-questions.html |
| 00:11.14 | brlcad | :) |
| 00:11.22 | brlcad | bah |
| 00:12.01 | *** join/#brlcad IriX64 (n=IriX64@bas3-sudbury98-1168056909.dsl.bell.ca) |
| 00:12.09 | IriX64 | power bump grrr.... :) |
| 00:12.24 | IriX64 | http://www.pastebin.ca/354478 |
| 00:12.40 | IriX64 | look at the last few lines. |
| 00:12.55 | IriX64 | libpng.so.1 does not exist here. |
| 00:13.02 | brlcad | Maloeran: the point is that in pretty much all of the cases, the differences and misses can be accounted for -- and librt works extensively to make sure that results are repeatable as it can't be emphasized as to the importance that has with simulation studies |
| 00:14.13 | brlcad | so missing just one pixel in a large render on an edge case .. is actually considered a significant BUG that has to be addressed .. not just a compiler behavior to be accepted -- they can (and should) be accounted for, or at least thoroughly understood as to what the *exact* cause is |
| 00:15.01 | brlcad | to date (and that date being 20+ years), there's not been a case of hardware/compiler goo that could not be accounted for by some means |
| 00:16.18 | brlcad | IriX64: at a glance, looks like a libtool bug .. but there's not much information to go with |
| 00:16.28 | brlcad | all the error indicates is that ld failed for some unknown reason |
| 00:17.18 | brlcad | would have to turn up gcc's verbosity and compile by hand to see what happened |
| 00:17.55 | brlcad | alternatively, you could install png via usual cygwin means, and let configure auto-detect it so it doesn't try to build the bundled libpng |
| 00:18.27 | Maloeran | brlcad, if we suppose a ray is hitting right on the edge of a triangle, any little difference caused by the compiler may swap the result ; if it hits or it doesn't |
| 00:18.58 | Maloeran | And you know that already... I guess it must just be explained, but the compiler will cause that kind of "artefacts" |
| 00:19.37 | Twingy | artifacts |
| 00:24.52 | IriX64 | brlcad: ty |
| 01:38.35 | brlcad | Maloeran: of course that can happen -- the issue is more knowing exactly when it happens and being sure that is what is really happening when a difference is encountered |
| 01:39.36 | brlcad | over the years, it's often been the case that there was either a bug in the hardware, or a bug in system routines (e.g. sqrt) that would have gone unnoticed had it all been assumed to be just compiler reordering |
| 01:40.34 | brlcad | even with reordering, a lot of differences can sometimes/often be accounted for -- checking for things consistently with tolerance for example, so if you're an edge case, you actually compare with tolerance considerations so it doesn't matter how it's ordered |
| 01:42.36 | brlcad | requires a lot more care and thought on the implementation, something that is rarely (never?) a concern for optical tracing, but is considerably important for simulation purposes that need to be repeatable studies or at least fully understood behavior (so it can be expected and classes of results can be observed) |
| 01:43.55 | brlcad | the CS aspects cannot overwhelm and are not more important than the engineering and scientific purposes that the codes are written for |
| 01:44.31 | dtidrow | likely less important, in fact |
| 01:45.02 | brlcad | usually extremely |
| 01:45.14 | brlcad | which is why a lot of the code is shit unfortunately too |
| 01:45.15 | dtidrow | yep |
| 01:46.15 | brlcad | though sometimes it's not too, I think you'll just find all sorts just like people ;) |
| 01:46.20 | Maloeran | Even with tolerance, it can almost be considered random exactly on the edge of the tolerance |
| 01:47.03 | Maloeran | I think the point is that the tolerance shouldn't matter. If the ray of a pixel goes directly on the edge of a triangle, it doesn't matter if the triangle is hit or not |
| 01:49.44 | CIA-5 | libIRC: 03jeffm2501 * 10libirc/ (include/TCPConnection.h src/TCPConnection.cpp): kill a connection if the listeners don't want it. |
| 01:53.04 | brlcad | that was just one example |
| 01:54.35 | brlcad | some issues can be accounted for by considering tolerance, some have nothing to do with tolerance |
| 01:55.18 | brlcad | for something like the edge case of a triangle, you could -- again, for example -- test if it's on the edge and consistently report a hit or miss |
| 01:55.45 | brlcad | whatever impact that causes on performance is secondary if it results in numerical stability |
| 01:55.46 | CIA-5 | libIRC: 03jeffm2501 * 10libirc/ (include/TCPConnection.h src/TCPConnection.cpp): give the hostmask and ip back seperately. |
| 01:56.21 | Maloeran | That triangle edge test could be subject to a bit of rounding too, but I get the idea |
| 01:57.02 | Maloeran | My raytracer sure causes a whole lot of off-by-many ; same hardware, same scene, even same compiled executable |
| 01:57.14 | brlcad | yep, but then that specifically would be a case where tolerance would give you invariant results (within the specified tolerance) |
| 01:57.27 | Maloeran | The graph is different on every run, and that clearly changes the results a tiny bit |
| 01:58.26 | brlcad | yes, and the case can be made (and has been made) that the purpose of your tracer is filling a niche where the impact and varaince is probably acceptible |
| 01:58.52 | Maloeran | All right, thanks |
| 01:59.30 | brlcad | that doesn't give a carte blanche to ignore the variances though ;) the differences will (at least initially) probably be investigated one-by-one so that they are understood |
| 02:00.26 | brlcad | (in a real analysis and with test cases, part of the production polish) |
| 02:01.26 | brlcad | I suspect the bigger issue with integrating your tracer is not going to be edge cases.. :) |
| 02:01.51 | Maloeran | Yes, quite right, unfortunately... :) |
| 02:02.47 | Maloeran | Really, I think the API is efficient, clean, flexible and complete. Because of that, it of course isn't "simple" |
| 02:02.47 | brlcad | aside from politics and other issues, it's going to be issues caused from your tracer's fundamental approach of not retaining knowledge of solid geometry |
| 02:03.04 | Maloeran | Oh. I assumed it was the interface |
| 02:03.09 | brlcad | inside out issues, problems building intersection segments, etc |
| 02:03.42 | Maloeran | Inside-out issues can be cleanly handled *if* the interface is used as such with ray sources |
| 02:04.13 | brlcad | you're still thinking at the CS level -- the interface is somewhat irrelevant other than impacting performance |
| 02:04.45 | Maloeran | I'm saying that if the native interface is used, handling intersection segments and inside-out issues will not be a problem |
| 02:05.07 | Maloeran | If the API is butchered to be squeezed into another interface, it will be a problem |
| 02:05.08 | brlcad | I'm saying, I bet it will be regardless of the interface ;) |
| 02:05.24 | Maloeran | It's one of the things ray sources are meant to solve |
| 02:06.00 | brlcad | handling of bad geometry will be another problem, and overall robustness of your code I suspect |
| 02:06.06 | brlcad | but that's all tbd |
| 02:07.43 | brlcad | do you retain manifolds and topological structure? other than basic neighbor connectivity that is |
| 02:08.12 | Maloeran | I don't even retain neighbor connectivity :) |
| 02:08.33 | brlcad | thought so.. don't think you're import format even supports the concept of a shared edge iirc |
| 02:09.06 | brlcad | will be interesting to see what sort of results it has |
| 02:09.12 | Maloeran | Getting duplicate hits on the edges of connected triangles is perfectly normal, and that can be easily and flawlessly corrected with properly oriented meshes |
| 02:10.55 | brlcad | for a single part, I think that can be easily proven -- for arbitrary collections of parts, not so easy (regions perfectly aligned to other regions, embedded in other regions, lots of various edge cases) |
| 02:11.36 | brlcad | iirc, it's an np-complete problem even if you DO have the toplogical information |
| 02:12.33 | Maloeran | Ah yes, you could get two alternate false hits in a row, and it wouldn't be able to correct from the oriented mesh information |
| 02:12.39 | Maloeran | It's just terribly unlikely though |
| 02:12.45 | brlcad | heh |
| 02:12.53 | brlcad | it happens all the time :) |
| 02:13.09 | Maloeran | Two consecutive alternate false hits? Gez :) |
| 02:13.29 | Maloeran | Perhaps we don't mean exactly the same thing, but it's probably like one in a billion |
| 02:13.45 | brlcad | mostly caused by floating point math issues, but yeah, it happens |
| 02:14.11 | Maloeran | I think I would need to make a drawing about this special case |
| 02:16.25 | brlcad | I think I know the case, its one of several actually where the segment building goes all out of whack and you basically have to flip a coin |
| 02:17.04 | brlcad | Twingy spent more time that I bet he cared to dealing with getting the segment building to handle a couple of those cases similar to librt |
| 02:17.46 | Maloeran | http://www.rayforce.net/error.png |
| 02:17.51 | brlcad | http://fogonazos.blogspot.com/2007/02/largest-drain-hole-ever.html |
| 02:18.14 | Maloeran | Assuming all triangles are properly oriented, the code "knows" which sides of the triangles point out and in |
| 02:18.34 | brlcad | oh yeah, that case will come up.. a lot |
| 02:18.49 | Maloeran | The ray in red will enter at A and exit at B, two consecutive false hits with alternate sides |
| 02:18.59 | Maloeran | Really? It doesn't seem very likely to me |
| 02:19.25 | Maloeran | The triangles overlap each other just barely enough to cover the numerical imprecision of the ray-triangle intersection code |
| 02:20.17 | Maloeran | If the two false hits aren't facing in/out exactly, the code can figure it out, two consecutive "in" of course means to ignore the first |
| 02:21.38 | brlcad | yeah, there are lots of similar sorts of concave compartments, structures, and parts where there will be potential for a ray to hit that condition from some viewing perspective |
| 02:22.20 | Maloeran | Right, but it's really not likely to happen |
| 02:23.24 | brlcad | that depends entirely on the view and the geometry of course |
| 02:23.55 | brlcad | considering billions of rays are generally fired for a simulation, one in a billion means it'll likely be encountered a few hundred times causing .. who knows |
| 02:24.00 | brlcad | may matter, may not |
| 02:24.30 | Maloeran | *nods* I'm hoping one per billion rays won't matter too much... |
| 02:25.17 | brlcad | hehe, that's a case where scientifically it *might* not matter (it's TBD) .. but politically, it might ;-) |
| 03:00.49 | *** join/#brlcad IriX64 (n=IriX64@bas3-sudbury98-1168056909.dsl.bell.ca) |
| 03:08.03 | *** join/#brlcad SWPadnos_ (n=Me@dsl245.esjtvtli.sover.net) |
| 03:15.47 | CIA-5 | libIRC: 03jeffm2501 * 10libirc/ (4 files in 2 dirs): get the IRC server class listening and calling methods for events. |
| 03:17.36 | Maloeran | An IRC server class, in BRL-CAD? |
| 03:18.00 | Maloeran | Unexpected, amusing |
| 05:22.46 | brlcad | Maloeran: no, not in brl-cad |
| 05:23.11 | brlcad | it's a completely separate project that I worked on with jeff a couple years ago, and dabble with from time to time |
| 05:23.17 | brlcad | libIRC |
| 05:23.36 | louipc | what's that written in? |
| 05:24.19 | brlcad | C++ |
| 05:25.04 | brlcad | it has/had C callbacks at one point, don't remember where we left off with them |
| 05:30.21 | brlcad | it has a client and server interface, you can set up one or the other .. ane jeff seems to be refactoring some bits today for something he's working on |
| 05:30.49 | louipc | It reminds me of something similar done in TCL |
| 07:15.12 | *** join/#brlcad clock_ (i=clock@84-72-95-194.dclient.hispeed.ch) |
| 08:08.14 | *** join/#brlcad clock_ (n=clock@zux221-122-143.adsl.green.ch) |
| 09:11.43 | *** join/#brlcad docelic (n=docelic@212.91.114.49) |
| 09:32.40 | CIA-5 | BRL-CAD: 03brlcad * 10brlcad/bench/pixcmp.1: add initial manual page for pixcmp that includes the variou newly being added options (-l -i -s) along with details on return codes and example use. |
| 09:33.26 | CIA-5 | BRL-CAD: 03brlcad * 10brlcad/bench/Makefile.am: include the new pixcmp.1 manual page |
| 09:38.26 | CIA-5 | BRL-CAD: 03brlcad * 10brlcad/bench/pixcmp.c: |
| 09:38.26 | CIA-5 | BRL-CAD: major rewrite, add support for -s, -l, and -i options for silent, verbose output |
| 09:38.26 | CIA-5 | BRL-CAD: (ala cmp's -l option), and support for skipping input. make the return/error |
| 09:38.26 | CIA-5 | BRL-CAD: codes more uniform as well as more detail on the usage. still need to actually |
| 09:38.26 | CIA-5 | BRL-CAD: add the print statement for -l, but everything else should be done. basic |
| 09:38.28 | CIA-5 | BRL-CAD: operation and previous use remains unaffected. |
| 09:42.12 | CIA-5 | BRL-CAD: 03brlcad * 10brlcad/NEWS: added support to pixcmp for -s, -l, and -i options for silent, verbose output, and support for skipping input making the interface more similar to cmp. also note the addition of a new manual page for pixcmp too. |
| 13:17.54 | Twingy | hrm |
| 13:18.00 | Twingy | icy |
| 14:11.06 | ``Erik | indeed, I'm not going to the office today |
| 14:52.19 | brlcad | hrmph, no connection to cad |
| 15:20.58 | brlcad | well allrighty then.. that plan didn't work |
| 15:31.32 | ``Erik | ? car iced over? |
| 15:41.53 | brlcad | yup |
| 15:42.16 | brlcad | and my scraper is sitting in front of my desk |
| 15:52.27 | ``Erik | lee was in the office and shut down machines, they had a long power outage |
| 15:52.53 | ``Erik | <-- was just on the phone with wendy, she'll try to find someone to light some of them up |
| 15:58.26 | brlcad | cad came back up |
| 15:58.39 | brlcad | and has no downtime, so probably just a switch somewhere |
| 15:59.16 | brlcad | the x twins are probably lee's doing |
| 16:01.25 | ``Erik | ... fuck.... |
| 16:03.40 | ``Erik | brlcad, think you could tar up ~/.cvs/devel/rtcmp and shoot it to me? |
| 16:05.04 | ``Erik | (or ~/src/rtcmp) |
| 16:07.46 | Twingy | use hot water |
| 16:28.13 | Twingy | if you have salt, hot salty water works good too |
| 16:29.00 | *** join/#brlcad docelic_ (n=docelic@212.91.112.149) |
| 16:29.22 | Twingy | if I owned your car I wouldn't drive in it either |
| 16:31.22 | louipc | I wouldn't think pouring salty water on a car is a good idea |
| 16:31.32 | archivist | having seen pics of his last crash, lock ``Erik indoors |
| 16:31.38 | ``Erik | heh |
| 16:31.54 | ``Erik | back to snow out there |
| 16:35.21 | ``Erik | being the only accident of any kind that was my fault in 15 yrs, and certain mitigating circumstances, I don't think I'm doing TOO bad... I mean, I've driven on 6" of solid ice, I've gone out of control on an onramp in colorado during a major blizzard, driven through fog with like 20' visibility, ... *shrug* |
| 16:35.41 | ``Erik | I had a bout of stupid, and I'm cured of it now. otherwise, I think I'm reasonably competent behind the wheel :D |
| 16:54.23 | brlcad | ``Erik: done, in your home on .bz |
| 17:27.31 | ``Erik | heh, that means I gotta remember my passwd to .bz :D |
| 17:28.13 | ``Erik | or find a valid ssh key'd machine |
| 17:32.40 | ``Erik | teh fux, one of my g4's is pinging but not permitting ssh |
| 18:14.59 | Twingy | hah |
| 18:15.06 | Twingy | <PROTECTED> |
| 18:15.17 | Twingy | decided to trim the new plane |
| 18:15.24 | Twingy | 3 flights, landings were almost vertical due to wind |
| 18:15.52 | Twingy | the funny thing is at 2 notches of 10 it was as fast as my trainer |
| 18:19.07 | ``Erik | where'd you fly? |
| 18:19.43 | ``Erik | too much noise to fly out your back yard, I presume... |
| 18:19.50 | ``Erik | fences, trees, houses, etc |
| 18:20.35 | Twingy | edgewood |
| 18:20.37 | Twingy | HS |
| 18:20.56 | ``Erik | ah, out at their sports fields... |
| 18:21.07 | Twingy | by the third flight I was slushing through |
| 18:21.15 | ``Erik | back in missouri, I talked to school admins, they didn' want me to fly due to the liability |
| 18:21.24 | Twingy | heh, ask me if I care :D |
| 18:21.26 | ``Erik | though they thought it was cool |
| 18:21.28 | ``Erik | *shrug* |
| 18:21.42 | ``Erik | <-- a bit less fast&loose about rules... |
| 18:22.02 | ``Erik | thought, oddly enough, I convinced the evil one to seriously bend a rule for me today |
| 18:22.20 | ``Erik | <-- working in his dining room O.o |
| 18:22.34 | Twingy | haha, the evil one |
| 18:22.37 | ``Erik | I mean, um, 'having a coordination meeting' |
| 18:22.41 | Twingy | Darth W |
| 18:22.45 | ``Erik | ayup |
| 18:23.02 | ``Erik | the disturbing part is that darth w sees the darth as a victem |
| 18:23.16 | ``Erik | like, lametard sw, not real s |
| 18:23.16 | ``Erik | sw |
| 18:23.32 | Twingy | yes, that does make the satire all the better :) |
| 18:23.47 | ``Erik | "where's skankbutt?" "you killed her" "nnnooooooooooocallameeting" |
| 18:24.10 | Twingy | the guys in my branch get a kick out of how many emails I get from wendy |
| 18:24.17 | ``Erik | every once a while, though, there's an omfg wtf |
| 18:24.31 | Twingy | checked my email this week, 2 from my branch, elevendy billion from wendy |
| 18:24.33 | ``Erik | hah, yeah, no shit, yesterday, I got like 40 from her out of like 60 |
| 18:24.58 | ``Erik | and a good number of the 'not from her' emails were automated status things |
| 18:25.05 | ``Erik | <-- gets 3 a day from the machines he admins |
| 18:25.33 | Twingy | there's 3 I'd like not to get from machines I don't admin |
| 18:25.35 | ``Erik | so over the 3 day weekend I enjoyed... she was still 2/3 of the volume |
| 18:25.59 | ``Erik | I don't htink you recieve any from my machines... just the list that you accidently got on, no? |
| 18:26.09 | Twingy | the x's and cad |
| 18:26.16 | ``Erik | those ain't mine |
| 18:26.18 | Twingy | root@ |
| 18:26.22 | Twingy | don't want those |
| 18:26.24 | ``Erik | but I'll look into removing you from that list if it's in my power |
| 18:26.28 | ``Erik | tomorrie |
| 18:26.29 | Twingy | hooray |
| 18:26.39 | Twingy | three less delete buttons to press |
| 18:26.49 | ``Erik | using web mail? |
| 18:27.03 | ``Erik | <-- has the winderz box, but mostly uses the web mail at wizmer |
| 18:27.04 | Twingy | no, hopping on co-workers computer until lappy ariives |
| 18:27.18 | ``Erik | the other two quit working... |
| 18:27.48 | Twingy | wendy got upset when I told her I was checking my email twice a week |
| 18:27.55 | ``Erik | hh |
| 18:28.10 | ``Erik | wow, twice? you're cutting into your productivity there |
| 18:28.14 | Twingy | the funny thing is, I don't care :) |
| 18:28.30 | ``Erik | I've taken the stance that I check it MAYBE once a day... when I get into the office... |
| 18:28.38 | ``Erik | no one has given me shit yet |
| 18:31.54 | ``Erik | hah |
| 18:31.55 | ``Erik | admin leave |
| 18:31.56 | ``Erik | swank |
| 18:32.52 | ``Erik | I'm damn glad I didn't attempt to drive in today |
| 18:39.01 | Maloeran | Working from home? |
| 18:39.55 | docelic | so who is wendy ? |
| 18:46.48 | Maloeran | The boss of Erik's boss, and the boss of Justin's former boss |
| 18:47.17 | docelic | Were the emails spicy, ``Erik ? |
| 18:47.17 | docelic | :) |
| 20:13.53 | *** join/#brlcad ChanServ (ChanServ@services.) |
| 20:13.54 | *** mode/#brlcad [+o ChanServ] by irc.freenode.net |
| 20:17.33 | ``Erik | heh, sorry... didnah catch teh k0rekshunz |
| 20:24.21 | *** join/#brlcad louipc (n=louipc@bas8-toronto63-1177706916.dsl.bell.ca) |
| 20:30.37 | *** join/#brlcad ChanServ (ChanServ@services.) |
| 20:30.37 | *** mode/#brlcad [+o ChanServ] by irc.freenode.net |
| 20:31.15 | *** join/#brlcad clock_ (i=clock@84-72-94-178.dclient.hispeed.ch) |
| 20:49.58 | CIA-5 | BRL-CAD: 03brlcad * 10brlcad/TODO: fix the variety of ami.tcl and ampi.tcl tclscript warnings/errors |
| 22:04.41 | CIA-5 | BRL-CAD: 03brlcad * 10brlcad/ (10 files in 3 dirs): remove libtkGLX. it was only being compiled on IRIX, but actually not even being used there. |
| 23:31.53 | *** join/#brlcad digitalfredy (n=digitalf@200.71.62.161) |
