| 08:25.30 | *** join/#brlcad ibot (~ibot@rikers.org) |
| 08:25.30 | *** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD release 7.18.4 ETA 20110325 || Welcome GSoC 2011 participants! Speak up, ask questions, start here: http://brlcad.org/wiki/Google_Summer_of_Code/2011 |
| 08:27.57 | *** join/#brlcad adityag (~ADITYA@182.237.144.88) |
| 08:47.23 | *** join/#brlcad adityag (~ADITYA@182.237.144.88) |
| 08:58.08 | *** join/#brlcad adityag (~ADITYA@182.237.144.88) |
| 10:14.56 | *** join/#brlcad piksi (piksi@pi-xi.net) |
| 13:00.16 | *** join/#brlcad kunigami (~kunigami@201.53.192.197) |
| 13:50.28 | *** join/#brlcad adityag (~ADITYA@182.237.144.88) |
| 15:16.17 | *** join/#brlcad adityag1 (~ADITYA@182.237.144.88) |
| 15:23.50 | kunigami | hi all, I'm studing mged code in order to fix the bug "gets stdin myinVar" fails - ID: 3087665 http://sourceforge.net/tracker/?func=detail&aid=3087665&group_id=105292&atid=640802 |
| 15:24.01 | kunigami | <PROTECTED> |
| 15:24.05 | kunigami | I though that input was read through a callback too (stdin_input) but it seems that in mode interactive and not classic_mged, the callback isn't set |
| 15:24.09 | kunigami | <PROTECTED> |
| 15:24.12 | kunigami | thanks! |
| 15:39.45 | *** join/#brlcad AbhijitKane (~Abhijit@111.93.5.194) |
| 16:02.31 | brlcad | AbhijitKane: glad to hear the research continues, and expected regarding alloys and polymers -- from our perspective we treat materials as strictly homogeneous matter |
| 16:03.23 | brlcad | bhinesley: yeah, don't worry about line length |
| 16:04.38 | brlcad | kunigami: oof, that's a tricky one since mged input is handled in a variety of ways |
| 16:04.48 | brlcad | input is left up to tcl most of the time iirc |
| 16:44.15 | kunigami | hmm ok. One thing I noticed is that when we don't redirect stdout/stderr to tclchannels (I commented out in the code). The output, now printed to terminal, does not show that bug |
| 16:52.55 | kunigami | I'll try to go back to this bug another time. I'm switching to the to-do list of brlcad :) |
| 16:53.04 | kunigami | There's this one: bu_basename() says it'll return things that it probably won't |
| 16:53.05 | kunigami | <PROTECTED> |
| 16:53.05 | kunigami | <PROTECTED> |
| 16:53.05 | kunigami | <PROTECTED> |
| 16:54.21 | kunigami | indeed, it says that "/" should return "/" and "a/" return "a", but for both cases the actual code is returning the empty string |
| 16:54.42 | kunigami | what is to be done: change commentaries or the code? |
| 17:14.50 | brlcad | kunigami: the redirection is definitely the "cause" of the bug -- it's more making sure the logic is appropriate for both console mode (where there shouldn't be redirection) and graphical mode (where there is redirection) and console mode that invokes the graphical mode (where there are multiple output streams) |
| 17:15.10 | brlcad | kunigami: the code should be fixed |
| 17:15.55 | brlcad | for bu_basename() .. it should basically behave identical to basename(); it's really just a wrapper for platforms that don't have basename() |
| 17:16.18 | brlcad | the initial naive implementation was just a little too hastily coded |
| 17:17.00 | brlcad | that would should be pretty easy to code from scratch or find a bsd reference impl |
| 17:19.22 | kunigami | I see. I'll do it then! thanks |
| 17:34.40 | brlcad | thank you, awesome |
| 18:05.34 | kunigami | hmm there are some issues though: I need to modify the string if it is for instance "a/" (it should return "a"). An option would be allocating space for a new char array, it that ok? |
| 18:06.29 | kunigami | this memory will probably never be deallocated, but I not sure if it's a problem |
| 18:06.32 | *** join/#brlcad AbhijitKane (~Abhijit@111.93.5.194) |
| 18:09.45 | AbhijitKane | brlcad: any updates on the database schema? |
| 18:20.19 | starseeker | for those interesting in watching an animation of part of the BRL-CAD source code history (a small part, admittedly): |
| 18:20.26 | starseeker | http://bzflag.bz/~starseeker/brlcad-gource.avi |
| 18:20.40 | starseeker | that's the gource tool brlcad found |
| 18:23.05 | brlcad | starseeker: awesome! |
| 18:23.39 | brlcad | starseeker: what settings did you use? |
| 18:23.49 | brlcad | and how did it take you to render it to video? |
| 18:29.55 | brlcad | AbhijitKane: I found everything, so no worries there |
| 18:30.30 | starseeker | brlcad: was a combination of yukon video capture, seom-filter, mencoder |
| 18:30.33 | brlcad | in fact, the dev site is still on-line .. just no means for online auth |
| 18:30.36 | brlcad | mater.brlcad.org |
| 18:30.41 | starseeker | don't seem to have the exact settings used for gource |
| 18:31.28 | starseeker | grabbed mencoder settings from here: http://www.mplayerhq.hu/DOCS/HTML/en/menc-feat-x264.html |
| 18:31.43 | starseeker | seom-filter yukon.seom | mencoder - -ovc x264 subq=6:partitions=all:8x8dct:me=umh:frameref=5:bframes=3:b_pyramid:weight_b -vf scale=512:384 -o file.avi |
| 18:32.23 | brlcad | oh, it's not the whole video |
| 18:32.28 | starseeker | right |
| 18:32.44 | AbhijitKane | brlcad: great. i checked a few material databases - they bascially divide all their data into polymers and alloys |
| 18:32.52 | starseeker | just thought I'd put up a subset for those interested in seeing something |
| 18:32.53 | brlcad | ahh, looks like you have the same settings too |
| 18:33.01 | AbhijitKane | then there are different methods for searching through each subset |
| 18:33.04 | brlcad | i made a few source code mod improvements |
| 18:33.23 | brlcad | never used seom-filter |
| 18:33.34 | starseeker | it goes along with the yukon thing |
| 18:33.47 | starseeker | https://devel.neopsis.com/projects/yukon/wiki/HowTo/Install?version=15 |
| 18:33.49 | brlcad | also a tiny video relative to what I was trying to capture |
| 18:33.54 | brlcad | was going for 720p |
| 18:34.01 | brlcad | well, originally 1080p :) |
| 18:34.09 | starseeker | https://devel.neopsis.com/projects/yukon/wiki/HowTo/Capture |
| 18:34.09 | brlcad | that would have filled this hd fast |
| 18:34.42 | starseeker | nods - yeah, mine is just the "here's something cool" sample, not the canonical video |
| 18:34.43 | brlcad | maybe I can just send you my mods and settings.. :) |
| 18:35.09 | starseeker | heh - and watch my pathetic little PC fry ;-) Still may be worth a shot |
| 18:35.28 | starseeker | however, the raw capture on just that part of the animation was 8 gigs |
| 18:35.46 | brlcad | well your video still looks better than mine, I was going to resort to the built-in ppm stream |
| 18:36.26 | starseeker | what were your source mods? |
| 18:36.48 | brlcad | nothing major, the big one was to make the nodes have a little more separation |
| 18:36.54 | brlcad | and I think that one was a data mod |
| 18:37.04 | brlcad | the other was control on the font size |
| 18:37.21 | starseeker | nods - cool. If you want to tar it up, I can give it a whirl |
| 18:37.32 | brlcad | there is an advanced font-size option, but it doesn't affect any of the node labels, just the title |
| 18:37.58 | starseeker | did you send them back upstream? |
| 18:38.03 | brlcad | the way it is now, it's a jumbled mess if the dir has more than about a dozen files in it and they're all edited |
| 18:38.33 | brlcad | with this, you can read most of them without overlap just by increasing the spacing slightly and decreasing the font slightly |
| 18:38.34 | starseeker | oh, there's my gource terminal |
| 18:38.41 | starseeker | yukon ~/gource-0.32/gource -p 0.8 -a 1 -s 1 |
| 18:39.35 | starseeker | this thing would make an awesome screensaver |
| 18:39.48 | brlcad | erm, now to remember what the short-hand opts were |
| 18:40.31 | starseeker | I think those were just to keep things moving rather than pause while waiting for the time to advance to the next commit |
| 18:40.37 | brlcad | settings I was using last: brlcad.org/tmp/CONFIG.gource |
| 18:40.45 | brlcad | though I was constantly tweaking |
| 18:41.21 | brlcad | ah right hilighting too |
| 18:41.39 | brlcad | made it so that commiters were slightly larger and always highlighted so you could distinguish them from the source nodes |
| 18:41.53 | brlcad | they get really lost with the defaults and a big tree |
| 18:42.00 | starseeker | nods |
| 18:42.13 | brlcad | lemme see if I can pull a patch |
| 18:42.32 | starseeker | can gource handle our full history? |
| 18:43.05 | starseeker | that's a stress test and a half |
| 18:43.53 | brlcad | if you skip forward in time, it gets totally screwed up -- the layout engine can't solve a suitable graph fast enough so it oscillates horribly |
| 18:44.09 | brlcad | it does handle the full history, takes a couple min to load |
| 18:44.22 | brlcad | if you let it build up the graph incrementally, works just fine |
| 18:44.51 | brlcad | wanted to compare two videos, one where we don't remove any nodes -- let the additions and deletions remove them instead of the time-based removal it uses by default |
| 18:45.06 | brlcad | then let it do something more like the default for unchanged nodes face away |
| 18:45.29 | brlcad | so you see where the action is at, instead of full view of the project |
| 18:45.45 | brlcad | AbhijitKane: haven't forgotten about you -- just a few secs |
| 18:45.52 | AbhijitKane | haha...sure |
| 18:46.08 | starseeker | brlcad: if it can do the full node graph, that'd be cool |
| 18:46.56 | brlcad | I think it can .. that's where the ppm stream frame dump may be required though |
| 18:47.17 | brlcad | on mine it really bogs down to < 1fps if there's a massive tree edit |
| 18:47.26 | starseeker | ah, so definitely beyond my machine for that one then |
| 18:47.28 | brlcad | like in 2004 during the conversion |
| 18:47.44 | brlcad | it catches back up, just slows the animation to a halt |
| 18:47.58 | brlcad | so if you're capturing video directly from the window, it'd suck |
| 18:48.00 | starseeker | yeah, that's gonna need a ppm dump |
| 18:48.08 | brlcad | but letting it take its time and compute frames, it'd be fine |
| 18:48.14 | brlcad | how much disk you have? |
| 18:48.15 | brlcad | :) |
| 18:48.21 | starseeker | not that much :-P |
| 18:48.47 | starseeker | my biggest drive is an external 1 terabyte, and that's got all my backup stuff |
| 18:48.51 | brlcad | I think I calculated it'd be around 90GB for the stream at 720p |
| 18:48.53 | starseeker | plus it's slow as a dog |
| 18:49.11 | starseeker | ah - I've got over a 100 gigs on my main drive |
| 18:49.32 | brlcad | that should compress down to less than 1GB for the full video |
| 18:49.43 | brlcad | but just take a day or so to process |
| 18:50.08 | brlcad | uploaded to http://brlcad.org/tmp/gource |
| 18:50.16 | starseeker | how much disk space do you have handy? |
| 18:50.17 | brlcad | replaces one of the files in data/ |
| 18:50.24 | brlcad | i only have 5GB at the moment |
| 18:50.43 | starseeker | can gource give me ppm frames as it currently stands? |
| 18:50.49 | brlcad | yep |
| 18:50.52 | brlcad | one of the options |
| 18:51.34 | brlcad | ffmpeg will read the ppm stream as is |
| 18:52.05 | starseeker | uh... I don't have a config file in data |
| 18:52.41 | brlcad | gource --load-config CONFIG.gource --output-ppm-stream frames.ppm |
| 18:52.56 | brlcad | no, that config file is a cmd-line option |
| 18:52.57 | starseeker | oh, gotcha |
| 18:53.01 | brlcad | the file.png goes into data |
| 18:53.08 | starseeker | (thought that was one of the source code mods) |
| 18:54.41 | kunigami | hi, I just sent a patch to the patch tracker. Any commentaries and suggestions are welcome. Thanks :) |
| 18:55.23 | brlcad | starseeker: pulling the source mods now |
| 18:57.54 | starseeker | ah, ok - you're filtering out src/other I see |
| 18:58.21 | brlcad | starseeker: uploaded patch.diff |
| 18:59.05 | brlcad | kunigami: fantastic .. it'll definitely get reviewed |
| 18:59.36 | brlcad | kunigami: include a web link in your application to your patch, that helps save some time figuring out who is who |
| 18:59.59 | brlcad | (not to mention your irc name, contact info, etc..) |
| 19:00.14 | starseeker | bhinesley: be sure to link to your patch(es) too |
| 19:00.58 | brlcad | AbhijitKane: glad to hear the research continues, and expected regarding alloys and polymers -- from our perspective we treat materials as strictly homogeneous matter |
| 19:02.06 | AbhijitKane | oh, so i guess you don't store many of the properties that the other databases do |
| 19:02.41 | brlcad | AbhijitKane: right now today, we only really care about density directly, and indirectly care about a half dozen other props like young's modulus |
| 19:02.55 | kunigami | ok! |
| 19:03.28 | kunigami | I'll turn now on composing my proposal. |
| 19:03.42 | brlcad | great |
| 19:04.00 | AbhijitKane | ohk |
| 19:04.35 | AbhijitKane | so the searching will just be based on these properties right? |
| 19:04.42 | brlcad | starseeker: patch apply alright? |
| 19:04.54 | brlcad | I didn't scrutinize it too closely |
| 19:04.59 | starseeker | the sketch one? Haven't had a chance to try it yet |
| 19:05.07 | brlcad | no, the gource patch |
| 19:05.14 | starseeker | oh :-) |
| 19:05.31 | starseeker | yep, just my ftgl.h was in a slightly different location then configure.ac wanted |
| 19:05.42 | brlcad | my patch changed that too |
| 19:05.54 | brlcad | just turned off the check and linked -lftgl :) |
| 19:06.01 | starseeker | ah :-) |
| 19:06.21 | starseeker | well, just compiled file - so about to give it it's initial trial |
| 19:06.36 | brlcad | was nice to see that it works cleanly against ftgl trunk |
| 19:07.02 | brlcad | we'd restructured things quite a bit, but trying to preserve the compile-time interface |
| 19:07.19 | brlcad | even run-time should be backwards-compatible |
| 19:08.58 | starseeker | brlcad: where's a good place to grab BRL-CAD_64x64.png? |
| 19:09.09 | brlcad | oh right |
| 19:09.21 | brlcad | http://brlcad.org/images/logo/ |
| 19:11.06 | brlcad | skips src/other, also skips dpk commits (jove dev) |
| 19:11.14 | starseeker | nods |
| 19:11.32 | starseeker | bit of a shame to skip the step and opennurbs work, but saves a lot of other cruft |
| 19:11.45 | brlcad | yeah |
| 19:12.05 | brlcad | could get more creative with the regex, but it's pretty darn complex as it is |
| 19:12.15 | starseeker | nods |
| 19:12.24 | brlcad | bigger issue is the length and speed of the animation |
| 19:12.29 | starseeker | alrightie, let's see what happens here... |
| 19:12.35 | starseeker | Reading Log... |
| 19:13.05 | starseeker | is this the config that keeps all the nodes? |
| 19:13.10 | brlcad | next thing I was going to try was allowing a bigger timescale .. it won't let you go over 4x right now .. 4 days per second |
| 19:13.44 | brlcad | I think so |
| 19:14.09 | starseeker | can I get away with piping this into ffmpeg, or will that preserve all the pauses for the long builds? |
| 19:15.15 | brlcad | ah, this one was a balance .. keeps nodes for 5min .. which should pretty much keep the whole graph most of the time |
| 19:15.50 | brlcad | since 5min is 300 sec is 1200 days is a lil over 3 years |
| 19:16.02 | starseeker | nods |
| 19:16.26 | brlcad | all source code is edited annually for the copyright update, so should keep the bulk of the tree at least from 2000 forward |
| 19:16.38 | brlcad | you should be able to pipe directly |
| 19:16.52 | brlcad | but I'd check the output first, letting it run |
| 19:17.07 | brlcad | hm! |
| 19:17.23 | brlcad | didn't think of that.. that might even be a way to avoid writing out 100GB .. duh |
| 19:17.28 | starseeker | still loading... |
| 19:17.38 | brlcad | yeah, takes a couple min |
| 19:18.48 | starseeker | is going with the default ffmpeg string on their site for now |
| 19:20.05 | brlcad | cool |
| 19:20.11 | starseeker | brlcad: you realize I won't be able to give ``Erik a hard time when he complains about how much space docbook takes up? |
| 19:20.43 | brlcad | I'm motivated to try it streaming here myself, but need to get my butt over to the gym.. haven't been sick like this in a while, probably due to gym slacking |
| 19:20.59 | starseeker | winces - I should be in the gym too |
| 19:21.53 | starseeker | ah, there we go |
| 19:21.59 | starseeker | it begins with mike |
| 19:22.27 | brlcad | yep |
| 19:22.36 | starseeker | 1993 |
| 19:22.40 | brlcad | the begining year or two is actually pretty cool |
| 19:22.54 | brlcad | I had it skip .1 |
| 19:23.33 | brlcad | was initial attempt at skipping dpk's commits, but then later found the other option, so can probably remove it back to skipping 0 |
| 19:24.06 | brlcad | how does it look? |
| 19:24.28 | starseeker | on screen it's OK - not sure about the video yet |
| 19:25.18 | starseeker | will stop it and restart - that shoudl be enough to test |
| 19:25.54 | starseeker | hah, awesome |
| 19:26.03 | starseeker | that should do it! |
| 19:26.09 | starseeker | sets up for the full run |
| 19:36.51 | brlcad | awesome |
| 19:36.53 | brlcad | set the skip to zero? |
| 19:41.06 | starseeker | uh - opps - was just using your settings |
| 19:42.21 | starseeker | restarts again |
| 19:44.54 | starseeker | brlcad: which setting are you referring to? |
| 19:44.56 | starseeker | start potition? |
| 19:45.03 | starseeker | er start-position? |
| 19:45.04 | brlcad | the one that says 0.1 |
| 19:45.07 | brlcad | or .1 |
| 19:45.10 | starseeker | ok, I see it |
| 19:45.56 | starseeker | hopefully screensaver won't bother this... not sure how to disable power save... |
| 20:08.18 | *** join/#brlcad sachi1325 (75d3557b@gateway/web/freenode/ip.117.211.85.123) |
| 20:57.25 | *** join/#brlcad sachi1325_ (75d3557b@gateway/web/freenode/ip.117.211.85.123) |
| 21:07.33 | *** part/#brlcad adityag1 (~ADITYA@182.237.144.88) |
| 22:52.09 | kunigami | is there any reference on brlcad system or do I have to study the code? |
| 22:53.01 | kunigami | oops |
| 22:53.17 | kunigami | I mean brlcad shader system |
| 22:53.47 | ``Erik | going to just have to look, they're in src/liboptical/ |
| 22:54.35 | kunigami | ok |
| 22:54.38 | kunigami | thanks |
| 22:57.15 | kunigami | forgive my ignorance, but there are two distinct things: shader language and a shader system, right? |