| 00:00.56 | ``Erik | that'd probably be a good "jr hacker" task |
| 00:10.22 | ``Erik | holy crap, that thing is pigging the corners bad |
| 00:10.28 | ``Erik | c55 amg on top gear |
| 00:10.56 | ``Erik | heh |
| 00:11.04 | ``Erik | it lost a cornering drive to a 'vette |
| 00:12.49 | ``Erik | way behind bmw, porsche, lotus, even mitsubishi :D |
| 00:22.16 | Ralith | is it possible to get antialiasing out of the brlcad renderers? |
| 00:23.01 | brlcad | it's performed at a ray-cast level, jittering, so probably not what you'd expect for antialiasing |
| 00:23.19 | brlcad | even though it is an antialiasing approach and will eliminate aliasing artifaces |
| 00:23.44 | brlcad | usually you'll want to render at 2x-4x and scale down, though, for clean image-space anti-aliasing |
| 00:24.10 | Ralith | I guess that's one way to do it. |
| 00:27.57 | brlcad | the results will usually be better in a super-sampled image space than what you can do in a sub-sampled ray-space |
| 00:29.01 | brlcad | Ralith: if you find a way to reproduce the vertical rect, lemme know .. never seen that |
| 00:29.19 | Ralith | I'll see what I can do |
| 00:29.24 | Ralith | it's pretty unpredictable, though |
| 00:34.00 | ``Erik | much more info would be needed for that |
| 00:34.37 | ``Erik | rt's antialiasing involves the -h (hypersample) and -J (jitter) flags being used in conjunction, basically shoot a bunch of rays per pixel with random minor mutations and the results averaged |
| 00:35.25 | ``Erik | -J3 is both cell and frame jitter, and -h takes the # of rays to fire, I haven't noticed any appreciable difference between ~7 and "more" |
| 00:35.39 | ``Erik | though sometimes I do a lot more to do profiling :) |
| 00:36.07 | ``Erik | hasn't really messed with shooting a big one and downscaling |
| 00:36.38 | Ralith | ``Erik: -h 5 -J3 gets me a white silhouette |
| 00:37.02 | ``Erik | woops |
| 00:37.03 | ``Erik | -H |
| 00:37.33 | ``Erik | -h is distance attenuation shtuff |
| 00:37.41 | ``Erik | like, uh, opengl style 'fog' |
| 00:37.47 | pacman87 | i think i forgot something: |
| 00:37.47 | pacman87 | warning: incompatible implicit declaration of built-in function 'fmin' |
| 00:37.50 | Ralith | hm. slows down things a lot and mostly just fuzzes the edges |
| 00:38.06 | Ralith | are standard antialiasing techniques inapplicable? |
| 00:38.12 | ``Erik | pacman: math.h ? |
| 00:38.23 | pacman87 | it's there |
| 00:38.27 | ``Erik | which "standard" antialiasing techniques? |
| 00:39.07 | ``Erik | opengl and d3d use a "magic set" approach published in a paper I believe out of nvidia for edge hits |
| 00:41.22 | Ralith | that works. |
| 00:41.31 | Ralith | is it inapplicable? |
| 00:41.49 | ``Erik | I imagine not, but it's highly recent compared to the existing approach |
| 00:41.53 | ``Erik | feel free to implement it :D |
| 00:42.00 | Ralith | hehe |
| 00:42.05 | Ralith | if I were a graphics programmer :P |
| 00:42.29 | ``Erik | I imagine being a graphics programmer is irrelevant, it'd be a hard coded pattern opposed to a random set of tweaks |
| 00:43.14 | Ralith | yeah, but I don't have enough background to even know where to begin. |
| 00:43.18 | ``Erik | whoever did the paper basically went through a series of possibly layouts until they came across the one that seemed the "best" for the least number of rasterizations |
| 00:43.23 | Ralith | let alone how to adapt something from opengl to brl-cad. |
| 00:43.59 | ``Erik | well, the paper, iirc, basically boils down to 7 points in a square |
| 00:44.16 | ``Erik | so instead of doing N random pertubations to rays, just assume those 7... |
| 00:44.19 | ``Erik | or 5 or whatever |
| 00:45.13 | ``Erik | finding the paper with the magic #'s would be the harder aspect, I'd imagine |
| 00:45.30 | ``Erik | but don't listen to me, I've been looking at lisp code, so I've been getting liquored up ;) |
| 00:45.35 | Ralith | heh |
| 00:45.47 | pacman87 | testing the balmer peak? |
| 00:45.49 | Ralith | raytracing isn't how opengl/d3d do things at all, though |
| 00:45.52 | Ralith | it's that directly mappable? |
| 00:46.08 | ``Erik | no, ogl and d3d are rasterized approaches |
| 00:46.13 | ``Erik | but I think the notion is mappable |
| 00:46.33 | Ralith | isn't even sure how a rasterized renderer differes from a raytracer |
| 00:46.40 | ``Erik | I haven't jumped around screaming "developers" over and over, nor have I launched chairs or sworn to "fucking kill" anyone |
| 00:46.41 | Ralith | other than that the latter seems to be very slow. |
| 00:46.46 | ``Erik | so, no, not on the ballmer track |
| 00:46.49 | Ralith | ``Erik: it's an xkcd reference |
| 00:46.58 | ``Erik | ohhhh |
| 00:47.02 | ``Erik | balmer, not ballmer |
| 00:47.02 | ``Erik | heh |
| 00:47.05 | pacman87 | http://xkcd.com/323/ |
| 00:47.09 | ``Erik | I think I'm beyond the productivity spike |
| 00:47.21 | ``Erik | sorry, I'm disadvantaged. :) |
| 00:47.41 | ``Erik | once ralith said xkcd, it clicked... :D |
| 00:47.57 | ``Erik | I do like how foxtrot included xkcd in their latest quip |
| 00:48.11 | pacman87 | yeah, i saw that |
| 00:48.28 | ``Erik | http://euler.missouristate.edu/~erik/comics/comic.php <-- web app he wrote to deal with those damn webcomics |
| 00:48.59 | ``Erik | and since I like high resolutions and big fonts, clicking an image zooms it, pheer javascript O.o |
| 01:07.38 | starseeker | brlcad: difference is that volume three was generated from docbook sources - like the earlier volume II example |
| 01:08.11 | starseeker | brlcad: As for the images, I had originally captured them at the highest resolution I could, simply to ensure I preserved the detail present in the originals |
| 01:08.30 | starseeker | If you're referring to the second tank image, I believe the pixelation there is present in the original |
| 01:09.43 | starseeker | I need to downsize the images anyway for pdf, so thinks will look better - I was simply ensuring that at least the svn history had the full image data |
| 01:12.09 | brlcad | if -j + -H simply averaged the cell results, it would look a hell of a lot better |
| 01:12.44 | brlcad | that's a viewend() post-processing hook that wouldn't be too hard to code up |
| 01:13.40 | brlcad | starseeker: the big ones aren't nearly as much of a concern as the under-res ones :) |
| 01:13.51 | brlcad | you can down-sample, upsampling sucks |
| 01:28.04 | pacman87 | primitives/revolve/revolve.c:176: warning: incompatible implicit declaration of built-in function 'fmax' |
| 01:28.29 | pacman87 | what am i missing? |
| 01:34.39 | ``Erik | perhaps a -lm ? |
| 01:34.58 | ``Erik | well, that error says it's not seeing the prototype in the header, though |
| 01:35.10 | ``Erik | "man fmax" and include the correct header O.o |
| 01:35.49 | pacman87 | says math.h |
| 01:36.10 | pacman87 | is fastf_t considered a float? |
| 01:36.28 | brlcad | not usually, but could be |
| 01:36.33 | ``Erik | um, I think it's usually a double |
| 01:36.47 | pacman87 | <PROTECTED> |
| 01:36.47 | pacman87 | <PROTECTED> |
| 01:36.47 | pacman87 | <PROTECTED> |
| 01:37.09 | brlcad | is that from the manpage or the header? |
| 01:37.15 | pacman87 | manpage |
| 01:37.23 | brlcad | see what your header has |
| 01:37.36 | brlcad | maybe it's in some #ifdef'd block |
| 01:40.33 | pacman87 | my /usr/include/math.h doesnt' have any of them |
| 01:41.18 | brlcad | eh, you didn't just grep I hope? :) |
| 01:41.28 | brlcad | usually it's just a front-end to /usr/include/somethingelse |
| 01:42.03 | brlcad | also, I presume you're using <math.h> and not "math.h", yes? |
| 01:42.23 | pacman87 | when grep failed, i opened it |
| 01:42.30 | pacman87 | and it's not linked anywhere |
| 01:42.41 | pacman87 | and yes to <math.h> |
| 01:43.15 | brlcad | can you upload your math.h somewhere? |
| 01:43.20 | pacman87 | sure |
| 01:43.49 | brlcad | not the first time i've seen them missing, but it's certainly been a while.. |
| 01:45.18 | pacman87 | https://webspace.utexas.edu/trv82/www/math.h |
| 01:47.30 | brlcad | what did you mean by "it's not linked anywhere"? |
| 01:48.12 | brlcad | that header includes about four or five others that might have fmax, try: grep -r -i fmax /usr/include |
| 01:48.16 | pacman87 | (08:42:17 PM) brlcad: usually it's just a front-end to /usr/include/somethingelse |
| 01:48.47 | brlcad | yeah, your math.h is a front end to /usr/include/bits |
| 01:48.53 | pacman87 | ah, ok |
| 01:48.56 | brlcad | for at least many decls |
| 01:50.32 | brlcad | I vaguely recall fighting fmax declarations on other platforms a while back |
| 01:50.51 | brlcad | gave up on nirt apparently, #define FMAX(a,b) ((((double)(a))>((double)(b)))?((double)(a)):((double)(b))) |
| 01:51.00 | pacman87 | yeah, i saw that one |
| 01:52.13 | brlcad | if it comes to it, go ahead and add an FMAX and FMIN to vmath.h |
| 01:52.17 | pacman87 | /usr/include/bits/mathcalls.h:__MATHCALL (fmax,, (_Mdouble_ __x, _Mdouble_ __y)); |
| 01:52.25 | brlcad | that's it |
| 01:53.40 | pacman87 | /usr/include/tgmath.h:#define fmax(Val1, Val2) __TGMATH_BINARY_REAL_ONLY (Val1, Val2, fmax) |
| 01:54.34 | brlcad | so either that __MATHCALL macro requires math.h coming after some other header, or mathcalls.h isn't getting included due to some #if inclusion logic, or similar situation |
| 01:56.14 | pacman87 | mathcalls.h is included |
| 01:56.20 | pacman87 | no #if wrapper |
| 01:57.34 | pacman87 | except #ifndef_MATH_H |
| 01:58.37 | brlcad | hmm.. but it is included before __MATHCALL is defined |
| 01:59.16 | pacman87 | __MATHCALL is defined on line 54 |
| 01:59.26 | pacman87 | #include <bits/mathcalls.h> is line 71 |
| 02:00.34 | brlcad | oh, I was looking at mathdef.h |
| 02:01.22 | brlcad | ah, it is wrapped |
| 02:01.51 | brlcad | add this before #include <math.h> .. #define __USE_MISC 1 |
| 02:02.05 | brlcad | might be SoL |
| 02:02.23 | brlcad | as it's a c99 macro, and it's not providing it unless in c99 mode |
| 02:04.09 | brlcad | so you can either cheat and just declare them yourself, extern double fmax(double, double); or do the FMAX/FMIN thing for now |
| 02:04.39 | pacman87 | <PROTECTED> |
| 02:04.47 | brlcad | since it's c99, configure would need to test for it and conditionally use it or provide it (which would still warrant a FMIN/FMAX) |
| 02:04.57 | brlcad | yeah, it probably unsets it |
| 02:05.34 | pacman87 | so add FMAX/FMIN to vmath.h, or somewhere else? |
| 02:05.49 | brlcad | didn't follow through all the logic, it's going to be one of the extension defines |
| 02:06.03 | brlcad | or adding -std=c99 as a cflag, etc |
| 02:06.09 | brlcad | which we can't do just yet |
| 02:06.34 | pacman87 | well, running the code doesn't blow up anything |
| 02:06.40 | brlcad | well, we could and it should work, but c89 strict hasn't been 100% tested (we're almost done) |
| 02:07.38 | brlcad | it's still resolved by the -lm symbol or the built-in |
| 02:08.04 | brlcad | no different than not including stdlib for exit(), just calls to exit will still work |
| 02:09.18 | brlcad | actually, add it to common.h -- it's not specific to vector or matrix math |
| 02:09.28 | brlcad | nor specific to libbn |
| 02:11.56 | pacman87 | #define FMAX(a, b)(((a)>(b))?(a):(b)); |
| 02:11.56 | pacman87 | #define FMIN(a, b)(((a)<(b))?(a):(b)); |
| 02:12.13 | pacman87 | or without the ; |
| 02:12.34 | pacman87 | s/or/err, |
| 02:16.39 | pacman87 | i'm looking at moving my open sketch detection to sketch from revolve's prep |
| 02:16.52 | pacman87 | since i'll need it for revolve's plot() too |
| 02:17.10 | pacman87 | so plot() shows the lines needed to close the sketch |
| 02:22.32 | brlcad | without the ; |
| 02:22.52 | pacman87 | brlcad: yeah, i fixed it |
| 02:24.00 | brlcad | consider adding a file to src/librt/primitives/here.c since it's shared so there isn't cross-primitive referencing |
| 02:24.35 | brlcad | not a huge deal, but part of the refactoring cleanup that would be good to work towards for some of the "combo" primitives |
| 02:26.04 | pacman87 | was wondering why it should be called 'here.c' |
| 02:26.22 | pacman87 | then i realized it was the location |
| 02:28.31 | brlcad | heh |
| 02:37.11 | ``Erik | y'know, uh, ... listening to some of the originals that metallica covered in their early years... metallica waren't nothin' special... they kinda sucked, really |
| 02:37.48 | CIA-22 | BRL-CAD: 03pacman87 * r31829 10/brlcad/trunk/src/librt/primitives/ (revolve/revolve.c sketch/sketch.c): add rt_sketch_bounds() to sketch.c; fix rt_revolve_prep() to use rt_sketch_bounds() in calculating bounding volume |
| 02:38.28 | CIA-22 | BRL-CAD: 03pacman87 * r31830 10/brlcad/trunk/include/common.h: add FMAX() and FMIN() |
| 02:48.09 | *** join/#brlcad dtidrow (n=dtidrow@c-69-255-182-248.hsd1.va.comcast.net) | |
| 02:55.20 | starseeker | brlcad: Agreed about the low res image(s), but I'm not sure what we can do about it at this late date :-/ |
| 03:07.39 | brlcad | where'd they come from? |
| 03:09.20 | brlcad | ``Erik: you see the note about the summit? |
| 03:10.05 | brlcad | leslie shared the date, 25th/26th |
| 03:10.15 | brlcad | pretty cool that it's two days this year |
| 03:11.05 | *** join/#brlcad SWPadnos_ (n=Me@dsl107.esjtvtli.sover.net) | |
| 03:12.20 | brlcad | awesome! .. new handbrake works much much better now |
| 03:20.03 | starseeker | brlcad: dunno where they came from |
| 03:20.28 | brlcad | er, you mean the images in the .doc are that small? |
| 03:20.37 | starseeker | yep |
| 03:20.38 | brlcad | they wouldn't have printed well at that resolution |
| 03:20.51 | brlcad | hunts for vol III |
| 03:20.54 | starseeker | well, maybe my extraction routine made a hash of them... |
| 03:25.11 | Ralith | starseeker: at least a few of them can be regenerated from scratch, can't they? |
| 03:25.44 | starseeker | The simple ones like diagrams, sure. The tank raytraces are something else again |
| 03:31.03 | brlcad | yeah, it's dropping it from 300dpi to 100dpi or something on extraction from the looks of it |
| 03:31.10 | starseeker | grr |
| 03:31.24 | brlcad | not that it'd look any better, just minor aliasing artifacts |
| 03:31.42 | brlcad | just not suitable for print |
| 03:32.14 | starseeker | hmm. can they be regenerated at higher res? |
| 03:32.29 | starseeker | thought maybe they were deliberately low res for release |
| 03:33.08 | brlcad | those probably could or manually extracted from the doc or scripted capture |
| 03:33.58 | brlcad | the doc compilation would probably run an image 'compile' to generate the right resolution depending on the target |
| 03:36.05 | starseeker | only if the models are to hand during the doc build... |
| 03:39.10 | brlcad | yeah, most of those could be generated with a simple script |
| 03:39.28 | brlcad | would make for a nice testing suite too |
| 03:39.37 | starseeker | what about the text overlays? |
| 03:39.40 | brlcad | something for later maybe |
| 03:39.45 | brlcad | sure, that's doable |
| 03:39.49 | brlcad | that's just mged plotting |
| 03:39.59 | brlcad | you can extract the mged overlay now |
| 03:40.50 | brlcad | they just entered edit mode so it displays the label, then captured a screenshot |
| 03:41.16 | starseeker | are we both looking at the tank raytracings at the beginning of Volume III? |
| 03:41.30 | brlcad | could just as easily extract that data as ps/plot data and run pl-fb to get the image |
| 03:41.40 | brlcad | no, i'm talking about the wireframes |
| 03:42.08 | brlcad | the tank images can't be regenerated of course, we don't have the models |
| 03:42.28 | brlcad | would just keep a high-res copy of the image and it'd downsample as needed |
| 03:42.59 | brlcad | er, "could" regenerate it, just not on the fly |
| 03:44.17 | starseeker | Ah, ok wireframes |
| 04:16.44 | poolio | I think I thought of the fix to the NMG brep code while watching Hancock :D |
| 04:18.28 | poolio | Time to see if it'll work :) |
| 04:23.09 | CIA-22 | BRL-CAD: 03brlcad * r31831 10/brlcad/trunk/ (Makefile.am include/conf/Makefile.am): make the reported compilation time reset every time 'make' is invoked so that the numbers are a little more meaningful for users pulling a dist and for partial recompiles. |
| 04:24.09 | CIA-22 | BRL-CAD: 03pacman87 * r31832 10/brlcad/trunk/src/librt/primitives/revolve/revolve.c: minor cleanup in rt_revolve_prep(); remember to save your final changes before comitting |
| 04:55.03 | CIA-22 | BRL-CAD: 03brlcad * r31833 10/brlcad/trunk/ (include/db5.h src/librt/db_match.c): |
| 04:55.03 | CIA-22 | BRL-CAD: add reference counting support for revolve primitives since they reference other |
| 04:55.03 | CIA-22 | BRL-CAD: objects (sketches), used by tops, xpush, and possibly a couple other mged |
| 04:55.03 | CIA-22 | BRL-CAD: commands. requires providing DB5_MINORTYPEs for revolve and a slew of other new |
| 04:55.03 | CIA-22 | BRL-CAD: objects that have since been added. stupid to maintain two listings like this. |
| 05:03.29 | *** join/#brlcad pacman87 (n=timothy@71.170.63.120) | |
| 05:41.59 | *** join/#brlcad clock_ (n=clock@217-162-111-246.dclient.hispeed.ch) | |
| 06:16.51 | *** join/#brlcad esben (n=esben@0x573ff382.boanqu1.static.dsl.tele.dk) | |
| 06:22.55 | CIA-22 | BRL-CAD: 03brlcad * r31834 10/brlcad/trunk/src/librt/primitives/dsp/dsp.c: |
| 06:22.55 | CIA-22 | BRL-CAD: fixed a bug detected by the solids regression test where dsp primitives were |
| 06:22.55 | CIA-22 | BRL-CAD: failing due to the change made in r31629 that made the converted the dsp's |
| 06:22.55 | CIA-22 | BRL-CAD: former rt_parsetab_tclget() (now rt_dsp_get()) routine from |
| 06:22.55 | CIA-22 | BRL-CAD: Tcl_DStringAppendElement to bu_vls_printf calls which are not equivalent. The |
| 06:22.58 | CIA-22 | BRL-CAD: Tcl_DStringAppendElement() calls automatically pad spaces, so have to manually |
| 06:23.00 | CIA-22 | BRL-CAD: pad the bu_vls_printf() call. |
| 06:46.59 | CIA-22 | BRL-CAD: 03brlcad * r31835 10/brlcad/trunk/src/libbu/parse.c: |
| 06:46.59 | CIA-22 | BRL-CAD: and we come full circle. perform a strcat instead of a strcpy so it doesn't |
| 06:46.59 | CIA-22 | BRL-CAD: clobber what's already written to log. that said, it's still BUSTED bad. not |
| 06:46.59 | CIA-22 | BRL-CAD: only does it only log instead of setting the var, it also still ends up smashed |
| 06:46.59 | CIA-22 | BRL-CAD: against the next logged item (see solids.sh regression test for db put dsp.s, |
| 06:47.02 | CIA-22 | BRL-CAD: broken) |
| 06:48.33 | *** join/#brlcad d_rossberg (n=rossberg@bz.bzflag.bz) | |
| 06:56.56 | CIA-22 | BRL-CAD: 03brlcad * r31836 10/brlcad/trunk/TODO: d_rossberg's suspicion was spot on, need to unbreak mged get/put commands and structparsing with %S formatters. it's been busted since r31629 and r31609 in particular from a couple weeks ago. |
| 07:20.26 | *** join/#brlcad clock_ (n=clock@zux221-122-143.adsl.green.ch) | |
| 07:25.48 | *** join/#brlcad geocalc (n=geocalc@dyn-91-171-218-234.ppp.tiscali.fr) | |
| 07:25.54 | *** join/#brlcad esben__ (n=esben@0x573ff382.boanqu1.static.dsl.tele.dk) | |
| 07:32.47 | *** join/#brlcad IriX64 (n=mariodot@bas2-sudbury98-1128564908.dsl.bell.ca) | |
| 08:02.55 | *** join/#brlcad thing0 (n=ric@203-206-48-50.dyn.iinet.net.au) | |
| 08:07.47 | *** join/#brlcad esben__ (n=esben@0x573ff382.boanqu1.static.dsl.tele.dk) | |
| 08:09.01 | *** join/#brlcad esben__ (n=esben@0x573ff382.boanqu1.static.dsl.tele.dk) | |
| 08:09.41 | *** join/#brlcad esben (n=esben@0x573ff382.boanqu1.static.dsl.tele.dk) | |
| 08:34.00 | CIA-22 | BRL-CAD: 03d_rossberg * r31837 10/brlcad/trunk/src/libbu/parse.c: reactivated the %S format (string copy to struct bu_vls) in bu_structparse_argv |
| 08:38.24 | CIA-22 | BRL-CAD: 03d_rossberg * r31838 10/brlcad/trunk/ (4 files in 3 dirs): changed the sketch_name in rt_revolve_internal to struct bu_vls to handle strings correctly |
| 08:50.56 | CIA-22 | BRL-CAD: 03d_rossberg * r31839 10/brlcad/trunk/src/mged/typein.c: changed the sketch_name type in rt_revolve_internal |
| 09:59.39 | *** join/#brlcad esben (n=esben@0x573ff382.boanqu1.static.dsl.tele.dk) | |
| 10:10.02 | *** join/#brlcad esben__ (n=esben@0x573ff382.boanqu1.static.dsl.tele.dk) | |
| 10:27.50 | *** join/#brlcad mafm (n=mafm@elnet-111.lip.pt) | |
| 10:33.27 | mafm | hiya |
| 10:40.43 | *** join/#brlcad elite01 (n=elite01@unaffiliated/elite01) | |
| 10:44.25 | *** join/#brlcad clock__ (n=clock@zux221-122-143.adsl.green.ch) | |
| 10:54.51 | *** join/#brlcad archivist_emc (n=archivis@host81-149-119-172.in-addr.btopenworld.com) | |
| 11:27.55 | *** join/#brlcad clock_ (n=clock@84-72-91-240.dclient.hispeed.ch) | |
| 11:32.54 | mafm | brlcad: trackball and shift-grips should be active at the same time? (be the same "camera mode") |
| 11:39.14 | *** join/#brlcad dtidrow (n=dtidrow@c-69-255-182-248.hsd1.va.comcast.net) | |
| 12:36.22 | *** join/#brlcad thing0 (n=ric@203-206-48-50.dyn.iinet.net.au) | |
| 13:27.01 | *** join/#brlcad dtidrow (n=dtidrow@c-69-255-182-248.hsd1.va.comcast.net) | |
| 13:44.33 | *** join/#brlcad dtidrow (n=dtidrow@c-69-255-182-248.hsd1.va.comcast.net) | |
| 13:46.56 | brlcad | mafm: no, those are two separate manners of interaction |
| 13:48.29 | *** join/#brlcad pacman87 (n=timothy@71.170.63.120) | |
| 13:48.49 | pacman87 | morning, all |
| 13:50.03 | ``Erik | salut |
| 13:53.14 | brlcad | hola |
| 14:00.06 | poolio | mornin' |
| 14:07.06 | d_rossberg | moin moin pacman87 |
| 14:07.07 | mafm | goody, so two different camera modes :D |
| 14:07.31 | mafm | inventing a new way of development... refartoring before even commiting :P |
| 14:07.36 | *** join/#brlcad cad00 (n=cec31333@bz.bzflag.bz) | |
| 14:07.41 | mafm | hi pacman87 |
| 14:09.21 | mafm | refart lol... refact*oring |
| 14:12.08 | brlcad | haha |
| 14:15.15 | mafm | now I can't complain if somebody tells me that my code is shit :| |
| 14:17.04 | ``Erik | because you re-farted it? |
| 14:23.58 | mafm | yep |
| 14:24.06 | mafm | is like when something talks by burping :) |
| 14:24.28 | ``Erik | lifts a cheek and lets some code out :D |
| 14:27.06 | mafm | lol |
| 14:27.18 | mafm | would avoid to go to any brl-cad hackaton |
| 14:27.53 | ``Erik | yeah, people would be confused at all the candles in the room O.o |
| 14:31.22 | CIA-22 | BRL-CAD: 03pacman87 * r31840 10/brlcad/trunk/src/librt/primitives/sketch/sketch.c: implemented rt_sketch_degree() |
| 14:35.21 | mafm | candles? |
| 14:35.44 | ``Erik | sure, some code might be flammable :D and that'd be cool |
| 14:36.27 | mafm | lol |
| 14:37.07 | mafm | BRL CAD's Flaming Circus |
| 14:38.01 | ``Erik | the trick is getting everyone to code in sync to cut off 'liberty bell' |
| 14:41.59 | mafm | :D |
| 14:48.23 | d_rossberg | pacman87: you should compute the hit_point member of struct hit in rt_revolve_norm as your comment on this function says (maybe other members are missing too) |
| 14:51.36 | pacman87 | d_rossberg: VJOIN1( hitp->hit_point, rp->r_pt, hitp->hit_dist, rp->r_dir ); |
| 14:52.04 | pacman87 | does adding that line to norm() fix it? |
| 14:52.44 | clock_ | And then get all the primitives sing "This is the CAD we live in!" |
| 14:52.57 | pacman87 | ...? |
| 14:53.05 | *** join/#brlcad SWPadnos_ (n=Me@dsl107.esjtvtli.sover.net) | |
| 14:53.27 | d_rossberg | pacman87: something like this, yes |
| 14:54.51 | d_rossberg | it looks like the rt command doesn't need this, but my application does |
| 14:55.41 | pacman87 | i'm allocating memory using bu_calloc in prep(), and storing it in revolve_specific - when should it be free'd? |
| 14:56.13 | *** join/#brlcad dtidrow (n=dtidrow@c-69-255-182-248.hsd1.va.comcast.net) | |
| 14:56.46 | pacman87 | just free the revolve_specific pointer before assigning the new data? |
| 14:59.58 | brlcad | burst, g_lint, lgt, nirt, and a few others need the hit_point too |
| 15:02.15 | d_rossberg | rt_revolve_free ? |
| 15:02.37 | pacman87 | does that always get called after prep? |
| 15:05.51 | d_rossberg | as far as i can see: yes |
| 15:34.09 | CIA-22 | BRL-CAD: 03mafm * r31841 10/rt^3/trunk/src/g3d/ (Commands.h GeometryConversion.cxx GeometryConversion.h): Fixing typo in name -- missing 'h' |
| 15:46.49 | mafm | does anybody know if there is a document like this for trackball mode? |
| 15:47.08 | mafm | http://brlcad.org/w/images/8/8c/Shift_Grips_Quick_Reference_Guide.pdf |
| 15:53.08 | brlcad | mafm: download AoI or Blender, their defaults are trackball-style |
| 15:55.55 | brlcad | trackball is merely a "rotate viewpoint" default |
| 15:57.38 | brlcad | AoI -> http://www.artofillusion.org/downloads |
| 15:59.02 | brlcad | similar to control-click with shift-grips |
| 15:59.31 | mafm | but I mean also with keys |
| 16:00.13 | mafm | would be arrow keys only? |
| 16:00.27 | brlcad | *confused* |
| 16:01.08 | brlcad | your question doesn't make any sense to me |
| 16:01.16 | brlcad | i also mean with keys too |
| 16:01.53 | brlcad | shift-grips .. is centered around key-bindings, and even without mouse arrow-keys still modify the view (they rotate iirc) |
| 16:03.31 | brlcad | in the end, all we're talking about is 1) key bindings and 2) view modifications ... sets of 1+2 => an interaction style |
| 16:04.12 | brlcad | shift-grips is one interaction style, the one used by mged with all the binding-to-view modifications spelled out in that guide (the key-only bindings are listed, but they're trivial) |
| 16:06.06 | brlcad | think of the view modifications as a 'tool' you might select (ala photoshop/gimp): e.g., zoom in/out, rotate freely, translate freely, rotate vertical, rotate horizontal, translate left/right, translate up/down, etc |
| 16:06.21 | brlcad | those map to input events |
| 16:10.50 | mafm | bleh |
| 16:10.57 | mafm | I'm dragging into all this :S |
| 16:55.05 | mafm | yay! |
| 16:55.10 | mafm | got something working at last :) |
| 17:10.33 | *** join/#brlcad clock_ (n=clock@77-56-86-73.dclient.hispeed.ch) | |
| 17:12.27 | esben__ | Hi, I'm using version 7.12.5 and when I try to raytrace something and try to underlay the framebuffer the wireframe version still gets hidden behind the frame buffer. Is this the intended behaviour or should I post a bug report ? |
| 17:15.11 | esben__ | I also posted this question on the user mailing list as I am living in Denmark and therefore is not available because of the time difference when you guys from the U.S. are on this channel |
| 17:29.44 | starseeker | stokes his courage with caffine and takes a look at firebirds title page xsl... |
| 17:35.34 | brlcad | esben__: I've seen the mailing list question, just haven't had a chance to look into it or reply |
| 17:36.26 | ``Erik | some people here are in non-us timezones, some people keep odd hours, and some of us read backlog and reply (eventually) |
| 17:37.41 | CIA-22 | BRL-CAD: 03mafm * r31842 10/rt^3/trunk/src/g3d/ (4 files): Commiting more flexible Camera system, having camera with different camera modes. Still WIP, but it's already working better than my previous attemps to control the view. |
| 17:43.55 | esben__ | Thanks Sean. I'll just wait for the reply then. About reading backlog I do that too, when I have time... |
| 17:45.17 | poolio | errr wut: cannot convert âface_g_plane*â to âfage_g_plane*â in assignment |
| 17:45.29 | poolio | Those two look the same to me. |
| 17:49.32 | ``Erik | face fage? |
| 17:49.51 | poolio | D'OH. |
| 17:50.00 | poolio | I should get my eyes checked |
| 17:50.24 | ``Erik | pop 'em out and mail 'em to a service center |
| 18:04.07 | brlcad | esben__: basically 7.12.5 implies you're using trunk sources .. which is somewhat unstable right now -- I just tried 7.12.2 and can't reproduce what you're saying |
| 18:04.22 | brlcad | maybe someone else can try trunk (don't have a compile handy atm) |
| 18:04.54 | brlcad | esben__: otherwise, no that's not expected behavior -- underlay should show the wireframe (unless the wireframe is the same color as the framebuffer of course) |
| 18:05.25 | brlcad | hehe, nice one poolio |
| 18:06.01 | brlcad | mafm: the site with your screenshots seems down, is it just from here or really down down? |
| 18:08.00 | poolio | brlcad: =( |
| 18:08.43 | brlcad | :) |
| 18:18.43 | mafm | brlcad: it's apache2 that sometimes dies... restarted |
| 18:19.01 | poolio | brlcad: so I'm trying to compute a rectangular bounding box for a given set of points on a plane. To do this, I'm letting the first point we look at be the "origin," the second point defines the direction of the x-axis/u, and then I project onto the x/y axis to find the min/max points |
| 18:19.09 | poolio | Does that seem reasonable or am I making this way too complicated? |
| 18:26.58 | starseeker | brlcad: I take it clone is also going to need some libged lov'in at some point? |
| 18:29.41 | mafm | brlcad: one of the things that I wanted to ask before is if there's a set of keys predetermined for trackball mode -- if it's the arrows keys, or other... |
| 18:33.43 | mafm | (demand overflow :P) |
| 18:38.46 | ``Erik | heh, "teach yourself programming in 10 years" |
| 18:40.33 | mafm | me with old voice: say 10 years, you punk? Ain't learn Cobol in less than 50, all those verbose sentences... |
| 18:41.10 | mafm | :P |
| 18:41.10 | mafm | missing / :) |
| 18:41.10 | ``Erik | http://www.norvig.com/21-days.html |
| 18:43.27 | brlcad | mafm: you're welcome to have an account on brlcad.org, if you're interested |
| 18:43.41 | mafm | yup, I read it like 10 days ago ``Erik :) |
| 18:43.51 | brlcad | would give you a brlcad.org/~mafm as well as the ability to put stuff under brlcad.org itself |
| 18:44.00 | ``Erik | heh, really? nutty :) |
| 18:44.12 | ``Erik | only $50/mo ? :D *duck* |
| 18:45.11 | mafm | well, if you think that it's worth having it... I would only use it for the screenies atm (I don't know even if I can upload them to the wiki) |
| 18:46.32 | brlcad | you can upload them into the wiki too, that's open -- but yeah I think it's worth having myself ;) |
| 18:46.36 | ``Erik | the dep chain for darcs is brutal O.o |
| 18:46.59 | mafm | ok then |
| 18:47.47 | mafm | I hope that I don't have to send my police file to us army or anything :PPP |
| 18:47.57 | brlcad | mafm: for the account, go to http://bzflag.bz/ hit the link in the bottom right, and go from there (has you do something) |
| 18:48.07 | brlcad | it's not a govt server |
| 18:48.38 | brlcad | it's just one I provide for cad, bz, and a couple dozen other purposes |
| 18:49.50 | mafm | lol, a hidden pixel in the website! |
| 18:50.00 | mafm | I don't hear from that since 1997 or so |
| 18:50.27 | brlcad | it's not hidden, but yeah a lil historic fun ;) |
| 18:51.01 | ``Erik | such a lame movie, though :) |
| 18:51.12 | ``Erik | had several tiny pi's on pages back in the day O.o |
| 18:51.30 | brlcad | yeah, it was very cheesy |
| 18:51.36 | brlcad | but memorable :) |
| 18:52.01 | ``Erik | um, I just remember the pi symbol and that sandra bullock is lame |
| 18:52.02 | ``Erik | :D |
| 18:52.14 | brlcad | if I could get voice authentication working over javascript, you'd have to say "my voice is my passport, verify me .. please" |
| 18:52.50 | ``Erik | scoots his office away from brlcad's |
| 18:53.55 | brlcad | hacks the gibson to send ``Erik streaming porn backed with disney music |
| 18:54.27 | mafm | have to rush to the supermarket for bread before they close, bbiab :D |
| 18:54.50 | ``Erik | heh |
| 18:54.52 | brlcad | poolio: x-axis/u ? |
| 18:54.59 | ``Erik | don't get dizzy from flying around all those cubes |
| 18:55.11 | ``Erik | excuse me while I go make out with angelina's jolies |
| 18:55.13 | ``Erik | O:-) |
| 18:55.19 | starseeker | starts pondering very basic naming functions as a way to think about an increment providing library |
| 18:55.26 | ``Erik | would you like to play a game? |
| 18:55.32 | brlcad | poolio: if you just want a projected 2d bounding box, just look at their x,y values and min/max them all |
| 18:56.23 | brlcad | global thermonuclear war |
| 18:56.42 | pacman87 | i finally saw that last year |
| 18:56.56 | pacman87 | didn't realize how many quotes from there i'd already heard |
| 18:57.00 | ``Erik | heh |
| 18:57.22 | ``Erik | or jurassic park, "I recognize this.. it's UNIX!" |
| 18:57.26 | ``Erik | with an old indy |
| 18:57.48 | brlcad | "ah ah ah ... [wags finger] ... ah ah ah" |
| 18:58.07 | ``Erik | after I saw sphere, I ran and wrote a little random print/sleep loop in C to emulate what was going on their terminals heh |
| 18:58.36 | ``Erik | and, uh, brlcad, YOU have to blow the computer. |
| 18:58.46 | poolio | brlcad: that only works if the plane lies in the z-axis though |
| 18:59.02 | poolio | I want to look at their "x,y" values on the plane and min/max them all |
| 18:59.23 | pacman87 | poolio: so you're projecting 3d points onto an arbitrary plane? |
| 18:59.40 | poolio | well, those 3d points are all on the plane |
| 18:59.56 | ``Erik | grar, still getting errors on my mac |
| 19:00.30 | brlcad | poolio: what is it that you're actually trying to do from a higher level? |
| 19:01.50 | poolio | Create a planar surface for the brep |
| 19:02.30 | poolio | So have the rectangular plane, then cut out the surface inside of that plane |
| 19:02.43 | poolio | well, rectangular surface, and cut out the proper shape of the surface inside of it |
| 19:03.12 | poolio | So for example, if I have a triangle, I want to first create a rectangle that surrounds the triangle, and then cut the triangle out of that rectangle (using trimming curves) |
| 19:04.22 | pacman87 | so the triangle verticies are your 3d points, and you need to know what size rectangle you need to contain them? |
| 19:05.43 | poolio | yes |
| 19:06.51 | pacman87 | could you use the 3d bounding box for the 3d points, and transfer that to the 2d plane? |
| 19:09.29 | poolio | hmm, that's probably a much easier way to do it, but I'd have to intersect the plane with the bounding box |
| 19:10.01 | pacman87 | it depends on how many 3d points you have |
| 19:10.52 | pacman87 | if it's only a few, it might be faster to project them all to the plane first |
| 19:11.55 | poolio | It's highly variable |
| 19:12.06 | poolio | I'm thinking that intersecting with the BB is probalby a better way to do it though |
| 19:12.06 | pacman87 | what's the average case? |
| 19:12.33 | poolio | not really sure...it's used to convert any NMG to brep |
| 19:13.13 | poolio | A fairly typical case may be 8 points when used for an arb8, but I'm guessing that there are models with a very large number of points |
| 19:15.39 | poolio | So intersecting with the BB works, but it's not the prettiest in terms of the geometry of the brep. If you have say, a rectangular surface, that is not axis-aligned, then you have to trim the surface at odd angles |
| 19:15.46 | pacman87 | if you know the plane's normal vector, dot it with each of the three axes (x,y,z), and see which is closest to zero. then you can project into that plane by ignoring that coordinate, get your 2d box, and transform it back to the real 2d plane |
| 19:16.35 | pacman87 | poolio: you could try getting a rect bounding box for the intersection... |
| 19:16.53 | poolio | well, it'd be rectangular but the issue is that it's not aligned with the face geometry |
| 19:17.40 | pacman87 | if alignment is worth starting with a larger box, you can just make an aligned box around the first bo |
| 19:17.41 | pacman87 | x |
| 19:18.10 | poolio | ah hmm |
| 19:18.30 | poolio | I'm going to see if my hacked up method works, if not, then yours sounds ... better :) |
| 19:19.03 | ``Erik | laughs evilly as he commits |
| 19:19.06 | CIA-22 | BRL-CAD: 03erikgreenwald * r31843 10/brlcad/trunk/src/rt/viewmlt.c: change to output using bu_image routines instead of straight pix |
| 19:19.08 | pacman87 | is your hacked up the "first point is origin, second is direction of x?" |
| 19:20.15 | *** join/#brlcad Ralith (n=ralith@216.162.199.202) | |
| 19:20.18 | pacman87 | poolio: and if your worried about aligning your bounding box, wouldnt that determine your x/y directions? |
| 19:20.41 | poolio | Wouldn't what? |
| 19:20.52 | poolio | pacman87: yes |
| 19:21.11 | pacman87 | poolio: yes to which: hacked up, or directions? |
| 19:21.23 | poolio | hacked up |
| 19:22.13 | pacman87 | if you need your bounding box to be aligned, you should use those axes you want to be aligned to, instead of an arbitrary set |
| 19:22.15 | poolio | That determines x/y directions. So I could just take the bounding box, create a new bounding box that's properly aligned and encloses the previous box. Then intersect the aligned box |
| 19:22.55 | poolio | pacman87: When I say aligned, I mean aligned with the geometry, not aligned with the x/y/z axis |
| 19:23.08 | poolio | I think I'm confusing both you and myself :( |
| 19:25.33 | pacman87 | so the aligned box has its own axes (u,v)? |
| 19:26.01 | poolio | yes |
| 19:26.23 | pacman87 | do you know what those axes are before you create the first bounding box? |
| 19:28.16 | poolio | well, the first bounding box is automatically created and axis aligned |
| 19:28.25 | poolio | (the standard min_pt, max_pt) |
| 19:28.46 | poolio | So, no. |
| 19:31.47 | esben__ | brlcad: Thanks. Do you need more info ? I go to bed now so lets continue over mail if you need more info. I the mean time I discovered another strange thing which I will report on the user list tomorrow Good night when you get that far. |
| 19:32.03 | mafm | back |
| 19:34.45 | CIA-22 | BRL-CAD: 03mafm * r31844 10/rt^3/trunk/src/g3d/ (5 files): Removing previous (and now unneeded) hacks related with camera positioning |
| 19:36.37 | pacman87 | poolio: ah, i was thinking if you already knew the u,v axes you wanted for the aligned bounding box, you could use those axes directly in determining max/min bounds for your points, and skip the "aligned bounding box around the x/y/z bounding box" |
| 19:37.57 | *** join/#brlcad docelic (n=docelic@78.134.196.59) | |
| 19:38.18 | pacman87 | though i'm not quite sure what you mean by 'automatically created'; i though you were the one making the bounding box |
| 19:39.57 | poolio | Well, the NMG primitive has a min_pt and max_pt for a face |
| 19:46.48 | CIA-22 | BRL-CAD: 03pacman87 * r31845 10/brlcad/trunk/src/librt/primitives/revolve/revolve.c: fix revolve's norm(), broken by trying to be too clever; incremental improvements to plot() for handling partial revolves of open sketches - draw lines to close sketches |
| 19:50.32 | starseeker | Anybody know the "right" way in C to ask for the number of characters in an integer? |
| 19:50.52 | ``Erik | erm, snprintf and strlen it? |
| 19:51.05 | ``Erik | or do a reduction loop? |
| 19:51.07 | starseeker | right - that's the right way? |
| 19:51.18 | starseeker | was hoping for charlength(number) or something cute |
| 19:51.28 | ``Erik | not that I know of |
| 19:51.32 | starseeker | phooey |
| 19:51.34 | starseeker | ok |
| 19:51.35 | starseeker | thanks |
| 19:52.22 | ``Erik | { int i = 1, x = val; while( x>10 ) { ++i; x /= 10; } printf("%d\n", i); } |
| 19:52.44 | pacman87 | don't forget about the negative |
| 19:53.17 | ``Erik | ok, abs(x)>10, ptbtbbt |
| 19:53.30 | pacman87 | and add a char for the ' |
| 19:53.32 | pacman87 | -' |
| 19:53.35 | ``Erik | (plus, I suppose, the -) |
| 19:54.22 | starseeker | bu_log("%d\n",snprintf(NULL, 0, "%d",i)); seems to do what I need |
| 19:54.24 | starseeker | thanks :-) |
| 19:55.26 | ``Erik | heh, string length of a number, silly lithper :D |
| 19:55.30 | ``Erik | "Mom? Whats 6 x 8?" "Oh sweetie, those are two completely different numbers!" |
| 19:57.49 | ``Erik | doesn't know that he'd trust writing 0 bytes to a NULL ptr to return the real length instead of 0 or -1 |
| 20:01.03 | starseeker | OK, now question two. How to make printf use a number in a variable, e.g. printf("%numofspacesd",integer); |
| 20:01.13 | mafm | I go now, take care folks :) |
| 20:01.19 | ``Erik | "% 4d" |
| 20:01.28 | ``Erik | ? |
| 20:01.30 | starseeker | yes, but 4 is in a variable |
| 20:01.35 | ``Erik | oh |
| 20:02.10 | ``Erik | char fmt[BUFSIZ]; snprintf(fmt, "%%%dd", x); printf(fmt, i); |
| 20:02.38 | ``Erik | minus the bugs/typos |
| 20:02.56 | starseeker | Does vls have anything? |
| 20:03.22 | ``Erik | Iuhho |
| 20:04.02 | Ralith | %%%dd looks more like your repeat rate is set too high than a valid format string |
| 20:05.17 | starseeker | hunts |
| 20:05.18 | ``Erik | printf("%%%dd\n", 4); will print "%4d" |
| 20:05.30 | Ralith | I know |
| 20:05.37 | Ralith | it's just kinda funny :P |
| 20:05.43 | ``Erik | :D could be worse |
| 20:05.46 | Ralith | true |
| 20:05.50 | ``Erik | take a look at lisps format notation |
| 20:05.52 | Ralith | this is C, after all |
| 20:06.07 | ``Erik | so many weird ~ commands that you'll get seasick from the waves :D |
| 20:06.12 | Ralith | hehe |
| 20:06.40 | pacman87 | http://xkcd.com/234/ |
| 20:07.54 | ``Erik | http://xkcd.com/224 :) |
| 20:08.04 | ``Erik | is in a very lisp state of mind at the moment |
| 20:08.19 | ``Erik | time to swap brains with cliff for a bit O.o |
| 20:08.49 | starseeker | I wouldn't do that if I were you :-) |
| 20:09.44 | ``Erik | doesn't grok how to address a thread in sbcl |
| 20:10.46 | ``Erik | like, I see one from (sb-thread:list-all-threads) I want defined as #<SB-THREAD "some name" {432135}> and I want to (sb-thread:terminate-thread 'it) |
| 20:11.29 | ``Erik | do (car (sb-thread:list-all-threads)) to get the legit pointer to the object? |
| 20:11.40 | ``Erik | tries |
| 20:12.51 | ``Erik | yuh oh, now sbcl isn't seeing the packages I installed with asdf |
| 20:13.03 | starseeker | has actually never delt with sbcl threads |
| 20:13.34 | ``Erik | bah, fat lot of good you are :D *duck* |
| 20:15.33 | ``Erik | ah, the car approach works |
| 20:31.02 | starseeker | ``Erik: Thanks - it looks strange but it does work |
| 20:31.48 | ``Erik | huh? what looks strange? O.o |
| 20:32.07 | ``Erik | oh, generating the format string at runtime? |
| 20:32.16 | starseeker | The format string for sprintf - %%s%%s%%0%dd%%s%%s... |
| 20:32.28 | starseeker | it's getting close to Perl readibility |
| 20:32.41 | ``Erik | heh |
| 20:32.58 | ``Erik | that's why C programmers comment ugly things like that O:-) |
| 21:37.26 | *** join/#brlcad PrezKennedy (n=Matthew@whitecalf.net) | |
| 22:26.01 | pacman87 | poolio: how'd your bounding work out? |
| 22:35.24 | poolio | pacman87: welllllll. I think it's working right...but there's still a bug somewhere |
| 22:35.33 | poolio | pacman87: Ask me again in about an hour :) |
| 22:37.36 | pacman87 | good luck |
| 22:42.58 | poolio | Make that ... a few more hours...going to see hellboy ii :) |
| 22:53.36 | ``Erik | heh |