| 00:19.28 | *** join/#brlcad Twingy (n=justin@74.92.144.217) | |
| 00:20.44 | IriX64 | why am I missing the lib that has XParseColor in it :( |
| 00:22.13 | IriX64 | have the H file but not the lib |
| 00:22.45 | Maloeran | Are you linking against libX11 ? |
| 00:22.52 | IriX64 | and bwish wants it sigh |
| 00:22.54 | IriX64 | yes |
| 00:23.15 | Maloeran | grep XParseColor /usr/lib/lib* |
| 00:23.23 | IriX64 | did nor there |
| 00:23.26 | IriX64 | not |
| 00:23.36 | IriX64 | oh wait |
| 00:23.59 | Maloeran | Compile with -lX11 , you really should have it |
| 00:25.09 | IriX64 | nothing in usr lib, i found the h in usr/X11R6 |
| 00:27.02 | IriX64 | ill try reinstalling x11 |
| 00:32.11 | IriX64 | heh or maybe ill force a link :) |
| 00:40.00 | ``Erik | if you can't find it in /usr/lib (or /lib, should be a link on cyggy), it won't link no matter what you do... |
| 01:02.57 | IriX64 | http://rafb.net/p/dnNdbM40.html <--- moving on whats this? |
| 01:34.30 | ``Erik | heh, looks like you pulled one of brlcad's gimpy mutilations to cope with broken libtools :D libbu is being linked twice |
| 01:40.17 | IriX64 | thanks :) |
| 01:41.11 | IriX64 | it happened again in remrt, same reason i presume :D |
| 01:43.14 | IriX64 | btw, mged uses that XParseColor thing too :( |
| 01:43.21 | brlcad | that's not what that is, it's saying there are two in two separate files |
| 01:43.51 | IriX64 | heh ``Erik spoke, I shut up :) |
| 01:44.19 | brlcad | and there actually are two bu_bomb() functions -- intentionally |
| 01:44.40 | IriX64 | why not just use the libbu one? |
| 01:44.51 | brlcad | what is odd is that it's erroring out on you instead of letting the one outscope the other like it normally does |
| 01:45.18 | IriX64 | man multiples are not allowed |
| 01:46.01 | brlcad | because lgt captures various call events (like bu_bomb) and does its own thing (namely in this instance flushes an image buffer |
| 01:46.33 | IriX64 | then it shouldnt be called the same |
| 01:47.00 | brlcad | it actually overrides the calls in routines that it doesn't have access to that you wouldn't want to rename |
| 01:47.08 | IriX64 | specially if your linking gainst a lib that has it already :) |
| 01:47.10 | brlcad | so it sorta needs to be called the same |
| 01:47.41 | brlcad | the real question is still why specifically is it error'ing |
| 01:48.03 | IriX64 | my compiler doesn't allow multiple definitions |
| 01:48.14 | brlcad | dude, you have no idea why it's happening |
| 01:48.15 | IriX64 | you can tell it to tho and i did |
| 01:48.22 | brlcad | you're just reading the message |
| 01:48.32 | IriX64 | ok |
| 01:48.44 | brlcad | that doesn't mean there isn't an option that allows it |
| 01:49.02 | IriX64 | see above |
| 01:49.10 | brlcad | or even that something else isn't provoking the error like a declaration mismatch |
| 01:49.37 | IriX64 | that would be reported seperatly |
| 01:49.48 | brlcad | not necessarily |
| 01:49.54 | IriX64 | redefinition of etc etc |
| 01:50.29 | brlcad | if it were redefined yes, but not if it was a mismatch |
| 01:50.39 | IriX64 | define mismatch |
| 01:50.47 | brlcad | one symbol's in a lib in an entirely separate compilation unit, and doesn't even necessarly pull in that header decl |
| 01:51.08 | IriX64 | don't understand |
| 01:51.30 | brlcad | I didn't really expect you to |
| 01:51.35 | IriX64 | ok |
| 01:52.41 | brlcad | this isn't really a productive conversation.. you can't debug that, and I don't have that environment set up to debug it for myself just yet |
| 01:53.16 | IriX64 | true |
| 01:53.26 | brlcad | last time I compiled on cygwin, it compiled fully and neither lgt nor bu_bomb() has changed since then |
| 01:53.41 | brlcad | so something else is still "up" and it just needs some dev attention |
| 01:53.59 | IriX64 | last time i compiled on cygwin nothing went right :) |
| 01:55.23 | brlcad | that seems to be usually the case, and will likely continue to be the case until someone that can trace through the issues has that environment set up |
| 01:55.51 | brlcad | I might be inclined to do that some weekend soon, but the website and other code matters are in line first |
| 01:56.02 | IriX64 | of course |
| 01:58.06 | brlcad | if you set up ssh access, I could be even more readily coerced to look into the build problems |
| 01:58.41 | IriX64 | ill think about it. |
| 02:09.50 | yukonbob | ?think about it -- the lead dev. is offering to fix your specific problem in the _actual_ problem environment |
| 02:15.47 | IriX64 | man this is a hobby for me |
| 02:23.37 | IriX64 | thats what i get for forcing a link, attach (nu|X) X =core dumped :) |
| 02:24.51 | IriX64 | well X is buggered here lets try ogl |
| 02:30.37 | IriX64 | i mean brlcad has better things to do with his time than babysit me yukonbob, thats all. |
| 02:31.12 | yukonbob | re: hobby -- so that means you don't mind if it doesn't work? |
| 02:31.21 | IriX64 | right :) |
| 02:31.33 | IriX64 | no production environment here |
| 02:31.37 | yukonbob | sounds like a frustrating hobby ;) |
| 02:31.45 | IriX64 | fun actually |
| 02:47.11 | louipc | haha |
| 02:56.48 | IriX64 | yukonbob, that also explains why there none of *my own models :) |
| 02:57.31 | IriX64 | brlcad gave me a paper moose, I didn't know where to begin |
| 02:57.46 | yukonbob | we're waiting... ;) Next havoc I see, I'm going to reach through the internet and take your modem away. |
| 02:58.03 | IriX64 | heh ill try cube ;) |
| 03:00.05 | IriX64 | meaning i'm just a block head :D |
| 03:14.56 | louipc | paper moose? |
| 03:21.22 | IriX64 | pix of one |
| 03:34.20 | *** join/#brlcad IriX64 (n=mariodot@bas2-sudbury98-1096600612.dsl.bell.ca) | |
| 03:34.32 | IriX64 | sigh :) |
| 03:35.46 | IriX64 | wonder if BitchX is more stable, or apropro here :) |
| 03:54.36 | IriX64 | nite all |
| 04:15.12 | CIA-4 | BRL-CAD: 03brlcad * 10brlcad/BUGS: |
| 04:15.12 | CIA-4 | BRL-CAD: nirt fails to report LOS and sometimes even hits on a BoT that is inverted or |
| 04:15.12 | CIA-4 | BRL-CAD: unoriented. most annoying is that just sometimes fails to report a hit while |
| 04:15.12 | CIA-4 | BRL-CAD: other times it just fails to report an LOS thickness, even though it does find a |
| 04:15.12 | CIA-4 | BRL-CAD: hit. |
| 04:20.22 | CIA-4 | BRL-CAD: 03brlcad * 10brlcad/BUGS: formatting |
| 05:21.49 | yukonbob | starseeker: re: openjade -- I don't think openjade require any form of TeX, but jadetex probably will -- lemme see if I can see what the deps are on my 'puter here... |
| 05:23.10 | yukonbob | Information for openjade-1.3.2nb5: |
| 05:23.11 | yukonbob | Built using: |
| 05:23.11 | yukonbob | opensp-1.5.2 |
| 05:23.11 | yukonbob | xmlcatmgr-2.2nb1 |
| 05:23.27 | yukonbob | Information for tex-jadetex-3.13nb5: |
| 05:23.28 | yukonbob | Built using: |
| 05:23.28 | yukonbob | tex-hugelatex-2.0nb4 |
| 05:23.28 | yukonbob | teTeX-bin-3.0nb14 |
| 05:23.28 | yukonbob | digest-20070803 |
| 05:23.50 | yukonbob | ... if you're using portage, that should take care of everything, though... |
| 07:25.38 | *** join/#brlcad Z80-Boy (n=clock@zux221-122-143.adsl.green.ch) | |
| 08:01.15 | *** join/#brlcad Elperion (n=Bary@p548771FA.dip.t-dialin.net) | |
| 09:45.14 | *** join/#brlcad elite01 (n=elite01@195.37.106.60) | |
| 12:57.41 | ``Erik | bahhh |
| 13:20.15 | brlcad | hummmbug |
| 13:23.31 | ``Erik | ahhhhh bumhug </beavis> |
| 13:24.34 | ``Erik | radmind stomping /Library/Tcl/macports1.0 is getting irritating... not nearly as irritating as stomping the parallels drivers, though. |
| 13:26.45 | Z80-Boy | Hmm, brl-cad produces .pix files where suddenly the lower part of the file is brighter |
| 13:26.53 | Z80-Boy | rt produces, to be more precise |
| 13:27.35 | ``Erik | ah, filenames are no longer part of ChangeLog? that was probably the most strusfrating part about that file :D |
| 13:28.11 | ``Erik | clock: pix-png and post? |
| 13:28.53 | Z80-Boy | Sure that's gonna happen |
| 13:29.12 | Z80-Boy | I am just trying to figure out if it's accidentally not triggered by stopping the rendering and then restarting it again. |
| 13:30.00 | ``Erik | ahhhhh, heh |
| 13:50.13 | *** join/#brlcad thing0 (n=ric@124-169-43-146.dyn.iinet.net.au) | |
| 14:14.40 | Z80-Boy | Then it is caused by breaking the raytrace and restarting it. |
| 14:15.10 | Z80-Boy | And now I realized it doesn't go from top to bottom, but from bottom to top |
| 14:15.16 | brlcad | that's curious, although not entirely surprising |
| 14:15.21 | Z80-Boy | so after the break, it doesn't render lighter, but darker |
| 14:15.31 | Z80-Boy | but why? |
| 14:15.36 | brlcad | it will try to continue a raytrace from the point that it left off at if there's data already partially written |
| 14:16.09 | brlcad | so it's continuing where it left off at instead of starting over (which was a big deal when the images took hours) |
| 14:16.20 | Z80-Boy | Actually it's more complicated |
| 14:16.35 | Z80-Boy | The unbroken images are all "dark" (= black background) |
| 14:17.12 | brlcad | but apparently from what youit's not picking up where it left off at .. probably due to resetting the image gamma or something |
| 14:17.36 | brlcad | is this in a framebuffer or to a file that you see the banding? |
| 14:18.21 | brlcad | mmmm.. the dual quad cores are more than twice as fast as wopr cpu-wise |
| 14:18.58 | brlcad | although still exceptionally slower with I/O .. compiling still takes 5-10 minutes (where on the altix it takes just 2-4 minutes) |
| 14:20.12 | brlcad | getting a vgr of about 12000 for a 12-processor altix .. which seems a bit lower than I recall, but that's with all of the bells and whistles turned on |
| 14:20.55 | brlcad | not using intel compiler, thought .. that might be what I'm remembering being about 17000 |
| 14:21.30 | brlcad | new mac workstations are coming up at 26000 for me, though .. freaking sweet |
| 14:23.58 | Z80-Boy | into a .pix file |
| 14:24.14 | Z80-Boy | don't know how to reproduce yet |
| 14:24.31 | Z80-Boy | faster than running a compile for a week and rebooting the machine at random intervals |
| 15:05.10 | *** join/#brlcad thing1 (n=ric@124-169-43-146.dyn.iinet.net.au) | |
| 15:10.05 | *** join/#brlcad elite01 (n=elite01@dslb-088-070-024-077.pools.arcor-ip.net) | |
| 15:55.45 | *** join/#brlcad CIA-4 (n=CIA@208.69.182.149) | |
| 16:08.30 | *** part/#brlcad thing1 (n=ric@124-169-43-146.dyn.iinet.net.au) | |
| 17:34.20 | ``Erik | http://www.bah3.org/main/index.html is amusing |
| 17:35.18 | ``Erik | 4-6 miles in 60-90 minutes with several beer stops... I think Ic ould do that O.o |
| 17:40.09 | ``Erik | "a drinking club with a running problem" |
| 18:25.16 | brlcad | mmm.. tcl 8.4b1 is now (really) posted |
| 18:26.23 | ``Erik | 8.5b1 ? |
| 18:27.08 | brlcad | er, yeah |
| 18:32.18 | *** join/#brlcad Z80-Boy (i=clock@77-56-72-172.dclient.hispeed.ch) | |
| 18:32.54 | brlcad | <PROTECTED> |
| 18:33.03 | Z80-Boy | I found and analyzed the bug with "half of the picture bright" |
| 18:33.15 | Z80-Boy | It happens only when -c "set gamma=2.2" is present. |
| 18:33.26 | brlcad | i figured it was gamma-related |
| 18:33.36 | Z80-Boy | It loads the gamma-corrected values into a buffer, then gamma-corrects them again and spits them out |
| 18:33.47 | Z80-Boy | if you break it multiple times, you get a "gradient" effect |
| 18:33.49 | brlcad | so is it basically not setting/using the gamma or are exising new values being overcorrected? |
| 18:34.06 | Z80-Boy | overcorrected |
| 18:34.06 | brlcad | ah, so overcorrects |
| 18:34.32 | Z80-Boy | I think it should make sure the already computed values should be spitted out as they are |
| 18:34.44 | Z80-Boy | But worse what I saw in the source I wasn't happy |
| 18:35.09 | brlcad | we could also just get rid of all that "restart" code |
| 18:35.20 | Z80-Boy | 1) it seems to never output 0,0,0. That's wrong. If 0,0,0 is in the scene (real black), I want real black and no distorted picture in the form of deep blue! |
| 18:35.27 | ``Erik | brlcad: /opt/ is ignored by radmind, but macports installs some stuff to /Library/Tcl/macports1.0 which gets stomped... but the stuff I'm messing with pertains to nice levels and number of concurrent jobs... |
| 18:35.30 | Z80-Boy | 2) similarly it refused to output the background colour |
| 18:35.45 | Z80-Boy | 3) some kind of random noise seems to be added into the image and being bravely called "dithering" |
| 18:36.06 | Z80-Boy | Dithering is when you use spectral noise shaping - you need to use error distribution |
| 18:36.12 | Z80-Boy | This is just adding noise into signal |
| 18:36.37 | Z80-Boy | I am also not sure if the values are properly rounded after gamma correction |
| 18:36.59 | Z80-Boy | I wouldn't mind getting rid of the restart code |
| 18:37.08 | Z80-Boy | Since the idea of inband signalling is braindead |
| 18:37.25 | Z80-Boy | Either mark "empty pixels" by their position beyond the end of file |
| 18:37.33 | brlcad | outputting 0,0,1 goes into deep history and there's fairly good reasons for why it was done that way (regardless of whether there are other ways this could be achieved today) |
| 18:37.50 | ``Erik | it's one of those "nifty features for 20 year old machines, but causes ugly issues" type things :/ |
| 18:38.11 | Z80-Boy | What's the reason for not outputting 0,0,0? |
| 18:38.14 | brlcad | 0,0,1 can't really be changed until 8.0 |
| 18:38.26 | Z80-Boy | I always wondered why my videos are not on black background but on something dark |
| 18:38.26 | ``Erik | yeah, ti'd break the pix files :( |
| 18:38.41 | brlcad | it's break tons of stuff |
| 18:38.42 | Z80-Boy | What does it mean break pix files? |
| 18:38.47 | Z80-Boy | ZOMG |
| 18:38.53 | brlcad | Z80-Boy: there is no alpha channel |
| 18:39.00 | Z80-Boy | and? |
| 18:39.10 | ``Erik | is there a reason for 0x1 as black other than restart? |
| 18:39.22 | brlcad | the designated "background color" for which 0,0,1 is simply the default effectively acts like an alpha channel mask without requiring the additional bandwidth |
| 18:39.54 | ``Erik | the pix files are used in the distribution to verify correct results when running the benchmark suite... if we change the nacent 'black' color, we'll get many many 'off-by-one' errors :) |
| 18:40.11 | brlcad | that channel "mask" is used all over the place, particularly in the framebuffer library but in loads of the tools as well, for detecting background vs non-background |
| 18:40.40 | Z80-Boy | lol it's all a crappy inband signalling design |
| 18:40.46 | Z80-Boy | which actually corrupts the signal |
| 18:40.47 | ``Erik | heh, :( magic colors can induce error |
| 18:40.56 | Z80-Boy | sorry, your TV cannot show black, we used black as a special value |
| 18:41.13 | brlcad | that's why it's not black actually |
| 18:41.15 | Z80-Boy | PCX could encode black |
| 18:41.27 | brlcad | as black is frequently requested |
| 18:41.36 | Z80-Boy | brlcad: what value is it then? 0,0,1? |
| 18:41.39 | ``Erik | yes, but PCX kept a magic color, and you had to make sure you never tried to use that magic color for a legitimate pixel |
| 18:42.12 | ``Erik | (that and the 256 color palette, ick) |
| 18:42.25 | Z80-Boy | I think it could encode all possible value |
| 18:42.44 | ``Erik | and ugly rle that could blow up your image size significantly if you gave it unfriendly data, like a horizontal gradient... |
| 18:42.44 | Z80-Boy | if it had a RLE escape, then the RLE escape was encoded as double escape or something like that |
| 18:43.48 | Z80-Boy | The gamma correction is also calculated as a separate pow() for each pixel |
| 18:44.14 | Z80-Boy | 995328 pows for my frame... isn't that slowing down? |
| 18:44.23 | Z80-Boy | I did it with a 16-bit table in links. |
| 18:45.28 | brlcad | Z80-Boy: 0,0,1 is merely the *default* background color |
| 18:45.35 | brlcad | you can still output black |
| 18:45.39 | Z80-Boy | so the "empty value" is 0,0,1? |
| 18:45.44 | brlcad | or 0,0,1 if you like |
| 18:45.45 | Z80-Boy | And can I also output 0,0,1? |
| 18:46.05 | Z80-Boy | and can I output all possible colours with a single background colour setting? |
| 18:46.06 | brlcad | of course you can |
| 18:46.17 | Z80-Boy | then it's not what I thought it is |
| 18:46.30 | brlcad | are you just looking for something to bitch about because you misinterpreted something you read in the code? :) |
| 18:46.32 | Z80-Boy | But what is this piece of code then? |
| 18:46.33 | Z80-Boy | <PROTECTED> |
| 18:46.33 | Z80-Boy | <PROTECTED> |
| 18:46.33 | Z80-Boy | <PROTECTED> |
| 18:47.03 | brlcad | make sure the *default* background color is never perfect black |
| 18:47.19 | Z80-Boy | but this is in view_pixel |
| 18:47.38 | Z80-Boy | r, g, b is actually the pixel value - the signal, the payload... |
| 18:47.50 | ``Erik | athat only happens if the ray never intersects, I think |
| 18:48.28 | Z80-Boy | no it happens if ap->a_user != 0 |
| 18:48.35 | brlcad | as for pow() .. show me a profile that shows that's a problem |
| 18:48.40 | Z80-Boy | and ap->a_user == 0 has comment "/* Shot missed the model, don't dither */" |
| 18:49.11 | brlcad | pow() is accurate, tables aren't necessarily -- and the raytrace is vastly dominated by the ray-tracing, not pixel operations |
| 18:49.26 | Z80-Boy | brlcad: accurate, but slow |
| 18:49.35 | brlcad | slow within a given context |
| 18:49.47 | ``Erik | pretty fast if you have optimization on certain chips |
| 18:49.50 | brlcad | if it's 0.3% of your computation time, who cares |
| 18:49.52 | Z80-Boy | but you're right, it mosly chokes on the threads |
| 18:50.02 | Z80-Boy | ``Erik: which chips? |
| 18:50.19 | brlcad | i'll take accurate over fast any day if there's not an order of magnitude performance difference |
| 18:50.28 | ``Erik | like, uh, opterons, athlons, p4's, ... |
| 18:50.35 | *** mode/#brlcad [+o minute] by ChanServ | |
| 18:50.52 | ``Erik | 3dnow and I think sse2+ have approximation fu on that? |
| 18:51.09 | ``Erik | and -ffast-math in gcc hopefully takes advantage of that |
| 18:51.24 | brlcad | either way, that's the whole point of profiling .. you're totally guessing as to the performance, speculative optimization is rarely useful |
| 18:51.27 | Z80-Boy | -fdodgy-math :) |
| 18:52.27 | brlcad | about as helpful as believing in the "gotos are bad" as an absolute -- they're bad in a given context but not always, same goes for just about every one absolute |
| 18:52.30 | ``Erik | yes, -ffast-math accepts some error in the name of speed... is also ignores a good bit of IEEE754/854, like appropriate handling of Inf and NaN |
| 18:52.45 | Z80-Boy | is there a standard in C saying how floats are cast into int, whether they are chopped down, up, or rounded? |
| 18:52.55 | ``Erik | not in C |
| 18:53.02 | *** join/#brlcad MinuteElectron (n=MinuteEl@bz.bzflag.bz) | |
| 18:53.07 | ``Erik | but there is in ieee754, and it's... skeery. |
| 18:53.09 | Z80-Boy | then why are you doing register int r=pow()? |
| 18:53.18 | Z80-Boy | shouldn't it be floor(pow()+0.5)? |
| 18:53.48 | Z80-Boy | that floor and 0.5 is inexpensive compared to that pow. |
| 18:53.53 | Maloeran | roundf() which is C99 |
| 18:53.57 | ``Erik | <-- uses floor(), too *shrug* |
| 18:54.36 | Z80-Boy | I always wondered why there are "flashes" in the Ronja video |
| 18:54.51 | Z80-Boy | It was because it takes so long to render I have to break it and then reboot |
| 18:54.59 | ``Erik | heh |
| 18:54.59 | Z80-Boy | every time I broke it, I got a flash... |
| 18:55.15 | brlcad | probably just an oversight on the pow cast |
| 18:55.40 | brlcad | or just has never mattered sufficiently |
| 18:56.23 | Z80-Boy | it usually goes into YUV encoding anyway and that's such unbelievable crap that it can hide anything I guss |
| 18:57.22 | brlcad | I'd give you commit to make some of these changes, but you couldn't go breaking backwards compatibility so readily with things like the background color |
| 18:57.40 | Z80-Boy | no don't give me commit it's better if a knowledgeable person revides that first |
| 18:57.56 | ``Erik | heh |
| 18:58.05 | Z80-Boy | I would quickly make a surfboard hut from your code |
| 18:58.12 | brlcad | it'd still be revised .. I'd envision several reverts too :) |
| 18:58.17 | ``Erik | well, feel free to use the 'patches' tracker, someone will review and comment on it ... eventually... |
| 18:58.30 | Z80-Boy | or I can patch it myself and keep it ;-) |
| 18:58.37 | brlcad | that you can |
| 18:58.51 | ``Erik | as long as the license is respected, it's all good :) |
| 18:58.51 | Z80-Boy | <PROTECTED> |
| 18:59.00 | Z80-Boy | <PROTECTED> |
| 18:59.36 | *** join/#brlcad minute_ (n=MinuteEl@bz.bzflag.bz) | |
| 18:59.36 | Z80-Boy | I guess povray and other "competing" (not really ;-) ) systems don't do this in-band signalling data damage |
| 18:59.47 | Z80-Boy | btw povray is triangle-only? |
| 18:59.54 | ``Erik | no, povray is CSG with implicites |
| 19:00.02 | Z80-Boy | implicite== ? |
| 19:00.05 | ``Erik | but it outputs BMP iirc? |
| 19:00.09 | Z80-Boy | OMG |
| 19:00.17 | Z80-Boy | better than Microsoft Word, though |
| 19:00.33 | ``Erik | heh |
| 19:00.34 | ``Erik | hehehe |
| 19:00.37 | ``Erik | mwahahahhahahahaa |
| 19:00.48 | ``Erik | a raytracer that outputs to excel... with each 'pixel' being a colored cell :D |
| 19:00.54 | Z80-Boy | lol |
| 19:00.56 | Z80-Boy | ex-cell |
| 19:01.40 | ``Erik | 'cept the moment you wnat more than, say, 80x25 renders, it crashes! |
| 19:01.53 | Z80-Boy | can BRL-CAD render into aalib? |
| 19:01.55 | ``Erik | also; white isn't really white, it's 100,000, or SUPER-white |
| 19:01.56 | ``Erik | O.o |
| 19:02.01 | Z80-Boy | or better libcaca? |
| 19:02.13 | Z80-Boy | ``Erik: you mean the 77.1*85 stuff? |
| 19:02.16 | ``Erik | no, but you can pix-png and push that through something that talks aalib |
| 19:02.27 | ``Erik | yeah, z80, 65536 = 100000 |
| 19:02.29 | Z80-Boy | or play the video on aalib mplayer... |
| 19:02.38 | Z80-Boy | ``Erik: where is the news? |
| 19:02.44 | ``Erik | erm, slashdot? |
| 19:02.54 | Z80-Boy | You know Windows Vista have to differ in something from XP - otherwise people wouldn't buy it |
| 19:03.06 | Z80-Boy | So they differ in the math - give BIGGER, BETTER results! |
| 19:03.09 | ``Erik | 65535 or 65536? O.o (and this was excel 2007, not windows) |
| 19:03.17 | Z80-Boy | With Vista, your company accounting will shine suddenly in black numbers! |
| 19:03.21 | CIA-4 | BRL-CAD: 03brlcad * 10brlcad/src/rt/view.c: patch/suggestion from Z80-Boy, round the gamma-corrected values to the nearest int consistently using floor() |
| 19:03.27 | Z80-Boy | They don't have Excel yet in the kernel? |
| 19:03.38 | ``Erik | no difference to your vgr's, I presume? |
| 19:03.54 | brlcad | Z80-Boy: if you need clean signal data, have rt output floating point images instead |
| 19:04.05 | brlcad | that's probably as raw as it gets |
| 19:04.10 | Z80-Boy | raw meat |
| 19:04.19 | Z80-Boy | then I can get HDR lol |
| 19:04.23 | Z80-Boy | which format is that? |
| 19:04.24 | ``Erik | heh, yeah, 's/clock/Karel/g;s/Z80-Boy/Karel/g;s/whineybitch/Karel/g;s/...' |
| 19:04.27 | ``Erik | *cough* O:-) |
| 19:04.42 | brlcad | which format? |
| 19:04.46 | brlcad | it's raw floating point data |
| 19:04.49 | ``Erik | or, uh, 's/clock\|Z80-Boy\|whineybitch/Karel/g' |
| 19:04.55 | Z80-Boy | well pix is 8-bit, which format is floating point? |
| 19:05.21 | brlcad | double-precision floating point values, network ordered, iirc |
| 19:05.33 | Z80-Boy | into the output file? |
| 19:05.46 | ``Erik | http://sourceforge.net/tracker/?group_id=105292&atid=640804 <-- and that's enough to mkae it not crap? O.o |
| 19:06.27 | Z80-Boy | ``Erik: maybe not anymore, after I "whined" ;-) |
| 19:06.40 | brlcad | manure makes excellent fertilizer |
| 19:06.54 | Z80-Boy | Does it mean the arbn mirroring bug is already fixed? |
| 19:07.33 | Z80-Boy | Being crap actually doesn't mean a project is bad |
| 19:07.54 | Z80-Boy | If the developers fix it, like in BRL-CAD they do very quickly, it doesn't matter |
| 19:08.04 | brlcad | the "problem" is that it's massive, so you don't have to look far to find an issue .. the rate of issues per lines of code isn't likely any more or less than most other projects |
| 19:08.12 | Z80-Boy | It booms? No prob, you "whine" or "bitch" (actually bugreport), they fix it, there we go... |
| 19:08.21 | Z80-Boy | massive and oldskool :) |
| 19:08.35 | brlcad | and just a lot of the issues .. really don't matter -- it's like making sure there are no cobwebs in the basement .. when you never/rarely ever go into the basement |
| 19:09.33 | brlcad | the last time someone needed "actual" gamma correction was a decade ago, and they were going to PAL, so it really didn't matter more than needing to make sure the colors were consistent in intensity |
| 19:09.36 | Z80-Boy | make ctags? |
| 19:09.48 | brlcad | make tags |
| 19:09.53 | Z80-Boy | well gamma correction is good to make sure you don't get Mach bands in 8-bit data |
| 19:09.59 | Z80-Boy | tags make etags which I don't use |
| 19:10.11 | brlcad | but you should be :) |
| 19:10.12 | Z80-Boy | brlcad: you know the TV theory? |
| 19:10.16 | brlcad | etags are so much better |
| 19:10.21 | Z80-Boy | do they work in vim? |
| 19:10.34 | brlcad | like i said.. they're better, so of course not ;) |
| 19:10.40 | brlcad | actually I have no idea |
| 19:10.52 | brlcad | wouldn't be surprised either way if there was a vim module for it |
| 19:11.14 | brlcad | etags are just a lot better at tagging, fixed a lot of problems in ctags |
| 19:11.19 | Z80-Boy | could be |
| 19:11.27 | Z80-Boy | never tried etags actually |
| 19:11.37 | brlcad | even etags gets tons of things outright wrong in a code like brl-cad |
| 19:11.57 | Z80-Boy | no wonder |
| 19:12.25 | brlcad | Z80-Boy: do you still need/want the sleep option, now that you know how to linger a window? |
| 19:12.56 | Z80-Boy | brlcad: with the linger I have to right click |
| 19:13.06 | Z80-Boy | With sleep I don't need |
| 19:13.20 | Z80-Boy | it could be used in a slow-motion script so that people can check if their video doesn't contain any glitches |
| 19:13.23 | Z80-Boy | with -p 1 |
| 19:13.36 | Z80-Boy | When the patch is already here... |
| 19:13.51 | brlcad | i do too, just trying to see how useful |
| 19:14.10 | brlcad | can't be too much crap, it's just like 4 lines |
| 19:14.25 | Z80-Boy | max. 4 lines can be crappy |
| 19:14.31 | Z80-Boy | plus the manpage patch. |
| 19:14.40 | Z80-Boy | Outsider patches are mostly crap |
| 19:14.40 | brlcad | the bigger issue is that of feature creep consistency, if it's going to be added, it should probably be on all the tracers |
| 19:14.47 | Z80-Boy | L0CALZ 0NLY! |
| 19:15.18 | Z80-Boy | tracer == ? |
| 19:15.28 | Z80-Boy | well then don't add it |
| 19:15.29 | brlcad | ray-tracers |
| 19:15.42 | ``Erik | that's just opt.c, no? |
| 19:15.42 | Z80-Boy | is pix-fb a raytracer? |
| 19:15.43 | brlcad | the ones that output to framebuffer at least |
| 19:15.54 | ``Erik | no, pix-fb is a weirdassed converter O.o |
| 19:15.54 | Z80-Boy | Then better not add it |
| 19:16.03 | Z80-Boy | My patch was for pix-fb |
| 19:16.26 | Z80-Boy | brlcad: floating point files will be huge on the disk |
| 19:16.33 | Z80-Boy | brlcad: I think 8-bit 2.2 gamma files are fine |
| 19:16.55 | Z80-Boy | My 2Y'CbCr converter takes that input format anyway |
| 19:17.06 | Z80-Boy | It's much better quality that what you get from common video formats anyway |
| 19:17.13 | ``Erik | erm, only 8x the size of a pix... |
| 19:17.36 | Z80-Boy | I think the clipping should be done in floating point and not in int |
| 19:17.53 | Z80-Boy | if you get some extreme light concentration from the raytrcing (lens)? you could get black spots |
| 19:18.03 | Z80-Boy | "only" |
| 19:18.20 | brlcad | sounds good to me, I'm not positive the dpix output was ever fully implemented myself *grin* |
| 19:19.41 | Z80-Boy | did you see Surf's Up? |
| 19:19.48 | Z80-Boy | It's a fully rendered film about surfing penguins |
| 19:20.06 | brlcad | not yet |
| 19:20.07 | Z80-Boy | they have the waves quite good except two things: |
| 19:20.20 | Z80-Boy | 1) the penguin gets a stable ride at high speed which he I guess shouldn't |
| 19:20.38 | Z80-Boy | 2) they didn't bother with calculating the waves spreading from the surfboard |
| 19:21.04 | Z80-Boy | also maybe 3) the waves turn up to be suspiciously perfect |
| 19:21.25 | Z80-Boy | But that wasn't rendered in brl-cad, I guess |
| 19:22.22 | Z80-Boy | I wonder what wavelet.c is used for, it sounds interesting. |
| 19:22.55 | Z80-Boy | <PROTECTED> |
| 19:22.55 | Z80-Boy | <PROTECTED> |
| 19:22.55 | Z80-Boy | <PROTECTED> |
| 19:23.04 | Z80-Boy | Did you try wavelet compression of the output data? |
| 19:23.58 | Z80-Boy | C. S. Morrison everywhere ;-) |
| 19:24.44 | Z80-Boy | ah no that's special thanks |
| 19:26.03 | brlcad | a few more signficant patches bumps that up to code contributions, a *whole* lot more and you'd be up in the dev category |
| 19:26.20 | brlcad | haar wavelet transforms are awesome |
| 19:26.33 | Z80-Boy | yeah it's like mipmaps |
| 19:26.42 | brlcad | kind of |
| 19:26.54 | ``Erik | [[1 1][1 -1]] O.o heh |
| 19:26.55 | brlcad | a great way to manipulate signal data |
| 19:26.57 | Z80-Boy | I once wrote a wavelet preprocessor for lossless sound compression |
| 19:27.45 | brlcad | perform decomposition all the way down, do a low pass filter, then reconstruct .. beautiful noise reduction |
| 19:27.50 | ``Erik | erm, but if it's digital sound, it's already lossy :D *duck* |
| 19:27.56 | brlcad | and great compression characteristics |
| 19:28.07 | Z80-Boy | brlcad: low pass the highest band? |
| 19:29.17 | brlcad | it's not used anywhere, it's one of a hundred or so standalone signal processing tools |
| 19:29.48 | brlcad | if you see noise in the trace, it's caused by tracer options or the geometry |
| 19:30.03 | brlcad | (usually) |
| 19:30.30 | brlcad | e.g. using jitter and not understanding what it means to rt |
| 19:31.08 | brlcad | bbiab |
| 19:32.09 | ``Erik | hehehe, -j2 -h0 :o |
| 19:39.34 | Z80-Boy | Is there a simple way how to disable the restart code correctly? |
| 19:39.44 | ``Erik | um |
| 19:39.47 | ``Erik | in uhhhhh view.c |
| 19:39.59 | Z80-Boy | I'm still not getting how it works |
| 19:40.15 | ``Erik | line, um |
| 19:40.18 | ``Erik | 1410ish |
| 19:40.28 | ``Erik | change HAVE_UNIX_IO to 0 |
| 19:40.31 | ``Erik | that should do it |
| 19:40.36 | Z80-Boy | lol :) |
| 19:40.43 | ``Erik | not quite 'correctly', but it should work |
| 19:41.13 | ``Erik | well |
| 19:41.35 | Z80-Boy | sure, it makes sense |
| 19:41.48 | ``Erik | pretty much every machine these days has unix i/o... |
| 19:42.25 | ``Erik | and that should go away, oh, next week when I get around to it :) |
| 19:42.58 | Z80-Boy | view.c:211: error: syntax error before '<<' token |
| 19:43.07 | Z80-Boy | lol, Z80-Boy did a blind cvs-update |
| 19:43.19 | ``Erik | the basic premise of how it works is probably ... not quite right... I might make it pre-fill the image to make sure there's space to write to :/ |
| 19:43.33 | ``Erik | yes, <<<<<<<<<<<< confuses C |
| 19:43.36 | Z80-Boy | I see brlcad is very fast |
| 19:43.52 | ``Erik | ? |
| 19:44.05 | Z80-Boy | he already added the floor(pow()+0.5) |
| 19:44.15 | ``Erik | oh yeah, almost an hour ago |
| 19:44.26 | ``Erik | CIA-4 reported it... |
| 19:44.49 | ``Erik | should I give you my order? |
| 19:45.02 | Z80-Boy | order? |
| 19:45.11 | ``Erik | you're making enough food for everyone, right? |
| 19:45.16 | Z80-Boy | no |
| 19:45.22 | Z80-Boy | it's too far away for you |
| 19:45.46 | Z80-Boy | unless you send Air Force One for it of course... |
| 19:46.23 | ``Erik | heh, air farce one? O.o I don't even qualify to ride cattle on a commercial flight |
| 19:46.48 | Z80-Boy | farce lol |
| 19:46.52 | Z80-Boy | ../../src/libdm/.libs/libdm.so.19.1: undefined reference to `ogl_fogHint' |
| 19:46.57 | Z80-Boy | Do I need to rerun autogen.sh now? |
| 19:47.03 | Z80-Boy | or configure? |
| 19:47.07 | ``Erik | um, gnumake shoulda done that for you |
| 19:47.19 | ``Erik | try, uh, make clean in libdm and rebuild? |
| 19:47.35 | ``Erik | apparently I had some slop in my modification to configure.ac that brlcad fixed |
| 19:48.44 | Z80-Boy | so now if I break it in the middle of the pixfile it will just overwrite it? |
| 19:48.58 | ``Erik | should |
| 19:49.07 | ``Erik | if it doesn't, I'll look into it... |
| 19:49.19 | ``Erik | SHOULD be working on a, uh, document, though. |
| 19:49.35 | Z80-Boy | I need a quick hack to produce correct videos for Ronja within that week you plan to shoot it off definitely after |
| 19:51.31 | Z80-Boy | have you heard about pcc? |
| 19:52.06 | Z80-Boy | They want to put it into OpenBSD |
| 19:52.14 | Z80-Boy | It was written in mid 70's! |
| 19:52.23 | Z80-Boy | Even a bit more oldschool than BRL-CAD! |
| 19:52.35 | Z80-Boy | brl-cad compiled successfully |
| 19:53.41 | ``Erik | yes, ummm |
| 19:53.46 | ``Erik | netbsd did it, too, I think |
| 19:53.53 | ``Erik | it's less gnu-ey than gcc |
| 19:54.16 | ``Erik | and fbsd has an annual 'replace gcc with tendra' trollfest |
| 19:54.38 | Z80-Boy | but now what happens if I say have 50 frames computer from 360 and I break it and run again |
| 19:54.44 | Z80-Boy | will 50 frames be skipped? |
| 19:56.07 | ``Erik | it SHOULD just disable the continuation of that one frame, and start that frame over |
| 19:56.28 | Z80-Boy | so complete frames will be skipped, and incomplete recalculated? |
| 19:56.38 | ``Erik | I think so |
| 19:56.57 | Z80-Boy | Otherwise I need to calculate into a separate file and then do an atomic mv by the script |
| 19:57.33 | Z80-Boy | can the rt output color according to how long it took to calculate given ray? |
| 19:58.18 | ``Erik | no |
| 19:59.16 | Z80-Boy | what other tricks it can do apart from rt and rtedge? |
| 19:59.41 | Z80-Boy | rtxray lol :) |
| 20:00.05 | Z80-Boy | rtweight too... |
| 20:00.42 | Z80-Boy | wow, it really skips the complete file :) |
| 20:01.44 | Z80-Boy | but it still does the same problem :( |
| 20:02.26 | Z80-Boy | oh no, that's because I forgot make install! |
| 20:19.19 | Z80-Boy | Hmm make install didn't help :( |
| 20:19.47 | yukonbob | ``Erik: netbsd is working/playing w/ pcc, yes. |
| 20:53.18 | Z80-Boy | It's about as good idea as making it from asbestos |
| 20:53.25 | Z80-Boy | people coughing blood will sue the ass out of you |
| 21:08.15 | *** join/#brlcad elite01 (n=elite01@dslb-088-070-024-077.pools.arcor-ip.net) | |
| 21:08.22 | brlcad | some of the HAVE_UNIX_IO sections don't work without modification on Windows, that's why they've not yet been removed .. needs some interactive love'n'care'n'testing else they'll just turn into !_WIN32 sections |
| 21:13.10 | CIA-4 | BRL-CAD: 03erikgreenwald 07STABLE * 10brlcad/src/mged/clone.c: merge of V5 implementation from HEAD |
| 21:17.33 | ``Erik | ooh, a b ig one O.o |
| 21:45.46 | ``Erik | *yawn* |
| 22:35.38 | *** join/#brlcad thing0 (n=ric@124-169-43-146.dyn.iinet.net.au) | |
| 22:36.50 | CIA-4 | BRL-CAD: 03brlcad * 10brlcad/src/mged/tedit.c: only report the basename of the editor |
| 23:54.58 | *** join/#brlcad Twingy (n=justin@74.92.144.217) | |