| 00:02.17 | andromeda-galaxy | another approach would be to have do_frame() actually turn the bu_list into an array, which would give really easy random access... |
| 00:21.02 | *** join/#brlcad unicodesnowman (~unicodesn@unaffiliated/unicodesnowman) |
| 00:37.34 | ``Erik | andromeda-galaxy: perspective is the big one, I think it's horizontal angle, um, and I vagually recall some other flag for rt that tweaked the ratio, I want to say it was needed for non-square rendering? |
| 00:47.19 | andromeda-galaxy | ``Erik: hmm, interesting... |
| 00:47.43 | andromeda-galaxy | is it better to use perspective and calculate the other angle from the ratio, or to get the angle from the width/height? |
| 00:48.02 | andromeda-galaxy | ``Erik: also, did you see the question about bu_list nth element? |
| 00:49.35 | andromeda-galaxy | ``Erik: ah, it looks like it's rt_perspective for the horizontal angle and aspect for the aspect ratio |
| 01:08.30 | *** join/#brlcad sofat_ (~sofat@202.164.45.208) |
| 01:18.32 | starseeker | andromeda-galaxy: I think you have to iterate over lists |
| 01:22.40 | andromeda-galaxy | starseeker: ah well... I was hoping that there was a utility function to do it already |
| 01:23.02 | andromeda-galaxy | I think that I'll just copy the linked list into an array.. |
| 01:23.07 | starseeker | recalls wishing the same thing... I usually end up using bu_ptbl arrays rather than lists |
| 01:23.26 | starseeker | not always the best move, but I've always been a little uncomfortable with bu_list |
| 01:23.37 | starseeker | (probably another reason to use them, actually...) |
| 01:25.19 | andromeda-galaxy | starseeker: hmm, interesting --- what do you think of the copying into array approach? |
| 01:25.36 | andromeda-galaxy | it seems like the simplest way to get the random access needed for minimally-invasive changes to rt |
| 01:25.49 | starseeker | andromeda-galaxy: sounds like it's worth a shot |
| 01:26.42 | andromeda-galaxy | starseeker: sounds good! I've just done the initial conversion effort for orthogonal, and now rt is segfaulting ;(... |
| 01:44.27 | andromeda-galaxy | starseeker: is there any way to ask make benchmark to only run the tests that use orthogonal rays? |
| 01:47.08 | andromeda-galaxy | starseeker: also, it looks to me from the code like rt defaults to rt_perspective = 0 (which would result in orthogonal), but I'm slightly worried thata the global is being set somewhere that I can't see; is that correct? |
| 01:47.28 | starseeker | uh... I don't think benchmark can do orthogonal rays only offhand... |
| 01:48.02 | starseeker | you might want to check the global read in gdb to be absolutely sure |
| 01:48.23 | starseeker | andromeda-galaxy: sorry, you're deep in a part of the code I know relatively little about |
| 01:51.19 | andromeda-galaxy | starseeker: oh well... if it's doing orthogonal by default, then it doesn't matter since moss, at least, seems to use the default |
| 01:55.33 | *** join/#brlcad chick_ (~chick@41.205.22.41) |
| 03:41.11 | Notify | 02GCI:brlcad * 5568169431269376 : Task Closed - Congratulations, this task has been completed successfully. |
| 03:41.22 | Notify | 02GCI:brlcad * 6458111619497984 : Task Assigned - This task has been assigned to Niels Mentink. You have 100 hours to complete this task, good luck! |
| 03:42.42 | Notify | 02GCI:brlcad * 5247354030522368 : Task Closed - Congratulations, this task has been completed successfully. |
| 03:45.06 | Notify | 02GCI:brlcad * 5323147989483520 : Task Needs More Work - One of the mentors has sent this task back for more work. Talk to the mentor(s) assigned to this task to satisfy the requirements needed to... |
| 04:00.25 | andromeda-galaxy | brlcad; what is wrong with https://www.google-melange.com/gci/task/view/google/gci2014/5323147989483520? |
| 04:00.26 | gcibot | [[ Visualize ray bundling #2 || BRL-CAD || NeedsWork || Kesha Shah, Daniel_R ]] |
| 04:04.09 | Notify | 02GCI:brlcad * 5323147989483520 : one minor thing - Oof, you're definitely starting to poke a hornets nest now... ;) So this looks fantastic, the visualizations are perfect. Heck, I didn't even... |
| 04:04.55 | brlcad | ``Erik: TMOUT is only commented-out in my dotfiles, you sure you don't have an unset in yours? :) |
| 04:05.35 | brlcad | ``Erik: and no idea about denyhost seizures .. it's not been working for many months (ever) -- adds to the file but that file isn't used, so maybe that's the issue? |
| 04:06.59 | brlcad | andromeda-galaxy: I'd rather move away from bu_list for the rays |
| 04:07.00 | Notify | 02GCI:o7p9bxbnyj * 5323147989483520 : -l/-c - -c is the number of rays per <ring/radius/length>, whereas -l is used to specify what the length actually is |
| 04:07.06 | brlcad | how to do that is something to discuss |
| 04:08.19 | brlcad | andromeda-galaxy: there's perspective and an aspect ratio, -V option |
| 04:09.26 | andromeda-galaxy | brlcad: regarding moving away from bu_list for the rays, I agree --- copying them into an array is just something that I was going to use temporarily |
| 04:09.29 | andromeda-galaxy | for the rt task |
| 04:09.56 | andromeda-galaxy | brlcad: let me document the options in xml quickly and then I'll resubmit it, take a look at my comment regarding -l vs. -c |
| 04:10.04 | brlcad | andromeda-galaxy: and no, there's no way to get benchmark to change the work it's doing .. that would violate the benchmark analysis |
| 04:10.21 | brlcad | you can certainly just run a couple traces yourself |
| 04:10.29 | brlcad | rt moss.g all.g |
| 04:12.41 | brlcad | andromeda-galaxy: and I think you misunderstood my options comment |
| 04:13.20 | brlcad | it's not so much to explain it .. it's how to say that without repeating the word "length" because you're basically mixing a 1-tuple with a 2-tuple |
| 04:14.48 | andromeda-galaxy | ahh |
| 04:14.54 | andromeda-galaxy | okay, let me try to reparase that quickly... |
| 04:15.25 | andromeda-galaxy | brlcad: on another note, converting rt to use these is being quite annoying... |
| 04:15.46 | brlcad | if -l # # is a width and height for the rect type (only? what about frustum?), then probably using the word "dimensions" would fix the mixing |
| 04:16.19 | andromeda-galaxy | brlcad: for frustum, the angle is used instead |
| 04:16.36 | andromeda-galaxy | brlcad: sure, I've just changed it to dimension in the rtshot help |
| 04:16.38 | brlcad | okay, so it's accurate |
| 04:18.09 | andromeda-galaxy | brlcad: okaya, I've uploaded a new diff with docbook & fixed rtshot help |
| 04:18.10 | Notify | 02GCI:o7p9bxbnyj * 5323147989483520 : Ready for review - The work on this task is ready to be reviewed. |
| 04:18.16 | andromeda-galaxy | brlcad: on the topic of updating rt, |
| 04:18.39 | andromeda-galaxy | for some reason, the rays created by the gen function are being correct for a while, and then getting off... it's really weird |
| 04:18.49 | andromeda-galaxy | I've been trying to track down the problem for ~4hrs already... |
| 04:23.35 | Notify | 02GCI:brlcad * 5323147989483520 : Task Closed - Congratulations, this task has been completed successfully. |
| 04:24.33 | brlcad | andromeda-galaxy: not sure what to tell you other than debugging hints .. print the rays with -x 0x00000001 |
| 04:25.04 | brlcad | if it's crashing, that should be much easier to diagnose .. maybe paste a backtrace |
| 04:25.18 | andromeda-galaxy | brlcad: it's not crashing, which is annoying |
| 04:25.26 | andromeda-galaxy | I have some of my own ray printing going on, because I forgot about -x |
| 04:25.32 | andromeda-galaxy | and it's doing some really weird things |
| 04:25.40 | andromeda-galaxy | for hundreds and hundreds of rays it's working gread |
| 04:25.42 | andromeda-galaxy | *great |
| 04:25.50 | andromeda-galaxy | and then it suddenly jumps to totally the wrong |
| 04:25.51 | andromeda-galaxy | place |
| 04:26.58 | andromeda-galaxy | it looks almost like it's coming up with slightly too few or too many rays, so when a given processor skips ahead, it skips too far... |
| 04:27.38 | andromeda-galaxy | brlcad: by the way, why does per_processor_chunk increase with the number of processors? It seems to me like it would make more sense to set per_processor_chunk at the beginning so that each processor had an equal chunk of the image (getting smaller as more processors appeared) |
| 04:30.15 | andromeda-galaxy | brlcad: if I don't get it working soon, would you mind if I submitted the mostly-working solution and we repurposed #2 to be finishing getting it working? |
| 04:33.26 | brlcad | andromeda-galaxy: another thought is -P1 to limit processing to single-threaded operation, just to rule out any concurrency/access issues |
| 04:33.48 | brlcad | and if it's hundreds of rays, perhaps it's at the end of the first scanline? |
| 04:33.48 | andromeda-galaxy | brlcad: good point, let me try that, thanks! I don't know why I didn't think of that earlier... |
| 04:34.18 | andromeda-galaxy | brlcad: it's possible... it looks like it's after more than one though... (thousands of rays, maybe) |
| 04:35.47 | andromeda-galaxy | brlcad: oh, and one other thing that's been nagging at me --- why do so many of brlcad's commands output routine information on stderr? |
| 04:35.50 | brlcad | and the comment above per_processor_chunk says why it increases |
| 04:36.01 | brlcad | the more you have, the more will be completed, so they take ncpu larger bites |
| 04:36.27 | brlcad | which in practice is roughly still the time it would have taken 1 cpu to do N/cpu work |
| 04:37.02 | andromeda-galaxy | brlcad: this is the comment that I'm seeing in worker.c, at least: ' /* The more CPUs at work, the bigger the bites we take */' |
| 04:37.28 | andromeda-galaxy | that makes mor sense now... |
| 04:37.29 | brlcad | yep, that's what I was referring to |
| 04:37.47 | andromeda-galaxy | it wasn't exactly transparent at first, my intuition was that the bite size should go down as the num went up |
| 04:37.59 | andromeda-galaxy | because otherwise eventually there wouldn't be enough bites left to go around... |
| 04:38.12 | brlcad | (and that is set at the beginning) |
| 04:38.40 | brlcad | npsw is going to be the number of cores you have, so 4 or 8 or 12 pixels at a time |
| 04:38.53 | brlcad | (or 1 with -P1) |
| 04:39.27 | brlcad | a few of the tracers override that value and make them calculate scanline at a time |
| 04:40.26 | andromeda-galaxy | hmm, that makes more sense... |
| 04:40.39 | andromeda-galaxy | brlcad: it is, apparently, being overidden to 512 |
| 04:45.25 | andromeda-galaxy | brlcad: btw, I'm actually changing p back to A on rtshot |
| 04:45.34 | andromeda-galaxy | *back to P |
| 04:45.39 | andromeda-galaxy | because -p conflicts with 'point' |
| 04:45.51 | andromeda-galaxy | don't know why it didn't show up earlier, sory |
| 04:50.14 | andromeda-galaxy | brlcad: would you mind taking a quick look at the png from the raytrace and telling me if something jumps out at you from that? |
| 04:58.48 | andromeda-galaxy | brlcad: ha, I've got it! the gen_rect() function needed to not include the upper/right end of its range.... |
| 04:58.56 | andromeda-galaxy | (I think that was it, at least) |
| 05:06.05 | brlcad | andromeda-galaxy: rt gets to overrule rtshot |
| 05:06.16 | brlcad | rtshot is a dev tool, rt is our oldest tool |
| 05:06.36 | andromeda-galaxy | ah, right --- is using -P instead of -p for rtshot alright, though? It's fairly similar... |
| 05:06.41 | brlcad | a point can be -O (origin) or seomthing else |
| 05:07.14 | andromeda-galaxy | brlcad: or, we could make -P be the origin point, and -p the perspective... it's not only for perspective though, it's also used for the conic... |
| 05:07.31 | brlcad | similar is not the same .. if there's going to be an option that has the exact semantic meaning as an existing rt option, it should use the rt nomenclature |
| 05:07.57 | brlcad | -P is num_cpu to rt, so if anyone ever goes to make it shoot in parallel, that'll get changed |
| 05:08.08 | andromeda-galaxy | brlcad: that's true... I guess my question is really, is it actually exactly the same semantically, since it's also used for conic? If you think it's close enough semantically, I'll change to -O/-p |
| 05:08.14 | brlcad | rt uses almost every letter/number, so there's always going to be a conflict :) |
| 05:08.43 | andromeda-galaxy | indeed :) unfortunately, rtshot already has o taken... maybe s for start? |
| 05:08.59 | andromeda-galaxy | it's even documented as "set starting point"... |
| 05:09.02 | brlcad | what's -O ? |
| 05:09.18 | andromeda-galaxy | <PROTECTED> |
| 05:09.18 | andromeda-galaxy | <PROTECTED> |
| 05:09.41 | brlcad | ah, that's messed up |
| 05:10.09 | brlcad | -o should universally be the -o output option |
| 05:10.35 | andromeda-galaxy | brlcad: true.... I don't think rtshot has any output |
| 05:10.39 | andromeda-galaxy | option |
| 05:10.58 | andromeda-galaxy | so someone decided to use it for onehit instead... for now, what do you think of using -s for start? |
| 05:11.02 | brlcad | it outputs text, but you're right that tit doesn't "really" |
| 05:11.15 | brlcad | s for start sounds fine |
| 05:11.25 | andromeda-galaxy | I wouldn't mind overhauling rtshot's interface sometime, but maybe not right now ;-) |
| 05:11.35 | brlcad | really doesn't matter -- it's only where we introduce options that do match rt, it should use rt's letter and rtshot should adjust to accommodate |
| 05:11.43 | andromeda-galaxy | now that's odd... my modified rt went through regress fine, and now it's doing this: |
| 05:11.46 | andromeda-galaxy | ERROR: bu_malloc(0) |
| 05:11.50 | andromeda-galaxy | brlcad: makes sense |
| 05:12.20 | brlcad | there will be a bomb log file from that bu_malloc(0) |
| 05:12.34 | brlcad | s/will/shou/d |
| 05:12.37 | brlcad | should* |
| 05:13.26 | andromeda-galaxy | there is, but there's no backtrace in it... |
| 05:13.30 | *** join/#brlcad MarcTannous (bc192333@gateway/web/cgi-irc/kiwiirc.com/ip.188.25.35.51) |
| 05:14.45 | brlcad | that's unusual in itself..... |
| 05:15.01 | brlcad | well, you can run in a debugger and put a breakpoint on bu_bomb |
| 05:15.14 | andromeda-galaxy | brlcad: I don't remember now, but it's possible that cmake has decided to build in release mode or some such, would that disable the backtraces? |
| 05:15.36 | brlcad | release mode doesn't disable backtracing |
| 05:16.23 | andromeda-galaxy | brlcad: hmm... and it's not even in release mode(just checked)... this is odd. |
| 05:16.36 | brlcad | does it say "WARNING: Unable to obtain a call stack backtrace"? |
| 05:17.03 | brlcad | maybe just paste it somewhere |
| 05:17.33 | Notify | 02GCI:tannousmarc * 5607116194709504 : Task Claimed - I would like to work on this task. |
| 05:17.34 | andromeda-galaxy | say that where? |
| 05:17.55 | brlcad | in the crash log |
| 05:18.44 | Notify | 02GCI:brlcad * 5607116194709504 : Task Assigned - This task has been assigned to Marc Tannous. You have 100 hours to complete this task, good luck! |
| 05:18.45 | Notify | 02GCI:brlcad * 5050736735944704 : Task Assigned - This task has been assigned to Raptor. You have 100 hours to complete this task, good luck! |
| 05:18.50 | andromeda-galaxy | brlcad: http://pastebin.com/D9d5itUy |
| 05:19.08 | andromeda-galaxy | brlcad: it doesn't, it just says there's a backtrace and then doesn't show it |
| 05:19.51 | andromeda-galaxy | brlcad: if you want, I can put the diff up on Melange and you can try running it and see if the same thing happens |
| 05:55.12 | Notify | 02GCI:o7p9bxbnyj * 6381493563686912 : Ready for review - The work on this task is ready to be reviewed. |
| 05:57.17 | Notify | 02GCI:o7p9bxbnyj * 6381493563686912 : Status - This appears to make rt work correctly while using the new rt_gen_rect() function for orthogonal mode (make benchmarak and make regress both appear to... |
| 06:03.51 | brlcad | andromeda-galaxy: huh, is the file still empty? it could just be taking a VERY long time |
| 06:04.58 | brlcad | andromeda-galaxy: I'd be glad to try it (tomorrow) |
| 06:10.04 | brlcad | with the latest task, modifying gen_rect to be a half closed and half open set is a little concerning... |
| 06:10.31 | brlcad | that's not exactly consistent behavior whereas the prior documented form (always a closed set) was consistent |
| 06:11.14 | brlcad | feels like making the interface match your tolernaces instead of making your tolerances match your interface |
| 06:12.23 | Notify | 02GCI:brlcad * 6381493563686912 : Task Closed - Congratulations, this task has been completed successfully. |
| 06:14.19 | andromeda-galaxy | brlcad: that's true, I also like the idea of fixing that |
| 06:14.27 | Notify | 02GCI:brlcad * 6381493563686912 : not commitable - Comments left on IRC, but this does not look at all in shape to be committed. Many questions and issues. Plus, refactoring to a function, the code... |
| 06:14.55 | andromeda-galaxy | (making it not half-open/half-closed) |
| 06:16.18 | andromeda-galaxy | brlcad: the problem is that as far as I can tell there is no way to make the behavior consistent without making the output of rt be slightly different (at the very least, having an extra row of pixels along/removing a row of pixels from the top/right) |
| 06:16.33 | andromeda-galaxy | and, of course, ideally rt continues to make the same output forever... |
| 06:17.56 | brlcad | eh? rt could certainly call the ray generator with parameters accordingly to keep the evaluated pixels identical |
| 06:18.52 | brlcad | there's nothing that says the values in rt must get passed to some function as-is and that function must behave the same, for example, if rt is doing a closed to open set sweep across scanlines |
| 06:19.47 | brlcad | if anything, it could throw the row away post generation |
| 06:20.48 | brlcad | recall that you introduced this notion of a center ray, and that could be complicating matters for getting them to match ;) |
| 06:21.11 | brlcad | (or rather elaborated on it's use by the existing generators) |
| 06:23.31 | andromeda-galaxy | brlcad: true... changing the center ray generation might work |
| 06:24.10 | andromeda-galaxy | brlcad: having rt throw away the extra rows is another approach that I considered, it might be best |
| 06:24.38 | andromeda-galaxy | with the current interface to rt_gen_rect(), at least, it can't get the same set of pixels that it previously used since reducing to the next size down closed set would result in a missing left/bottom row |
| 06:25.43 | brlcad | i'd still first question if/why the generator parameters cannot be made to exactly produce the same set of rays as before |
| 06:25.46 | brlcad | and if not, why not |
| 06:25.48 | andromeda-galaxy | I just like having the center_ray with symmetrical generation parameters because that's what everything else is using... |
| 06:26.14 | brlcad | that's why an integration task was created, not just a matter of using the function, but to find out where the function is failing in design |
| 06:26.39 | brlcad | note that there really is no "center ray" ... there's maybe a center/direction vector |
| 06:26.44 | brlcad | and starting point |
| 06:26.58 | brlcad | happen to be using a ray construct that has a point and direction vector embedded |
| 06:27.09 | brlcad | but it shouldn't be confused with being an actual raytrace ray |
| 06:27.13 | andromeda-galaxy | brlcad: indeed... would you mind creating a second integration task to try to fix the failings of this one? I'd enjoy doing it, but think that that combined with what I did for this is probably enough work for two tasks |
| 06:27.52 | andromeda-galaxy | it might be possible to get the right behavior with the fully closed set behavior |
| 06:28.05 | andromeda-galaxy | by moving the center ray to be on a half-pixel boundary down and left from the center |
| 06:28.34 | andromeda-galaxy | and then changing the a/b len vectors as required... |
| 06:29.20 | brlcad | there is already https://www.google-melange.com/gci/task/view/google/gci2014/6466077978525696 |
| 06:29.20 | gcibot | [[ Update rt to utilize new ray sampling functions #2 || BRL-CAD || Open || Kesha Shah, Deepak ]] |
| 06:29.45 | andromeda-galaxy | brlcad: the current task description basically says that that one should be about perspective, since this one was about orthogonal, right? |
| 06:30.12 | brlcad | it was just to chop up work into multiple tasks as this was known to be a complicated goal |
| 06:30.33 | andromeda-galaxy | brlcad: sure, then I'll claim that one and try to polish some of this work a little more tomorrow |
| 06:30.59 | andromeda-galaxy | if it doesn't take too long, I'll combine it with the submission for perspective, if it does, I'll make it separate and ask if you can create another task for perspective |
| 06:31.30 | Notify | 02GCI:o7p9bxbnyj * 6466077978525696 : Task Claimed - I would like to work on this task. |
| 06:31.59 | brlcad | that's fine, let me know how it goes |
| 06:32.13 | brlcad | reminds that task count is mostly irrelevant |
| 06:32.43 | brlcad | tasks that can't be integrated / used will generally get ranked lower than those that can be used |
| 06:32.51 | andromeda-galaxy | brlcad: sure, if I run into anything too problematic, I'll mention it on IRC... hopefully the perspective migration will go slightly more smoothly now that I have some experience from the orthogonal one |
| 06:32.51 | brlcad | so better to take something to a useful completion |
| 06:33.12 | andromeda-galaxy | brlcad: indeed :-) I really want to get this into a workable state & have it merged |
| 06:34.12 | brlcad | my main concerns are the generator getting defined to be a quirky open/closed set definitino, that it actually expanded rt's line count substantially (this should be justified or corrected), and it obviously must be validated with testing |
| 06:35.58 | brlcad | the result might be the elimination of a center pt+dir view notion or maybe defining a view and defining sampling within that view separately, or it might be a simple matter of tweaking tolerances consistently or something else entirely |
| 06:36.06 | brlcad | (just food for thought) |
| 06:36.33 | brlcad | keep an open mind, not lost in where you've been but where you're going |
| 06:37.04 | andromeda-galaxy | brlcad: that makes sense, thanks for the advice! I'll start with the simple verson tomorrow, and see how it does by those metrics, if it gets too bad I'll try some of the more radical changes. |
| 06:37.19 | Notify | 02GCI:brlcad * 6466077978525696 : Task Assigned - This task has been assigned to Andromeda Galaxy. You have 100 hours to complete this task, good luck! |
| 06:37.29 | brlcad | it's still fantastic progress either way |
| 06:37.39 | brlcad | hopefully you'll be able to sort it all out :) |
| 06:37.47 | andromeda-galaxy | brlcad: thanks! I hope so too :) |
| 06:37.50 | brlcad | if anything, though, those visualizations are gold |
| 06:38.09 | brlcad | my only lament is that you didn't get to this sooner so you could have tackled some of the OpenCL work :) |
| 06:38.57 | andromeda-galaxy | ah well... maybe this year I'll actually manage to stay more involved post-GCI and do some things like OpenCL |
| 06:39.16 | andromeda-galaxy | though for that, I'll have to get my graphics drivers working with OpenCL, mesa/Gallium still doesn't really wor |
| 06:39.19 | andromeda-galaxy | *work |
| 06:43.41 | *** join/#brlcad andromeda_galaxy (~andromeda@108-225-17-54.lightspeed.sntcca.sbcglobal.net) |
| 06:50.45 | *** join/#brlcad YashM (~YashM@117.222.23.137) |
| 07:47.40 | *** join/#brlcad andrei_ (c35a6e7d@gateway/web/freenode/ip.195.90.110.125) |
| 14:56.38 | *** join/#brlcad infobot (ibot@rikers.org) |
| 14:56.38 | *** topic/#brlcad is Topic for #brlcad: BRL-CAD || http://brlcad.org || logs: http://ibot.rikers.org/%23brlcad/ || Welcome GCI 2014 participants! If you're participating, be patient when asking questions... we're very busy and sometimes have packed schedules. We will respond if you are still on IRC: learn screen+irssi. |
| 15:07.15 | brlcad | andrei_: do you have the link to the tasks that parth copied? |
| 15:07.36 | brlcad | please report any instances of blatant plagiarism to me |
| 15:07.54 | brlcad | Ch3ck: keep an eye out especially on design tasks .. there is cheating going on |
| 15:08.18 | andrei_ | brlcad: one moment |
| 15:08.59 | andrei_ | http://www.google-melange.com/gci/task/view/google/gci2014/5186134254551040 and http://www.google-melange.com/gci/task/view/google/gci2014/6362007112515584 are the same |
| 15:09.00 | gcibot | [[ Animate our logo! #9 || BRL-CAD || Closed || Mihai Neacsu, Daniel_R ]] |
| 15:09.01 | gcibot | [[ Animate our logo! #5 || BRL-CAD || Closed || Mihai Neacsu, Ishwerdas ]] |
| 15:09.41 | andrei_ | for once, let me dig a bit |
| 15:10.13 | andrei_ | also, it's worth pointing out that I removed his claim once for repeatedly doing this |
| 15:12.15 | andrei_ | http://www.google-melange.com/gci/task/view/google/gci2014/5327961523748864 these are also forged http://www.google-melange.com/gci/task/view/google/gci2014/6453861430591488 |
| 15:12.18 | gcibot | [[ Design a new website favicon! #2 || BRL-CAD || Closed || Sean, Jacob B ]] |
| 15:12.18 | gcibot | [[ Design a new website favicon! #5 || BRL-CAD || Closed || Deepak, Ch3ck ]] |
| 15:12.37 | andrei_ | I mean not forged, but identical |
| 15:13.04 | Notify | 02GCI:brlcad * 5867661997113344 Animate our logo! #14 https://www.google-melange.com/gci/task/view/google/gci2014/5867661997113344: also not using the right logo Rohit, you're also using the old... |
| 15:13.06 | gcibot | [[ Animate our logo! #14 || BRL-CAD || NeedsWork || Kesha Shah, Ishwerdas ]] |
| 15:14.31 | *** join/#brlcad darshpreets (~darshpree@202.164.53.117) |
| 15:16.50 | Notify | 02GCI:brlcad * 6362007112515584 : not acceptable - Parth, copying the work of others is not acceptable. |
| 15:19.50 | Notify | 02GCI:rohit_agarwal * 5867661997113344 : Ready for review - The work on this task is ready to be reviewed. |
| 15:20.57 | *** join/#brlcad chick_ (~chick@195.24.220.134) |
| 15:27.16 | brlcad | andrei_: I see how the logo animation is a copy, but the favicon? |
| 15:28.05 | andrei_ | his favicon is aditya's favion with a different background? |
| 15:28.19 | andrei_ | actually, if you see aditya around, ask him/her, he was regularly complaining/warning us about that |
| 15:28.43 | andrei_ | you can even see his/her comments on some tasks |
| 15:31.20 | brlcad | andrei_: I know, several students tasks have already become marked invalid and the students disqualified for such behavior |
| 15:31.46 | brlcad | my point was merely that the favicon actually was technically different, just not very much |
| 15:32.05 | brlcad | enough for there to be an argument |
| 15:32.36 | brlcad | i.e., looks like they imported the animated gif into photoshop and reordered /deleted layers |
| 15:33.23 | brlcad | let me know if you see any others and hopefully Ch3ck can be more careful to at least reject crappy submissions like that one a few times even if he doesn't notice they're copies ;) |
| 15:33.24 | andrei_ | Sorry, I have to go right now, I ll have a look later to see what he did, I ll see if I can search posts on melange(i.e tasks he claimed and I unclaimed or so) |
| 15:33.42 | brlcad | the blatant one is enough and has been reported |
| 15:33.48 | andrei_ | alright, great |
| 15:33.54 | brlcad | i mean any other students |
| 15:35.27 | YashM | http://www.google-melange.com/gci/task/view/google/gci2014/5107273286287360 is a forge of http://www.google-melange.com/gci/task/view/google/gci2014/5170304011730944 |
| 15:35.27 | gcibot | [[ Model BRL-CAD logo in BRL-CAD #2 || BRL-CAD || Closed || Popescu Andrei, Hardeep Singh Rai ]] |
| 15:35.27 | gcibot | [[ Model BRL-CAD logo in BRL-CAD || BRL-CAD || Closed || Kesha Shah, Deepak ]] |
| 15:37.31 | andromeda-galaxy | brlcad: in case you were curious, I just found that using closed sampling and shifting the center over half a scanline to the left and down appears to be working |
| 15:38.13 | andromeda-galaxy | (at least, it's right visually --- I'm running regress right now to finish checking that it's pixel-perfect) |
| 15:41.43 | brlcad | YashM: that one is already known and being delt with |
| 15:41.56 | YashM | ok |
| 15:42.02 | andromeda-galaxy | brlcad: do any of the benchmark/regress tests use perspective rendering? I couldn't find any by grepping through the bench/regress directories |
| 15:46.50 | *** join/#brlcad kintel (~kintel@unaffiliated/kintel) |
| 15:53.18 | raptor | ooooh |
| 15:56.51 | brlcad | andromeda-galaxy: yes, the solids-simple and solids regressions set perspective mode |
| 15:57.13 | andromeda-galaxy | brlcad: oh, good to know, thanks! I don't know why I didn't see that when grepping regress/run.sh... |
| 15:58.05 | brlcad | they set perspective via a script |
| 15:58.42 | andromeda-galaxy | brlcad: ahh, that must be it --- thanks |
| 15:59.18 | Notify | 02GCI:rohit_agarwal * 5867661997113344 : None - the quality of logo has degraded a little |
| 16:00.22 | andromeda-galaxy | brlcad: also, I'm mildly worried that this whole set of changes is going to create at least a small increase in rt line count, since it has to running the gen_* functions, whereas before it just calculated point... is that acceptable? |
| 16:00.53 | brlcad | wow, that's just great ... there's a new intrusion botnet that tries a distributed crack |
| 16:01.04 | brlcad | ``Erik: pain-in-the-ass |
| 16:01.26 | brlcad | time to get denyhosts actually using the ips it wants to block... :) |
| 16:01.39 | brlcad | mentally shelves that task for later today |
| 16:02.02 | brlcad | andromeda-galaxy: it has to be justifiable |
| 16:02.34 | brlcad | andromeda-galaxy: e.g., and worrying about a few lines here or there isn't the issue .. especially if it improves readability or modularity |
| 16:02.46 | andromeda-galaxy | brlcad: that makes sense... |
| 16:02.59 | andromeda-galaxy | I think that there are currently two things causing it to expand somewhat |
| 16:03.07 | brlcad | from what I saw in the first patch, though, that wasn't the case .. there was a couple dozen lines of code added that looked like maybe remarshalling of data |
| 16:03.21 | andromeda-galaxy | brlcad: the calling sequence for gen_rect? |
| 16:03.26 | andromeda-galaxy | that's the bit that I'm most worried about as well |
| 16:03.44 | brlcad | that's a net negative and might indicate the container api is maybe not right |
| 16:03.54 | andromeda-galaxy | but I think that the best way to fix it is to revisit using an array instead of a bu_list for the gen_* results |
| 16:04.31 | brlcad | I'd suggest first just getting an actual line count, then looking at where the lines are extra/added .. and just ask yourself why and then ask what *could* you do about it and think if it'd be worth it |
| 16:05.06 | brlcad | frankly, the caller probably shouldn't be so tightly coupled with a data type |
| 16:05.20 | brlcad | the API should probably handle it as a ray set and have an accessor/iterator |
| 16:05.39 | andromeda-galaxy | brlcad: that's true, and it would make it really easy to support |
| 16:05.41 | brlcad | so under the hood it can be a list or array or whatever, and what's handed to the caller is simple (e.g., an array) |
| 16:05.44 | andromeda-galaxy | the streaming/generator model from before |
| 16:05.50 | andromeda-galaxy | *that we discussed before |
| 16:06.14 | brlcad | it's related to streaming, but how it shakes out isn't so strictly needing to be a streaming API |
| 16:06.19 | andromeda-galaxy | of course, as long as the underlying data structure is a linked list, the api around it will never be able to *efficiently* give random access.. |
| 16:07.15 | andromeda-galaxy | brlcad: right, it's just that those apis could be set up to access the (opaque) data structure in any way they wanted, including on-demand generation and caching or some such |
| 16:07.54 | ``Erik | if the underlying data structure is appropriately encapsulated, the data structure can be changed if needed... |
| 16:08.18 | andromeda-galaxy | brlcad: what do you think of my going ahead with getting perspective working for now, then looking at it and seeing if this is still a problem (which itt probably will be) and then trying to implement encapsulating apis for the bundles? |
| 16:08.29 | ``Erik | brlcad: what's a pita, the distributed crack attempt, denyhost going nuts, or ya just calling me one? :D |
| 16:09.31 | ``Erik | brlcad: I tried restarting the denyhosts daemon to see if that'd do the trick, it did not. Not sure why it'd start now, the program was last written aug30 |
| 16:10.02 | andromeda-galaxy | ``Erik: indeed... the problem is that the current api just returns a bu_list and there aren't any functions to access rays, it expects the caller to walk them... |
| 16:14.14 | ``Erik | hm, what about making a second function that fills an array? then uses could be migrated to the new approach one at a time? |
| 16:15.09 | andromeda-galaxy | ``Erik: there aren't that many functions, so it wouldn't be too hard to do it to all of them at once, the big problem is (for the older functions) deprecation policy |
| 16:15.31 | andromeda-galaxy | which I already ran into when trying to move rt_raybundle_maker off of the old rt_shootray_bundle() api |
| 16:15.46 | andromeda-galaxy | the newer functions haven't been released yet, so they're fine |
| 16:17.32 | andromeda-galaxy | but since rt is only using the newer functions (right now, at least), it might make sense to make the new api (with better-encapsulated functions) and convert at least those two to use it |
| 16:17.37 | andromeda-galaxy | and then one-by-one try to convert the rest |
| 16:22.35 | ``Erik | fun, libbu fails on osX.10 with ntohll redef http://paste.lisp.org/display/145211 |
| 16:25.01 | andromeda-galaxy | ``Erik: what do you think of that approach} |
| 16:25.03 | andromeda-galaxy | ? |
| 16:26.37 | brlcad | ``Erik: distributed cracking <= pita |
| 16:26.54 | ``Erik | andromeda-galaxy: it sounds like we're violently agreeing? :D |
| 16:27.07 | brlcad | just one or two attempts from dozens/hundreds of different IPs |
| 16:27.23 | andromeda-galaxy | ``Erik: I think so :D |
| 16:28.08 | andromeda-galaxy | last -clear |
| 16:28.31 | andromeda-galaxy | sorry, irssi cmd with a missing / |
| 16:28.41 | ``Erik | brlcad: yeah, is it worth changing the listening port or something until it blows over? finding a blacklist would be nice... |
| 16:29.58 | brlcad | denyhost gets them when they attempt an admin account |
| 16:30.15 | ``Erik | andromeda-galaxy: have you looked at "trackbar.pl"? it's an irssi mod that helps figure out where to start reading from :) change windows and it'll put a bar where it was, then change back after a whiel and scroll up to find the bar... magic! |
| 16:30.37 | andromeda-galaxy | ``Erik: I did see that, I keep meaning to either install it or write my own |
| 16:30.57 | ``Erik | brlcad: so we're taking the "grit your teeth and weather it" approach... |
| 16:31.14 | andromeda-galaxy | since sometimes I have a number of tmux windows connected, it would be nice to have an approach that kept track of the number of 'readers' currently looking at any window |
| 16:31.20 | andromeda-galaxy | and interpeted tmux lock events as leaving |
| 16:33.18 | ``Erik | tmux is good stuff, too :) only problem is when you use it with a lot of scroll on a mac using an xquartz xterm, it gets really sluggish. I moved to Terminal.app because of that. Otherwise, it tromps screen |
| 16:33.48 | andromeda-galaxy | ``Erik: I've only been using it on linux, so I haven't noticed that, but I do generally like it better than screen (which I used to use) |
| 16:34.49 | ``Erik | yeah, it takes a very specific set of circumstances to get that issue to crop up... it works great with xterms on linux, fbsd, console on both, putty on windows |
| 16:35.12 | andromeda-galaxy | ``Erik: interesting... have you made a bug report? |
| 16:35.45 | ``Erik | nah, not sure if it's a tmux or xquartz (or xorg) issue |
| 16:35.53 | andromeda-galaxy | ahh, true.. |
| 16:37.29 | ``Erik | xterm was the last thing keeping X running on my macbook, so I bit the bullet and configured terminal.app to not suck, problem routed around :) |
| 16:37.46 | andromeda-galaxy | that makes sense |
| 16:45.41 | Notify | 03BRL-CAD:carlmoore * 63937 brlcad/trunk/doc/docbook/system/man1/en/pixborder.xml: revise comments about default portion of image |
| 16:57.01 | *** join/#brlcad nmz787_i (~nmccorkx@192.55.54.36) |
| 17:00.43 | *** join/#brlcad raptor_ (~raptor@213.222.229.229) |
| 17:11.20 | Notify | 02GCI:thevk * 5340178071683072 : Ready for review - The work on this task is ready to be reviewed. |
| 17:20.45 | starseeker | ``Erik: does that mean you've got the native aqua build of BRL-CAD working on Mac? :-P |
| 17:25.54 | Notify | 03BRL-CAD:carlmoore * 63938 brlcad/trunk/doc/docbook/system/man1/en/pixhalve.xml: remove 'both' and combine 2 sentences |
| 17:32.43 | Notify | 03BRL-CAD:carlmoore * 63939 brlcad/trunk/doc/docbook/system/man1/en/pixhalve.xml: move period |
| 18:12.19 | ``Erik | starseeker: brlwhat? |
| 18:15.46 | andromeda-galaxy | ``Erik: just in case vmath already has a function for this that I can't find: |
| 18:15.51 | ``Erik | hasn't compiled BRL-CAD on his laptop since... aug08 |
| 18:16.29 | andromeda-galaxy | is there an easy way to compute the term k such that normalize(normalize(a+b+c)-k) = normalize(a+b)? |
| 18:17.02 | ``Erik | woops, wrong machine, aug04 |
| 18:18.22 | andromeda-galaxy | ``Erik: figuring that out is currently annoying my efforts to make perspective rendering use gen_frustum(), since gen_frustum takes an angle and a vector and normalizes the vector result internally... which makes sense for it's usual use case, but is a pain for rt |
| 18:18.52 | ``Erik | andromeda-galaxy: dunno, but wouldn't k be a set of possible values, one of those being =c? |
| 18:19.27 | andromeda-galaxy | hmm... I don't think so, because of the normalizatoin |
| 18:19.31 | andromeda-galaxy | *normalization |
| 18:19.36 | andromeda-galaxy | let me grab a concrete example quicky |
| 18:19.38 | andromeda-galaxy | *quickly |
| 18:19.56 | ``Erik | not sure why you'd need that computation, generating rays given a frustum is pretty straight forward |
| 18:20.36 | andromeda-galaxy | gen_frustum needs the center of the grid and the angle, I'm having trouble reverse-engineering the angle to give it from width/height... |
| 18:21.05 | andromeda-galaxy | (and I've tried using rt_perspective/aspect*rt_perspective, but that's not workign correctly, so I wanted to try it this way and see if it gave me more information about what's wrong) |
| 18:23.06 | andromeda-galaxy | ``Erik: see what I mean? |
| 18:24.40 | ``Erik | wouldn't the angle between the center of the grid and the edge be rt_perspective/2.0 ? I'm not sure what number you're looking for... |
| 18:26.04 | andromeda-galaxy | ``Erik: I'm not sure if there are some off-by-one errors or not, so I wanted to try to get the angle from the atan of the width/height instead and compare it |
| 18:26.32 | Notify | 03BRL-CAD:carlmoore * 63940 brlcad/trunk/doc/docbook/system/man1/en/pixmorph.xml: in pixmorph.xml , do not underscore punctuation, and place right parentheses properly, and add a new comma |
| 18:27.36 | ``Erik | could always tweak the existing code to printf what you want and do comparisons against that, right? |
| 18:29.04 | andromeda-galaxy | ``Erik: well, that's the problem --- I'm trying to figure out what to print... |
| 18:29.21 | ``Erik | (or just shove your code in and run the benchmark regression stuff and see if the result image is 'right', should let you know if you're wrong pretty quickly... not necessarily if you're right, but ...) |
| 18:30.18 | andromeda-galaxy | it's definitely wrong, I'm just trying to figure out *why* it's wrong |
| 18:33.17 | andromeda-galaxy | ``Erik: it's a really annoying kind of wrong, becauase by the end the cumalitive error is still < 0.001 |
| 18:33.21 | andromeda-galaxy | (in pixel coordinates) |
| 18:36.08 | ``Erik | huh, I d'no, that sounds like it could just be plain old floating point fuzz from doing a different order of operations... it could be that if you did the two calculations with infinite precision, they'd come up the same... and it could even be that the existing approach is MORE divergant than your new one. |
| 18:36.46 | andromeda-galaxy | ``Erik: I know, that's why errors at that level are so annoying for me... |
| 18:37.00 | andromeda-galaxy | *I find errors ... |
| 18:37.38 | andromeda-galaxy | and, of course, since the difference is in the *coordinates* and not the actual computed value, it makes regress* fail catastrophically |
| 18:38.29 | ``Erik | well, I'd wait for brlcad to weight in, it might be irrelevant... if it's really bugging you, what about implementing the two approaches using something with better numbers (mathematica, maple, commonlisp/scheme, java bignum, libgmp, etc) and see how close THOSE are, then how close the ieee754 approaches come to the arbitrary precision approaches? |
| 18:39.06 | andromeda-galaxy | ``Erik: that might work.. well, thanks for the advice! I'll try checking a couple of intermediate results quickly as well to see if I can easily eliminate it |
| 18:39.31 | ``Erik | aight, good luck |
| 18:40.05 | ``Erik | <-- thought the error was small enough that regress passed |
| 18:48.37 | andromeda-galaxy | ``Erik: no, the problem I was having is that it is really small, just not quite small enough |
| 18:49.07 | andromeda-galaxy | I think it's probably that because the difference is in the coordinates, it can cause a (relatively) large fluctuation in pixel values |
| 18:49.19 | andromeda-galaxy | though to a human eye it still looks pretty similar |
| 18:53.10 | Notify | 03BRL-CAD:carlmoore * 63942 (brlcad/trunk/src/util/pixembed.c brlcad/trunk/src/util/pixmerge.c): in 2 utilities, implement h? for help; this necessitated ending a -h for high-res |
| 19:36.27 | andromeda-galaxy | brlcad: what do you think about this one? the error appears to be cumulative, and by the end of a 512x512px run, it is ~0.0005... |
| 19:52.39 | andromeda-galaxy | brlcad, ``Erik: I'm pretty sure that the ``error'' stems from the fact that gen_frustum() scales the vector that was passed in (viewbase_model - eye-model) to be unit and then adds equivalent numbers determined from the angle, as opposed to the main code which does everything with bigger vectors and then normalizes at the end |
| 19:55.37 | *** join/#brlcad raptor_ (~raptor@213.222.229.229) |
| 20:11.07 | *** join/#brlcad teepee (~teepee@gateway/tor-sasl/teepee) |
| 20:13.21 | *** join/#brlcad teepee (~teepee@gateway/tor-sasl/teepee) |
| 20:21.56 | Stragus | andromeda-galaxy, indeed. Adding x repeatedly to a number is less accurate than multiplying right away |
| 20:22.27 | andromeda-galaxy | Stragus: I just tried another version that comes up with int j/i and multiplies them, |
| 20:22.32 | andromeda-galaxy | but it is still slightly less accurate |
| 20:22.35 | andromeda-galaxy | probably due to the scaling... |
| 20:29.25 | ``Erik | ieee754 numbers tend to behave best if you can try to keep them close to the 1.0-2.0 range... they get fuzzier as you get really really big or really really small |
| 20:30.09 | ``Erik | there're a few papers in the "what every programmer should know about ieee754" or floating point or 854 or ... |
| 20:31.00 | ``Erik | here's one http://docs.oracle.com/cd/E19957-01/806-3568/ncg_goldberg.html |
| 20:32.03 | Stragus | It's more a matter of understanding mantissa and exponent than keeping to the 1.0-2.0 range... |
| 20:32.37 | Stragus | Precision is the same everywhere over the normal range, it's just a matter of scale |
| 20:32.52 | andromedagalaxy | ``Erik, Stragus: indeed! In a few more minutes , I'll try a couple of alternative computations... |
| 20:32.58 | Stragus | (plus denormals and other quirks to know about) |
| 20:34.07 | ``Erik | Stragus: yeh, but if you want an easy rule of thumb, I find the 1-2 idea to be a decent heuristic :) |
| 20:34.53 | ``Erik | (damn, pedantry is annoying when I'm not the pedant *cough* O:-) ) |
| 20:39.01 | andromeda-galaxy | ``Erik, Stragus: the simplist thing that I'll start by doing is just delaying the VUNITIZE() call, because even though that results in working with larger numbers (5000), it's what the old rt coode does |
| 20:39.26 | ``Erik | 5000 is still pretty small, should be fine |
| 20:41.07 | andromeda-galaxy | ``Erik: that was my thought as well |
| 20:51.07 | andromeda-galaxy | ``Erik, Stragus: any idea how close pixdiff needs things to be to comparea correctly? |
| 20:52.37 | andromeda-galaxy | ``Erik, Stragus: the pixel *coordinates* (no idea about the values though) are now within 0.0003 of each other by the end of a 512x512 raaytrace |
| 21:00.06 | andromeda-galaxy | except that that made the *beginning* coordinates go 0.0004 out of sync with each other... |
| 21:00.34 | Notify | 02GCI:deep10 * 5222964656078848 : Task Claimed - I would like to work on this task. |
| 21:02.15 | raptor_ | All a good night! |
| 21:09.59 | andromeda-galaxy | ``Erik: are you still here? |
| 21:19.24 | andromeda-galaxy | it looks like the problem is that when you tell rt to trace a 512x512 grid with angle theta, it actually does the equivalent of traacing a 513x513 grid and throwing away the topmost row and rightmost column |
| 21:19.28 | andromeda-galaxy | this is, to say the least, problematic |
| 21:21.52 | ``Erik | andromeda-galaxy: that is... interesting. this behavior is old? |
| 21:22.09 | andromeda-galaxy | ``Erik: I think so... it seems to be being confirmed by the tests |
| 21:22.12 | ``Erik | source code to microsoft basic from '78: http://www.pagetable.com/?p=774 |
| 21:22.19 | andromeda-galaxy | there's a similar issue with orthogonal rays, it always uses half-open sets |
| 21:22.33 | andromeda-galaxy | it traces on the boundary for the left/lower sides, but not for the right/upper |
| 21:23.23 | ``Erik | andromeda-galaxy: have you tried emulating the +1 behavior in your code to see if it "fixes" things? |
| 21:23.50 | andromeda-galaxy | ``Erik: At one point, at least, I had it tracing using the grid of width+1/height+1 rays |
| 21:23.56 | andromeda-galaxy | and for the first scanline everything was perfect |
| 21:24.13 | andromeda-galaxy | but then the last pixel of that scanline was rendered as the first of the next, and everything broke |
| 21:24.37 | ``Erik | heh, slanted? what about width/height+1 ? |
| 21:26.09 | andromeda-galaxy | ``Erik: hmm... the problem is that it does the spacing as if it was width+1/height+1 |
| 21:27.03 | andromeda-galaxy | also, something else has suddenly stopped working while trying to fix that issue, now it goes wrong halfway trhough the first scanlinei... |
| 21:28.38 | ``Erik | has a feeling that this has crept beyond the appropriate scope :/ |
| 21:29.19 | andromeda-galaxy | hmm? |
| 21:31.21 | andromeda-galaxy | ``Erik: I think it may be that the originala way that rt worked was that it divided the view into NxN cells, and sampled the lower left corner of each cell |
| 21:31.42 | andromeda-galaxy | that naturally caused this behavior, which is now being a real pain to make work with code that doesn't sample that way |
| 21:33.11 | *** join/#brlcad merzo (~merzo@214-60-132-95.pool.ukrtel.net) |
| 21:34.29 | *** join/#brlcad mpictor (~mark@c-69-136-183-213.hsd1.in.comcast.net) |
| 21:34.29 | *** join/#brlcad javampire (~javampire@v10024.1blu.de) |
| 21:34.29 | *** join/#brlcad starseeker (~starseeke@66-118-151-70.static.sagonet.net) |
| 21:34.29 | *** join/#brlcad ries (~ries@D979C47E.cm-3-2d.dynamic.ziggo.nl) |
| 21:34.29 | *** join/#brlcad unicodesnowman (~unicodesn@unaffiliated/unicodesnowman) |
| 21:35.48 | *** join/#brlcad teepee (~teepee@gateway/tor-sasl/teepee) |
| 21:37.00 | andromeda-galaxy | ``Erik: now this brings usback to my original concerns about trying to get angle from width/height instead of rt_perspective; doing so would allow adjusting the values to maake everything work (hopefully) |
| 21:37.33 | *** join/#brlcad n_reed (~molto_cre@66-118-151-70.static.sagonet.net) |
| 21:41.37 | *** join/#brlcad n_reed (~molto_cre@66-118-151-70.static.sagonet.net) |
| 21:41.37 | *** join/#brlcad teepee (~teepee@gateway/tor-sasl/teepee) |
| 21:41.37 | *** join/#brlcad unicodesnowman (~unicodesn@unaffiliated/unicodesnowman) |
| 21:41.37 | *** join/#brlcad ries (~ries@D979C47E.cm-3-2d.dynamic.ziggo.nl) |
| 21:41.37 | *** join/#brlcad starseeker (~starseeke@66-118-151-70.static.sagonet.net) |
| 21:41.37 | *** join/#brlcad javampire (~javampire@v10024.1blu.de) |
| 21:41.37 | *** join/#brlcad mpictor (~mark@c-69-136-183-213.hsd1.in.comcast.net) |
| 21:41.37 | *** join/#brlcad merzo (~merzo@214-60-132-95.pool.ukrtel.net) |
| 21:41.37 | *** join/#brlcad kintel (~kintel@unaffiliated/kintel) |
| 21:41.37 | *** join/#brlcad andromedagalaxy (~andromeda@108-225-17-54.lightspeed.sntcca.sbcglobal.net) |
| 21:41.37 | *** join/#brlcad mihaineacsu (~mihaineac@92.85.10.174) |
| 21:41.37 | *** join/#brlcad Notify (~notify@66-118-151-70.static.sagonet.net) |
| 21:41.37 | *** join/#brlcad archivist (~archivist@host81-149-189-98.in-addr.btopenworld.com) |
| 21:41.37 | *** join/#brlcad FreezingCold (~FreezingC@135.0.41.14) |
| 21:41.37 | *** join/#brlcad krishna_ (~krishna@5.231.52.94) |
| 21:41.37 | *** join/#brlcad KimK (~Kim__@ip68-102-30-143.ks.ok.cox.net) |
| 21:41.37 | *** join/#brlcad ignacio (~IgnacioUy@unaffiliated/ignaciouy) |
| 21:41.37 | *** join/#brlcad Stragus (~alexis@modemcable090.29-19-135.mc.videotron.ca) |
| 21:41.37 | *** join/#brlcad gcibot (ignacio@unaffiliated/ignaciouy/bot/gcibot) |
| 21:41.37 | *** join/#brlcad maths22 (~maths22@66-118-151-70.static.sagonet.net) |
| 21:41.37 | *** join/#brlcad nmz787 (~nmz787@unaffiliated/nmz787) |
| 21:41.37 | *** join/#brlcad ankesh11 (uid8015@gateway/web/irccloud.com/x-uugahetzbpoxylmz) |
| 21:41.37 | *** join/#brlcad jrullman (sid54856@gateway/web/irccloud.com/x-wsrkvdskqbtgyhmp) |
| 21:41.37 | *** join/#brlcad mikolalysenko_ (sid34553@gateway/web/irccloud.com/x-uhznlmmvyknypwsf) |
| 21:41.37 | *** join/#brlcad ejno (~ejno@unaffiliated/kazaik) |
| 21:41.37 | *** join/#brlcad brlcad (~sean@66-118-151-70.static.sagonet.net) |
| 21:41.37 | *** join/#brlcad Ch3ck (~Ch3ck@66-118-151-70.static.sagonet.net) |
| 21:41.38 | *** join/#brlcad yiyus_ (1242712427@je.je.je) |
| 21:41.38 | *** join/#brlcad hsrai (~hsrai@66-118-151-70.static.sagonet.net) |
| 21:41.38 | *** join/#brlcad andromeda-galaxy (~andromeda@108-225-17-54.lightspeed.sntcca.sbcglobal.net) |
| 21:41.38 | *** join/#brlcad ChanServ (ChanServ@services.) |
| 21:41.38 | *** join/#brlcad kanzure (~kanzure@unaffiliated/kanzure) |
| 21:41.38 | *** join/#brlcad ``Erik (~erik@pool-74-103-94-19.bltmmd.fios.verizon.net) |
| 21:41.38 | *** mode/#brlcad [+o ChanServ] by verne.freenode.net |
| 21:43.45 | Notify | 02GCI:ngenius * 4639899508539392 : Task Claimed - I would like to work on this task. |
| 21:43.47 | Notify | 02GCI:ngenius * 4639899508539392 : Claim Removed - The claim on this task has been removed, someone else can claim it now. |
| 21:43.50 | *** join/#brlcad maths22 (~maths22@66-118-151-70.static.sagonet.net) |
| 21:50.32 | *** join/#brlcad KimK (~Kim__@ip68-102-30-143.ks.ok.cox.net) |
| 21:50.32 | *** join/#brlcad ignacio (~IgnacioUy@unaffiliated/ignaciouy) |
| 21:50.32 | *** join/#brlcad ankesh11 (uid8015@gateway/web/irccloud.com/x-uugahetzbpoxylmz) |
| 21:50.32 | *** join/#brlcad jrullman (sid54856@gateway/web/irccloud.com/x-wsrkvdskqbtgyhmp) |
| 21:53.44 | *** join/#brlcad archivist (~archivist@host81-149-189-98.in-addr.btopenworld.com) |
| 21:53.44 | *** join/#brlcad Stragus (~alexis@modemcable090.29-19-135.mc.videotron.ca) |
| 21:53.44 | *** join/#brlcad gcibot (ignacio@unaffiliated/ignaciouy/bot/gcibot) |
| 21:53.44 | *** join/#brlcad ejno (~ejno@unaffiliated/kazaik) |
| 21:53.49 | *** join/#brlcad Ch3ck (~Ch3ck@66-118-151-70.static.sagonet.net) |
| 21:54.33 | *** join/#brlcad andromeda-galaxy (~andromeda@108-225-17-54.lightspeed.sntcca.sbcglobal.net) |
| 21:54.33 | *** join/#brlcad kanzure (~kanzure@unaffiliated/kanzure) |
| 21:54.33 | *** join/#brlcad ``Erik (~erik@pool-74-103-94-19.bltmmd.fios.verizon.net) |
| 21:55.08 | *** join/#brlcad kanzure (~kanzure@unaffiliated/kanzure) |
| 21:56.49 | *** join/#brlcad jrullman (sid54856@gateway/web/irccloud.com/x-luqkfudqyuvbixlj) |
| 21:59.24 | *** join/#brlcad mihaineacsu (~mihaineac@92.85.10.174) |
| 21:59.24 | *** join/#brlcad Notify (~notify@66-118-151-70.static.sagonet.net) |
| 21:59.24 | *** join/#brlcad nmz787 (~nmz787@unaffiliated/nmz787) |
| 21:59.24 | *** join/#brlcad yiyus_ (1242712427@je.je.je) |
| 22:00.14 | *** join/#brlcad FreezingCold (~FreezingC@135.0.41.14) |
| 22:01.17 | Notify | 03BRL-CAD:starseeker * 63943 brlcad/trunk/db/CMakeLists.txt: Add public FAA models as fastgen db files. |
| 22:06.12 | *** join/#brlcad jrullman (sid54856@gateway/web/irccloud.com/x-luqkfudqyuvbixlj) |
| 22:06.12 | *** join/#brlcad KimK (~Kim__@ip68-102-30-143.ks.ok.cox.net) |
| 22:06.13 | *** join/#brlcad ignacio (~IgnacioUy@unaffiliated/ignaciouy) |
| 22:06.13 | *** join/#brlcad ankesh11 (uid8015@gateway/web/irccloud.com/x-uugahetzbpoxylmz) |
| 22:09.25 | *** join/#brlcad jrullman (sid54856@gateway/web/irccloud.com/x-lbvkmulohstfariz) |
| 22:47.39 | ``Erik | brlcad: seen https://stribika.github.io/2015/01/04/secure-secure-shell.html ? |
| 22:53.57 | andromeda-galaxy | pixdiff output on solids is down to 24 by 1, 6 by many... |
| 22:58.16 | andromeda-galaxy | I have now discovered that the regression tests will fail if certain pixel coordinates are off by 2e-8 |
| 23:04.05 | andromeda-galaxy | there are now thirty pixels failing regression, all of which seem to have coordinates that differ by only something like 1e-7 (apparently not cumulative) |
| 23:15.42 | Notify | 02GCI:martizor56 * 4958060736937984 : Task Claimed - I would like to work on this task. |
| 23:30.05 | Notify | 02GCI:o7p9bxbnyj * 6466077978525696 : status - This patch includes the changes from the last task (since those were definitely not ready for production) and adds another 5.75-6hrs work which... |
| 23:30.10 | Notify | 02GCI:o7p9bxbnyj * 6466077978525696 : Ready for review - The work on this task is ready to be reviewed. |
| 23:30.45 | andromeda-galaxy | brlcad: status report on rt-using-ray bundles: everything nearly works, but there are a couple of problems (which I outlined in the task); if you create a #3 task I'll happily fix them now, or I can do them post-GCI |