IRC log for #brlcad on 20080428

00:15.02 CIA-20 BRL-CAD: 03brlcad * r30885 10/brlcad/trunk/src/libged/CMakeLists.txt: add the missing CMakeLists.txt file for libged
00:17.21 CIA-20 BRL-CAD: 03brlcad * r30886 10/brlcad/trunk/ (7 files in 4 dirs): move nirt.c to libged, it's a dgo ged command
00:28.05 ``Erik because you can't spell slaughter without laughter O.o
00:32.22 CIA-20 BRL-CAD: 03brlcad * r30887 10/brlcad/trunk/include/mater.h: add header reinclusion protections and include raytrace.h for struct region
00:49.35 CIA-20 BRL-CAD: 03brlcad * r30888 10/brlcad/trunk/ (14 files in 4 dirs): move vdraw.c, bigE.c, and qray.c from librt to libged too. that should be the remaining dgo functionality.
02:42.54 CIA-20 BRL-CAD: 03brlcad * r30889 10/brlcad/trunk/include/raytrace.h: ws
02:43.56 CIA-20 BRL-CAD: 03brlcad * r30890 10/brlcad/trunk/src/librt/opennurbs_ext.cpp: get rid of the using statement, make namespace use explicit
03:01.45 CIA-20 BRL-CAD: 03brlcad * r30891 10/brlcad/trunk/src/librt/ (9 files):
03:01.45 CIA-20 BRL-CAD: more migration of global vars to globals.c .. move rt_uniresource, nmg_eue_dist,
03:01.45 CIA-20 BRL-CAD: and the three nmg callback globals: nmg_plot_anim_upcall,
03:01.45 CIA-20 BRL-CAD: nmg_vblock_anim_upcall, nmg_mged_debug_display_hack. includes a periphery
03:01.45 CIA-20 BRL-CAD: cleanup and conversion of some globals to static
03:40.49 CIA-20 BRL-CAD: 03brlcad * r30892 10/brlcad/trunk/ (4 files in 3 dirs): remove rt_nfunctab global, not really needed/useful as-is
03:47.36 CIA-20 BRL-CAD: 03brlcad * r30893 10/brlcad/trunk/src/librt/globals.c: rt_functab is too big to import, just reference it
04:00.34 CIA-20 BRL-CAD: 03brlcad * r30894 10/brlcad/trunk/include/raytrace.h: comment cleanup
04:17.48 CIA-20 BRL-CAD: 03brlcad * r30895 10/brlcad/trunk/src/librt/ (g_arb.c globals.c): move the arb8 globals over to globals.c including the edit arb arrays and rt_arb_faces; with cleanup
04:33.52 CIA-20 BRL-CAD: 03brlcad * r30896 10/brlcad/trunk/src/librt/ (g_cline.c globals.c): move rt_cline_radius to globals.c plus cleanup
04:34.09 CIA-20 BRL-CAD: 03brlcad * r30897 10/brlcad/trunk/include/raytrace.h: ws
04:36.19 poolio Wow.
04:51.51 CIA-20 BRL-CAD: 03brlcad * r30898 10/brlcad/trunk/src/librt/ (g_bot.c globals.c): move rt_bot_minpieces and rt_bot_tri_per_piece over from g_bot.c to globals.c; with comment cleanup
06:07.36 CIA-20 BRL-CAD: 03brlcad * r30899 10/brlcad/trunk/include/magic.h: consolidate all public magic numbers into a single 'registry' so that structures can be uniformly validated in libbu
06:08.30 CIA-20 BRL-CAD: 03brlcad * r30900 10/brlcad/trunk/include/ (13 files): consolidate all public magic numbers into a single 'registry' in magic.h so that structures can be uniformly validated in libbu
06:09.42 CIA-20 BRL-CAD: 03brlcad * r30901 10/brlcad/trunk/src/libbu/rb_internals.h: push bu_rb's magic numbers up into magic.h, clean up comments
06:10.29 CIA-20 BRL-CAD: 03brlcad * r30902 10/brlcad/trunk/src/libbu/magic.c: no longer need all header numbers under the sun. this should help keep libbu decoupled properly. just include magic.h
06:16.17 CIA-20 BRL-CAD: 03brlcad * r30903 10/brlcad/trunk/include/magic.h: leave a note that this header should be considered a PRIVATE header and should NEVER refer to the specific define values.
06:17.00 CIA-20 BRL-CAD: 03brlcad * r30904 10/brlcad/trunk/include/Makefile.am: bu.h needs magic.h, install it
06:54.35 CIA-20 BRL-CAD: 03brlcad * r30905 10/brlcad/trunk/src/librt/globals.c: ws
07:00.36 *** join/#brlcad clock_ (n=clock@zux221-122-143.adsl.green.ch)
07:00.50 CIA-20 BRL-CAD: 03brlcad * r30906 10/brlcad/trunk/TODO: seems to be pretty pervasive that the framebuffer isn't refreshing, at least linux and mac under X11 aren't behaving properly. they only refresh when the window is forcibly refreshed (dirty rect0
07:33.22 *** join/#brlcad d_rossberg (n=rossberg@bz.bzflag.bz)
07:37.38 CIA-20 BRL-CAD: 03brlcad * r30907 10/brlcad/trunk/src/librt/shoot.c: reorder functions so forward declaration of rt_plot_cell() isn't necessary
07:40.12 CIA-20 BRL-CAD: 03brlcad * r30908 10/brlcad/trunk/src/librt/spectrum.c: make global a static along with some header cleanup
07:47.34 CIA-20 BRL-CAD: 03brlcad * r30909 10/brlcad/trunk/src/librt/table.c: give them semicolons regardless so that they indent correctly by automatic .. might have been solaris complaining originally, but see if it's still a concern (gcc is fine with the '};')
07:49.55 CIA-20 BRL-CAD: 03brlcad * r30910 10/brlcad/trunk/src/librt/transform.c: cleanup
08:02.38 CIA-20 BRL-CAD: 03brlcad * r30911 10/brlcad/trunk/src/librt/ (globals.c tree.c vers.c vlist.c): move (last?) two remaining straggler globals, rt_initial_tree_state and rt_vlist_cmd_descriptions, over to globals.c; tidy up while going along.
08:09.58 d_rossberg brlcad: i tried to post to the mentors-list but i got an error message
08:10.19 d_rossberg but i can see the message appended to the thread too
08:11.18 d_rossberg so, have you seen something from me (probable not)
08:25.02 *** join/#brlcad Axman6 (n=Axman6@pdpc/supporter/student/Axman6)
10:00.52 mafm allo
10:01.21 mafm if somebody tried to speak with me during the weekend, I was not here
10:01.30 mafm it seems that the client got reconnected for some reason
10:02.34 mafm and the log is not that big to save what you people told to me
11:50.44 *** join/#brlcad thing1 (n=ric@58.171.91.143)
12:00.15 brlcad d_rossberg: no, I had not
12:02.15 brlcad d_rossberg: common problem on some brosers is that your session expires while composing, should make sure you're actually logged in (try changing an account setting)
12:06.59 brlcad which thread, what error?
12:07.37 brlcad mafm: tis alright .. if it's important, they can say it again :)
12:07.44 d_rossberg the error was a gmail/googlemail confusion
12:08.22 d_rossberg the subscription was for gmail but i tried to send a post from a googlemail account
12:09.22 brlcad can you log into google groups using gmail ?
12:09.30 brlcad or trying to post via e-mail?
12:10.13 brlcad which thread, I can verify I don't see anything
12:10.34 *** join/#brlcad SWPadnos_ (n=Me@dsl107.esjtvtli.sover.net)
12:12.15 d_rossberg the thread was: Let the introductions begin! :)
12:13.10 d_rossberg it looks like there no real difference between gmail and googlemail
12:15.01 d_rossberg i.e. if you send something to somebody with a googlemail account with @gmail it will reach the addressee
12:42.20 mafm there are more quirks even
12:42.44 mafm if you have a.b.c@gmail.com, all combinations not including dots get to the same person
12:43.24 mafm in my case, manuel.montezelo@ or manuelmontezelo@ or m.a.n.u.e.l.etc@gmail.com get to my inbox anyway
12:45.29 ``Erik weird
12:46.41 mafm I knew about that when a neighbor sent me a mail, she missed the dot, and it got into my inbox anyway
12:46.43 mafm :)
12:51.35 d_rossberg but obviously their error tolerance is limited :|
13:05.54 ``Erik how's this for damn odd, when I originally got my gmail account, I had to put a dot in it because it said it was taken... but both the one I wanted and the one I got go to my dotted address O.o
13:09.54 mafm yep, that caused problems sometimes
13:10.01 mafm but I don't know how it's resolved
13:10.17 mafm (that's what I read a few months ago, didn't put much attention to it)
13:22.24 ``Erik pheer, fuzzy matching email addresses O.o hope you don't have important bits sent through gmail :D
13:35.09 ``Erik awesome, a core dump out of pine
13:49.20 mafm well, actually I use it normally without problems
13:54.05 brlcad d_rossberg: they may be moderated/pending given that thread already has 400+ posts
13:54.21 brlcad there was a comment the other day about how people were still posting to that thread :)
13:54.26 brlcad after bart's message
13:56.05 ``Erik huh, bill kendrik is in gsoc, too
14:00.49 CIA-20 BRL-CAD: 03brlcad * r30912 10/brlcad/trunk/include/ (magic.h mater.h): wtf was I smoking .. don't cross the streams ray
14:01.12 ``Erik heh, ironical that I'd just read the second on the wiki about good commit messages and bad ones *smirk*
14:01.36 brlcad :)
14:02.55 d_rossberg brlcad: anyway, i'll repost it today evening
14:03.30 brlcad d_rossberg: okay, I'll ask lh if anything is up
14:03.56 brlcad she won't be on for a couple hours still
14:04.16 *** join/#brlcad prasad_ (n=psilva@h-67-103-183-185.mclnva23.covad.net)
14:05.32 ``Erik thinks he needs to buy a power sander and a couple cans of wood stain and sealant before he pressure washes his deck O.o
14:05.45 d_rossberg brlcad: i hope i've successfully switched the subscription to my googlemail account, thats why i hope it will work now
14:05.46 ``Erik sucker not only takes away the dirt and moss, but paint, stain, wood, ...
14:05.58 *** join/#brlcad prasad_ (n=psilva@70.108.244.218)
14:06.37 *** join/#brlcad docelic (n=docelic@78.134.192.202)
14:17.00 CIA-20 BRL-CAD: 03brlcad * r30913 10/brlcad/trunk/include/mater.h: add DECL wrappers for C++ compilation
14:18.18 CIA-20 BRL-CAD: 03brlcad * r30914 10/brlcad/trunk/include/dg.h: add proper file header docs for what this header is and is for
14:20.44 CIA-20 BRL-CAD: 03brlcad * r30915 10/brlcad/trunk/include/ (Makefile.am ged.h raytrace.h): add ged.h to the header list for the new LIBGED. it provides the declarations for wdb_obj, view_obj, and indirectly for dg_obj (through dg.h)
14:29.22 ``Erik huh, dave wheeler is, too O.o lots of old faces poppingup
14:32.59 *** join/#brlcad andrecastelo (n=chatzill@189.71.7.205)
14:33.11 andrecastelo hey everyone :D
14:33.28 ``Erik howdy
14:33.47 andrecastelo hey ``Erik, what's up?
14:34.20 ``Erik not much, relaxing at home, watching the rain and updating a few fbsd machines
14:35.29 ``Erik reading up on this gsoc mentor traffic, sheesh there's a lot O.o sure hope it dies down a bit :D
14:36.16 andrecastelo if you think that's a lot of traffic, you haven't seen the student list :D
14:37.44 andrecastelo ``Erik: also, http://andrecastelo.wordpress.com
14:38.34 ``Erik awesome
14:38.39 brlcad andrecastelo: sweet
14:38.55 ``Erik I was about to harrass brlcad about finishing the migration to the new machine so we could set up some blog software for gsoccers
14:39.37 andrecastelo hehehe
14:40.32 ``Erik I also had a minor brain queef this morning about a good 'baby step' for the MLT work... claiming a light model # and stubbing it to a simple flat shader or something to get a feel for the guts and small patch, and to get an 'ugly detail' out of the way up front
14:41.31 ``Erik d'no if it's a good idea, just throwing it out there for people to comment on O:-)
14:42.41 ``Erik woops, you're in trouble now, andré, I have that page bookmarked
14:42.54 CIA-20 BRL-CAD: 03brlcad * r30916 10/brlcad/trunk/src/libged/ (8 files): header and identity cleanup, add them to a libged group for doxygen. removed unused headers and clean up some comments
14:43.13 brlcad ``Erik: you were thinking of adding it as a lighting model to rt?
14:43.34 ``Erik yeah, why, you were thinking of having rtmlt?
14:45.18 brlcad yeah, not strongly, but I'd thought something like 'pt' that used the same raytrace interface as the other rt* apps, but did its own thing
14:46.11 brlcad or whatever it'd get named, that wasn't so important
14:46.17 ``Erik hm, we seem to have two competing precedents going :)
14:47.24 brlcad yeah, and probably either can work for this
14:47.43 ``Erik <-- kinda figured the light model approach would be a bit easier and quicker
14:48.00 andrecastelo couldn't we add the bidirectional path tracer to RT and the rest of the MLT to something like rtmlt?? then it would be easier later to add lighting models that use the path tracer
14:48.15 brlcad the tradeoff is probably the fact that rt's option namespace is full and you wouldn't have to weed through as much regarding the assumptions in rt that it's not a path tracker
14:48.40 ``Erik photon mapping offers an approach, arcane as it is
14:49.07 brlcad andrecastelo: MLT is bidirectional path tracing
14:49.41 brlcad photon mapping isnt' just arcane, it was shoed in totally half-assed
14:49.48 andrecastelo yeah, the rest i was talking about is really small (the mutation part)
14:50.11 ``Erik it's a modified bidirectional path tracing, the 'raw' pathtracing that rise does is also bidirectional path tracing, but far more brute force
14:50.14 ``Erik iiuc
14:51.30 brlcad andrecastelo: yeah, I don't think that distinction matters here -- the difference from rt's perspect is where you hook in the logic; rt has lighting models that modify the manner in which rays are fired, rt *apps* fully override the ray-trace 'view' interface to do something similar
14:52.34 brlcad mlt is that, but the distinction at this point is .. pointless .. it doesn't matter for whether it's a light model or a new bin or really affect how it's named, that's just a couple lines in the docs
14:53.23 andrecastelo i see
14:53.25 ``Erik the state of things is a bit confusing :)
14:53.42 andrecastelo but would mlt be chosen just as photon mapping is?? (the number thing Erik was talking about)
14:55.00 brlcad andrecastelo: that is the question at hand..
14:55.36 brlcad regardless of photon mapping (which *really* is a bad example to follow) .. the issue boils down to either making another binary app for this, or hooking it into rt
14:56.15 brlcad hooked into rt, it has to be optional and default off of course -- so that means it would have to be a lighting model and maybe rewrite some other pieces of rt that assume direct ray-tracing
14:57.22 ``Erik (should we put "unfuck photon mapping interface" in the todo?)
14:59.38 andrecastelo I guess i was following photon mapping example too much :D
15:00.55 brlcad as a new application, it means you have less to deal with wrt existing code but you also loose "some" of the infrastructure that rt already provides (e.g. gamma settings, some parallel bits, framebuffer hooks) that you'd have to implement (at least some of)
15:07.56 brlcad ``Erik: could put that in the todo .. it's about in as usable a state though as adrt was .. almost amounts to rewriting most of it for it to be actually useful
15:09.23 brlcad even when it works, it doesn't do anything useful really and that's aside from how it was tacked in the code throughout optical and rt
15:12.57 ``Erik <-- wouldn't mind seeing it kluge geometry by adding a bounding cube/sphere and light source of they're not found... *shrug*
15:13.56 brlcad there are already light sources, just not with the "right" settings for photomapping to work
15:14.04 brlcad *default* lights
15:15.00 ``Erik yeah, the box is the killer for that one, I'd imagine
15:15.14 ``Erik oh, and the light can't have a diameter of 0, heh :D
15:15.14 brlcad the bounding cube/sphere could be useful but the reason that's needed was mainly because it doesn't bother to check where the model is
15:34.37 CIA-20 BRL-CAD: 03brlcad * r30917 10/brlcad/trunk/include/solid.h: header needs bu.h and raytrace.h to be self-contained
16:03.04 CIA-20 BRL-CAD: 03brlcad * r30918 10/brlcad/trunk/ (8 files in 3 dirs):
16:03.04 CIA-20 BRL-CAD: add a globals.c to the build for libged with the single global it presently
16:03.04 CIA-20 BRL-CAD: uses. removed one of the other vdraw globals by making the interface between
16:03.04 CIA-20 BRL-CAD: vdraw and dg clean enough that the command table could be made static.
16:20.35 CIA-20 BRL-CAD: 03brlcad * r30919 10/brlcad/trunk/configure.ac: generate POSIX 1003.1-1988 tarballs (256 char paths, allows empty dirs, pretty portable), not the default V7 tar format (which limits to 99 char paths and no empty dirs)
16:22.34 CIA-20 BRL-CAD: 03brlcad * r30920 10/brlcad/trunk/configure.ac: bah, tar-ustar is 1.9+
17:25.55 *** join/#brlcad Elperion (n=Bary@p54877B87.dip.t-dialin.net)
18:19.27 CIA-20 BRL-CAD: 03starseeker * r30921 10/brlcad/trunk/src/proc-db/tire.c: Add extra trimming for 'truck' profile to avoid tread looking like it is flaring out.
18:19.55 starseeker now has to redo screenshots again... arrrgh...
18:34.14 CIA-20 BRL-CAD: 03starseeker * r30922 10/brlcad/trunk/src/proc-db/tire.c: Tweak truck tread to clear up cut artifacts.
19:01.00 mafm bye
19:19.48 *** join/#brlcad clock_ (n=clock@217-162-111-165.dclient.hispeed.ch)
19:43.09 *** join/#brlcad clock__ (n=clock@217-162-111-165.dclient.hispeed.ch)
21:51.12 *** join/#brlcad MTee (n=MT@41.233.136.28)
21:52.20 CIA-20 BRL-CAD: 03brlcad * r30923 10/brlcad/trunk/src/libged/globals.c: erm, lost the header. need dg.h to calculate the storage size of HeadDGObj.
22:12.21 CIA-20 BRL-CAD: 03brlcad * r30924 10/brlcad/trunk/src/mged/cmd.c: needs to call vdraw_cmd(), was renamed from dgo_vdraw_cmd()
22:13.03 CIA-20 BRL-CAD: 03brlcad * r30925 10/brlcad/trunk/include/ged.h: declare a Ged_Init() Tcl interface for libged
22:18.59 CIA-20 BRL-CAD: 03brlcad * r30926 10/brlcad/trunk/src/librt/tcl.c: remove the calls to Wdb_Init, Dg_Init, Vo_Init from librt since they're no longer in librt ... they need to be provided by libged if needed so there's not a cyclic dependency. big ws cleanup too.
22:20.26 CIA-20 BRL-CAD: 03brlcad * r30927 10/brlcad/trunk/ (4 files in 2 dirs): initial tcl interface to libged so we can call Wdb_Init, Dgo_Init, and Vo_Init and provide Ged_Init for dynamic loading from within tcl.
22:48.42 CIA-20 BRL-CAD: 03brlcad * r30928 10/brlcad/trunk/src/libged/Makefile.am: need TCL_CPPFLAGS now that there are tcl routines..
22:49.11 CIA-20 BRL-CAD: 03brlcad * r30929 10/brlcad/trunk/configure.ac: GED_LIBS needs to come *after* RT_LIBS if w'ere going to use it.
22:53.19 CIA-20 BRL-CAD: 03brlcad * r30930 10/brlcad/trunk/src/Makefile.am: librtserver doesn't need libged to move it to benchmark dirs
23:34.55 CIA-20 BRL-CAD: 03brlcad * r30931 10/brlcad/trunk/configure.ac: libdm uses HeadDGObj and drawable geometry now in libged

Generated by irclog2html.pl Modified by Tim Riker to work with infobot.