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? |