| 00:20.08 | andrecastelo | brlcad: question: how can i commit with brlcad (using svn) ?? i've found a typo i want to fix :) |
| 00:22.36 | brlcad | andrecastelo: you make a couple patches first to engender trust that you understand and are following HACKING first :) |
| 00:22.51 | brlcad | patches tracker is on sf |
| 00:23.01 | andrecastelo | ok, if anything burns i'll call you |
| 00:23.10 | brlcad | nods |
| 00:32.28 | andrecastelo | brlcad: ok, i guess everything worked as expected |
| 00:32.48 | andrecastelo | here's the patch : http://rafb.net/p/nPdkdS88.html (i've submitted it already) |
| 00:33.13 | brlcad | heh |
| 00:33.18 | brlcad | coulda just said that one :) |
| 00:33.47 | andrecastelo | i wanted to submit my first patch :) |
| 00:34.03 | andrecastelo | (this is not the patch you want me to submit though) |
| 00:34.07 | CIA-20 | BRL-CAD: 03brlcad * r30644 10/brlcad/trunk/HACKING: it's apparently an int pointer, thanks andrecastelo |
| 00:34.47 | andrecastelo | cheers |
| 00:39.38 | CIA-20 | BRL-CAD: 03brlcad * r30645 10/brlcad/trunk/misc/nsis/brlcad.nsi: apply sf patch 1936200 (Selecting the environmental variables in NSIS) so that PROGRAMFILES is properly set. kinda helps the windows installer work. thanks suryajith. |
| 00:43.45 | andrecastelo | brlcad: that last patch was related to the problem i was having hehehe |
| 00:43.50 | andrecastelo | compiling brlcad |
| 00:46.04 | brlcad | really? |
| 00:46.12 | brlcad | you're on windows? |
| 00:46.25 | andrecastelo | yes |
| 00:46.32 | andrecastelo | non english windows |
| 00:46.33 | brlcad | marks down the application a few points |
| 00:46.38 | brlcad | j/k :) |
| 00:46.39 | andrecastelo | ;O |
| 00:46.43 | andrecastelo | WAIT |
| 00:46.49 | andrecastelo | i have debian installed!!! |
| 00:46.50 | andrecastelo | :) |
| 00:46.59 | brlcad | uh huh, suuure you do :) |
| 00:47.13 | andrecastelo | hahaha |
| 00:47.36 | brlcad | doesn't matter, if the mascot isn't a little daemon with a pitchfork, you're still getting marked down ;) |
| 00:47.55 | andrecastelo | :( |
| 00:48.23 | brlcad | our windows side actually needs lots of loving |
| 00:48.56 | brlcad | almost all of the work put in to date has been by folks that really don't like windows on a very deep level :) |
| 00:49.20 | brlcad | knowledgeable, but not liking working on windows does kinda affect what gets fixed/worked |
| 00:49.41 | brlcad | it gets done out of sheer demand |
| 00:49.56 | andrecastelo | i see.. i guess i'll try building the source on linux |
| 00:50.18 | andrecastelo | and on debian i've heard i have to do some work arounds |
| 00:52.20 | brlcad | finding a good work-around for default debian would be a very useful patch |
| 00:53.02 | andrecastelo | but isn't the work-around debian sided ?? |
| 00:53.22 | andrecastelo | installing an unmodified certain library |
| 00:53.42 | brlcad | well yeah, that works |
| 00:53.47 | brlcad | but that's not a "work-around" |
| 00:54.04 | brlcad | waiting for the devs to fix a problem they don't want to fix is also not a work-around |
| 00:54.27 | brlcad | our build system accounts for lots of system configuration problems so things "just work" as best possible |
| 00:55.25 | brlcad | macs have a poorly configured libtool that is useless by default, for example, but autogen.sh takes care of it |
| 00:56.20 | brlcad | there are a slew of work-arounds in configure and some of the Makefile.am files |
| 00:56.23 | andrecastelo | so, autogen.sh should detect that the system is debian and it has a flawed library, and taking care of the problem.. |
| 00:56.57 | brlcad | the failure happens during make -- so the fix could happen just about anywhere up the chain |
| 00:57.35 | brlcad | we had a work-around in there before, which involved recursively declaring dependencies for all binaries (utterly massive duplicitive link lines) |
| 00:58.16 | brlcad | that's a pretty bad work-around though, involves editing every single Makefile.am with a target |
| 00:58.36 | andrecastelo | and i guess build times sky rocket ? |
| 00:59.00 | brlcad | and had the massive link lines, slow build times, big logs, annoying link-line duplication |
| 00:59.16 | brlcad | kinda a shot-gun approach |
| 00:59.29 | brlcad | should be something that can happen during autogen.sh or configure |
| 01:01.10 | brlcad | or who knows -- maybe things have changed since then and we have a bonefide build bug that needs fixed |
| 01:01.26 | andrecastelo | i'll be afk for a minute and then i'll try compiling it with debian |
| 01:01.54 | andre|away | just a sec, be right back |
| 01:03.35 | *** topic/#brlcad by brlcad -> BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || Channel logs at http://ibot.rikers.org/%23brlcad/ || BRL-CAD is participating in the 2008 Google Summer of Code, see http://brlcad.org/wiki/Google_Summer_of_Code || GSoC applications are being reviewed throughout the week, final candidates will be required to provide a useful patch | |
| 02:00.49 | andrecastelo | brlcad: i've been looking at the viewarea.c and i'm clueless as to how to connect it to the standard center point idea (median of the points that form the area).. can you give me some pointers ? |
| 02:02.46 | brlcad | do you see how those are callbacks called during rtarea? |
| 02:03.23 | brlcad | pre/during/post callbacks |
| 02:04.04 | andrecastelo | i thought of using struct area, but i think this struct is a completely different concept |
| 02:04.17 | andrecastelo | (seems to be) |
| 02:04.24 | brlcad | right now it stores things as just a counter iirc -- but to compute center of presented area, it needs to also store the X,Y values -- and then average them at the end |
| 02:05.24 | andrecastelo | yes, it counts the presented hits and the exposed hits |
| 02:06.02 | andrecastelo | hm, i kind of understand now - struct area should have a list of points, is that it ? |
| 02:06.58 | brlcad | yeah, it's too simple |
| 02:07.24 | brlcad | it's also "wrong" w.r.t. presented hits if you want to fix that too ;) |
| 02:07.47 | brlcad | almost everyone uses it for exposed areas |
| 02:08.01 | andrecastelo | w. r. t. ? |
| 02:08.58 | andrecastelo | but if i just add the points and the function, how would that connect to the whole thing ?? |
| 02:09.13 | andrecastelo | i mean, i need to make the connection, right ? |
| 02:09.41 | brlcad | ~wrt |
| 02:09.41 | ibot | hmm... wrt is with respect to, or with regards to, or the Linksys WRT54G on which some people have successfully installed Asterisk. More information at http://www.voip-info.org/wiki-Asterisk+Linksys+WRT54G |
| 02:10.05 | brlcad | connect? hm? |
| 02:10.52 | brlcad | if you set the values in the hit callback, they'll be available during the output/final callback |
| 02:10.55 | andrecastelo | to actually input the points |
| 02:12.49 | brlcad | the x/y/z of the hitpoint is available in the hit callback |
| 02:13.01 | brlcad | you could stash that into the struct |
| 02:13.17 | andrecastelo | the rayhit function calls the application, so that where i could get the points, am i thinking right here ? |
| 02:14.15 | brlcad | the application struct is a "ray-trace application" -- it contains details about the current ray that was fired |
| 02:14.55 | brlcad | might want to read through http://brlcad.org/wiki/Developing_applications quickly to understand the basic structures and callbacks |
| 02:15.03 | andrecastelo | hm ok ok |
| 02:15.11 | andrecastelo | but am i on the right track? :) |
| 02:15.16 | brlcad | yeah |
| 02:30.31 | *** join/#brlcad spike1234124214 (n=spike@eridani.acm.jhu.edu) | |
| 03:49.05 | CIA-20 | BRL-CAD: 03starseeker * r30646 10/brlcad/trunk/src/proc-db/tire.c: Change variable naming conventions to match new measurements |
| 04:17.36 | andrecastelo | good night everyone |
| 04:17.38 | andrecastelo | cya tomorrow |
| 04:33.09 | brlcad | that's quite a few patches |
| 04:39.46 | starseeker | brlcad: Is there a quick clean way in C (or our utility libs) to concatenate strings? I would like to say "Shape-" + variablestring + ".s" as an argument to mk_* functions |
| 04:40.36 | starseeker | 's memories of strings and C from college are not happy ones |
| 04:40.56 | pacman87 | sprintf? |
| 04:41.35 | pacman87 | newstring = sprintf("Shape-%s.s", variablestring); |
| 04:42.33 | *** join/#brlcad Twingy (n=justin@74.92.144.217) | |
| 04:42.35 | pacman87 | or try strcat |
| 04:43.02 | pacman87 | but you need to make sure your string has enough room |
| 04:43.35 | brlcad | snprintf ftw |
| 04:43.49 | pacman87 | what's the 'n' do? |
| 04:44.19 | brlcad | or bu_strlcat() |
| 04:44.26 | brlcad | n is the buffer length |
| 04:44.40 | starseeker | thanks guys |
| 04:44.45 | brlcad | snprintf(buffer, size, "Shape-%s.s", variablestring); |
| 04:44.46 | starseeker | ftw? |
| 04:44.49 | brlcad | ~ftw |
| 04:44.50 | ibot | extra, extra, read all about it, ftw is wtf backwards, or for the win, or for the win |
| 04:45.06 | starseeker | heh |
| 04:45.16 | pacman87 | for the win twice? |
| 04:45.51 | brlcad | ~pacman87 is astute |
| 04:45.51 | ibot | brlcad: okay |
| 04:45.59 | brlcad | ~pacman87 is also here |
| 04:46.00 | ibot | okay, brlcad |
| 04:46.03 | brlcad | ~pacman87 |
| 04:46.04 | ibot | pacman87 is probably astute, or here |
| 04:46.40 | starseeker | brlcad: is snprintf preferable to sprintf? (see both in the code) |
| 04:46.43 | pacman87 | is that an xor? |
| 04:46.46 | brlcad | starseeker: yes |
| 04:47.00 | pacman87 | only astute when not here? |
| 04:47.08 | starseeker | ugh |
| 04:47.21 | brlcad | ~pacman87 is also the nick for someone on irc |
| 04:47.22 | ibot | brlcad: okay |
| 04:47.26 | brlcad | ~pacman87 |
| 04:47.27 | ibot | i guess pacman87 is astute, or here, or the nick for someone on irc |
| 04:47.33 | brlcad | factoids |
| 04:47.36 | starseeker | doesn't care what the length is, he just wants to use the concatentated string for a shape name... |
| 04:47.55 | brlcad | starseeker: you have to put it into a buffer, so you have to care |
| 04:47.59 | brlcad | else use bu_vls strings |
| 04:48.28 | pacman87 | was wrong earlier |
| 04:48.36 | brlcad | ~forget pacman87 |
| 04:48.36 | ibot | brlcad: i forgot pacman87 |
| 04:48.39 | pacman87 | int sprintf ( char * str, const char * format, ... ) |
| 04:48.46 | pacman87 | returns int, not new string |
| 04:49.02 | brlcad | wasn't going to get all pedantic |
| 04:49.03 | pacman87 | ~blame pacman87 |
| 04:49.04 | ibot | ACTION blames pacman87 (and Canada) for all the evil in the world |
| 04:49.21 | pacman87 | well, if he tries to use what i said, it'd blow up on him |
| 04:49.29 | brlcad | it's good for him |
| 04:49.42 | pacman87 | doesnt like lying to people |
| 04:49.42 | starseeker | mumbles under his breath about languages that can't abstract anything and starts in with snprintf... |
| 04:49.53 | brlcad | shouldn't use any function on blind faith, that's why there are manpages and headers :) |
| 04:50.37 | pacman87 | if i'm going to help, i feel obligated to help correctly |
| 04:50.54 | brlcad | starseeker: you don't have to worry about the size with bu_vls strings -- that's why they're there |
| 04:51.14 | brlcad | otherwise you're writing into a buffer of static or allocated memory and can have a corruption if you don't check/limit your length |
| 04:51.20 | starseeker | OK. |
| 04:51.29 | brlcad | you would just concat into a bu_vls |
| 04:51.30 | starseeker | takes a look a bu_vls... |
| 04:53.33 | brlcad | struct bu_vls str; bu_vls_init(&str); bu_vls_printf(&str, "Shape-%s.s", variablestring); .. then later bu_vls_free(&str); something like that, check the header for exact args |
| 04:54.34 | brlcad | or see other examples throughout the code |
| 04:55.23 | starseeker | Cool. |
| 04:55.26 | starseeker | thanks |
| 04:56.19 | brlcad | relatively high-performance heap-based string management |
| 04:57.04 | starseeker | figured there was something in there somewhere :-) |
| 05:01.39 | starseeker | is moderately bemused to note that there is no other use of any bu_vls function in proc_db according to grep |
| 05:02.23 | brlcad | not surprising, tend to just find static arrays and fault intolerant code |
| 05:04.42 | starseeker | Hmm - will mk_* functions accept a vls type? |
| 05:04.58 | brlcad | bu_vls_addr(&str) |
| 05:05.59 | starseeker | ah :-) |
| 05:06.08 | starseeker | just figured out the grep that found it |
| 05:06.08 | brlcad | (see bu.h and wdb.h) |
| 05:06.13 | starseeker | righto |
| 05:08.21 | starseeker | bingo - thanks brlcad! Sorry for such an elementary question... |
| 05:09.05 | brlcad | the first ones are always free ;) |
| 05:13.04 | pacman87 | is there a brlcad elementary question market? |
| 05:18.59 | starseeker | is beginning to feel malloc stir like an ancient demon in the depths of his memories... |
| 05:27.07 | pacman87 | balrog? |
| 05:45.32 | starseeker | something like that :-) |
| 05:46.28 | starseeker | has been lingering too long in the gentle forests of Lisplorien ;-) |
| 05:46.57 | starseeker | woo-hoo: one step closer |
| 05:47.07 | starseeker | http://my.bzflag.bz/~starseeker/tireshot.png |
| 05:48.15 | pacman87 | impressive |
| 05:48.38 | pacman87 | my revolve should make that a bit easier to do |
| 05:48.47 | starseeker | indeed |
| 05:50.30 | CIA-20 | BRL-CAD: 03starseeker * r30647 10/brlcad/trunk/src/proc-db/tire.c: Add option to append text to all components of a tire shape - allows for multiple definitions in one g file, required for curved subtraction of tire solid. |
| 05:51.07 | starseeker | should have said text to the shape names |
| 05:51.10 | starseeker | crud |
| 05:52.16 | pacman87 | you're writing C code to generate the tire? |
| 05:52.26 | starseeker | Ah, well - once I figure out the equation to automatically calculate the cutout and do some robustness testing, I should be ready for the next stage |
| 05:52.27 | starseeker | yep |
| 05:52.33 | starseeker | proc-db |
| 05:52.41 | starseeker | learning exercise |
| 05:58.13 | *** join/#brlcad clock_ (n=clock@217-162-111-204.dclient.hispeed.ch) | |
| 06:00.58 | *** join/#brlcad camcorder (n=draco@81.213.157.51) | |
| 06:20.52 | *** join/#brlcad clock_ (n=clock@217-162-111-204.dclient.hispeed.ch) | |
| 06:36.15 | *** join/#brlcad clock_ (n=clock@217-162-111-204.dclient.hispeed.ch) | |
| 06:39.22 | brlcad | starseeker: eep, you should only ever init once -- you trunc it thereafter |
| 06:40.14 | brlcad | very nice screenshot, though |
| 06:48.50 | *** join/#brlcad spike_ (i=[U2FsdGV@centaur.acm.jhu.edu) | |
| 06:50.33 | brlcad | late night, eh? |
| 06:55.42 | spike_ | nods |
| 07:32.17 | brlcad | burps, sips and wanders back to an editor |
| 08:05.42 | *** join/#brlcad clock_ (n=clock@zux221-122-143.adsl.green.ch) | |
| 08:16.04 | hippieindamakin8 | brlcad, thanks for accepting the patch Sean |
| 08:32.32 | spike_ | stumbles off to bed |
| 08:32.34 | spike_ | night guys |
| 09:21.28 | *** join/#brlcad yukonbob (i=1000@s142-179-54-198.bc.hsia.telus.net) | |
| 10:05.34 | *** join/#brlcad mafm (n=mafm@elnet-111.lip.pt) | |
| 10:08.21 | mafm | hi |
| 11:39.16 | *** join/#brlcad d_rossberg (n=rossberg@bz.bzflag.bz) | |
| 11:41.12 | d_rossberg | pacman87: i've send you an e-mail to your gmail account |
| 11:43.07 | clock_ | Is this GSoC somehow connected with gmail accounts? |
| 11:43.20 | clock_ | I once wanted to open a gmail account and realized the terms and conditions are unacceptable for me |
| 11:43.39 | clock_ | is like gmail account required to participate in the GSoC? |
| 11:44.50 | archivist | gmail is good for list type mail |
| 11:45.16 | clock_ | I didn't ask about features of gmail |
| 11:46.16 | d_rossberg | yes, you need an gmail account to subscribe |
| 11:46.40 | d_rossberg | but you don't need to use them for other things/communication |
| 11:47.38 | clock_ | and if the gmail accounts terms and conditions are unacceptable for you then you cannot participate on GSoC? |
| 11:48.47 | d_rossberg | as i said: you need the account to subscribe |
| 11:49.01 | archivist | bend your principles a bit, it wont hurt |
| 11:49.03 | clock_ | OK so the participation on GSoC is bound by the gmail terms and conditions |
| 11:49.54 | clock_ | archivist: your kind request is ignored |
| 11:50.08 | d_rossberg | but the gmail terms and conditions are not bound to all of your communication |
| 11:50.47 | clock_ | whatever - I am not interested in GSoC anyway |
| 11:50.58 | clock_ | I just wanted to know how Google behaves |
| 11:51.55 | d_rossberg | i use may account for GSoC only |
| 11:53.52 | clock_ | Global System of Censorship |
| 11:59.45 | starseeker | brlcad: Ah, sorry |
| 11:59.47 | starseeker | fixes |
| 12:02.48 | CIA-20 | BRL-CAD: 03starseeker * r30648 10/brlcad/trunk/src/proc-db/tire.c: Truncate the string to reset it correctly. |
| 12:29.23 | *** join/#brlcad clock_ (n=clock@zux221-122-143.adsl.green.ch) | |
| 13:02.12 | brlcad | actually, you need a "google account" -- you can turn any e-mail into a google account |
| 13:02.35 | brlcad | not just gmail |
| 13:09.09 | *** join/#brlcad Axman6 (n=Axman6@pdpc/supporter/student/Axman6) | |
| 13:14.30 | clock_ | brlcad: in that case you don't actually need to agree with their non-GSoC conditions to participate in GSoC? |
| 13:25.46 | brlcad | right |
| 13:27.47 | d_rossberg | and why did i created my gmail account last year? |
| 13:48.34 | brlcad | d_rossberg: my bad .. |
| 13:48.40 | brlcad | it was a pretty prevalent misconception |
| 13:48.50 | brlcad | only clarified this year |
| 13:51.29 | mafm | GSoC: We received more than 7,000 applications, compared with last year's count of 6,179; we look forward to bringing you more updates on applicant demographics over the next few days. |
| 13:51.47 | mafm | it seems that they got what they wanted, after all |
| 13:51.54 | brlcad | sorta |
| 13:52.06 | brlcad | this year fairs rather well for students |
| 13:52.28 | brlcad | student applications only increased by about 13% |
| 13:52.44 | brlcad | org/slots increased by about 30% |
| 13:53.19 | brlcad | so chances of getting accepted are considerably higher (on average) this year than they were last year |
| 13:54.38 | mafm | well, that depends mostly on the number of *students accepted*, not the number of orgs :) |
| 13:57.56 | brlcad | yes, but it's already been said that the number of slots will correspond to the increase in slots |
| 13:58.06 | brlcad | er increase in orgs |
| 13:58.32 | mafm | so ~1200 students |
| 15:04.47 | CIA-20 | BRL-CAD: 03bob1961 * r30649 10/brlcad/trunk/src/mged/ (ged.c mged.bat): Removed hack that was used to have output from rt apps show up in mged's command window in gui mode. |
| 15:39.11 | ``Erik | *yargn* |
| 15:47.48 | *** join/#brlcad SWPadnos (n=Me@dsl107.esjtvtli.sover.net) | |
| 16:35.12 | *** join/#brlcad andrecastelo (n=chatzill@189.71.7.20) | |
| 16:35.30 | andrecastelo | hey everyone |
| 16:35.39 | andrecastelo | hey mafm, brlcad |
| 16:52.05 | mafm | hi |
| 16:52.52 | CIA-20 | BRL-CAD: 03starseeker * r30650 10/brlcad/trunk/src/proc-db/tire.c: Redo the side subtractions, make tire input parameters variables |
| 17:05.04 | yukonbob | starseeker: how is this project going? Fun? Difficult? |
| 17:05.14 | yukonbob | waves in to the cadheads |
| 17:34.59 | pacman87 | waves back |
| 17:35.57 | pacman87 | yukonbob: give any more thought to your acoustic modelling? |
| 17:53.35 | yukonbob | pacman87: hey |
| 17:54.12 | pacman87 | hi |
| 17:54.25 | yukonbob | pacman87: re: accoustic modelling -- no haven't thought more about it -- I _have_ had the idea for ~1yr, though, so the idea isn't only 1week old to me... |
| 17:55.18 | yukonbob | what I need to do is start exploring the rt facilities and just "playing" -- then determining what "light models" map to what "sonic models" and sync-up parameters (I think) :) |
| 17:55.58 | *** join/#brlcad cad05 (n=91486201@bz.bzflag.bz) | |
| 18:00.58 | yukonbob | wonders out loud: /me wonders if the best way to process a scene would be to map single-bounce waves, and order by distance to determine the time (of audio signal), and then map double-bounces, and process the same, then triple, etc., etc. |
| 18:01.19 | yukonbob | s/waves/rasy |
| 18:01.22 | yukonbob | *rays |
| 18:03.10 | yukonbob | s/accoustic/acoustic/ |
| 18:03.13 | pacman87 | doing a breadth-first calculation? |
| 18:03.35 | pacman87 | wide and shallow first, then deeper and narrower |
| 18:04.27 | yukonbob | what do you mean by "wide" and "narrow"? |
| 18:04.48 | pacman87 | a depth-first approach would be to start with a direction |
| 18:04.56 | pacman87 | and trace it back to the sound source |
| 18:05.10 | pacman87 | with as many reflections as you want |
| 18:05.25 | pacman87 | then do the same with the next direction/ray |
| 18:05.51 | pacman87 | what you're saying is to get the first bounce from every direction |
| 18:06.00 | pacman87 | then get the second bounce from every direction |
| 18:06.09 | pacman87 | and so on |
| 18:06.57 | yukonbob | that's right -- seems most "intuitive" to me; but could just be naive? |
| 18:07.00 | pacman87 | ex: empty cubical room, with you and a sound source |
| 18:07.44 | pacman87 | yukonbob: i'm pretty sure it's faster to do depth-first |
| 18:08.25 | pacman87 | and you can keep track of the sound amplitude/volume too, and stop tracing the path back when its contribution gets too small |
| 18:09.56 | pacman87 | depth-first can be done recursively, so you keep track of the previous hit pints |
| 18:09.58 | pacman87 | points |
| 18:10.04 | yukonbob | pacman87: the way I'm imagining the processing would be doing the breadth-first, then processing all those "same level" items for time/spatialization, so it's closer to producing "serial" output |
| 18:10.34 | yukonbob | re: depth-first and too-small contributions -- that's a good point... |
| 18:11.10 | pacman87 | i'm saying you'd be redoing a lot of the work finding the second level that was already done for the first level |
| 18:11.16 | yukonbob | nods |
| 18:12.01 | yukonbob | right -- I'd end up w/ some exponential Order |
| 18:13.46 | pacman87 | for each hit, you'd need to check the direct path to the source, the reflected path (from the surface normal), and the transmitted path (through the object, direction depends on surface normal and speed of sound outside/inside the material, similar to index of refraction) |
| 18:14.14 | pacman87 | and for each of those, you'd do the same thing again |
| 18:15.49 | pacman87 | and stop when you get to your preset maximum path length to disregard the insignifigant parts |
| 18:18.58 | pacman87 | of course, this all assumes that the objects are not affected by the sound waves. i'm not sure how you'd go about modelling the actual objects vibrating |
| 18:20.44 | brlcad | yukonbob: have you looked at the brl-cad docs for writing a new ray-trace-based application? |
| 18:20.59 | brlcad | what you suggest shouldn't be all that much work to do |
| 18:23.40 | *** join/#brlcad clock_ (n=clock@77-56-83-126.dclient.hispeed.ch) | |
| 18:28.07 | ``Erik | http://bash.org/?854899 |
| 18:33.43 | brlcad | :) |
| 18:33.45 | yukonbob | brlcad: I've probably seen them, but haven't reviewed them critically with this application in mind.. |
| 18:34.08 | ``Erik | handling interference would be the hard part, I'd imagine |
| 18:34.46 | brlcad | basically it's a fairly simple way to write apps that need to do energy/interaction simulations |
| 18:35.53 | brlcad | http://brlcad.org/wiki/Example_Application |
| 18:36.18 | brlcad | or the more detailed http://brlcad.org/w/images/3/3d/Application_Development.pdf |
| 18:37.06 | mafm | bye |
| 18:37.25 | yukonbob | brlcad: cool |
| 18:37.27 | brlcad | cya mafm |
| 18:37.27 | yukonbob | reviews |
| 18:37.34 | yukonbob | ciao mafm |
| 18:38.19 | brlcad | basically it alll centers around calling rt_shootray() -- you shoot a ray and have it do this or that if you hit or miss |
| 18:39.39 | brlcad | so creating an image is basically shooting a grid of rays with rt_shootray(), for every miss you have background color, for every hit you color the pixel based on what you hit |
| 18:40.14 | pacman87 | brlcad: i just replied to d_rossberg's email, you're cc'd |
| 18:40.15 | brlcad | doing a simulation might involve shooting a "burst cloud" or rays with rt_shootray() and for every hit, shoot another burst cloud, recursively |
| 18:40.21 | brlcad | pacman87: okay |
| 18:41.03 | ``Erik | we need the grid generation crap hoisted into librt :/ |
| 18:41.06 | brlcad | I've not read the initial exchange in detail myself, but it sounds like a lot of the discussion is about sweeping, not revolutions |
| 18:41.34 | brlcad | thinks "solids of revolution" when he reads a revolve -- which are fairly well-defined |
| 18:41.36 | pacman87 | well, the revolution is a special case of a sweep |
| 18:42.01 | brlcad | sure, it's a subset, but the math behind that subset is a helluvalot simpler :) |
| 18:42.28 | brlcad | particularly for implementing things like tess() and plot() |
| 20:07.32 | *** join/#brlcad Elperion (n=Bary@p548774BC.dip.t-dialin.net) | |
| 20:21.47 | prasad_ | what's the best yacc implementation these days |
| 20:21.53 | prasad_ | bison or byacc? |
| 20:24.18 | ``Erik | best for what? O.o bison is the gnu version, byacc is the bsd version... different philosophies |
| 20:24.35 | prasad_ | ic |
| 20:25.01 | prasad_ | best for getting a passing grade |
| 20:25.02 | prasad_ | :o |
| 20:25.44 | yukonbob | prasad_ what are you trying to do? |
| 20:26.20 | prasad_ | modify the yacc spec of this compiler for my class |
| 20:26.32 | prasad_ | dling bison for cygwin right now |
| 20:26.37 | ``Erik | if the spec works with byacc, it's damn solid... bison is ... extended |
| 20:26.40 | prasad_ | so hoping it'll be enough |
| 20:27.31 | prasad_ | erik the defender of bsd |
| 20:27.34 | prasad_ | ;) |
| 20:44.31 | *** join/#brlcad hippieindamakin8 (n=hippiein@210.212.55.3) | |
| 20:49.30 | *** join/#brlcad prasad_ (n=psilva@h-67-103-183-185.mclnva23.covad.net) | |
| 20:51.38 | *** join/#brlcad prasad_ (n=psilva@static-70-108-244-218.res.east.verizon.net) | |
| 20:52.09 | *** part/#brlcad prasad_ (n=psilva@static-70-108-244-218.res.east.verizon.net) | |
| 20:52.25 | *** join/#brlcad prasad_ (n=psilva@static-70-108-244-218.res.east.verizon.net) | |
| 21:22.18 | ``Erik | defender of tools that "just work, damnit" :D |
| 22:43.32 | yukonbob | in prasad_'s case, the answer for "which tool" is "whatever tool that grammar is for" |
| 23:04.06 | ``Erik | I thought I'd alluded to that, but I guess I wasn't very clear :D |
