| 01:13.55 | CIA-5 | BRL-CAD: 03brlcad * 10brlcad/ (1348 files in 82 dirs): (log message trimmed) |
| 01:13.55 | CIA-5 | BRL-CAD: Sweeping license updates. Documentation is fully relicensed to the BSD |
| 01:13.55 | CIA-5 | BRL-CAD: Documentation License (a minor variant of the FreeBSD Documentation License and |
| 01:13.55 | CIA-5 | BRL-CAD: BSD License). All GPL code (mostly application code) is converted to the LGPL |
| 01:13.55 | CIA-5 | BRL-CAD: and now also specifically declares version 2.1, revoking the blank check to the |
| 01:13.58 | CIA-5 | BRL-CAD: FSF. The intent of these sweeping changes are to simplify the licensing terms |
| 01:14.00 | CIA-5 | BRL-CAD: and increase overall flexibility of use, both externally (to users for their |
| 01:14.23 | CIA-5 | BRL-CAD: 03brlcad * 10brlcad/src/ (409 files in 16 dirs): (log message trimmed) |
| 01:14.23 | CIA-5 | BRL-CAD: Sweeping license updates. Documentation is fully relicensed to the BSD |
| 01:14.23 | CIA-5 | BRL-CAD: Documentation License (a minor variant of the FreeBSD Documentation License and |
| 01:14.23 | CIA-5 | BRL-CAD: BSD License). All GPL code (mostly application code) is converted to the LGPL |
| 01:14.24 | CIA-5 | BRL-CAD: and now also specifically declares version 2.1, revoking the blank check to the |
| 01:14.26 | CIA-5 | BRL-CAD: FSF. The intent of these sweeping changes are to simplify the licensing terms |
| 01:14.28 | CIA-5 | BRL-CAD: and increase overall flexibility of use, both externally (to users for their |
| 01:16.27 | ``Erik | O.O |
| 02:10.42 | Maloeran | Confirmed by Mark, they did look into non-immigration visas too. Oh well, I guess it's time to get that degree paper thing |
| 04:04.37 | *** join/#brlcad PrezKennedy (n=Matthew@c-69-138-68-160.hsd1.md.comcast.net) |
| 08:26.16 | *** join/#brlcad clock_ (n=clock@zux221-122-143.adsl.green.ch) |
| 10:02.52 | CIA-5 | BRL-CAD: 03d_rossberg * 10brlcad/src/other/libregex/libregex.dsp: |
| 10:02.52 | CIA-5 | BRL-CAD: not a BRL-CAD core library |
| 10:02.52 | CIA-5 | BRL-CAD: remove misleading multibyte-character support |
| 10:04.43 | clock_ | What does -a mean in pix-png? It seems to not have a manpage. |
| 10:05.01 | clock_ | Turn upside down? Or 16-bit input? |
| 10:07.14 | CIA-5 | BRL-CAD: 03d_rossberg * 10brlcad/src/other/openNURBS/opennurbs.dsp: |
| 10:07.14 | CIA-5 | BRL-CAD: ignore opennurbs_zlib_memory.cpp in win32-msvc build |
| 10:07.14 | CIA-5 | BRL-CAD: we do not need the openNURBS wrapper functions zcalloc() and zcfree() since we're just letting zlib do it's own thing |
| 11:17.31 | *** join/#brlcad clock_ (n=clock@zux221-122-143.adsl.green.ch) |
| 11:49.46 | brlcad | noir:~ morrison$ man brlcad/src/util/pix-png.1 | grep autosize -a autosize the input file to determine file image height and width |
| 11:56.27 | CIA-5 | BRL-CAD: 03brlcad * 10brlcad/NEWS: write up a summary of the recent sweeping license changes. i.e. describe gpl->lgpl and gfdl/gpl->bdl as well as the motvations, impact, and intent. |
| 11:56.39 | brlcad | basically -a means "try to figure out how big the file is", which is only useful if your image has "standard" common dimensions and it guesses correctly. |
| 12:51.44 | *** join/#brlcad rossberg (n=rossberg@bz.bzflag.bz) |
| 13:19.56 | *** join/#brlcad rossberg_ (n=rossberg@66.111.56.50) |
| 13:49.01 | *** join/#brlcad rossberg (n=rossberg@bz.bzflag.bz) |
| 14:08.03 | ``Erik | heh |
| 14:45.20 | ``Erik | eh? |
| 17:21.30 | CIA-5 | BRL-CAD: 03johnranderson * 10brlcad/src/librtserver/rtserver.c: Java Partition objects now include entrance and exit surface normals |
| 17:49.39 | clock_ | lol Java |
| 17:49.48 | clock_ | and BRL-CAD goes downhill too :) |
| 18:15.39 | Maloeran | Woah, there's a Java interface for librt o.O |
| 18:17.43 | Maloeran | Ah yes, it's for MUVES of course |
| 18:19.33 | Maloeran | Don't worry clock_, I'll try not to let anyone write a Java interface for the new raytracer :) |
| 18:24.38 | brlcad | clock_: that's been in there for several years, jni wrapper to a subset of librt |
| 18:26.07 | brlcad | Maloeran: good luck -- that's actually the next generation muves 3 there that uses the jni interface, not muves-s2 |
| 18:26.49 | brlcad | but then with that interface, there's a *lot* more room for flexibility and marshalling of data in and changing/defining the api |
| 18:27.28 | brlcad | that's certainly not on this year's agenda I'd have to guess though |
| 18:27.57 | Maloeran | brlcad, it's just that it implies performing the "shading" in Java ; which, as you know, will make performance collapse |
| 18:50.47 | ``Erik | the 'shading' being done in the C variant has no performance, so there's a possibility that a java version may be faster... |
| 18:51.12 | ``Erik | not the one actually being worked on, but *A* version might be... |
| 18:51.13 | ``Erik | O:-) |
| 19:34.09 | Maloeran | Erik, can I "safely" assume floats are always 4 bytes and doubles 8 bytes? ( flipping endianess of floats between nodes ) |
| 19:36.14 | Maloeran | It checks if the floating point encoding is the same between the platforms of course, but I'm wondering if different widths exist |
| 19:50.21 | ``Erik | I don't think the C spec makes any assertion on width of float or double? |
| 19:50.47 | ``Erik | hm, k&r is showing bunches of different bitwidths for, uh, ... all C types |
| 19:51.14 | ``Erik | I can't think of a machine that doesn't use 32 and 64 bits ieee754/854 for float and double |
| 19:51.23 | ``Erik | a modern one, that is |
| 19:51.42 | ``Erik | I mean, the honeywell 6000 used 36 and 72 |
| 19:55.58 | Maloeran | Ahah, cool. |
| 19:56.23 | Maloeran | I know that C doesn't garantee anything on floating point datatypes, but I still need to flip bytes somehow |
| 19:56.59 | Maloeran | I was wondering if some arch could have used 8 and 16 bytes floats/doubles, or the same width for both, etc. |
| 19:57.23 | ``Erik | ieee754 is the standard that describes bit packing and width |
| 19:57.50 | ``Erik | mebbe, I saw mention of "half precision" floats using 16b that might be going into ieee754 |
| 19:57.55 | ``Erik | and quad precision with 128b |
| 19:58.42 | ``Erik | um, intel, amd, and ibm/ppc are all ieee754 fpu equiped... |
| 19:59.10 | Maloeran | I have alternative paths to handle non-ieee floats anyhow, it's just the width I was wondering about |
| 19:59.36 | ``Erik | (bear in mind, intel 386's usually came without an fpu, you have to shove in an x387 or get a 386dx for fpu hw, otherwise the c compiler faked it... common availability ofa n fpu is still pretty new) |
| 19:59.49 | ``Erik | if it's not ieee754, then all bets are off on width |
| 20:01.55 | Maloeran | It still requires storage in memory somehow, so it's likely to be some 2-4-8-16 bytes wideness |
| 20:02.17 | ``Erik | most machines are these days... several were 36 bit words |
| 20:04.05 | ``Erik | hrm, looks like the cell uses ieee... at least, they say it supports their rounding modes |
| 20:04.27 | ``Erik | and since ibm has the modules for ieee754 for their ppc's, I can't see them not reusing it |
| 20:05.02 | Maloeran | It's really just the width I was concerned about, non-ieee is already handled |
| 20:05.20 | ``Erik | I'm going to imagine that for the target hardware, it's ok to make those assumptions |
| 20:05.36 | Maloeran | The graph preparation code plays right in the binary representation of floats/doubles, if it's IEEE |
| 20:05.42 | ``Erik | ieee specifies widths, so it's all good |
| 20:05.43 | Maloeran | Right, thanks |
| 20:06.22 | ``Erik | damn this code is retarded :/ |
| 20:07.04 | Maloeran | Are you working on the raytracing comparison framework? |
| 20:07.09 | ``Erik | yeah |
| 20:08.12 | ``Erik | loading a 'geometry' file in this thing involves setting up a new tcl interpreter, shoving crap into it, then deleting it... instead of using the one already running |
| 20:08.30 | Maloeran | Strange... |
| 20:08.44 | Maloeran | By the way, did Lee obtain the leave to complete his doctorate or not? |
| 20:08.59 | ``Erik | it's still being looked at, heh |
| 20:09.33 | ``Erik | someone had an ego writing this thing, too |
| 20:09.49 | ``Erik | mebbe I should start doing that... struct mything_s *erik; |
| 20:10.00 | Maloeran | Ahaha |
| 20:11.02 | Maloeran | Have you considered stepping up to take Lee's place, if he leaves? I think you said you weren't interested |
| 20:12.34 | ``Erik | <-- just a lowly db2, that's a db4 position |
| 20:12.58 | ``Erik | also; I've pissed off the fucktards in mgmt as much as anyone else |
| 20:13.22 | Maloeran | At the indian restaurant in Baltimore, Lee said he was looking for a competent person to take his place if he leaves, and he would gladly give it to someone like you |
| 20:13.40 | Maloeran | Though I don't know, I'm not too aware of what's going there |
| 20:21.31 | ``Erik | heh, there's political bs in the way *shrug* |
| 20:21.56 | ``Erik | plus I d'no think I'd be interested in ever doing what he does... meetings and ties ain't mah thang |
| 20:24.15 | dtidrow_work | what a heretical idea... ;-) |
| 20:28.35 | ``Erik | blah->destructor(blah); stinks, I'd rather see blah_destructor(blah); :/ |
| 20:29.16 | Maloeran | Unless that destructor varies a lot based on the state of "blah", a function pointer does the job then |
| 20:32.17 | ``Erik | blah is malloc'd, so you'd have to free() it after calling that destructor (or declare it on the stakc and pass &blah, which'd be much neater) |
| 20:32.18 | ``Erik | imma rewrite all this shit in lithp one of thethe dayth |
| 20:33.24 | Maloeran | By the way, is that blocking one-ray-at-a-time interface threaded? In that design, I would somewhat need an arbitrary pointer per thread to keep track of state on a per-thread basis... |
| 20:34.00 | Maloeran | Single threaded, globals would do I guess |
| 20:34.12 | *** join/#brlcad magicalex (n=54dd4221@bz.bzflag.bz) |
| 20:35.25 | ``Erik | I was hoping to talk to lee about extending the interface to allow bundled shtuff |
| 20:35.45 | ``Erik | and maybe feeding that back to the codemonkeys on the retarded side of the fence |
| 20:35.55 | ``Erik | but he's out today |
| 20:37.40 | Maloeran | Bundled, non-blocking with callbacks, letting me do the threading would be nice. An interface allowing intelligent management of ray sources and displacements would be a blessing |
| 20:38.11 | Maloeran | Anyhow, I'll try to make up something that works no matter the interface you give me |
| 20:39.00 | ``Erik | *shrug* the sales pitch was about integrating it into a specific program, so I'm gonna give you as close to their interface as I can |
| 20:39.21 | ``Erik | changing it much is going to get them up in a knot and either fighting it or not using it |
| 20:54.25 | brlcad | the initial approach of getting it working with the interface that is already in place, for better or worse, is still the best first step for various reasons |
| 20:55.45 | ``Erik | *nod* |
| 20:55.59 | ``Erik | this code makes me want to run away o.O |
| 20:56.36 | brlcad | adding non-blocking callbacks to librt might be the next step, showing how it would change interaction with librt .. get them to understand/adopt those changes |
| 20:57.28 | brlcad | now how non-blocking results would actually be beneficial to the various algorithms the other codes are using is where I could easily see there being big problems |
| 20:58.28 | ``Erik | their fundamental design is very serial and it hasn't aged well :/ |
| 20:58.50 | brlcad | it makes sense for a ray intersection engine to answer asynchronously, but then ray-tracing in general can trivially compute asychronous as most of the computations are pretty much independent |
| 20:59.48 | brlcad | their design isn't independent, just about everything depends on something else, very serial, very much a "how thick is this region" and they can't really ask any more questions or do anything without guessing blinding until they get that answer |
| 21:01.59 | brlcad | part of it is their design, but part of it is also the domain and approach of the algorithms (which predominantly is neither their responsibility or in their domain of expertise to be designing) |
| 21:02.56 | ``Erik | <-- thinks it could be just as parallelizable as raytracing if it were described in terms of shading opposed to what they do now |
| 21:03.06 | ``Erik | *shrug* |
| 21:04.00 | ``Erik | yeah, each ray would be a fair bit heavier to compute, but if ya shoot 10,000 non-interacting primaries, it should theoretically scale linearly on a 10,001 cpu machine |
| 21:04.32 | brlcad | it probably could be, it correlates closely for some interactions |
| 21:05.23 | brlcad | but you don't convince someone riding a bike about the benefits of driving a car by trying to force them into the seat and telling them how much their bike sucks ;) |
| 21:05.53 | brlcad | there's plenty of downsides (from their perspective) that are entirely relevant |
| 21:06.01 | Maloeran | Quite right, slaming a car door in his face is so much more effective :) |
| 21:06.17 | ``Erik | mal: your bike sucks |
| 21:06.18 | ``Erik | :D |
| 21:06.27 | dtidrow_work | who's 'they', btw? |
| 21:06.38 | brlcad | brl-cad's primary user |
| 21:06.54 | dtidrow_work | heh |
| 21:06.55 | brlcad | the vulnerability/lethality analysis developers |
| 21:07.05 | ``Erik | heh, "vlad" |
| 21:07.15 | ``Erik | dealing with the current crop sure does suck the life out of ya |
| 21:07.20 | ``Erik | O:-) |
| 21:07.25 | Maloeran | Non-blocking sure would be nice, but especially, processing of rays in batches |
| 21:09.37 | brlcad | sure, Maloeran .. but when their entire problem-space is for a given algorithm is just a handful of dependent rays (done over and over, with dependencies at each step) .. it's like telling someone that's eating a salad at a local diner that they could have a much bigger salad if they bought in bulk at the local sams club |
| 21:09.59 | ``Erik | s/analogies/ ... |
| 21:10.01 | ``Erik | :D |
| 21:10.01 | brlcad | they simply wouldn't care .. at all .. no matter how many heads of lettuce they can get for a buck |
| 21:10.07 | Maloeran | Yes, I got the idea. If they need to know A before doing B, and B before doing C ; we should process 50000 A rays, followed by 50000 B and C |
| 21:10.25 | *** join/#brlcad SWPadnos_ (n=Me@dsl245.esjtvtli.sover.net) |
| 21:10.40 | ``Erik | we get the same issue (sorta), mebbe WORSE in the "hall of mirrors" scenario |
| 21:11.16 | brlcad | they can be convinced to change their shopping and eating habits, but that's a long-term issue frankly pretty much outside the scope of the project |
| 21:11.32 | Maloeran | If we imagine global illumination where rays bounce around constantly, we don't want to follow one single ray until the end |
| 21:11.56 | Maloeran | We could process the first hit for 4000 rays, second hit for the same bouncing 4000 rays, etc. |
| 21:12.28 | ``Erik | for optical, that's fine.. |
| 21:12.45 | ``Erik | but, y'knw, if an optical ray hits glass, you shoot two secondaries and mix the result |
| 21:12.51 | ``Erik | they shoot several hundred |
| 21:13.27 | Maloeran | I would have used probabilities to decide which way it goes, but that works too |
| 21:13.50 | ``Erik | (but that's ok, they could do those several hundred in parallel, and they could do all their primaries in parallel) |
| 21:13.53 | ``Erik | y'know, if they chose to |
| 21:14.23 | ``Erik | *shrug* |
| 21:14.39 | Maloeran | So the problem could be re-engineered, but it's not going to happen so we have to handle individual blocking rays. All right |
| 21:15.25 | brlcad | this is like the bi-weekly bitch-fest isn't it? |
| 21:15.34 | ``Erik | oh yeah |
| 21:15.45 | ``Erik | if I gotta deal with their code, you'll hear me go off. |
| 21:16.00 | ``Erik | and I gotta deal with their code. |
| 21:16.08 | dtidrow_work | lol |
| 21:16.41 | brlcad | you know, nobody really disagrees -- and it's not even a new idea to question the way they do what they do and point out how it could/should be better .. been that way for decades |
| 21:17.13 | brlcad | but it's mostly pointless, or at least impractical without actually working hand-in-hand with them for weeks to make a change happen (and that just isn't going to happen either anytime soon) |
| 21:17.14 | Maloeran | I realize you are tired of hearing it over and over, when you can't do much about it |
| 21:17.23 | ``Erik | I know, and that's why everyone on the second floor is doing what they're doing |
| 21:17.33 | brlcad | right, and that worked out great |
| 21:17.43 | brlcad | :) |
| 21:17.44 | ``Erik | but, y'know, they're wrong, everyone's a moron, only I'm right :D *duck* |
| 21:17.54 | dtidrow_work | lol |
| 21:18.22 | ``Erik | (my award winning attitude, that's why all the users adore me :D ) |
| 21:19.34 | dtidrow_work | brlcad: ``Erik's public lynching is next week, right? ;-) |
| 21:19.35 | brlcad | attitude did more to the performance than java or the architecture itself ever did |
| 21:19.56 | ``Erik | at least thte activity of exploration into what the old software does and why, with the documentation... that's a good thing.. a step in the right direction. when that's done, maybe an appropriate replacement can be started |
| 21:20.52 | ``Erik | the architecture when viewed from orbit seems ok, up close it's ... nonoptimal |
| 21:22.04 | ``Erik | probably a combo of too many people working on it too early and too much "ooh shiney" without the opportunity to assess and fix (or remove) some mistakes |
| 21:22.05 | ``Erik | :) |
| 21:22.22 | ``Erik | *gripebitchcomplain* |
| 21:23.43 | brlcad | dtidrow_work: nah, he does enough to torture himself by not speaking out (at least tactfully) when it matters .. but then he's also partially escaped the sphere of influence so he doesn't have to be involved as much |
| 21:23.56 | dtidrow_work | heh |
| 21:24.50 | brlcad | riight, you're about as tactful as a box of tacks |
| 21:24.58 | brlcad | :) |
| 21:25.03 | ``Erik | trained attack tacks |
| 21:25.10 | dtidrow_work | rofl |
| 21:28.12 | Maloeran | As Caligula Ceasar walked among his lowly people anonymously, what a difference it would make if a manager were to listen here. He could even claim the ideas to "fix" these doomed projects were his own |
| 21:33.00 | Maloeran | Erik, do you have any idea if Lee had plans for me after this task? No need to ask him, I'm just wondering because SURVICE apparently plans to keep me busy |
| 21:33.03 | brlcad | not likely, because it's still not taking all the considerations into account that all become part of the issue.. mitigation of risks, not just doing things for academic purity (who the f*ck cares if it's not perfect, it does the job and does it well), the time/money/resources it would take to change it in a major way, documenting the new approach, *validating* that you really are 100% sure you didn't F-something up (the are-you-willing-to-bet-y |
| 21:34.58 | ``Erik | mal: I'm sure he does, whether or not he can execute them is nto necessarily in his power... and competent coders aren't exactly a common beast, if they can figure out how to make money off of you, they'll try to do it *shrug* |
| 21:35.34 | ``Erik | once ya got a little paid experience on your cv, it's not hard to stay working *shrug* |
| 21:36.27 | Maloeran | Well sure, SURVICE has plans. I would personally prefer to work with you guys somehow, if you are fine with that |
| 21:36.48 | ``Erik | <-- doesn't have any say in anything, one way or the other *shrug* |
| 21:37.10 | brlcad | if you had a specific task in mind, that would make selling a point a whole lot easier -- I have several in mind myself that I could raise |
| 21:37.50 | ``Erik | hm, the an/fsq-7 was kinda big |
| 21:38.17 | brlcad | que? |
| 21:39.10 | ``Erik | old computer, 2000m^2 floor space (half an acre) |
| 21:40.03 | brlcad | ahh |
| 21:40.05 | ``Erik | and wifi to boot |
| 21:42.23 | brlcad | Maloeran: the next thing I'd think would be cool to try and implement would be 1) a global illumination renderer using your tracer as a basis and 2) try to apply the same evaulation approach directly to implicit geometry |
| 21:43.16 | brlcad | and perhaps 3) a variety of shaders maybe implementing the renderman shader interface |
| 21:43.42 | ``Erik | heh, to see how bad bmrt's butt can get whupped? :D |
| 21:44.07 | brlcad | maybe for starters :) |
| 21:44.51 | Maloeran | brlcad, the whole raytracer was initially designed to solve high-performance global illumination, so I would be very interested in that |
| 21:45.07 | brlcad | at the order of magnitude he's got, if it could be sustained, he could even potentially give some of the big names a run for their money |
| 21:45.14 | Maloeran | It's really designed for that problem specifically. Though I wonder, what use would that be for the ARL? |
| 21:45.28 | ``Erik | making pretty pictures? |
| 21:45.39 | brlcad | Maloeran: signal processing, signatures, pretty pictures, pretty animations, etc |
| 21:46.24 | ``Erik | adrt has "rise" for path tracing, and it cooked a good bit of cpu time here for pretty pictures :) |
| 21:46.26 | brlcad | add support for multispectral energies and you can suddently generate real radar, infrared, microwave images |
| 21:47.01 | Maloeran | All right. SURVICE wants traversal of tetrahedron graphs with per-tetrahedron ray refraction implemented too |
| 21:47.06 | brlcad | rise was very much brute force, but very much "sells the cake" because the results look great |
| 21:47.19 | brlcad | ew |
| 21:47.20 | ``Erik | heh, yeah, and radiated energy distribution (like figuring out cell phone coverage, for example) |
| 21:47.28 | brlcad | sounds finite elementish |
| 21:47.54 | brlcad | i bet that's exactly what they want it for actually .. hm |
| 21:48.07 | ``Erik | per-tetrahedron ray refraction? O.o |
| 21:48.20 | Maloeran | It's to handle refraction of lasers mounted on aircrafts, going through layers of air of different density and temperature |
| 21:48.25 | Maloeran | It refracts the rays a bit |
| 21:48.27 | ``Erik | ah |
| 21:48.37 | ``Erik | interesting way to cope with atmospherics |
| 21:48.52 | Maloeran | It's rather nice, I hesitated for a very long time between a sector graph and a tetrahedron graph, so I'll be able to try the second way |
| 21:49.04 | brlcad | that same technique can be used to propagate energies and forces, it's the basics of FEA |
| 21:59.24 | *** join/#brlcad SWPadnos_ (n=Me@dsl245.esjtvtli.sover.net) |
| 23:24.12 | Maloeran | *yawn* Urgh, I didn't sleep well last night because I was too emotionally moved by the "death" of HAL-9000 in "2010: The year we make contact" |
| 23:24.23 | ``Erik | heh, dork |
| 23:25.49 | ``Erik | I'm dorky, too, though *shrug* read mccarthy's "the robot and the baby" |
| 23:26.17 | ``Erik | http://www-formal.stanford.edu/jmc/robotandbaby.html |
| 23:26.28 | Maloeran | I haven't read that one, thanks |
| 23:26.36 | ``Erik | it's very short |
| 23:28.21 | ``Erik | (in case you're not brushed up, mccarthy was a move and shaker in the 50's and 60's with ai stuff... he was also the guy who axiomed the notion of programming computers and discovered lithp, invented things like function declarations and conditionals in programming, etc) |
| 23:28.21 | Maloeran | Thinking about it, it's really weird to have even more altruistic feelings towards AIs than humans |
| 23:28.42 | ``Erik | aiomized |
| 23:28.45 | ``Erik | axiomized |
| 23:29.13 | Maloeran | Ah I see, thanks. I was mixing names with Clarke |
| 23:31.35 | *** join/#brlcad cad34 (n=3ba7fd52@bz.bzflag.bz) |
| 23:57.34 | ``Erik | The C programming language requires that all memory be accessible as bytes, so C implementations on 36-bit machines use 9-bit bytes. |
| 23:57.35 | ``Erik | neat |
| 23:57.59 | ``Erik | (and a testament to how untrustworthy C's types are) |
| 23:58.21 | brlcad | the sticky bit |