00:01.15 |
Ralith |
okay |
03:33.38 |
*** join/#brlcad epileg
(~epileg@unaffiliated/epileg) |
04:56.44 |
*** join/#brlcad Stattrav
(~Stattrav@122.172.16.143) |
04:56.44 |
*** join/#brlcad Stattrav
(~Stattrav@unaffiliated/stattrav) |
07:55.10 |
brlcad |
Ralith: was waiting since you were gone and
not away -- he didn't write up any of his plans or work from
anything written up |
07:55.38 |
brlcad |
if he made any progress, it wasn't made
publicly available that I'm aware of |
07:56.10 |
Ralith |
brlcad: just got ahold of him after a month of
trying, actually. Will be resuming his work. |
07:56.17 |
Ralith |
he sent me his full git repo |
07:56.58 |
brlcad |
excellent |
07:57.07 |
brlcad |
I have a copy of some python code he
wrote |
07:57.20 |
brlcad |
don't know if it's the same as what was in his
repo |
07:57.35 |
Ralith |
nope, this is C |
07:57.38 |
brlcad |
but at a glance, it was mainly a way to do in
python some of the things you can do in mged |
07:57.45 |
brlcad |
k |
07:57.57 |
Ralith |
this is a partly complete slicer based on the
raytracer |
07:58.06 |
Ralith |
not sure how partly; I suspect
mostly. |
07:58.08 |
brlcad |
that's good |
07:58.20 |
Ralith |
outputs a sequence of line segments and
circular arcs |
07:58.24 |
brlcad |
that's one of two respectable approaches, the
easier of the two |
07:58.33 |
Ralith |
what's the other, out of curiosity? |
07:59.09 |
brlcad |
we'll, you're either using ray-tracing and
sampling the space to determine an approximation for
toolpaths |
07:59.57 |
brlcad |
or you're projecting a contour image to 2D
(either sampled or in parametric form) and using that for
toolpaths |
08:00.46 |
Ralith |
contour image being something along the lines
of the sketch-from-plane-region-intersection thing I was asking
about earlier? |
08:00.54 |
Ralith |
projected contour image* |
08:01.13 |
brlcad |
basically |
08:01.26 |
brlcad |
that'd be one way to attempt it |
08:01.54 |
Ralith |
that was what I was planning on doing had I
not been able to recover this code. |
08:02.04 |
brlcad |
three or four come to mind but they all
involve projecting an object onto a viewing plane, not a simple
thing to do |
08:02.05 |
Ralith |
looks like that will be unnecessary,
though |
08:02.28 |
brlcad |
the sampled approach is MUCH much easier and
doable today |
08:02.35 |
Ralith |
nod |
08:02.37 |
Ralith |
good to know |
08:02.45 |
brlcad |
and only limited by the resolution you're
willing to sample |
08:03.05 |
Ralith |
and I have a concrete upper limit to that: the
precision of the target machine. |
08:03.19 |
Ralith |
typically worse than 0.1mm. |
08:03.32 |
brlcad |
you can probably even sample below some
specified machining tolerance and it'd never matter |
08:03.37 |
brlcad |
yeah |
08:03.48 |
Ralith |
and a typical build volume of 20cm means quite
reasonable sample counts, I believe. |
08:04.22 |
brlcad |
yeah, that'd just be a 2k x 2k sample
grid |
08:04.34 |
Ralith |
trickier on ultraprecise CNC lathes and such,
but my first priority is reprap support, which means relatively
low-res additive. |
08:04.42 |
brlcad |
that'd take just a second or two to calculate
them all |
08:04.47 |
Ralith |
sweet |
08:05.08 |
Ralith |
if the line/arc approximation math jonored's
already finished isn't too heavy, this'll easily outstrip
everything else people are using |
08:05.29 |
Ralith |
all of which are improvised STL
processors |
08:05.54 |
brlcad |
crank that up to a 200cm piece or 20cm at a
0.01mm tolerance, and you jack up the grid to 20k x 20k |
08:06.11 |
brlcad |
which would be a couple minutes (10x order of
mag. increase) |
08:06.55 |
Ralith |
jonored also mentioned that he was put off by
some bug wherein the second derivative of toroids was
mis-reported? |
08:06.59 |
Ralith |
know anything about that? |
08:07.14 |
brlcad |
nope |
08:07.41 |
Ralith |
okay, will see about hunting it down if/when I
encounter it myself |
08:07.41 |
brlcad |
first I've heard of toroids having a
problem |
08:08.03 |
Ralith |
it sounded like a minor one: |
08:08.16 |
Ralith |
19:56:53 <jonored> Yep. Either puts them
in the wrong slots, or gives a direction of the larger curvature at
right angles to what it should, don't recall which. |
08:08.44 |
brlcad |
there is one thing that comes to mind, but
it's not second-derivative related. it's failure to converge on a
hit/miss if you perfectly graze a torus under certain math
conditions |
08:08.52 |
brlcad |
but then it just counts it as a miss |
08:09.04 |
Ralith |
seems like a pretty minor issue, at least for
my purposes |
08:09.16 |
brlcad |
ah, curvature is a different routine |
08:09.46 |
Ralith |
he referred to it as having the "curvature
flipped" |
08:09.51 |
brlcad |
not used by much, so that would be a little
less surprising -- but also trivial to investigate -- one tiny
func |
08:09.58 |
Ralith |
okay then |
08:10.10 |
Ralith |
will mention it if I find anything |
08:10.28 |
Ralith |
hopefully with a patch in tow, though I'm
still a bit worried about my ability to keep up with the
math |
08:10.35 |
brlcad |
src/librt/primitives/tor/tor.c:831 |
08:10.39 |
brlcad |
rt_tor_curve() |
08:10.45 |
Ralith |
thanks :) |
08:10.52 |
brlcad |
if there's a curvature bug, that's where it'd
be |
08:11.45 |
brlcad |
it'd be easy to get a sign wrong |
08:12.32 |
Ralith |
looks like this might well be pretty
straightforward. |
08:14.29 |
brlcad |
"rt -l4 -s1024 file.g object" will render
'object' in 'file.g' to a window 1024x1024 with a curvature
visualization lighting model, so you can see them in an
image |
08:14.52 |
Ralith |
ooh, fun! |
08:17.49 |
Ralith |
hm, behaves oddly. |
08:17.54 |
Ralith |
perhaps I should install a stable
version |
08:18.50 |
Ralith |
frame buffers are hanging around and not
responding to close requests, and display sharply skewed output
despite it appearing normal mid-render |
08:19.17 |
brlcad |
are you (or your window manager) resizing the
window? |
08:19.24 |
Ralith |
window manager is. |
08:19.42 |
brlcad |
that'd be a problem |
08:19.58 |
Ralith |
tiling wm; tends to be more forceful about
that than much code expects |
08:20.05 |
Ralith |
not a very well behaved tiling wm,
though. |
08:20.20 |
brlcad |
fb windows aren't resizable
unfortunately |
08:20.23 |
Ralith |
will switch to something more
compliant and with float support in the near
future |
08:20.28 |
brlcad |
sucks, but nobody has fixed |
08:20.31 |
brlcad |
try fbserv instead |
08:20.39 |
brlcad |
fbserv 0 /dev/X & |
08:20.49 |
brlcad |
rt -F0 -s1024 file.g object |
08:21.35 |
Ralith |
that works nicely! |
08:21.36 |
Ralith |
thanks :) |
08:22.47 |
brlcad |
manpage shows other options if the need
arises |
08:22.50 |
Ralith |
nod |
09:43.04 |
*** join/#brlcad mafm
(~mafm@5.Red-83-45-73.dynamicIP.rima-tde.net) |
10:38.21 |
CIA-29 |
BRL-CAD: 03tbrowder2 * r42406
10/brlcad/trunk/src/libged/attr.c: modify and rename attr sort comp
function for extern use |
10:40.01 |
CIA-29 |
BRL-CAD: 03tbrowder2 * r42407
10/brlcad/trunk/src/libged/ged_private.h: add extern for attr comp
function; add flags for extension of mged tree command
args |
10:42.17 |
CIA-29 |
BRL-CAD: 03tbrowder2 * r42408
10/brlcad/trunk/src/libged/ls.c: cast to int to quell compiler
warnings about signed/unsigned comparison |
10:44.21 |
*** join/#brlcad epileg
(~epileg@unaffiliated/epileg) |
11:13.47 |
*** join/#brlcad mafm
(~mafm@5.Red-83-45-73.dynamicIP.rima-tde.net) |
11:14.02 |
CIA-29 |
BRL-CAD: 03tbrowder2 * r42409
10/brlcad/trunk/HACKING: list extensions for Perl code |
11:44.18 |
DaveLo |
Mernin all |
12:32.38 |
CIA-29 |
BRL-CAD: 03Dloman 07http://brlcad.org * r2422
10/wiki/GeometryServiceNetworkProtocol: |
13:07.39 |
*** join/#brlcad d_rossberg
(~rossberg@BZ.BZFLAG.BZ) |
13:37.10 |
DaveLo |
opens a new can of
Photoshop-fu. Will need lots today. |
13:38.50 |
CIA-29 |
BRL-CAD: 03Dloman 07http://brlcad.org * r0
10/wiki/Special:Log/upload: uploaded
"[[Image:GSNetProtocol.png]]" |
13:55.05 |
CIA-29 |
BRL-CAD: 03Dloman 07http://brlcad.org * r2424
10/wiki/GeometryServiceNetworkProtocol: Added in specifics about
GSNet Header stufff. WIP still. |
13:57.11 |
CIA-29 |
BRL-CAD: 03Dloman 07http://brlcad.org * r0
10/wiki/Special:Log/upload: uploaded
"[[Image:GSNetMsgBreakdown.png]]" |
13:59.45 |
CIA-29 |
BRL-CAD: 03Dloman 07http://brlcad.org * r2426
10/wiki/GeometryServiceNetworkProtocol: New image name, down size a
bit. |
14:03.33 |
starseeker |
is probably going to end up
volunteering to maintain a few Find*.cmake modules |
14:09.06 |
DaveLo |
that'll be fun! |
14:10.03 |
starseeker |
apparently back in 07 they switched to a
system where people volunteer to maintain specific modules, on the
(quite reasonable) theory that Kitware didn't have the resources to
properly test them all |
14:10.59 |
*** join/#brlcad cjdevlin
(~devlin@d118-75-252-178.try.wideopenwest.com) |
14:11.04 |
starseeker |
submitted patches for Tcl,
OpenGL and X11 anyway on the theory that Kitware probably wouldn't
want to trust them to a 3rd party maintainer, give how core they
were |
14:11.07 |
starseeker |
silly me |
14:11.17 |
*** join/#brlcad kanzure
(~kanzure@131.252.130.248) |
14:11.20 |
*** join/#brlcad 15SABD4WY
(~CIA@208.69.182.149) |
14:12.26 |
starseeker |
in one sense though it's not too big a deal,
since I'll either be maintaining our local copy of those files as a
"mini-fork" or doing it for CMake proper |
14:13.28 |
*** join/#brlcad CIA-38
(~CIA@208.69.182.149) |
14:13.32 |
*** join/#brlcad packrat
(~packrator@99-67-225-40.lightspeed.livnmi.sbcglobal.net) |
14:13.48 |
starseeker |
X11 and OpenGL should be pretty mature anyway,
but the FindTCL module is a radical departure |
14:14.42 |
DaveLo |
Hows the roads down there? |
14:15.45 |
CIA-38 |
BRL-CAD: 03Dloman 07http://brlcad.org * r0
10/wiki/Special:Log/upload: uploaded "[[Image:GSNet
Symbol.png]]" |
14:15.53 |
*** join/#brlcad R0b0t1
(~Enigma@64-136-219-55.dyn.everestkc.net) |
14:15.53 |
*** join/#brlcad R0b0t1
(~Enigma@unaffiliated/r0b0t1) |
14:17.59 |
*** join/#brlcad ``Erik_
(Here@c-69-140-109-104.hsd1.md.comcast.net) |
14:18.33 |
*** join/#brlcad epileg1
(~epileg@188.119.210.222) |
14:20.36 |
*** join/#brlcad mafm
(~mafm@5.Red-83-45-73.dynamicIP.rima-tde.net) |
14:21.53 |
starseeker |
grits his teeth and does a
reboot into Windows for another test round... |
14:22.49 |
CIA-38 |
BRL-CAD: 03Dloman 07http://brlcad.org * r2428
10/wiki/GeometryServiceNetworkProtocol: Add in GSnet graphic and
align. |
14:23.13 |
DaveLo |
starseeker: Hows the roads down there? made
the trek in to work yet? |
14:24.11 |
*** join/#brlcad Elrohir
(~kvirc@p5B14977D.dip.t-dialin.net) |
14:27.59 |
starseeker |
no, not yet - they plowed but there is a lot
of slush in our area |
14:28.13 |
starseeker |
just got done scraping the driveway |
14:29.16 |
CIA-38 |
BRL-CAD: 03Dloman 07http://brlcad.org * r2429
10/wiki/GSNet_String: Stub in GSNet String page. |
14:31.33 |
starseeker |
will head in once he sees
what happens on Windows... |
14:33.09 |
starseeker |
oooo - lot of updates to pull |
14:37.44 |
*** join/#brlcad Elrohir
(~kvirc@p5B14977D.dip.t-dialin.net) |
14:59.43 |
DaveLo |
lotsa ice up here as well. |
15:00.00 |
DaveLo |
just called in to leave a telework notice.
Heh, no one answered! =D |
15:06.09 |
*** join/#brlcad epileg
(~epileg@unaffiliated/epileg) |
15:10.43 |
``Erik_ |
snow line said post was closed until
9 |
15:13.05 |
CIA-38 |
BRL-CAD: 03erikgreenwald * r42410
10/brlcad/trunk/src/librt/Makefile.am: move nmg_junk to
EXTRA_DIST |
15:28.03 |
CIA-38 |
BRL-CAD: 03starseeker * r42411
10/brlcad/branches/cmake/src/CMakeLists.txt: Put the CMAKE_HEADERS
variable in the src add_definitions (Windows seems to like this
better, needs more testing.) |
15:36.01 |
DaveLo |
``Erik: righto, but I called at 10 and still
no answer :) |
15:39.33 |
CIA-38 |
BRL-CAD: 03erikgreenwald * r42412
10/brlcad/trunk/src/libged/ged.c: type fix |
15:44.38 |
*** join/#brlcad Stattrav
(~Stattrav@117.202.19.46) |
15:44.38 |
*** join/#brlcad Stattrav
(~Stattrav@unaffiliated/stattrav) |
16:22.12 |
CIA-38 |
BRL-CAD: 03starseeker * r42413
10/brlcad/branches/cmake/CMakeLists.txt: |
16:22.12 |
CIA-38 |
BRL-CAD: Successfully generate an NSIS
installer, although it doesn't work yet due to |
16:22.12 |
CIA-38 |
BRL-CAD: src/other libraries being installed
to the wrong dir - need to correct the CMake |
16:22.12 |
CIA-38 |
BRL-CAD: files in question or add additional
logic in src/other/CMakeLists.txt, whichever |
16:22.12 |
CIA-38 |
BRL-CAD: makes sense. |
18:03.41 |
DaveLo |
whoooo doggy. There's some serious ice out
there! Im still chipping away at getting clear. |
18:03.49 |
CIA-38 |
BRL-CAD: 03starseeker * r42414
10/brlcad/branches/cmake/ (11 files in 11 dirs): Make the CMake
library target logic a bit more generic. A lot of these files
should probably be worked into being proper stand-alone
CMakeLists.txt files. |
18:03.56 |
DaveLo |
looks like two layers of ice then snow.
Blech |
18:04.12 |
starseeker |
nods - I'll be heading in
soon, but yeah - figured the more melted the
better |
18:04.21 |
starseeker |
at least it's above freezing, or moving would
be out of the question |
18:04.37 |
DaveLo |
Temps up here are cycling above then below
here. |
18:04.45 |
starseeker |
ah, we're a few degrees above |
18:04.59 |
DaveLo |
half the stuff that melted and ran off the
jeep refroze on the ground :/ |
18:05.18 |
DaveLo |
We're getting more this evening, right? i
havent checked the forecast in a bit. |
18:05.27 |
starseeker |
still had to shovel - if it
had re-frozen tonight, would have had 3/4 inch or better of ice all
over the driveway |
18:05.42 |
starseeker |
dunno - haven't seen any indications of more,
but perhaps that's changed |
18:06.09 |
starseeker |
makes one file stab at
Windows before heading in |
18:07.02 |
DaveLo |
checks
forecast |
18:07.56 |
DaveLo |
heh, yeah. Starting around 10pm, more ice and
snow... at least up here. |
18:08.40 |
DaveLo |
looks like mostly rain down your way, with
temps never dipping below freezing. |
18:08.53 |
DaveLo |
have a nice day at work! muwahahaha
=P |
18:09.35 |
CIA-38 |
BRL-CAD: 03Dloman 07http://brlcad.org * r2430
10/wiki/GeometryServiceNetworkProtocol: Change links to start
eliminating the iBME references. |
18:10.01 |
CIA-38 |
BRL-CAD: 03Dloman 07http://brlcad.org * r0
10/wiki/Special:Log/delete: deleted "[[IBME NETWORKPROTO STRING]]":
iBME references are antiquated and being updated. |
18:20.41 |
*** part/#brlcad cjdevlin
(~devlin@d118-75-252-178.try.wideopenwest.com) |
18:20.53 |
*** join/#brlcad cjdevlin
(~devlin@d118-75-252-178.try.wideopenwest.com) |
18:49.54 |
*** join/#brlcad alex_joni
(~alex_joni@emc/board-of-directors/alexjoni) |
19:24.53 |
CIA-38 |
BRL-CAD: 03Dloman 07http://brlcad.org * r2431
10/wiki/GeometryServiceNetworkProtocol: Spacing |
19:30.10 |
CIA-38 |
BRL-CAD: 03Dloman 07http://brlcad.org * r2432
10/wiki/GeometryServiceNetworkProtocol: Specifics about the libPKG
header implementation |
19:48.20 |
brlcad |
starseeker: note that the current nsis
installer is "wrong" in several aspects as to where files are
placed |
19:49.22 |
brlcad |
you don't need to accommodate the existing
mistakes -- keep the install tree like it is supposed to be so it's
the same on all platforms |
19:49.25 |
brlcad |
the nsis installer can be fixed to
accomodate |
19:52.00 |
CIA-38 |
BRL-CAD: 03Dloman 07http://brlcad.org * r2433
10/wiki/GeometryServiceNetworkProtocol: Use CSS to make the table
purty. |
19:55.41 |
CIA-38 |
BRL-CAD: 03brlcad * r42415
10/brlcad/trunk/src/libged/ (attr.c ged.c ged_private.h): |
19:55.41 |
CIA-38 |
BRL-CAD: private functions used across
commands should be in the _ged_ namespace, |
19:55.41 |
CIA-38 |
BRL-CAD: otherwise, they don't need to be
declared in ged_private.h and can remain HIDDEN |
19:55.41 |
CIA-38 |
BRL-CAD: _cmd_ prefixed. rename
_attr_cmpstringp() to _ged_cmpattr() to reflect that it |
19:55.41 |
CIA-38 |
BRL-CAD: specifically compares
bu_attribute_value_pair objects. |
20:12.27 |
CIA-38 |
BRL-CAD: 03brlcad * r42416
10/brlcad/trunk/src/libged/ (attr.c ged.c ged_private.h): ws
consistency update, elim forward decls |
20:15.04 |
starseeker |
nods |
20:15.30 |
starseeker |
trying to figure out why mged isn't finding
anything on Windows... |
20:15.47 |
starseeker |
needs to generalize the
pkgIndex.tcl files a bit, doing that first |
20:19.42 |
CIA-38 |
BRL-CAD: 03brlcad * r42417
10/brlcad/trunk/src/libged/ (ged_private.h ls.c): convert up to
size_t instead of down to int. |
20:56.07 |
CIA-38 |
BRL-CAD: 03brlcad * r42418
10/brlcad/trunk/src/librt/parse.c: quell warnings, size_t
upconversions |
20:58.54 |
CIA-38 |
BRL-CAD: 03brlcad * r42419
10/brlcad/trunk/src/librt/Makefile.am: |
20:58.55 |
CIA-38 |
BRL-CAD: compile parse.c and nmg_junk.c so we
make sure that they keep compiling as the |
20:58.55 |
CIA-38 |
BRL-CAD: library evolves. they don't need to
be installed, but they should still be |
20:58.55 |
CIA-38 |
BRL-CAD: maintained until they're integrated
or removed. (alas, they both have useful |
20:58.55 |
CIA-38 |
BRL-CAD: routines that should be
integrated) |
20:59.38 |
brlcad |
starseeker: be wary of #ifdef _WIN32 and if
{$platform == "windows"} statements in C/Tcl code that Bob added to
override search paths |
21:00.33 |
brlcad |
some of them are sprinkled in unsuspecting
places, have to trace the logic when something fails to load that
should be loading to make sure it's not a hack job screwing things
up |
21:00.54 |
starseeker |
nods - will
do |
21:22.42 |
CIA-38 |
BRL-CAD: 03starseeker * r42420
10/brlcad/branches/cmake/src/other/ (6 files in 6 dirs):
Fix/generalize pkgIndex.tcl logic, make incrTcl libs follow
convention. |
21:40.08 |
CIA-38 |
BRL-CAD: 03brlcad * r42421
10/brlcad/trunk/src/librt/primitives/metaball/metaball.c: |
21:40.09 |
CIA-38 |
BRL-CAD: not entirely clear what the compiler
is complaining about here with the two |
21:40.09 |
CIA-38 |
BRL-CAD: (const point_t *) parameters to
rt_metaball_find_intersection(). the problem |
21:40.09 |
CIA-38 |
BRL-CAD: has something to do with point_t
being an array typedef. instead of getting the |
21:40.09 |
CIA-38 |
BRL-CAD: address during the call, get the
point_t address beforehand with an explicit |
21:40.09 |
CIA-38 |
BRL-CAD: cast to keep things quiet. (gcc
4.2.1) |
21:49.15 |
``Erik |
hm, I disabled nmg_junk.c last week due to
'defined but not used' warnings stopping the compile |
22:08.28 |
brlcad |
everything in librt_xxx.la is not used, so
maybe it'll be quiet -- seems to work here with 4.2.1 |
22:08.46 |
brlcad |
otherwise, I can add some extern
decls |
22:08.54 |
brlcad |
that'll definitely make it shut up |
22:15.54 |
CIA-38 |
BRL-CAD: 03starseeker * r42422
10/brlcad/branches/cmake/src/libbu/brlcad_path.c: |
22:15.54 |
CIA-38 |
BRL-CAD: Interesting... when launching bwish
from the root install dir (e.g. ./bin/bwish) |
22:15.54 |
CIA-38 |
BRL-CAD: the return of bu_brlcad_data was not
a full path (or even strictly speaking a |
22:15.54 |
CIA-38 |
BRL-CAD: relative path unless you add an
implicit '.') and archer didn't start. This is |
22:15.54 |
CIA-38 |
BRL-CAD: a bit of a corner case, but still
should work - try to make it more robust. |
22:29.09 |
CIA-38 |
BRL-CAD: 03starseeker * r42423
10/brlcad/branches/cmake/src/archer/plugins/Utility/botUtilityP.tcl:
shouldn't need brlcadDataPath variable here. |
22:38.48 |
CIA-38 |
BRL-CAD: 03starseeker * r42424
10/brlcad/branches/cmake/src/libbu/brlcad_path.c: Whoops, try to do
snprintf right |
22:47.42 |
starseeker |
mutter... bwish starts, but it's auto_path is
rather underpopulated |
22:50.13 |
starseeker |
and bu_brlcad_data doesn't know what's up on
Windows (at least from build-dir, which I suppose isn't too
surprising) |
23:06.08 |
*** join/#brlcad epileg
(~epileg@unaffiliated/epileg) |
23:46.11 |
brlcad |
starseeker: that could be related to path
separator, or trying to mix one style of separator with
another |