| 00:06.18 | CIA-77 | BRL-CAD: 03starseeker * r43356 10/geomcore/trunk/ (3 files in 2 dirs): Proof of concept code to chop the toplevel objects out of a .g file, write them to individual .g files in the svn repository, and commit them. |
| 01:08.04 | brlcad | _psilva: nope |
| 01:22.17 | *** join/#brlcad WhiteCalf (MK@whitecalf.net) |
| 01:36.04 | CIA-77 | BRL-CAD: 03brlcad * r43357 10/brlcad/trunk/TODO: list the slew of requested and useful converters including step export, dae, x3d, g-code, u3d, 3D pdf, sat, ply, json, and xml formats |
| 02:23.25 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) |
| 02:34.22 | brlcad | starseeker: nice proof of concept chop-blocking |
| 02:34.58 | brlcad | would be good exercise to convert to db_walk_tree or one of the other walkers since the next step is probably to stop at the region level |
| 03:05.56 | starseeker | brlcad: ah, from what dloman was saying it sounded like we would break out every object in the first round |
| 03:07.09 | starseeker | also, if we stop at the region level, does that mean we do a full keep of each tree below the region level, even if it means duplicating geometry? |
| 03:09.27 | ``Erik | json? really? |
| 03:09.46 | brlcad | about as useful as xml ;) |
| 03:11.02 | brlcad | starseeker: either way but I think it's pretty much inevitable, also makes us parallel other cad packages (a region is a part) |
| 03:12.10 | brlcad | intermediate dev would be fine, but we probably shouldn't deploy down to the prim level since we haven't yet sorted out database upgrades |
| 03:12.24 | brlcad | and our next step given the new timeline is pretty much deployment ;) |
| 03:16.04 | brlcad | as for the duplication issue, i've had a plan in place to address that for about 7 years now -- effectively instantiating a more robust concept of a part (one with and without the region bit set) |
| 03:18.55 | starseeker | brlcad: so... first step is full keep and eat the duplication, then follow on later with the proper solution? |
| 03:19.10 | brlcad | and even without that concept, the duplication issue can become a non-issue by inverting the region-parent relationships (instead of C1->R1,R2,R3->subC1, you have C1->subC1,subC2,subC3->R1) |
| 03:19.55 | brlcad | basically, but it fortunately doesn't really require changes under the hood, just changes how geometry is managed on import |
| 03:20.35 | starseeker | kinda - but we'll have to migrate broken-out-at-region setups to the final solution |
| 03:20.51 | starseeker | is fine with it, just wants to be sure he's hacking the right thing |
| 03:21.00 | brlcad | not necessarily, it'll just be duplicate data |
| 03:21.16 | brlcad | we could automate remerging duplication later as a backend job |
| 03:21.22 | starseeker | nods |
| 03:21.46 | starseeker | all rightie, tree walking it is |
| 03:22.43 | brlcad | there would be one benefit of going all the way down to the primitive level, if you actually calculate the call overhead on a full vehicle with a checkin->breakout->commit->checkout->recombine scenario, see what the numbers look like, then redo stopping at region level |
| 03:23.19 | brlcad | see if it's actually a significant issue in practice on given arch, like macosx, that has bad i/o performance |
| 03:23.54 | brlcad | if it's not, then we could reasonably punt with confidence that it doesn't matter and let all objects get tracked uniformly |
| 03:24.04 | starseeker | nods |
| 03:24.20 | starseeker | it would simplify re-constructing a .g file - just dbconcat all the pieces |
| 03:24.39 | starseeker | building a bunch of regions with full trees back into the original .g is a bit of a chore |
| 03:24.52 | brlcad | without the metrics, though, I would definitely just stop at regions since there is pretty significant data overhead at the primitive level: 104 bytes per object |
| 03:25.20 | starseeker | nods - at least until we can get our own custom svn backend, anyway |
| 03:25.34 | brlcad | most objects in implicit form aren't even 104 bytes ;) |
| 03:26.18 | brlcad | the metrics are critical, though .. because the performance could be an outright show-stopper for a full vehicle |
| 03:26.22 | starseeker | overheads probably higher than that in the proof of concept code - I'm making everything its own .g file |
| 03:26.32 | brlcad | .g overhead is 104 bytes |
| 03:26.36 | starseeker | oh, gotcha |
| 03:26.47 | brlcad | and most of that is _GLOBAL, so there are other ways to optimize too |
| 03:27.12 | starseeker | the other approach is to do a more custom write - I took the quick and simple way to write out object data, but I could customize a routine to write JUST the object info |
| 03:27.29 | brlcad | though file ops likely dominate on files that small |
| 03:28.23 | starseeker | ('course if I do custom IO I might as well start looking at an FS-G backend now, and that's not the priority) |
| 03:28.38 | starseeker | will see if he can get the tree walker going and do the metrics |
| 03:28.59 | brlcad | the other benefit of constructing this region/non-region organization is that we can enforce proper DAG structures more easily -- CSG recipes would only be valid at/below region level, for example |
| 03:29.09 | brlcad | above, they're just assemblies, groups |
| 03:29.25 | brlcad | unions |
| 03:30.16 | brlcad | would effectively make it not possible to subtract assemblies from assemblies without pushing the operations down to the region level |
| 03:31.16 | starseeker | how would we combine region files of that type back into one .g file? scan for duplicate primitives and selectively import the ones not already present? |
| 03:31.35 | starseeker | what about changes to a multiply referenced primitive? how do we make sure we hit all the copies? |
| 03:35.35 | brlcad | the region file stored would already be the pushed result |
| 03:35.50 | brlcad | so the file being combined back on read is just cat-able |
| 03:36.03 | starseeker | you mean we wouldn't support unpushed geometry? |
| 03:36.12 | starseeker | ouch |
| 03:36.16 | brlcad | not following |
| 03:36.22 | brlcad | no no |
| 03:37.02 | brlcad | the ONE high-level operation (subtract assemb1 (with r1, r2) from assemb2 (with r3, r4)) |
| 03:37.16 | brlcad | would result in r3 and r4 getting modified |
| 03:38.02 | starseeker | right... I'm thinking a little lower level. let's say r3 and r4 both include sph1, and I change sph1 |
| 03:38.05 | brlcad | a "dumb" implementation would simply import r1/r2 into r3 and r4 and subtract them |
| 03:38.31 | starseeker | if r3 and r4 are both full tree copies in the repository, there are two independent copies of sph1 |
| 03:38.37 | starseeker | both of which need to be updated |
| 03:40.11 | brlcad | for example, you mean two 'sph1' instances in r3 ? |
| 03:40.52 | starseeker | no - I'm thinking I "break" model.g with two regions r1 and r2 into the repository: |
| 03:41.07 | starseeker | model.g (toplevel object) and two region files r1.g and r2.g |
| 03:41.28 | starseeker | both r1 and r2 union in the same primitive, sph1 |
| 03:41.45 | starseeker | if I'm doing a deep keep to create r1.g and r2.g, BOTH files have identical copies of sph1 |
| 03:42.06 | starseeker | if I then edit sph1 in my modeler, the implication is I'm changing both r1.g and r2.g |
| 03:42.13 | brlcad | that's not possible in the stop-at-region-level setup, the sph1 would be duplicated across the two regions |
| 03:42.30 | brlcad | if it needs to be reusable, then the definition of the region changes |
| 03:43.08 | starseeker | so you're saying that by definition a region does not contain any geometry objects that are used in any other regions? |
| 03:43.11 | brlcad | and you have model.g (toplevel), c1.g (was r1.g), c2.g (was r2.g) and a new r.g (containing the one sph1 instance) |
| 03:43.42 | brlcad | yes, all regions become fully self-contained namespaces |
| 03:44.06 | starseeker | shakes his head - I highly doubt that's how things work out in practice |
| 03:44.11 | brlcad | you can convert any existing model to that structure with the flip inversion I mentioned without loss of generality |
| 03:44.27 | starseeker | I'm not quite parsing the flip inversion |
| 03:45.03 | brlcad | I'll draw |
| 03:47.29 | starseeker | oh, wait - you're turning regions that are not self contained into assemblies, and creating regions below them of the shared subset? |
| 03:47.44 | brlcad | yes |
| 03:47.57 | starseeker | won't that really mess with region_id information>? |
| 03:48.23 | starseeker | if a geometry was set up with r1 and r2 having different region ids and shared geometry... |
| 03:48.47 | brlcad | not necessarily |
| 03:50.30 | brlcad | important note, though, that the progression is towards the minimization of region ids -- S2 will need updating to accommodate, but M3 uses different tracking mechanisms |
| 03:51.23 | starseeker | that definition of a region strikes me as a bit limiting - let's say I have a model of a screw, and I want to make 10 different regions using the same geometry but different material properties (aluminum screw, steel screw, etc...) - intentionally the same size and geometry but different regions, and the desire to have any change to screw dimensions propogate to all regions |
| 03:51.37 | brlcad | region id's in this new system become mostly irrelevant -- it's just attribute data |
| 03:51.47 | starseeker | brlcad: OK, we're assuming S2 changes as well - that's different |
| 03:52.23 | brlcad | the concept of a "part" is more that there's a point where they're no longer assemblies and become self-contained part data |
| 03:52.59 | brlcad | I really probably just need to write all this up in a document since it's a discussion that's come up before |
| 03:53.23 | starseeker | what happens to the different-materials same-geometry sceario? |
| 03:55.30 | brlcad | that's either multiple parts (which is what most cad packages do and matches our current "region" concept), or we have to implement support for multiple-segment regions |
| 03:55.57 | brlcad | the latter would be great for things like the vol primitive |
| 03:57.50 | brlcad | at this point, most of the issues on regions/materials/ids/etc can be punted so long as the routine that breaks up a .g has a means to stop at some level in the hierarchy -- whether at prim, region, one below region, one above, etc |
| 03:58.36 | brlcad | one solution to the multiply reference region was to invert downwards instead of upwards |
| 04:00.20 | brlcad | so every region becomes a region comb containing just one member, the former region hierarchy -- basically injects a comb node and pushes the region bit up and the "part" becomes a non-region |
| 04:00.41 | starseeker | nods |
| 04:01.20 | brlcad | so then S2 keeps doing what they're doing -- regions are unaffected |
| 04:01.27 | brlcad | region count is unchanged |
| 04:02.18 | brlcad | lil harder to ensure database integrity, so every region has one and only one member, a part |
| 04:03.27 | starseeker | hmm. Well, regardless it sounds like the first stage is to get a tree walker going and be able to control the break points |
| 04:05.26 | starseeker | likes the sound of multiple-segment regions, even if he doesn't know exactly what that would entail |
| 04:06.20 | starseeker | must sleep - early morning gym appointment (ugh) |
| 04:07.58 | brlcad | yeah, definitely |
| 04:39.55 | CIA-77 | BRL-CAD: 03brlcad * r43358 10/brlcad/trunk/TODO: consolidate the other conversion tasks |
| 06:33.18 | *** join/#brlcad Stattrav (~Stattrav@117.192.132.151) |
| 06:33.18 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) |
| 08:07.49 | *** join/#brlcad epileg (~epileg@unaffiliated/epileg) |
| 09:31.11 | *** join/#brlcad Stattrav (~Stattrav@117.192.132.151) |
| 09:31.11 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) |
| 09:44.05 | dloman | starseeker: brlcad: I'm not quite grasping at what problem we are solving by stopping the disassembly of the .g file at the region level.... |
| 09:44.26 | dloman | it seems to me it would cause much more problems than is worth the gain in simplicity... |
| 09:45.10 | dloman | Modelers frequently use a single prim from a region (r1) to subtract from another region (r2) for overlaps. |
| 09:46.27 | dloman | so, but keeping all the prims in the region level file, the GS would have to load two region .g's (entirely with all their geometry) just to get at the solid in r1 for r2... seems a bit clunky and complex |
| 09:46.57 | dloman | what was the 'gain' for keeping the geometry in the region level .g file? |
| 11:50.37 | ``Erik | hm, there's been argument that subtracting a region itself is incorrect, the proper way for that hack would be to make a subregion group, have the region contain the group, and subtract the group from other geometry O.o |
| 11:52.47 | ``Erik | dlo: I'm not making it in today, I'll be at upper chesapeake most of the day, I think the last fugly wart I left is the UUID shtuff if it's a show stopper and you want to regain functionality... my intent is to try to use the system uuid (e2fs or ossp, depending on os) with some cmake checks and #if e2fs #if ossp fu, if you need something rolling today |
| 11:53.43 | dloman | not likely, I'll probably be leaving early today... |
| 11:54.12 | dloman | the senario I am talking about is: r1 = s1 u s2 u s3 u s4 |
| 11:54.26 | dloman | r2 = s5 u s6 - s1 |
| 11:55.13 | dloman | I don't see why we would want to keep all the prims in the r1.g and r2.g file, such that we have a duplicate of s1 |
| 11:55.51 | ``Erik | hasn't read backlog and is getting ready to head to the hospital, will catch it all later O.o |
| 11:56.00 | dloman | ack, everything okay? |
| 11:56.20 | ``Erik | it's not for me |
| 13:19.56 | starseeker | dloman: if I understand correctly, the notion is that each region would be a fully independent piece of geometry |
| 13:20.31 | starseeker | by definition, there would be no shared geometry between regions, so subtractions to avoid overlaps would become a somewhat problematic way to handle things |
| 13:22.02 | starseeker | The main practical concern with breaking up the entire .g file into all its objects is IO performance (lots and lots of small files) |
| 13:23.03 | starseeker | brlcad also seems to have some ideas about enforcing region policy and .g structure |
| 13:23.31 | starseeker | isn't sure if that logic should live at the svn level or above it |
| 13:24.40 | starseeker | as far as the policy stuff, what I understand of it sounds OK but I'm not sure current modeling practices like you describe are really compatible with it |
| 13:27.02 | starseeker | e.g. subtracting parts of one interfering region from another region will result in a copy of the subcomponents needed for the subtraction appearing in the region being subtracted from, and those components will lose their relationship to the region being subtracted |
| 13:28.02 | starseeker | so if you have r1 and r2, and need to subtract c2 that is part of r2 from r1 to avoid an overlap, r1 would get a copy of c2 |
| 13:29.01 | starseeker | and changes to the original c2 in r2 would not be automatically propogated back to r1, unless we implement something to do that (which kinda violates the notion of each region being its own independent entity) |
| 13:42.21 | *** join/#brlcad epileg (~epileg@unaffiliated/epileg) |
| 13:44.04 | *** join/#brlcad epileg (~epileg@unaffiliated/epileg) |
| 14:15.23 | _psilva | hiyo |
| 14:31.07 | CIA-77 | BRL-CAD: 03brlcad * r43359 10/brlcad/trunk/src/irprep/ir-sgi.c: HAS_SGIGL .. isn't going to be around much longer. but test for it being set instead of being true until it's gone. |
| 14:32.23 | CIA-77 | BRL-CAD: 03brlcad * r43360 10/brlcad/trunk/src/irprep/ (firpass.c ir-X.c secpass.c shapefact.c): quell verbose warnings. mark unused params, size_t signage promotions, index shadows, and exact floating point comparisons. |
| 14:36.56 | CIA-77 | BRL-CAD: 03brlcad * r43361 10/brlcad/trunk/src/lgt/ (do_options.c execshell.c): need to include unistd.h |
| 14:47.22 | dloman | Hrm, well, putting a combination between a region and its prims doesn't solve the problem. |
| 14:48.14 | dloman | I can 99.99% gurantee that dupicating geometry (in the example, s1) will be *adding* a substantial maintenance burden on the modelers |
| 14:48.24 | dloman | especially if s1 is a somewhat sizable bot. |
| 14:50.19 | dloman | additionally, although diskspace is 'cheap' and we should only solve problems when they become a problem |
| 14:51.07 | dloman | wouldn't duplicating s1 in two spots actually end up as a net negative performance on IO, since we would technically have to read that prim twice? |
| 14:51.32 | dloman | We can't ignore overlaps, as the are GOING to happen. Of this, I am 110% certain. |
| 14:52.15 | starseeker | dloman: I may be missing some of the implications of what brlcad is describing, so he should weigh in |
| 14:52.27 | dloman | add in the increasing data sizes due to bots and the impending complex nurbs, and I don't see 'each region as its own, idependent, entity' as being a good idea. |
| 14:52.35 | dloman | sure thing. |
| 14:53.12 | dloman | I am just trying to understand how brlcad and i got our wires crossed.... cause this is not the impression i got, walking away from our last discussion on the subject :/ |
| 14:53.27 | dloman | or more specificly, what brlcad's notion is. |
| 14:53.59 | dloman | is remote today, so Im not in office. |
| 14:54.07 | starseeker | dloman: did you read the scrollback from last night? |
| 14:54.33 | dloman | yuppers. |
| 14:54.37 | starseeker | you might be able to follow it better than me |
| 14:54.58 | CIA-77 | BRL-CAD: 03brlcad * r43362 10/brlcad/trunk/src/nirt/ (command.c interact.c nirt.c nirt.h parse_fmt.c read_mat.c): eliminate the rtip global. propagate api changes throughout. |
| 14:55.09 | dloman | and keeping the prims in the region .g's is, in my opinion, going to cause a ****-ton of issues. |
| 14:56.12 | dloman | keeping all the solids in their own file, just like the c's and r's, but in a directory named after the associated r, is what i understood our approach was. |
| 14:57.05 | dloman | yes, it creates many more files, but i honestly think its more flexible and will be lower IO in the long run. |
| 14:58.35 | CIA-77 | BRL-CAD: 03brlcad * r43363 10/brlcad/trunk/src/nirt/showshot.c: convert %F to %lf. not optimal, but gefn |
| 14:58.38 | *** join/#brlcad Stattrav (~Stattrav@117.192.132.151) |
| 14:58.38 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) |
| 15:20.43 | dloman | starseeker: do you know if its bad to change an #include <string> to #include <string.h> ? |
| 15:21.08 | starseeker | uh. isn't the first one C++ and the second one C? |
| 15:21.29 | dloman | thats what i thought too. just checking. |
| 15:21.55 | dloman | hard to google things with a 13 month old in one arm :) |
| 15:23.14 | starseeker | heh |
| 15:23.21 | starseeker | winces |
| 15:23.54 | starseeker | havoc checkout takes 35 megs doing the write-out-every-object scheme |
| 15:24.31 | CIA-77 | BRL-CAD: 03brlcad * r43364 10/brlcad/trunk/src/proc-db/ (brickwall.c masonry.c): quell warnings, exact floating point comparisons |
| 15:24.37 | starseeker | guess the every-object-is-a-g-database thing isn't so hot |
| 15:24.53 | starseeker | commits anyway... |
| 15:25.10 | starseeker | oh, took several minutes to commit and checkout, too |
| 15:25.18 | dloman | why is that bad? whats the original filesize? |
| 15:25.37 | CIA-77 | BRL-CAD: 03brlcad * r43365 10/brlcad/trunk/src/proc-db/kurt.c: !EQUAL instead of != for floating point comparison |
| 15:25.37 | starseeker | 580K |
| 15:26.25 | dloman | looks like the per file overhead is a bit more than 104 bytes eh? |
| 15:26.36 | dloman | or are there a bajillion files? |
| 15:26.55 | starseeker | yeah, there's a lot of files |
| 15:26.55 | CIA-77 | BRL-CAD: 03brlcad * r43366 10/brlcad/trunk/src/proc-db/ (16 files): quell verbose compilation warnings mostly related to unused params and vars, shadowings, and checking usage. |
| 15:27.16 | starseeker | plus the .svn checkout keeps a baseline copy of each file and a properties file for each file |
| 15:27.28 | starseeker | .svn is 23 Megs, rest is checkout |
| 15:28.43 | dloman | idealisticly, we could boil the whole repo down to one or two baseline versions of each prim, and just use a ton of matricies :) |
| 15:28.45 | CIA-77 | BRL-CAD: 03starseeker * r43367 10/geomcore/trunk/tests/svntest/main.c: Try writing out every object, and directory organization. Use havoc for more of a stress test - performance doesn't look promising |
| 15:29.10 | starseeker | somewhat amusingly, the actual repository (as opposed to the checkouts) is 1.7 megs |
| 15:31.06 | dloman | thought: if we are using dbobject names to link to other files, why can't a region contain all its own prims, but still be able to link to other region .g's for prims too ? whats wrong with that? |
| 15:31.34 | starseeker | uh... |
| 15:31.50 | starseeker | that gets back to the whole "redefine what a region means" problem |
| 15:34.52 | dloman | Well, what ever the solution is, having two copies of the same solid, one to construct r1, one to be a overlap subtraction for r2, is going to make a bunch of people really upset. |
| 15:35.09 | starseeker | hmm... so if the count is right, there were just shy of 3000 objects, which means counting the base files and props files just shy of 9000 files for havoc, not counting any other svn files in the checkout |
| 15:36.34 | dloman | as in 9000 in the repo and 3000 end user visible? |
| 15:36.41 | starseeker | yep |
| 15:37.16 | dloman | well, thats better than I thought :) brlcad and I were thinking an average of 10k per model. |
| 15:37.25 | dloman | granted, its just havoc |
| 15:37.31 | starseeker | nods |
| 15:37.37 | starseeker | simple model |
| 15:37.47 | dloman | but converted geometry is like to have less objects, but larger size per |
| 15:38.18 | dloman | i think the last conversion i worked with had about 1500 db objects, but the .g file size was 280 mges |
| 15:38.24 | starseeker | I suppose committing and checking out an entire model in one gulp could also be regarded as worst case |
| 15:38.24 | dloman | megs |
| 15:38.41 | dloman | yeah, untill the multi-system projects start hooking in :) |
| 15:39.15 | starseeker | "checking out" in this case is also creating the repository on disk |
| 15:39.29 | brlcad | that overhead is pretty much what I expected |
| 15:39.48 | brlcad | so the checkout is 1.7, repo is 23 .. original was? |
| 15:39.49 | starseeker | it might be worth investigating if there are ways to talk to the repo without an explicit checkout to disk |
| 15:40.11 | starseeker | no, checkout is 35, repo is 1.7, original was 580K |
| 15:40.21 | starseeker | 35 Meg, 1.7 Meg |
| 15:40.39 | brlcad | checkout includes .svn dir data |
| 15:40.42 | brlcad | what's the export size? |
| 15:40.45 | starseeker | running the test as currently committed on the Mac takes 4.5 minutes |
| 15:41.02 | starseeker | about 12 Megs, I think... |
| 15:41.10 | brlcad | figure the mac should be worst case performance, so it's a good baseline |
| 15:42.07 | brlcad | the reason for stopping at the region level was to fight some of that performance, I expect it to knock that at least in half if not more |
| 15:42.47 | dloman | so with stopping at the r level, how does one handle using s1 from r1 as a subtraction in r2? |
| 15:43.04 | brlcad | putting the repo more on par with the .g size (maybe 25% expansion, minor), and checkout around an order larger |
| 15:43.40 | brlcad | in the short term or long term? :) |
| 15:43.59 | brlcad | and under the hood, or exposed-to-user? |
| 15:44.05 | dloman | exposed to user |
| 15:45.10 | brlcad | going to take a sec to write |
| 15:51.27 | dloman | gets his grub on while he waits. Grilled Cheeze == nom nom nom |
| 15:52.57 | brlcad | so "s1" is some member of this 'part' object "r1", which I'm going to intentionally avoid calling a region for reasons that will hopefully become evident. so this piece of solid part r1 is being used as a subtraction shape on solid part r2. previously both in their same namespace, but no longer with this new 'part' concept -- each part is a unique namespace. so the subtraction of r1/s1 from r2 becomes a cross-namespace reference for the overlapping portions ( |
| 15:53.41 | CIA-77 | BRL-CAD: 03r_weiss * r43368 10/brlcad/trunk/src/libbn/bntester.c: Added to 'bntester' support for testing function 'bn_isect_lseg3_lseg3'. |
| 15:54.01 | brlcad | cross-reference namespace then become a conscious decision of modelers to import data (breaking the need for a cross-namespace reference), or refactor into a new base part that both r1 and r2 reference |
| 15:54.36 | brlcad | basically what they do now, just with an implicit single namespace |
| 15:55.02 | brlcad | I'll have to revisit our notes from that half-day discussion we had -- because we had it pretty lock solid then |
| 15:55.43 | brlcad | I might have a minor detail off, but shouldn't be far off .. but then it was a couple months ago :) |
| 15:56.14 | dloman | okay, will the end user have to maintain two 's1's or just one? |
| 15:56.15 | brlcad | the whole problem revolved around solving mergability of .g files |
| 15:56.31 | brlcad | they get to decide -- default would be just one s1 |
| 15:57.07 | brlcad | an s1 from the r1 namespace, r1::s1 |
| 15:57.27 | brlcad | if imported as r1::s1 and r2::s1, then they have to make a decision whether those are mergable or not |
| 15:57.52 | dloman | so a modeler uses s1 from part1, or part1::s1, in part2 as a subtraction, or part2 = part2::s1 - part1::s1 |
| 15:57.53 | brlcad | but then we can provide tools to assist with that decision process -- auto-merge identical geometry, for instance |
| 15:58.10 | brlcad | right |
| 15:58.16 | dloman | and the modeler doesn't want to make a new part.... how do we store that on our end? |
| 15:58.41 | starseeker | if I'm going to sort assemblies out from combinations, I'll probably have to get search set up to return a list of directory pointers - the ged results string won't cut it |
| 15:58.42 | brlcad | then it's a configuration option as to what they might want to auto-do with that type of operation -- auto-import/copy, keep the reference, etc |
| 15:59.13 | brlcad | it literally just becomes a named reference, part1::s1 in part2 |
| 16:00.27 | brlcad | part2 was just "u s1" with s1 being an implicit part2::s1 -- with the subtraction and absent any automerging, it becomes: "u s1 - part1::s1" as string data in the .g file |
| 16:00.53 | brlcad | the part that's escaping me at the moment (no pun intended) is how we solved the "where's my namespace" problem |
| 16:01.02 | dloman | so we wont be storing two copies of part1::s1 ? |
| 16:01.11 | brlcad | nope |
| 16:01.27 | dloman | okay then. |
| 16:01.53 | dloman | so by this logic, the overall svn dir structure wont ever exceed two dirs deep? (but be very wide) ? |
| 16:01.53 | brlcad | only if they request exactly that as an operation -- "cut my external refs" .. "import external refs", etc |
| 16:02.09 | brlcad | that's the part that I'm not remembering without our notes |
| 16:02.20 | brlcad | we'd solved that issue |
| 16:02.35 | brlcad | I think it was with top-level namespacing |
| 16:02.53 | brlcad | so not a part1 namespace, but some higher tank1 namespace and tank2 namespace |
| 16:03.16 | dloman | right, per my understanding and notes and diagrams, we left our last talk thinking the repo will be three layers deep: projects->combs/regs->prims |
| 16:03.31 | dloman | now i'm hearing different, hence my confusion :) |
| 16:03.57 | brlcad | s/projects/namespaces/ and I can see that :) |
| 16:04.26 | brlcad | yeah, I wasn't being entirely precise last night as the focus was more just that there needs to be "some" mechanism to halt traversal part-way down the DAG |
| 16:04.45 | brlcad | because of the horrid performance impact I was anticipating |
| 16:04.50 | dloman | namespaces->regions/combs .... thats it, since all the prims will be stored in the files in the regions/combs level |
| 16:05.54 | dloman | ..if I am understanding correctly. |
| 16:05.55 | brlcad | yeah, the details are starting to come back to me now :) |
| 16:06.12 | starseeker | I can probably get a rough idea of how expensive writing out regions will be, but it won't be meaningful until I can sort out the assemblies and that's not so straightforward |
| 16:06.59 | *** join/#brlcad roberthl (~robert@v001.rhl.me.uk) |
| 16:06.59 | *** join/#brlcad roberthl (~robert@mediawiki/RobertL) |
| 16:07.18 | starseeker | almost feels like the search logic needs to move from ged to somewhere else |
| 16:07.23 | starseeker | and have ged wrap it |
| 16:07.27 | starseeker | but not sure where to move it |
| 16:07.30 | brlcad | yep, librt |
| 16:07.38 | starseeker | heh, that works |
| 16:07.43 | brlcad | mged -> libged -> librt is the progression of logic |
| 16:07.52 | brlcad | there's a lot in libged that belongs in librt |
| 16:08.14 | starseeker | ok, I'm gonna have to move that as a first step - I need the search filters to do an intelligent breakout |
| 16:08.19 | brlcad | libged in a final state would actually end up with very little, just state container wrappers and string parsing really |
| 16:09.37 | brlcad | daniel's comment was a good one, libged isn't really optimal underneath the GE -- it's at the same level, so most of the geometry manipulation it performs is logic that should be in librt (and is, in a way) |
| 16:10.19 | brlcad | it becomes more of a transaction management interface that bridges and simplifies all that's possible with librt |
| 16:13.07 | brlcad | dloman: will have to revisit the notepad next time I'm in the office (maybe friday) to make sure we're fresh on the solution we came up with, it was pretty tight and there are a few particulars I'm not remembering at the moment |
| 16:13.18 | dloman | so GE *isn't* a C++ wrapper for libged? |
| 16:13.29 | dloman | I likely won't be back in the office till next Wednesday |
| 16:13.57 | brlcad | it could be as an interim solution, but really shouldn't be |
| 16:14.56 | brlcad | libged is really a transactional command parsing library .. that string parsing foo is major suck for any sort of performance geometry processing |
| 16:15.02 | brlcad | GE is more akin to ACIS |
| 16:15.05 | dloman | so if the GE is side by side with ged, then any/all common functionality needs to be pushed down into librt (and possibly elsewhere too) otherwise we're duplicating code? (Did i capture the concept correctly?) |
| 16:15.19 | brlcad | you got it |
| 16:15.55 | brlcad | alternatively, pushed into GE and libged sits on top of GE .. but librt makes more sense at the moment |
| 16:16.29 | dloman | isn't libged primarily c? |
| 16:16.38 | brlcad | basically "libged > GE > librt" or "libged,GE > librt" (current plan) |
| 16:16.53 | brlcad | right, that's why it makes more sense to stay that way |
| 16:17.24 | brlcad | it could easily be an encapsulated wrapper, where the GE c++ness would be mere implementation detail like opennurbs in librt |
| 16:17.42 | dloman | in order to keep the code from getting wicked stupid, then GE would also need to be c, not C++ ...? |
| 16:17.52 | brlcad | not at all |
| 16:18.25 | brlcad | because libged's api is presently a single data container and argc/argv string data |
| 16:18.41 | brlcad | what goes on under the hood stays under the hood |
| 16:18.50 | brlcad | (bom chika wah wah) |
| 16:21.59 | CIA-77 | BRL-CAD: 03brlcad * r43369 10/brlcad/trunk/src/remrt/ihost.c: if DEFINED, not if NOT defined |
| 16:22.04 | brlcad | oof, that took a while to see... |
| 16:30.11 | dloman | alright, Im going afk for a few days. I expect the GS to be finished when I return. Hop to it! :P |
| 16:31.26 | dloman-afk | (I only say that cause its now very apparent to me that I have (and had) no idea what I'm doing, heh ) |
| 16:41.24 | brlcad | we need to get rolling on gsoc preparations if you all are interested in mentoring again -- the ideas page needs major updating |
| 16:51.45 | CIA-77 | BRL-CAD: 03brlcad * r43370 10/brlcad/trunk/src/remrt/ihost.h: include the headers this header requires, self containment |
| 16:52.26 | starseeker | sounds like fun |
| 16:52.33 | CIA-77 | BRL-CAD: 03brlcad * r43371 10/brlcad/trunk/src/remrt/ (remrt.c rtsrv.c): mark unused params, check argc params, terminal sentinel with NULL instead of 0, and other quellage |
| 17:21.15 | _psilva | hey brlcad |
| 17:21.20 | _psilva | got some news for you |
| 17:24.42 | brlcad | sup? |
| 17:25.16 | brlcad | you spawned a child process? :) |
| 18:25.45 | _psilva | then it's two thing |
| 18:25.48 | _psilva | hah |
| 18:25.54 | _psilva | due march 16 ish |
| 18:26.08 | _psilva | but even bigger and more relevant |
| 18:26.20 | _psilva | we got bought by autocad |
| 18:26.23 | _psilva | er |
| 18:26.25 | _psilva | autodesk |
| 18:26.55 | _psilva | http://usa.autodesk.com/adsk/servlet/index?id=16284057&siteID=123112 |
| 18:27.11 | _psilva | is now autodesk employee |
| 19:31.35 | starseeker | _psilva: do we offer condolances? |
| 20:05.30 | brlcad | _psilva: heh, well congrats on the 16th and condolences on the 30th (april) |
| 20:09.46 | _psilva | heh |
| 20:10.23 | _psilva | at least we're not being relocated |
| 20:10.30 | _psilva | :) |
| 20:15.10 | _psilva | we'll see |
| 20:15.19 | _psilva | gonna stick around until something more interesting pops up |
| 20:31.35 | CIA-77 | BRL-CAD: 03jordisayol * r43372 10/brlcad/trunk/ (misc/debian/control sh/make_deb.sh): modify dependencies to build deb packages |
| 21:01.58 | CIA-77 | BRL-CAD: 03starseeker * r43373 10/brlcad/trunk/ (7 files in 3 dirs): Make a stab at moving search logic to librt |
| 21:22.17 | CIA-77 | BRL-CAD: 03starseeker * r43374 10/brlcad/branches/cmake/ (56 files in 18 dirs): MFC r43373 |
| 21:33.37 | CIA-77 | BRL-CAD: 03starseeker * r43375 10/brlcad/trunk/src/librt/search.c: Fix order of inputs, UNUSED some inputs |
| 21:37.27 | CIA-77 | BRL-CAD: 03starseeker * r43376 10/brlcad/branches/cmake/src/librt/search.c: MFC r43375 |
| 21:38.15 | CIA-77 | BRL-CAD: 03brlcad * r43377 10/brlcad/trunk/src/librt/bool.c: |
| 21:38.15 | CIA-77 | BRL-CAD: call NEAR_EQUAL() with a 0.001 tolerance instead of rt_fdiff() since that |
| 21:38.15 | CIA-77 | BRL-CAD: function is deprecated. this potentially affects fastgen platemode overlap |
| 21:38.15 | CIA-77 | BRL-CAD: reporting since it's no longer performing a relative tolerance comparison, but |
| 21:38.16 | CIA-77 | BRL-CAD: the impact shouldn't be too significant since the absolute tolerance is rather |
| 21:38.16 | CIA-77 | BRL-CAD: loose at 0.001 |
| 21:40.26 | CIA-77 | BRL-CAD: 03starseeker * r43378 10/brlcad/branches/cmake/src/ (libged/CMakeLists.txt librt/CMakeLists.txt): Fix CMake logic for search file changes |
| 21:41.25 | CIA-77 | BRL-CAD: 03brlcad * r43379 10/brlcad/trunk/src/librt/db_flip.c: |
| 21:41.25 | CIA-77 | BRL-CAD: use a bridge pattern to separate the deprecated function logic into new private |
| 21:41.25 | CIA-77 | BRL-CAD: functions. this lets us continue to be able to flip v4 files, even after the |
| 21:41.25 | CIA-77 | BRL-CAD: deprecated rt_* functions become obsolete, yet allows for the API to continue |
| 21:41.25 | CIA-77 | BRL-CAD: working for now. |
| 21:41.35 | CIA-77 | BRL-CAD: 03brlcad * r43380 10/brlcad/trunk/src/librt/librt_private.h: declare the new flip functions |
| 21:42.24 | CIA-77 | BRL-CAD: 03brlcad * r43381 10/brlcad/trunk/src/librt/binunif/db5_bin.c: call ntohl() and htonl() instead of the deprecated libbu functions. |
| 21:42.53 | CIA-77 | BRL-CAD: 03brlcad * r43382 10/brlcad/trunk/src/librt/comb/db_comb.c: call the new private flip funcs instead of the deprecated api. |
| 22:33.32 | brlcad | starseeker: librt api should not have argc/argv parameters |
| 22:34.29 | starseeker | brlcad: all right, I'll have to revert then - reworking the code to not use them could be a significant effort |
| 22:34.39 | brlcad | yeah, moving search to librt is not going to be a simple move |
| 22:34.45 | brlcad | it needs to work on data |
| 22:35.22 | starseeker | well, that's a days work down the drain |
| 22:35.29 | brlcad | data in, data out -- no printing to console (except diagnostic) |
| 22:36.03 | starseeker | uh... it's not printing to console |
| 22:36.10 | brlcad | so you'd get back, for example, an array of rt_db_internal pointer's from a given query -- the search front-end would iterate over a result and print their names |
| 22:37.09 | starseeker | that's edging dangerously close to a complete rework |
| 22:37.28 | brlcad | I was surprised that you were heading down that road :) |
| 22:37.42 | starseeker | well, is there another way to spot assemblies? |
| 22:37.45 | brlcad | it's doable, not necessarily a rewrite |
| 22:38.10 | brlcad | the hardest part of search is building up that query filtering logic, stopping criteria -- that all stays the same |
| 22:38.31 | starseeker | if I'm going to do the one .g per region, I have to be able to identify the assembly combinations - they will need to be written out as their own objects, since the region .g files won't handle them |
| 22:40.05 | brlcad | search still sounds like a good approach for that |
| 22:40.27 | brlcad | you just have to split things up some |
| 22:40.47 | CIA-77 | BRL-CAD: 03starseeker * r43383 10/brlcad/trunk/src/librt/search.c: |
| 22:40.47 | CIA-77 | BRL-CAD: Add logic to append directory pointer entries to a list - will allow for |
| 22:40.47 | CIA-77 | BRL-CAD: manipulation of objects found in C code without having to re-parse string. For |
| 22:40.47 | CIA-77 | BRL-CAD: now, only return pointer to leaf node of path - could conceivably be expanded if |
| 22:40.47 | CIA-77 | BRL-CAD: there is a need. |
| 22:40.50 | brlcad | somewhere in search, I'm sure it's taking the input argc/argv and turning that into an in-memory expression of some sort |
| 22:41.08 | starseeker | brlcad: it is. I'm quite sure it can be done, but it's... tangled |
| 22:41.27 | brlcad | that logic stays in libged's search front-end, librt takes that in-memory expression as a parameter to rt_search() |
| 22:41.45 | brlcad | layers, like an onion ;) |
| 22:41.56 | starseeker | brlcad: what should I do - full revert, put everything back in libged? |
| 22:42.23 | starseeker | I'm pretty sure I won't have time until next month to do that kind of sorting out of the search logic |
| 22:46.26 | brlcad | might as well |
| 22:46.39 | starseeker | k |
| 22:46.59 | CIA-77 | BRL-CAD: 03starseeker * r43384 10/brlcad/branches/cmake/src/librt/ (6 files in 3 dirs): MFC r43383 |
| 22:48.17 | brlcad | at a glance, looks like it's pretty close already -- find_formplan() would become something like rt_search_plan(), find_execute() would probably become something like rt_search(). that'd be your two new api hooks |
| 22:48.59 | brlcad | ged_search() looks rather peculiar to me.. how does it know how many expression arguments there are?? |
| 22:50.00 | starseeker | what, the altered one or the original? |
| 22:50.47 | starseeker | OK, everything should be back in place |
| 22:51.03 | brlcad | I don't know -- I'm just looking at my current checkout with is r42551 |
| 22:51.22 | starseeker | oh, yeah that's the original |
| 22:51.42 | brlcad | Oh.. is the entire expression in argv[1]?? |
| 22:51.45 | brlcad | heh |
| 22:51.47 | starseeker | yeah |
| 22:51.49 | brlcad | wow |
| 22:51.55 | starseeker | it's up to the search functions to make sense of it |
| 22:52.21 | brlcad | so yeah.. a few changes |
| 22:53.59 | brlcad | ged_search() should take variable argc/argv, one per actual argument .. that would get parsed into an "rt_search_plan" struct of some sort (basically a custom "PLAN *"), that'd get passed to rt_search() |
| 22:54.29 | CIA-77 | BRL-CAD: 03starseeker * r43385 10/geomcore/trunk/tests/svntest/main.c: |
| 22:54.30 | CIA-77 | BRL-CAD: Add some commented out code based on the test code used in ged_search to test |
| 22:54.30 | CIA-77 | BRL-CAD: directory pointer list printing. Will need to construct argc/argv input for |
| 22:54.30 | CIA-77 | BRL-CAD: rt_search, but this should in principle allow the identification in C code of |
| 22:54.30 | CIA-77 | BRL-CAD: assemblies. |
| 22:54.55 | brlcad | librt could provide rt_search_plan() as a helper function to turn the string data into an rt_search_plan, but you'd be able to bypass that and do it all string-less with rt_search() then if you wanted |
| 22:54.57 | starseeker | brlcad: we need to be careful there - the find command has its own option handling logic, I don't know how similar it is to our normal stuff |
| 22:56.16 | brlcad | not too careful -- at worse, ged_search() and/or rt_search_plan() would just join all of the argv parameters together into one bit string and pass to find's plan making code |
| 22:56.45 | starseeker | uh... if we're doing that, why bother splitting them up in the first place? |
| 22:57.02 | brlcad | ahh, I see -- it's not one big string |
| 22:57.12 | brlcad | it's iterating afterall |
| 22:57.20 | brlcad | but requires a NULL-terminated argv |
| 22:57.46 | brlcad | you're not splitting them up, they start out split up |
| 22:58.18 | starseeker | sort of - formplan gets argv[2] |
| 22:59.10 | brlcad | but as a char **, it then iterates over the argv elements individually |
| 22:59.18 | starseeker | right |
| 22:59.35 | brlcad | so it's not all in argv[1]/argv[2] |
| 22:59.43 | brlcad | it's already a proper argv list |
| 22:59.57 | starseeker | brlcad: as long as we're at this... is there a function somewhere to do for bu_lists or some other bu data structure what uniq does on the unix command line? |
| 23:00.53 | starseeker | you hand mentioned wanting to fix some search behavior that was unexpected, and iirc it required always doing a full path iteration, so to simulate searching through ls results we would need to do some kind of uniq filtering |
| 23:00.57 | CIA-77 | BRL-CAD: 03starseeker * r43386 10/brlcad/trunk/ (7 files in 3 dirs): Sigh. Put search back in libged for now - need to split out the argument parsing logic into libged and the backend logic into librt first. |
| 23:01.03 | brlcad | bu_ptbl's have unique awareness for pointer tracking |
| 23:01.30 | brlcad | bu_ptbl_ins_unique() |
| 23:01.34 | starseeker | hmm... can I stash directory pointers in a bu_ptbl? |
| 23:01.45 | brlcad | ptbl == pointer table |
| 23:01.48 | brlcad | arbitrary pointer container |
| 23:02.19 | starseeker | ok, that might do then |
| 23:02.23 | brlcad | redblack trees have similar uniqueness insertion routines |
| 23:02.39 | brlcad | depends what sort of O behavior you need |
| 23:03.21 | brlcad | so search is already pretty close to what you'd need for librt from what I'm seeing here |
| 23:03.58 | brlcad | the biggest change is just fixing the routine names, creating corresponding rt_ prefix names for the api |
| 23:04.26 | starseeker | and making sure everything functions in libged/librt respectively |
| 23:04.29 | brlcad | the code already has that separation I referred to |
| 23:05.07 | starseeker | ah, good :-) |
| 23:05.19 | brlcad | think of it as only migrating find_formplan() and find_execute() to librt, but not with those names |
| 23:05.48 | brlcad | ged_search() stays in libged exactly as it is, just pointing to the new names instead of find_formplan() and find_execute() |
| 23:06.02 | starseeker | well, I've got tomorrow so I'll do what I can |
| 23:06.14 | brlcad | instead of find_formplan() returning a PLAN*, it should be some rt_plan_t or somesuch |
| 23:06.57 | starseeker | hmm - db_plan_t maybe? |
| 23:07.01 | brlcad | find_formplan() would get renamed to something like rt_search_plan(); find_execute() would get renamed to something like rt_search() |
| 23:07.13 | starseeker | doesn't really have much to do with raytracing - db_ prefix may make more sense |
| 23:07.17 | brlcad | it could be db_ api instead of rt_ api |
| 23:07.18 | brlcad | sure |
| 23:07.31 | brlcad | unless it's going to return rt_db_internal objects |
| 23:07.34 | brlcad | then it's rt_ api |
| 23:07.47 | brlcad | I think |
| 23:07.51 | brlcad | have to check on that one |
| 23:08.11 | brlcad | ah, yes, find_execute() would have to be refactored to not have a gedp parameter |
| 23:08.23 | brlcad | same with findplan |
| 23:08.49 | starseeker | will probably return a list of db_full_path structs and a bu_ptbl of directory pointers |
| 23:09.07 | starseeker | yeah, ged structs are everywhere in there |
| 23:09.20 | starseeker | I got those out once, so I'm not too worried about that - just takes time |
| 23:10.30 | starseeker | or if directory pointers make it rt_ specific, could just return db_full_path list and let the calling function sort it out |
| 23:11.18 | starseeker | that's probably cleaner |