| 01:52.31 | *** join/#brlcad BigAToo (n=BigAToo@pool-96-230-124-196.sbndin.btas.verizon.net) | |
| 07:34.47 | *** join/#brlcad _clock_ (n=_sushi_@77-58-151-159.dclient.hispeed.ch) | |
| 08:51.36 | CIA-32 | BRL-CAD: 03Ralith 07http://brlcad.org * r1514 10/wiki/User:Ralith: Log for 2009-06-28 |
| 09:42.12 | *** join/#brlcad IriX64 (n=IriX64@bas2-sudbury98-1096600584.dsl.bell.ca) | |
| 11:14.14 | d-lo | merinin all! |
| 11:17.53 | d-lo | Ralith: How goes the conflict resolution? |
| 11:30.30 | *** join/#brlcad BigAToo (n=BigAToo@pool-96-230-124-196.sbndin.btas.verizon.net) | |
| 11:37.41 | *** join/#brlcad Elrohir (n=kvirc@p5B14FD98.dip.t-dialin.net) | |
| 13:11.28 | *** join/#brlcad elena (n=elena@89.136.118.141) | |
| 13:13.31 | CIA-32 | BRL-CAD: 03ebautu * r34893 10/web/trunk/htdocs/more/sites/all/modules/brlcad/ (. brlcad.info brlcad.install brlcad.module): BRL-CAD integration module (initial commit) |
| 13:44.22 | brlcad | hi elena! |
| 13:44.27 | brlcad | welcome back |
| 13:44.29 | elena | hi. |
| 13:44.32 | elena | thank you. |
| 13:44.40 | brlcad | have a good trip? |
| 13:44.44 | elena | yes. |
| 13:44.55 | elena | I was just about to ask some help here :) |
| 13:45.02 | elena | but first, how are you? |
| 13:52.05 | brlcad | i'm doing great, had a fantastic weekend |
| 13:52.28 | elena | wonderfull. I'm glad to hear that. |
| 13:52.45 | brlcad | wonderful wine tasting event and dinner with friends on saturday, latino festival on sunday :) |
| 13:53.03 | elena | that sounds very nice. |
| 13:53.24 | elena | what kind of festival? |
| 13:53.42 | elena | I mean: dancing, food, etc? |
| 13:53.45 | brlcad | yeah |
| 13:53.56 | elena | ok. |
| 13:54.14 | brlcad | concerts going, lots of great food, music, dancing |
| 13:54.40 | brlcad | the wine tasting was aboslutely spectacular, a real highlight |
| 13:54.41 | elena | in your town or traveling? |
| 13:54.54 | brlcad | in baltimore |
| 13:56.27 | elena | do you have time to give me some tips on raytraceing models? |
| 13:57.46 | brlcad | sure, is this for generating pictures? |
| 13:58.02 | elena | yes. |
| 13:58.25 | elena | I'm not sure if I should use mged and the rt command |
| 13:58.35 | brlcad | that's probably the best way |
| 13:58.36 | elena | or only the rt tool. |
| 13:58.48 | elena | ok. then I know how to do it. |
| 13:58.55 | brlcad | running through mged will make it a little easier to set up the view |
| 13:59.03 | elena | yes. exactly. |
| 13:59.09 | elena | another problem. |
| 13:59.59 | elena | is there a way to setup the view size so that it best fits the model? |
| 14:00.09 | brlcad | heh |
| 14:00.14 | brlcad | was just going to comment on that |
| 14:00.16 | brlcad | yes and no |
| 14:00.24 | brlcad | the 'autoview' command fits the model to the view |
| 14:00.33 | brlcad | but it does a guarantee fit, not necessarily a best fit |
| 14:00.43 | elena | that's ok. |
| 14:00.50 | brlcad | you'll probably want to run "zoom 2" on everything being rendered |
| 14:00.51 | elena | i didn't know about autoview. |
| 14:01.05 | elena | ok. i'll do some tests. |
| 14:01.17 | brlcad | if there is nothing displayed, and you 'draw'/'e' something up, it'll autoview automatically |
| 14:01.26 | elena | i tried some hacks with grouping objects. not very successful. |
| 14:02.13 | elena | and I was thinking to do something like: |
| 14:02.16 | elena | draw * |
| 14:02.20 | brlcad | oh, no |
| 14:02.23 | elena | rt -o model.pix |
| 14:02.24 | brlcad | don't do that :) |
| 14:02.28 | elena | why? |
| 14:02.37 | brlcad | "draw *" is very bad |
| 14:02.39 | elena | and what's the alternative. |
| 14:02.47 | elena | ? |
| 14:03.08 | brlcad | that means draw every single object and shape in the database |
| 14:03.09 | elena | because it draws all objects? |
| 14:03.20 | elena | yes. |
| 14:03.29 | elena | what's the alternative? |
| 14:03.52 | elena | so I have a database that the user uploaded. |
| 14:04.09 | elena | and I want to get the images from different angles. |
| 14:04.22 | brlcad | so if the objects were text, and a word is a union of the letters, and a phrase is a grouping of multiple words, like "Hello world" |
| 14:04.31 | elena | I'll use ae to set the angle, autoview to fit the object. |
| 14:05.06 | elena | go on... |
| 14:05.28 | brlcad | saying "draw *" is effectively, "draw H", "draw e", "draw l", "draw l", "draw o", "draw ' '", "draw Hello", "draw world", "draw Hello world" |
| 14:06.05 | brlcad | it's everything including all uses and groupings .. not what you want, you want just the last one "draw Hello world" |
| 14:07.00 | brlcad | moreover with brl-cad geometries, our format supports an arbitrary number of models per file, so there could be lots of 'main' objects, not necessarily just one |
| 14:07.18 | brlcad | to find a starting point, you run the "tops" command |
| 14:07.22 | brlcad | that lists the top-level objects |
| 14:07.41 | brlcad | normally, one or more of those is a primary |
| 14:07.57 | elena | and draw that. |
| 14:08.01 | elena | ok. makes sence. |
| 14:08.01 | brlcad | right |
| 14:08.22 | elena | can I do draw and tops in one command? |
| 14:08.33 | elena | something like draw `tops` ? |
| 14:08.40 | brlcad | you can, but you also don't want that |
| 14:08.45 | elena | i think I can. I'll look. |
| 14:08.49 | brlcad | that would imply they had something to do with each other |
| 14:08.52 | elena | no? why? |
| 14:09.02 | brlcad | they're top-level because they are independent |
| 14:09.05 | elena | you're reading my thoughts before I type :) |
| 14:09.21 | brlcad | .g files are collections of trees of geometries. |
| 14:09.35 | brlcad | there may be one tree, there may be twenty trees |
| 14:09.48 | elena | how would you approach this? |
| 14:09.48 | brlcad | you've seen the example .g files, yes? |
| 14:09.53 | elena | yes. |
| 14:10.17 | brlcad | I could very trivially combine them all into one single .g file and it would be perfectly valid |
| 14:10.34 | brlcad | there'd just be a lot of top-level objects |
| 14:10.52 | elena | that will alter the db, too, right? |
| 14:11.01 | brlcad | what do you mean? |
| 14:12.01 | brlcad | i mean those 20+ separate files are only separated by convention, I could combine them together and it's a valid .g |
| 14:12.13 | elena | in mged. if I do a group. |
| 14:12.30 | elena | that group will instantly be saved in the database. |
| 14:12.34 | brlcad | i mean literally, you can "cat *.g > everything.g" .. bad thing to do, but entirley valid |
| 14:12.51 | elena | I didn't know that. |
| 14:13.05 | brlcad | creating a group in mged is a different thing altogether -- that basically creates a new top-level object |
| 14:13.13 | brlcad | and if the things you're grouping were top-level, they no longer are |
| 14:13.50 | brlcad | it's a set of directed acyclic graphs, with named references |
| 14:14.04 | elena | but in our case, the user will upload only one file. |
| 14:14.22 | brlcad | one _file_ .. but that file could be anything |
| 14:14.34 | elena | cool. let me play some more with what you told me and I'll get back. |
| 14:14.43 | *** join/#brlcad mafm (n=mafm@165.Red-81-35-69.dynamicIP.rima-tde.net) | |
| 14:14.44 | brlcad | so you're going to have to either just import all top-level objects |
| 14:14.52 | elena | i'll buzz you or cliff some more if I don't manage it myself. |
| 14:14.54 | brlcad | or have the user specify which object to import |
| 14:15.28 | brlcad | you definitely should not be creating groups or geometry |
| 14:15.43 | elena | yes. I imagine that. |
| 14:16.03 | elena | this is why I was looking for the autoview-style solution also. |
| 14:16.19 | brlcad | for safety, you may even want to store the files as read-only, 444 or something |
| 14:16.43 | elena | i'll look into that, too. |
| 14:17.18 | elena | i think i lost some time trying to make a lot of customizations that proved not that important. |
| 14:17.33 | elena | on the processing queue part. |
| 14:17.57 | elena | but they led to a simpler solution :) |
| 14:18.01 | brlcad | here's a good example, if you look at the havoc.g example file .. and run tops |
| 14:18.07 | brlcad | you'll see there are three top-level objects |
| 14:18.16 | brlcad | BRL-GSI_EFFORT/ havoc/ sun/R |
| 14:18.45 | brlcad | you don't know which of those is important without asking the user |
| 14:19.03 | brlcad | so you either import all three, or have the user prompt (in this case, havoc is the important one) |
| 14:19.28 | brlcad | prompting is probably best as the important object is often not even a top-level |
| 14:19.48 | elena | but if i have a different format |
| 14:19.51 | brlcad | the m35.g file is another good example |
| 14:20.09 | elena | then that might not have objects in it. |
| 14:20.14 | brlcad | 8 top-level objects: 2 assemblies, 2 primitives, 4 regions |
| 14:20.41 | brlcad | all formats have at least one object in them :) |
| 14:21.02 | brlcad | it's just many are actually contrained to exactly one object, |
| 14:21.16 | elena | what is _GLOBAL? |
| 14:21.19 | brlcad | like the stl file format, one object |
| 14:21.24 | brlcad | it's a non-geometric object |
| 14:21.30 | brlcad | file attributes |
| 14:21.40 | elena | aha. |
| 14:21.44 | brlcad | stores things like title and the working units |
| 14:21.52 | elena | ok. thank you for your help. |
| 14:23.21 | brlcad | no problemo, keep the questions coming |
| 14:23.57 | elena | :) |
| 14:34.21 | mafm | hi |
| 14:34.54 | elena | hi |
| 14:36.35 | brlcad | hi |
| 14:47.14 | *** join/#brlcad Ralith_ (n=ralith@216.162.199.202) | |
| 14:47.24 | starseeker | hey elena |
| 14:47.39 | elena | hi starseeker. |
| 14:47.46 | d-lo | hi! |
| 14:47.52 | starseeker | welcome back :-) |
| 14:47.57 | elena | thank you :) |
| 14:48.13 | elena | how have you been? |
| 14:48.26 | elena | hi d-lo. |
| 14:51.48 | d-lo | WIth all this greeting action happening, I just had to get in on it. |
| 14:51.58 | starseeker | would actually recommend requiring the user to specify at least one named "primary" db object, or example, or something like that |
| 14:52.02 | elena | :)) |
| 14:53.33 | starseeker | or, since user laziness usually wins, grab the tops list, generate some default raytraces, and present them a list of images asking them to select the correct toplevel images |
| 14:53.40 | elena | will that work with other formats, too? |
| 14:53.51 | starseeker | hard to say |
| 14:54.28 | brlcad | that'll for for most all formats simply because we're a superset format |
| 14:54.30 | starseeker | logically speaking, the first thing to check is whether there is a toplevel object named <filename> if the file is called filename.g |
| 14:54.44 | elena | what would be the purpose of creating a top object if you don't use it in the final render? |
| 14:54.46 | starseeker | (e.g. havoc in havoc.g) |
| 14:55.06 | starseeker | sometimes you want to quickly show different aspects of a design |
| 14:55.17 | brlcad | starseeker: that's more the exception than the rule, depends which org/person is modeling |
| 14:55.39 | brlcad | for a decade, the convention was to group your primary into an "all.g" object |
| 14:55.59 | starseeker | models can get very complex, and if you want to show someone just "this part, this part, and this part" multiple times in different situations it's a quick and easy way to have it available |
| 14:56.16 | starseeker | brlcad: that's unfortuante, really - it would be a very logical convention |
| 14:57.18 | starseeker | elena: then in that case I'd suggest presenting the user with visuals of the top level objects and let them tell you which ones to pay attention to :-/ |
| 14:57.56 | elena | ok. i'll try to do that. |
| 14:58.20 | elena | then submitting has to be a two step process. |
| 14:58.25 | brlcad | starseeker: remember the filename can vary drastically (stryker_dlo_20040329.g) too .. I wouldn't assume anything based on filename |
| 14:58.37 | brlcad | you can't even really assume it's a top-level you want, but that's a good starting point |
| 14:58.45 | elena | first submit the file, then (next step) select the object names. |
| 14:58.47 | brlcad | elena: what you could do is simply show them the hierarchy |
| 14:58.50 | brlcad | let them pick the point |
| 14:59.03 | brlcad | for simple formats, it's just an object, or list of objects |
| 14:59.06 | d-lo | will ignore the stryker comment... :P |
| 14:59.26 | brlcad | for hierarchical formats, you display a collapsed tree |
| 14:59.54 | elena | maybe multiple select? |
| 14:59.58 | brlcad | sure |
| 15:00.03 | elena | ok. |
| 15:00.07 | brlcad | but selecting selects that entire subtree |
| 15:00.15 | elena | yes. |
| 15:00.46 | brlcad | hm, actually there's no real need to impose that limitation .. it's just whatever nodes they select |
| 15:01.22 | elena | yes. it's more in tone with the hello world example :) |
| 15:03.23 | brlcad | chuckles that dlo is the name of an ipod/iphone accessory manufacturer, particularly in the context of stryker |
| 15:03.38 | brlcad | and then there's the stryker sonoma winery ;) |
| 15:04.46 | d-lo | wha.... I'm getting a lawyer! They stolededed my irc handle! |
| 15:18.44 | *** join/#brlcad BigAToo (n=BigAToo@64.74.225.82) | |
| 15:34.34 | starseeker | d-lo: so with a lawyer, you'll be both broke and annoyed rather than just annoyed? ;-) |
| 15:35.26 | d-lo | lol nice. unless... wait a minute.... a close relative ISA lawyer and owes me a favor.... hrm..... |
| 15:36.30 | d-lo | visualizes himself standing ontop of a burning, ruined building which use to be 'dlo HQ - makers of iPhone/iPod accessories"... |
| 15:38.06 | ``Erik | heh, 'cept dlo.com is a subsidiary of phillips |
| 15:38.33 | d-lo | orly? Phillips wants some too eh? |
| 15:38.38 | ``Erik | imagines they might have a bit of legal flex :D plus going back to '01 |
| 15:39.37 | d-lo | i can see it now on /. : Philips Legal dept gets omgwtfpwnd by loudmouth government employee.... |
| 15:39.44 | d-lo | =D |
| 15:40.42 | ``Erik | given the accuracy of /. headlines and summaries, that might be posted |
| 15:41.12 | ``Erik | that bug totally owned that speeding car, look at that ugly greasemark on the grill! PWN3d!#~@ |
| 15:41.38 | louipc | why not just ask the user what object he/she wants to use for the preview pic? |
| 15:42.13 | starseeker | still has not forgiven slashdot for that premature/wrong announcement of the original Apollo 11 tapes turning up |
| 15:42.22 | starseeker | talk about a letdown... |
| 15:42.34 | louipc | hah |
| 15:43.26 | starseeker | bets they were erased and re-used - sounds just like "policy" on such tapes... heck with history, it's the policy and we're following it |
| 15:43.33 | d-lo | lol |
| 15:44.15 | d-lo | at the viewing of those Apollo 11 tapes, somehow pron ends up on the overhead screen....lol |
| 15:44.30 | starseeker | that really does suck big time - one of the great events in the history of human beings AS A SPECIES and they went missing |
| 15:44.31 | ``Erik | was just thinking that o.O |
| 15:44.34 | starseeker | cries |
| 15:45.09 | d-lo | starseeker: didn't you hear? thats tnhe main reason we are going back in 2020... gotta remake the tapes. |
| 15:45.13 | ``Erik | "houston, apogee attained, now firin*TSSHT* uhh uhhh uhhh oh yeah uhhh" |
| 15:45.33 | d-lo | Apollo 11... is that a funky saxaphone? |
| 15:45.53 | louipc | yeah you'd think they'd save something like that |
| 15:46.33 | starseeker | still wants to figure out some way to spend a decade or two with the Saturn V technical archives and a wide format scanner in his retirement years... |
| 15:47.06 | ``Erik | and then model it down to the bolt threads? |
| 15:47.24 | starseeker | you got it |
| 15:47.40 | d-lo | ...for the hallibut? |
| 15:48.00 | ``Erik | biggest cadpeen ever |
| 15:49.12 | starseeker | thinks such an accomplishment is worth documenting in detail |
| 15:49.45 | louipc | well, it's on paper :D |
| 15:49.57 | starseeker | louipc: my point exactly :-/ |
| 15:50.32 | ``Erik | paper isn't what it used to be, 60's paper and ink are probably already in bad shape :/ |
| 15:50.38 | starseeker | and everything I've see suggests that the filing system used is probably.... well... I guess we'll got with inadequate |
| 15:50.48 | ``Erik | acidic paper eats itself up |
| 15:50.52 | ``Erik | ask tufte O.o |
| 15:51.25 | louipc | so this is something you probably want to do now, rather than wait for retirement... |
| 15:52.39 | starseeker | louipc: I have no clue how to get the funding it would take to do that, even assuming they would let me... |
| 15:53.53 | starseeker | plus, I've got a few things to do first :-) |
| 15:54.07 | starseeker | doesn't want to model a Saturn V with mged as a modeler... |
| 15:54.24 | louipc | haha |
| 15:54.41 | louipc | yeah but the scanning will be enough work |
| 15:54.51 | starseeker | that's for sure |
| 15:55.02 | d-lo | modling it by hand would be faster :) |
| 15:55.17 | d-lo | holey bad speling dai batman... |
| 15:55.26 | ``Erik | sure you do, perfect way to isolate usability issues in the interface and fix 'em :D |
| 15:56.21 | starseeker | the stages would be 1. high res scan every sheet of paper related 2. invent an organizational scheme that would actually work and sort everything into it 3. recruit the internet to make svg versions of the 2d drawings so you can actually work with 'em 4. cad model that baby |
| 15:56.26 | brlcad | starseeker: more than likely, it's like our taps -- there's a bigass stack of a couple hundred sitting off in some room, maybe a summer intern or two worked on archiving, but mostly still gestating |
| 15:56.41 | brlcad | s/taps/tapes/ |
| 15:56.58 | ``Erik | crowdsourcing, pheer |
| 15:57.00 | starseeker | brlcad: fingers crossed - if that's the case they might yet be found |
| 15:57.44 | brlcad | I doubt they're actually "lost" .. there's probably just only two or three people that know where they're at, just like ours :) |
| 15:57.58 | ``Erik | heh |
| 15:57.59 | starseeker | ``Erik: inkscape + 2000 space nerds with no social life - that's a force to be respected ;-) |
| 15:58.36 | starseeker | expensive part is a wide format scanner plus the manhours of scanning required |
| 15:59.04 | starseeker | wonders why he didn't think of trying to get that into the stimulus bill... |
| 15:59.06 | ``Erik | just a few years ago, they found the french commission papers for the two "english" ships captain kidd had taken, supposedly proof that he was a legal privateer and not a pirate O.o misplaced media is a bitch |
| 15:59.33 | starseeker | heh |
| 15:59.55 | ``Erik | hung because someone misfiled a paper |
| 15:59.59 | louipc | you have to get into NASA before step 1 |
| 16:00.20 | starseeker | louipc: actually, their records are part of the public archives now (at least from that era) |
| 16:00.24 | starseeker | some of them, anyway |
| 16:00.32 | louipc | oh cool |
| 16:01.22 | starseeker | check out this dude's site: http://www.ibiblio.org/apollo/ |
| 16:02.00 | ``Erik | nasa doesn't have the budget or impetus to be very secretive O.o they mostly use russian agencies for lifting these days heh |
| 16:03.12 | starseeker | specifically, http://www.ibiblio.org/apollo/QuestForInfo.html |
| 16:04.26 | starseeker | he's done some Really Impressive Work digging up info |
| 16:05.06 | starseeker | the government archives are beyond doubt repositories of lots of really neat historical treasures that nobody knows how to find and nobody cares enough to sort through |
| 16:10.59 | ``Erik | shoulda brought in a tv dinner |
| 16:13.16 | *** join/#brlcad jdoliner (n=jdoliner@c-68-51-75-169.hsd1.il.comcast.net) | |
| 16:14.25 | jdoliner | sean slash indianlarry, or anyone else who's interested. Would you be help me with an algorithm here? |
| 16:14.35 | jdoliner | I'm kind of stuck |
| 16:15.19 | ``Erik | what algo? |
| 16:15.59 | jdoliner | unfortunately I don't have the name so I'll have to describe it |
| 16:16.12 | ``Erik | psuedocode in pastebin? |
| 16:16.26 | jdoliner | pastebin? |
| 16:16.51 | jdoliner | it's more I need help devising the algorithm |
| 16:16.56 | ``Erik | http://pastebin.bzflag.bz/ |
| 16:16.59 | ``Erik | ah, ok |
| 16:17.06 | ``Erik | shuts up and listens |
| 16:18.15 | jdoliner | so I have my code all setup to take two meshes, and return as polylines the trimming curves between them |
| 16:19.06 | jdoliner | so that's nice and all but know I need to talk that polyline and use it to split each mesh into two meshes, the one inside the other mesh and the one outside |
| 16:19.11 | jdoliner | and I' |
| 16:19.14 | jdoliner | m not sure |
| 16:19.21 | jdoliner | of the best way to do that |
| 16:19.36 | jdoliner | do you think it's a better idea to do it afterward using the polyline |
| 16:20.10 | ``Erik | by "mesh", you don't mean a mesh, but a NURBS, right? |
| 16:21.22 | jdoliner | no I mean an ON_Mesh |
| 16:21.52 | jdoliner | it's still discrete geometry at this point and not parametric |
| 16:21.53 | ``Erik | painkillers have me fuzzy, here, I'll throw something at the back of indianlarrys head |
| 16:22.33 | ``Erik | if it's triangles, any line cutting through a triangle will produce 2 triangles... I d'no ON_Mesh |
| 16:22.46 | indianlarry | hey joe |
| 16:22.48 | jdoliner | it's triangles or quads |
| 16:22.49 | jdoliner | hi |
| 16:23.02 | indianlarry | catchin up... |
| 16:23.27 | jdoliner | but lines don't necessarily cut all the way through on a triangle |
| 16:23.36 | ``Erik | (wait, some lines will produce a quad, but those can be broken into two triangles) |
| 16:23.46 | jdoliner | yeah |
| 16:24.18 | jdoliner | but you could also have a triangle broken up by not just one line but a whole bunch of little lines |
| 16:24.37 | jdoliner | if for example one mesh has much smaller details than the other |
| 16:25.22 | ``Erik | by casting vertex to vertex, you can cut polygons into triangles |
| 16:26.32 | ``Erik | do it recursively and you have a fully triangulated mesh *shrug* but the vicodin has me goofy, indianlarry will come up with something brilliant here... |
| 16:26.33 | jdoliner | yes, on of my ideas involves doing that |
| 16:27.24 | indianlarry | definitely need resolution to capture the smallest details |
| 16:27.51 | indianlarry | we are currently working similar issue with nurbs trims |
| 16:27.54 | ``Erik | (mebbe an aggressive splitting algo followed by a decimation pass?) |
| 16:28.07 | jdoliner | no I'm not |
| 16:28.30 | jdoliner | oh you are sry |
| 16:28.48 | jdoliner | so here's my one idea which I think could work |
| 16:29.19 | jdoliner | right now I have it all setup to find every intersection line |
| 16:29.28 | jdoliner | load it into an array |
| 16:29.45 | jdoliner | and then at the end it goes through and reconstructs these into the polylines |
| 16:30.05 | jdoliner | now instead of doing exactly that |
| 16:30.39 | jdoliner | I can keep track of which faces the lines came from |
| 16:31.09 | jdoliner | by loading them into arrays for each face |
| 16:31.16 | indianlarry | i would think you'd want to track which face it belongs too |
| 16:32.17 | indianlarry | need to remember that trimming edges within a face have to show direction/inner/outer |
| 16:32.18 | jdoliner | yeah then when I run my algorithm on the lines from each seperate face. I get a polyline that indicates exactly how each face should be split up |
| 16:32.31 | jdoliner | yes that's my question |
| 16:32.35 | jdoliner | how should I do that |
| 16:32.37 | jdoliner | ? |
| 16:33.04 | indianlarry | just thinking out loud |
| 16:33.43 | jdoliner | well I can test points for being inside or outside the meshes |
| 16:33.46 | indianlarry | if your intersection coisides with an outer edge at any point the intersection becomes an outer edge ? |
| 16:33.58 | indianlarry | sorry coincides |
| 16:34.17 | jdoliner | sry I don't follow |
| 16:34.23 | jdoliner | waht do you mean by outer edge |
| 16:34.24 | jdoliner | ? |
| 16:34.56 | indianlarry | guess your working with simple faces which only have an outer trim? |
| 16:35.05 | jdoliner | yeah |
| 16:36.10 | indianlarry | a corner intersecting a face could still produce an inner loop? |
| 16:36.28 | jdoliner | yes |
| 16:38.10 | jdoliner | so one option that I see |
| 16:38.31 | jdoliner | is that I can pretty easily test a point for being inside our outside a mesh |
| 16:38.52 | jdoliner | it just takes linear time with the number of triangles |
| 16:39.07 | jdoliner | (which is kinda big) |
| 16:39.14 | jdoliner | but once I have that point |
| 16:39.20 | jdoliner | then anything that's connected to it |
| 16:40.18 | jdoliner | is also on the same side of the mesh |
| 16:41.45 | jdoliner | so we would really only need to do one point per connected region which isn't so unreasonable |
| 16:43.24 | indianlarry | do brep meshes have trim loops or do they just get subdivided into smaller meshes |
| 16:44.15 | jdoliner | they do not have trim loops |
| 16:44.29 | indianlarry | okay |
| 16:47.58 | indianlarry | you'd thnk there wold be a way to track edge direction to help out here |
| 16:49.11 | indianlarry | ust keep visualizing the corner into the center of a face problem |
| 16:50.39 | jdoliner | k, will do |
| 16:50.48 | indianlarry | each facet or quad has defined outward pointing normal? |
| 16:51.08 | jdoliner | yes, by right hand rule |
| 16:51.35 | jdoliner | hmm |
| 16:51.58 | jdoliner | I think I need to look back at my lower level functions |
| 16:52.41 | indianlarry | each facet or quad that is intersected could then be subdivided into inside outside? |
| 16:52.48 | jdoliner | I bet that they consistantly indicate something with the direction the resultant edge points |
| 16:53.07 | indianlarry | thats how they do it with the nurbs trims |
| 16:54.21 | indianlarry | you could almost create your own polyline trimming loops |
| 16:56.00 | jdoliner | yeah I think I can |
| 16:56.08 | jdoliner | I mean I think that's what my code in the present state does |
| 16:56.26 | indianlarry | need to keep the loops by face then inner/outter |
| 16:57.11 | *** join/#brlcad BigAToo (n=BigAToo@pool-96-230-124-196.sbndin.btas.verizon.net) | |
| 16:58.08 | jdoliner | oh here's an interesting fact: |
| 16:58.51 | jdoliner | if we intersect triangles abc and def |
| 16:59.37 | jdoliner | then the dot product of (d-a) and the normal of abc is positive if d is on the external side of abc |
| 17:03.06 | indianlarry | just tells you which side d is on holds for any point |
| 17:05.29 | jdoliner | yeah, it only indicates ternality if there's nothing intersecting def between the line that abc leaves and d |
| 17:08.58 | indianlarry | if you store the intersect polyline by face you should be able to use it with right-hand-rule to subdivide you facets/mesh |
| 17:10.00 | indianlarry | if polyline intersects face edge its an outer type loop otherwise an inner loop |
| 18:01.30 | CIA-32 | BRL-CAD: 03irpguardian * r34894 10/brlcad/trunk/src/proc-db/human.c: |
| 18:01.30 | CIA-32 | BRL-CAD: Added needed data to allow poseable left arm, with connected parts and joints. |
| 18:01.33 | CIA-32 | BRL-CAD: Bounding boxes for those limbs have been removed until a better method is devised. |
| 18:05.56 | *** join/#brlcad _sushi_ (n=_sushi_@80-218-237-16.dclient.hispeed.ch) | |
| 18:26.11 | CIA-32 | BRL-CAD: 03homovulgaris * r34895 10/brlcad/trunk/src/libged/cc.c: cc : input from commandline rather than hardcoded data |
| 19:00.25 | CIA-32 | BRL-CAD: 03brlcad * r34896 10/brlcad/trunk/src/mged/Makefile.am: we needed the mged_LINK in order to override LDFLAGS when we had a custom tk, but that's not the case any longer. problem came up where we needed one of the globally set LDFLAGS. |
| 19:04.34 | CIA-32 | BRL-CAD: 03brlcad * r34897 10/brlcad/trunk/configure.ac: |
| 19:04.36 | CIA-32 | BRL-CAD: apply a fugly workaround for the Mac OS X 10.5 linker problem whereby it fails |
| 19:04.38 | CIA-32 | BRL-CAD: saying 'ld: cycle in dylib re-exports with /usr/X11/lib/libGL.dylib'. the |
| 19:04.42 | CIA-32 | BRL-CAD: problem appears to be the glx internals making calls into the GL framework, |
| 19:04.44 | CIA-32 | BRL-CAD: which ends up finding the wrong (same) dylib during load. the 'fix' is to tell |
| 19:04.49 | CIA-32 | BRL-CAD: it exactly where the framework dylib lives, which is done via a project-wide |
| 19:04.51 | CIA-32 | BRL-CAD: LDFLAGS so we don't have to pollute all the places it would be needed. |
| 19:44.04 | CIA-32 | BRL-CAD: 03brlcad * r34898 10/brlcad/trunk/BUGS: mged rotation halts after a few events once a model is e'd up and you zoom in/out (at least with mouse). seems to be specific to mac 10.5 |
| 19:45.25 | CIA-32 | BRL-CAD: 03brlcad * r34899 10/brlcad/trunk/BUGS: kill command (and probably others) in archer is horked. |
| 20:07.56 | CIA-32 | BRL-CAD: 03brlcad * r34900 10/brlcad/trunk/BUGS: mged crashes inside X_choose_visual() with default X11 libdm interface on mac os x 10.5 (fbserv seemed to be fine) |
| 20:56.41 | CIA-32 | BRL-CAD: 03irpguardian * r34901 10/brlcad/trunk/src/proc-db/human.c: |
| 20:56.42 | CIA-32 | BRL-CAD: Created a new function for creating the entire left arm, allowing for the arm to pivot |
| 20:56.44 | CIA-32 | BRL-CAD: around the shoulder joint, and have all connected parts of the arm point in the same |
| 20:56.46 | CIA-32 | BRL-CAD: direction. |
| 21:33.33 | elena | how can I ran multiple mged commands from the command line? |
| 21:33.56 | elena | something like mged -cr something.g "tops;tops" |
| 21:37.31 | elena | I got it. |
| 21:39.26 | CIA-32 | BRL-CAD: 03ebautu * r34902 10/web/trunk/htdocs/more/sites/all/modules/brlcad/brlcad.module: Update BRL-CAD module (raytracing code is work in progress). |
| 21:40.03 | brlcad | something exactly like that |
| 21:40.43 | elena | i only got it working with echo -e tops\\ntops | mged -cr something.g |
| 21:41.21 | CIA-32 | BRL-CAD: 03Ebautu 07http://brlcad.org * r1517 10/wiki/More_Changelog: /* June, 17 - today */ |
| 21:41.38 | elena | going to bed. have a great afternoon. |
| 22:06.19 | mafm | uh |
| 22:06.34 | mafm | elena working in raytracing code? |
| 22:07.02 | louipc | to generate preview images for the model repository |
| 22:07.15 | mafm | oh |
| 22:07.30 | mafm | I was getting worried about creating a raytracer in php or something :P |
| 22:07.43 | louipc | bahhah |
| 22:08.05 | *** join/#brlcad BigAToo1 (n=BigAToo@pool-96-230-124-196.sbndin.btas.verizon.net) | |
| 22:08.14 | mafm | brl-cad web on esteroids :P |
| 22:08.25 | ``Erik | raytracer in javascript, pheer |
| 22:10.57 | mafm | :D |
| 22:13.17 | *** join/#brlcad Elrohir (n=kvirc@p5B14FD98.dip.t-dialin.net) | |
| 22:17.36 | *** part/#brlcad jdoliner (n=jdoliner@c-68-51-75-169.hsd1.il.comcast.net) | |
| 22:42.37 | *** join/#brlcad CIA-30 (n=CIA@208.69.182.149) | |
| 22:43.59 | *** join/#brlcad alecs1 (i=alex@193.170.133.88) | |
| 22:50.28 | *** join/#brlcad samrose (n=samrose@c-24-11-214-181.hsd1.mi.comcast.net) | |
| 23:01.12 | Ralith_ | d-lo: I've got several ideas, although my first hacks didn't pan out. |
| 23:01.30 | Ralith_ | they're just getting increasingly nontrivial and equally not guaranteed to success |
| 23:03.38 | ``Erik | anything guaranteed to succeed is boring O.o d-lo probably won't see this for another 12 hours or so, though |
| 23:10.09 | Ralith | true enough |
| 23:11.16 | louipc | what is guaranteed to success? |
| 23:15.28 | ``Erik | bets he could write "hello world" and get it to compile the very first time :D |
| 23:17.22 | mafm | ``Erik: but it will be buggy! http://www.ddj.com/hpc-high-performance-computing/217801225 |
| 23:18.03 | ``Erik | that's too much reading for me, I'm illiterate |
| 23:18.35 | starseeker | Ralith: have you considered contacting the Qt folks to see if they can steer you towards the parts working the reset magic? |
| 23:19.09 | mafm | (erm, page 2, about errors of "hello world" programs in C) |
| 23:19.10 | mafm | :D |
| 23:19.28 | starseeker | might also be a good opener if we need to propose some changes to include in the next Qt |
| 23:19.39 | mafm | that's fine ``Erik, you just reminded me about the recently read article |
| 23:19.52 | Ralith | starseeker: I found lots of magic-looking code in QGraphicsView::render, but I'm not sure I can use it without modifying Qt |
| 23:19.56 | Ralith | which seems like a worst-case. |
| 23:20.05 | ``Erik | who said C? :D |
| 23:20.13 | Ralith | QGraphicsScene* |
| 23:20.43 | Ralith | then again, perhaps I could simply introduce some redundancy... |
| 23:21.25 | starseeker | Ralith: redundancy? |
| 23:21.50 | Ralith | starseeker: the big block of setup code in the render function might be practical to extract into the g3d code. |
| 23:21.58 | starseeker | ah |
| 23:22.06 | starseeker | might do for a start, certainly |
| 23:22.12 | starseeker | especially if it works ;-) |
| 23:22.13 | Ralith | my original thought was to slightly rework Qt itself to do that without the redundancy |
| 23:22.25 | louipc | haha writeln |
| 23:22.27 | Ralith | but that'd undesirable and I now realise perhaps unnecessary |
| 23:22.39 | starseeker | nods |
| 23:22.53 | starseeker | we've already got Ogre back in svn, so that's the easier mod target to start with |
| 23:23.19 | Ralith | and one of the nice things about using Qt is that many already have it installed; using a customized version negates that. |
| 23:24.00 | starseeker | I wouldn't be afraid of redundancy at this stage - if it works we can try to work with Qt/Ogre to find the "correct/pretty" way later |
| 23:24.31 | Ralith | yeah. |
| 23:24.47 | starseeker | drags self off to gym |
| 23:25.19 | mafm | ``Erik: probably the guy who wrote the article can find bugs in any other languages, given the length of the "lecture" about errors in C hello world programs :) |
| 23:29.43 | ``Erik | O.o so, uh, checking the return value of a function is... well... ALL of his argument there? weak :) |
| 23:30.32 | Ralith | urgh. |
| 23:30.42 | Ralith | this init code requires stuff only render knows about :/ |
| 23:54.08 | ``Erik | yeesh, goblin sharks are creepy |