| 01:27.25 | *** join/#brlcad IriX64_ (n=who@toronto-HSE-ppp4310781.sympatico.ca) | |
| 01:29.41 | Mario | hahah already taken. |
| 01:31.18 | MarioD | now you know me :) |
| 01:31.24 | MarioD | and its registered. |
| 01:35.00 | brlcad | MarioD: what does ymp stand for? |
| 01:37.56 | MarioD | cray multi-processing |
| 01:41.04 | brlcad | heh, so you did mean that |
| 01:41.31 | brlcad | why in the world did you put that on the ftp upload to windows binaries? |
| 01:42.06 | MarioD | say what? |
| 01:42.19 | MarioD | my transfer never completed. |
| 01:43.13 | ``Erik | o.O |
| 01:43.26 | MarioD | somebody's trying to do me dirt brlcad. |
| 01:43.31 | ``Erik | new windows super computing edition for cray? blue-screen faster than ever? :D |
| 01:43.48 | MarioD | heheh ``Erik craydows :) |
| 01:44.49 | ``Erik | in case someone hasn't seen it yet.. http://www.columbusdiscgolf.com/IMAGES/LOTRsig.gif |
| 01:45.44 | MarioD | elf?!? |
| 01:46.14 | MarioD | Robin Goodfellow :) |
| 01:48.38 | ``Erik | uh... did you enjoy a lot of wall candy when you were a kid? |
| 01:49.05 | MarioD | i smoke... i don't toke :) |
| 01:49.28 | ``Erik | uh... that's not what wall candy is... |
| 01:49.38 | MarioD | judeg me by my iq number will you ? ;) |
| 01:49.47 | ``Erik | O:-) |
| 01:49.57 | MarioD | so elucidate what the fark is wall candy? |
| 01:50.08 | brlcad | MarioD: one of the transfers completed, I decompressed it |
| 01:50.24 | MarioD | no not mine, both my transfers aborted. |
| 01:50.37 | brlcad | still, doesn't explain why you'd choose a cray designation on windows binaries.. ;) |
| 01:50.42 | ``Erik | ... well... long long ago, people used lead based paint for their walls... and eventually it'd start flaking... and kids would eat it... and, uh, become slightly mentally deficient... hockey helmet, water wings, etc |
| 01:50.49 | MarioD | i DIDN'T!!! |
| 01:51.12 | ``Erik | O:-) |
| 01:51.30 | MarioD | ahhh i see eric dumb of me not to have made the connection, perhaps i inhaled a few flakes. |
| 01:51.43 | brlcad | you say they aborted.. what aborted? |
| 01:51.51 | MarioD | the uploads. |
| 01:51.58 | brlcad | i mean what were the filenames of what you were uploading.. |
| 01:52.06 | MarioD | disconnected connection closed by remote host. |
| 01:52.29 | MarioD | one was linuxbrlcad.zip and the other was ympbrlcad.zip |
| 01:52.41 | ``Erik | why 'ympbrlcad'? |
| 01:52.54 | brlcad | okay, there you have it.. yes, why ymp for windows binaries? :) |
| 01:53.05 | MarioD | man..... i was hoping youd take a chance and test it. |
| 01:53.32 | brlcad | heh |
| 01:53.41 | MarioD | do you or do you not have that cray in your database drawings file? |
| 01:54.03 | brlcad | i wouldn't copy user-provided binaries to HPC assets |
| 01:54.03 | MarioD | i dont do that eric. |
| 01:54.06 | ``Erik | yeah, like an old cray2... |
| 01:54.08 | ``Erik | but, uh... |
| 01:54.17 | ``Erik | DUDE, you DID |
| 01:54.35 | MarioD | no i didnt whats the ip it came from? |
| 01:54.38 | ``Erik | when we see 'ympbrlcad', we see "this is brlcad built for a cray machine runnign unicos" |
| 01:54.50 | MarioD | exactly. |
| 01:55.20 | MarioD | thats the problem with anonymous ftp its so easy to smear someone, now ill shut up. |
| 01:55.24 | brlcad | actually, I highly doubted it was cray binaries and simply assumed ymp had to mean something else :) |
| 01:55.33 | MarioD | heh |
| 01:55.42 | brlcad | especially after a file type showed they certainly were not |
| 01:55.49 | ``Erik | (unicos is a funkyarsed OS, btw) |
| 01:56.01 | MarioD | mvp 12 7809 |
| 01:56.27 | MarioD | smoke break. |
| 02:07.33 | MarioD | man..now it's bugging me, my transfers never completed , i swear, if you keep aborted files you should have a ymp-brlcad.zip and a partial linuxbrlcad.zip too im sorry i caused you grief, i won't repeat the mistake. |
| 02:07.58 | MarioD | back to work. |
| 02:08.00 | brlcad | there were several versions of each, it iterates versions |
| 02:08.16 | MarioD | my client keeps trying. |
| 02:08.28 | brlcad | no surprise |
| 02:08.35 | ``Erik | quit letting it do that |
| 02:08.49 | MarioD | heh yah i should not have gone to bed... sue me :) |
| 02:09.17 | MarioD | plz appoint one. |
| 02:09.25 | ``Erik | mr hat! |
| 02:09.32 | MarioD | mrs cat |
| 02:09.36 | MarioD | ! |
| 02:09.40 | ``Erik | had her |
| 02:09.42 | ``Erik | I mean, uh |
| 02:09.47 | ``Erik | O:-) |
| 02:09.57 | MarioD | heh thats the name of the house smooz. |
| 02:10.43 | MarioD | for me work calls, for you duty calls have at her....;) |
| 02:53.09 | MarioD | say ``Erik do you have access to a vax boxen? |
| 02:53.42 | MarioD | vax code generator is complete. |
| 02:58.29 | MarioD | my days as an FSE for DEC came in handy here :) |
| 02:59.27 | *** join/#brlcad DTRemenak (n=DTRemena@c-24-23-59-104.hsd1.ca.comcast.net) | |
| 07:42.53 | *** join/#brlcad Twingy (n=justin@c-69-250-236-111.hsd1.md.comcast.net) | |
| 14:04.47 | IriX64 | ./configure --build=pdp11/70 <---- system pdp11/70 not recognized... *GOOF* doh. |
| 14:05.19 | IriX64 | its pdp11 dork. :) |
| 14:06.02 | IriX64 | brlcad for the pdp11 ultrix systems, sweet. |
| 14:08.36 | IriX64 | time to build one for myself. |
| 14:40.13 | IriX64 | 10 years worth of work just to compile BRL-CAD ? ;) |
| 14:40.36 | IriX64 | ``Erik i'll buy it from you i was not given one when i left :P |
| 14:41.05 | ``Erik | if you have a pdp crosscompiler on your windows machine, I would be HIGHLY surprised. Bear in mind, just because you say --build=somearch does NOT mean it'll actually build for that arch... you need the appropriate crosscompiler installed... a full compiler for each target |
| 14:41.06 | IriX64 | they gave me a watch instead :) |
| 14:41.11 | ``Erik | (and --target is the right flag) |
| 14:41.30 | IriX64 | heh |
| 14:41.31 | IriX64 | ok |
| 14:41.59 | IriX64 | unless of course your configuring *as a pdp11/70. |
| 14:43.46 | ``Erik | eh? |
| 14:44.52 | IriX64 | set build type if a cross compiler is detected it will be used direct quote from configure. |
| 14:45.04 | IriX64 | dont use --host. |
| 14:46.33 | IriX64 | i try to configure my compiler and linker ``Erik, different approach to that of gcc. |
| 14:47.25 | IriX64 | heh where were you with your questions all these years? |
| 14:47.29 | IriX64 | :) |
| 14:47.40 | ``Erik | o.O |
| 14:48.16 | IriX64 | set CC=cassie.exe and set LD=cassield.exe is what i live by. |
| 14:48.41 | IriX64 | hrmph or in some cases die by. :) |
| 14:49.18 | IriX64 | what do you call yours? |
| 14:49.33 | ``Erik | erm, heh, which ones? |
| 14:49.35 | ``Erik | :> |
| 14:49.46 | IriX64 | the most popular one heh. |
| 14:50.00 | IriX64 | gcc right? |
| 14:50.02 | IriX64 | :) |
| 14:50.12 | ``Erik | well, I've provided aid to bigger projects... the ones that are actually mine are pet projects that haven't been released |
| 14:50.19 | ``Erik | nah, I don't mess with gcc |
| 14:50.25 | IriX64 | ill show you a collect ;) |
| 14:50.36 | ``Erik | the 'compiler' I've probably done the most with is gauche |
| 14:50.43 | IriX64 | mine will *never be released. |
| 14:50.54 | IriX64 | other plans for her. |
| 14:51.00 | ``Erik | <-- bit of a scheme head |
| 14:51.07 | IriX64 | gauche as in bouche? |
| 14:51.24 | ``Erik | no, gauche as in the japanese scheme compiler/interpreter? |
| 14:51.39 | IriX64 | ah dont know that one. |
| 15:04.47 | IriX64 | doing pix now how fast is a build on your cluster ``Erik? |
| 15:05.50 | ``Erik | um, I haven't done a build across the cluster yet |
| 15:05.51 | IriX64 | 45 mins 25 secs ... finally. |
| 15:06.22 | ``Erik | just a single node on a cluster... |
| 15:06.49 | IriX64 | sigh now 10 mins for the install... you know all computers wait at the same speed 18.2ticks/sec :) |
| 15:07.44 | ``Erik | hm, most of mine tick at either 100hz or 1000hz |
| 15:07.47 | ``Erik | depending on their role |
| 15:08.11 | IriX64 | dropped the g file did you? :) |
| 15:08.24 | ``Erik | huh? |
| 15:08.30 | IriX64 | heh |
| 15:08.53 | IriX64 | 100cps or 1000cps? |
| 15:09.52 | IriX64 | doing the jack stuff now...jack...jack shit, i know him :P |
| 15:10.15 | ``Erik | man, you need to lay off the crack |
| 15:10.33 | IriX64 | its that wall candy. |
| 15:11.18 | IriX64 | i do crack of dawn everyday |
| 15:11.46 | SWPadnos | 18.2 ticks/sec was the slowest the PC timer tick could be, but it can be much faster (possibly up to the full clock rate of 1.192MHz |
| 15:12.24 | IriX64 | the timer tick cant be changed youll break backwards compatibility. |
| 15:12.32 | SWPadnos | not really |
| 15:12.39 | IriX64 | its so. |
| 15:12.45 | IriX64 | they insist |
| 15:13.08 | SWPadnos | that may be true for DOS and Windows, but I assure you that the Linux kernel runs at 1000 Hz just fine |
| 15:13.37 | SWPadnos | or 100, or 250, or ... |
| 15:13.50 | IriX64 | its not programmable SWPadnos. |
| 15:13.53 | ``Erik | Elapsed compilation time: 3 minutes, 35 seconds |
| 15:13.55 | ``Erik | sweet |
| 15:14.09 | IriX64 | cmon. nothings that fast. |
| 15:14.15 | ``Erik | 12 core altix is |
| 15:14.24 | ``Erik | real 3m35.257s |
| 15:14.24 | ``Erik | user 14m55.047s |
| 15:14.24 | ``Erik | sys 6m18.258s |
| 15:14.27 | SWPadnos | some of us only had access to PDP-11s or PCs ;) |
| 15:14.30 | IriX64 | your serious here? |
| 15:14.44 | IriX64 | heh |
| 15:14.45 | brlcad | and that's optimized, unoptimized only takes about 2.5 minutes |
| 15:15.04 | ``Erik | numanumanuma |
| 15:15.05 | ``Erik | *duck* |
| 15:15.08 | brlcad | the 16 core takes about 2 |
| 15:15.14 | IriX64 | where do i swear allegiance :) |
| 15:15.14 | ``Erik | brlcad, you coming in today? |
| 15:15.20 | brlcad | nope |
| 15:15.26 | SWPadnos | my dual Opteron did a full optimized build in ~10 minutes, and that's dual single-core, 244s, with 800 MHz HT |
| 15:15.42 | brlcad | ``Erik: plan to actually get some work done, get some stuff coded |
| 15:15.50 | ``Erik | darn, I was hoping to bounce ideas about wdb for my meat balls |
| 15:15.59 | IriX64 | sigh im stoneage by comparison. |
| 15:16.05 | ``Erik | and the building is empty, heh |
| 15:16.23 | ``Erik | uh... opteron? ht? uh? |
| 15:16.46 | SWPadnos | heh |
| 15:17.08 | brlcad | there's a compilation threshhold where it's not really going to get any faster without parallel linking and multi-directory compilation parallelism |
| 15:17.27 | ``Erik | that's where a smarter make would be nice... :) |
| 15:17.31 | SWPadnos | are uou using recursive makefiles, or "submakefiles"? |
| 15:17.34 | IriX64 | ;) |
| 15:17.34 | SWPadnos | you |
| 15:17.36 | brlcad | there is a make rule that does parallel linking (make fast), that can give a boost on distributed compiles |
| 15:18.03 | SWPadnos | I'd bet that ccache or something similar would also help |
| 15:18.25 | ``Erik | uh, only on the second build... it makes the first a bit slower |
| 15:18.42 | brlcad | recursive |
| 15:19.09 | SWPadnos | ``Erik, ok - I wasn't sure if multiple files in the build would have an advantage (if they use similar headers) |
| 15:19.19 | brlcad | non-recursive starts to fall apart the larger the project gets |
| 15:19.35 | IriX64 | dudes whats with terra.g mged crashes on it, mapped file open failed. |
| 15:19.38 | SWPadnos | brlcad, we found that changing to a hierarchical make sped up emc compilation by ~2-3x |
| 15:19.52 | SWPadnos | and made it so you could actually cvs up and get correct builds ;) |
| 15:20.16 | SWPadnos | hmmm - maybe only 2x or so, not 3x |
| 15:20.20 | brlcad | i don't doubt that it is usually faster |
| 15:20.25 | brlcad | the tradeoffs are in other aspects |
| 15:20.42 | SWPadnos | yeah - nobody's used to the method ;) |
| 15:20.57 | IriX64 | ERROR: NULL bu_mapped_file_pointer , file g_dsp.c line 3135 |
| 15:21.00 | brlcad | if you're a project composed of projects (which brl-cad is massively), then you've suddenly lost all the "free" build rules |
| 15:21.39 | brlcad | IriX64: that's a terrain database -- you probably have to find the datafile and have it in . or somesuch |
| 15:22.02 | IriX64 | thanks |
| 15:22.03 | brlcad | i.e. it's an outboard data file that is trying to be read in, and it fails because it can't find it |
| 15:25.18 | brlcad | SWPadnos: not only are folks unfamiliar with it, you have to manually create custom clean rules for every "subproject", there's no standard naming convention and make does not expose targets leaving users to guess, read docs, read the Makefile, etc instead of using the otherwise consistent convention of using cd to designate a selection |
| 15:26.42 | SWPadnos | the ability to cd <blah> and make is great, and I'm not sure if we needed that |
| 15:26.52 | SWPadnos | (I didn't do any of the makefile work - I don't know enough about it) |
| 15:27.25 | brlcad | it's pretty simple, does emc comprise multiple projects? :) |
| 15:27.35 | brlcad | or have a lot of binaries/libraries at least |
| 15:27.38 | SWPadnos | sort of |
| 15:27.41 | SWPadnos | yes |
| 15:27.52 | brlcad | what do you consider a lot? |
| 15:27.52 | SWPadnos | there are multiple GUIs, RT components, kernel modules, etc. |
| 15:28.21 | SWPadnos | there are roughly a dozen executables, and more than a dozen kernel modules, plus generated scripts and the like |
| 15:28.22 | brlcad | not referring to configuration items |
| 15:28.42 | brlcad | configure generally handles features/modules, not make directly |
| 15:29.08 | SWPadnos | well, you run the make from the top level src dir, and only from there ;) |
| 15:29.17 | brlcad | sure |
| 15:29.27 | brlcad | that's basic non-recursive make |
| 15:30.06 | SWPadnos | it used to be recursive, and we still did things that way |
| 15:30.32 | brlcad | i implemented the start of a non-recursive make for brl-cad but it really just wasn't providing a significant benefit and was going to require a considerable amount of extra work to match was current recursive make already provides |
| 15:30.34 | SWPadnos | there were annoying complications like having to create a temp headers dir and copy all .h files there, and other ugliness |
| 15:30.37 | ``Erik | recursive make is as fast as non-recursive if your subdirs are well populated... |
| 15:32.13 | brlcad | one of my biggest complaints against it is that the main arguments against recursive make are not based on user-experience, they are founded on limitations of make itself (that "could" be fixed) |
| 15:33.09 | SWPadnos | not really |
| 15:33.13 | brlcad | theoretically, we're using automake so if they were so inclined, they could turn all the Makefile.am's into a non-recursive setup, it's just such a massive amount of work that I doubt they ever will |
| 15:33.20 | brlcad | at least not this decade |
| 15:33.29 | SWPadnos | the issue is that make can't generate a complete dependency tree, because it doens't know about everything up front |
| 15:33.53 | brlcad | uhm, that's entirely a limitation of make itself |
| 15:34.38 | SWPadnos | not really - remember, the makefiles have multiple projects in them, so the information is being intentionally kept separate |
| 15:34.39 | brlcad | has nothing to do with the user interface aspect of building projects |
| 15:35.13 | SWPadnos | right |
| 15:36.28 | SWPadnos | http://www.canb.auug.org.au/~millerp/rmch/recu-make-cons-harm.html |
| 15:36.35 | brlcad | from an automake-using project perspective, the information is all there -- I've told it exactly which subdirs that tie into it |
| 15:36.51 | brlcad | yes, that's an ancient pile of tripe :) |
| 15:37.13 | SWPadnos | heh |
| 15:37.33 | SWPadnos | well - I shouldn't waste your time - I don't know enough to discuss the subject intelligently :) |
| 15:37.36 | brlcad | the entire arguement focuses on performance limitation, not usability |
| 15:38.27 | brlcad | it sacrifices implicit usability for the sake of performance (or at best delegating the role of usability onto developer hands) |
| 15:38.43 | brlcad | instead of focusing on the limitations of make and fixing the problem there |
| 15:38.47 | SWPadnos | the argument that got me wasn't about performance |
| 15:38.50 | brlcad | or automake should you have the case |
| 15:38.55 | SWPadnos | it was correctness |
| 15:39.26 | brlcad | i'd argue that there is nothing inherintly "incorrect" about recursive make in the least |
| 15:39.29 | SWPadnos | we had problems where a build wouldn't work until you did make clean (or just did a clean checkout) |
| 15:39.38 | brlcad | make could propagate information to children make processes |
| 15:39.44 | SWPadnos | and those were all solved by changing to a non-recursive make |
| 15:40.05 | SWPadnos | they may have been due to stupidities in the original makefiles though |
| 15:41.28 | brlcad | we used to see similar issues but it almost always traced down to either an automake bug or an invalid assumption or missing dependency in some Makefile.am |
| 15:42.13 | brlcad | it took a while to get in right, but now it does assuming the automake rev isn't buggy -- all dependencies update like they're documented to work when things are edited, things generally don't get "stuck" etc |
| 15:43.51 | brlcad | the biggest problem with recursive make that I see is a similar agreement that make should propagate state information |
| 15:44.46 | brlcad | i've talked to the gnu make devs to some extent about it and they mostly agreed after a similar long debate but basically boiled down to "it'd be a lot of work" and nobody wanted to do it |
| 15:45.37 | brlcad | easier to start yet another religion by declaring the hard way incorrect and the status quo correct :) |
| 15:49.37 | SWPadnos | FSM |
| 15:49.53 | SWPadnos | sorry - new religion ;) |
| 15:57.11 | IriX64 | i like the -i switch on make it comes in very handy ;) |
| 16:00.38 | IriX64 | that file is farked, but still it should not shutdown should just report an error and keep on trucking. |
| 16:06.25 | IriX64 | smoke break bbiab. |
| 17:30.37 | IriX64 | ray tracing the m35 belly up :) |
| 17:30.52 | IriX64 | on a sky blue background. |
| 19:02.27 | *** join/#brlcad IriX64 (n=IriX64@toronto-HSE-ppp4310781.sympatico.ca) | |
| 19:50.18 | *** join/#brlcad Lapo (n=kvirc@81-208-74-176.ip.fastwebnet.it) | |
| 19:50.23 | Lapo | Hi all |
| 20:19.03 | Lapo | help close |
| 20:26.58 | *** join/#brlcad Lapo (n=kvirc@81-208-74-176.ip.fastwebnet.it) | |
| 20:27.04 | Lapo | Hi all again |
| 20:28.39 | Lapo | please Can someone help me in the installation of brl-cad? |
| 20:42.50 | ``Erik | ? |
| 20:46.00 | Lapo | Hi Erik |
| 20:49.50 | Lapo | mged: error while loading shared libraries: /usr/brlcad/lib/libtermio.so.19: ELF file OS ABI invalid |
| 20:50.09 | Lapo | I got this problem |
| 20:50.35 | Lapo | Do you have an idea of what is wrong? |
| 21:08.22 | *** part/#brlcad Lapo (n=kvirc@81-208-74-176.ip.fastwebnet.it) | |
| 21:12.16 | CIA-2 | BRL-CAD: 03johnranderson * 10brlcad/src/librtserver/rtserver.c: added (int) cast to eliminate compiler warning |
| 21:27.59 | ``Erik | heh, and he bolts |
| 23:19.44 | IriX64 | that go on often? |
| 23:20.19 | IriX64 | thought so was a static lib. |
| 23:20.53 | IriX64 | ahh well too much beer :) |
| 23:27.02 | IriX64 | This better: Frame 0: 894916 rays in 1.02 secs = 880822.83 rays/sec RTFM (Read the fine manual) |
| 23:29.34 | brlcad | .so => shared object library |
| 23:29.43 | IriX64 | .la |
| 23:29.48 | brlcad | libtool archive |
| 23:29.58 | IriX64 | .a |
| 23:30.02 | brlcad | archive |
| 23:30.12 | IriX64 | static lib? |
| 23:30.23 | brlcad | yes, static library archive |
| 23:30.36 | IriX64 | hmph :) |
| 23:30.55 | IriX64 | you know way too much to be useful ;) |
| 23:31.37 | brlcad | heh, you can run gentoo on gentoo.. |
| 23:31.40 | brlcad | http://www.obsession.se/gentoo/ |
| 23:31.54 | IriX64 | any experience with vmware? |
| 23:32.41 | brlcad | yeah, good stuff |
| 23:32.56 | IriX64 | so i hear. ... might play. |
| 23:32.57 | brlcad | used to write linux kernel code in it |
| 23:33.07 | IriX64 | that advanced? |
| 23:33.08 | brlcad | makes for a great kernel dev environment |
| 23:33.33 | brlcad | reboot the system, write filesystem drivers without potentially screwing up your main system |
| 23:33.51 | brlcad | if the kernel crashes, you just restart vmware, etc |
| 23:34.06 | brlcad | all in an app instead of waiting for hardware |
| 23:35.22 | IriX64 | nice |
| 23:35.45 | IriX64 | smoke break :) |
| 23:36.34 | brlcad | you smoke a lot |
| 23:45.46 | ``Erik | hah |
| 23:45.47 | ``Erik | wow |
| 23:46.04 | ``Erik | knowing a couple lbasic and very common file extensions is 'knowing too much', that's ripe |
| 23:46.04 | ``Erik | :) |
| 23:47.18 | ``Erik | and pungent? |
| 23:47.23 | brlcad | most definitely |
| 23:48.08 | ``Erik | zo, I am tinkink about ze wdb file format, ja? |
| 23:48.23 | brlcad | "wdb file format"? |
| 23:48.26 | ``Erik | erm |
| 23:48.27 | ``Erik | for |
| 23:48.29 | ``Erik | meat balls |
| 23:48.34 | ``Erik | sveedish ones |
| 23:48.57 | brlcad | ah, you mean how to add your prim to the .g |
| 23:49.05 | ``Erik | a float (the eval value), and a set of [point&float] |
| 23:49.48 | ``Erik | point&float pairs need to be modifiable, and need to be added to the 'metaball' after the metaball is defined |
| 23:49.56 | brlcad | would include a count at the onset so a future mod or even current code can jump to the next section fwiw |
| 23:49.58 | ``Erik | is there an obvious approach? |
| 23:50.03 | ``Erik | of course |
| 23:50.07 | brlcad | ran into that problem with the nurbs prim where it didn't do that |
| 23:50.08 | ``Erik | that's a minor optimization, though |
| 23:50.15 | brlcad | making it a bltch to add trimming info |
| 23:50.30 | brlcad | (in a backwards-compatible way) |
| 23:50.58 | brlcad | what are the point/float pairs? |
| 23:51.06 | ``Erik | heh, I've already noticed cruft from maintaining backwards compatability... |
| 23:51.26 | brlcad | probably all the v4 stuff, this isn't that bad |
| 23:51.31 | ``Erik | they're the defining points |
| 23:51.54 | brlcad | the what's the initial float? |
| 23:52.23 | brlcad | the effective power no? |
| 23:52.34 | ``Erik | a set of points, each with a field strength generates the raw 'metaball', then to get the shell, you define an value and generate an isosurface... |
| 23:52.56 | ``Erik | as far as I understand |
| 23:52.57 | brlcad | ahh, the zero-crossing value to evaluate the implicit at |
| 23:53.03 | brlcad | gotcha |
| 23:53.16 | ``Erik | yeah, f(n)-q=0 where f(n) is the metaball and q is the evaluation value |
| 23:54.02 | ``Erik | <-- not sure how to interface this via brlcad's "in" cmd or how to spec a wdb friendly way to store it... |
| 23:54.31 | ``Erik | I'd imagine having the points as a linked list spread throughout the .g would be a bad thing... |
| 23:55.18 | ``Erik | <-- wanted to bug lee about this last evening |
| 23:55.24 | ``Erik | but lee was busy and I decided I wanted to go hom :) |
| 23:55.57 | ``Erik | <-- should probably annoy lee on thursday |
| 23:57.49 | brlcad | the wdb interface is just going to call the primitive's export function, librt deals with the actual i/o |
| 23:58.22 | brlcad | the export/import functions will implicitly determine how things are stored onto disk |
| 23:58.29 | brlcad | you basically serialize your data there |
| 23:58.54 | ``Erik | hm, and there is no concept of compaction or collection ? |
| 23:59.03 | brlcad | and from the database layer's perspective, you're just stashing a binary chunk of data for the primitive |
| 23:59.20 | brlcad | there is across multiple objects |
| 23:59.43 | brlcad | and individual objects can optionally manage that on their own, though I don't think any take advantage of that right now |
| 23:59.52 | ``Erik | I mean, I could save a two floats, then an array of vec4's... |
| 23:59.53 | brlcad | the BoT's are actually a good example |
