| 00:18.03 | brlcad | that's the best place to start |
| 00:18.42 | brlcad | in particular, the intro to mged and the quick reference, followed by principles of effective modeling |
| 00:19.19 | dli | brlcad, thanks |
| 04:00.51 | *** join/#brlcad digitalfredy (n=digitalf@200.71.62.161) | |
| 04:52.11 | *** join/#brlcad IriX64 (n=IriX64@toronto-HSE-ppp4303658.sympatico.ca) | |
| 04:52.34 | IriX64 | so have you adopted my_free yet? |
| 04:59.18 | brlcad | heh |
| 04:59.40 | brlcad | already have it, it's called bu_free() ;) |
| 05:04.31 | IriX64 | i said round, but thanks ;) |
| 05:25.25 | *** join/#brlcad PKMOBILE (n=Apathy@c-24-13-128-35.hsd1.il.comcast.net) | |
| 05:55.54 | *** join/#brlcad haywood_giablomi (n=John_K@c-71-56-97-21.hsd1.ga.comcast.net) | |
| 06:32.59 | CIA-9 | BRL-CAD: 03brlcad * 10brlcad/configure.ac: xosdefs.h? how about searching for X11/Xosdefs.h instead |
| 06:34.18 | CIA-9 | BRL-CAD: 03brlcad * 10brlcad/src/libdm/ (dm-X.c dm-glx.c dm-ogl.c dm-pex.c dm-tk.c): HAVE_XOSDEFS_H was a conf.h fictional, update to new configure check for HAVE_X11_XOSDEFS_H and clean up header foo some. |
| 06:43.04 | CIA-9 | BRL-CAD: 03brlcad * 10brlcad/src/libdm/dm-X.c: oops .. they are x_vars, not dm_xvars |
| 06:46.58 | *** join/#brlcad clock_ (i=clock@84-72-62-41.dclient.hispeed.ch) | |
| 08:21.15 | CIA-9 | BRL-CAD: 03brlcad * 10brlcad/BUGS: several of the max screen size values were increased or reworked, revisit bug |
| 08:27.01 | CIA-9 | BRL-CAD: 03brlcad * 10brlcad/TODO: intel compiler was tested, it's pretty sweet. still need to add the configure detection, though. also most warnings are quelled finally, time to move on to the verbose warnings soon.. |
| 08:31.02 | *** join/#brlcad clock_ (n=clock@zux221-122-143.adsl.green.ch) | |
| 08:56.14 | *** join/#brlcad clock__ (n=clock@zux221-122-143.adsl.green.ch) | |
| 09:17.44 | *** join/#brlcad clock_ (n=clock@zux221-122-143.adsl.green.ch) | |
| 12:10.08 | brlcad | hmm |
| 12:16.39 | clock_ | brlcad: hi |
| 12:20.10 | ValarQ | hello clock and mr Cad |
| 12:25.07 | brlcad | ciao ciao clock_ ValarQ |
| 12:27.24 | clock_ | brlcad: yesterday we weree waxing down our surfboards with Sex Wax :) |
| 12:54.56 | CIA-9 | BRL-CAD: 03brlcad * 10brlcad/src/mged/ged.c: disable logging for now until it can be tied to OPTIMIZED too |
| 13:04.09 | *** join/#brlcad digitalfredy (n=digitalf@200.71.62.161) | |
| 13:18.26 | *** join/#brlcad digitalfredy (n=digitalf@200.71.62.161) | |
| 13:26.59 | CIA-9 | BRL-CAD: 03brlcad * 10brlcad/BUGS: fbhelp sends some of the output to stdout and some to stderr |
| 13:28.16 | CIA-9 | BRL-CAD: 03d_rossberg * 10brlcad/misc/win32-msvc/Dll/brlcad.def: expand exported symbols list |
| 13:33.17 | *** join/#brlcad rossberg (n=rossberg@bz.bzflag.bz) | |
| 14:29.47 | *** join/#brlcad dli (n=dli@nsit-dhcp-035-180.uchicago.edu) | |
| 14:30.24 | dli | how do I select prim? |
| 14:31.00 | dli | the Edit menu entry is gray, and the command " draw <obj>" does nothing |
| 14:39.45 | *** join/#brlcad SWPadnos (n=Me@dsl245.esjtvtli.sover.net) | |
| 15:14.14 | brlcad | dli: you have to specify what geometry you want it to draw |
| 15:14.49 | brlcad | then when you've drawn/loaded geometry, you can specify a selection for edit or other operation |
| 15:15.30 | brlcad | dli: the n00b docs cover this in one of the first lessons too fwiw ;) |
| 15:16.56 | brlcad | in short .. you can 1) run the geometry browser and use it to display geometry or 2) use tops, get a list of objects, run "e some_object" to display that object, use Edit menu or sed 'some_oject' to edit a primitve |
| 15:17.14 | brlcad | just two of several ways to do that as well |
| 15:21.22 | dli | brlcad, thanks |
| 15:24.36 | dli | brlcad, the 2nd way, in Edit menu, the "Prim Selection" is gray, " sed " gives Error: Unable to do <keyboard solid edit start> from SOL EDIT state. |
| 15:30.59 | brlcad | dli: oh, it sounds like you're already in solid edit mode on some object? is there a reject/apply/accept option? |
| 15:32.11 | dli | brlcad, got it, after rejection, it works now |
| 15:32.34 | brlcad | yeah, helps to not be in edit mode ;) |
| 15:32.46 | brlcad | hooray for modality errors |
| 15:33.57 | dli | brlcad, can I get 2D drawing finally? the classical ones, with dimensions |
| 15:34.31 | dli | brlcad, I can see there are Front/Top/Side views, but I don't see a way to get dimensions on them |
| 15:36.20 | ``Erik | heh, 'draft' mode seems to be getting a lot of requests o.O :) |
| 15:36.25 | clock_ | dli: no support yet |
| 15:37.09 | dli | clock_, then, I have to work with bugs of qcad |
| 15:49.04 | clock_ | dli: I have to work with bugs of qcad too |
| 15:49.14 | clock_ | dli: especially the one that it cannot be compiled on OpenBSD ;-) |
| 15:51.58 | dli | clock_, it compiles :( but it has serious font problem, also, dashed ellipse shown as solid lines, it can not trim ellipse arc |
| 15:53.19 | clock_ | dli: how did you compile it? |
| 15:53.23 | clock_ | What version are you using? |
| 15:54.04 | dli | clock_, 2.0.4.0-r1 in gentoo |
| 15:54.15 | clock_ | dli: ah Gentoo I said on OpenBSD |
| 15:54.33 | dli | clock_, I mean it compiles here :( |
| 16:16.04 | *** join/#brlcad IriX64 (n=mario_du@toronto-HSE-ppp4303658.sympatico.ca) | |
| 16:51.25 | CIA-9 | BRL-CAD: 03erikgreenwald * 10brlcad/src/librt/g_metaball.c: minor clean, and changed some logic in shot to fix a memory leak. |
| 16:54.09 | *** part/#brlcad IriX64 (n=mario_du@toronto-HSE-ppp4303658.sympatico.ca) | |
| 16:54.44 | *** join/#brlcad IriX64 (n=IriX64@toronto-HSE-ppp4303658.sympatico.ca) | |
| 17:17.50 | *** join/#brlcad IriX64 (n=IriX64@toronto-HSE-ppp4303658.sympatico.ca) | |
| 17:27.59 | *** join/#brlcad IriX64 (n=Who@toronto-HSE-ppp4303658.sympatico.ca) | |
| 17:38.14 | *** join/#brlcad DTRemenak (n=DTRemena@c-24-23-59-104.hsd1.ca.comcast.net) | |
| 17:52.26 | brlcad | ahh, ``Erik found it? |
| 17:54.01 | ``Erik | yeah |
| 17:54.26 | ``Erik | some fishy logic had an RT_GET_SEG that never got to a BU_LIST_INSERT |
| 17:56.20 | ``Erik | <-- special |
| 17:58.52 | ``Erik | msot of this morning was getting a fresh debug version on a single proc machine, heh :) |
| 18:05.06 | brlcad | so, compiling on your O2 again,eh? :) |
| 18:06.53 | ``Erik | hah, no, the 1.8ghz fbsd thingie |
| 18:06.55 | ``Erik | my mp3 player |
| 19:12.52 | *** join/#brlcad dli (n=dli@nsit-dhcp-035-180.uchicago.edu) | |
| 19:43.33 | ``Erik | 10293 vgr's, not too shabby |
| 19:45.24 | brlcad | not too shabby |
| 19:49.25 | brlcad | that's optimized I hope? |
| 19:49.42 | brlcad | curious how well --disable-runtime-debug improves that score |
| 19:49.46 | ``Erik | um, yeah, but still with debugging |
| 19:50.07 | brlcad | debugging isn't really much but cache coherency related, maybe 1-2% at best |
| 19:50.17 | brlcad | running strip and you have the same |
| 19:50.32 | ``Erik | yeah |
| 19:50.44 | ``Erik | bah, you bastard |
| 19:50.46 | brlcad | --disable-runtime-debug, however, is completely different |
| 19:50.59 | ``Erik | $ sh autogen.sh |
| 19:50.59 | ``Erik | INTERNAL ERROR: dirname/basename inconsistency: autogen.sh != ./autogen.sh |
| 19:51.04 | brlcad | it disabled the plethora of run-time validity checks that just bomb |
| 19:51.09 | brlcad | heh |
| 19:51.52 | brlcad | comment it out |
| 19:52.01 | brlcad | or fix it :) |
| 19:52.21 | ``Erik | meh, I ran it as ./autogen.sh |
| 19:54.47 | brlcad | yep, that's denoted in the BUGS file .. noticed that over a year ago |
| 19:55.19 | brlcad | no biggie, you can run it installed from anywhere and just point RT to the one just compiled |
| 19:55.29 | brlcad | RT=path/to/RT benchmark |
| 19:56.11 | brlcad | or even: RT=path/to/rt make benchmark |
| 19:58.14 | brlcad | interesting.. "dirname autogen.sh" reports "." |
| 19:59.14 | brlcad | heh, sh ./autogen.sh would have worked too |
| 20:04.53 | CIA-9 | BRL-CAD: 03brlcad * 10brlcad/autogen.sh: if autogen.sh exists, consider it good enough. otherwise then print error cruftage. |
| 20:09.44 | ``Erik | 11555 vgr's |
| 20:10.44 | ``Erik | like 12.2% gain |
| 20:13.17 | *** join/#brlcad clock_ (i=clock@84-72-61-250.dclient.hispeed.ch) | |
| 20:22.56 | dtidrow_work | 11555 - nice :-) |
| 20:27.30 | dtidrow_work | best I've gotten on this box is 2335 |
| 20:29.35 | brlcad | dtidrow_work: did you try --disable-runtime-deubg ? |
| 20:30.43 | dtidrow_work | nope, wasn't aware of it |
| 20:30.50 | dtidrow_work | just did 'make benchmark' |
| 20:31.24 | dtidrow_work | '--disable-runtime-deubg' - is that a configure option? |
| 20:48.03 | brlcad | ahhh |
| 20:48.15 | brlcad | yes, it's a configure option |
| 20:48.28 | CIA-9 | BRL-CAD: 03brlcad * 10brlcad/configure.ac: check for the sys/prctl.h header .. it declares sproc() |
| 20:48.30 | brlcad | helps to not repeat my typo too :) .. "debug" |
| 20:49.04 | brlcad | ./configure --enable-optimized --disable-debug --disable-runtime-debug should give a fairly optimal run-time result |
| 20:49.47 | dtidrow_work | heh - back in 40min then ;-) |
| 20:51.13 | brlcad | after a make clean of course to clear out the proevious build |
| 20:51.25 | dtidrow_work | yep - compiling now |
| 20:51.32 | brlcad | that should pretty much double your performance unless the previous was already --enable-optimized |
| 20:51.46 | dtidrow_work | which it was |
| 20:52.02 | dtidrow_work | that boosted it from ~1700 to 2335 |
| 20:52.04 | brlcad | so then you might get anywhere from 10-30% from disabling run-time debug |
| 20:52.18 | brlcad | surprisingly low boost actually |
| 20:52.37 | dtidrow_work | this is a 4-year-old box :-\ |
| 20:52.41 | brlcad | commodity platform? |
| 20:52.53 | dtidrow_work | Dell 670 from '02 |
| 20:53.04 | dtidrow_work | 530, rather |
| 20:53.19 | brlcad | implies either the compiler is doing a pretty good job optimizing at -O0 or is doing a horrible job at -O3 |
| 20:53.22 | dtidrow_work | dual 2GHz Xeons with HT turned on |
| 20:53.47 | brlcad | or a little bit of both probably more likely |
| 20:53.48 | dtidrow_work | running FC4 |
| 20:54.25 | dtidrow_work | gcc 4.0.2 |
| 20:55.24 | ``Erik | <PROTECTED> |
| 21:14.53 | dtidrow_work | brlcad: getting an error in the compilation, though it seems weird |
| 21:14.57 | dtidrow_work | make[1]: Entering directory `/home/dtidrow/src/brlcad-7.8.2/pix' |
| 21:14.57 | dtidrow_work | make[1]: *** No rule to make target `bldg391.pix', needed by `all-am'. Stop. |
| 21:14.57 | dtidrow_work | make[1]: Leaving directory `/home/dtidrow/src/brlcad-7.8.2/pix' |
| 21:15.16 | dtidrow_work | why would it be making stuff in the 'pix' dir? |
| 21:19.10 | brlcad | hrm, that is odd |
| 21:19.52 | brlcad | sounds like file(s) have been deleted |
| 21:20.07 | dtidrow_work | yeah, something got screwed |
| 21:20.10 | brlcad | ooh |
| 21:20.25 | brlcad | you said you did make benchmark? |
| 21:20.29 | dtidrow_work | yeah |
| 21:20.43 | brlcad | did you also run configure with --enable-only-benchmark? |
| 21:20.49 | dtidrow_work | nope |
| 21:20.52 | brlcad | hrmph |
| 21:21.06 | brlcad | is that pix file in the pix/ dir? |
| 21:21.24 | dtidrow_work | don't see it there |
| 21:21.37 | dtidrow_work | wait a minute, let me check again |
| 21:22.16 | dtidrow_work | there's a "bldg391.pix.22980" |
| 21:22.41 | brlcad | ahh, sounds like you maybe deleted the reference images at some point |
| 21:22.44 | dtidrow_work | looks like a process-id added onto the end, like from a previous benchmark run |
| 21:22.52 | dtidrow_work | hmmm |
| 21:23.09 | dtidrow_work | maybe I should just nuke the whole thing and start fresh from the tarball |
| 21:23.20 | brlcad | when you run benchmark, it dumps out a lot of pix files, backing up existing as .PID files |
| 21:24.29 | brlcad | yeah, starting fresh is probably best |
| 21:25.11 | dtidrow_work | easy enough |
| 21:27.32 | *** join/#brlcad IriX64 (n=Who@toronto-HSE-ppp4303658.sympatico.ca) | |
| 21:28.05 | CIA-9 | BRL-CAD: 03brlcad * 10brlcad/src/canon/canon.h: use the newly added HAVE_SYS_PRCTL_H so we can check whether PR_SALL and PR_SFDS are provided by the sproc interface for working with dslib. |
| 21:31.10 | CIA-9 | BRL-CAD: 03brlcad * 10brlcad/src/canon/ (canonlib.c ipuscan.c ipustat.c pix-ipu.c png-ipu.c): header cleanup |
| 21:31.23 | brlcad | dtidrow_work: do you happen to have any experience with mosix? |
| 21:31.39 | dtidrow_work | nope, what is it? |
| 21:31.54 | brlcad | it's a cluster operating system |
| 21:32.16 | brlcad | provides virtual shared memory, automatic process migration among nodes, load balancing, etc |
| 21:32.18 | dtidrow_work | ah, that's why it sounds vaguely familiar |
| 21:32.35 | IriX64 | obviously not a vax cluster. :) |
| 21:32.38 | brlcad | SMP style, not the distributed independent MPI/PVM style |
| 21:34.19 | IriX64 | Qnix? |
| 21:34.23 | IriX64 | :) |
| 21:34.45 | IriX64 | your comeback should be *nix ;) |
| 21:44.01 | IriX64 | would pay for a screen shot of your system brlcad, if thats what you're running. |
| 21:52.20 | CIA-9 | BRL-CAD: 03brlcad * 10brlcad/src/librt/tree.c: quell 64bit warning |
| 21:56.07 | dtidrow_work | I'd love to see what the benchmark on this monster comes out as: http://www.boxxtech.com/products/apexx8.asp |
| 21:58.16 | brlcad | ooh, sweet hardware |
| 21:58.59 | dtidrow_work | indeed :-) |
| 21:59.17 | dtidrow_work | think they had a demo system of that @SIGGRAPH |
| 21:59.18 | brlcad | I'd bet/hope something on the order of 30k vgr if not better |
| 21:59.33 | dtidrow_work | I never did get a good look in that booth |
| 21:59.35 | brlcad | rough quote? |
| 21:59.50 | dtidrow_work | guessing around $30k |
| 22:01.16 | dtidrow_work | k, the latest bench run came out at 2556 |
| 22:01.42 | brlcad | hm, so about 10% too |
| 22:01.55 | dtidrow_work | something like that |
| 22:02.13 | dtidrow_work | I just need a new box ;-) |
| 22:02.34 | dtidrow_work | the rambus memory probably isn't helping, either |
| 22:03.00 | brlcad | seems reasonable.. the higher end 30% numbers are mostly on much older hardware, especially systems like irix 5 that can get branch predictions wrong a lot |
| 22:04.03 | brlcad | nice to see almost every test more than a million rays/sec :) |
| 22:04.04 | dtidrow_work | which altix system? |
| 22:04.11 | brlcad | it's a 12 node |
| 22:04.19 | dtidrow_work | nice |
| 22:04.29 | brlcad | 1.4 |
| 22:04.40 | dtidrow_work | too bad it's from S_I |
| 22:11.00 | brlcad | 13574 vgr |
| 22:13.26 | ``Erik | that the 12 or the 16? |
| 22:13.58 | brlcad | the 12 |
| 22:14.17 | ``Erik | 1131 vgr's per core, opposed to the amd64's 2889 vgrs per core :) |
| 22:14.25 | brlcad | yup |
| 22:14.29 | ``Erik | *stomp* hehehe |
| 22:14.46 | brlcad | considerably more spensive too.. though way better on I/O |
| 22:14.56 | ``Erik | *nod* |
| 22:15.21 | ``Erik | if the amd had the same class of disk, it'd be smokin' too, though |
| 22:17.46 | brlcad | not just disk, their cray interconnect stuff is just nice |
| 22:18.06 | brlcad | i think that more than anything is what gets the compile down so fast |
| 22:18.56 | brlcad | mind you that vgr is also on a machine that is probably about 3-4 years old, cluster is at least 6-12 months newer |
| 22:19.30 | brlcad | i mean, the new macbooks are almost 5k .. |
| 22:20.21 | brlcad | that puts one single xserve in the ballpark of that altix |
| 22:20.31 | brlcad | and the cluster |
| 22:21.46 | brlcad | that boxx apex system is sweet though.. if the specs match up, that really could be as much as 20-30k vgrs |
| 22:22.11 | IriX64 | you people are spoled rotten :) |
| 22:22.24 | IriX64 | spoiled too. |
| 22:22.35 | dtidrow_work | what's the new 'vgr'? |
| 22:22.47 | brlcad | though at $30k, you'd get more bang per buck with 8 xserves.. should be about 80k vgrs |
| 22:22.47 | dtidrow_work | is that the altix? |
| 22:23.12 | dtidrow_work | that $30k was just a guess |
| 22:23.13 | brlcad | no no.. vgr baseline is unchanged |
| 22:23.16 | IriX64 | reguts.c line 58 NDEBUG redefined guys. |
| 22:23.29 | dtidrow_work | still the ancient VAX? |
| 22:23.42 | brlcad | IriX64: there is no reguts.c |
| 22:23.50 | IriX64 | eh? |
| 22:24.05 | IriX64 | my mistake :( |
| 22:24.18 | IriX64 | must be mine. |
| 22:24.27 | IriX64 | it is. |
| 22:24.36 | brlcad | dtidrow_work: the physical hardware for VGR was decommissioned about 5 years ago iirc, but we still have the performance metrics |
| 22:24.57 | dtidrow_work | that's what I thought |
| 22:25.06 | brlcad | i've been looking at using vax running in simh to keep it maintainable indefinitely |
| 22:25.39 | brlcad | i set up the vax in there and got netbsd installed with not too much hassle, few source edits, some kernel trickery to get data in the machine |
| 22:25.41 | dtidrow_work | Chris Johnson was messing around with that at one time |
| 22:25.54 | brlcad | yeah, we were talking about that a year or two ago |
| 22:26.42 | brlcad | wouldn't take too much work (one would imagine) to throttle simh so that it consistently computes an exact 1.0 vgr |
| 22:26.49 | IriX64 | regguts.h sorry. |
| 22:27.02 | ``Erik | heh |
| 22:27.08 | brlcad | IriX64: that's tcl, not our code |
| 22:27.33 | brlcad | any warnings in src/other are "not our problem" |
| 22:27.42 | IriX64 | never mind its legit i disable debug and symbols. |
| 22:27.47 | ``Erik | but netbsd instead of bsd4.3? you're not afraid of library differences or kernel differences skewing things? :) |
| 22:27.48 | brlcad | I only care fix code in there if it fails |
| 22:27.50 | IriX64 | disabled too. |
| 22:28.05 | ``Erik | or are you gonna try to redefine the vgr o.O |
| 22:28.15 | brlcad | you have a copy of 4.3 lying around? :) |
| 22:28.23 | ``Erik | I bet kermit has the tapes |
| 22:28.24 | brlcad | i would have gone for anything |
| 22:28.30 | brlcad | but open crapped on it |
| 22:28.38 | brlcad | and wasn't even going to attempt free |
| 22:28.48 | ``Erik | old fbsd might've |
| 22:28.50 | brlcad | net was seamless |
| 22:29.19 | ``Erik | be interesting seeing how many vgr's a vgr class machine gets with a different(ish) os |
| 22:29.23 | dtidrow_work | http://www.creativemac.com/articles/viewarticle.jsp?id=39966 - says that a maxed one would be around $80k |
| 22:29.23 | brlcad | yeah, maybe old, but net was clean and very simple |
| 22:29.31 | brlcad | eek |
| 22:29.58 | dtidrow_work | likely fully loaded with memory and disks |
| 22:30.26 | dtidrow_work | which means 128GB RAM and 7-10TB of disk |
| 22:30.26 | brlcad | that's like 16 xserves loaded .. different architecture of course, but if the vgr count was primae fascia importance.. |
| 22:30.40 | dtidrow_work | and one system image |
| 22:30.41 | brlcad | makes for a beautiful deskside SMP station, though, gotta admit |
| 22:31.11 | dtidrow_work | the new BFM9000 ;-) |
| 22:31.25 | brlcad | pretty much :) |
| 22:32.05 | dtidrow_work | brlcad: when did you start up there at ARL? |
| 22:32.11 | brlcad | if I had the new cad website up with the benchmark database.. I'd certainly be working on getting simh going with some stable setup |
| 22:32.28 | brlcad | dtidrow_work: about 7 years ago |
| 22:32.30 | brlcad | thereabouts |
| 22:32.38 | dtidrow_work | did you ever make it down to NVL? |
| 22:32.44 | brlcad | NO! |
| 22:32.47 | brlcad | i wish i had |
| 22:32.48 | dtidrow_work | heh |
| 22:33.33 | brlcad | that's a connection that unfortunately was lost with the loss oD[D[D[D[D[D[D[D[D[Df m.m. |
| 22:33.43 | brlcad | er, that was wierd |
| 22:34.11 | dtidrow_work | glitch in the matrix? ;-) |
| 22:34.20 | brlcad | i think so |
| 22:34.35 | dtidrow_work | lol |
| 22:34.39 | ``Erik | mr anderson... |
| 22:35.14 | brlcad | so.. ``Erik .. the freebsd ports thing |
| 22:35.29 | ``Erik | um, hrm? |
| 22:35.41 | brlcad | assuming it's all worky worky now for using a system tcl/tk |
| 22:35.49 | ``Erik | no |
| 22:36.01 | brlcad | i'm playing with the idea of having multiple independent projects |
| 22:36.14 | ``Erik | when it starts up, it look for tcl paths and only gets the brlcad/crap path, since it only search for one path |
| 22:36.23 | ``Erik | or, it did last I looked |
| 22:36.31 | brlcad | yeah, I mean aside from that.. still have to fix that ;) |
| 22:36.53 | ``Erik | well, asking it to use the system tcl and tk si trivial, I've tried it a few times |
| 22:36.59 | ``Erik | but until that is fixed, it's unusable |
| 22:37.17 | brlcad | how much work you think it'll be to support having multiple ports packages as well as the main kitchen sink one? |
| 22:37.24 | ``Erik | uh |
| 22:37.29 | ``Erik | why would it be multiple ports packages? |
| 22:37.44 | brlcad | 18:36 <@brlcad> i'm playing with the idea of having multiple independent projects |
| 22:37.57 | ``Erik | ah, heh |
| 22:37.57 | brlcad | so that if I only wanted some piece.. i could install just that |
| 22:37.59 | ``Erik | well |
| 22:38.01 | brlcad | e.g. libpkg |
| 22:38.06 | brlcad | or the raytrace library |
| 22:38.10 | brlcad | or just mged |
| 22:38.13 | brlcad | or just the converters, etc |
| 22:38.27 | ``Erik | um, if it's broken into like 30 projects, that would be difficult to get flying with the comitters and core |
| 22:38.28 | brlcad | (see doc/PROJECTS for what'd probably be the list) |
| 22:38.39 | brlcad | more like 10 |
| 22:39.01 | brlcad | howso? I've seen other ports that are broken up that way |
| 22:39.10 | ``Erik | into 2 or 3 |
| 22:39.13 | brlcad | especially the big ones, gtk is a prime example |
| 22:39.15 | ``Erik | ... |
| 22:39.27 | ``Erik | heh, gtk is broken into gtk and glib |
| 22:39.29 | ``Erik | ... |
| 22:39.43 | ``Erik | and lots of other programs started using glib without gdk and gtk, so it was broken up |
| 22:39.55 | brlcad | it works, though |
| 22:40.06 | brlcad | there are several projects in brl-cad that really stand on their own |
| 22:40.23 | brlcad | some are already in ports as a separate project even :) (ttcp) |
| 22:40.53 | ``Erik | yeah, ttcp, jove, ... |
| 22:41.14 | ``Erik | if you do it, I could try to create a bunch of ports and see if they fly |
| 22:41.31 | brlcad | we don't "own" jove, but we technically do ttcp even if there are "patched versions" out there now that have more features |
| 22:41.45 | ``Erik | heh |
| 22:41.50 | ``Erik | about as much as we own ping... |
| 22:41.57 | brlcad | i'm just wondering how much trouble it'd be |
| 22:42.06 | brlcad | nah, ttcp hasn't changed nearly as much as ping has ;) |
| 22:42.23 | ``Erik | a day or so of work to get the ports built and stuff, then antoher week or so to get 'em reviewed and committed, I'd imagine |
| 22:42.30 | ``Erik | ping is a little more used than ttcp |
| 22:42.32 | brlcad | i looked into bringing in his original ping source as a utility |
| 22:43.06 | brlcad | would have too, cept he initially wrote the sockets using privileged socket options |
| 22:43.12 | brlcad | so you have to run it as root :) |
| 22:43.33 | ``Erik | heh |
| 22:44.03 | brlcad | was tempting, though.. I could actually use that in the new modeler as a plugin had it not |
| 22:47.00 | IriX64 | heh ;) |
| 22:48.16 | IriX64 | #ifdef #ifndef whats an n more or less :) |
| 22:54.38 | IriX64 | while((ptr=strchr(string,'\0x0d')));ptr+1=0x00; |
| 22:54.48 | IriX64 | whats wrong with that? |
| 22:55.28 | brlcad | heh, this is right up your alley ``Erik: http://www.hermann-uwe.de/files/images/programmer_hierarchy.png |
| 22:57.21 | IriX64 | brlcad:should rename to required education for any programmer. :) |
| 22:57.58 | IriX64 | ahrrrgggghhhh *ptr+1 |
| 22:58.15 | IriX64 | *(ptr+1) |
| 23:00.13 | brlcad | hm .. depends entirely on the intent, no? :) |
| 23:00.22 | IriX64 | yah. :) |
| 23:00.55 | IriX64 | intent is to null terminated a bunch of non nullterminated strings. |
| 23:01.14 | IriX64 | but the do have 0d oa in them. |
| 23:01.21 | IriX64 | 0a too |
| 23:02.25 | *** join/#brlcad Twingy (n=justin@c-69-250-236-111.hsd1.md.comcast.net) | |
| 23:12.44 | b0ef | brlcad: it's really great to break up the project like that;) |
| 23:14.26 | Twingy | Smoking is bad for your lungs. |
| 23:14.49 | b0ef | , but it sure is good |
| 23:16.20 | Twingy | it's a waste of time |
| 23:16.33 | IriX64 | thats why i do it ;) |
| 23:16.52 | Twingy | are you religious? |
| 23:16.57 | b0ef | Twingy: so you claim |
| 23:17.04 | IriX64 | yes the one true religion. |
| 23:17.08 | brlcad | beer? |
| 23:17.16 | IriX64 | beleiving. |
| 23:17.33 | IriX64 | catholicism the rest just ways of beiliving. |
| 23:17.50 | brlcad | i've seen it, even tasted |
| 23:17.52 | IriX64 | thats a cult :) |
| 23:19.03 | IriX64 | twingy is suppsed to do cpr. |
| 23:19.09 | IriX64 | supposed too. |
| 23:19.19 | brlcad | i don't think that'd be a good idea :) |
| 23:19.34 | IriX64 | leave me dead would you ? |
| 23:19.40 | IriX64 | medi |
| 23:19.44 | IriX64 | medic too. |
| 23:21.12 | IriX64 | better a hippie than a yuppie don't you think? |
| 23:22.09 | brlcad | hey Twingy.. you know of a good means to compute an OBB that's aligned with the view frustum? |
| 23:22.25 | brlcad | (of implicit prims, not just polys) |
| 23:22.33 | Twingy | isn't that an oxymoron? |
| 23:22.56 | brlcad | er, not afaik |
| 23:23.09 | Twingy | is the OBB AA? |
| 23:23.27 | brlcad | it'd be an aabb if I consider the view frustum as creating some global coordinate system i suppose |
| 23:24.03 | brlcad | but even then.. i have that transformation, and not clear how to make a nice tight fitting bb |
| 23:24.29 | brlcad | end result that I'm trying to get is a rect on pixel image where an object possibly intersects |
| 23:24.31 | Twingy | you have an arbitrary view and a frustum that goes with it |
| 23:25.02 | IriX64 | do pixel math :) |
| 23:25.04 | brlcad | s/intersects/exists or is otherwise going to get rendered for some rays) |
| 23:25.40 | Twingy | what is the OBB encapsulating? |
| 23:26.36 | brlcad | i got a torus being looked at 35 25 or something, going to render 512x512.. want to know which ray-pixels are definitely NOT possibly intersecting the torus |
| 23:26.54 | brlcad | idea was to create an obb aligned with the view to get that box |
| 23:27.22 | Twingy | a scene graph would be able to tell you that with the same amount of instructions as your proposed algorithm would |
| 23:28.09 | Twingy | but given how coupled everything is to BSP's... |
| 23:28.32 | brlcad | okay, but even the scene graph would be testing rays against planes or aabbs or obb's or some other bvh |
| 23:29.00 | Twingy | they would be, but the number of instructions is like in the tens, just ask alexis |
| 23:29.01 | brlcad | i don't really want to test rays (yet) |
| 23:29.43 | Twingy | the cross products alone will eat up that many instructions |
| 23:30.15 | brlcad | still.. you say walk the scene graph which is all good.. but a scene graph of what? just a bsp? |
| 23:30.37 | IriX64 | Twingy: not if you encapsulate the algorithm in a repetitive loop with a way out. |
| 23:30.50 | Twingy | a graph of nodes with pointers to neighbors like alexis has, I'm not sure how detailed I can get without his permission though |
| 23:31.11 | Twingy | it becomes a breshenham stepping problem |
| 23:31.21 | brlcad | so he's using aabbs basically |
| 23:31.26 | Twingy | yes, exactly |
| 23:31.31 | brlcad | or at least you're suggesting using aabbs |
| 23:31.31 | Twingy | but not a tree |
| 23:31.49 | Twingy | yea, if aabb's get used as a tree like I did in adrt then it's already non-optimal |
| 23:31.49 | brlcad | sure |
| 23:32.16 | brlcad | basically a variant of grid traversal |
| 23:32.21 | Twingy | exactly |
| 23:32.29 | brlcad | ingo actually talked a fair bit about his work on that this past year.. |
| 23:32.31 | Twingy | but not in any research papers |
| 23:32.36 | Twingy | atleast as of yet afaik |
| 23:32.49 | Twingy | ah, so he's catching up to alexis's work then :) |
| 23:32.54 | brlcad | perhaps |
| 23:33.09 | brlcad | you'll have to take a look at the course video |
| 23:33.36 | Twingy | ok, but getting back to reality |
| 23:33.42 | brlcad | still wasn't close to russian dude's first-hit tracer |
| 23:33.46 | Twingy | implementing a scene graph is not practical right now |
| 23:33.59 | Twingy | reschetov's is clever, but still not entirely optimal |
| 23:33.59 | brlcad | but then nobody is still |
| 23:34.35 | brlcad | not practical, howso? |
| 23:34.45 | Twingy | I think he's trying to use kd-tree's in ways that no longer make them kd-tree's... |
| 23:35.14 | Twingy | it's not a textbook tree if you have leaf nodes pointing to other leaf nodes |
| 23:35.44 | brlcad | it's just an inbred tree ;) |
| 23:35.45 | Twingy | it's closer to a scene graph than anything |
| 23:36.05 | Twingy | I think reschetov will be the first to call it a scene graph |
| 23:36.19 | Twingy | but ingo might too, anybody's guess |
| 23:36.58 | Twingy | so back to the torus |
| 23:37.15 | brlcad | getting back to my problem, though.. at least one of my many problems.. say I wanted to draw a box, light up the pixels, around some rendered object |
| 23:37.24 | Twingy | you're doing 2 matrix multiplies right now I take it? |
| 23:37.51 | Twingy | what if you steal some rasterization codes |
| 23:37.59 | brlcad | right now, nothing.. i'm trying to sort out what I need to implement |
| 23:38.02 | Twingy | reasterize the torus |
| 23:38.05 | Twingy | *rasterize |
| 23:38.14 | brlcad | that's the trick though, without rendering the box contents |
| 23:38.23 | brlcad | otherwise it's just trivial pixel walking |
| 23:38.25 | Twingy | but rasterization is cheap |
| 23:38.52 | Twingy | ok, don't rasterize |
| 23:38.54 | brlcad | not in this particular usage.. i just want to know a basic projection box around the object |
| 23:38.59 | Twingy | nod |
| 23:39.21 | brlcad | i can take the bounding sphere and quickly compute a bounding box around that.. but that's rarely going to be tight fitting |
| 23:40.11 | Twingy | so are you going to do ray/box testing? |
| 23:40.27 | brlcad | i was hoping to avoid any ray testing, but if necessary sure |
| 23:40.40 | dtidrow_work | brlcad: what are you trying to do again? |
| 23:40.42 | brlcad | it seems just conceptually that I should be able to compute that box |
| 23:40.48 | brlcad | directly |
| 23:41.28 | brlcad | dtidrow_work: determine a bounding square on a rendered image around some given object in 3-space |
| 23:41.33 | Twingy | that box is already a function in each primitive |
| 23:41.51 | brlcad | so if I rendered a tank, for example, this would be the tightest fitting square outline in the image if I were to crop the image |
| 23:42.05 | brlcad | the box is aligned to global coordinates in each prim |
| 23:42.10 | brlcad | not the view |
| 23:42.25 | brlcad | I could do the same projection like for the sphere, but that'll also not be tight fitting |
| 23:42.42 | Twingy | is this just to speed up rendering images with empty pixels or in general, like in a forest |
| 23:43.00 | brlcad | which is why I was thinking of how to compute an obb directly on some given prim, and provide an orientation that was aligned with the view |
| 23:43.39 | brlcad | neither and both really.. it's for an idea I have for fast csg evaluation |
| 23:43.46 | Twingy | that box is a function of the projection matrix AND modelview matrix |
| 23:44.09 | Twingy | if we're talking opengl lingo |
| 23:44.27 | brlcad | it's an idea that would effectively make boolweave and the bsp traversal go away in librt potentially |
| 23:44.44 | brlcad | or at least get computed in a radically different manner |
| 23:45.30 | Twingy | is the box you're getting aligned with the view? horizontal and vertical lines |
| 23:45.31 | brlcad | yeah, it is .. so how do I go from those two matrices to that projection? |
| 23:45.42 | brlcad | yeah, purely horizontal and vertical |
| 23:46.01 | Twingy | oh, I know |
| 23:46.05 | brlcad | basically I want to categorize pixels bunches sort of into the postage stamp sections |
| 23:46.21 | Twingy | the mesa source code has the GLU Project utility |
| 23:46.22 | brlcad | where know this square of pixels needs to be tested |
| 23:46.44 | Twingy | take the 8 projected points of the box, min max them |
| 23:46.45 | Twingy | done |
| 23:46.46 | brlcad | against some primitive |
| 23:46.58 | Twingy | you already have a bounding box for the primitive |
| 23:47.13 | brlcad | that's what i meant though.. that's projecting the aabb onto the view |
| 23:47.16 | brlcad | it's not tight fitting |
| 23:47.18 | Twingy | so you project the 8 points (might be an optimization in there to do less) and grab the min max |
| 23:47.40 | Twingy | oh, the aabb |
| 23:47.47 | Twingy | well, you could always add a new type of box |
| 23:48.00 | Twingy | that is the aabb * transformation matrix |
| 23:48.14 | Twingy | err some function of that |
| 23:48.20 | Twingy | 6 floats... |
| 23:48.28 | brlcad | which would be a function that effectively computes an obb :) |
| 23:48.46 | brlcad | which i don't see how to directly evaluate on a given implicit :) |
| 23:48.50 | Twingy | yea, but I just listed the puzzle pieces |
| 23:48.57 | Twingy | well the code will simplify |
| 23:49.35 | Twingy | I know that with the projection code from mesa, transformation matrix for the primitive, and perhaps an extra 6 floats in each primitive I could hash something out then optimize it |
| 23:49.42 | Twingy | atleast that is what my approach would be |
| 23:49.53 | brlcad | hm |
| 23:50.02 | brlcad | i'll take a look there then |
| 23:50.24 | Twingy | I ripped the mesa projection code and put it in nurbana for selecting control points on a mesh |
| 23:50.42 | Twingy | the code documents are in french I think |
| 23:50.50 | Twingy | but it's easy to follow |
| 23:51.03 | brlcad | heh |
| 23:52.52 | Twingy | http://js.cx/~justin/ProjectUtility.cpp |
| 23:53.50 | Twingy | you want UnProject |
| 23:54.17 | Twingy | all the way at the bottom |
| 23:55.48 | Twingy | the trick will be finding the optimizations after you merge it into the other code to project the 8 pts |
| 23:56.13 | Twingy | my gut feeling is you can simplify alot of that cruft |
| 23:56.18 | brlcad | hm |
| 23:56.39 | Twingy | output of UnProject is x,y screen coordinate |
| 23:56.44 | brlcad | i think i follow, but still don't have a good way to determine those 8 points |
| 23:56.57 | brlcad | in model space |
| 23:57.04 | Twingy | before the primitive gets a transformation applied to it |
| 23:57.15 | Twingy | it's AABB is tight fitting no? |
| 23:57.25 | brlcad | yeah, should be |
| 23:57.27 | brlcad | ahhh |
| 23:57.35 | brlcad | so it's rotating |
| 23:57.37 | Twingy | k, stargate time |
| 23:58.11 | brlcad | calculating the box using the aabb, then unprojecting those points back up through the modelview and projection matrix |
| 23:58.14 | brlcad | coolness |
| 23:58.20 | brlcad | thanks, that might just work! :) |
| 23:58.44 | brlcad | mm.. stargate.. yay for dvr.. but time to go home :) |
