| 01:35.20 | yukonbob | hello, cadheads |
| 01:35.55 | starseeker_ | howdy |
| 01:35.59 | starseeker_ | read read read... |
| 01:39.34 | starseeker_ | pacman87: Heh - when I see L6 I always think of Howard Clark's L6 katana blades: http://swordforum.com/summer99/howardclark.html |
| 01:39.38 | yukonbob | is "read read read..." what you're doing, or what I should do? |
| 01:39.44 | starseeker_ | what I'm doing |
| 01:41.24 | brlcad | howdy yukonbob |
| 01:41.30 | brlcad | hasn't started the read read yet |
| 01:46.17 | yukonbob | howdy brlcad :) |
| 01:47.53 | brlcad | pacman87: awesome new pics .. got negative quadrants working now it seems |
| 01:48.11 | brlcad | at least first and third |
| 01:49.28 | pacman87 | brlcad: they're all working, of a sort |
| 01:49.40 | pacman87 | the problem is with overlapping geometry |
| 01:50.07 | pacman87 | if you have + and - sides of a sketch, you're fine unless you try to go more than 180 degrees |
| 01:50.20 | pacman87 | then it ends up as an XOR-type thing |
| 01:50.36 | brlcad | treat it like a union |
| 01:51.23 | brlcad | so if you have 1,1->1,-1 and -1,.5->-1,-.5 .. you get a cylinder |
| 01:51.40 | brlcad | I see them as sweeping solid space |
| 01:52.04 | brlcad | that smaller left side shouldn't both create material and carve out the right me thinks |
| 01:52.44 | pacman87 | ok, that will require more condition handling for sketches over 180 degrees |
| 01:54.28 | brlcad | seemed like it should simplify things |
| 01:54.53 | pacman87 | no, because i'll have to determine which surfaces to ignore |
| 01:55.08 | brlcad | since that's the same as treating the -x as the same as a +x curve, just only for half |
| 01:55.32 | brlcad | do left and right independently, then you can merge your segment lists for the result |
| 01:56.09 | brlcad | just have to trim all curves that cross from + to - x |
| 01:56.43 | brlcad | at least it's a thought, it's the thought that counts right? :) |
| 01:57.22 | pacman87 | i'm already finding the angle for each hitpoint to determine whether it's valid |
| 01:58.04 | brlcad | just seems to me like it should make things simpler .. at least over xor'ing |
| 01:58.13 | pacman87 | i'm not doing anythign special to XOR |
| 01:58.18 | pacman87 | it just happens naturally |
| 01:58.51 | brlcad | unless you go over 180 |
| 01:59.04 | pacman87 | no, only if you go over 180 |
| 01:59.16 | brlcad | then what's the problem? :) |
| 01:59.22 | pacman87 | if it's under 180 the + and - sides dont' interfere |
| 02:00.42 | pacman87 | in this image: https://webspace.utexas.edu/trv82/www/rev_rt20.png |
| 02:00.58 | pacman87 | the holes are caused because the top and bottom surface are traced twice |
| 02:01.12 | pacman87 | once for +, once for - |
| 02:01.27 | brlcad | g'dammit .. that utexas.edu server sends the wrong mime type every so often |
| 02:01.40 | pacman87 | um... sorry? |
| 02:01.42 | brlcad | really wierd/craptastic |
| 02:01.53 | brlcad | it spews the png data as binary into the browser |
| 02:01.58 | *** join/#brlcad Twingy (n=justin@74.92.144.217) |
| 02:01.59 | pacman87 | fun |
| 02:02.07 | brlcad | till something resets, and it's fine |
| 02:02.08 | pacman87 | that's the lynx compatibality mode |
| 02:02.12 | pacman87 | ;) |
| 02:02.49 | pacman87 | anyway, the curved hole surfaces are from valid hits on the - side |
| 02:02.53 | brlcad | so what am I looking at in 20? what's the sketch? |
| 02:03.01 | pacman87 | two vertical lines |
| 02:03.08 | pacman87 | one at -4, the other at +8 |
| 02:03.14 | pacman87 | from -1 to 1 in y |
| 02:03.25 | pacman87 | it's 270 degrees |
| 02:04.24 | brlcad | huh? i'm missing a coordinate or a reference frame |
| 02:04.31 | brlcad | "at -4" .. |
| 02:04.45 | brlcad | and what way is the image oriented |
| 02:04.57 | pacman87 | ae -135 60 |
| 02:05.14 | pacman87 | so +z is up through the center |
| 02:05.18 | *** join/#brlcad cerrayo (n=cerrayo@c-67-160-127-173.hsd1.wa.comcast.net) |
| 02:05.25 | pacman87 | +x is upper right |
| 02:05.32 | pacman87 | going away |
| 02:06.21 | pacman87 | you want the .g to play with? |
| 02:07.51 | pacman87 | https://webspace.utexas.edu/trv82/www/neg3.g |
| 02:09.05 | brlcad | arg, I don't have a recent compile .. this might take a bit |
| 02:10.11 | brlcad | does a g2asc and sees the values anyways |
| 02:10.59 | brlcad | {-4 -1} {-4 1} {8 -1} {8 1} helps ;) |
| 02:12.57 | poolio | brlcad: Holy cow it is pouring :P |
| 02:13.07 | brlcad | nay a drop here :) |
| 02:13.40 | poolio | Heh, it was the same way when you had rain and I didn't last night. I just got home and the roads were crazy...a lot of lights were out and a few roads were flooded out |
| 02:15.47 | pacman87 | https://webspace.utexas.edu/trv82/www/rev_rt20b.png |
| 02:16.13 | pacman87 | added coord axes: z=black; x=red; y=green; |
| 02:16.37 | brlcad | heh, did you manually draw that? :) |
| 02:16.41 | pacman87 | yeah :) |
| 02:16.47 | brlcad | thanks, I figured that much |
| 02:18.09 | brlcad | what bothers me about that is the first 90 on the -x side (third quadrant |
| 02:18.40 | pacman87 | the bottom hole? |
| 02:18.48 | brlcad | since if you just had -4,-1->-4,1 that would be filled in .. |
| 02:18.51 | brlcad | yes |
| 02:19.22 | pacman87 | but the +x side from 180 to 270 overlaps that |
| 02:19.30 | pacman87 | giving zero-length hit segments |
| 02:19.34 | pacman87 | which are ignored |
| 02:19.36 | brlcad | likewise, the fact that 2nd quadrant is filled, I'd expect that to be open |
| 02:20.14 | pacman87 | quad II is only swept once |
| 02:20.32 | pacman87 | by the + side only |
| 02:20.45 | pacman87 | quad IV is only swept by the - side |
| 02:20.47 | brlcad | ah, right right |
| 02:22.14 | pacman87 | i'm assuming you still want it fixed (ie, holes filled in) |
| 02:23.14 | brlcad | i could be convinced either way really since it's sort of an "exceptional use" I think |
| 02:24.15 | brlcad | just seems to ask for issues .. e.g. what does 1,1->-1,-1 and -1,1->1,-1 give you (i.e. an X) |
| 02:24.30 | brlcad | nothing? two cylinders? |
| 02:24.40 | pacman87 | if it's symmetric, you get nothing from a 360 revolve |
| 02:25.52 | pacman87 | for a 180 degree, you'd get two cones |
| 02:26.29 | pacman87 | a 270 would look the same as a -90 |
| 02:38.07 | brlcad | trying to think of a case where that's actually useful |
| 02:39.35 | brlcad | (where either union or xor is more desired) |
| 02:40.02 | pacman87 | xor is faster, as it requires no additional tests/code |
| 02:40.14 | pacman87 | at least the way i have it coded now |
| 02:43.09 | brlcad | hm, there is one benefit of xor |
| 02:43.28 | *** join/#brlcad PrezKennnedy (i=Matthew@whitecalf.net) |
| 02:45.14 | brlcad | with the union approach, you can obviously get the same result (with a 360) by using |x| for your curve or by unioning two separate revolves with |x| and ofsetting one 180 |
| 02:46.01 | *** join/#brlcad andrecastelo_ (n=chatzill@189.71.12.88) |
| 02:46.06 | brlcad | with xor, there are some shapes that you cannot get |
| 02:46.22 | brlcad | at least not without subtractions and only performing partial rotations, etc |
| 02:46.41 | brlcad | a bit more complicated |
| 02:47.09 | Ralith | union seems a lot more intuitive |
| 02:51.13 | poolio | brlcad: will I be seeing you tomorrow? :) |
| 02:51.44 | brlcad | Ralith: can you think of a shape where you'd intentionally model the revolve curve over into -x though and expect/need that unioned result |
| 02:51.57 | brlcad | poolio: heh |
| 03:02.03 | Ralith | brlcad: well, say you wanted a disk with a ridge extending out for 270 degrees, but absent for the rest |
| 03:02.42 | Ralith | you could rotate a rectangle with a ridge on one end around its center 270 degrees, and if it unioned you'd get that |
| 03:03.27 | Ralith | of course, there are all sorts of other ways to do that |
| 03:03.53 | pacman87 | Ralith: give me 5 min to make that sketch |
| 03:04.16 | Ralith | 5 min? It's a painfully simple sketch :P |
| 03:04.36 | pacman87 | i'm writing the sketch by hand, and doing the math in my head |
| 03:04.39 | pacman87 | i was estimating |
| 03:05.01 | Ralith | say, 1,1 -> 1,-1 -> -1,-1 -> -2,0 -> -1,1 -> 1,1 |
| 03:05.23 | Ralith | math? |
| 03:07.54 | pacman87 | Ralith: that won't work |
| 03:08.59 | pacman87 | ...at least not with xor |
| 03:09.34 | Ralith | huh? |
| 03:09.38 | Ralith | that was a union example |
| 03:09.42 | pacman87 | oh |
| 03:09.52 | Ralith | I can't think of a case where you'd want an xor |
| 03:14.16 | pacman87 | if you need a union, split the rev into two parts less than 180 and combine them |
| 03:14.41 | *** join/#brlcad stting (n=stting@c-67-160-127-173.hsd1.wa.comcast.net) |
| 03:14.43 | pacman87 | if you want an XOR, you can't get it if it defaults to a union |
| 03:15.03 | brlcad | you can, it just takes a few more operations |
| 03:15.23 | pacman87 | (A-B) U (B-A) |
| 03:16.55 | *** join/#brlcad stting (n=stting@c-67-160-127-173.hsd1.wa.comcast.net) |
| 03:22.37 | pacman87 | just found a new bug :( |
| 03:23.31 | pacman87 | note to self: when testing shapes, don't always put the center at the origin, and line the vectors up with the axes... |
| 03:26.07 | brlcad | pacman87: another argument against xor approach.. any +x curve rotated beyond 360 would wipe itself out |
| 03:26.36 | brlcad | instead of what I'd intuitively expect where anything >360 == 360 |
| 03:27.41 | pacman87 | no, seperate code path for > 360 |
| 03:30.26 | brlcad | well then that sort of breaks the behavior consistency |
| 03:31.38 | brlcad | i mean that the same reasoning that might result in xor being okay from 180->360 is similar to a +x-only curve for 360->720 |
| 03:34.01 | pacman87 | brlcad: it's still an xor |
| 03:34.19 | pacman87 | but it treats everythign over 360 as 360 exactly |
| 03:35.16 | brlcad | that's my point |
| 03:35.43 | pacman87 | sorry, i'm not seeing what you're trying to say |
| 03:36.08 | brlcad | that "but" case is the only reason it doesn't subtract away, where behaviorally I would expect it to |
| 03:36.54 | brlcad | that is, i would expect it to iff it's using xor behavior |
| 03:37.09 | pacman87 | (10:27:00 PM) brlcad: instead of what I'd intuitively expect where anything >360 == 360 |
| 03:37.17 | brlcad | with xor behavior, 360 != 361 |
| 03:37.43 | brlcad | right, intuitive modeling intent behavior, I would expect >360==360 |
| 03:37.50 | brlcad | but not if it's xor'ing |
| 03:38.13 | pacman87 | it xor's the + and - half of the revolve |
| 03:38.19 | brlcad | i'd expect it to oscillate on/off depending on the angle |
| 03:39.10 | pacman87 | the way to handle >360 would be to rework the start vector and angle behind the scenes |
| 03:39.24 | pacman87 | if you want it to keep xoring |
| 03:40.33 | brlcad | wasn't saying it couldn't be dealt with, just that I would expect it to behave that way if it's going to xor for 180-to-360 angles for -x curves |
| 03:41.25 | brlcad | that said, i'm not seeing the benefit vs. expected behavior still for why you'd specifically want an xor'd result -- some specific meaningful shape |
| 03:41.26 | pacman87 | so you want consistancy |
| 03:41.48 | pacman87 | it doesnt' really matter to me much either way |
| 03:41.58 | pacman87 | i'm just throwing out the options |
| 03:42.10 | pacman87 | so "what i code" == "what you want" |
| 03:42.15 | brlcad | i mean, it could be an option when you create the revolve, could ask which way to behave .. but then that's more work and probably not necessary :) |
| 03:42.23 | brlcad | heh |
| 03:42.49 | brlcad | "what I want" == "everything"! |
| 03:43.37 | pacman87 | does than mean i have to go back and set the universal constanst so that the universe evolves to contain a hard disk with your 'everything'? |
| 03:44.23 | brlcad | yes please |
| 03:45.03 | brlcad | the universe with hookers and blackjack |
| 03:45.09 | brlcad | in fact, forget the universe |
| 03:47.15 | pacman87 | so, final decision = union? |
| 03:47.20 | brlcad | pacman87: see what daniel says about the revolve, but my inclination would probably still by my original assertion that a union behavior is more what I would expect (and overall simpler to account for consistently) |
| 03:48.04 | pacman87 | ok |
| 03:48.55 | brlcad | not to mention a hell of a lot easier to document and explain |
| 03:49.13 | brlcad | if some twisted soul wants xor behavior, he can do the subtractions and union ops himself |
| 03:49.33 | pacman87 | awww, i kinda liked catering to the twisted soul |
| 03:50.05 | brlcad | mm.. sounds like the name of a rock band |
| 03:50.20 | pacman87 | 'catering to the twisted soul'? |
| 03:50.40 | brlcad | yeah or even just 'twisted soul' |
| 03:50.56 | brlcad | longer could be their cover song |
| 03:51.12 | pacman87 | right |
| 03:51.13 | brlcad | waits for punkrockgirl to write and sing it |
| 03:51.27 | pacman87 | i managed a segfault with 'l revolve' |
| 03:51.42 | pacman87 | now i've got 3 bugs to fix |
| 03:53.19 | brlcad | l revolve should be an easy one |
| 03:53.26 | pacman87 | yeah |
| 03:53.36 | pacman87 | i'm pretty sure i know how to fix them all |
| 03:55.39 | pacman87 | i still havent' managed to convince KDE that my monitor is 1680 px wide |
| 03:56.14 | brlcad | still? |
| 03:56.22 | brlcad | that something new? what changed? |
| 03:56.45 | pacman87 | i turned off twinview |
| 03:57.04 | pacman87 | it was giving me trouble playing bzflag :D |
| 03:57.14 | pacman87 | so now i have three seperate X sessoins |
| 03:57.54 | brlcad | heh |
| 03:57.58 | andrecastelo | hey guys |
| 03:58.03 | pacman87 | hi andrecastelo |
| 03:58.04 | brlcad | hello andrecastelo |
| 03:58.12 | andrecastelo | hey pacman87, hey brlcad |
| 03:58.17 | brlcad | andrecastelo: how are the secondary rays coming? |
| 03:59.01 | *** join/#brlcad quentusrex (n=quentusr@c-71-197-244-228.hsd1.or.comcast.net) |
| 03:59.09 | brlcad | don't linger too long on those -- you really need to get into the depths of path tracing soon (which requires secondary rays) |
| 03:59.19 | pacman87 | we should schedule a mentors vs gsocers bzflag match ;) |
| 03:59.23 | andrecastelo | i've been taking a look into rtexample.c and rt_simple.c and the idea is to set a new direction and a new point and fire again, right ? |
| 03:59.37 | brlcad | pretty much |
| 03:59.40 | andrecastelo | and perhaps write another function to handle those secondary rays |
| 03:59.56 | brlcad | look at the new rtexample.c -- i merged the two |
| 04:00.06 | andrecastelo | ok, will svn |
| 04:00.16 | brlcad | same code, just more comments |
| 04:00.26 | andrecastelo | okay |
| 04:00.54 | andrecastelo | rtexample uses a main(), so there's the place to set the new points and directions |
| 04:01.48 | andrecastelo | but which function works like that in a callback way (as is viewmlt.c ) ? i need to look into to which function it goes after it shoots the rays |
| 04:03.25 | brlcad | at least one of the functions in viewmlt.c is basically a callback to rt_shootray() already -- just one that is being called for you by the code that shoots the original primary rays in a grid |
| 04:03.48 | brlcad | inside that callback, you set up a struct application ap for each secondary ray |
| 04:04.03 | brlcad | and call rt_shootray() yourself with your own callback(s) |
| 04:04.49 | andrecastelo | hm, setting up a flag, perhaps, in mlt_app, to ensure no recursion madness (so the secondary rays dont call secondary rays)? |
| 04:05.39 | brlcad | depending on what you need to do, recursion may be desirable |
| 04:05.46 | brlcad | now for shadows, you don't need recursion |
| 04:05.53 | brlcad | but for path-tracing... |
| 04:06.05 | brlcad | that's sort of exactly how basic path tracing works |
| 04:06.50 | brlcad | otherwise, though, you'll only end up with a recursive-potential-infinite-loop if you make your hit/miss callback also call that same hit/miss callback |
| 04:07.11 | brlcad | you wouldn't call the same view callback though for the secondary rays |
| 04:07.27 | andrecastelo | got it, i was misunderstanding |
| 04:07.37 | brlcad | you'd call your own |
| 04:10.35 | Ralith | smacks ogre around a bit with a large abort |
| 04:12.33 | pacman87 | how do i append a bu_vls to another bu_vls? |
| 04:16.20 | brlcad | bu_vls_vlscat() |
| 04:16.37 | pacman87 | where are those? |
| 04:16.52 | brlcad | bu_vls_vlscatzap() if you're done with the one being added |
| 04:17.14 | pacman87 | this is for describe() |
| 04:17.16 | brlcad | they're all in include/bu.h -- but easier to read the documentation in src/libbu/vls.c |
| 04:17.47 | brlcad | it's on my todo to move all docs into the headers, but that's a hell of a lot of work.. :) |
| 04:22.07 | brlcad | wow, the website is getting about 32k hits/day |
| 04:22.20 | pacman87 | which site? |
| 04:22.24 | brlcad | brlcad.org |
| 04:22.27 | pacman87 | impressive |
| 04:22.37 | pacman87 | unique? |
| 04:22.50 | brlcad | no, indiv. requests |
| 04:23.18 | pacman87 | turns on opera auto-reload every 2 seconds |
| 04:23.44 | brlcad | looks like at least in the last 24 hours, 1081 unique IPs |
| 04:24.06 | pacman87 | 32 pages per user average |
| 04:24.29 | brlcad | s/pages/requests/ |
| 04:24.55 | pacman87 | hits != pages ? |
| 04:25.07 | brlcad | first page is about 7 requests |
| 04:25.22 | pacman87 | so, 4.5 pages |
| 04:26.05 | pacman87 | bugcount--; |
| 04:26.13 | pacman87 | fixed the segfault |
| 04:26.13 | brlcad | looks like it |
| 04:26.26 | brlcad | fairly small sample, but interesting nonetheless |
| 04:26.37 | brlcad | ~pacman87++ |
| 04:27.33 | pacman87 | describe was still treating the sketch name as a *char instead of a vls |
| 04:27.56 | pacman87 | ~karma |
| 04:27.56 | ibot | pacman87 has karma of 4 |
| 04:28.06 | pacman87 | thought it was 2... |
| 04:28.38 | pacman87 | not complaining |
| 04:30.06 | brlcad | ~pacman87++ |
| 04:30.34 | brlcad | you know you can get a char* from a vls too, yes? |
| 04:30.39 | brlcad | bu_vls_addr() ftw |
| 04:31.24 | pacman87 | i assumed vls->vls would be better |
| 04:31.32 | pacman87 | rather than vls->char*->vls |
| 04:31.45 | pacman87 | bugcount--; |
| 04:31.55 | pacman87 | now there's one left |
| 04:32.00 | pacman87 | that i know of |
| 04:35.23 | CIA-22 | BRL-CAD: 03pacman87 * r31926 10/brlcad/trunk/src/librt/primitives/revolve/revolve.c: two bugfixes: segfault in describe() due to change from char* to bu_vls; and ignore the start/end planes for full revolves (>360) |
| 04:35.37 | brlcad | 120,224 bytes in 6 files to be exact (on the main page) |
| 04:35.53 | brlcad | oh sure, much better |
| 04:36.07 | pacman87 | hmm? |
| 04:36.12 | brlcad | i just meant in general |
| 04:36.23 | brlcad | using bu_vls_addr() if you need a char* |
| 04:36.31 | pacman87 | ah, ok |
| 04:36.32 | brlcad | if you can stick to vls use, even better |
| 04:37.17 | pacman87 | sorry, my bugfixing took over my local context |
| 04:37.33 | pacman87 | needs a bigger L2 cache |
| 04:37.57 | pacman87 | but going to bed would probably work too |
| 04:38.11 | pacman87 | since i need to be up early enough to catch d_rossburg |
| 04:39.10 | brlcad | you can always hit him up on the mailing list too |
| 04:40.02 | pacman87 | if i dont catch him tomorrow morning, i'll do that |
| 04:40.08 | pacman87 | good night |
| 04:40.13 | brlcad | cya1 |
| 04:43.25 | PrezKennedy | ~karma |
| 04:43.25 | ibot | prezkennedy has karma of 3 |
| 04:47.28 | Ralith | who's bot is ibot? |
| 04:49.04 | Ralith | also: cool about the high traffic |
| 04:49.07 | Ralith | wonder what's generating interest |
| 04:49.11 | Ralith | any common referrers? |
| 04:49.23 | yukonbob | ~karma |
| 04:49.23 | ibot | yukonbob has karma of 2 |
| 04:49.41 | yukonbob | passes hat for karma |
| 04:49.55 | Ralith | ~karma |
| 04:49.55 | ibot | ralith has neutral karma |
| 04:49.58 | Ralith | aw :[ |
| 04:50.10 | yukonbob | you're the switzerland of karma |
| 04:50.17 | Ralith | that's not so bad |
| 04:50.33 | Ralith | I have a full on citizen militia |
| 04:57.39 | brlcad | Ralith: I didn't dig into the stats much further -- I'll do something more comprehensive and automated later, maybe at the anniversary |
| 04:58.29 | brlcad | the bot is run by tim on one of his systems |
| 04:58.57 | brlcad | on a couple hundred channels at last check |
| 04:59.08 | brlcad | and probably the largest factoid database for an irc bot |
| 04:59.23 | yukonbob | ~brlcad |
| 04:59.23 | ibot | somebody said brlcad was like a learner wrapped in tofu best served chilled |
| 04:59.39 | brlcad | ~stats |
| 04:59.39 | ibot | Since Mon Jul 14 18:39:43 2008, there have been 143 modifications, 1468 questions, 0 dunnos, 0 morons and 1061 commands. I have been awake for 9d 10h 19m 56s this session, and currently reference 115036 factoids. I'm using about 21096 kB of memory. With 0 active forks. Process time user/system 23166.69/1095.29 child 0.01/0.02 |
| 05:08.06 | yukonbob | installs |
| 05:08.14 | yukonbob | tcl 8.5, listening: |
| 05:08.18 | yukonbob | Boards of Canada |
| 05:08.22 | yukonbob | ^- a haiku |
| 05:09.25 | PrezKennedy | ~prezkennedy |
| 05:09.33 | yukonbob | (read "8.5" "Eight Five") |
| 05:09.34 | PrezKennedy | aww :( |
| 05:21.53 | louipc | catering to the twisted soul eh? |
| 05:22.40 | louipc | with human flesh. Death Metal! |
| 05:42.46 | *** join/#brlcad homovulg2ris (n=d@117.196.130.210) |
| 05:43.10 | *** join/#brlcad homovulg3ris (n=d@117.196.130.210) |
| 06:06.09 | *** join/#brlcad clock_ (n=clock@77-56-95-27.dclient.hispeed.ch) |
| 07:02.25 | *** join/#brlcad elmom (n=elmom@hoasnet-ff04dd00-187.dhcp.inet.fi) |
| 07:13.48 | *** join/#brlcad clock_ (n=clock@84-72-91-240.dclient.hispeed.ch) |
| 07:18.00 | *** join/#brlcad homovulg2ris (n=d@117.196.130.210) [NETSPLIT VICTIM] |
| 07:18.00 | *** join/#brlcad CIA-22 (n=CIA@208.69.182.149.simpli.biz) [NETSPLIT VICTIM] |
| 07:18.00 | *** join/#brlcad b0ef (n=b0ef@062016141231.customer.alfanett.no) [NETSPLIT VICTIM] |
| 07:18.56 | *** join/#brlcad starseeker_ (n=CY@c-68-33-217-173.hsd1.md.comcast.net) [NETSPLIT VICTIM] |
| 07:24.40 | *** join/#brlcad Axman6 (n=Axman6@pdpc/supporter/student/Axman6) |
| 08:42.18 | *** join/#brlcad Elperion (n=Bary@p5B14ED6F.dip.t-dialin.net) |
| 09:08.24 | *** join/#brlcad elite01 (n=elite01@unaffiliated/elite01) |
| 09:20.24 | *** join/#brlcad mafm (n=mafm@elnet-111.lip.pt) |
| 09:21.38 | mafm | hi |
| 09:33.27 | alex_joni | hi |
| 10:34.32 | louipc | hi |
| 10:40.23 | homovulg2ris | hi :D |
| 11:57.32 | *** join/#brlcad elite01 (n=elite01@unaffiliated/elite01) [NETSPLIT VICTIM] |
| 11:57.32 | *** join/#brlcad starseeker_ (n=CY@c-68-33-217-173.hsd1.md.comcast.net) [NETSPLIT VICTIM] |
| 12:35.37 | *** join/#brlcad thing0 (n=ric@123.208.78.105) |
| 12:38.25 | *** part/#brlcad thing0 (n=ric@123.208.78.105) |
| 13:03.56 | andrecastelo | brlcad: got it to shoot secondary rays and to use another function for the secondary hits.. the algorithm in the secondary rays hit function is a stub (it shades again), i need to work on that now |
| 13:16.46 | *** join/#brlcad PrezKennedy (i=Matthew@whitecalf.net) |
| 13:36.35 | *** join/#brlcad clock_ (n=clock@84-72-91-240.dclient.hispeed.ch) |
| 13:58.00 | pacman87 | ~seen d_rossberg |
| 13:58.01 | ibot | d_rossberg <n=rossberg@bz.bzflag.bz> was last seen on IRC in channel #brlcad, 7d 22h 35m 31s ago, saying: '(if not along a coordinate axis)'. |
| 14:26.18 | *** join/#brlcad mafm (n=mafm@elnet-111.lip.pt) |
| 14:26.26 | mafm | network network network |
| 14:26.45 | CIA-22 | BRL-CAD: 03andrecastelo * r31927 10/brlcad/trunk/src/rt/viewmlt.c: Added secondary rays support. rayhit() calls secondary_hit(). The algorithm in secondary_hit() needs to be changed, though. |
| 14:57.43 | *** join/#brlcad clock_ (n=clock@84-72-91-240.dclient.hispeed.ch) |
| 15:30.52 | *** join/#brlcad jonored (n=jonored@c-76-19-120-77.hsd1.ma.comcast.net) |
| 15:35.50 | *** join/#brlcad homovulgaris (n=d@117.196.140.116) |
| 15:38.20 | *** join/#brlcad docelic (n=docelic@78.134.199.199) |
| 15:54.01 | *** join/#brlcad pacman87 (n=timothy@71.170.63.120) |
| 15:55.16 | *** join/#brlcad pacman87 (n=timothy@71.170.63.120) |
| 16:01.40 | CIA-22 | BRL-CAD: 03homovulgaris * r31928 10/brlcad/trunk/src/libpc/ (pcVariable.cpp pcVariable.h): making VariableAbstract more than an empty class by shifting data from Variable<T> templates |
| 16:58.57 | CIA-22 | BRL-CAD: 03pacman87 * r31929 10/brlcad/trunk/src/librt/primitives/sketch/sketch.c: add carc support to rt_sketch_contains() |
| 17:46.25 | CIA-22 | BRL-CAD: 03homovulgaris * r31930 10/brlcad/trunk/src/libpc/ (pcVariable.cpp pcVariable.h solver_test.cpp): adding intersectInterval() function to Domain object , which among many other things would be helpful in implementing implicit constraints which result only in domain reduction |
| 18:09.53 | pacman87 | <PROTECTED> |
| 18:09.53 | pacman87 | <PROTECTED> |
| 18:12.07 | CIA-22 | BRL-CAD: 03homovulgaris * r31931 10/brlcad/trunk/src/libpc/pcBasic.h: scheduled removal/cleanup |
| 18:39.49 | louipc | yeh I got that too |
| 18:40.06 | louipc | mged seemed to work ok |
| 18:40.36 | pacman87 | i just went back to autogen.sh and configure |
| 18:43.53 | CIA-22 | BRL-CAD: 03pacman87 * r31932 10/brlcad/trunk/include/vmath.h: add V2ADD3() to vmath.h |
| 18:44.33 | louipc | woo |
| 18:47.30 | louipc | do your floats conform to IEEE 754? |
| 18:47.39 | louipc | configure:38682: checking whether floats conform to IEEE 754 |
| 18:47.43 | pacman87 | i think i got that warning too |
| 18:49.48 | pacman87 | configure:38993: WARNING: The floating point implementation does not seem to be IEEE 754 |
| 18:49.49 | pacman87 | configure:38995: WARNING: compliant. The behavior or htond and htonf may be incorrect. |
| 18:50.40 | pacman87 | s/or/of? |
| 18:52.58 | CIA-22 | BRL-CAD: 03erikgreenwald * r31933 10/brlcad/trunk/configure.ac: fix minor typo in warning, spotted by pacman87 |
| 18:53.01 | ``Erik | looks right to me |
| 18:54.39 | pacman87 | hmm, autogen.sh and configure didn't fix the "WARNING: Too many of the pkgIndex.tcl and tclIndex files are empty." |
| 18:55.12 | ``Erik | I get that, too... not sure why, haven't dug into it (what I do seems to work, so I haven't been concerned) |
| 18:55.24 | ``Erik | the annoying thing is that I have to svn revert -R src/tclscripts once in a while |
| 19:01.37 | *** join/#brlcad clock_ (n=clock@77-56-88-130.dclient.hispeed.ch) |
| 19:33.10 | CIA-22 | BRL-CAD: 03johnranderson * r31934 10/brlcad/trunk/src/librtserver/rtserver.c: Eliminated call to exit() and added memory clean-up to shutdown method |
| 20:09.50 | pacman87 | is it possible to alias commands within mged |
| 20:28.55 | CIA-22 | BRL-CAD: 03starseeker * r31935 10/brlcad/trunk/src/proc-db/tire.c: |
| 20:28.55 | CIA-22 | BRL-CAD: Fix problem with nicks being removed from tread - turned out to be a problem |
| 20:28.55 | CIA-22 | BRL-CAD: with the trimming of the tread ellipse, which was trimming material from inside |
| 20:28.55 | CIA-22 | BRL-CAD: the tread as well as outside. Switched to using two trimming cyls getting only |
| 20:28.55 | CIA-22 | BRL-CAD: the necessary outer parts - tread now renders without visual defect. |
| 20:31.11 | CIA-22 | BRL-CAD: 03starseeker * r31936 10/brlcad/trunk/NEWS: note fix to tire tool in NEWS file. |
| 20:39.19 | brlcad | poolio: in your home dir again |
| 20:40.29 | homovulgaris | brlcad: i was doing some header include cleanup .. to use std::string we don't need to have any #includes ? |
| 20:40.52 | brlcad | pacman87: sure, you can create a proc that calls any number of other procs, even overriding commands already provided |
| 20:41.32 | brlcad | homovulgaris: what do you mean? should include <string> I'd think, no? |
| 20:41.52 | homovulgaris | yeah that was what i was thinking.. but it compiles fine :P |
| 20:42.19 | brlcad | if you use it, include it |
| 20:42.22 | homovulgaris | anyways.. good coding practice is to #include <string> :) |
| 20:42.26 | homovulgaris | i guess |
| 20:42.53 | brlcad | just means somewhere earlier in the header dependency chain, someone else needed it and is including it |
| 20:43.00 | brlcad | but that's not a guarantee |
| 20:43.37 | brlcad | so you should alwways include what a given file uses -- either its interface header (which includes what its implementation needs) and/or including the necessary implementation headers |
| 20:44.20 | homovulgaris | hmm.. :) |
| 20:44.36 | brlcad | is rather pedantic on headers |
| 20:44.44 | brlcad | s/pedantic/picky/ |
| 20:45.31 | homovulgaris | on another note i was almost about to delve into RTTI ..I think i should search for a better solution.. basically the issue is I want to support constraints which support multiple Variable types |
| 20:45.55 | brlcad | yeah, I think you need a really good reason to start using rtti |
| 20:46.05 | brlcad | that causes a handful of portability problems |
| 20:46.23 | brlcad | if your project wasn't so important, I would have said "absolutely no" :) |
| 20:46.51 | brlcad | but as a last resort, he can try to make the headaches work if needed |
| 20:47.05 | homovulgaris | I don't want to use it either.. I just need to write a heterogeneous container |
| 20:47.06 | brlcad | still, if you can find a better solution, it would probably be preferred |
| 20:48.06 | pacman87 | i'm pretty sure a bug is in revolve.c lines 302-344, so if someone wants to lend a fresh set of eyes to it, i'd appreciate it |
| 20:48.19 | brlcad | ah, yeah, there are better ways to get to that end (change the problem, use multiple containers, use a base class, type identifiers, even void* marshalling) |
| 20:49.03 | pacman87 | the problem is determining which side is + and which is - for a hitpoint on the start/end planes |
| 20:49.11 | homovulgaris | basically implementationwise how would the constraint evaluation function know the type of variables in the expression it evaluates.. I tried a bit with Variable Inheritance .. but function pointers still cause trouble due to signature difference.. I am experimenting a bit with boos::function and boost::lambda .. but it's proving to be tricky |
| 20:49.25 | brlcad | looks like someone checked in a bunch of tclIndex files |
| 20:50.38 | brlcad | wags his finger at bob |
| 20:53.18 | ``Erik | casting pointers with a magic check is pretty common in BRL-CAD |
| 20:54.35 | pacman87 | ``Erik: that's how extrude determines which segment type to use |
| 20:56.03 | brlcad | homovulgaris: I was actually going to talk to you about that bit .. what are your thoughts on using something a little more "less custom" for parsing the expressions |
| 20:56.03 | ``Erik | heh, that's core to just about everything librt does, pacman... :D |
| 20:57.24 | starseeker | brlcad: heh - another regex recruit? |
| 20:57.44 | homovulgaris | brlcad: u mean not using spirit ? and using flex/yacc instead ? |
| 20:59.38 | homovulgaris | I think spirit along with phoenix would be able to put in a lot of functional programming techniques into constraint generation.. performance wise though i think spirit is a bit of an issue.. |
| 21:01.34 | homovulgaris | about phoenix : http://www.boost.org/doc/libs/1_35_0/libs/spirit/phoenix/doc/preface.html |
| 21:02.34 | homovulgaris | basically i want the precompiled constraint functors to be as generic as possible.. |
| 21:04.50 | homovulgaris | hmm.. magic check.. |
| 21:15.07 | pacman87 | bugcount--; |
| 21:16.17 | brlcad | pacman87: so what exactly is the bug in that section? |
| 21:16.23 | brlcad | or is that the bugcount--? |
| 21:16.27 | pacman87 | i fixed it |
| 21:16.31 | brlcad | ah, bah :) |
| 21:16.34 | brlcad | what was the problem |
| 21:16.38 | brlcad | and the fix :) |
| 21:16.46 | pacman87 | i wanted the untransformed hit, and was using the transformed hit point |
| 21:17.03 | pacman87 | i was taking the dot product of the start vector and the point |
| 21:18.06 | pacman87 | so i switched to use the translated point and the original ray's direction |
| 21:18.12 | brlcad | this is part of turning that chunk into a union instead of subtraction/xor based? |
| 21:18.16 | pacman87 | no |
| 21:18.22 | brlcad | ah, just some other issue? |
| 21:18.24 | pacman87 | yeah |
| 21:18.29 | pacman87 | the last one i found last night |
| 21:18.33 | brlcad | what was the issue? |
| 21:18.41 | brlcad | i.e. the end result |
| 21:19.01 | brlcad | wrong hit points I presume? |
| 21:19.08 | pacman87 | it was confusing +/- for the x coordinates to pass to rt_sketch_conatains() |
| 21:19.15 | homovulgaris | :| i will have to burn a lot of midnight oil for clearing my solver segfault :( |
| 21:20.13 | pacman87 | but i didnt' see it before since my testing had all been aligned with the coordinate axes |
| 21:20.32 | brlcad | homovulgaris: i'll have to read up on phoenix later tonight, but it does sound like there's a need for some direction discussions here rsn :) |
| 21:20.33 | pacman87 | so the transformed was the same as the untransformed |
| 21:21.08 | homovulgaris | brlcad: amen :) |
| 21:22.12 | CIA-22 | BRL-CAD: 03pacman87 * r31937 10/brlcad/trunk/src/librt/primitives/revolve/revolve.c: fix bug that caused flipping the start/end plane's x-axis for certain revolve start vectors |
| 21:35.40 | *** join/#brlcad stting_ (n=stting@c-67-160-127-173.hsd1.wa.comcast.net) |
| 21:37.03 | *** join/#brlcad stting (n=stting@c-67-160-127-173.hsd1.wa.comcast.net) |
| 21:37.09 | *** part/#brlcad stting (n=stting@c-67-160-127-173.hsd1.wa.comcast.net) |
| 21:37.15 | *** join/#brlcad stting (n=stting@c-67-160-127-173.hsd1.wa.comcast.net) |
| 21:41.47 | poolio | brlcad: thanks |
| 21:58.36 | brlcad | pacman87: makes complete sense, thanks :) |
| 22:32.10 | CIA-22 | BRL-CAD: 03homovulgaris * r31938 10/brlcad/trunk/src/libpc/ (8 files): Include cleanup |
| 22:44.03 | *** join/#brlcad jonored (n=jonored@c-76-19-120-77.hsd1.ma.comcast.net) |
| 23:15.47 | brlcad | wonders if he got stuck |
| 23:38.49 | pacman87 | who got stuck? |
| 23:39.30 | brlcad | starseeker |
| 23:39.33 | brlcad | but he didn't |
| 23:39.50 | starseeker | I'm back :-) |
| 23:40.14 | starseeker | may get stuck in another sense, as he attempts to tame regex to his will... |
| 23:40.30 | brlcad | starseeker: contains offsets to the start and end, not copies |
| 23:40.39 | starseeker | right |
| 23:40.41 | brlcad | so you just allow as many entries as you'll have matches |
| 23:41.06 | starseeker | how do I tell which substring was matched by which pattern? |
| 23:41.13 | brlcad | which yeah, could be strlen and/or something big |
| 23:41.33 | brlcad | they're ordered |
| 23:42.07 | starseeker | k |
| 23:42.16 | starseeker | starts working on a test case |
