| 00:21.43 | pra5ad | punchline city |
| 00:58.22 | pra5ad | Twingy, |
| 01:03.12 | brlcad | I suppose I should have been paying attention.. |
| 01:07.31 | pra5ad | <PROTECTED> |
| 01:07.31 | pra5ad | <PROTECTED> |
| 01:07.35 | pra5ad | that seem right to u? |
| 01:08.09 | brlcad | not really |
| 01:08.17 | brlcad | that's basically 0 0 0 and inf inf inf |
| 01:08.21 | pra5ad | straight from DIVA's db |
| 01:08.32 | pra5ad | and there isnt any stride issues |
| 01:08.48 | brlcad | diva's db? |
| 01:08.51 | pra5ad | cos i get the mesh list with fully formed name elemts |
| 01:09.17 | pra5ad | justin put everything on the opterons |
| 01:09.20 | pra5ad | mysqld |
| 01:16.14 | brlcad | ah, yes he's using mysqld for his storage |
| 01:16.24 | ``Erik | cuz he's el loco |
| 01:21.47 | *** join/#brlcad tegtmeye (n=tegtmeye@pool-70-17-225-27.balt.east.verizon.net) |
| 01:21.48 | pra5ad | so ive got an infinitely long triangle |
| 01:21.56 | pra5ad | yo mike |
| 01:22.01 | tegtmeye | hey! |
| 01:22.14 | tegtmeye | Sean on? |
| 01:22.18 | brlcad | of course not |
| 01:22.28 | pra5ad | i should make that a trigger |
| 01:22.30 | pra5ad | =) |
| 01:22.47 | brlcad | while I make /kick pra5ad a trigger |
| 01:22.55 | pra5ad | gattaca!! |
| 01:23.07 | brlcad | good movie |
| 01:23.13 | ``Erik | hehehe |
| 01:23.16 | brlcad | uma hotman |
| 01:23.30 | tegtmeye | yo, more autoconf ?s |
| 01:24.24 | pra5ad | ahh i meant 'attica! attica!' |
| 01:24.24 | tegtmeye | how to set your PREFIX as a macro inside, ie |
| 01:24.26 | pra5ad | bloops =) |
| 01:24.50 | tegtmeye | #define MIKE_FOO PREFIX |
| 01:25.03 | tegtmeye | where do I get the PREFIX |
| 01:25.11 | tegtmeye | that I used in configure? |
| 01:25.45 | pra5ad | mike: u have two meshes before and one after my mesh list, other than that the mesh/face counts are the same |
| 01:25.50 | brlcad | prefix is just the var "prefix" |
| 01:26.28 | pra5ad | my mesh stride is correct (since im getting the correct mesh names) |
| 01:26.29 | brlcad | when configure is running, if the user hasn't specified prefix, it's set to "NONE" |
| 01:27.17 | tegtmeye | so, I just set my macro as AC_DEFINE(prefix,...)? |
| 01:27.26 | brlcad | not quite |
| 01:28.10 | brlcad | you'll need to check for "NONE" otherwise you'll have a value of NONE in your config.h |
| 01:28.14 | tegtmeye | prasad, did justin change the file? |
| 01:28.27 | pra5ad | u mean db |
| 01:28.28 | brlcad | so make up your own var and check it.. something like: |
| 01:28.30 | pra5ad | i dunno |
| 01:28.44 | brlcad | if test "x$prefix" = "xNONE" ; then |
| 01:29.17 | brlcad | <PROTECTED> |
| 01:29.19 | brlcad | else |
| 01:29.24 | brlcad | <PROTECTED> |
| 01:29.31 | brlcad | <PROTECTED> |
| 01:29.33 | brlcad | fi |
| 01:30.04 | brlcad | AC_DEFINE_UNQUOTED([MIKE_FOO], "$tegt_prefix", "Location where we are installing to") |
| 01:31.01 | tegtmeye | ah... |
| 01:31.19 | brlcad | that'll put a #define MIKE_FOO /path/to/whatever in your config.h |
| 01:31.39 | tegtmeye | thx! |
| 01:32.08 | brlcad | which can then be used in string concat or snprintf's or whatever |
| 01:32.19 | tegtmeye | is that the std way of getting the prefix dir into your src or |
| 01:32.47 | tegtmeye | do folks usually do something else? |
| 01:33.45 | tegtmeye | prasad, u want me to generate and send you the component names? |
| 01:34.28 | pra5ad | sure |
| 01:34.33 | pra5ad | xon/tmp |
| 01:34.57 | brlcad | that's the only way i've seen used to date |
| 01:35.08 | brlcad | not many put the path in their project |
| 01:35.22 | brlcad | since you usually want to allow the package to be relocateable |
| 01:35.53 | brlcad | brl-cad only embeds it and uses it as part of a search-order for finding mged resource files |
| 01:36.17 | brlcad | check run-time path, compile-time path, current dir, etc |
| 01:37.27 | tegtmeye | I'm asking for the config files, so the app knows to look in its PREFIX/etc dir unless told otherwise... |
| 01:37.49 | tegtmeye | so basically the same reason... |
| 01:40.07 | brlcad | pretty much, though it should probably check the run-time path too ;) |
| 01:40.27 | brlcad | you could snarf the code from libbu for that |
| 01:41.21 | brlcad | src/libbu/which.c for 'which' search semantics or src/libbu/whereis.c for 'whereis' style search semantics |
| 01:41.27 | brlcad | (probably would want 'which') |
| 01:43.00 | pra5ad | what does the bu stand for |
| 01:44.04 | brlcad | libbu, the brl-cad utility library |
| 01:44.39 | brlcad | libbn, the brl-cad numerics library |
| 01:44.48 | tegtmeye | prasad, tmp/out |
| 01:44.54 | brlcad | you can s/brl-cad/basic/ too if you really wanted to |
| 01:48.20 | pra5ad | names match |
| 01:48.32 | tegtmeye | ackkk!!!! gotos in which.c! you bad modern programmer you;) |
| 01:50.25 | brlcad | compile-time messy preprocessor convenience |
| 01:51.17 | brlcad | you can rewrite it without the gotos but one of the few cases where the logic was more simplified with than without |
| 01:52.40 | tegtmeye | just giving you trouble..., I have no trouble with the occasional goto |
| 01:52.44 | brlcad | the files work well with bu_argv0() in src/libbu/brlcad_path.c if there's going to be a long time between starting up the app and searching for the runtime path |
| 01:55.22 | pra5ad | man wtf :\ |
| 01:56.55 | brlcad | tegtmeye: mind you those are for finding where the current running binary are located, you'd then use a relative path to find ../etc for example |
| 01:57.06 | brlcad | if it wasn't obvious |
| 01:57.36 | tegtmeye | gotcha |
| 01:57.51 | tegtmeye | whats up prasad? |
| 01:59.39 | pra5ad | headache |
| 01:59.39 | pra5ad | this doesnt make sense |
| 01:59.39 | ``Erik | damn you whine a lot |
| 01:59.42 | ``Erik | :D |
| 01:59.45 | pra5ad | yes i do |
| 01:59.48 | pra5ad | deal with it |
| 01:59.59 | ``Erik | <-- unsheathes "tar arn" |
| 02:00.26 | ``Erik | don't step up, boy, I'm tequila drunk right now :D |
| 02:00.33 | pra5ad | tegtmeye, look at this |
| 02:00.34 | pra5ad | <PROTECTED> |
| 02:00.34 | pra5ad | <PROTECTED> |
| 02:00.50 | ``Erik | 0,0,0, sane,inf,inf ? |
| 02:01.11 | CIA-5 | BRL-CAD: 03brlcad * 10brlcad/TODO: run-time path identification of mged resources was never completed |
| 02:01.36 | ``Erik | are you assuming something like float[3] when it's double[3] or visa versa? |
| 02:03.34 | tegtmeye | actually, depends on what your doing. in adrt, those last #'s are considered 0 in 19 and wtf in 20 |
| 02:04.27 | pra5ad | <PROTECTED> |
| 02:04.27 | pra5ad | <PROTECTED> |
| 02:04.30 | pra5ad | that's with doubles |
| 02:04.33 | tegtmeye | are you actually doing somthing or still just reading in? |
| 02:04.47 | brlcad | what's your printf? |
| 02:04.55 | brlcad | or whatever you're using |
| 02:05.02 | tegtmeye | everything he gave me was in floats with the indes as shorts |
| 02:05.11 | pra5ad | cout << "\t Vertex " << vidx << ") [ " << pt_list[ pt_idx ] << " , " << |
| 02:05.11 | pra5ad | pt_list[ pt_idx + 1 ] << " , " << pt_list[ pt_idx + 2 ] << " ]" << endl; |
| 02:05.15 | pra5ad | yea ive been using floats |
| 02:05.38 | pra5ad | pt_list is a float* |
| 02:05.56 | brlcad | what's 19/20 for double? |
| 02:06.35 | pra5ad | er? |
| 02:06.42 | pra5ad | oh sec |
| 02:07.15 | pra5ad | hrm would help if i remember what mesh it was |
| 02:07.24 | pra5ad | lemme get a new pair of vals |
| 02:08.19 | pra5ad | <PROTECTED> |
| 02:08.19 | pra5ad | <PROTECTED> |
| 02:08.22 | pra5ad | for float |
| 02:09.34 | pra5ad | <PROTECTED> |
| 02:09.35 | pra5ad | <PROTECTED> |
| 02:09.37 | pra5ad | dbl |
| 02:10.01 | brlcad | eh, you have something screwy going on elsewhere |
| 02:10.14 | brlcad | they shouldn't be different if the db has a float |
| 02:11.13 | brlcad | double looks more correct |
| 02:11.24 | pra5ad | no its not |
| 02:11.27 | pra5ad | <PROTECTED> |
| 02:11.27 | pra5ad | <PROTECTED> |
| 02:11.30 | pra5ad | for dbl |
| 02:11.45 | brlcad | well, for 19/20 it "looks more correct" |
| 02:11.53 | brlcad | which it shouldn't regardless |
| 02:12.02 | brlcad | hence "you have something screwy going on elsewhere" |
| 02:13.36 | tegtmeye | I agree, the values should not have an 'e' in them anywhere if memory serves |
| 02:13.45 | tegtmeye | for any of the meshes |
| 02:14.17 | pra5ad | the mesh strides are correct for float and dbl |
| 02:14.26 | pra5ad | id assume both are dbl word |
| 02:14.55 | pra5ad | .. *shrug* |
| 02:15.43 | Twingy | what |
| 02:16.14 | pra5ad | did u change the geometry data in the db recently? |
| 02:16.36 | Twingy | in mysql? |
| 02:16.40 | pra5ad | yes |
| 02:16.57 | Twingy | nope, haven't changed the format since tegtmeyer suggested a change in september |
| 02:17.21 | pra5ad | ur tfloat is a normal float, yes? |
| 02:17.28 | Twingy | currently, yes |
| 02:17.45 | pra5ad | getting bogus values for vertex data |
| 02:17.47 | Twingy | parsing difficulties? |
| 02:17.53 | pra5ad | yes |
| 02:17.58 | Twingy | did you read in the endian and revision? |
| 02:18.05 | Twingy | 2 byte endian, 2 byte revision |
| 02:18.24 | pra5ad | hmm |
| 02:18.41 | Twingy | then mesh name length 1 byte, mesh name string N bytes, vertex num, vertex data |
| 02:18.52 | Twingy | it's all in the 200 or so lines of load.c |
| 02:19.05 | pra5ad | <PROTECTED> |
| 02:19.05 | pra5ad | <PROTECTED> |
| 02:19.09 | pra5ad | that's all u do |
| 02:19.19 | pra5ad | i dont see any revision extraction |
| 02:19.19 | Twingy | ok, then do that |
| 02:19.26 | pra5ad | and that's what i did |
| 02:19.28 | Twingy | I probly removed it |
| 02:19.39 | Twingy | in september |
| 02:19.40 | pra5ad | so is there a 2B revision ? |
| 02:19.50 | Twingy | don't worry about revision for now |
| 02:20.01 | Twingy | what's the next 4 bytes |
| 02:20.09 | pra5ad | i can traverse ur byte array fine |
| 02:20.16 | pra5ad | since i can extract mesh names correctly |
| 02:20.21 | Twingy | I see |
| 02:20.46 | pra5ad | dunno why vertex data is giving inf values |
| 02:20.52 | Twingy | and vertex num is okay? |
| 02:21.04 | Twingy | are you getting sane vertex num values? |
| 02:21.11 | pra5ad | not all the time |
| 02:21.25 | Twingy | are you handling the face indices correctly? |
| 02:21.32 | pra5ad | and vnum has to be correct for the mesh strides to work right |
| 02:21.34 | pra5ad | and ive checked with tegtmeyer's output |
| 02:21.35 | Twingy | 1 byte to denate short or int |
| 02:21.42 | pra5ad | yes |
| 02:21.51 | pra5ad | it's a direct translation from ur code |
| 02:22.03 | Twingy | maybe your mysql loader is borked? |
| 02:22.28 | Twingy | you did a use result, and then got the first row |
| 02:22.33 | Twingy | and are running through row[0] I guess |
| 02:22.38 | tegtmeye | tegtmeye doesn't see any tile work going on... |
| 02:22.46 | Twingy | tile work for what? |
| 02:22.50 | Twingy | oh |
| 02:22.53 | Twingy | just laid down 22 |
| 02:22.53 | tegtmeye | u finished? |
| 02:22.57 | tegtmeye | ah |
| 02:23.09 | Twingy | I need a break or else I can't lay down another batch tonight |
| 02:23.14 | Twingy | I'm at 160 now |
| 02:23.22 | Twingy | speant the last 3 hours on that |
| 02:23.22 | pra5ad | dude.. i just told u i can extract ur mesh names from the byte array. to do that i need to have the correct data sizes and limits (which apparenty i do) |
| 02:23.26 | pra5ad | whatever |
| 02:23.46 | Twingy | does the first mesh come through ok? |
| 02:24.01 | Twingy | I think it's like 22 faces |
| 02:24.12 | Twingy | I remember that from tegtmeyer's test program |
| 02:24.31 | pra5ad | name: /scene/light1.r/light1.bot^@ |
| 02:24.31 | pra5ad | vertices: 8 |
| 02:24.31 | pra5ad | faces: 12 |
| 02:24.48 | Twingy | what's the ^@ ? |
| 02:25.10 | pra5ad | ask mike |
| 02:25.27 | pra5ad | this is his output |
| 02:25.34 | Twingy | what geometry is this? |
| 02:25.40 | Twingy | is this the humvee? |
| 02:25.55 | pra5ad | t62 |
| 02:25.56 | ``Erik | heh |
| 02:26.09 | ``Erik | isn't ^@ a \0 ? |
| 02:26.19 | Twingy | anyway |
| 02:26.26 | Twingy | that looks okay |
| 02:26.33 | pra5ad | has to be the t62, since my #1 mesh is his #3 mesh |
| 02:26.34 | Twingy | what do you get for first vertice? |
| 02:26.39 | pra5ad | and it follows that pattern |
| 02:26.48 | pra5ad | my mesh id = tegt mesh + 2 |
| 02:27.00 | pra5ad | and mesh properties are equal |
| 02:28.21 | tegtmeye | yea, t62. the ^@ is mac newline stupidity |
| 02:28.53 | Twingy | sooo you gonna answer my question? |
| 02:29.23 | pra5ad | [Mesh16 0] '/compartment/hull/hull_ext/hull_armor/rt_side/r160/r160.bot' |
| 02:29.23 | pra5ad | - ( 66 | 140 ) |
| 02:29.50 | pra5ad | that's (verts, faces) |
| 02:30.00 | Twingy | k |
| 02:30.27 | Twingy | and the first vert? |
| 02:30.55 | ``Erik | yowza, i'm behind on rvb |
| 02:31.14 | pra5ad | sec |
| 02:32.05 | Twingy | meh, I need to shave |
| 02:32.10 | Twingy | and get some sleep again |
| 02:32.20 | pra5ad | <PROTECTED> |
| 02:32.20 | pra5ad | <PROTECTED> |
| 02:32.20 | pra5ad | <PROTECTED> |
| 02:32.20 | pra5ad | <PROTECTED> |
| 02:32.28 | Twingy | those look sane |
| 02:32.33 | pra5ad | yea well.. |
| 02:32.49 | Twingy | it almost seems like a memory leak or buffer overlow or something |
| 02:32.53 | pra5ad | <PROTECTED> |
| 02:32.53 | pra5ad | <PROTECTED> |
| 02:32.58 | Twingy | ah |
| 02:33.07 | Twingy | at 55 it starts screwing up? |
| 02:33.19 | pra5ad | <PROTECTED> |
| 02:33.19 | pra5ad | <PROTECTED> |
| 02:33.19 | pra5ad | <PROTECTED> |
| 02:33.19 | pra5ad | <PROTECTED> |
| 02:33.34 | brlcad | probably walking the array in some bogus manner |
| 02:33.38 | Twingy | and you're 100% positive for that mesh you're reading the face indexes in as shorts |
| 02:34.01 | Twingy | *indices |
| 02:34.08 | pra5ad | if it printed out as mesh16 then yes |
| 02:34.15 | Twingy | ah, k |
| 02:34.30 | pra5ad | its weird |
| 02:34.33 | pra5ad | at 17 it goes haywire |
| 02:34.38 | pra5ad | then at 36 it's sane again |
| 02:34.40 | Twingy | let me think |
| 02:34.47 | pra5ad | at 46 it goes nuts again |
| 02:34.54 | Twingy | is there a pattern? |
| 02:34.54 | pra5ad | at 57 its sane |
| 02:35.26 | brlcad | i bet you're reading garbage or filling your array wrong |
| 02:35.33 | brlcad | init your array to all zero |
| 02:35.40 | pra5ad | what array? lol |
| 02:35.43 | Twingy | he's not filling an array |
| 02:35.49 | Twingy | he's parsing a blob of binary data |
| 02:35.53 | pra5ad | yes there looks like a pattern |
| 02:36.07 | pra5ad | there's N sane and N garbage |
| 02:36.13 | brlcad | the blob the array then |
| 02:36.18 | Twingy | so there's a 2*X issue |
| 02:36.36 | brlcad | and your index is probably wrong then |
| 02:36.40 | pra5ad | but the num_verts and num_faces are good |
| 02:37.06 | Twingy | print the face indices out |
| 02:37.10 | Twingy | not the vertice values |
| 02:37.15 | pra5ad | doing that too |
| 02:37.19 | pra5ad | and there's the same pattern |
| 02:37.25 | Twingy | what're they? |
| 02:37.29 | pra5ad | <PROTECTED> |
| 02:37.29 | pra5ad | <PROTECTED> |
| 02:37.29 | pra5ad | <PROTECTED> |
| 02:37.29 | pra5ad | <PROTECTED> |
| 02:37.29 | pra5ad | <PROTECTED> |
| 02:37.30 | pra5ad | <PROTECTED> |
| 02:37.37 | pra5ad | that 2x issue |
| 02:37.57 | brlcad | how big is the blob? |
| 02:38.07 | brlcad | byte-wise |
| 02:38.14 | Twingy | select gsize from geometry |
| 02:38.30 | *** join/#brlcad DTRemenak (n=DTRemena@DHCP-170-143.caltech.edu) |
| 02:38.33 | Twingy | of course not |
| 02:39.14 | pra5ad | Geom data size: 1549673 |
| 02:39.20 | brlcad | i wouldn't know otherwise, i don't know what the geometry is :P |
| 02:39.24 | Twingy | 1.5 meg |
| 02:39.41 | Twingy | he's parsing a little itty bitty mesh < 100 triangles |
| 02:39.42 | pra5ad | the face idx should be 0 < fidx < 66 |
| 02:39.50 | Twingy | yea |
| 02:40.17 | Twingy | wait |
| 02:40.25 | Twingy | why are you printing face 67 - 72 |
| 02:40.29 | Twingy | oh, nm |
| 02:44.09 | Twingy | your indexing is wrong |
| 02:44.09 | Twingy | <PROTECTED> |
| 02:44.09 | Twingy | pra5ad mesh.AddVertex( pt_list[ pt_idx ] , |
| 02:44.09 | Twingy | pra5ad pt_list[ pt_idx + 1 ], |
| 02:44.09 | Twingy | pra5ad pt_list[ pt_idx + 2 ] ); |
| 02:44.09 | pra5ad | damn |
| 02:44.09 | Twingy | pt_idx is not bytes |
| 02:44.09 | pra5ad | that's not it |
| 02:44.09 | Twingy | it's an integer into the array |
| 02:44.19 | Twingy | you're calculating bytes |
| 02:44.20 | pra5ad | yea agreed |
| 02:44.44 | pra5ad | thanks :D |
| 02:44.52 | Twingy | you bet |
| 02:45.48 | pra5ad | much better |
| 02:47.15 | Twingy | get rid of mesh.AddVertex when you're done too |
| 02:47.25 | Twingy | calling a function will cause you great performance grief |
| 02:47.45 | Twingy | it'll add an extra minute to loading stryker |
| 02:50.23 | pra5ad | O3 will inline it |
| 03:00.51 | tegtmeye | cya... |
| 04:28.51 | Twingy | and that makes another 10 |
| 05:56.43 | *** join/#brlcad PKMOBILE (n=Apathy@pcp0011645240pcs.aberdn01.md.comcast.net) |
| 07:46.08 | *** join/#brlcad DTRemenak (n=DTRemena@DHCP-170-143.caltech.edu) |
| 11:37.29 | *** join/#brlcad fenn (n=fenn@adsl-68-251-147-85.dsl.bltnin.ameritech.net) |
| 11:37.52 | fenn | ahoy mateys! |
| 11:38.52 | fenn | i'm looking for a relatively simple solid modeling language to simulate collisions in machine tools |
| 11:39.21 | fenn | stuff like cylinder, cube, sphere, cone, prism |
| 11:57.46 | fenn | also testing for collisions with a nurbs toolpath would be nice |
| 11:58.16 | fenn | what parts of the brlcad tree would i need for this? or is brlcad the wrong tool for the job? |
| 13:27.31 | brlcad | fenn, brl-cad wouldn't be the wrong tool for the job, but depending on exactly what you want changes what you might want to look at |
| 13:27.41 | brlcad | and coding will probably be required |
| 13:27.46 | fenn | yeah definitely |
| 13:28.02 | brlcad | librt is where all the primitive and geometry introspect (via ray shooting) lives |
| 13:28.20 | fenn | what handles geometry intersections? |
| 13:28.52 | fenn | oh the other tricky thing is i have to transform some things into n dimensional space |
| 13:28.52 | brlcad | it's implicit geometry representations |
| 13:29.04 | brlcad | so geometry intersections are known when a ray is fired |
| 13:29.19 | brlcad | and the implicit equations and segment/partition lists are computed |
| 13:30.00 | brlcad | you can register callback handles via the raytrace programming api for hit/miss/overlap |
| 13:30.24 | fenn | so a ray is like a vector? it has magnitude? |
| 13:30.47 | brlcad | a ray has a starting position and a direction |
| 13:30.57 | fenn | hmmm |
| 13:31.12 | brlcad | you can get geometry information along that ray |
| 13:31.18 | fenn | i need to know if a vector is inside a volume |
| 13:32.48 | fenn | brlcad is probably the wrong tool for this |
| 13:33.59 | brlcad | if your talking about what I think you're talking about |
| 13:34.24 | brlcad | then you have some "tool", a shaped carving/cutting bit with some 3d shape |
| 13:34.38 | fenn | eh, no that's a different project |
| 13:35.12 | brlcad | oh? then what the "testing for collsions with a nurbs toolpath" mean? |
| 13:35.53 | fenn | ok these projects are all related you can see |
| 13:36.11 | fenn | i have a CAM project that takes a solid and plans out the toolpaths |
| 13:36.22 | brlcad | k |
| 13:36.34 | fenn | now we are working on a new CNC motion controller to replace emc |
| 13:37.07 | fenn | they have some similar functions and some redundant functions |
| 13:37.20 | fenn | like the cnc controller has to be able to compensate for cutters of different sizes |
| 13:38.07 | fenn | so if you have are cutting a sharp inside corner for instance, you dont want to blindly offset the path by some amount |
| 13:38.21 | fenn | this kinda hard without pictures |
| 13:38.28 | brlcad | i think i follow though |
| 13:38.51 | fenn | so, cutter comp and toolpath planning in the CAM are pretty similar |
| 13:38.58 | brlcad | you want a sharp corner, and if you were using a large circular cut, you'd have a big corner curve |
| 13:39.08 | fenn | yeah |
| 13:39.48 | fenn | if you follow the path that was made for a smaller cutter it might go too far into the corner and gouge the part |
| 13:40.12 | fenn | so i wanted to do collision detection between the toolpath and the cutter |
| 13:40.17 | fenn | make sense? |
| 13:40.24 | brlcad | now do you restrict the toolpath to "mostly" 2D (like a thin slab of metal being cut), or entirely 2D (sheet-metal style cutting), or entirely 3d? |
| 13:40.47 | fenn | it's restricted to mostly 2d |
| 13:40.52 | fenn | i think it's kinda dumb myself |
| 13:41.02 | fenn | why not just run it thru cam again? |
| 13:41.10 | fenn | but anyway.. |
| 13:41.47 | brlcad | so basically it's a 2D cutting path and toolbit exercise where you just have to take the vertical shape of the toolbit into consideration |
| 13:43.16 | fenn | the main problem i've been thinking about is how to transform arbitrary geometries from "cartesian space" to "joint space" |
| 13:43.39 | fenn | where "joint space" is the space with a set of basis vectors defined by the actual motions of the machine tool |
| 13:44.09 | fenn | like a milling machine will have a quill, a knee, an X axis and a Y axis |
| 13:44.40 | fenn | so in this instance you are taking a 3d toolpath and transforming it into 4 dimensional space |
| 13:45.36 | fenn | now you want to make sure that you are within a specified tolerance, but the information in realtime is coming from the joints |
| 13:46.12 | brlcad | have you run rtedge in brl-cad yet? |
| 13:46.17 | fenn | so i think it's easier to transform the tolerance into joint space before the machine moves than to try to transform all the joints back into normal cartesian coordinates |
| 13:46.28 | fenn | no.. *hangs his head* |
| 13:46.56 | fenn | i get lost every time i try to use brlcad |
| 13:46.59 | brlcad | that effectively solves the path contour, detecting/reporting the edge of a specified slice of geometry |
| 13:47.28 | brlcad | you could even use the results as basis vectors for a 2D bezier path directly |
| 13:47.54 | fenn | like slicing a part along the z axis? |
| 13:48.00 | brlcad | you'd have to account for the direction changes to detect inside/outside corners that would need a different toolbit |
| 13:48.17 | brlcad | again, as you noted, pictures would help :) |
| 13:51.11 | fenn | i figured this is the sort of stuff you did in simulations |
| 13:52.06 | brlcad | it is in many ways |
| 13:52.56 | brlcad | those are almost always custom algorithms but the basic need is for geometric introspection, which is what librt provides |
| 13:53.05 | *** join/#brlcad Maloeran (n=alexis@modemcable065.3-83-70.mc.videotron.ca) |
| 13:53.25 | brlcad | full blown simulations of a munition hitting a target can be simulated that way |
| 13:53.32 | fenn | is there a way to get librt without all the rest of brlcad? |
| 13:53.40 | brlcad | or energy/blast effects, etc |
| 13:53.51 | brlcad | heh |
| 13:53.58 | fenn | if not it's not a big deal |
| 13:53.59 | brlcad | you could, sure .. but "why"? :) |
| 13:54.22 | fenn | for instance if you're running a cnc controller off a usb stick and dont have space for all of brlcad |
| 13:54.32 | brlcad | ah, for that purpose, sure |
| 13:55.05 | fenn | cool.. i'll have to look into it more then |
| 13:55.53 | brlcad | librt relies upon brl-cad's basic numerics and utility libraries (libbn and libbu), libregex, and libz |
| 13:56.20 | brlcad | so you pull those four directories out, and you'd have just what you needed, a fairly contained library |
| 13:56.45 | fenn | they're just shared library files right? (.so) |
| 13:56.46 | brlcad | I could make a configure target for that as well for convenience |
| 13:57.11 | brlcad | shared or static |
| 13:57.11 | fenn | well, .a, close enough |
| 13:58.34 | fenn | i can just link to that at compile time |
| 14:14.18 | fenn | thanks for talking to me.. i'll be back |
| 14:14.32 | *** part/#brlcad fenn (n=fenn@adsl-68-251-147-85.dsl.bltnin.ameritech.net) |
| 14:33.06 | CIA-5 | BRL-CAD: 03brlcad * 10brlcad/TODO: rtedge-style tracer that outputs tool paths for CNC/CAM tool path decriptions (g-code output) |
| 14:34.54 | archivist | definable g-code as not all machines use all g-codes |
| 14:35.47 | CIA-5 | BRL-CAD: 03brlcad * 10brlcad/regress/Makefile.am: |
| 14:35.47 | CIA-5 | BRL-CAD: the regression tests should run regardless of the output files. in fact, start |
| 14:35.47 | CIA-5 | BRL-CAD: by cleaning out the directory first so we're always at a known starting state. |
| 14:35.47 | CIA-5 | BRL-CAD: have each test output when it's complete and a message at the end to indicate |
| 14:35.47 | CIA-5 | BRL-CAD: that testing was completed successfully |
| 14:35.55 | brlcad | definable, hmm |
| 14:36.12 | brlcad | from what i've seen, g-code is a mostly 'standardized' format |
| 14:36.42 | brlcad | not sure if it was a proper ieee/acm spec of any sort, but the doc I remember reading from many moons ago seemed relatively clear |
| 14:37.13 | archivist | some machines(older) have a very small subset |
| 14:37.26 | brlcad | ah, subsets would probably be fine |
| 14:38.03 | brlcad | could be some sort of compliance/version level option on the output |
| 14:38.14 | brlcad | like outputting vrml 2 vs 1 etc |
| 14:38.39 | archivist | I have seen tick box method to choose avalable before processing |
| 14:39.13 | brlcad | easy enough |
| 14:39.34 | brlcad | the task really is mostly written already via rtedge |
| 14:39.56 | brlcad | all that's missing is tying the segments together into continuous contours solving for a bezier path |
| 14:40.47 | brlcad | since associativity is lost/not needed for creating an image |
| 14:40.52 | archivist | machine here would not understand a bezier |
| 14:41.05 | brlcad | wouldn't need to |
| 14:41.12 | brlcad | it's just solving "the path" |
| 14:41.29 | brlcad | the actual output could be segments, points, arcs, whatever |
| 14:41.55 | brlcad | since they're just a descretization of the mathematical tooling path |
| 15:34.33 | archivist | had a visitor |
| 15:35.43 | CIA-5 | BRL-CAD: 03brlcad * 10brlcad/AUTHORS: |
| 15:35.44 | CIA-5 | BRL-CAD: david becker provided vectorized implementations of the shot routines for |
| 15:35.44 | CIA-5 | BRL-CAD: several of the primitives. the qualifies as a significant coding contribution. |
| 15:35.44 | CIA-5 | BRL-CAD: his placement in the time ordering might not be right, but CVS log shows he |
| 15:35.44 | CIA-5 | BRL-CAD: contributed circa 1988/1989 |
| 15:37.20 | archivist | order matters as machining one dir will give a different size due to tool and machine spring (older machines have no compensation or tool path direction sorting/correction) |
| 15:55.19 | *** join/#brlcad paul_c (n=paul@cpc1-norw1-6-0-cust99.pete.cable.ntl.com) |
| 16:03.48 | learner | howdy paul_c |
| 16:04.08 | CIA-5 | BRL-CAD: 03brlcad * 10brlcad/AUTHORS: (log message trimmed) |
| 16:04.08 | CIA-5 | BRL-CAD: Spencer, Thomas W.; McKie, Jim; Davies, Steve; Turkowski, Ken; Woods, James A.; |
| 16:04.08 | CIA-5 | BRL-CAD: Orost, Joseph; all added with special thanks for the (indirect) contributions to |
| 16:04.08 | CIA-5 | BRL-CAD: the package. in particular, they all worked on the code 'compress.c' that |
| 16:04.08 | CIA-5 | BRL-CAD: serves as the basis for out libfb compression, added by chris johnson in 1991. |
| 16:04.09 | CIA-5 | BRL-CAD: the code was derived from software contributed to Berkeley by James A. Woods, |
| 16:04.11 | CIA-5 | BRL-CAD: derived from original work by Spencer Thomas and Joseph Orost. Spencer Thomas |
| 16:04.35 | paul_c | Hi learner |
| 16:04.58 | paul_c | Just wondering if there was a Debian package for brlcad |
| 16:05.04 | learner | heh |
| 16:05.11 | learner | sort of |
| 16:05.15 | learner | it's not in apt yet afaik |
| 16:05.34 | learner | nobody has taken the time to submit it or be a sponsor or request a sponsor, etc |
| 16:05.46 | learner | but there was at least one fellow that made a .deb for it |
| 16:06.58 | learner | to be honest, though, it should be considerably more easy to compile from source |
| 16:07.13 | learner | the .deb was for an older version |
| 16:07.35 | learner | i'd be glad to walk you through the steps if you're interested |
| 16:07.54 | paul_c | source compiles are OK up to a point.. |
| 16:08.47 | paul_c | google is my fiend... http://scientificcomputing.net/debian/packages/brlcad/ |
| 16:09.35 | learner | looks good enough |
| 16:09.57 | learner | 7.6.6 is the latest going out today so that's not too far back (3 months or so) |
| 16:10.14 | learner | though the gfdl comment is no longer valid |
| 16:10.41 | learner | the docs are user-selectably gfdl or gpl |
| 16:10.51 | paul_c | With the source package available, it wouldn't be too difficult to rebuild with 7.6.6 sources. |
| 16:13.31 | paul_c | the next Q. which I 'spose gets asked quite often.... |
| 16:13.45 | paul_c | Are there any CAM export options ? |
| 16:16.19 | learner | yep, very often :) |
| 16:16.35 | learner | almost as often as questions regarding cadd (drafting/dimensioning) |
| 16:16.47 | learner | there are not cam export options |
| 16:17.20 | paul_c | any in the pipeline that you know of ? |
| 16:17.29 | learner | though moding one of the existing tools, or writing a new tool to do this would not be very hard at all .. just need to find someone interested enough to take the initiative |
| 16:17.38 | learner | s/though/through/ |
| 16:18.30 | learner | it's in the pipeline for sure, but it's very far down the list of priorities for this year with the current devs .. need more people to get involved that have cam interest |
| 16:18.55 | learner | so far, more people are stepping up to the plate in support of cadd and fem |
| 16:20.55 | paul_c | that doesn't suprise me TBH |
| 16:21.19 | CIA-5 | BRL-CAD: 03brlcad * 10brlcad/AUTHORS: recognize special thanks to balbir thomas for putting together the first debian package for brl-cad |
| 16:21.35 | learner | there was one guy heavily interested at first |
| 16:22.04 | learner | but he started working on a step converter first |
| 16:22.27 | learner | and that is one big complicated/expensive and time consuming task to approach |
| 16:22.29 | paul_c | eeeuuw... ;) |
| 16:23.23 | learner | we have most of the pieces now |
| 16:23.43 | learner | purchased most of the relevant portions of the spec from ieee |
| 16:24.00 | learner | have a c parser for at least the 2001 revision, iirc |
| 16:24.17 | paul_c | a parser for step ? |
| 16:24.32 | learner | yes, ap21 or whatever it's called |
| 16:24.43 | learner | the file format for step |
| 16:25.03 | learner | for the purpose of creating step-g and g-step converters |
| 16:25.16 | learner | at least step-g |
| 16:25.21 | paul_c | ears prick up big time. |
| 16:25.51 | paul_c | step is mostly XML data format ? |
| 16:26.15 | learner | he started updating the parser for the 2003 revision of step and that's where he started hitting brick walls, incompatible inconsistencies in the spec |
| 16:26.22 | learner | no, it's not |
| 16:26.43 | learner | they use EXPRESS |
| 16:27.05 | learner | which is a markup language in itself, similar to XML |
| 16:27.37 | learner | so you have to write an express parser (which is what we have, through support of nist) |
| 16:28.01 | learner | and then a translation from express for conformancy against one of the step AP interfaces |
| 16:28.11 | learner | like AP201 for "solid modeling" |
| 16:28.30 | learner | or 203 for CSG operations, etc |
| 16:29.01 | learner | THEN .. you can worry about translating objects to/from brl-cad and step format |
| 16:29.09 | paul_c | got it.. Some test data from NIST. It includes some *.stp files. |
| 16:29.32 | paul_c | which I assume are the STEP files ? |
| 16:29.47 | learner | there express parser had several bugs and cross-platform support issues that we updated too |
| 16:29.55 | learner | yes, stp are step files |
| 16:30.09 | learner | those are the 2001 variant/compliant that I referred to |
| 16:31.04 | learner | nist only developed the parser as a one-shot deal and are no longer interested in maintaining the project, so we were given pretty leniant leeway to take over development |
| 16:31.14 | paul_c | *slap.. I know where the XML idea came from now. |
| 16:31.50 | learner | there is a proposal for an xml-based step format, but it's still not finalized or even in final draft form iirc |
| 16:31.56 | paul_c | Will & Fred over at NIST were working on XML data exchange with rcslib |
| 16:35.10 | CIA-5 | BRL-CAD: 03brlcad * 10brlcad/AUTHORS: consistent usage of periods on middle name initials |
| 16:38.12 | paul_c | hrmm.. Was there a reason for patching tcl/tk ? |
| 16:40.16 | learner | yes |
| 16:40.36 | CIA-5 | BRL-CAD: 03brlcad * 10brlcad/AUTHORS: |
| 16:40.36 | CIA-5 | BRL-CAD: daniel dender was involed in the 3.0->4.x days minimally and has code credited |
| 16:40.36 | CIA-5 | BRL-CAD: to his name in mged (facedef.c) as well as the patch-g converter, so attribute |
| 16:40.36 | CIA-5 | BRL-CAD: him appropriately into the coding contributions section. he was also actively |
| 16:40.36 | CIA-5 | BRL-CAD: involved on the old mailing list. |
| 16:40.48 | learner | we've made several tcl/tk mods over the years, some that have made their way into the distribution, some that haven't still |
| 16:41.21 | learner | one of the two main differences we have now are a bezier canvas widget to Tk |
| 16:41.33 | learner | though I recently moved that out of libtk into a different library |
| 16:41.59 | learner | archivist, where? |
| 16:42.23 | archivist | daniel dender was involed in the 3.0->4.x |
| 16:42.28 | learner | ah |
| 16:42.51 | learner | no biggie then :) i at least got it right later on |
| 16:44.04 | learner | woo hoo.. only 8 more names unaccounted for in the authors file |
| 16:46.43 | learner | paul_c, the other reason is that the tcl/tk build was broken for several platforms that we support so we actually don't use their build system for the version we ship |
| 16:47.11 | learner | theoretically, though, you should be able to --disable-tcl-build and --disable-tk-build and have brl-cad use a system-installed tcl/tk with no problem |
| 16:47.56 | paul_c | OK.. I'll have to look in to that over the weekend. |
| 16:48.36 | learner | the decoupling of modifications to tcl/tk was specifically done to appease the apt/ports/portage crowds |
| 16:49.36 | learner | there's still a few more things that I'd like to change in support of the packaging systems, but it should at least 'work' now without requiring installation into /usr/brlcad |
| 16:50.39 | paul_c | I have to head off to the wastelands of Norfolk in a few mins... |
| 16:51.00 | paul_c | I'll try and catch you guys early next week. |
| 16:52.06 | archivist | tis a bit barren in Norfolk |
| 16:52.09 | learner | sounds like fun |
| 16:52.25 | learner | yet Norfolk & Western play good music ;) |
| 16:52.38 | CIA-5 | BRL-CAD: 03brlcad * 10brlcad/AUTHORS: |
| 16:52.38 | CIA-5 | BRL-CAD: joe johnson worked with steve satterfield on the Lyon-Lamb VAS IV video |
| 16:52.38 | CIA-5 | BRL-CAD: animation controller (vas4) code .. should probably be in code contributions, |
| 16:52.38 | CIA-5 | BRL-CAD: need to revisi more carefully later. maybe have a talk with steve first. |
| 16:53.23 | archivist | oo revisi another new word |
| 16:53.44 | learner | hmm yes |
| 16:53.59 | learner | i should type less when I've not eaten or drank anything today yet |
| 16:54.31 | archivist | my typing on irc can be bad sometimes |
| 17:01.54 | CIA-5 | BRL-CAD: 03brlcad * 10brlcad/AUTHORS: |
| 17:01.54 | CIA-5 | BRL-CAD: Martin, Glenn E. and Willson, Stephen Hunter of the Northrup Research and |
| 17:01.54 | CIA-5 | BRL-CAD: Technology Center worked with Mike on the Tektronix 4109 device driver display |
| 17:01.54 | CIA-5 | BRL-CAD: manager interface circa 1986 according to cvs logs. credit them with special |
| 17:01.54 | CIA-5 | BRL-CAD: thanks. |
| 17:34.46 | *** join/#brlcad Maloeran (n=alexis@modemcable065.3-83-70.mc.videotron.ca) |
| 17:35.51 | CIA-5 | BRL-CAD: 03brlcad * 10brlcad/AUTHORS: special thanks to f. kenton musgrave and robert skinner for algorithm support in the perlin-style noise function and height field primitive (Grid Tracing: Fast Ray Tracing for Height Fields paper) |
| 17:36.52 | learner | woot, only 3 names left! |
| 18:33.52 | CIA-5 | BRL-CAD: 03brlcad * 10brlcad/AUTHORS: brant ross wrote the FrameBuffer library interface for Raster Technology One/80 (libfb's if_rat.c), fairly significant coding contribution |
| 18:34.40 | brlcad | 2! |
| 18:41.40 | CIA-5 | BRL-CAD: 03brlcad * 10brlcad/AUTHORS: special thanks to william sebok for his fast Princeton memory allocater routines that john added to libbu as pmalloc.c in 1997 with some modifications. |
| 18:52.20 | CIA-5 | BRL-CAD: 03brlcad * 10brlcad/AUTHORS: |
| 18:52.20 | CIA-5 | BRL-CAD: special thanks goes out to charles stanley for his support of the package in the |
| 18:52.20 | CIA-5 | BRL-CAD: development of mged. charles/chuck is listed in the historic documentation, but |
| 18:52.20 | CIA-5 | BRL-CAD: is not authored on any of the files -- managerial support in a similar vein as |
| 18:52.20 | CIA-5 | BRL-CAD: deitz perhaps, though his participation does seem to go far back to near the |
| 18:52.20 | CIA-5 | BRL-CAD: start of the project |
| 18:54.50 | CIA-5 | BRL-CAD: 03brlcad * 10brlcad/AUTHORS: |
| 18:54.50 | CIA-5 | BRL-CAD: WOO HOO, no more names to be filed.. there may be a few names that still need to |
| 18:54.50 | CIA-5 | BRL-CAD: get credited, but the list is considerably more comprehensive now. could use |
| 18:54.50 | CIA-5 | BRL-CAD: more work on the chronological ordering and perhaps some indication of years in |
| 18:54.50 | CIA-5 | BRL-CAD: the file itself, but it's a good start. |
| 19:01.43 | *** join/#brlcad ``Erik (i=erik@pcp0011474399pcs.chrchv01.md.comcast.net) |
| 21:01.26 | *** join/#brlcad ibot (i=ibot@pdpc/supporter/active/TimRiker/bot/apt) |
| 21:01.26 | *** topic/#brlcad is http://brlcad.org/ || BRL-CAD is now Free Software! || 7.6.6 to be released by the 15th! |
| 21:57.29 | *** join/#brlcad _AchiestDragon (n=dave@whipy.demon.co.uk) |
| 22:00.13 | *** join/#brlcad AchiestDragon_ (n=dave@whipy.demon.co.uk) |
| 22:02.26 | *** join/#brlcad AchiestDragon_ (n=dave@whipy.demon.co.uk) |
| 22:06.43 | *** join/#brlcad AchiestDragon_ (n=dave@whipy.demon.co.uk) |
| 22:11.01 | *** join/#brlcad AchiestDragon (n=dave@whipy.demon.co.uk) |
| 22:43.52 | *** join/#brlcad AchiestDragon (n=dave@whipy.demon.co.uk) |
| 22:54.45 | CIA-5 | BRL-CAD: 03brlcad * 10brlcad/ (NEWS configure.ac): prepare for release, 7.6.6 |
| 23:52.30 | CIA-5 | BRL-CAD: 03brlcad * 10brlcad/configure.ac: add an alias for --enable-everything of --enable-build-everything |