00:00.51 |
starseeker |
dreeves: here's the other screenshot with the
uncommented code: http://bzflag.bz/~starseeker/d2_270_0_2.png |
00:02.10 |
Ralith |
also nice! |
00:18.55 |
CIA-28 |
BRL-CAD: 03indianlarry * r34234
10/brlcad/trunk/src/conv/asc2g.c: renamed getline() to
gettclblock() |
00:24.48 |
starseeker |
these are somewhat interesting: http://bzflag.bz/~starseeker/dented_sphere.png |
00:24.58 |
starseeker |
http://bzflag.bz/~starseeker/dented_sph_surf_norm.png |
00:27.29 |
Ralith |
that doesn't look dented so much as
holed |
00:27.54 |
louipc |
blind hole |
00:28.11 |
louipc |
needs isometric view |
00:28.14 |
starseeker |
It does appear to represent a removal rather
than a surface distortion |
00:31.51 |
starseeker |
the surface normal coloring, however, should
be fairly unambiguous |
00:32.27 |
starseeker |
if it were an outward distortion, I would
expect the color gradient to run in the same general direction as
that of the main sphere |
00:38.09 |
starseeker |
is beginning to think it
might be useful to have the option to draw more complete wireframes
for the nurb primitives, corresponding to their
structure |
00:38.37 |
starseeker |
relating a raytrace to the underlying
surfaces, edges, etc just by numbers may be a bit tricky |
00:42.38 |
brlcad |
starseeker: can you create two spheres that
match the dented sphere perfectly? |
00:42.59 |
starseeker |
I can try |
00:43.04 |
starseeker |
one second |
00:44.03 |
brlcad |
would be interesting to run pixdiff/pixcmp on
the results if the original radii and position values are
derivable |
00:44.13 |
starseeker |
hmm |
00:44.24 |
starseeker |
not easily, at least from the l
output |
00:45.05 |
brlcad |
can't believe he owes so much
this year |
00:45.20 |
starseeker |
winces |
00:45.30 |
starseeker |
doing the late night post office thing?
;-) |
00:45.46 |
brlcad |
oh hell no, stopped that 5/6 years
ago |
00:45.56 |
starseeker |
online then? |
00:45.59 |
brlcad |
e-file |
00:46.02 |
brlcad |
yeah |
00:46.03 |
starseeker |
nods |
00:46.10 |
starseeker |
that's how I did it too, except for
VA |
00:46.23 |
brlcad |
used to do it all by hand, an all-day event,
many forms, all the instructions and subforms |
00:46.54 |
starseeker |
yuck |
00:47.00 |
brlcad |
until one year it got so bad that I worked on
them for about 20 hours non-stop (and I knew what I was doing!) and
was still running up against the deadline |
00:47.15 |
starseeker |
dreeves: fwiw, I can confirm that the rebuilt
sphere is manifesting as holes |
00:47.30 |
brlcad |
I had about two-hours till midnight (blen
burnie office was open till midnight), went on-line |
00:47.40 |
brlcad |
did the whole thing in less than half an
hour |
00:47.47 |
Ralith |
odamn |
00:47.54 |
Ralith |
that must have been a little
frustrating. |
00:48.08 |
brlcad |
it was more amazing |
00:48.09 |
Ralith |
after 20 hours of work |
00:48.39 |
brlcad |
I was dubious that it'd be at all right with
all the various forms I had (self-employed, depreciation tables,
multiple sources of income, etc) |
00:49.30 |
brlcad |
since it asked more in a wizard-style
interface, asking lots of questions |
00:50.08 |
brlcad |
I was already 95% done on paper, so I actually
had everything in front of me to verify and it all matched up
nicely |
00:50.16 |
brlcad |
so never again after that |
00:50.40 |
brlcad |
this year was hell though, even on-line ...
for many reasons |
00:51.18 |
brlcad |
worst. tax-year. ever. (for me) |
00:52.44 |
brlcad |
orders some comfort
food |
00:57.17 |
starseeker |
figures new house made things
nice and complex... |
00:57.28 |
brlcad |
it did |
00:57.41 |
brlcad |
insanely so |
00:57.53 |
brlcad |
especially purchasing near the end of the
year |
00:58.00 |
starseeker |
ow |
00:58.08 |
yukonbob |
what about the cocaine and hookers from your
rockstar lifestyle as a BRL-CAD developer? |
00:58.17 |
``Erik |
hehehe |
00:58.38 |
starseeker |
would hire a CPA or something
rather than deal with the headache of truly complex
taxes... |
00:58.46 |
brlcad |
yukonbob: they're paid under the table,
*shhh* |
00:58.52 |
yukonbob |
heh |
00:58.53 |
``Erik |
yes, we take private jets when we go out for
lunch and all that, and wear leather pants |
00:59.05 |
yukonbob |
LOL leather pants |
00:59.10 |
yukonbob |
hawt |
00:59.11 |
yukonbob |
! |
00:59.17 |
``Erik |
yes, they are, a lot of chaffing |
00:59.36 |
starseeker |
scowls at rebuilt
sphere |
01:00.35 |
starseeker |
gonna need some way to know what we're
raytracing within the nurb and how close it is to any
edges/verticies/etc |
01:02.34 |
``Erik |
hm, since opennurbs has a container for a
straight up brep surface, ya think the utah teapot might be a good
geometry to experiment with? |
01:02.52 |
starseeker |
could be |
01:03.01 |
``Erik |
iirc, it's just 16 control points |
01:03.51 |
brlcad |
teapot isn't solid geometry |
01:04.04 |
``Erik |
wait, no, 28 patches in the original |
01:04.14 |
brlcad |
handling non-solid ON_Brep objects hasn't been
looked into |
01:04.40 |
``Erik |
ah, okie, I figured it might be magically
handled in the guts of opennurbs :) *shrug* |
01:05.52 |
starseeker |
this is probably informative once it can be
related to the nurbs surfaces: http://bzflag.bz/~starseeker/rebuilt_sphere_270_0.png |
01:05.59 |
brlcad |
same surface intersection and trimming logic,
but that all has to be handled up in the shot() routine |
01:07.51 |
hippieindamakin8 |
silently
observes. |
01:08.08 |
starseeker |
it's almost as if the surfaces are being
rendered up to some maximum absolute x, y or z and then
nothing |
01:08.08 |
brlcad |
not so silent :) |
01:08.16 |
hippieindamakin8 |
:P |
01:09.15 |
starseeker |
will have to take a hard look
at how the line renderings are done and see if edges can be
incorporated as an option |
01:09.53 |
starseeker |
if those it would be helpful to be able to see
the makeup of the surfaces |
01:11.00 |
starseeker |
suppose it can be compared with the complete
sphere... |
01:11.09 |
starseeker |
alright, I'm getting out of here :-) |
01:11.12 |
starseeker |
bbl |
01:29.42 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-146.sbndin.btas.verizon.net) |
01:37.36 |
dreeves |
starseeker yes I confirmed last night it was
holes. BTW it is entirely possible to see dark spots with out the
slow change in color. I have seen cases where were on the edge of
a surfaces and it calculates a normal perpendicular to the ray. In
order to confirm it wasn't that I checked every normal and when one
was near perpendicular I reset to reverse the ray direction which
will make the pixel light up they didn't |
01:39.34 |
dreeves |
so obviously it was a hole which really
surprised me because I wasn't getting errors for odd number of hit
points. If it missed on the front it should have hit on the other
side and reported errors. I isn't which means it isn't only
missing the front but also the surface behind it |
01:41.23 |
dreeves |
that is what drove me to rt from different ae
when I noticed everything went to hell in a hand basket pdq. Was
some what encouraging though believe it or not because at least it
isn't wasn't a tolerance problem. Just dealing with something
wrong. |
01:44.59 |
dreeves |
I don't think it is anything real serious
because obviously we are able to calculate intersection and appear
to that we somewhat understand the trim geometry. BTW I can turn
off trimming and still see the problem so this isn't trimming doing
this. |
01:47.35 |
dreeves |
The front side it is scary because it looks
like an edge but I don't think it is because when I shot from the
other angle a lot more was missing than an edge. IMO something is
going on with interpretation of the geometry that is causing the
problem |
01:48.03 |
brlcad |
dreeves: note that the phong shader will
automatically flip a backward-facing normal |
01:48.37 |
brlcad |
should see "shade_inputs(object) flip N ..."
messages if it does |
01:50.33 |
dreeves |
yeah I new that was the case but if it is near
perpendicular and not perpendicular or more I was thinking it might
not be flipping that |
01:50.59 |
dreeves |
either was it is definitely a hole |
01:51.15 |
brlcad |
yeah, if it's just "nearly" perpendicular,
it'll come back |
01:51.37 |
dreeves |
are you saying it will flip it? |
01:51.39 |
brlcad |
BN_VECT_ARE_PERP() is using the default
tolerance |
01:51.53 |
brlcad |
if it's nearly perpendicular, it
won't |
01:52.03 |
dreeves |
right that was my thinking |
01:53.15 |
dreeves |
The delay in me working this isn't because I'm
struggling I just got busy on the day job. I'm actually pretty
confident we can fix this pdq |
01:53.47 |
dreeves |
I was worried when I thought it was a
tolerance issue but now that I know it isn't I feel
better |
01:54.48 |
*** join/#brlcad dtidrow
(n=Don@c-68-62-76-34.hsd1.mi.comcast.net) |
01:55.37 |
brlcad |
nods |
01:55.50 |
brlcad |
there are plenty of tolerance issues
remaining, no worries there ;) |
01:58.58 |
dreeves |
nods :) |
02:36.56 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-146.sbndin.btas.verizon.net) |
02:53.33 |
*** join/#brlcad
AlexandreGuedes
(n=chatzill@189-92-165-117.3g.claro.net.br) |
03:30.36 |
*** join/#brlcad madant_
(n=madant@117.196.128.248) |
03:39.04 |
PrezKennedy |
wtf |
03:46.37 |
*** join/#brlcad _pseudony
(n=irchon@wireless-128-62-173-79.public.utexas.edu) |
03:48.17 |
_pseudony |
/nick _pseudonym |
03:48.59 |
pacman87 |
hmm, seems to be some bugs/omissions in the
ipod touch irc client i'm trying |
03:50.16 |
*** join/#brlcad
AlexandreGuedes_
(n=chatzill@189-92-165-117.3g.claro.net.br) |
03:52.25 |
*** join/#brlcad _pseudony
(n=irchon@wireless-128-62-173-79.public.utexas.edu) |
03:54.41 |
*** join/#brlcad _pseudony
(n=irchon@wireless-128-62-173-79.public.utexas.edu) |
03:56.02 |
*** join/#brlcad _pseudony
(n=irchon@wireless-128-62-173-79.public.utexas.edu) |
03:57.07 |
*** join/#brlcad _pseudony
(n=irchon@wireless-128-62-173-79.public.utexas.edu) |
03:57.53 |
*** join/#brlcad _pseudony
(n=irchon@wireless-128-62-173-79.public.utexas.edu) |
03:58.04 |
pacman87 |
sorry about the join/part spam :( |
04:00.00 |
*** join/#brlcad _pseudony
(n=irchon@wireless-128-62-173-79.public.utexas.edu) |
04:01.52 |
*** join/#brlcad pacman_87
(n=irchon@wireless-128-62-173-79.public.utexas.edu) |
04:03.58 |
*** join/#brlcad poolio
(i=poolio@LEAF.RES.CMU.EDU) |
04:04.08 |
poolio |
Err, did bzflag get klined? |
04:22.22 |
*** join/#brlcad madant
(n=madant@117.196.128.248) |
04:28.44 |
PrezKennedy |
looks like it |
04:28.52 |
PrezKennedy |
whole bunch of you guys got dumped at
once |
04:38.10 |
*** join/#brlcad
AlexandreGuedes_
(n=chatzill@189-92-165-117.3g.claro.net.br) |
05:07.02 |
*** join/#brlcad elena
(n=opera@92.86.0.28) |
05:31.51 |
*** join/#brlcad elite01
(n=omg@unaffiliated/elite01) |
05:38.01 |
*** join/#brlcad madant
(n=d@117.196.148.46) |
06:15.20 |
*** part/#brlcad elena
(n=opera@92.86.0.28) |
06:41.59 |
dreeves |
so I'm having compile problems in librt can't
find mirror.c?? |
06:59.07 |
*** join/#brlcad
AlexandreGuedes_
(n=chatzill@189-92-165-117.3g.claro.net.br) |
07:19.25 |
*** join/#brlcad poolio
(i=poolio@LEAF.RES.CMU.EDU) |
07:29.23 |
*** join/#brlcad _clock_
(n=_sushi_@77-58-147-167.dclient.hispeed.ch) |
07:31.00 |
*** join/#brlcad SWPadnos_
(n=Me@dsl107.esjtvtli.sover.net) |
07:40.01 |
*** join/#brlcad SWPadnos_
(n=Me@dsl107.esjtvtli.sover.net) |
07:47.01 |
*** join/#brlcad SWPadnos_
(n=Me@dsl107.esjtvtli.sover.net) |
08:01.28 |
*** join/#brlcad madant
(n=d@117.196.129.235) |
08:22.41 |
*** join/#brlcad
AlexandreGuedes
(n=chatzill@189-92-165-117.3g.claro.net.br) |
08:22.45 |
*** join/#brlcad elite01
(n=omg@unaffiliated/elite01) |
08:45.25 |
*** join/#brlcad
AlexandreGuedes_
(n=chatzill@189-92-165-117.3g.claro.net.br) |
09:03.10 |
*** join/#brlcad
AlexandreGuedes
(n=chatzill@189-92-165-117.3g.claro.net.br) |
09:35.39 |
*** join/#brlcad elite01_
(n=omg@unaffiliated/elite01) |
09:50.33 |
*** join/#brlcad madant
(n=d@117.196.135.125) |
10:10.02 |
*** join/#brlcad
AlexandreGuedes_
(n=chatzill@189-92-165-117.3g.claro.net.br) |
10:20.43 |
*** join/#brlcad
MinuteElectron
(n=MinuteEl@unaffiliated/minuteelectron) |
11:01.12 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-146.sbndin.btas.verizon.net) |
11:13.43 |
*** join/#brlcad d-lo
(n=claymore@bz.bzflag.bz) |
11:13.53 |
d-lo |
mernin all! |
11:19.30 |
*** join/#brlcad brlcad
(n=sean@bz.bzflag.bz) |
11:19.46 |
*** mode/#brlcad [+o brlcad]
by ChanServ |
11:20.10 |
d-lo |
howdy there brlcad! |
11:20.21 |
brlcad |
hellos |
11:21.17 |
*** join/#brlcad elena
(n=opera@92.86.0.28) |
11:21.45 |
*** part/#brlcad elena
(n=opera@92.86.0.28) |
11:22.33 |
*** join/#brlcad elena
(n=opera@92.86.0.28) |
11:32.14 |
*** part/#brlcad elena
(n=opera@92.86.0.28) |
11:34.09 |
*** join/#brlcad mafm
(n=mafm@223.Red-83-49-86.dynamicIP.rima-tde.net) |
11:34.22 |
mafm |
hi |
11:34.55 |
d-lo |
hai mafm! |
11:35.03 |
brlcad |
d-lo: nice work commenting on the
apps |
11:35.20 |
d-lo |
puffs out
chest. |
11:35.21 |
d-lo |
thanks! |
11:35.35 |
brlcad |
if any jumped out at you over the one that
you're assigned to, mentors can still be swapped around |
11:35.55 |
brlcad |
technical mentoring is still group-based, but
the mentor assigned does much of the logistic tracking |
11:36.42 |
d-lo |
I was actually thinking about the GUI
project.... might be a better fit for me. If starseeker doesn't
care of course. |
11:37.16 |
brlcad |
everyone wants the gui :) |
11:37.46 |
d-lo |
I don't think i could provide the proper level
of mentoring for libpc, revolve/sweep, or BREP. |
11:39.27 |
brlcad |
remember that it's not so much the technical
side, it's just being able to keep track of how much they've
done |
11:39.31 |
brlcad |
how active they've been |
11:39.42 |
d-lo |
Importers, sure, but the hardcore math stuff I
am not so strong with. |
11:39.48 |
brlcad |
how much of what they said they were going to
do did they actually finish |
11:40.12 |
d-lo |
okay, thats as much as i figured. Its the
'technical questions' that are sure to pop up ;) |
11:40.26 |
brlcad |
technical questions belong to the whole
team |
11:40.37 |
brlcad |
they should intentionally be out in the
open |
11:40.43 |
d-lo |
but i suppose there is a decent support
network in place. |
11:41.22 |
brlcad |
for example, there should be no private
discussions -- no PMs on IRC to talk technical issues |
11:41.29 |
d-lo |
pffft. look at this. 'we can still swap
mentors around' but when i take him up on the offer, its
'Noooooooooooooo sir!' ;) |
11:41.36 |
brlcad |
should all be on this channel or on the wiki
or on the devel mailing list |
11:41.37 |
d-lo |
j/k |
11:42.06 |
brlcad |
nah, that's possible -- have to talk to
cliff |
11:42.33 |
brlcad |
libged connection is why you were added to the
one you're on |
11:42.46 |
brlcad |
since that relates to the GS a bit |
11:42.52 |
d-lo |
its all good. I am happy where I am
at. |
11:42.53 |
brlcad |
but the gui has a similar connection |
11:43.11 |
d-lo |
can't shy away from new things *too*
much |
11:43.13 |
brlcad |
and more importantly, gui should be using GS
directly |
11:43.39 |
brlcad |
just I don't expect it'll actually get that
far over the summer |
11:43.54 |
d-lo |
well now, i just might have to crack the whip
a bit ;) |
11:43.58 |
brlcad |
would rather see the gui get to a solid
framework state with no/little backend support |
11:44.07 |
brlcad |
have it look good |
11:44.12 |
d-lo |
'what the 'ell is Google payin ya for boy?!'
:) |
11:44.34 |
d-lo |
agreed |
11:45.42 |
d-lo |
is there anyway to make Saunders wire in the
gui to the existing build system vice cmake ? |
11:46.57 |
brlcad |
how so? |
11:47.15 |
brlcad |
it alread is using cmake |
11:47.24 |
d-lo |
haven't looked at it in a while, but doesn't
the the new gui, g3d, or whatever its called use cmake? |
11:47.39 |
mafm |
yes, it is |
11:47.52 |
d-lo |
points to mafm. There he
is! |
11:47.56 |
brlcad |
it works similar to the gs -- you build and
install brl-cad, then it builds against the brl-cad libs in
cmake |
11:48.30 |
d-lo |
just wondering if it would be cleaner to keep
the build systems uniform, thats all. pros/cons? |
11:48.38 |
brlcad |
he actually updated it to use our pkg-config
files too, so it finds the deps to link against nicely |
11:48.48 |
mafm |
I just didn't understand the Saunders, wire
and vice words in your phrase :D |
11:49.17 |
brlcad |
d-lo: lemme know when you're done converting
all of the main module build to cmake and we can talk about
integration :) |
11:49.54 |
brlcad |
otherwise it could be an autotools based
project, but we'd picked cmake because it's generally better for
new code |
11:50.52 |
d-lo |
ah, kk. So would it be 'better' to make rt^3
build via cmake since its techically all 'newer' code? |
11:51.09 |
brlcad |
yeah |
11:51.43 |
d-lo |
strokes his chin.
Hrm.... |
11:51.58 |
mafm |
isn't it yet? |
11:52.11 |
brlcad |
rt^3's build predates cmake being useful so it
was mirrored off the main module |
11:52.23 |
mafm |
ops :) |
11:52.24 |
brlcad |
mafm: not yet |
11:52.54 |
d-lo |
wonders if a convert to
cmake, now, would be better, rather than waiting till rt^3 gets
more complex and cluttered... |
11:53.28 |
brlcad |
it would |
11:53.54 |
brlcad |
further it goes, the more entrenched and less
beneficial a move |
11:53.57 |
mafm |
coreInterface is small, shouldn't be much of a
problem I guess, if not already |
11:54.28 |
d-lo |
grumbles about just getting
this blasted Work computer working with
autotools... |
11:54.44 |
mafm |
ogre & co. in src/other are using their
own build systems (but called from cmake IIRC), I produced cmake
for RBGui and Mocha that will be gone |
11:55.08 |
brlcad |
like the main module -- the cost vs benefit
just isnt there for us to convert the build to cmake because it's
so well developed, complete, with lots of tuned behavior and
options that would be very time-consuming to replicate and retest
in cmake |
11:55.37 |
d-lo |
nods at
brlcad. |
11:55.37 |
*** join/#brlcad elite01
(n=omg@unaffiliated/elite01) |
11:55.48 |
brlcad |
so autoconf isn't going away anytime soon
:) |
11:56.05 |
brlcad |
we'll just have two |
11:56.30 |
d-lo |
two? build systems? |
11:56.34 |
brlcad |
actually still works rather nicely to have
distinctly separate barrier between the lib layers |
11:57.13 |
brlcad |
yeah, two build systems -- the core (brlcad)
and then an overlay (rt^3) |
11:57.33 |
d-lo |
kk, just making sure I understood what you
typed =D |
12:00.21 |
d-lo |
as for rt^3/src/ director structure, i am
thinking of doing some re-organizing. It kinda bugs me that there
are several aspects of the project going on at the same time with
little to no communications and people are putting things wherever
they want (myself included) |
12:01.45 |
d-lo |
and if the rt^3 dividing lines (GUI, GS, GE)
are acceptable, I am thinking of re-org'ing the dirs a bit to
represent that. |
12:01.45 |
d-lo |
especially if we end up with multiple
GUIs |
12:03.03 |
mafm |
ok for me, svn preserves history and
everything, so no big disadvantages |
12:03.59 |
d-lo |
I think daniel is the only other major worker
bee in the rt3 module, so I might email him/use the devel mailing
list. |
12:04.15 |
d-lo |
of course, i might just re-org now and as
permission later ;) |
12:04.46 |
brlcad |
yeah, those should definitely be three
distinct "products" by themselves with GS dependent on GE, GUI
dependent on GS, all three dependent on core |
12:04.48 |
d-lo |
and thats just cause I dont know what is
'politically correct' in the OS world yet :) |
12:05.12 |
d-lo |
core == common stuff |
12:05.14 |
brlcad |
re-org would be great, but it should be
communicated |
12:05.15 |
d-lo |
-or- |
12:05.22 |
d-lo |
core == brlcad module |
12:05.25 |
d-lo |
? |
12:05.25 |
brlcad |
brlcad module |
12:05.26 |
d-lo |
kk |
12:05.58 |
brlcad |
they may have some common code, classes that
are shared -- but I wouldn't plan for them having shared sublibs
just yet |
12:06.33 |
brlcad |
as that common code probably just belongs down
with GE if it is common |
12:08.03 |
brlcad |
should e-mail daniel (or any dev) directly on
dev matters, the mailing list communicates that openly much
better |
12:08.15 |
brlcad |
it's a pretty small list, not like the
discussion wanders off-topic into arguments |
12:08.33 |
d-lo |
heh, 'down with GE'.... 80's rap song about
General Electric... |
12:09.41 |
brlcad |
how about proposing the overall reorg
structure to the list, then work towards that structure
incrementally |
12:11.19 |
d-lo |
brlcad: working on an email right now. I do
not think that it will cause much of a 'wave in the water' to reorg
src/ into src/guis/ src/gs/ src/ge src/common and
src/other |
12:11.31 |
brlcad |
or at least making the changes incrementally
so that if an issue comes up, it's not mixed in with 100 other
reorg changes |
12:11.52 |
d-lo |
nods.
Understood |
12:12.24 |
brlcad |
heh, I wouldn't plan on multiple guis until we
have a distinct need |
12:12.28 |
d-lo |
plus it will give a good history and allow
people to make fun of me when i do something stupid =D |
12:12.36 |
brlcad |
have enough work ahead to get one working
well |
12:12.49 |
brlcad |
what is src/common? |
12:13.25 |
d-lo |
place to put code common to guis/ gs/ and ge/
(if it actually exists) |
12:14.13 |
brlcad |
bikeshed difference, but src/GUI, src/GS,
src/GE (caps) would reflect their c++ nature well :) |
12:14.23 |
d-lo |
i only thought that src/common might be useful
since the guis may not want to include the entire libge |
12:14.29 |
brlcad |
ah, that was my point earlier -- if it's
actually common, it probably belongs in GE |
12:15.56 |
d-lo |
yeah, i was thinking about that point, and i
can't come up with anything that the GUIs would need that would be
in GE... but I suppose we can work that issue when it
arises |
12:16.13 |
d-lo |
'if' it comes up at all. |
12:16.19 |
brlcad |
yeah |
12:16.25 |
brlcad |
leave it out until needed |
12:16.37 |
d-lo |
you minimalist you. |
12:16.55 |
hippieindamakin8 |
giggles |
12:17.10 |
brlcad |
the various lib dirs in src/lib* were
organized that same way you're suggesting before GE came on the
scene |
12:17.25 |
brlcad |
those libs collectively were the start of a GE
themselves |
12:17.44 |
brlcad |
geometry, image, network, numeric, raytrace,
and utility (common) services |
12:17.50 |
d-lo |
well then, sounds like an easy mv command or
two! |
12:18.01 |
d-lo |
;) |
12:18.28 |
brlcad |
most everything daniel's done to date fits
under that geometry category |
12:18.53 |
brlcad |
GS picked up that network category |
12:19.08 |
brlcad |
(so ge longer has it) |
12:26.01 |
d-lo |
your words speak true. I had felt a
disturbance in the rt3 module for some time, but couldn't put my
finger on what it was.... |
12:26.03 |
brlcad |
it shouldn't be too hard to get a consensus on
the basic layout -- more just an issue of merging the right things
together without losing any of the invested effort on the old or
various new codes that have since kicked off |
12:27.36 |
brlcad |
there's actually not much duplication as it
is, just four people that have ignored what the previous coder left
in place :) |
12:28.02 |
d-lo |
are you refering to lib* dirs? |
12:28.42 |
brlcad |
for the first guy, yeah |
12:28.56 |
brlcad |
then the next guy ignored the lib dirs and
what the second guy added |
12:29.15 |
brlcad |
then the next guy ignored the lib dirs, what
the second guy added, and the third guy, ... :) |
12:29.22 |
brlcad |
kinda funny, but classic |
12:29.31 |
brlcad |
mostly because it's a sandbox |
12:29.52 |
brlcad |
wasn't a pressing need to hardline the
organization until recently |
12:30.11 |
brlcad |
so time to refactor! |
12:32.07 |
brlcad |
plus the switch in build systems made it even
more tricky to merge them half-way through |
12:32.17 |
brlcad |
and is really the brunt of the work even
now |
12:32.54 |
brlcad |
the org itself isn't complicated or riddled
with pitfalls (unless code is deleted) |
12:33.03 |
brlcad |
it's wiring up the build |
13:17.02 |
CIA-28 |
BRL-CAD: 03d_rossberg * r34235
10/rt^3/trunk/include/brlcad/common.h: |
13:17.03 |
CIA-28 |
BRL-CAD: an exception with an error message
similar to bu_bomb |
13:17.03 |
CIA-28 |
BRL-CAD: The implementation/return value of
std::exception::what() depends on the |
13:17.03 |
CIA-28 |
BRL-CAD: compiler (it is not in the standard).
That's why there is now a |
13:17.03 |
CIA-28 |
BRL-CAD: BRLCAD::bad_alloc derived from
std::bad_alloc which carries a hopefully useful |
13:17.05 |
CIA-28 |
BRL-CAD: message. |
13:20.39 |
CIA-28 |
BRL-CAD: 03d_rossberg * r34236 10/rt^3/trunk/
(20 files in 2 dirs): the core interface now compiles under Linux
too |
14:06.32 |
*** join/#brlcad louipc
(n=louipc@archlinux/trusteduser/louipc) |
14:09.46 |
CIA-28 |
BRL-CAD: 03davidloman * r34237
10/rt^3/trunk/src/iBME/Makefile.am: Cleanup: removed a few
straggling references to Boost libs |
14:13.43 |
*** join/#brlcad madant
(n=d@117.196.150.228) |
14:21.28 |
CIA-28 |
BRL-CAD: 03davidloman * r34238
10/rt^3/trunk/src/other/Makefile.am: Cleanup: removed Makefile.am
that referred to outdated/removed 3rd party libs |
14:22.07 |
*** join/#brlcad madant_
(n=d@117.196.137.213) |
14:28.30 |
CIA-28 |
BRL-CAD: 03davidloman * r34239 10/rt^3/trunk/
(configure.ac src/other/uuid/ src/uuid/): moved src/uuid to
src/other/uuid |
14:31.22 |
CIA-28 |
BRL-CAD: 03davidloman * r34240
10/rt^3/trunk/src/ (GUI/ GUIs/): Refactored GUI to GUIs |
14:31.54 |
*** join/#brlcad elite01
(n=omg@unaffiliated/elite01) |
14:51.17 |
*** join/#brlcad elena
(n=opera@92.86.0.28) |
15:08.08 |
*** part/#brlcad elena
(n=opera@92.86.0.28) |
15:08.45 |
*** join/#brlcad samrose
(n=samrose@adsl-76-226-71-255.dsl.sfldmi.sbcglobal.net) |
15:09.00 |
*** join/#brlcad elena
(n=opera@92.86.0.28) |
15:09.52 |
brlcad |
waves to
elena |
15:12.05 |
*** part/#brlcad elena
(n=opera@92.86.0.28) |
15:14.42 |
*** join/#brlcad FAMULUS
(n=mark@dsl081-135-036.nyc1.dsl.speakeasy.net) |
15:16.21 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-146.sbndin.btas.verizon.net) |
15:17.23 |
PrezKennedy |
waves to
brlcad |
15:17.31 |
brlcad |
howdy |
15:17.35 |
brlcad |
digest all that meat yet? |
15:17.38 |
PrezKennedy |
yeah! |
15:17.43 |
PrezKennedy |
finally |
15:27.03 |
``Erik |
uh, way tmi |
16:29.51 |
*** join/#brlcad jdoliner
(n=jdoliner@c-68-51-76-57.hsd1.il.comcast.net) |
16:31.40 |
jdoliner |
have selections been announced publicly
somewhere? |
16:39.04 |
pacman87 |
jdoliner: official announcement is still the
20th, i believe |
16:40.19 |
pacman87 |
although the topic disagrees with me |
17:01.04 |
jdoliner |
yeah, this is what led to my confusion as
well |
17:01.09 |
jdoliner |
how many slots did yu guys get? |
17:01.44 |
brlcad |
5 |
17:02.15 |
brlcad |
ah right, topic .. the selections are pretty
near final on the 15th, but we cannot announce until the
20th |
17:03.09 |
*** topic/#brlcad by brlcad
-> BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad
|| Release 7.14.6 posted (20090403) || GSoC2009 Next Step:
selections are made, they will be announced (by Google) on the
20th |
17:19.39 |
*** join/#brlcad poolio
(i=poolio@LEAF.RES.CMU.EDU) |
17:20.20 |
brlcad |
howdy poolio |
17:20.37 |
poolio |
ahoy! |
17:21.11 |
*** join/#brlcad elena
(n=ebautu@89.136.118.141) |
17:21.40 |
hippieindamakin8 |
hey brlcad , pacman87 |
17:21.51 |
brlcad |
poolio: how goes the semester? |
17:21.58 |
brlcad |
howdy hippieindamakin8 |
17:22.08 |
poolio |
I just was catching up on e-mail... are the
mentor-student assignments all worked out? |
17:22.16 |
brlcad |
yeah |
17:22.32 |
brlcad |
unless you want an assignment, you're welcome
to one |
17:22.42 |
brlcad |
really shouldn't be assigned,
for example |
17:22.53 |
poolio |
brlcad: it's been good, but insanely busy.
working two jobs and 7 classes :) |
17:24.46 |
poolio |
hmm, well it looks like the only project I
could possibly be helpful on is the BREP on BREP one, and it looks
like there's already someone who is not you on that. I'll
definitely be idling around here over the summer and try to provide
as much help as I can, maybe even finish up on some of that CSG
-> BREP stuff now that I get it |
17:26.16 |
*** join/#brlcad poolio
(i=poolio@LEAF.RES.CMU.EDU) |
17:26.19 |
brlcad |
poolio: the assigned mentors are more for
logistic tracking, not technical guidance -- technical is
group-shared so you can help out with that one regardless |
17:26.39 |
brlcad |
also, selections aren't announced, so hush on
the projects :) |
17:26.43 |
brlcad |
bah |
17:26.47 |
*** join/#brlcad poolio
(n=poolio@bz.bzflag.bz) |
17:27.01 |
poolio |
will do |
17:27.19 |
brlcad |
also, selections aren't announced, so hush on
the projects .. :) |
17:29.31 |
poolio |
oopsy daisy. sorry bout that... what I meant
to say was if such a project were accepted into GSOC then
... |
17:29.46 |
brlcad |
heh |
17:30.35 |
brlcad |
it's okay, if folks were closely paying
attention, it's pretty clear who at least 4 of the 5 are |
17:31.13 |
brlcad |
at least .. "in all likelihood" |
17:31.39 |
elena |
;) |
17:34.18 |
brlcad |
hm, I suppose our project priorities (
http://brlcad.org/BRL-CAD_Priorities.png
) conceivably narrows in a little too |
17:34.27 |
brlcad |
though there are a couple outliers, hm, maybe
not |
17:35.42 |
*** join/#brlcad
AlexandreGuedes
(n=chatzill@189-92-135-182.3g.claro.net.br) |
18:36.21 |
*** join/#brlcad FAMULUS
(n=mark@dsl081-135-036.nyc1.dsl.speakeasy.net) |
18:36.51 |
*** join/#brlcad samrose
(n=samrose@ip-207-145-38-45.iad.megapath.net) |
18:42.25 |
*** join/#brlcad
hippieindamakin8 (n=hippiein@202.3.77.38) |
19:06.03 |
dreeves |
brlcad and starseeker shoot the dented sphere
from the side with trimming definitely not dented |
19:06.35 |
dreeves |
So maybe there still is some issues with
trimming |
19:30.08 |
*** join/#brlcad _sushi_
(n=_sushi_@77-58-243-9.dclient.hispeed.ch) |
19:49.33 |
*** join/#brlcad jonored_
(n=jonored@LAZARUS2.WIFI.WPI.EDU) |
19:53.51 |
*** join/#brlcad BigATo1
(n=BigAToo@pool-96-230-124-146.sbndin.btas.verizon.net) |
20:03.11 |
*** join/#brlcad andax
(n=andax__@d213-102-40-135.cust.tele2.ch) |
20:05.35 |
CIA-28 |
BRL-CAD: 03bob1961 * r34241
10/brlcad/trunk/src/ (3 files in 2 dirs): Updates related to
Archer's view-only mode. |
20:16.07 |
*** part/#brlcad elena
(n=ebautu@89.136.118.141) |
20:47.23 |
jonored_ |
...Well, I can get the principal curvatures
for a point on a nurbs surface, but not the associated direction
yet... |
21:04.38 |
*** join/#brlcad Don_
(n=Don@c-68-62-76-34.hsd1.mi.comcast.net) |
21:15.07 |
*** join/#brlcad elena
(n=ebautu@89.136.118.141) |
22:28.44 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-146.sbndin.btas.verizon.net) |
22:32.47 |
*** join/#brlcad typ0
(n=coder@um-sd06-125-2.uni-mb.si) |
23:23.43 |
*** join/#brlcad Don__
(n=Don@c-68-62-76-34.hsd1.mi.comcast.net) |
23:55.24 |
*** join/#brlcad Elrohir
(n=kvirc@p5B14FF0E.dip.t-dialin.net) |