| 01:33.57 | *** join/#brlcad Twingy (n=justin@74.92.144.217) |
| 02:04.46 | *** join/#brlcad Daytona (n=jra@c-68-55-36-65.hsd1.md.comcast.net) |
| 02:06.33 | Daytona | prasad_: Hey, how's it going? |
| 02:28.01 | *** join/#brlcad pacman87 (n=Timothy@resnet-45-192.dorm.utexas.edu) |
| 02:41.13 | poolio | yikes. I accidentally just removed my brlcad folder because the box I was ssh'd into has the same PS1 :'( |
| 02:56.02 | yukonbob | :P |
| 02:57.42 | poolio | hopes he backed up everything |
| 03:14.19 | poolio | So I passed configure and when I went to building it failed because it could not find zlib.h. I installed zlib, but shouldn't configure have caught this? |
| 03:15.53 | poolio | (it correctly detects that I do not have a working zlib though, maybe it should be pointed to brlcad's zlib.h?) |
| 03:20.10 | poolio | so the problem appears to be that I had working zlib runtime and not the development headers... |
| 04:18.34 | brlcad | hello Harriss |
| 04:18.41 | brlcad | and howdy poolio |
| 04:20.14 | *** join/#brlcad wuxia (n=wuxia@unaffiliated/wuxia) |
| 04:20.15 | brlcad | yeah, the test is technically for both libs and (separately) for headers and (separately) for run-time functionality .. at least usually those three have to pass for a given lib |
| 04:20.28 | brlcad | otherwise it doesn't have what it needs |
| 04:20.33 | brlcad | hello wuxia |
| 04:21.00 | wuxia | can anyone expain what the brlcad rendering algorithm does? i.e. does it only require that the geometry support a 'does this ray intersect with this shape' query? [I'm trying to find something similar to 'generative modeling language' or synder's 'genmod' ] |
| 04:22.35 | brlcad | depends what the "it" is in your sentence |
| 04:23.32 | brlcad | in terms of implementing or adding new primitives, they basically just have to answer the "does this ray intersect with this shape" |
| 04:23.36 | wuxia | hey, that's a good bot |
| 04:23.42 | wuxia | what algorithm? alice? elizra ? |
| 04:23.54 | brlcad | ~fishslap wuxia |
| 04:23.54 | ibot | ACTION slaps wuxia up side the head with a wet fish. |
| 04:24.42 | wuxia | a human would have kicked me |
| 04:25.18 | brlcad | so comparing against all primitives, it ends up with lots of "segments" -- those are weaved together per the CSG rules |
| 04:25.40 | wuxia | gotcha :-) |
| 04:25.54 | wuxia | is there any good interfaces between pbrt and brlcad? |
| 04:26.04 | wuxia | I feel that pbrt does ray tracing better, but brlcad is better at modeling |
| 04:26.48 | brlcad | pbrt does a lot of things fundamentally differently |
| 04:28.15 | wuxia | is there any good bridge for taking a gbrlcad model |
| 04:28.20 | wuxia | and rendering it in pbrt? |
| 04:28.31 | brlcad | if generating pretty pictures is your goal, they certainly have a better global illum model integrated -- but then iirc they are almost exclusively explicit geometry models and not a shotline-capable solid geometry ray-tracer (evaluating all the way along through materials) |
| 04:28.48 | brlcad | i'm not aware of any "good" bridge yet |
| 04:29.01 | brlcad | mostly because of that implicit vs explicit geometry issue |
| 04:29.02 | wuxia | what is 'shotline-capable solid geometry ray-tracer' ? |
| 04:30.17 | brlcad | it's a fair bit to explain, but basically a ray-trace engine that takes solidity into account -- not just surface-based or (the most common) first-hit based ray-trace interfaces |
| 04:30.43 | wuxia | for a surface-based |
| 04:30.47 | wuxia | I need only provide "does this ray intersect" |
| 04:30.57 | brlcad | brl-cad's librt ray-trace engine is a full-path shotliner that will either report first-hit or all segments along the ray |
| 04:31.04 | wuxia | what more complicated thing does "shotline-capable solid geometry ray-tracer' require me? |
| 04:31.10 | wuxia | ah |
| 04:31.14 | wuxia | and one way to do csg |
| 04:31.19 | wuxia | is to report all semgnets along the ray? |
| 04:31.25 | wuxia | and then do the csg operations |
| 04:31.29 | wuxia | to decide which one it actually hit? |
| 04:32.07 | brlcad | actually you can evaluate the csg with just first hit or with all segments |
| 04:32.18 | brlcad | that's not really different |
| 04:32.31 | brlcad | i'm talking about other purposes of ray-tracing, not just generating pictures |
| 04:32.41 | wuxia | oh |
| 04:32.45 | wuxia | like firing a bullet into a tank? |
| 04:32.57 | brlcad | sure |
| 04:33.13 | brlcad | or simply answering the question of "how much of this material is on this shotline" |
| 04:34.09 | brlcad | with an explicit ray-engine, you end up with all sorts of analytic/analysis questions that are harder to guarantee without solid geometry |
| 04:34.48 | wuxia | why is that |
| 04:34.51 | wuxia | given a boundary |
| 04:34.54 | brlcad | if you assertively have "crack-free" geometry, and aren't inside things when you start a ray |
| 04:35.03 | wuxia | why can't I get the 'solid geometry' by looking at entry and exit points? |
| 04:36.27 | brlcad | mostly because of numerics -- if your geometry isn't actually cracked (i.e. non-solid), there is a higher probability of numerical cracks due to floating point issues on the seams on the boundaries |
| 04:36.50 | brlcad | solid geometry entails a *guarantee* that there is no crack, numeric or otherwise |
| 04:37.23 | brlcad | implicit geometry implicitly guarantees this, other CAD systems provide the guarantee through "crack-free" BREP implementations |
| 04:37.38 | brlcad | something that only generates pictures doesn't really have to care |
| 04:37.57 | brlcad | anyway, why you ask? :) |
| 04:38.38 | brlcad | there are ways to extract an explicit geometry model from brl-cad geometry that you could undoubtedly feed to pbrt via one of their importers |
| 04:39.06 | wuxia | i want to render procedural sci-fi cities |
| 04:39.07 | brlcad | it conceivably wouldn't be that hard to write an exporter if you have their file format (especially if they support primitive descriptions) |
| 04:39.16 | wuxia | brl-cad looks awesome for geometry modeling; pbrt for rendering |
| 04:41.35 | brlcad | wuxia: for what it's worth, pbrt looks great because most of their shots have global illumination calcs turned on (which librt doesn't implement, though it is a gsoc topic) |
| 04:42.21 | brlcad | there's only two screenshots that use the global illum renderer we do have: http://brlcad.org/gallery/s/renderings/humvee.png.html and http://brlcad.org/gallery/s/renderings/stryker_slat.jpg.html |
| 04:42.57 | brlcad | brute force solutions |
| 04:43.10 | brlcad | and required conversion to brep polygonal format |
| 04:43.21 | wuxia | why brep first? |
| 04:43.27 | wuxia | why can't global illumination be done on csg's ? |
| 04:47.19 | brlcad | there's no reason it can't |
| 04:47.41 | brlcad | it just hasn't been done yet, that's why it's a gsoc suggested task |
| 04:50.10 | *** join/#brlcad hippieindamakin8 (n=hippiein@203.200.95.130) |
| 04:55.01 | poolio | brlcad: wait, so then why did it fail compiling but pass configure? in config output it says it's using system zlib, but I fail the tests |
| 05:01.04 | poolio | basically, I was just upset to see the build die :) |
| 05:04.27 | brlcad | as you should be, build failures indicate something is probably wrong in configure :) |
| 05:07.39 | brlcad | that third test -- the functionality test -- is either weak or non-existent for zlib |
| 05:10.59 | poolio | bah. I want configure to stop and print in big bold letters that I should not continue :) I ran configure and looked away, and the summary looked all fine and dandy |
| 05:13.58 | brlcad | that's what I mean -- it's probably missing a test |
| 05:14.02 | brlcad | it normally does halt |
| 05:14.44 | poolio | ah Ok |
| 05:14.49 | poolio | thanks and sorry for the whining :) |
| 05:15.10 | brlcad | hum, was just looking |
| 05:15.15 | brlcad | there is a functionality test |
| 05:15.26 | brlcad | so "something else" is wrong |
| 05:15.39 | poolio | errr, I also just realized the build failed again later |
| 05:16.17 | brlcad | can you post your build log and config.log files? |
| 05:16.22 | poolio | this is a trunk checkout by the way |
| 05:16.38 | poolio | yeah, do I uninstalled the zlib1g-dev package and am going to regenerate the broken zlib.h error |
| 05:21.19 | poolio | brlcad: build is gonna take a little while, I'm on my shiny new, not that fast, x300 :P |
| 05:23.15 | brlcad | heh |
| 05:29.20 | poolio | brlcad: config.log: http://poolio.org/files/config.log and build: http://poolio.org/files/zlib_error.txt |
| 05:38.37 | brlcad | poolio: try editing src/other/tkimg/png/Makefile.am and add: ${LIBZ_CPPFLAGS} \ after the PNG_CPPFLAGS line |
| 05:39.13 | poolio | brlcad: alright, I'm waiting for the build to finish with zlib-dev installed, so gimme a few minutes. |
| 05:39.30 | poolio | is feeling the grind of the 1.2ghz for the first time |
| 05:41.01 | CIA-33 | BRL-CAD: 03brlcad * r30625 10/brlcad/trunk/src/other/tkimg/png/Makefile.am: missing LIBZ_CPPFLAGS |
| 05:41.35 | brlcad | yeah, I'm betting that was the problem -- tkimg's png module's build rules didn't have the header search path |
| 05:41.50 | brlcad | the configure tests worked, failed and was set to build |
| 05:43.21 | poolio | alrighty |
| 05:47.38 | poolio | brlcad: http://poolio.org/files/htester_error.txt is what I'm getting with zlib working |
| 05:58.10 | brlcad | didn't realize you're on ubuntu/debian? |
| 05:59.14 | brlcad | they have a busted libtool, it incorrectly strips out linkage paths |
| 05:59.46 | poolio | sorry :( |
| 06:00.00 | poolio | is there an easy fix? |
| 06:00.26 | brlcad | other than installing an unmodified libtool from gnu? |
| 06:00.37 | brlcad | unmodified works without a hitch |
| 06:01.58 | brlcad | otherwise, I haven't completed debugging the libtool script itself to see if there's a good way to trick it or work around it |
| 06:22.18 | poolio | that's weird, because when I was working on brlcad last summer I was using debian |
| 06:24.28 | brlcad | yeah, the build options have changed to not be excessively redundant -- there was a recursive redundant declaration of libraries pushed down to the binary LD line instead of relying on libtool's usual dependency tracking |
| 06:25.03 | brlcad | pushed down to the binary ld option, debian's mods don't come into play |
| 06:25.27 | brlcad | but that's a bear to keep -- libraries listed dozens of times over per binary |
| 06:59.02 | *** join/#brlcad clock_ (n=clock@77-56-92-162.dclient.hispeed.ch) |
| 07:07.38 | poolio | brlcad: sounds like a good dev choice, but having a source install not function on a very popular distro is a bad decision :) |
| 07:10.28 | brlcad | of course |
| 07:12.13 | brlcad | someone(tm) really needs to see if there's some way to work around the problem |
| 07:13.43 | brlcad | being popular isn't a good excuse for being wrong too, the problem has been reported by others to debian devs and they refuse to fix it |
| 07:15.25 | brlcad | we make workarounds for a lot of platform-specific stupidities, that one just isn't in the frequent testing rotation as nobody has stepped up to maintain the port |
| 07:17.44 | brlcad | so feel free to be that someone(tm) and fix it :) |
| 07:18.08 | brlcad | shouldn't be too hard to find a work-around |
| 07:22.28 | poolio | brlcad: in a month or so I'll give it a shot :) |
| 08:20.28 | *** join/#brlcad Axman6 (n=Axman6@pdpc/supporter/student/Axman6) |
| 08:47.43 | *** join/#brlcad d_rossberg (n=rossberg@bz.bzflag.bz) |
| 09:53.20 | *** join/#brlcad mafm (n=mafm@elnet-111.lip.pt) |
| 09:54.40 | mafm | hallo |
| 10:19.16 | *** join/#brlcad MinuteElectron (i=5207211c@silentflame/member/pdpc.base.minuteelectron) |
| 10:58.32 | *** join/#brlcad MinuteElectron (i=5207211c@silentflame/member/pdpc.base.minuteelectron) |
| 13:04.08 | brlcad | howdy mafm |
| 13:05.17 | mafm | :) |
| 13:05.52 | ``Erik | no love for twingy's photon mapping, I see O.o |
| 13:38.36 | mafm | hmm, I have a linguistic question totally unrelated to the topic of the channel, may I? |
| 13:39.43 | brlcad | go for it |
| 13:41.38 | mafm | if I'm studying a degree, say CS, what's the name of the individual parts composing it, as in Programming I, Networks, Distributed Systems, AI, etc, comprising typically one semester or a year, one hour per day or so? it's "courses"? |
| 13:48.13 | brlcad | yeah, those are your courses |
| 13:48.51 | mafm | hmm, and you're from USA right? |
| 13:49.19 | brlcad | i've lived in a number of places, and the usa is one of them |
| 13:50.23 | mafm | it's only to ask if you know if it's named the same across english-speaking languages |
| 13:50.55 | brlcad | tries to think what else you might call them |
| 13:51.06 | mafm | for some reason I was calling it "subjects", but I don't know where I took it :D |
| 13:51.18 | brlcad | courses, classes, seminars |
| 13:51.36 | mafm | maybe it's that I directly translate from portuguese or something like that |
| 13:51.37 | prasad_ | hey is daytona == jra? |
| 13:51.41 | brlcad | usually "seminar courses" are a specific type |
| 13:51.44 | brlcad | prasad_: yup |
| 13:51.49 | prasad_ | ah missed him |
| 13:52.14 | brlcad | mafm: yeah, I think courses/classes are pretty much the terms |
| 13:53.14 | mafm | good, thank you very much |
| 13:56.10 | *** join/#brlcad MinuteElectron (i=5207211c@silentflame/member/pdpc.base.minuteelectron) |
| 14:09.43 | *** join/#brlcad MinuteElectron (n=MinuteEl@silentflame/member/pdpc.base.minuteelectron) |
| 14:32.40 | mafm | svn: URL 'https://brlcad.svn.sourceforge.net/svnroot/brlcad/trunk' doesn't exist |
| 14:32.44 | mafm | what do you use as trunk? |
| 14:38.00 | poolio | /svnroot/brlcad/brlcad/trunk |
| 14:44.35 | mafm | oh thanks |
| 15:01.29 | brlcad | ~cadsvn |
| 15:01.29 | ibot | To obtain BRL-CAD from Subversion: svn checkout https://brlcad.svn.sourceforge.net/svnroot/brlcad/brlcad/trunk brlcad |
| 15:04.43 | mafm | not a light download, it seems :) |
| 15:28.11 | *** join/#brlcad Elperion (n=Bary@p54875445.dip.t-dialin.net) |
| 16:00.22 | mafm | hmm, the things using C++ in brl-cad are related to 3rd party tools? |
| 16:03.56 | mafm | and is it all in other/ 3rd party tools it seems? |
| 16:04.16 | *** join/#brlcad Axman6 (n=Axman6@pdpc/supporter/student/Axman6) |
| 16:06.49 | mafm | brlcad: I have a problem compiling |
| 16:11.21 | poolio | mafm: are you by any chance running a debian-based distro? |
| 16:11.49 | mafm | nope, I don't run degenerates |
| 16:11.59 | mafm | I use Debian itself :) |
| 16:12.01 | poolio | debian is debian-based, no? |
| 16:12.20 | mafm | just kidding :) |
| 16:12.30 | mafm | so what's the problem with debian then? |
| 16:12.42 | poolio | mafm: So I just had the same problem earlier... brlcad says debian uses a broken libtool, and there's no easy fix other than installing a clean libtool |
| 16:12.56 | mafm | :S |
| 16:13.34 | mafm | what's a clean libtool? different versions, vanilla without possible distro patches? |
| 16:13.53 | poolio | vanilla I would guess |
| 16:14.48 | mafm | /usr/bin/ld: warning: libtcl8.5.so, needed by ./.libs/libbu.so, not found (try using -rpath or -rpath-link) |
| 16:14.48 | mafm | ./.libs/libbu.so: undefined reference to `Tcl_ResetResult' |
| 16:14.48 | mafm | ./.libs/libbu.so: undefined reference to `Tcl_SetObjResult' |
| 16:14.49 | mafm | ... |
| 16:14.55 | mafm | is this your error too? |
| 16:23.57 | poolio | Yep. |
| 16:25.40 | mafm | :S |
| 16:25.44 | mafm | version? |
| 16:26.00 | mafm | ii libtool 1.5.26-1 Generic library support script |
| 16:40.28 | poolio | 1.5.26-2 here. It's more than just libtool, I tried out a vanilla libtool and that didn't fix it |
| 16:41.27 | mafm | :S |
| 16:43.23 | poolio | mafm: Just softlink libtcl8.5.so.0 to libtcl8.5.so for now |
| 16:45.40 | mafm | what vanilla libtool did you try? I installed the one from 'stable' distro, which is .22, and it just seems to work |
| 16:46.02 | mafm | or maybe it didn't reach the part failing yet, not sure :D |
| 16:46.49 | poolio | mafm: haven't tried vanilla, sorry |
| 16:47.24 | mafm | ok |
| 16:47.30 | mafm | but this .22 one seems to fix it, yuep |
| 16:47.32 | mafm | :) |
| 17:12.48 | *** join/#brlcad clock_ (n=clock@77-56-86-67.dclient.hispeed.ch) |
| 17:37.26 | mafm | does anybody know if it's worth patching the 3rd party tools for compiler warnings/errors? |
| 17:42.04 | ``Erik | yes, debian modifies libtool to "optimize" the link line |
| 17:42.17 | ``Erik | the effect is that they strip out critical information needed to compile BRL-CAD |
| 17:43.26 | ``Erik | mafm: don't worry too much about language barriers, both brlcad and I have lived in non-english speaking countries for several years, we will ask if we don't think we understand what you intend to say... |
| 17:45.37 | ``Erik | now if I recall the issues with the debian libtool correctly from last time I chased that down, a system installed tcl85 will still work... and I THINK debian just picked up 85 into testing, d'no if that's floated to ubuntu or other derivatives just yet |
| 17:45.57 | ``Erik | may have to redo the debian script in BRL-CAD to use the system one |
| 17:50.06 | *** join/#brlcad CIA-33 (n=CIA@208.69.182.149) |
| 17:55.52 | mafm | the language doubts were not meant to clear up misunderstandings, it's because I was updating my CV :) |
| 17:56.29 | mafm | well, to avoid the hassle I just put that tcl8.5 dir in the ld.so.conf file |
| 17:58.56 | mafm | bah, a new related error :S |
| 18:05.11 | ``Erik | oh? |
| 18:05.51 | mafm | before that ... in libbu you use a temp.c to make temporary files... why not use mktemp calls instead? aren't they portable enough? |
| 18:06.36 | mafm | ``Erik: the new error is: http://rafb.net/p/YDu6XN14.html |
| 18:37.01 | poolio | mafm: I got there with the system libtool, linking libtcl8.5.so.0 to .so |
| 18:41.18 | mafm | but it's not working for me |
| 18:41.35 | mafm | maybe I'm missing some additional library or something |
| 18:55.20 | ``Erik | looks like libXi.so isn't being picked up for some reason :/ |
| 18:59.24 | mafm | ``Erik: in libbu you use a temp.c to make temporary files... why not use mktemp calls instead? aren't they portable enough? |
| 19:00.07 | ``Erik | mktemp is actually bad, mkstemp is better |
| 19:00.54 | ``Erik | mktemp also doesn't work on all platforms, like old obscure ones (crayos? vms?) or stupid ones (windows?) iirc |
| 19:01.37 | ``Erik | *looklooklook* |
| 19:01.44 | alex_joni | heh, stupid :) |
| 19:02.07 | mafm | doesn't work in windows? |
| 19:02.09 | mafm | hmm |
| 19:02.23 | mafm | there was a similar issue with Aqsis |
| 19:02.28 | ``Erik | ah, looks like it's a "safe" wrapper for mkstemp() with file marshalling |
| 19:02.50 | mafm | I think that they used in there a relatively clean workaround, not so huge as in libbu |
| 19:02.54 | ``Erik | and a very low level last ditch attempt |
| 19:03.02 | ``Erik | huge as bu? temp.c is tiny |
| 19:03.18 | ``Erik | and works pretty much everywhere O.o :D |
| 19:03.23 | mafm | well, I'm talking about 10 lines or so |
| 19:03.34 | ``Erik | notes that aqsis does not work on as many platforms as BRL-CAD |
| 19:03.36 | mafm | not in the hundreds of lines |
| 19:04.35 | ``Erik | most of temp.c is error checking of some form or another *shrug* |
| 19:04.40 | mafm | well, that's the question... it's in the ToDo or Buglist to remove that code, so I thought about that... but if it's not portable enough... :) |
| 19:04.55 | ``Erik | a lot of the portability isn't NEEDED anymore |
| 19:05.05 | ``Erik | we've stripped out some vax gould and crayos code already |
| 19:05.21 | ``Erik | because no one uses 70's or 80's computers anymore |
| 19:05.33 | mafm | :) |
| 19:06.00 | ``Erik | also; few os's leave dangling file handles when an app is closed anymore |
| 19:06.07 | mafm | In the TODO: * libbu routine to make a temp file reliably/consistently |
| 19:06.31 | ``Erik | hrm, probably means brlcad spotted a place where mkstemp failed |
| 19:07.30 | *** join/#brlcad gedex (n=gedex@222.124.185.169) |
| 19:08.09 | CIA-33 | BRL-CAD: 03brlcad * r30627 10/brlcad/trunk/AUTHORS: add gillich to the contributors list for his g-sat importer |
| 19:08.28 | mafm | I see |
| 19:08.40 | mafm | well, I already produced a patch, even if not very useful |
| 19:09.53 | mafm | if I have time maybe I'll do something better during the selection process :) |
| 19:10.13 | *** part/#brlcad gedex (n=gedex@222.124.185.169) |
| 19:11.40 | yukonbob | waves in |
| 19:12.30 | mafm | hallo yukonbob |
| 19:16.58 | mafm | have to go now |
| 19:17.25 | mafm | bye |
| 19:40.32 | *** join/#brlcad clock_ (n=clock@77-56-86-67.dclient.hispeed.ch) |
| 19:56.19 | *** join/#brlcad clock_ (n=clock@77-56-86-67.dclient.hispeed.ch) |
| 20:43.04 | *** join/#brlcad clock_ (n=clock@77-56-86-67.dclient.hispeed.ch) |
| 20:55.01 | *** join/#brlcad prasad_ (n=psilva@70.108.244.218) |
| 20:58.07 | CIA-33 | BRL-CAD: 03bob1961 * r30629 10/brlcad/trunk/src/mged/mged.bat: Mods to get rid of complaints about nul. |
| 20:58.07 | CIA-33 | BRL-CAD: 03bob1961 * r30630 10/brlcad/trunk/src/archer/archer.bat: Move "ECHO OFF" up in the file. |
| 21:43.00 | *** join/#brlcad pacman87 (i=127@resnet-45-192.dorm.utexas.edu) |
| 21:43.43 | *** join/#brlcad Mets (n=Mets@JETSTAR.RES.cmu.edu) |
| 21:43.54 | *** part/#brlcad Mets (n=Mets@JETSTAR.RES.cmu.edu) |
| 21:57.35 | *** join/#brlcad iraytrace (n=iraytrac@trapezewireless114.insecure.utah.edu) |
| 22:12.47 | *** join/#brlcad cad68 (n=59d93561@bz.bzflag.bz) |
