00:01.49 |
brlcad |
if you post just one patch to the patches
tracker, I'd just as well give you commit access so long as you've
read the hacking file |
00:02.21 |
yukonbob |
where's that document? |
00:02.24 |
brlcad |
all commits are reviewed by myself and others,
so the more the merrier ;) |
00:02.31 |
brlcad |
new devs welcome |
00:02.35 |
brlcad |
it's in the top-level |
00:02.37 |
brlcad |
HACKING |
00:02.49 |
brlcad |
that's the basic dev guide |
00:03.53 |
brlcad |
nothing is set in stone, but it at least lays
down some consistency structure |
00:04.49 |
brlcad |
intentionally do avoid some of the more
mundane "bikeshed" issues |
00:06.02 |
IriX64 |
and i suppose if i bitch long enough you'll
ask me why I don't fix it myself ;) |
00:06.21 |
brlcad |
IriX64: in your case, no I wouldn't
:) |
00:06.42 |
IriX64 |
good just so you know I'm *not capable
:) |
00:07.34 |
brlcad |
now is an opportune time for devs though as
the activity is such that even my ability to review all commits
isn't swamped yet (such that new devs couldn't be added without
peer-review delegation) |
00:08.04 |
IriX64 |
no...thanks :) |
00:09.32 |
IriX64 |
http://rafb.net/p/IwLSo887.html
heh look at the cflags |
00:10.24 |
brlcad |
IriX64: not bad, that will get you better
performance |
00:10.50 |
brlcad |
it's something that would be nice to do
automatically some day when --enable-optimized is turned on
too |
00:10.57 |
brlcad |
at least some variation |
00:11.09 |
IriX64 |
should i'm hoping it works actually |
00:11.17 |
brlcad |
IriX64: there are other gcc flags that will
give you even more performance that you might want to test out as
well |
00:11.51 |
IriX64 |
thankyou ill look :) |
00:11.52 |
brlcad |
given how much you like to compile and run the
benchmarks, that certainly be useful to figure out -- what's the
absolute best performance you can get simply out of tweaking
compilation CFLAGS |
00:12.23 |
IriX64 |
have to disable debug and symbols tho if you
really want it to scream |
00:12.47 |
IriX64 |
i like debug on :) |
00:13.10 |
brlcad |
another set of flags are the ones for
alignment, i.e. -falign-functions, -falign-jumps, -falign-labels,
-falign-loops, etc .. those can boost performance particularly well
and in concert with other flags |
00:13.28 |
IriX64 |
btw i was wrong flushall() isn't needed
fcloseall() does that too |
00:13.42 |
brlcad |
that was actually an amusing discovery --
disabling debug without turning on alignment can actually slow it
down |
00:14.03 |
IriX64 |
heh ill play |
00:14.03 |
IriX64 |
don't mind waiting 50 minutes per |
00:14.16 |
brlcad |
IriX64: abort() closes any descriptors that
weren't closed too |
00:14.37 |
IriX64 |
never used abort so i don't know |
00:18.14 |
yukonbob |
brlcad: rock'n'roll... I'll let you get back
to your work, and we can catch-up later for commit access (is cvs,
svn, other?) |
00:20.53 |
brlcad |
cvs at the moment, svn before the end of the
year |
00:21.18 |
CIA-4 |
BRL-CAD: 03brlcad * 10brlcad/src/util/pl-X.c:
use 'fixed' font by default instead of the obscure 'vtsingle'
font.. should really have a cmd-line option to
set/override |
00:21.46 |
brlcad |
hm, now how to work pl-X .. haven't used it in
years |
00:22.02 |
yukonbob |
pl-X < my_plotfile.plot |
00:22.29 |
brlcad |
hrmph.. flashes my plot file then
exits |
00:23.34 |
brlcad |
ah, well now that's stupid... |
00:24.03 |
brlcad |
it just sleeps for a second then
exits |
00:24.12 |
yukonbob |
heh -- cheap |
00:24.13 |
brlcad |
and assumes single-buffered |
00:33.05 |
yukonbob |
heh -- no kidding? ;) What are you running
IriX64? |
00:33.16 |
IriX64 |
winaxe at the moment |
00:33.58 |
IriX64 |
shows the geometry in color but bring up a
frame buffer and the graphic screen and command screen go
black |
00:34.43 |
IriX64 |
touch one of those other screens and they
revert to normal tho |
00:36.28 |
IriX64 |
nice online help tho |
00:37.39 |
IriX64 |
twingy was right i know nothing about
lighting, all my havoc photonmaps come out sorta dark |
00:40.52 |
IriX64 |
doh...it's taking so long cause you started a
compile and forgot about it goof :) |
00:41.54 |
IriX64 |
http://www.winaxe.com/x-windows-for-windows.html |
00:42.00 |
IriX64 |
there yukonbob |
00:48.30 |
IriX64 |
still have fits trying to cut from the xside
and pasting to the windows side |
00:51.10 |
yukonbob |
winaxe looks like an x server, not a window
manager... |
00:51.10 |
yukonbob |
how long does evaluation last? |
00:51.29 |
IriX64 |
thats what it is and a whole lot
more |
00:51.41 |
IriX64 |
hasn't expired yet and ive had it a
month |
00:53.21 |
IriX64 |
whup oh well :) |
01:00.49 |
IriX64 |
demo time is up oh well |
01:02.30 |
*** join/#brlcad yukonbob
(n=bch@whthyt224-180.northwestel.net) |
01:04.17 |
IriX64 |
yukonbob it's demo ware shuts down on you
after i think 60 minutes |
01:05.12 |
yukonbob |
IriX64: so did you buy your copy? |
01:05.16 |
yukonbob |
brlcad: the built-in regex in brlcad... is it
just henry spencers lib, or ?? |
01:09.38 |
brlcad |
yes it is |
01:11.11 |
brlcad |
everything in src/other is really just
provided for compilation convenience so users don't have to go
download anything -- using pre-installed or build-system installed
libraries are generally preferred of course |
01:11.53 |
brlcad |
libregex is an interesting case, though --
have found several regex implementations that perform
_considerably_ slower than spencer's earlier 90 |
01:12.11 |
yukonbob |
right -- I'm just going through all this on my
NetBSD system to try to build dependencies w/i the pkgsrc system,
and keep everything "admin-able" w/i the pgksrc
framework... |
01:12.20 |
brlcad |
90's implementation .. or buggy even, where
spencers has no problem (with massive expressions for
example) |
01:13.22 |
brlcad |
yukonbob: ideally, you should/could get it to
work with --disable-almost-everything (and maybe then add
--enable-tcl-build --enable-tk-build since they're
pre-release) |
01:13.46 |
yukonbob |
brlcad: I'm still playing w/ 7.8, since it's
not dealing w/ 8.5... |
01:15.25 |
yukonbob |
I use tcl/tk on my system anyway... if I
wasn't worried about collisions, I'd just install the
8.5... |
01:15.26 |
brlcad |
i really wish we didn't have to upgrade to
8.5, it's the first time in recent memory (ever?) that we've gone
to a pre-release version, usually hanging behind a few
versions |
01:15.45 |
brlcad |
but getting AquaTk working is a bit of a
high-priority item |
01:16.10 |
yukonbob |
I guess I could install a chroot environ for
brlcad and go w/ 8.5... |
01:16.27 |
brlcad |
the problem you'll run into in 7.8 is that we
actually required a custom tk |
01:16.40 |
brlcad |
brl-cad included several tk mods that were
being integrated upstream into tk |
01:16.49 |
brlcad |
new canvas widget in particular |
01:17.48 |
brlcad |
the process with the tcl/tk folks, however,
just become too much of a burden so much of that code has been
rewritten, decoupled, and/or removed, so that we can build with a
clean tcl/tk again -- none of those changes are in 7.8 though
iirc |
01:18.13 |
brlcad |
that's functionality limited to just one
feature of mged, but it means you'll probably have to have a patch
to successfully compile against a system tcl/tk |
01:19.44 |
yukonbob |
ahh --- that makes sense --- I witnessed what
you were talking about, but didn't finish looking into
it... |
01:19.58 |
yukonbob |
7.10 removes that restriction? |
01:20.15 |
brlcad |
our tk enhancements are the predominant reason
why we're still not integrated into the various package management
systems like ports, apt, fink, etc, and part of the motivation for
much of the changes in 7.10 |
01:20.43 |
brlcad |
yeah, latest head removes that restriction and
builds cleanly now |
01:22.01 |
yukonbob |
alright -- well, I've got 7.8.4 building on my
machine, but using it's (necessarily) custom tcl/tk... but I'm
going to move to playing w/ 7.10 then... tcl/tk 8.5 is going to
have to make it to the system sometime anyway... |
01:23.22 |
yukonbob |
what's the feature of mged that required the
core-patch to tk? |
01:24.06 |
brlcad |
the Sketch Editor |
01:24.22 |
brlcad |
it draws on a custom Bezier Canvas
widget |
01:24.36 |
yukonbob |
right -- /me explored that
briefly... |
01:25.05 |
brlcad |
that's the item in the TODO remaining for
7.10.2 release that I've left to deal with |
01:25.22 |
yukonbob |
there's currently no sketch editor? |
01:25.24 |
brlcad |
as it's presently just turned off -- need to
make it use a different canvas widget |
01:25.48 |
yukonbob |
OK -- so sketching fucntionality is
temporarily missing in 7.10.x, correct? |
01:25.48 |
brlcad |
currently on head -- should be restored prior
to release, but I have to code that up |
01:26.21 |
brlcad |
in 7.10.1 yes |
01:34.02 |
brlcad |
``Erik: just fyi, a particular server is under
massive woes at the moment .. went nutty and eventually locked
up |
01:34.53 |
brlcad |
it was having a helluva time scrubbing ..
massive delays and crashed or was rebooted this morning, and spent
most of the day fscking only to later lock up hard |
01:36.49 |
``Erik |
um |
01:36.55 |
``Erik |
bring it up single user mode |
01:36.55 |
Twingy |
you guys haven't thrown that in the garbage
can yet? |
01:36.59 |
``Erik |
disable background fsck |
01:37.08 |
Twingy |
it's ancient |
01:37.09 |
brlcad |
massive woes with services after the earlier
reboot too, many libraries were apparently updated without the
tools being rebuilt so they all fail with missing library errors
(this was before the crash) |
01:37.10 |
``Erik |
that's what kills it |
01:37.25 |
``Erik |
huh |
01:37.29 |
``Erik |
:/ |
01:37.34 |
``Erik |
didja world it? |
01:37.38 |
``Erik |
um |
01:37.40 |
brlcad |
i was in the midst of rebuilding smbd when it
locked up |
01:37.54 |
``Erik |
I think the only big consumers left are us and
bills guys |
01:38.14 |
brlcad |
yeah, bills guys were up in arms as he's got
pjt breathing down at him for some data |
01:38.28 |
brlcad |
I'll be in early early tomorrow to hopefully
upline it |
01:38.46 |
``Erik |
um, you can mount it ro |
01:38.49 |
``Erik |
to get the data to 'em |
01:39.27 |
brlcad |
well at the moment, it aint doing anything
since it locked up -- didn't have time to deal with the crash
today |
01:40.02 |
``Erik |
um, when ti's booting, and hits the |/-\
scroller, hit backspace or something, do "boot -s" to get single
user mode |
01:40.12 |
``Erik |
then you can mount stuff up, etc, get the
production need off |
01:40.24 |
brlcad |
I can manage, but thought you might like to
know in case you try to get in .. 2 is still scrubbing btw (with
curiously/exceptionally low cpu/io usage) |
01:40.48 |
brlcad |
where's background fsck stashed? |
01:58.49 |
*** join/#brlcad IriX64
(n=mario_du@bas2-sudbury98-1096601029.dsl.bell.ca) |
02:02.30 |
IriX64 |
rotten cat keeps pressing my reboot button
while crying for milk :) |
02:03.15 |
IriX64 |
yukonbob if you're interested in windows
xservers xwin32 is pretty decent too |
02:03.26 |
IriX64 |
commercial also |
02:03.57 |
IriX64 |
also mi_x 4.2 |
02:04.11 |
IriX64 |
and my fav cygwin-x |
02:12.26 |
``Erik |
/etc/rc.conf has the inf0z, um, it's a feature
to regular fsck |
02:12.33 |
``Erik |
-F vs -B or something |
02:13.00 |
``Erik |
background fsck requires soft updates turned
on, so if you have it unmounted, you COULD use tunefs to disable
softupdates |
02:13.07 |
``Erik |
I believe you can turn them back on with the
fs live |
02:13.40 |
``Erik |
(softupdates is essentially a smarter
operation order, the theory being that by doing the ops in a
concurrency friendly order, a journaled FS is
unnecessary) |
02:14.24 |
brlcad |
how long does the fsck usually take? |
02:14.41 |
``Erik |
straight fsck without softupdates (fg mode) is
maybe 1-1.5 hours |
02:15.18 |
brlcad |
i might just bring it up single user then, do
the fsck, then get them their data |
02:15.37 |
brlcad |
then fool around with any fixings |
02:15.42 |
``Erik |
that'd be the best way, I think |
02:15.59 |
``Erik |
I'll try to keep half an eye on irc, or you
have my cellphone # |
02:16.15 |
brlcad |
you're on vacation, I ain't calling |
02:16.22 |
brlcad |
that's just wrong |
02:16.32 |
``Erik |
aight *shrug* |
02:16.36 |
brlcad |
:) |
02:16.37 |
``Erik |
if you get terribly stuck, though
*shrug* |
02:16.47 |
``Erik |
I seriously doubt you will |
02:16.52 |
``Erik |
but *shrug* |
02:17.15 |
brlcad |
maybe someone would call the MPs and say
there's something explosive inside the case |
02:17.40 |
``Erik |
my big plans for tomorrow are to make pretzels
from scratch *shrug* |
02:17.50 |
``Erik |
heh, different kind of "blow up" |
02:18.14 |
brlcad |
the server's .. uh .. down.
permanently. |
02:18.34 |
``Erik |
up... way up.. in many pieces... |
02:20.39 |
IriX64 |
http://rafb.net/p/PujJym17.html
dunno if i should paste stuff like this |
02:21.31 |
IriX64 |
if xwin32 doesn't time out on me ill post the
results on the blog |
02:26.30 |
IriX64 |
http://irix32.spaces.live.com/photos
brlcad albumn first pix |
02:28.16 |
IriX64 |
should test some of the other lighting models
i guess |
02:28.19 |
poolio |
brlcad: Tomorrow I'm probably going to be
researching/designing the GA framework. If I write / sketch stuff
by hand, is it fine if I just keep that to myself and use it or
would you rather be able to see my progress/ideas |
02:46.15 |
brlcad |
IriX64: not unless you intend to fix them
:) |
02:46.44 |
brlcad |
sub millimeter overlaps are not cause for
concern regardless, you can quell the reporting with a command line
option |
02:47.21 |
IriX64 |
the lighting models? |
02:47.38 |
IriX64 |
fix them? snort! |
02:47.41 |
brlcad |
poolio: your development workflow is your own
.. just the code should be very well documented as to what is going
on, even if you need to resort to ascii art :) |
02:47.48 |
brlcad |
IriX64: no, the overlaps |
02:49.47 |
poolio |
brlcad: so you won't be worried if you don't
see code? (my main question was proving that I was
working( |
02:50.01 |
IriX64 |
the overlap tool is capable of that but i
don't know what i'm doing with it |
02:50.45 |
IriX64 |
err gui overlap tool |
02:51.05 |
IriX64 |
ill show you it wait a few minutes |
02:54.10 |
brlcad |
poolio: ahh, no, that's fine |
02:54.28 |
IriX64 |
the blog brlcad albumn tool1 &
tool2 |
02:54.39 |
poolio |
brlcad: ok. I'll try to get the main framework
outline done and include that as part of my project writeup and
email that to you tomorrow |
02:55.03 |
brlcad |
IriX64: I don't want/need to see the overlap
tool .. I know more than well enough what all of mged looks like
... |
02:55.25 |
IriX64 |
sorry thought you expressed an interest
:) |
02:55.26 |
brlcad |
poolio: sounds great |
03:03.29 |
*** join/#brlcad yukonbob_
(n=bch@whthyt247-240.northwestel.net) |
03:06.08 |
IriX64 |
watch it poolio he'll send the policio after
you if it's not proper :) |
03:06.43 |
IriX64 |
maybe that should be mpios :) |
03:07.29 |
IriX64 |
brlcad got time to tend to my build problem or
should we shelve that for now? |
03:12.40 |
IriX64 |
same blog same albumn compare to the native
windows version. |
03:12.45 |
IriX64 |
tool3 |
03:13.46 |
IriX64 |
that bob@mako is good :) |
03:16.28 |
IriX64 |
prefer the cygwin port myself ;) |
03:20.42 |
brlcad |
IriX64: i'm working on it |
03:22.49 |
poolio |
brlcad: did you try running the beset fitness
test prog? I just want to make sure I added it to cvs
right |
03:24.36 |
poolio |
brlcad: also when you were saying variable
length genomes were difficult, had you ever looked at genetic
programming? Apparently GAs and GPs aren't just synonyms, GPs are
tailored to run on trees (of variable sizes) |
03:38.48 |
IriX64 |
I'm reloading the IriX64 blog with past
effortts,designs,disasters :) |
03:39.40 |
IriX64 |
The IriX32 blog is only half of me
:) |
03:45.08 |
IriX64 |
http://irix64.spaces.live.com/photos |
03:52.04 |
*** join/#brlcad PrezKennedy
(n=Matthew@c-76-106-124-125.hsd1.md.comcast.net) |
03:57.15 |
*** join/#brlcad yukonbob
(n=bch@whthyt247-240.northwestel.net) |
05:25.07 |
CIA-4 |
BRL-CAD: 03brlcad *
10brlcad/src/util/pl-X.c: |
05:25.07 |
CIA-4 |
BRL-CAD: big update/enhancements so that pl-X
is actually functional and useful. if the |
05:25.07 |
CIA-4 |
BRL-CAD: last command in a plot file is an
erase command, don't do it (wth show a black |
05:25.07 |
CIA-4 |
BRL-CAD: window). most importantly, keep the
window up until the user presses a key. |
05:25.07 |
CIA-4 |
BRL-CAD: additional goodness, if we're on Mac
OS X, make sure X11 has focus. ignore |
05:25.09 |
CIA-4 |
BRL-CAD: newlines in the file for
kicks. |
06:47.53 |
*** join/#brlcad akreal
(n=ak@ll-81-222-164-251.awanti.ru) |
07:20.10 |
*** join/#brlcad Laniakea
(n=clock@zux221-122-143.adsl.green.ch) |
07:58.47 |
*** join/#brlcad Laniakea
(n=clock@zux221-122-143.adsl.green.ch) |
07:59.19 |
*** join/#brlcad Laniakea
(n=clock@zux221-122-143.adsl.green.ch) |
08:34.52 |
*** join/#brlcad yukonbob
(n=bch@whthyt247-240.northwestel.net) |
08:53.59 |
*** join/#brlcad CIA-4
(n=CIA@208.69.182.149) |
09:00.31 |
*** join/#brlcad CIA-4
(i=cia@208.69.182.149) |
09:04.36 |
*** join/#brlcad fressbaer
(i=fressbae@gateway/tor/x-76142f652052e383) |
09:04.43 |
fressbaer |
hello |
09:18.04 |
*** join/#brlcad CIA-4
(n=CIA@208.69.182.149) |
09:42.13 |
*** join/#brlcad CIA-4
(i=cia@208.69.182.149) |
09:46.58 |
*** join/#brlcad Bariton
(n=Bary@p54875D9F.dip.t-dialin.net) |
10:02.46 |
*** join/#brlcad CIA-4
(n=CIA@208.69.182.149) |
10:23.39 |
*** join/#brlcad CIA-4
(n=CIA@208.69.182.149) |
10:41.40 |
*** join/#brlcad CIA-4
(i=cia@208.69.182.149) |
11:19.27 |
*** join/#brlcad docelic
(n=docelic@212.91.116.121) |
11:26.39 |
*** join/#brlcad thing0
(n=ric@124-168-87-73.dyn.iinet.net.au) |
11:26.52 |
thing0 |
hey all |
11:40.57 |
*** join/#brlcad elite01
(n=elite01@dslc-082-082-095-242.pools.arcor-ip.net) |
11:41.28 |
thing0 |
hey elite01 |
11:41.29 |
thing0 |
sup? |
11:41.36 |
elite01 |
home! :) |
11:41.39 |
elite01 |
(just got home) |
11:42.00 |
elite01 |
and now, fortune spit with a quote form "Edwim
Schrodinger" at me |
11:47.08 |
*** join/#brlcad thing1
(n=ric@124-168-87-73.dyn.iinet.net.au) |
11:47.11 |
*** part/#brlcad thing1
(n=ric@124-168-87-73.dyn.iinet.net.au) |
11:47.13 |
*** join/#brlcad thing1
(n=ric@124-168-87-73.dyn.iinet.net.au) |
11:47.28 |
thing1 |
damn dialup drop out |
11:47.29 |
thing1 |
argh |
11:47.29 |
thing1 |
hehe |
11:50.27 |
thing1 |
damn |
13:51.47 |
*** join/#brlcad elite01
(n=elite01@dslc-082-082-095-242.pools.arcor-ip.net) |
15:20.28 |
*** join/#brlcad CIA-4
(n=CIA@208.69.182.149) |
15:43.27 |
*** join/#brlcad CIA-4
(n=CIA@208.69.182.149) |
16:01.37 |
*** join/#brlcad akreal
(n=ak@ll-81-222-164-251.awanti.ru) |
16:03.25 |
*** join/#brlcad CIA-4
(n=CIA@208.69.182.149) |
16:15.49 |
*** join/#brlcad CIA-4
(n=CIA@208.69.182.149) |
16:57.56 |
*** join/#brlcad CIA-4
(n=CIA@208.69.182.149) |
17:57.32 |
*** join/#brlcad Laniakea
(i=clock@77-56-107-241.dclient.hispeed.ch) |
18:17.17 |
poolio |
brlcad: You've got mail :) |
18:35.30 |
*** join/#brlcad jimmyz
(n=asd@host86-133-245-247.range86-133.btcentralplus.com) |
18:54.07 |
poolio |
brlcad: also when you get a chance, maybe you
could explain how brlcad deals with the CSG trees :) |
19:31.31 |
IriX64 |
make install |
19:34.55 |
IriX64 |
http://rafb.net/p/VZiv2N84.html
< --- fbserv on the windows side :) |
19:41.20 |
IriX64 |
http://rafb.net/p/axrGmn24.html
< --- heheh it works sorrry to be so verbose :) |
19:42.39 |
*** join/#brlcad IriX64_
(n=mario_du@bas2-sudbury98-1096601029.dsl.bell.ca) |
19:46.11 |
IriX64 |
now to copy my latest effort from cygwin to
windows.... wish me luck :) |
19:48.09 |
IriX64 |
this thing is huge, over a gig for the tree,
course thats a static compile |
19:48.47 |
IriX64 |
err link |
19:50.34 |
IriX64 |
name something that by all rights should not
work, i'm trying to be complete here |
19:51.20 |
IriX64 |
man 2,708 files, 90 folders |
19:51.57 |
IriX64 |
thats everything except adrt |
19:55.30 |
IriX64 |
crap metaball creation still crashes it
:( |
20:04.57 |
IriX64 |
http://rafb.net/p/8AaDui37.html
< --- just so you know i'm working with your code |
20:24.31 |
IriX64 |
ah i see metaball not implemented in this
version |
20:24.58 |
IriX64 |
so why does it crash mged |
20:41.27 |
IriX64 |
bu_log..... |
20:42.05 |
IriX64 |
to each his own :) |
20:47.58 |
*** join/#brlcad Elperion
(n=Bary@p54875D9F.dip.t-dialin.net) |
21:13.11 |
IriX64 |
48kc ... interesting :) |
21:16.46 |
IriX64 |
starting another tree to go edit happy in,
yours brlcad awaits you :) |
21:18.00 |
brlcad |
poolio: got it, thanks! |
21:18.07 |
brlcad |
IriX64: five lines... |
21:18.29 |
IriX64 |
again i don't count well but ill try |
21:19.20 |
IriX64 |
you've gotta admit what i lack in expertise i
make up form in enthusiasm :) |
21:21.09 |
poolio |
brlcad: cool cool. I've started kind of
outlining in pseudocode what the framework is gonna be
like |
21:21.23 |
brlcad |
IriX64: which is the main reason you've not
been ejected ;) |
21:21.35 |
brlcad |
others wouldn't be so patient |
21:21.39 |
brlcad |
so please try to count |
21:21.42 |
IriX64 |
heh thanks for your tolerance :) |
21:21.47 |
IriX64 |
ill try |
21:23.26 |
poolio |
brlcad: the whole tree layout and whatnot in
librt are quite confusing to me :$ |
21:24.27 |
brlcad |
poolio: I'll read it in more detail later this
evening and add some of my own comments and edits for sharing
around "in house" (mainly adding extra detail on the "big picture"
of why try to do this at all) |
21:25.23 |
brlcad |
poolio: the csg tree is a directed acyclic
graph that can be turned into a binary directed tree or left in
graph form |
21:25.51 |
brlcad |
you generally don't have to care other than
knowing how to create a hierarchy (which you don't need just yet
;) |
21:26.56 |
brlcad |
first input test case should be just a simple
sphere |
21:37.09 |
poolio |
brlcad: Yes, but I'd like to have it correclty
interact with the csg tree, even if it's just one shape |
21:38.15 |
poolio |
brlcad: I'd also appreciate more comments on
the big picture, I don't think I entirely understand it
:) |
21:39.29 |
poolio |
bascially I want to learn how to work with the
csg tree now, that way everything will work the same when I go to
more shapes or operations the current structure won't work and will
need to be heavily updated. I'd pretty much have to rewrite all of
the genome encoding and reading stuff |
21:44.49 |
brlcad |
poolio: from a construction perspective, maybe
look at src/proc-db and man libwdb |
21:45.12 |
brlcad |
and perhaps src/mk |
21:45.30 |
brlcad |
they includes lots of examples on creating
geometry in memory, creating .g geometry files |
21:46.12 |
poolio |
alright cool |
21:46.34 |
poolio |
also, is a good way of approaching the storage
of objects putting htem in a .g file and
manipulating/reading/writing from there? that's the way I currently
hvae it set up |
21:46.40 |
brlcad |
there's a way to create/open in-memory-only
geometry files as well, but I'd recommend actually sticking to
creating actual files so results can be reviewed, manually loaded,
etc |
21:47.07 |
poolio |
brlcad: Well I think it's probalby better to
keep it optionally stored to a file, that way if you want to speed
it up when you run in parallel it will be a lot better |
21:47.14 |
poolio |
otherwise you're transmitting quite a lot of
data back and forth |
21:47.58 |
brlcad |
fwiw, that's getting into the realm of
optimization where you've not yet profiled .. |
21:48.11 |
poolio |
true :P |
21:48.34 |
poolio |
It's just a thought. Also for me testing I
need to try to keep it reasonably fast otherwise I might go days
computing |
21:48.52 |
brlcad |
it's a good concern, but I can categorically
say that you're very likely not going to be I/O bound writing
geometry to disk -- ray-tracing will dominate |
21:48.55 |
poolio |
and I don't know how large the .g file will
grow to, but I guess I can always just scale it down |
21:49.35 |
brlcad |
the .g files shouldn't be more than a few K,
they're rather compact for CSG |
21:50.04 |
brlcad |
a full tank in csg can be often only a few
MB |
21:50.24 |
poolio |
brlcad: ok :) |
21:50.24 |
brlcad |
whereas in polygonal form, they might be a
GB |
21:50.47 |
brlcad |
there's about two orders of magnitude
difference |
21:51.11 |
poolio |
that's quite crazy. Some insane compression if
it works well :) |
21:54.42 |
poolio |
brlcad: also the reason I want to work with
trees is because of the crossover, mutation, and reproduction
aspects. I'd rather code them to work with trees than with whatever
shape I'm working with |
21:54.50 |
poolio |
although I guess the only thing that will
exist is mutation |
21:54.51 |
brlcad |
.g overhead is 104 bytes to stub out an empty
file, each primitive is roughly about 100-500 bytes |
21:54.54 |
poolio |
(in a one-shape system) |
21:56.00 |
*** join/#brlcad _yukonbob
(n=bch@whthyt224-180.northwestel.net) |
22:24.02 |
IriX64 |
anybody know the latest version of solaris?
issolaris5 is good but.. |
22:24.11 |
IriX64 |
ie too |
22:43.06 |
IriX64 |
haha solaris10 :) |
22:43.51 |
IriX64 |
testing your solaris code i.e -DSOLARIS
:) |
22:51.21 |
IriX64 |
http://rafb.net/p/z44nf372.html
lets see if it even starts to build |
22:54.12 |
IriX64 |
http://rafb.net/p/oJxZEi22.html
heh i'll shutup now :) |