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 |