| 02:37.55 | brlcad | nope |
| 03:17.28 | *** join/#brlcad Twingy (n=justin@74.92.144.217) | |
| 06:32.13 | *** join/#brlcad Z80-Boy (n=clock@217-162-111-154.dclient.hispeed.ch) | |
| 06:32.38 | Z80-Boy | My infamous model: Frame 0: 4720128 rays in 26011.79 sec = 181.46 rays/sec (wallclock) |
| 06:32.46 | Z80-Boy | And that's a COre 2 Duo 2.2 GHz |
| 07:33.36 | *** join/#brlcad Axman6 (n=Axman6@pdpc/supporter/student/Axman6) | |
| 07:59.53 | *** join/#brlcad clock_ (n=clock@zux221-122-143.adsl.green.ch) | |
| 08:00.45 | clock_ | hi all |
| 10:47.28 | *** join/#brlcad elite01 (n=elite01@dslb-088-070-001-048.pools.arcor-ip.net) | |
| 11:25.58 | *** join/#brlcad d_rossberg (n=rossberg@bz.bzflag.bz) | |
| 11:34.52 | brlcad | wow, that is incredibly slow |
| 11:38.47 | clock_ | brlcad: I hope you can look at the model which causes this and see the cause |
| 11:38.53 | clock_ | now I am leaving for lunch sorry |
| 12:28.30 | *** join/#brlcad illethal (n=oden@c-69-137-199-63.hsd1.fl.comcast.net) | |
| 12:49.06 | *** join/#brlcad Elperion (n=Bary@p54877627.dip.t-dialin.net) | |
| 13:39.18 | illethal | Hello fellow humans of Earth! |
| 13:40.48 | ``Erik | �/det |
| 13:41.11 | ``Erik | heh |
| 13:41.19 | ``Erik | no hello for me, illethal? *cry* :D |
| 14:02.42 | *** join/#brlcad elite01_ (n=elite01@dslb-088-070-001-048.pools.arcor-ip.net) | |
| 14:05.25 | *** join/#brlcad clock_ (n=clock@zux221-122-143.adsl.green.ch) | |
| 14:46.08 | *** join/#brlcad MinuteEl1ctron (n=MinuteEl@bz.bzflag.bz) | |
| 14:58.25 | *** join/#brlcad MinuteElectron (n=MinuteEl@silentflame/member/pdpc.base.minuteelectron) | |
| 15:04.30 | *** join/#brlcad poolio_ (n=poolio@bz.bzflag.bz) | |
| 15:04.48 | *** join/#brlcad MinuteElectron (n=MinuteEl@silentflame/member/pdpc.base.minuteelectron) | |
| 15:08.21 | *** join/#brlcad cad84 (n=91486201@bz.bzflag.bz) | |
| 15:13.49 | *** join/#brlcad d_rossberg (n=rossberg@bz.bzflag.bz) | |
| 15:16.58 | CIA-32 | BRL-CAD: 03d_rossberg * r30449 10/brlcad/trunk/src/irprep/Makefile.am: put irdisp neatly under WITH_X11 condition |
| 15:23.36 | *** join/#brlcad elite01 (n=elite01@dslb-088-070-001-048.pools.arcor-ip.net) | |
| 15:37.46 | *** join/#brlcad brlcad (n=sean@bz.bzflag.bz) | |
| 15:49.14 | *** join/#brlcad tofu (n=sean@bz.bzflag.bz) | |
| 15:51.55 | ``Erik | quit pissing peer off, dude, he'll jack you up |
| 15:53.09 | *** join/#brlcad jgay (n=jgay@fsf/staff/jgay) | |
| 15:56.45 | clock_ | brlcad: yes I have 118 pixels per second |
| 15:57.00 | clock_ | brlcad: it's the strange model that causes 210x slowdown |
| 15:57.28 | clock_ | http://ronja.twibright.com/3d/headcut.g object name headcut |
| 15:58.59 | brlcad | clock_: I'm aware of the model, and had looked at it |
| 15:59.02 | brlcad | and commented on it |
| 15:59.08 | brlcad | or have you forgotten?? :) |
| 15:59.17 | ``Erik | neat, bus error |
| 15:59.20 | clock_ | I faintly remember you have commented on it |
| 15:59.22 | clock_ | but not what you said |
| 15:59.30 | clock_ | A fact is it's still hell slow |
| 15:59.36 | clock_ | is it gonna stay this slow? |
| 16:00.44 | brlcad | it's slow for several reasons -- the biggest of which relates to how it's modeled -- you can get the same shape with a different hierarchy and probably get back much of the performance |
| 16:00.49 | brlcad | you're more than 210x slower |
| 16:00.55 | brlcad | you're mixing two different issues |
| 16:01.30 | clock_ | can't the program transform the hierarchy into the more efficient one automatically? |
| 16:01.42 | ``Erik | cuz that's insanely complex to do? |
| 16:01.49 | brlcad | clock_: go for it |
| 16:02.21 | brlcad | :) |
| 16:02.22 | clock_ | So now I have to do a insanely complex thing with my model to get back some of the performance? |
| 16:02.41 | ``Erik | insanely complex to automate correctly |
| 16:02.58 | clock_ | how should I change the hierarchy? |
| 16:03.09 | ``Erik | if we could do that reasonably, we could also convert polygon soup to csg reasonably |
| 16:04.36 | brlcad | usually just balancing the csg tree will do wonders particularly if it's deep |
| 16:05.05 | brlcad | but the better opt involves looking at the shapes and bounding boxes of the shapes being used |
| 16:05.05 | clock_ | No it's shallow |
| 16:05.07 | clock_ | like 3 or 4 |
| 16:05.32 | brlcad | er, not that I recall.. |
| 16:06.22 | brlcad | gah, it's hard as heck to chat right now |
| 16:06.30 | brlcad | isp is being attacked |
| 16:06.34 | ``Erik | well, it may be disguised |
| 16:06.51 | ``Erik | if you, say, union 16 things all together at once, it looks like one level, but it's actually at least 3 |
| 16:07.10 | ``Erik | er, 5 |
| 16:07.32 | clock_ | But it has a lot of things in one node |
| 16:07.36 | ``Erik | the actual csg structure is all leaf, unary or binary |
| 16:07.38 | brlcad | and depending on the ops and the way they're input, you might even end up with 16 levels |
| 16:08.00 | clock_ | Balancing a tree isn't an insanely complex operation |
| 16:08.11 | clock_ | It has the insane complexity of second year of the university |
| 16:08.14 | ``Erik | but it's an ordered tree |
| 16:08.25 | clock_ | what's an ordered tree? |
| 16:08.26 | ``Erik | if you change the order or even position, you change the semantic |
| 16:08.47 | clock_ | not for unions |
| 16:09.04 | brlcad | clock_: so then seriously .. code it up, you're being given the simple explanation just for sake of explaining it |
| 16:09.04 | clock_ | not for logical ANDs |
| 16:09.26 | ``Erik | ok, imagine if you have, say, a union, then you use that union to cut from another object, that makes one shape... but if you cut, then union, say through a tree balancing, it's the same operations, but you get a different shape |
| 16:09.48 | clock_ | I have an impression now that BRL-CAD contains some kind of simple straightforward unoptimized implementation that goes off on heavily unbalanced trees |
| 16:09.52 | ``Erik | and I think for simple union, we do balance? |
| 16:10.44 | brlcad | clock_: actually the csg processing is *heavily* optimized, one of the tightest you'll find anywhere |
| 16:10.56 | brlcad | but in this particular instance, there is other stuff going on |
| 16:11.20 | ``Erik | the next step in optimizing is worth a fair number of doctorates, I'd imagine :/ |
| 16:11.22 | brlcad | several issues, one being the construction hierarchy, other issues being the bounding volumes iirc |
| 16:11.40 | clock_ | Do I imagine CSG correctly as firing a ray, intersecting with all primitives their bounding boxes the ray hits, and then finding the first visible intersect according to the logical operations? |
| 16:11.44 | ``Erik | perhaps np complete, even |
| 16:12.21 | clock_ | My scene has no reason to be difficult |
| 16:12.28 | clock_ | It's a stack of cylindrical slices |
| 16:12.36 | clock_ | and the stack is cut in half with a large primitive |
| 16:12.42 | brlcad | clock_: no, it's considerably more complex than that -- there is spatial partitioning to determine which bounding boxes to test against |
| 16:12.46 | clock_ | Every cylindrical slice has a tiny bounding box |
| 16:13.00 | brlcad | if you did what you suggest of "intersecting with all primitives their bounding boxes the ray hits" it would be horrendously slow |
| 16:13.14 | clock_ | so every ray hits only through small amount of slices unless you are looking close to the axis |
| 16:13.22 | brlcad | depending on how you actually determine which bounding boxes it intersects |
| 16:13.26 | clock_ | The deadly picture isn't AFAIK looking along the axis |
| 16:14.00 | ``Erik | whoa |
| 16:14.11 | brlcad | clock_: I believe itss that large primitive that is killing it |
| 16:14.26 | clock_ | is it so complex to calculate an intersection with a cube? |
| 16:14.28 | brlcad | by doing that, it basically has to evaluate every primitive every time |
| 16:14.33 | ``Erik | does 'head' raytrace fast? |
| 16:14.40 | clock_ | yes |
| 16:14.42 | clock_ | fast as hell |
| 16:14.44 | ``Erik | (and did anyone do a tree on head? jfc) |
| 16:15.43 | clock_ | Or maybe the bounding boxes are evaluated too liberal? |
| 16:15.58 | clock_ | Like saying a tiny slice of metal with a huge negative box give a bounding box of the negative box? |
| 16:16.22 | ``Erik | Frame 0: 263441 rays in 12.24 sec = 21527.96 rays/sec (RTFM) |
| 16:16.25 | clock_ | For an AND it's good to at least take the bounding box of the smaller part |
| 16:17.27 | ``Erik | definitely the massive boolean overload from having the slice at that position :/ |
| 16:17.46 | clock_ | I can't put the slice elsewhere sorry |
| 16:17.57 | clock_ | The idea is to show where the bolts are going through |
| 16:18.05 | ``Erik | without the cutter |
| 16:18.06 | ``Erik | Frame 0: 262165 rays in 0.04 sec = 6802545.46 rays/sec (RTFM) |
| 16:18.18 | clock_ | why do you get 21527 rays and me 118? |
| 16:18.23 | clock_ | I have 2.2GHz Core Duo |
| 16:18.28 | ``Erik | cuz my machine is moar awesomer |
| 16:18.31 | clock_ | What do you have? |
| 16:18.35 | ``Erik | 8 3ghz cores |
| 16:18.41 | illethal | That is awesome. |
| 16:18.44 | illethal | Octcore? |
| 16:18.53 | clock_ | ZX Spectrum with a secret tape of Manic Miner picked from the wreckage of US 193? |
| 16:19.02 | clock_ | octopus |
| 16:19.02 | ``Erik | two quadcore xeons, beefy mac pro |
| 16:19.20 | ``Erik | makes a nice footrest, too |
| 16:19.21 | clock_ | OK |
| 16:19.44 | clock_ | Do you understand the mechanism of the slowdown? |
| 16:19.47 | ``Erik | if you made, say, a hundred small cutting boxes, the scnee would go much faster |
| 16:19.48 | ``Erik | yes |
| 16:20.07 | clock_ | why would making hundred small ones help? |
| 16:20.25 | ``Erik | because right now, your big cutting box is in the tree making the bounding volume include everything |
| 16:20.34 | ``Erik | so every single pixel must evaluate every single primitive |
| 16:20.41 | ``Erik | and weave all of them together |
| 16:20.51 | ``Erik | you've effectively eliminated space partitioning |
| 16:21.00 | clock_ | so if you have a 3mm part and cut it with a 1m cube, the bounding box inflates to 1m? |
| 16:21.07 | ``Erik | yes |
| 16:21.24 | clock_ | Whoa! What algorithmic motorization! Secret trick, dude: if you subtract from something, it never gets bigger |
| 16:21.49 | ``Erik | yeah, but what if that 1m cube not only clips out part of that 3mm part, but ALSO part of the other 3mm part over there |
| 16:22.12 | ``Erik | until evaluated, there's no way to know what primitives that subtraction impacts |
| 16:22.22 | ``Erik | YOU know, because you're modelling it,but the software CANNOT know |
| 16:22.47 | clock_ | OK jokes about pinnacle of development back let's assume it's really serious |
| 16:23.12 | clock_ | Let's say I have a scene with zillion tiny slices and one big cube that subtracts (eats off) half of each slice |
| 16:23.29 | clock_ | I fire a ray |
| 16:23.49 | clock_ | Now I take one primitive after another, check it's bounding box and possibly calculate intersection |
| 16:28.03 | clock_ | ``Erik: what the software knows is that the cube is always the same cube so it doesn't have to calculate it million times |
| 16:35.33 | clock_ | What the software also know is that zillion parts cut with one cutter equals zillion results of (part cut with the cutter) |
| 16:36.02 | clock_ | or more precisely can know, if programmed thusly |
| 16:38.10 | illethal | Dang how do I compile this. |
| 16:52.18 | clock_ | illethal: do you have an error? |
| 16:52.22 | illethal | I type make install |
| 16:52.26 | illethal | but it does nothing, I'm su. |
| 16:52.33 | illethal | It says no targets. |
| 16:52.36 | clock_ | did you do make before? |
| 16:52.38 | illethal | What directory do I have to be in? |
| 16:52.46 | clock_ | in the toplevel brl-cad |
| 16:52.50 | illethal | Doesn't do anything either |
| 16:53.19 | clock_ | What I do is unpack tgz, configure, make, make install |
| 16:53.20 | clock_ | it works |
| 16:53.23 | clock_ | on Linux and OpenBSD |
| 16:53.27 | clock_ | what system do you have? |
| 16:53.29 | illethal | Linux |
| 16:53.33 | illethal | Ubuntu 64 |
| 16:53.37 | clock_ | oops 64 |
| 16:53.54 | clock_ | heard that a lots of things don't work on 64 |
| 16:54.14 | illethal | Ahhhh a lot do actually. |
| 16:54.25 | illethal | Just Flash is meh. |
| 16:54.40 | illethal | nspluginwrapper crap. It works for 30 mins them breaks, then I have to recompile. |
| 16:55.29 | illethal | root@valhall:/home/oden/Desktop/progs/usr# make |
| 16:55.31 | illethal | make: *** No targets specified and no makefile found. Stop. |
| 16:55.40 | illethal | arg |
| 16:55.42 | illethal | wrong dir |
| 16:55.54 | illethal | Still |
| 16:55.58 | illethal | Doesn't do anything wtf. |
| 16:56.05 | clock_ | maybe it's a demo version |
| 16:56.10 | clock_ | after 30 seconds you have to buy a licence? |
| 16:56.21 | clock_ | My Firefox crashes |
| 16:56.29 | clock_ | That's normal that Firefox is a piece of crap |
| 16:56.34 | illethal | Everything else works fine except flash for me. |
| 16:56.38 | clock_ | oh 30 minutes you wrote not seconds sorry |
| 16:56.45 | clock_ | My flash works but often crashes |
| 16:56.58 | clock_ | And brings down the whole Firefox. It hangs and stops refreshing the window |
| 16:56.58 | illethal | Adobe needs to burn. |
| 16:57.03 | clock_ | I have to kill it lose all my open tabs |
| 16:57.15 | clock_ | Adobe is piece of crap |
| 16:57.16 | illethal | What distro you on? |
| 16:57.22 | clock_ | Linux From Scratch |
| 16:57.34 | illethal | From Scrath? |
| 16:57.39 | clock_ | yes |
| 16:57.40 | illethal | Like you made your own os? |
| 16:57.46 | illethal | Or modified/whatever? |
| 16:57.49 | clock_ | compiled |
| 16:58.08 | clock_ | LFS is a web instructions where they tell you what to type to compile everything from scratch |
| 16:58.18 | illethal | Cool. |
| 16:58.19 | clock_ | kernel, gcc, glibc,...bash,...,firefox,... |
| 16:58.26 | illethal | Ubuntu is pretty unstable. |
| 16:58.28 | illethal | Imo. |
| 16:58.37 | illethal | I think I'm going to switch to gentoo. |
| 16:58.45 | clock_ | Friend had an Ubuntu and he typed locate and locate segfaulted |
| 16:58.53 | illethal | Yeah. |
| 16:59.03 | clock_ | I had gentoo but every time I upgraded it blew up about 5 times and I had to try secret tricks from google |
| 16:59.14 | illethal | haha |
| 16:59.16 | clock_ | sometimes the tricks didn't work so I had to google up a different remedy etc. |
| 16:59.19 | clock_ | It's a load of bullshit |
| 16:59.25 | clock_ | Then I ditched gentoo and tried OpenBSD |
| 16:59.30 | clock_ | Also exploded when I upgrded |
| 16:59.31 | illethal | Well my bro uses gentoo more than ubuntu. So if I need help I've got it. |
| 16:59.41 | clock_ | So now I have LFS. I had LFS for years before and I was basically happy |
| 16:59.45 | clock_ | So now I am happy again :) |
| 16:59.49 | illethal | I havn't upgraded in a long ass time. |
| 16:59.52 | illethal | I'm still on feisty. |
| 17:00.17 | illethal | Ubuntu has such gay names. |
| 17:00.21 | illethal | Gutsy Gibbon lol |
| 17:00.28 | clock_ | Software today is piece of crap. Load of bullshit. Heap of trash. |
| 17:00.48 | clock_ | I am gay |
| 17:00.59 | clock_ | you shouldn't use the word "gay" as a synonym for something bad or laughable |
| 17:01.14 | illethal | You're a homosexual. |
| 17:01.22 | illethal | Not gay =P |
| 17:01.22 | clock_ | Yes that too |
| 17:01.28 | clock_ | No I am gay |
| 17:01.34 | illethal | You could be a manic depressed homosexual! |
| 17:01.44 | clock_ | you could be Manic Miner |
| 17:02.39 | illethal | Don't mean to offend you buddy. |
| 17:02.39 | clock_ | Yeah sure I know |
| 17:02.39 | clock_ | you just didn't care to offend all gays in the world |
| 17:03.23 | illethal | You mean homos. |
| 17:03.33 | clock_ | I know what I mean |
| 17:03.35 | clock_ | you can't know it |
| 17:03.50 | illethal | Homos are gays. Heteros are Sads. |
| 17:04.38 | clock_ | yeah you have all those wifes shopping babies etc. |
| 17:04.45 | clock_ | changing diapers |
| 17:04.49 | clock_ | kindergartens |
| 17:05.41 | illethal | Gays like to shop too I thought. |
| 17:05.50 | clock_ | Especially the camp ones |
| 17:05.53 | illethal | Could just be a stereotype. |
| 17:06.17 | clock_ | Buy a lot offancy crap to hook up on their HIV-soaked promiscuous bodies |
| 17:06.36 | illethal | Exactly. |
| 17:06.43 | clock_ | I don't like promiscuous gays |
| 17:06.45 | illethal | To each his own. |
| 17:06.53 | clock_ | I read 1 of 6 gays in the "scene" in Zurich are HIV+ |
| 17:07.36 | clock_ | sounds like I should walk only with rubber gloves protective goggles and a preservative already on in the street just for the case I passed by some of them |
| 17:08.20 | clock_ | sounds like a promiscuity is a ticket to cemetery here |
| 17:09.27 | illethal | Lol |
| 17:09.36 | illethal | yeah that's groooooooz |
| 17:09.52 | clock_ | 1 in 6 that's like the Russian Roulette |
| 17:10.45 | clock_ | If they invent a vaccine for HIV they need to excavate a lot of earth for the storage tanks in the factory |
| 17:10.58 | illethal | Haha |
| 17:11.05 | clock_ | maybe build a pipeline |
| 17:11.06 | *** join/#brlcad MinuteElectron (n=MinuteEl@silentflame/member/pdpc.base.minuteelectron) | |
| 17:11.42 | illethal | Isn't Zurich in Switzerland? |
| 17:11.51 | clock_ | ``Erik: did I offend you with my comment on pinnacle of 30 years of development? |
| 17:11.56 | clock_ | yes Switzerland |
| 17:12.15 | clock_ | in the news today in teh paper new in the train |
| 17:12.21 | clock_ | they wrote the price of prostitution dropped |
| 17:12.33 | clock_ | like 30 CHF (35 USD?) for a sex in the street |
| 17:12.47 | illethal | http://micah.noobgrinder.com/builda.png |
| 17:12.58 | clock_ | What's happening with our Zurich? |
| 17:13.23 | illethal | Something I was working on a while ago. |
| 17:13.27 | clock_ | Autodesk that's not BRL-CAD |
| 17:13.35 | clock_ | do you want to use BRL-CAD for that? |
| 17:13.59 | illethal | It's maya. |
| 17:14.07 | illethal | 8.5 |
| 17:14.18 | illethal | I could probably never do that in BRL-CAD. |
| 17:14.35 | illethal | All I can do in BRL-CAD is make a cube and move it's faces lol |
| 17:14.44 | clock_ | yeah |
| 17:14.59 | clock_ | nothing against BRL-CAD I like BRL-CAD even with the limitations it has |
| 17:15.05 | clock_ | But I wanted to do a polygonal plate |
| 17:15.16 | clock_ | So I asked brlcad and he advised me some secret command that was undocumented |
| 17:15.22 | clock_ | Described the syntax in detail |
| 17:15.32 | clock_ | I typed it I believe exactly as he said and it didn't work |
| 17:15.59 | clock_ | Every now and then I run into some error in the doc, ambiguity or some topic not being covered at all |
| 17:16.04 | clock_ | I also found a lot of segfaults |
| 17:16.26 | clock_ | Like - it's still great - but these can be serious obstackles during work, especially for a novice |
| 17:16.38 | clock_ | Now I have a problem if I do a cutaway view the rendering alsmost grinds to a halt |
| 17:17.28 | clock_ | BRL-CAD people are great they fix all or most of the problems shortly after I find them |
| 17:17.31 | clock_ | Especially segfaults |
| 18:07.09 | ``Erik | nah, didn't offend me, I was out at lunch |
| 18:08.05 | ``Erik | I'm hoping my contributions have removed a lot of the suck and modernized things a lot int he last few years, but *shrug* I'm only one codegod :D and smothered in bs politics and crap so I don't have much time to commit |
| 18:15.26 | clock_ | ``Erik: the problem is my model is logically built |
| 18:15.34 | clock_ | that means I first make a device like the optical head |
| 18:15.46 | clock_ | and then I say now we want to look what's inside .... cut! |
| 18:16.01 | clock_ | Thinking about the cut at the moment I make the screw is not appropriate. |
| 18:16.07 | clock_ | Also because the script is made by an automatic script. |
| 18:16.25 | clock_ | However, would it help if the cutting thing was composed of a larger amount of smaller subthings? |
| 18:17.21 | clock_ | the script is made -> the bolt (screw) is made |
| 18:46.26 | CIA-32 | BRL-CAD: 03bob1961 * r30450 10/brlcad/trunk/include/raytrace.h: struct dg_obj and supporting cast has been moved to dg.h |
| 18:46.50 | *** join/#brlcad docelic (n=docelic@212.15.184.79) | |
| 18:47.02 | CIA-32 | BRL-CAD: 03bob1961 * r30451 10/brlcad/trunk/include/dg.h: Initial check-in. |
| 18:48.34 | *** join/#brlcad poolio (n=poolio@bz.bzflag.bz) | |
| 18:48.54 | CIA-32 | BRL-CAD: 03bob1961 * r30452 10/brlcad/trunk/src/ (69 files in 5 dirs): Mods related to bio.h and the new dg.h wrt getting things compiled on Windows. |
| 18:54.14 | CIA-32 | BRL-CAD: 03bob1961 * r30453 10/brlcad/trunk/include/raytrace.h: Move "drawable geometry" related function declarations to dg.h |
| 19:02.44 | CIA-32 | BRL-CAD: 03bob1961 * r30454 10/brlcad/trunk/include/dg.h: Added function declarations. |
| 19:50.43 | *** join/#brlcad Elperion (n=Bary@p54877627.dip.t-dialin.net) | |
| 20:55.25 | *** join/#brlcad elite01_ (n=elite01@dslb-088-070-003-070.pools.arcor-ip.net) | |
| 21:00.30 | CIA-32 | BRL-CAD: 03bob1961 * r30455 10/brlcad/trunk/src/librt/opennurbs_ext.cpp: Move include for bio.h after common.h |
| 21:05.58 | CIA-32 | BRL-CAD: 03bob1961 * r30456 10/brlcad/trunk/src/libfb/if_wgl.c: Move include for bio.h after common.h |
| 21:13.49 | *** join/#brlcad jgay (n=jgay@fsf/staff/jgay) | |
| 22:18.54 | ``Erik | 1http://bash.org/?10626 |
| 22:24.48 | ``Erik | minus that first 1, of course |
| 22:25.09 | archivist | cooking, whats wrong with beans on cheese on toast? |
| 23:48.16 | *** join/#brlcad Elperion (n=Bary@p548777EC.dip.t-dialin.net) | |
| 23:48.57 | *** mode/#brlcad [+o brlcad] by ChanServ | |