| 00:07.45 | CIA-5 | BRL-CAD: 03brlcad * 10brlcad/include/bu.h: export bu_argv0 |
| 00:15.29 | IriX64 | http://pastebin.com/884885 <===== for the record regressed back to distributed configure.ac and automake-1.9.6 |
| 00:16.16 | louipc | IriX64: try using the latest CVS it should work now |
| 00:16.31 | louipc | with automake 1.10 |
| 00:16.36 | IriX64 | don't do CVS ;) |
| 00:16.46 | IriX64 | btw its installing fine too. |
| 00:17.48 | louipc | man pastebin is lagging |
| 00:17.59 | IriX64 | noticed that. |
| 00:18.41 | IriX64 | errr did you say it *works with 1.10? |
| 00:18.51 | louipc | yes |
| 00:18.59 | brlcad | ~pastebin |
| 00:19.00 | ibot | from memory, pastebin is a place to paste your stuff without flooding the channel - try http://pastebin.ca, or http://channels.debian.net/paste, or http://rafb.net/paste/, or http://pastebin.com is usually painfully too slow and unresponsive to use, use one of the other pastebin sites |
| 00:19.02 | IriX64 | the make install part too? |
| 00:20.04 | IriX64 | louipc? |
| 00:20.06 | louipc | yeah it was a problem with an empty variable because automake decided to name it with all caps out of the blue |
| 00:20.40 | louipc | you just need autogen.sh and m4/mkdirp.m4 |
| 00:20.43 | brlcad | why it didn't work when you removed our mkdirp.m4 is still a mystery, but whatever it works |
| 00:21.25 | IriX64 | ty |
| 00:21.46 | IriX64 | takes a good man ;) |
| 00:22.42 | brlcad | to do an evil deed? |
| 00:22.44 | IriX64 | now to play with it, I'll be seriously neglecting the window for a while :) |
| 00:23.05 | IriX64 | s /this/the |
| 00:23.57 | IriX64 | evil has Eve's name in it for a reason. |
| 00:25.47 | IriX64 | 12 minute install time, gotta get a faster toaster. |
| 00:32.27 | ``Erik | paste.lisp.org is teh seckzie |
| 00:44.27 | brlcad | sucky? *duck* |
| 00:50.24 | CIA-5 | BRL-CAD: 03brlcad * 10brlcad/src/mged/tedit.c: searching for a text editor.. needs the path on argv0, not just the name of the binary unless it's going to go hunting for it with bu_which(). |
| 00:51.35 | louipc | brlcad: I think it did work when I moved mkdirp.m4, just an error on my part hence 'oh no wait. ignore me' :P |
| 01:04.16 | brlcad | louipc: ahh, okay.. good to know then, thx |
| 01:04.20 | CIA-5 | BRL-CAD: 03brlcad * 10brlcad/src/libbu/dirname.c: extract bu_dirname() from malloc.c and put it in its own file. should consider using dirname() since it's part of posix (along with rt_basename() -> basename()). |
| 01:06.17 | CIA-5 | BRL-CAD: 03brlcad * 10brlcad/src/libbu/Makefile.am: add dirname.c to the compilation |
| 01:07.04 | CIA-5 | BRL-CAD: 03brlcad * 10brlcad/src/libbu/malloc.c: remove bu_dirname(), was moved to new file dirname.c. |
| 01:14.49 | CIA-5 | BRL-CAD: 03brlcad * 10brlcad/ (include/bu.h src/libbu/malloc.c): get rid of the bu_strdup() dead code and comment how it's really an interface macro pass through that provides file:line info when bu debugging is enabled |
| 01:17.38 | CIA-5 | BRL-CAD: 03brlcad * 10brlcad/ (src/libbu/libbu.dsp misc/win32-msvc7/libbu/libbu.vcproj): add dirname.c to the msvc build files |
| 01:20.54 | CIA-5 | BRL-CAD: 03brlcad * 10brlcad/HACKING: at least for now.. bu_dirname() instead of dirname() |
| 01:55.27 | IriX64 | why is castle all white and yellow ;) |
| 01:58.55 | IriX64 | http://www.pastebin.ca/364290 |
| 03:11.01 | CIA-5 | BRL-CAD: 03brlcad * 10brlcad/src/tclscripts/ (ami.tcl ampi.tcl): make sure argv is set to avoid btclsh sourcing errors |
| 03:11.49 | louipc | brlcad includes the latest utah-raster? 3.1b yeah? |
| 03:12.27 | louipc | circa 1996 |
| 03:17.41 | CIA-5 | BRL-CAD: 03brlcad * 10brlcad/ (5 files in 2 dirs): naming consistency, rename rt_dspline.c sans prefix to dspline.c |
| 03:20.01 | CIA-5 | BRL-CAD: 03brlcad * 10brlcad/ (include/raytrace.h src/librt/dspline.c): rename references of rt_dspline.c to dspline.c |
| 03:24.06 | CIA-5 | BRL-CAD: 03brlcad * 10brlcad/sh/header.sh: eek, double Lesser Lesser |
| 03:32.23 | CIA-5 | BRL-CAD: 03brlcad * 10brlcad/ (4 files in 4 dirs): less Lesser |
| 03:33.11 | CIA-5 | BRL-CAD: 03brlcad * 10brlcad/src/libbu/bu_fgets.c: ws |
| 03:38.08 | CIA-5 | BRL-CAD: 03brlcad * 10brlcad/ (5 files in 2 dirs): naming consistency, rename bu_fgets.c to fgets.c |
| 03:38.57 | CIA-5 | BRL-CAD: 03brlcad * 10brlcad/misc/win32-msvc7/libbu/libbu.vcproj: bu_fgets.c was missing from the vc7 build file, but we can just go ahead and add its rename of fgets.c |
| 03:39.14 | brlcad | louipc: yes, plus all patches as of last year |
| 03:39.35 | louipc | oh wow |
| 03:39.51 | brlcad | plus a few build fixes of our own, but nothing critical |
| 03:39.51 | louipc | yeah it looks like a real mess in there |
| 03:41.04 | louipc | I was going to make a packages of some stuff in other/ so I don't have to keep re-compiling it and such |
| 03:41.22 | brlcad | yeah, we also don't quell their compilation warnings (same for most things in src/other) either, so it whines about quite a few things during compilation |
| 03:41.38 | brlcad | some of them are in package systems |
| 03:43.04 | CIA-5 | BRL-CAD: 03brlcad * 10brlcad/src/libbu/brlcad_path.c: use a filesystem group, these routines have nothing to do with logging |
| 03:44.14 | brlcad | blt and iwidgets are often not available (but hard as hell to detect during configure) as well as openNURBS and tkimg .. everything else can usually be found |
| 03:44.53 | louipc | is a lot of this being developed any more? |
| 03:44.56 | brlcad | configure will automatically disable the compilation of anything it detects by default unless you enable an option that says to compile them |
| 03:45.02 | brlcad | a lot of what? |
| 03:45.08 | louipc | other/ |
| 03:45.11 | brlcad | oh yeah |
| 03:46.27 | brlcad | the stable or otherwise dead codes are urtoolkit, awf, jove, libpng, libregex, libtermlib, libutahrle (part of URT), and libz |
| 03:46.57 | brlcad | the others are fairly active, blt, incrTcl, iwidgets, tcl, tk, openNURBS, tkimg |
| 03:47.01 | louipc | ah you split urt into two |
| 03:47.48 | brlcad | yeah, not a great decision in hindsight, but it still has its benefits |
| 03:47.52 | louipc | I downloaded the src from an ftp server and I'm not sure what to do with it hah |
| 03:49.32 | brlcad | oh yeah, we did rewrite their build system too, so it compiles more reliably and cross-platform |
| 03:49.49 | brlcad | but then that goes for just about everything in other |
| 03:50.26 | louipc | ouch |
| 03:51.52 | louipc | I guess I'll start with what you say is still active then |
| 03:52.14 | louipc | thanks |
| 03:53.13 | brlcad | which packaging system? |
| 03:53.26 | louipc | archlinux |
| 03:53.29 | louipc | pacman |
| 03:53.30 | brlcad | ahh, that's right |
| 03:54.58 | brlcad | fwiw, tcl/tk cannot be disabled in the current sources due to run-time path resource lookups that tcl tries to do (in order to use a system tcl), but then that is actually what i'm working on tonight |
| 03:55.20 | brlcad | it's been a long-standing problem with using a system tcl/tk |
| 03:55.42 | louipc | ah neat yeah you said gentoo people and others were complaining about it |
| 03:56.05 | brlcad | that same issue trickles over to incrtcl, iwidgets, and blt, but this fix should take care of them all in one swoop |
| 03:56.14 | brlcad | yeah all of the packaging systems |
| 03:56.39 | brlcad | tk was the biggest problem, as we actually had additions made to their sources that we required |
| 03:57.04 | brlcad | but I've since rewritten and removed the modifications so it can work with a vanilla tk |
| 03:57.58 | louipc | ah |
| 04:02.50 | CIA-5 | BRL-CAD: 03brlcad * 10brlcad/NEWS: |
| 04:02.50 | CIA-5 | BRL-CAD: john continued to rock when he wrote bu_fgets() to allow automatic |
| 04:02.50 | CIA-5 | BRL-CAD: cross-platform line handling ala fgets(), which doesn't necessarily handle all |
| 04:02.50 | CIA-5 | BRL-CAD: of the various line endings that can be encountered (CR, LF, and CR/LF being the |
| 04:02.50 | CIA-5 | BRL-CAD: predominant ones). in particular, this fix addresses a bug that was reported on |
| 04:02.53 | CIA-5 | BRL-CAD: windows with dxf-g parsing files from another platform incorrectly. note the |
| 04:02.55 | CIA-5 | BRL-CAD: fix as it applies to dxf-g at least. |
| 04:04.49 | CIA-5 | BRL-CAD: 03brlcad * 10brlcad/src/libbu/fgets.c: whoops, formatting asterick garbage on M-q |
| 04:12.36 | CIA-5 | BRL-CAD: 03brlcad * 10brlcad/HACKING: should use bu_fgets() instead of fgets() since john's addition makes file for improved cross-platform processing support in general (parsing unix files on Windows, windows files on unix, etc). |
| 04:14.40 | ``Erik | jra++ |
| 04:15.03 | ``Erik | if he wasn't so insanely impressive, I think I'd have moved my office downstairs. |
| 04:15.33 | ``Erik | his gooby sh questions are well worth the "whoa, check me, yo" moments |
| 04:19.46 | brlcad | yeah, he's like a machine |
| 04:20.38 | brlcad | i think this update might just be one helluva collection of "bug fixes" if you consider the inability to parse foreign files a bug |
| 04:21.08 | brlcad | gonna hit almost half the tools, about 150 tools |
| 04:22.27 | brlcad | 250 instances |
| 04:24.10 | Maloeran | http://en.wikipedia.org/wiki/Arimaa - This is a very nice board game, seems more interesting than Go |
| 04:38.42 | *** join/#brlcad IriX64 (n=who@bas3-sudbury98-1168056909.dsl.bell.ca) | |
| 06:23.21 | *** join/#brlcad IriX64 (n=who@bas3-sudbury98-1168056909.dsl.bell.ca) [NETSPLIT VICTIM] | |
| 06:23.21 | *** join/#brlcad deltazap (n=zap@pool-72-64-253-55.tampfl.fios.verizon.net) [NETSPLIT VICTIM] | |
| 06:23.21 | *** join/#brlcad Twingy (n=justin@74.92.144.217) [NETSPLIT VICTIM] | |
| 06:23.21 | *** join/#brlcad Maloeran (n=maloeran@c510091F5.inet.catch.no) [NETSPLIT VICTIM] | |
| 06:23.21 | *** join/#brlcad CIA-5 (i=cia@cia.navi.cx) | |
| 06:24.52 | *** join/#brlcad BlackSabbath (n=andre@S0106000fb5a0e5c5.gv.shawcable.net) | |
| 06:53.52 | *** join/#brlcad dtidrow (n=dtidrow@c-69-255-182-248.hsd1.va.comcast.net) | |
| 07:26.26 | *** join/#brlcad clock_ (i=clock@84-72-94-164.dclient.hispeed.ch) | |
| 07:31.10 | *** join/#brlcad clock_ (i=clock@84-72-94-164.dclient.hispeed.ch) | |
| 07:37.55 | *** part/#brlcad BlackSabbath (n=andre@S0106000fb5a0e5c5.gv.shawcable.net) | |
| 07:47.01 | CIA-5 | BRL-CAD: 03brlcad * 10brlcad/src/mged/tedit.c: oop, bu_argv0 requires an argument |
| 07:51.19 | CIA-5 | BRL-CAD: 03brlcad * 10brlcad/src/conv/Makefile.am: |
| 07:51.19 | CIA-5 | BRL-CAD: turns out that anything being compiled static with gcc and against openNURBS |
| 07:51.19 | CIA-5 | BRL-CAD: needs the -fexceptions flag, that's what was causing the UnwindResume linkage |
| 07:51.19 | CIA-5 | BRL-CAD: error. link conv-vg2g (ugh, needs renaming) and euclid_unformat against libbu |
| 07:51.19 | CIA-5 | BRL-CAD: (needed for bu_fgets). |
| 07:54.09 | CIA-5 | BRL-CAD: 03brlcad * 10brlcad/src/irprep/ (9 files): convert to bu_fgets(), which of course adds a libbu dependency if there wasn't one already. this allows processing of foreign text files with different line endings more consistently. |
| 08:05.58 | CIA-5 | BRL-CAD: 03brlcad * 10brlcad/src/adrt/ (14 files in 7 dirs): revert the introduction of a libbu dependency to adrt, it's somewhat inconsequential value added just to get bu_getopt processing compared to the benefit of it still compiling stand-alone if needed. |
| 08:10.52 | CIA-5 | BRL-CAD: 03brlcad * 10brlcad/src/adrt/librender/Makefile.am: heh, -lm is not a CFLAG, add it to LIBADD instead using LIBM (still need to get adrt's subconfigure working cleanly). |
| 08:20.19 | CIA-5 | BRL-CAD: 03brlcad * 10brlcad/src/ (64 files in 22 dirs): |
| 08:20.19 | CIA-5 | BRL-CAD: update all usages of fgets() to instead use john's swanktastic bu_fgets() that |
| 08:20.19 | CIA-5 | BRL-CAD: behaves as one would generally want regardless of the line ending type of the |
| 08:20.19 | CIA-5 | BRL-CAD: compilation platform or of the input files. bu_fgets() responds to input files |
| 08:20.19 | CIA-5 | BRL-CAD: that use CR (usually old mac), LF (usually unix, new mac), or CR/LF (usually |
| 08:20.21 | CIA-5 | BRL-CAD: windows) for the line ending so now these file do too effectivley squashing |
| 08:20.23 | CIA-5 | BRL-CAD: buggish/bad behavior. |
| 08:32.37 | CIA-5 | BRL-CAD: 03brlcad * 10brlcad/NEWS: |
| 08:32.37 | CIA-5 | BRL-CAD: john's bu_fgets() fun and my update to the various tools that needed it ends up |
| 08:32.37 | CIA-5 | BRL-CAD: improved the end-of-line (EOL) processing in about 70+ tools. basically any |
| 08:32.37 | CIA-5 | BRL-CAD: command that read in a text file using fgets(). this fix is particularly |
| 08:32.37 | CIA-5 | BRL-CAD: relevant for running our tools on windows where data files are frequently |
| 08:32.39 | CIA-5 | BRL-CAD: migrated from the unix/linux/max side without a line-ending conversion. |
| 08:39.20 | *** join/#brlcad clock_ (n=clock@zux221-122-143.adsl.green.ch) | |
| 08:56.25 | CIA-5 | BRL-CAD: 03brlcad * 10brlcad/src/mged/setup.c: |
| 08:56.25 | CIA-5 | BRL-CAD: bu_getprogname seems to be behaving now, so use it for selection of the |
| 08:56.25 | CIA-5 | BRL-CAD: executable name unless it does return null for some reason -- then default back |
| 08:56.25 | CIA-5 | BRL-CAD: to just 'mged'. try (again?) to set auto_path before Tcl_Init since we need to |
| 08:56.25 | CIA-5 | BRL-CAD: set up auto_path before init so the scripts, including init.tcl, can be found. |
| 08:58.31 | CIA-5 | BRL-CAD: 03brlcad * 10brlcad/src/archer/archer: search for tcl/tk 8.5 too (we're upgrading to it now) |
| 09:05.43 | CIA-5 | BRL-CAD: 03brlcad * 10brlcad/src/libtclcad/tkImgFmtPIX.c: add support for the newer tk 8.5 Tk_PhotoExpand and Tk_PhotoPutBlock functions that now expect an interp parameter, but retain compilation functionality on previous versions too |
| 09:07.49 | CIA-5 | BRL-CAD: 03brlcad * 10brlcad/src/other/blt/src/bltNsUtil.h: comment out a couple function declarations that are apparently declared, at least in 8.5 though they're different/conflicting |
| 09:10.09 | CIA-5 | BRL-CAD: 03brlcad * 10brlcad/src/other/incrTcl/itcl/generic/itcl_util.c: the specified internal assumptions being made by blt don't hold with tcl 8.5 (in particular the set macro doesn't exist), so just comment out that section of code. |
| 09:17.43 | CIA-5 | BRL-CAD: 03brlcad * 10brlcad/src/rttherm/Makefile.am: add missing dependency on Tcl |
| 09:20.07 | CIA-5 | BRL-CAD: 03brlcad * 10brlcad/src/other/openNURBS/Makefile.am: create an openNURBS noinst library so that we can fully resolve librtserver if brep support is enabled |
| 09:22.05 | CIA-5 | BRL-CAD: 03brlcad * 10brlcad/src/Makefile.am: conditionally include opennurbs into libbrlcad (via the new noinst library) so that we can fully resolve all librt symbols |
| 09:30.42 | CIA-5 | BRL-CAD: 03brlcad * 10brlcad/src/ (burst/extern.h nirt/showshot.c): need bu.h for bu_fgets() |
| 12:55.13 | *** join/#brlcad docelic (n=docelic@212.91.115.41) | |
| 13:45.16 | *** join/#brlcad SWPadnos_ (n=Me@dsl245.esjtvtli.sover.net) | |
| 16:28.29 | Maloeran | Hum. I'm sorry to bother you with that, I wanted to familiarize myself with SURVICE's archer, what is this : Error in startup script: couldn't load file "/usr/brlcad/lib/tkimg.so": /usr/brlcad/lib/tkimg.so: undefined symbol: png_read_destroy ? |
| 16:31.40 | Maloeran | Assuming that's why ./archer gives me a nice white X window |
| 16:37.10 | Maloeran | Actually, that white window is bwish |
| 16:58.06 | *** join/#brlcad Twingy (n=justin@74.92.144.217) | |
| 17:25.15 | CIA-5 | BRL-CAD: 03erikgreenwald * 10brlcad/src/other/libpng/Makefile.am: libpng.txt was moved to libpng-1.2.16.txt |
| 17:26.32 | Maloeran | Erik, any tips about running Archer? |
| 17:27.13 | ``Erik | um |
| 17:27.14 | ``Erik | sure |
| 17:27.15 | ``Erik | use windows |
| 17:27.36 | Maloeran | It's supposed to run on Linux, is it not? |
| 17:28.26 | ``Erik | um, mark said that it should, but windows is their dev platform *shrug* the error you're getting might be fixed by preloading libpng.so? *shrug* |
| 17:28.43 | ``Erik | LD_PRELOAD=/usr/lib/libpng.so ./archer |
| 17:29.05 | Maloeran | Error remains |
| 17:29.10 | ``Erik | (or making tkimg.so link to libpng) |
| 17:29.32 | ``Erik | does your libpng have that symbol? ... |
| 17:30.21 | Maloeran | Doesn't seem to! |
| 17:31.05 | Maloeran | Upgrading libpng from 1.2.12-r1 to 1.2.13 though that's not likely to help |
| 17:31.08 | ``Erik | hm, upgrade it? |
| 17:31.41 | ``Erik | 1.2.13? wow, how ancient :D 1.2.16 is included in BRL-CAD these days... |
| 17:37.43 | brlcad | Maloeran: it does run on linux, but the version of archer in CVS hasn't been "fixed" to work out of the box |
| 17:38.44 | Maloeran | Oh. I suppose there's no quick and easy fix available? |
| 17:38.45 | brlcad | tkimg plugin is failing to load because of that png symbol is a linker issue in tkimg (or version problem with libpng) |
| 17:39.01 | brlcad | quick and easy if you're familiar with archer, sure ;) |
| 17:40.20 | brlcad | what does ldd on /usr/brlcad/lib/tkimg.so say regarding libpng? |
| 17:41.59 | Maloeran | Linked to libpng12.so.0 |
| 17:44.20 | Maloeran | Same problem with 1.2.15, last version of libpng in Gentoo package tree |
| 17:46.33 | Maloeran | Same problem with latest libpng CVS |
| 17:47.37 | ``Erik | $ nm -D /usr/local/lib/libpng.so | grep png_read_destroy |
| 17:47.37 | ``Erik | 00000000000098f0 T png_read_destroy |
| 17:48.23 | ``Erik | hum |
| 17:48.37 | ``Erik | is that because linux is obviously superior? :D *duck* |
| 17:49.27 | louipc | Maloeran: not gentoo!? |
| 17:49.27 | ``Erik | the symbol is there on rhat |
| 17:49.40 | ``Erik | and suse |
| 17:50.57 | Maloeran | http://rafb.net/p/GZGe0y78.html - Look, I'm not dreaming |
| 17:51.01 | ``Erik | and debian... hehehe.... |
| 17:51.13 | ``Erik | it's too bad funroll-loops.org doesn't seem to be responding... O:-) |
| 17:51.24 | louipc | :P |
| 17:51.59 | brlcad | Maloeran: you can relink tkimg.so with static libpng and if you really do have a sufficient version, it should resolve |
| 17:55.37 | louipc | I don't have that symbol either |
| 17:55.37 | Maloeran | louipc, what I basically want is a Linux from scratch, except... with some package management system, and Gentoo fulfills that |
| 17:55.57 | ``Erik | huh, it's not an optional symbol in 1.2.16... it's a basic part of cleaning up after you read an image O.o |
| 17:57.16 | louipc | Maloeran: have you tried archlinux? It's a lot less compiling but you can custom compile packages as well |
| 17:57.36 | brlcad | yeah, I don't see how you can optionally compile it out either with one of the PNG_* flags |
| 17:57.56 | louipc | the package management system is a lot more straight forward too |
| 17:58.01 | Maloeran | It's not really about packages, it's about the whole set up and scripts. I don't want a distribution to force its maze of scripts on me |
| 17:58.19 | ``Erik | ssoooooo cut their scripts out of the loop? |
| 17:58.37 | brlcad | oh, wait.. there is a overall flag.. PNG_READ_SUPPORTED .. if they compiled with that off, it leaves out all of the routines |
| 17:58.45 | brlcad | including png_read_destroy |
| 17:58.50 | Maloeran | It's tricky, it's often a huge mess. I prefer to start with a clean distribution like Gentoo |
| 18:00.57 | louipc | I've got png_read_end *image *info *png *row *rows *update_info |
| 18:01.03 | louipc | no destroy :( |
| 18:01.28 | Maloeran | Exactly |
| 18:03.12 | brlcad | Maloeran: it could also be a bad assumption in tkimg -- it has a stubs lookup table for png_read_destroy -- but it doesn'tactually use the function |
| 18:03.50 | brlcad | you could just remove it from src/other/tkimg/pngtcl/pngtclDecls.h and pngtclDeclsMask.h |
| 18:04.16 | brlcad | and src/other/tkimg/pngtcl/pngtclStubInit.c |
| 18:08.54 | CIA-5 | BRL-CAD: 03erikgreenwald * 10rtcmp/adrt/adrt.c: ADRT interface |
| 18:09.22 | ``Erik | fek, it's catching them now |
| 18:10.13 | CIA-5 | BRL-CAD: 03erikgreenwald * 10rtcmp/perfcomp.c: the comparison engine |
| 18:12.17 | CIA-5 | BRL-CAD: 03erikgreenwald * 10rtcmp/rtcmp.c: move the display back to the end, so the nmg_triangulate spew doesn't obfuscate the results |
| 18:23.31 | *** join/#brlcad IriX64_ (n=who@bas3-sudbury98-1168056909.dsl.bell.ca) | |
| 18:24.07 | Maloeran | Sorry, was away for a bit. png_write_destroy undefined as well, hacking some more |
| 18:25.44 | Maloeran | Ah finally, there we go, thanks |
| 18:27.10 | Maloeran | It works until "Error, can't find package blt", that is. |
| 18:27.23 | ``Erik | so make it a sandwich, bitch |
| 18:28.02 | ``Erik | blt == bacon lettuce tomato |
| 18:28.03 | ``Erik | :D |
| 18:34.13 | Maloeran | Okay, I'll give up on Archer for now. Mark wanted to know about integrating RF in it |
| 18:38.48 | IriX64_ | Maloeran? windows archer or *nix archer? |
| 18:39.51 | Maloeran | Linux archer of course |
| 18:39.59 | IriX64_ | ty |
| 18:50.49 | IriX64 | goof that i am sigh ... |
| 18:53.24 | ``Erik | heh, it's a bit of a walk |
| 18:54.56 | IriX64 | any wild beasten would disagree with me though :) |
| 18:56.59 | IriX64 | ``Erik promptly roars with hunger. |
| 18:57.16 | louipc | <PROTECTED> |
| 18:57.32 | IriX64 | not following? |
| 18:58.02 | ``Erik | and that's why drugs are bad. |
| 18:58.41 | IriX64 | heh you paint with a broadsword there you know that. |
| 18:59.21 | louipc | wide brush? |
| 18:59.57 | IriX64 | very |
| 19:17.11 | Maloeran | brlcad, would it be possible for you to quickly put me on the right track to solve this "Error, can't find package blt"? |
| 19:17.38 | ``Erik | sounds like a tcl path error |
| 19:17.49 | ``Erik | when you built brlcad, did it try to use the system tcl? |
| 19:18.15 | Maloeran | I have absolutely no idea, plain standard ./configure --prefix=/usr |
| 19:18.31 | ``Erik | hm, in src/other/libtcl, do you see libtcl_nil.la ? |
| 19:19.07 | IriX64 | try /prefix=/usr/brlcad. |
| 19:19.14 | IriX64 | err -- |
| 19:19.29 | Maloeran | Yes, it's there |
| 19:19.41 | Maloeran | Err nevermind, not the _nil part |
| 19:20.25 | ``Erik | hm, just libtcl.la ? |
| 19:20.39 | Maloeran | Correct |
| 19:20.48 | Maloeran | And libctcl8.4.la |
| 19:21.15 | ``Erik | ok, so it did build the tcl lib, hum |
| 19:21.29 | louipc | hm |
| 19:21.41 | ``Erik | ok, did src/other/blt get installed? |
| 19:21.59 | Maloeran | Seems to be compiled and installed, yes |
| 19:22.11 | ``Erik | tryyyyy LD_LIBRARY_PATH=/usr/brlcad/lib ? |
| 19:23.16 | Maloeran | Problem remains |
| 19:23.28 | ``Erik | ('cept it sounds like it's not finding the blt tcl index thingymajigger) |
| 19:23.41 | Maloeran | It occurs whenever I try to load or create a .g file |
| 19:25.49 | ``Erik | in... mged? or archer? |
| 19:25.59 | Maloeran | Archer |
| 19:49.27 | IriX64 | http://www.pastebin.ca/365207 <this is what archer says here Maloeran. |
| 20:00.33 | Maloeran | Cool, looks worse than mine :) |
| 20:08.46 | CIA-5 | BRL-CAD: 03erikgreenwald * 10brlcad/src/tclscripts/archer/images/Themes/Crystal_Large/Makefile.am: required images that need installed... |
| 20:09.00 | CIA-5 | BRL-CAD: 03brlcad * 10brlcad/src/other/libutahrle/ (Makefile.am include/Makefile.am): colorquant.h was moved to src/other/libutahrle/include/. |
| 20:09.33 | ``Erik | hm, seems to work fine for me |
| 20:09.36 | ``Erik | kinda neat |
| 20:14.30 | CIA-5 | BRL-CAD: 03erikgreenwald * 10brlcad/src/ (4 files in 4 dirs): dependancy info |
| 20:16.39 | Maloeran | Ah well, booting the win98 Pentium 2 |
| 20:16.41 | ``Erik | does mged work? |
| 20:17.28 | Maloeran | Yes |
| 20:17.54 | Maloeran | Or at least I think so, I don't know how to do anything with it.. but files load :} |
| 20:18.41 | ``Erik | um, in the command window, after you've opened a .g file, type "tops", then pick something interesting from that list and type "e <something>" |
| 20:19.13 | ``Erik | then you should be able to do mouse crap in the view window, uh, middle click I think is to rotate |
| 20:19.45 | Maloeran | Yup, it renders |
| 20:20.55 | Maloeran | Holy... graal, the raytrace is slow! :) My poor laptop |
| 20:21.00 | ``Erik | what about ummmm, uninstall, clean, reconfigure with --enable-almost-everything and do the build/install and see if that "fixes" it? |
| 20:23.00 | Maloeran | 153 seconds to shoot 2 million rays |
| 20:23.19 | Maloeran | All right, I'll try that switch |
| 20:23.36 | Maloeran | mged seems to have froze after the render completed |
| 20:23.53 | ``Erik | froze? hrm, odd |
| 20:24.45 | brlcad | Maloeran: default compile is non-optimized on top of it |
| 20:24.46 | Maloeran | The GUI was just made of plain gray windows |
| 20:25.29 | brlcad | mged's gui is non-optimal in many regards, it's not meant to be impressive |
| 20:26.11 | brlcad | if you recompile, unless you need to debug, add --enable-optimized too |
| 20:26.13 | Maloeran | No, I mean the mged windows were just of a filled plain gray instead of the usual widget elements |
| 20:26.36 | brlcad | sounds like it's waiting for something |
| 20:26.49 | brlcad | a dialog, or it's frozen on a bug, hard to say -- don't know what you did |
| 20:26.52 | ``Erik | yeah, hurry up and click the button that's not drawing... no, not that one!!! |
| 20:26.53 | ``Erik | :D |
| 20:27.20 | brlcad | ooh |
| 20:27.21 | Maloeran | I clicked on "raytrace" multiple times, then closed that dialog window after the render, and it went grey |
| 20:27.42 | Maloeran | Multiple times because I thought it wasn't working, it hadn't filled a handful of lines yet |
| 20:27.59 | brlcad | ahh, you probably provoked a bug |
| 20:28.06 | brlcad | and that |
| 20:28.13 | brlcad | do a killall rt on the command line |
| 20:28.28 | brlcad | or run "rtabort" if you can type into the command window |
| 20:29.12 | Maloeran | The command window was gone. I just did killall -9 |
| 20:30.49 | brlcad | did it restore or still stuck? |
| 20:31.32 | brlcad | if the command window gets too much data being dumped too quickly to it, there is a bug where it'll get stuck in a Tcl event handler loop, hanging mged |
| 20:32.22 | ``Erik | trying to see if other bits and chunks of the install work... |
| 20:32.23 | Maloeran | That might be what happened. I'm sorry I didn't wait very long, I just did killall -9 |
| 20:32.40 | brlcad | iirc, archer specifically tries to load blt directly, not using the auto_path search -- so you might have to tweak the load-line |
| 20:34.11 | brlcad | bob didn't make it robust cross-platform-wise, he got it working and moved on .. needed to produce another release for a different platform, made a few tweaks, and moved on |
| 20:35.16 | brlcad | sorta the multi-os makefile approach actually .. just that he's only fuddled with 2 of them so far and they have hard-coded assumptions about the compiler sort of setup |
| 20:35.19 | brlcad | ;) |
| 20:35.21 | *** join/#brlcad dtidrow_work (n=dtidrow@host169.objectsciences.com) | |
| 20:35.39 | brlcad | not literally of course, it's all tcl foo |
| 20:37.06 | ``Erik | dan seems to be having issues today o.O |
| 20:46.36 | CIA-5 | BRL-CAD: 03erikgreenwald * 10brlcad/src/libwdb/Makefile.am: no g_brep.cpp here... |
| 20:49.56 | ``Erik | oh, brlcad, I put those 3 fast linux machines into the perfmon mix |
| 20:50.20 | ``Erik | so now instead of getting excel spreadsheets saying they're going untouched, we can look at a graph of how untouched they are :D |
| 21:12.39 | Maloeran | --enable-almost-everything fixed the tkimg library issue, but it still throws errors about BLT |
| 21:16.11 | Maloeran | 14 seconds for 750000 rays, a bit better |
| 21:19.07 | Maloeran | Bug is reproductible. Click 20 times on "raytrace", and when all of them have completed or so I assume, processor usage drop back to zero and the mged gui freezes |
| 21:19.21 | Maloeran | I understand one isn't supposed to do that :) |
| 21:19.46 | ``Erik | heh |
| 21:20.16 | ``Erik | now try uninstalling, make clean, then configure with --enable-optimized :D |
| 21:20.21 | Maloeran | I did that |
| 21:20.25 | ``Erik | okie |
| 21:20.34 | ``Erik | slightly less horrible *shrug* |
| 21:21.24 | Maloeran | I'm sure its rays are far more accurate than mine :) |
| 21:21.37 | ``Erik | iiiinteresting, I keep getting brlcad_config.h files with exactly one line... :/ |
| 21:24.20 | Maloeran | http://www.rayforce.net/brlcad-rt-freeze.png - Just in case there's any doubt about what I mean |
| 21:27.58 | brlcad | Maloeran: hmmm. that might actually be a different issue |
| 21:30.34 | *** join/#brlcad docelic (n=docelic@212.91.114.6) | |
| 21:52.15 | *** join/#brlcad louipc (n=louipc@bas8-toronto63-1096782827.dsl.bell.ca) | |
| 21:56.20 | CIA-5 | BRL-CAD: 03brlcad * 10brlcad/BUGS: mged in console mode goes into an inf loop if you try to read from stdin using Tcl routines (e.g. read stdin, fgets stdin blah).; mged in GUI mode rejects reads on stdin |
| 21:56.21 | louipc | lol |
| 21:58.00 | Maloeran | Is that the bug? I would have assumed an infinite loop to consume some cpu time, it was more deadlocked |
| 21:58.28 | brlcad | Maloeran: no, different issue altogether |
| 21:58.48 | CIA-5 | BRL-CAD: 03brlcad * 10brlcad/src/tclscripts/mged/prj_add.tcl: header and ws |
| 22:01.55 | brlcad | there are lots of similarly "unforgiving" bugs that can occur when you do bad things that are considered bad use |
| 22:02.12 | brlcad | i don't generally fix them as time is being put towards the new interface instead |
| 22:02.18 | brlcad | i just document them as needed |
| 22:05.01 | brlcad | and fix or work-around if they're non-triivial or I'm needing some diversion |
| 22:27.56 | Maloeran | *nods* Sean, where in the brlcad source should I look for the conversion from solid modelling to triangles? |
| 22:32.39 | brlcad | depends on the purpose, but mostly in the converters section, src/conv, if you are doing a data conversion |
| 22:34.58 | Maloeran | I would like to see how complex it would be to make triangles face the proper way, build better meshes for raytracing ( less long thin triangles ), and perhaps fix the gaps between connected surfaces. It's the right place? |
| 22:35.39 | brlcad | as a starting point, yes |
| 22:36.02 | brlcad | that expands into src/librt .. a vast collection of nmg_* files and routines |
| 22:36.26 | brlcad | i can explain the overall process if you like |
| 22:36.37 | brlcad | from a high level, if it'd help |
| 22:37.03 | Maloeran | It could help, thanks. These files of 236kb are a bit intimidating |
| 22:38.15 | Maloeran | I think there might be several issues with the triangulation process. Do you consider the code is good enough to work from there, or a rewrite might be preferable? |
| 22:38.35 | brlcad | depends on a lot of factors |
| 22:38.53 | brlcad | it's not an easy problem at all, with the constraint of being topologically preserving |
| 22:38.58 | brlcad | and maintaining closure |
| 22:39.25 | Maloeran | Indeed, but I'm afraid any major changes to such a big piece of code might be more trouble than even rewriting.. |
| 22:39.27 | brlcad | it's slightly easier to just get triangles, but even that requires effort -- basically the evaluation of the boolean |
| 22:39.50 | brlcad | the code actually isn't that bad -- the approach is sound |
| 22:39.53 | Maloeran | Good to hear |
| 22:40.04 | brlcad | the bad news is that it lacks horribly in robustness |
| 22:40.20 | Maloeran | Yes, I noticed that... |
| 22:40.21 | brlcad | it doesn't manage propagate tolerance control very well |
| 22:40.33 | brlcad | and doesn't have good failure checking/recovery |
| 22:41.15 | brlcad | the algorithmic approach, however, is one of the recommended ways to go to maintain a solid model |
| 22:41.57 | Maloeran | I think that if a good and very fast solid modelling -> triangles conversion were possible, views could be raytraced interactively during the modelling |
| 22:41.58 | brlcad | we might actually have a rewrite in our laps already with openNURBS .. but that requires additional effort to integrate with to determine how good they tessellate |
| 22:42.28 | brlcad | that they could (and opengl becomes usable too) |
| 22:43.18 | brlcad | i was actually thinking of having your engine serve as that kind of real-time interface renderer in the new modeler if it were ever integrated |
| 22:43.21 | Maloeran | I think that would be really nice, and it would put some very-fast-but-not-so-accurate raytracer to good use |
| 22:43.36 | brlcad | be able to toggle between opengl, raytraced, wireframe, etc |
| 22:43.41 | Maloeran | Exactly |
| 22:44.18 | brlcad | so back to the crux of the problem to solve is the evaluation of the implicit solids and csg booleans (two separate problems) |
| 22:44.46 | brlcad | *currently*, the nmg code in librt does the following: |
| 22:45.40 | brlcad | 1) it walks a given csg hierarchy all the way down to the primitive level |
| 22:46.03 | brlcad | 2) it facetizes each primitive according to tessellation/tolerance/size criteria |
| 22:46.41 | brlcad | 3) it walks back up the csg hierarchy combining the facetized collections according to the CSG operations encountered |
| 22:46.54 | Maloeran | I'm not sure I would facetize before extruding volumes and so on... but please continue |
| 22:47.18 | brlcad | yes, that's a very good observation |
| 22:47.58 | brlcad | the bulk of the effort happens in the "combining the facetized collections" as that is the evaluation of the boolean, comparing polygon sets against polygon sets |
| 22:48.09 | brlcad | the implicits were evaluated in step 2 |
| 22:48.58 | Maloeran | Some problems, like gaps, are impossible to solve without swapping 2) and 3) |
| 22:49.40 | brlcad | for 3) to evaluate the CSG operations, it walks over all edges, of all loops, of all faces, of all surfaces, of all regions .. doing the pairwise comparison -- determines which polygons are inside or outside and depending on the operator, throws away those fully in/out as needed |
| 22:49.52 | brlcad | yes, very true |
| 22:50.04 | brlcad | well, you can guarantee no gaps |
| 22:50.12 | brlcad | but you can't guarantee that you'll find a solution |
| 22:50.23 | Maloeran | Eheh, okay :) |
| 22:50.32 | brlcad | it does guarantee no gaps, that is the nature of the nmg structure of walking edges, loops, faces, etc |
| 22:51.09 | Maloeran | Does it? The triangulated truck I was given has clear gaps between adjacent primitives |
| 22:51.21 | Maloeran | ( and it's not a raytracing artifact ) |
| 22:52.21 | brlcad | and when you have two spheres that are intersecting and being union'd together, for example, you will have two polygon datasets to start with, it computes which triangles are fully inside the other and throws them away, then computes where exactly the triangles intersect and correctly trims them and fuses the two sets together at a reasonable seam |
| 22:53.43 | brlcad | maybe I should say the structure "can" and is supposed to -- barring any bugs of course. there are other ways to extract polygons that will drop the solid model criteria, especially if it gets to solutions it cannot resolve |
| 22:54.50 | brlcad | for solid models, which are the predominant concern, it's supposed to, but then when we're going to polygons, it's usually for a non-solid model purpose so it is sometimes relaxed -- don't know the detail of how the truck was generated specifically (and it still could just be a bug regarless) |
| 22:55.24 | Maloeran | All right, so gaps don't normally occur. That's reassuring |
| 22:56.01 | brlcad | retaining knowledge of the actual surface/primitive toplogy is frankly a better way to go (and perhaps even an easier implementation) |
| 22:56.15 | Maloeran | Yes, I think so too |
| 22:56.21 | brlcad | but still requires a conversion from implicit form, to some explicit form |
| 22:56.23 | Maloeran | How efficient and optimized is the current code? |
| 22:56.26 | brlcad | just not triangles |
| 22:56.46 | brlcad | heh, nmg facetization? it's not optimized |
| 22:57.20 | brlcad | it's hard enough to get it working "correctly" regardless of the computational constraint |
| 22:57.42 | Maloeran | Stupid question : where can I see the list of all csg primitives used/known by the software? |
| 22:58.31 | brlcad | they're all in src/librt/g_*.c |
| 22:58.39 | brlcad | visually, here's "most" of them: http://ftp.brlcad.org/tmp/primitives/Primitives3_grouped_labels.png |
| 22:59.17 | brlcad | there are some details missing, that picture is just a simplification, and leaves some of the more complex/experimental primitives out |
| 22:59.19 | Maloeran | Hrmph, quite a few of them |
| 23:00.22 | louipc | how's the extrude further represented? |
| 23:00.37 | brlcad | all of them, except perhaps the bot/ars (i.e. triangles), dsp (i.e. height field), extrude/sketch, and bitmap primtiives are stored and usually processed in implicit form |
| 23:01.09 | brlcad | louipc: what do you mean? |
| 23:01.25 | brlcad | an extrude object is coupled to some sketch object |
| 23:01.45 | brlcad | sketches are pretty flexible/arbitrary collections of points, lines, arcs, loops, etc |
| 23:02.47 | louipc | ah |
| 23:02.52 | brlcad | i think extrude would probably be considered a hybrid, it's actually evaluated in a semi-implicit form, though the sketch is clearly an explicit representation |
| 23:03.56 | brlcad | extrusions are basically a direction vector and distance off of a sketch along with ratio scaling vectors |
| 23:05.11 | brlcad | Maloeran: the *plan* so far, assuming that this openNURBS business works out well (and it's going great so far, Jason's making nice progress) is to implement a "describe yourself in explicit spline surface form" for all primitives |
| 23:06.48 | brlcad | all primitives already have various describe functions -- describe in implicit form, describe in explicit wireframe form, describe as serialized on-disk form, describe as textual values, etc |
| 23:07.09 | Maloeran | Right, sounds like a good step towards a robust triangulation |
| 23:07.16 | brlcad | there's a stub in there (that a couple of the major primitives already implement) for describing in brep/spline surface form |
| 23:07.38 | Maloeran | I wonder though if it might not be slower than just working from the primitive equations, for most of them |
| 23:07.42 | brlcad | with that implemented, the next step would be to implement the boolean evaluation of brep against brep |
| 23:08.25 | brlcad | once you have an evaluated boolean-free brep, triangulation is trivial and can usually be done in real-time |
| 23:09.07 | brlcad | what do you mean by "work from the primitive equations"? which equation? |
| 23:09.40 | Maloeran | Of the csg primitives rather than splines |
| 23:11.06 | brlcad | i think i'm still not following what "it" was in "if it might not be slower" |
| 23:11.40 | brlcad | the big question is how hard and computationally intensive is it to evaluate brep against brep, evaluating the boolean |
| 23:12.36 | brlcad | my feel is that will be "reasonably fast" as in a couple seconds for an object with dozens to hundreds of primitives |
| 23:12.57 | brlcad | tessellation would be practically instantaneous |
| 23:13.16 | Maloeran | Yes... but that doesn't sound fast enough for interactive use, during the modelling process |
| 23:13.35 | brlcad | evaluation of the boolean when they are triangle vs triangle is what we have now with the nmg conversion process |
| 23:13.52 | brlcad | evaluation of the boolean when they are implicit against implicit is what we have now with librt |
| 23:14.27 | brlcad | actually, it generally is fast enough, because that's the time to convert something all-out |
| 23:14.42 | brlcad | that conversion can be hidden in many places (during file load for example) |
| 23:15.11 | brlcad | during editing, it's pretty much instantaneous evaluation as you're only evaluating small deltas |
| 23:15.23 | Maloeran | *nods* It's just less practical to stall the rendering for a couple seconds every time the user makes a change, though you could only rebuild the affected region |
| 23:15.28 | Maloeran | All right, great |
| 23:15.39 | brlcad | it's actually the approach most commercial cad systems take that use BREP as their primary representation |
| 23:15.53 | brlcad | and you do end up pausing on large models while it evaluates every now and then |
| 23:16.05 | Maloeran | Sounds very nice then. The only problem I'm seeing is not having triangles face the proper way, which should be really easy to fix |
| 23:20.21 | Maloeran | That and efficiency perhaps. Would you mind some #ifdef __SSE__ in that code? ;) |
| 23:21.23 | brlcad | depends on a lot of factors, but in general not really a problem so long as there's an alternative |
| 23:22.10 | brlcad | the bigger issue would be tolerance, there's entire classes of cases where even double floating point isn't enough |
| 23:22.28 | Maloeran | Oh? I wouldn't have expected that |
| 23:22.56 | brlcad | yeah, that's one of the bigger problems some of the CAD systems deal with to varying degrees of success/failure |
| 23:23.35 | brlcad | you know what a tapered blend is, yes? |
| 23:23.52 | Maloeran | Sorry, I don't |
| 23:25.19 | Maloeran | A reasonably fast fixed 128 or 256 bits data type to handle these cases wouldn't be too much trouble to write, perhaps to integrate in the code though |
| 23:25.59 | Maloeran | ( With SSE, a home-made 128 bits floating point format doesn't look so bad ) |
| 23:26.03 | brlcad | hmm, better example then.. say you have a hand full of peanut butter and you smear it out across a table making a sloping ramp that becomes rather minutely thin |
| 23:26.24 | Maloeran | That I can follow :) |
| 23:26.30 | brlcad | the issue becomes how and where you terminate the ramp |
| 23:27.02 | Maloeran | I see, okay |
| 23:27.43 | brlcad | it might be a smear that is mathematically something like |||||\\\~~~~~,,,,..... |
| 23:27.44 | brlcad | the question is how many dots |
| 23:27.44 | Maloeran | I'm thinking, we really could make a 128 bits floating point data type in SSE that would be just a bit slower than double |
| 23:27.53 | brlcad | even with double on most cases, you cannot go out as far as you need to without truncating the ramp prematurely |
| 23:28.04 | ``Erik | O.o |
| 23:28.15 | brlcad | else you end up with something mathematically just a plane .. and that's no longer a solid model |
| 23:28.24 | Maloeran | Understood |
| 23:28.38 | brlcad | that particular case actually happens a lot in real engineering models |
| 23:29.03 | brlcad | solder between joints, tapered blends, various materials combining together, etc |
| 23:29.06 | Maloeran | If these cases can be identified before or when we encounter them, a home-made floating point format could be a great solution |
| 23:29.12 | brlcad | there are others, but that's the easiest to describe |
| 23:30.07 | brlcad | part of the problem is that they are frankly hard as hell to identify and even worse to detect them |
| 23:30.25 | Maloeran | Oops okay, that's a problem |
| 23:30.39 | brlcad | because you already have code asking questions like "are theses two surfaces cojoined".. are they the same, are they just "really close", etc |
| 23:31.09 | brlcad | if you assume just really close, then you lose solid model connectivity, introduce gaps, etc |
| 23:31.43 | brlcad | if you assume they're not, then there similarly isn't a problem of gaps and such, but you truncate and create non-faithful geometry |
| 23:31.48 | Maloeran | Indeed |
| 23:32.11 | brlcad | you sort of need to know the modelers intent during the modeling process |
| 23:32.23 | brlcad | which would be great to have of course... but you rarely have that :) |
| 23:32.53 | brlcad | that's where unigraphics and solidworks start earning their pricetags |
| 23:32.58 | Maloeran | Hum. I really thought the interface would allow modellers to make their intend clear |
| 23:33.09 | Maloeran | At least it was when I did Autocad |
| 23:33.43 | brlcad | initially you have it, after almost any conversion except sometimes with STEP, all that is lost |
| 23:34.18 | brlcad | and most real modeling is done by teams and/or between companies/groups and often using different cad systems |
| 23:35.15 | brlcad | iges is/was the predominant cad exchange format, and it didn't retain this sort of intent modeling, just connectivity if you were lucky, but sometimes you'd lose even that |
| 23:35.16 | Maloeran | Right, so intents on connectivity are lost and the code falls back on... guesses |
| 23:35.41 | brlcad | and then all bets are off, normals get reverse, you might get cracks, etc ;) |
| 23:36.48 | brlcad | for as painful and crappy as NMGs are in librt, they're actually on par with a lot of cad systems for that class of conversion, sometimes it's even better |
| 23:37.16 | brlcad | but the approach is fundamentally limited given you loose actual surface/intersection information really early on during implicit evaluation |
| 23:37.51 | Maloeran | If it's really a problem that numerical precision can solve... I'm thinking about some hack coming from my overview of the gcc code |
| 23:38.01 | brlcad | it then spends 80-99% of the time evaluating sets of N^3 problems |
| 23:38.18 | Maloeran | We could replace the built-in fpu emulation code with floats and doubles of 128 and 256 bits |
