| 00:03.10 | *** join/#brlcad BigAToo (n=BigAToo@pool-96-230-124-74.sbndin.btas.verizon.net) |
| 00:14.41 | *** join/#brlcad Ralith (n=ralith@69.90.48.127) |
| 00:58.37 | *** join/#brlcad ``Erik (i=erik@c-69-140-109-104.hsd1.md.comcast.net) [NETSPLIT VICTIM] |
| 01:01.22 | yukonbob | brlcad: online? |
| 01:01.29 | brlcad | nope |
| 01:01.33 | yukonbob | damn |
| 01:01.37 | yukonbob | I'll check back later. |
| 01:01.38 | yukonbob | :P |
| 01:01.53 | yukonbob | I've got a question, and I bet you have the answer |
| 01:02.02 | yukonbob | now that I think of it, I've got lots of questions... |
| 01:02.09 | yukonbob | but perhaps 2 you can answer... |
| 01:02.11 | yukonbob | re: dsp |
| 01:03.13 | yukonbob | 1 -- DEM co-ords signify the "space between" grid elems (i.e. the intersection points of a grid, not the squares) -- is this how dsp behaves as well? |
| 01:03.59 | yukonbob | 2 -- can I / how-feasible-is-it to try to skin a DSP accurately (i.e. using a geotiff). Of course, accuracy is key. |
| 01:05.07 | yukonbob | geotiff == tiff image, but with geo-specific meta data -- so one can place them accurately on a map, for example... |
| 01:14.42 | brlcad | 1: yes. 2: not sure what you mean by skin it |
| 01:14.58 | brlcad | never worked with a geotiff |
| 01:17.00 | yukonbob | what I want is to be able to lay the tiff down on the dsp, and if they're representing the same square land-region, have the blue lines of the rivers match up in the gulleys of the dsp, etc, distorting as one would expect mapping a 2D tiff -> 3D dsp, but otherwise "fitting properly". |
| 01:17.20 | ``Erik | so basically just texture it with specified uv coords? |
| 01:17.48 | yukonbob | right. |
| 01:18.34 | yukonbob | are there diff't model for how one can apply a texture map like that, or would it work buy default, or ?? |
| 01:18.57 | yukonbob | i.e. if I have an 8x8 table, and an 8x8 table cloth, I can lay the cloth to cover the table. |
| 01:19.33 | yukonbob | but if I put a candlestick on top of the table (without the cloth), and then try to lay the cloth, it won't cover edge-to-edge... |
| 01:19.44 | yukonbob | how does the mapping work in brlcad? |
| 01:20.28 | yukonbob | is there a way to have a "magic" table cloth that, because it is 8x8, will cover the 8x8 surface... |
| 01:21.32 | yukonbob | , or would one sample the tiff and then use mater to adjust the "grid"s of the dsp? |
| 01:24.04 | brlcad | yukonbob: there is a separation of the geometric shapes and rendering properties such as texturing |
| 01:24.34 | brlcad | the tiff data can be converted to a height field directly |
| 01:24.57 | yukonbob | tell me more |
| 01:25.08 | brlcad | the tiff can also be applied as a texture pretty easily as well with a shader |
| 01:27.24 | yukonbob | researches height fields. Looks like what I need. Thx brlcad, ``Erik |
| 01:27.50 | brlcad | "dsp" is our name for a height field |
| 01:27.51 | brlcad | dsp == "displacement map" |
| 01:27.52 | yukonbob | right -- displacement map. |
| 01:28.17 | yukonbob | and that can have a (say) 800x800 TIFF, and generate an 800x800 heightfield then? |
| 01:28.22 | brlcad | yes |
| 01:28.28 | yukonbob | awesomenessus |
| 01:28.43 | yukonbob | I've only generated grey blobs so far, myself. |
| 01:28.45 | brlcad | though to create a dsp, all it cares about is the raw binary values |
| 01:28.53 | brlcad | so you'll have to convert the tiff |
| 01:29.05 | brlcad | nothing tricky, but a couple of data conversion steps |
| 01:29.22 | brlcad | probably tiff -> png -> bw |
| 01:29.41 | yukonbob | brlcad: don't know if you remember, but playing w/ dsp/DEMs was one of my first exercises; at the time, I tickled a nasty memory leak -- was that ever corrected? |
| 01:29.52 | brlcad | yeah, I remember |
| 01:29.55 | brlcad | it wasn't a leak |
| 01:30.00 | brlcad | it was an inefficiency |
| 01:30.06 | brlcad | using more than expected |
| 01:30.16 | yukonbob | nods. |
| 01:30.24 | brlcad | taking up 160 bytes per cell iirc |
| 01:30.27 | yukonbob | tuned up, or as was? |
| 01:30.54 | brlcad | ~(160 * 800 * 800) / 1024 / 1024 |
| 01:30.55 | ibot | 97.65625 |
| 01:31.14 | brlcad | 97MB shouldn't be a problem :) |
| 01:31.38 | yukonbob | when I threw 800x800 out, that was only for sake of argument ;) |
| 01:31.47 | ``Erik | ~1/0 |
| 01:31.50 | ``Erik | O:-) |
| 01:31.53 | yukonbob | hehe. |
| 01:32.12 | yukonbob | <PROTECTED> |
| 01:32.13 | ibot | it has been said that 2^2 is a bad question. You want 2**2. |
| 01:32.15 | ``Erik | (it still pings, musta ignored that) |
| 01:32.42 | yukonbob | ~ lart self |
| 01:32.42 | ibot | acting on orders from an unspecified client drags self into court suing for $200 million |
| 01:33.23 | yukonbob | brlcad: so is still consuming same amt. memory as previous, or was there re-coding in that inefficiency? |
| 01:34.02 | ``Erik | ~1<<5 |
| 01:34.29 | yukonbob | remembers sections of Pugeot Sound were un-renderable for self at the time... |
| 01:34.56 | ``Erik | mebbe it's cuz the puget sound is just too cool for ya |
| 01:34.57 | ``Erik | :D |
| 01:35.09 | yukonbob | actually, now that I think of it, brlcad, you had nice huge dsp's that were of larger grid, built from older brl-cad. |
| 01:35.11 | ``Erik | (my old stompin' ground, grew up on whidbey island) |
| 01:35.45 | yukonbob | courtney love tells me Olympia sucks |
| 01:35.59 | ``Erik | yeah, olympia sucks, but courtney sucks more |
| 01:36.02 | ``Erik | :D |
| 01:36.25 | ``Erik | (shit, courtney has probably sucked most of olympia *cough*) |
| 01:37.21 | brlcad | yukonbob: i don't think it's changed, but your best bet is to just give it a go and see how it behaves for your data |
| 01:37.45 | brlcad | it's been used several times over since then for various projects with complete success |
| 01:38.35 | yukonbob | brlcad: sounds good. thx. |
| 01:39.36 | ``Erik | if it's a memory related issue, make sure swap is enabled and reasonably large if you use linux. Last I checked, the OOM murder code in linux is... odd. :) |
| 01:39.39 | yukonbob | one more q: re: png -> height field -- will the various heights map to a single index so all "0" heights == a certain shade of blue, all "30" height map to same shade of green? |
| 01:39.57 | ``Erik | ->bw, greyscale image |
| 01:40.13 | yukonbob | ``Erik: good point. I'm personally running BSD, but I'd hate to run in on another machine and have it killed after hours of chugging... |
| 01:40.19 | starseeker | I think he wants to use the image data to "shade" a dsp? |
| 01:41.08 | brlcad | yukonbob: the intensity values of the grayscale image will correspond to height values (you set scaling parameters on creation) |
| 01:41.12 | yukonbob | right -- i.e. Imagine an image with a river, a block that is supposed to be a forrest, a road, etc. |
| 01:41.23 | brlcad | you'll then apply whatever colors as a texture |
| 01:41.32 | ``Erik | then there'll be two image files I think, one for the heightmap in bw greyscale, the other in pix for the texture |
| 01:41.54 | brlcad | the projection shader will make the colors map directly onto the surface giving whatever colors for each cell as you want |
| 01:42.24 | yukonbob | will have to experiment and get experience; it's not making sense to me, but it appears to me (by you guy's comments) it's possible... I just need to play, wrap my head around the process. |
| 01:42.50 | yukonbob | thanks again, gentlemen :) |
| 01:42.57 | ``Erik | good luck O.o |
| 01:43.11 | yukonbob | cheers |
| 01:43.55 | brlcad | yukonbob: a related tutorial is the ebm (extruded bitmap) |
| 01:43.56 | brlcad | http://brlcad.org/wiki/EBM |
| 01:44.09 | yukonbob | nice. thx :D |
| 01:44.56 | brlcad | you'll want a dsp instead of an ebm, but it covers basic file conversion |
| 05:34.11 | *** join/#brlcad Ralith (n=ralith@69.90.48.127) |
| 05:41.24 | *** join/#brlcad PrezKennedy (i=Matthew@whitecalf.net) |
| 06:36.12 | *** join/#brlcad FlossLikeYouMean (n=on_Chatz@ip72-198-41-52.ok.ok.cox.net) |
| 08:03.27 | *** join/#brlcad Yoshi47 (n=jan@firewall.walinga.com) |
| 10:21.54 | *** join/#brlcad BigAToo (n=BigAToo@pool-96-230-124-74.sbndin.btas.verizon.net) |
| 11:18.17 | CIA-28 | BRL-CAD: 03Dloman 07http://brlcad.org * r1626 10/wiki/EBM: Quick typo fix. |
| 11:19.19 | ``Erik | excessive bowel movement? O.o |
| 11:23.24 | d-lo | Yes, ``Erik, we have a turd primitive in BRL-CAD. |
| 11:24.35 | ``Erik | damn, there goes that brilliant new use for metaballs |
| 11:26.55 | d-lo | 'brilliant' was quite the word I was going to use lol |
| 11:28.15 | d-lo | s/was/wasn't/ |
| 11:44.20 | ``Erik | freudian slip? :D |
| 11:44.45 | d-lo | yeah... that's it! Right! |
| 11:44.47 | d-lo | :P |
| 11:46.34 | ``Erik | blah, 7:45 already |
| 11:46.42 | ``Erik | puts pants on and starts driving |
| 11:47.21 | d-lo | thats a good order to do things :) |
| 12:41.04 | ``Erik | oh, wait, I listed those as an unordered set, there's supposed to be an order? |
| 12:46.53 | *** join/#brlcad BigAToo (n=BigAToo@64.255.115.3) |
| 13:06.41 | ``Erik | http://www.subblue.com/blog/2009/9/20/quaternion_julia |
| 13:07.28 | starseeker | standard English language convention generally implies temporal coherence in left to right ordering barring specific notation of other organization |
| 13:14.53 | *** join/#brlcad BigAToo (n=BigAToo@64.255.115.3) |
| 13:31.07 | *** join/#brlcad BigAToo (n=BigAToo@64.255.115.3) |
| 13:45.23 | *** join/#brlcad samrose (n=samrose@mi-beaco-rtr-16-59.synergydsl.com) |
| 13:48.20 | CIA-28 | BRL-CAD: 03starseeker * r35972 10/brlcad/trunk/ (5 files in 4 dirs): Start to stub out what is needed for testing a sketch brep conversion. |
| 13:51.31 | *** join/#brlcad PrezKennedy (i=Matthew@whitecalf.net) |
| 14:01.01 | *** join/#brlcad BigAToo (n=BigAToo@64.255.115.3) |
| 14:02.10 | CIA-28 | BRL-CAD: 03starseeker * r35973 10/brlcad/trunk/src/proc-db/csgbrep.cpp: Erm, uncomment some of the other stuff besides sketch... |
| 14:32.02 | CIA-28 | BRL-CAD: 03starseeker * r35974 10/brlcad/trunk/src/proc-db/csgbrep.cpp: few tweaks so a normal sketch is also generated for comparison. |
| 14:33.28 | CIA-28 | BRL-CAD: 03starseeker * r35975 10/brlcad/trunk/src/librt/primitives/sketch/sketch_brep.cpp: Start working through the early phases of the sketch generation logic - will need to have the correct 'environment' set up before it's even worth looking for loops. |
| 14:34.36 | CIA-28 | BRL-CAD: 03bob1961 * r35976 10/brlcad/trunk/src/libdm/color.c: dm_copy_cmap has been changed to _X_copy_cmap. |
| 15:25.19 | brlcad | hehe, he's probably gonna regret that |
| 15:25.31 | brlcad | (victor subscribed to commits) |
| 15:32.26 | ``Erik | mwahahahaha </evillaugh> |
| 15:32.36 | ``Erik | or is it (evillaugh "Mwahahhahaha") |
| 15:43.44 | d-lo | So in the next commit message, someone should put "hi victor!" ? |
| 15:46.36 | brlcad | heh |
| 15:46.42 | CIA-28 | BRL-CAD: 03brlcad * r35977 10/brlcad/trunk/src/mged/attach.c: minor cleanup, remove dead code |
| 15:58.12 | CIA-28 | BRL-CAD: 03brlcad * r35978 10/brlcad/trunk/src/mged/mged.c: more consistency cleanup while reviewing attach. (hi victor!) |
| 15:58.59 | d-lo | ha! |
| 16:13.26 | *** join/#brlcad BigAToo (n=BigAToo@208.95.141.189) |
| 16:54.29 | *** join/#brlcad Ralith (n=ralith@69.90.48.127) |
| 17:01.43 | *** join/#brlcad samrose (n=samrose@adsl-99-131-31-41.dsl.sfldmi.sbcglobal.net) |
| 17:02.18 | ``Erik | now EVERY commit message needs " (hi victor!)" at the end |
| 17:11.46 | starseeker | ``Erik: technically, it's <laugh mode='evil'>Mwahahahahaha</laugh> |
| 17:20.02 | ``Erik | or <laugh><evil>Mwwahhahahaha</evil></laugh> |
| 17:20.59 | starseeker | of course, the truly proper language for an evil laugh has to be Microsoft Visual Basic |
| 17:21.05 | ``Erik | (defclass evil (alignment) ()) (defgeneric laugh ((self evil)) "Mwahahahaha!") |
| 17:21.08 | ``Erik | ((())(()(((()(())(()))) |
| 17:21.12 | starseeker | heh |
| 17:21.13 | ``Erik | (*Y*) |
| 17:21.33 | ``Erik | fires up vim before he hurts himself or someone else |
| 17:22.01 | *** join/#brlcad Axman6 (n=Axman6@pdpc/supporter/student/Axman6) |
| 17:22.02 | ``Erik | (s/generic/method/) |
| 17:47.03 | CIA-28 | BRL-CAD: 03starseeker * r35979 10/brlcad/trunk/include/brep.h: Tighten up the edge miss tolerance some more - really need to do something adaptive to model scale here. |
| 17:47.18 | ``Erik | hum http://www.dadhacker.com/blog/?p=1132 |
| 18:35.19 | *** join/#brlcad Ralith (n=ralith@69.90.48.127) |
| 18:48.05 | brlcad | huh, i swear i've read that before |
| 18:48.13 | brlcad | yet says it posted today |
| 18:49.23 | d-lo | copy paste job perhaps? |
| 18:57.10 | brlcad | dunno, don't see other refs to it |
| 18:57.28 | brlcad | maybe just a really similar posting -- those are very common sentiments |
| 18:57.45 | brlcad | *very* common :) |
| 19:15.12 | Ralith | ? |
| 19:16.15 | starseeker | old school guys not caring for newer paradigms that hide many of the details |
| 19:16.38 | starseeker | (and/or don't deliver what they promised to deliver) |
| 19:17.01 | Ralith | ah. |
| 19:17.22 | ``Erik | ì |
| 19:22.51 | CIA-28 | BRL-CAD: 03brlcad * r35980 10/brlcad/trunk/ (4 files in 3 dirs): (log message trimmed) |
| 19:22.51 | CIA-28 | BRL-CAD: add a '-a' option to mged that allows users to specify a display manager to |
| 19:22.51 | CIA-28 | BRL-CAD: attach to. this avoids the attach prompting seen in interactive mode that |
| 19:22.51 | CIA-28 | BRL-CAD: should help systems that prompt for an attach device even when non-interactive. |
| 19:22.51 | CIA-28 | BRL-CAD: expand the docs with examples including filling in details on the -d display |
| 19:22.52 | CIA-28 | BRL-CAD: option as well. note that you cannot (presently) invoke multiple attachments |
| 19:22.54 | CIA-28 | BRL-CAD: due to the way display manager creation is presently deferred without a little |
| 19:25.29 | CIA-28 | BRL-CAD: 03starseeker * r35981 10/brlcad/trunk/src/librt/primitives/sketch/sketch_brep.cpp: Hmm. How about using the plane to convert the 2 space coordinates to 3 space coordinates... |
| 19:32.44 | CIA-28 | BRL-CAD: 03brlcad * r35982 10/brlcad/trunk/include/brep.h: this header file is included by rtgeom.h for C compiles as well, so no-go on the //isms |
| 19:33.15 | ``Erik | "I tell you what, if I find out I'm having a baby, I'm coming after you" O.O ya overhear the damndest things around here |
| 19:34.24 | starseeker | is afraid to ask... |
| 19:35.03 | d-lo | lol |
| 19:35.11 | brlcad | starseeker: that option is actually kinda odd .. don't know if someone was planning on adding it at some point, but the docs had -c [nu|ogl|X] documented (which afaik has never been valid) |
| 19:35.26 | starseeker | hmm, that is od |
| 19:35.29 | starseeker | er odd |
| 19:35.55 | brlcad | single char args with an optional param aren't common convention either |
| 19:36.19 | brlcad | makes me think someone was just thinking of adding it |
| 19:37.07 | starseeker | I always did wonder why there wasn't some way to specify that without the extra step... |
| 19:37.23 | brlcad | would be cool to expand the deferred startup to accept multiple attachings, even with different display settings |
| 19:37.49 | brlcad | mged -c -a ogl -d secondhost:0 -a X -d third:1 -a ogl |
| 19:38.10 | brlcad | but would have to make a container that stashes the attach type and current display value |
| 19:38.26 | brlcad | so when they're later undeferred, they all create appropriately |
| 19:40.52 | brlcad | anyone have python on windows with a brl-cad install handy? |
| 19:42.33 | starseeker | brlcad: whoops, sorry about the comment |
| 19:43.14 | starseeker | reminds himself to be nice to the C side of the street |
| 19:47.43 | *** join/#brlcad archivist_emc (n=archivis@host81-149-119-172.in-addr.btopenworld.com) |
| 20:25.39 | CIA-28 | BRL-CAD: 03starseeker * r35983 10/brlcad/trunk/src/librt/primitives/sketch/sketch_brep.cpp: OK, first baby step - create straight line edges from the line segments. They line up, so checkpoint. |
| 20:41.53 | CIA-28 | BRL-CAD: 03starseeker * r35984 10/brlcad/trunk/src/librt/primitives/sketch/sketch_brep.cpp: Add edges from full circles. |
| 20:48.32 | CIA-28 | BRL-CAD: 03brlcad * r35985 10/brlcad/trunk/src/mged/mged.c: allow a display manager to be attached even if we're running the tk gui -- make sure we attach if the user requested it. |
| 20:49.03 | CIA-28 | BRL-CAD: 03brlcad * r35986 10/brlcad/trunk/doc/docbook/system/man1/en/mged.xml: pedantic blank line was added (so error messages don't overlap the prompt) |
| 21:00.25 | CIA-28 | BRL-CAD: 03starseeker * r35987 10/brlcad/trunk/src/librt/primitives/sketch/sketch_brep.cpp: Punt on arcs for the moment - logic is surprisingly complex to extract what is needed to get a 3rd point for the opennurbs arc routine. reference where in sketch.c to look for later. |
| 21:01.03 | CIA-28 | BRL-CAD: 03brlcad * r35988 10/brlcad/trunk/src/mged/ (attach.c cmd.c cmd.h mged.c mged.h): refactor los tres amigos into one function to remove code duplication. propagate a const as consequence. |
| 21:02.35 | CIA-28 | BRL-CAD: 03brlcad * r35989 10/brlcad/trunk/src/mged/ (cmd.c cmd.h): more const propagation |
| 21:03.53 | CIA-28 | BRL-CAD: 03brlcad * r35990 10/brlcad/trunk/BUGS: if you attach a display manager in tk-mged, kill the window, then quit, mged crashes on exit. pretty likely that mged is trying to destroy the already destroyed window, of course. observed on osx 10.4 |
| 21:08.20 | CIA-28 | BRL-CAD: 03brlcad * r35991 10/brlcad/trunk/include/ (dm-X.h dm-ogl.h dm-rtgl.h dm-tk.h dm-wgl.h): dm_color.h is obsolete (albeit marked deprecated), don't include it. |
| 21:15.22 | CIA-28 | BRL-CAD: 03starseeker * r35992 10/brlcad/trunk/src/librt/primitives/sketch/sketch_brep.cpp: Woot. Get the bezier stuff working - can now draw all the lines of the default sketch object. Now for the hard part - building trims and loops. |
| 21:20.42 | CIA-28 | BRL-CAD: 03brlcad * r35993 10/brlcad/trunk/src/mged/mged.c: quell all pedantic compilation warnings (sans long-long and format) |
| 21:24.10 | CIA-28 | BRL-CAD: 03brlcad * r35994 10/brlcad/trunk/src/mged/mged.c: lotta dead code elimination. |
| 21:52.47 | *** join/#brlcad samrose (n=samrose@173-110-143-189.pools.spcsdns.net) |
| 21:52.54 | *** join/#brlcad BigAToo (n=BigAToo@pool-96-230-124-74.sbndin.btas.verizon.net) |
| 22:10.08 | *** join/#brlcad Ralith (n=ralith@69.90.48.127) |
| 23:02.27 | *** join/#brlcad ``Erik (i=Here@c-69-140-109-104.hsd1.md.comcast.net) |
| 23:07.27 | *** join/#brlcad ``Erik (i=Here@c-69-140-109-104.hsd1.md.comcast.net) |