| 01:36.29 | *** join/#brlcad louipc (~louipc@archlinux/trusteduser/louipc) |
| 03:00.15 | starseeker | brlcad: http://pastebin.mozilla.org/1124576 |
| 04:44.32 | brlcad | starseeker: thanks |
| 04:44.37 | brlcad | try with that fix |
| 04:44.44 | CIA-77 | BRL-CAD: 03brlcad * r43680 10/brlcad/trunk/src/librt/primitives/extrude/extrude.c: |
| 04:44.44 | CIA-77 | BRL-CAD: pull the declaration of center2d (and his friends) up to the top scope to make |
| 04:44.44 | CIA-77 | BRL-CAD: sure the warning reflects the current file state. preprocessor directive in |
| 04:44.44 | CIA-77 | BRL-CAD: that function was missing a semicolon, so perhaps that was confusing gcc? see |
| 04:44.44 | CIA-77 | BRL-CAD: if we still get an uninitialized use warning now that it's outside of the loop. |
| 04:44.52 | brlcad | I think I understand what it's detecting |
| 04:45.29 | brlcad | it is really obscure and apparently not without bugs if those line numbers are to be believed |
| 04:46.30 | brlcad | but the center2d var was declared inside a loop, which I believe is only initialized once, but not per iteration like one might expect so it's possibly warning based on the future use. |
| 04:47.08 | brlcad | the only thing unique about that function, however, was an inconsistent macro call, so still a little bit of a mystery |
| 04:47.26 | brlcad | that'd be a good one to see the post-preprocessor output being fed to gcc |
| 05:45.01 | *** join/#brlcad roberthl_ (~robert@v001.rhl.me.uk) |
| 05:52.40 | brlcad | outstanding spelunking on the red failure, great to know exactly why it was failing but working with HEAD |
| 05:53.12 | brlcad | starseeker: so do you know which regex feature wasn't supported? |
| 05:54.02 | brlcad | curious how our regex worked and theirs didn't, because theirs is actually a never derivative |
| 05:54.16 | brlcad | unless if it's something like the regex enums don't match, hmm |
| 05:54.52 | brlcad | aha, yep that's it |
| 05:56.22 | brlcad | REG_NEWLINE is 300 for Tcl and 10 for ours |
| 05:56.28 | brlcad | REG_EXTENDED matches |
| 05:59.12 | brlcad | so that mystery is solved |
| 06:00.15 | brlcad | one take-home lesson to keep in mind for cmake is that it will have to make sure include directories are NOT listed if a src/other dep is not going to be compiled, otherwise that same type of problem can happen with any of them (png, libz, ..) |
| 06:54.44 | *** join/#brlcad epileg (~epileg@unaffiliated/epileg) |
| 06:58.14 | *** join/#brlcad Robert___ (~robert@v001.rhl.me.uk) |
| 07:06.46 | vtts | any way to fix this? http://pastebin.com/rFeVqwHG |
| 07:07.51 | vtts | happens when I click on Edit -> Combination Editor |
| 07:09.12 | vtts | same goes for "Attribute Editor" and similar oneline error in command window for geometree command |
| 07:09.36 | vtts | (mac os x) |
| 07:12.33 | vtts | version from svn r43679 |
| 08:04.12 | *** join/#brlcad Stattrav (~Stattrav@122.172.12.71) |
| 08:04.12 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) |
| 08:14.20 | *** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ) |
| 12:52.07 | starseeker | brlcad: is this what you need? http://bzflag.bz/~starseeker/extrude.preprocess |
| 12:52.24 | starseeker | (that's without applying you're latest fix) |
| 12:53.16 | starseeker | brlcad: as a rule, the include directory variables should do the right thing when a src/other dep is turned on or off |
| 12:53.20 | starseeker | (for cmake) |
| 12:53.46 | starseeker | that one is a particular problem because we can have the situation where regex is off and tcl is on |
| 12:54.20 | starseeker | (or was until the rename anyway) |
| 12:58.58 | starseeker | bah s/you're/your/ |
| 13:00.52 | starseeker | sweet - that last tweak to extrude looks like it got it |
| 13:00.56 | dloman | @anyone: How are tcl scripts 'automatically' loaded when mged launches? Aka, if I have a tcl script or two I'd like to put in a few of my scripts i've written and make them load whenever mged launches.... |
| 13:01.07 | starseeker | thanks for following that up brlcad - that was waaay out of my depth :-P |
| 13:01.35 | starseeker | uh... I think you can do that by putting source statements in .mgedrc? |
| 13:01.46 | dloman | righto, got that part |
| 13:02.03 | dloman | just with no user configging, aka 'its part of mged' |
| 13:02.49 | starseeker | uh... you'd have to stick them in one of the directories that libtclcad's autopath logic (or the system tcl/tk) know about and alter the pkgIndex.tcl file (I think?) |
| 13:03.07 | starseeker | take a look at what src/tclscripts files do |
| 13:03.36 | dloman | awesome, thanks. |
| 13:06.28 | starseeker | eyes the failure of toyjeep.g to convert with release flags turned on... http://pastebin.mozilla.org/1126164 |
| 13:06.51 | starseeker | that seems to happen ONLY when I turn on release build flags - with debug flags it succeeds |
| 13:09.01 | starseeker | is that another one specific to my system or has someone else seen it? |
| 13:14.13 | starseeker | this is the problem child: http://bzflag.bz/~starseeker/pipeproblem.asc |
| 13:20.45 | d_rossberg | starseeker: what do you mean with "convert"? |
| 13:27.25 | starseeker | asc2g |
| 13:32.37 | starseeker | d_rossberg: oh - have you had any chance to see if your particular cmake logic can work with the new cmake build? |
| 13:33.49 | d_rossberg | no, haven't tested yet |
| 13:34.17 | starseeker | hmm - maybe I'm wrong, asc2g failed with both builpes... |
| 13:35.07 | starseeker | d_rossberg: k. I'll try to take a look myself if I get a chance - that's the main hurdle for being able to move the CMake logic to trunk (even if we don't use it as the "default" build logic) |
| 13:35.54 | starseeker | s/builpes/both build configs/ |
| 13:37.31 | starseeker | here's a little more detail on the pipe failure: http://pastebin.mozilla.org/1126269 |
| 13:39.32 | starseeker | looks like VDOT is coming back with -1, which acos doesn't like... |
| 13:42.43 | d_rossberg | maybe it's -1.0000000..0001 ? |
| 13:44.19 | d_rossberg | btw, i'll update may brlcad cmake branch for a short code review ... |
| 13:48.43 | dloman | wow, 35 mins to svn up. that's just painful :/ |
| 13:50.52 | CIA-77 | BRL-CAD: 03starseeker * r43681 10/brlcad/branches/cmake/misc/CMake/test_srcs/timedelta_end.c.in: check fscanf here too to make compiler happy |
| 13:53.07 | starseeker | ah, good - just needed a clean build - still avoids erroring out with debug and does with release |
| 13:56.24 | starseeker | this is as much as I know currently: http://pastebin.mozilla.org/1126326 |
| 14:02.26 | starseeker | why is acos(-1) not happy... |
| 14:03.57 | starseeker | d_rossberg: you may be right... let's see... |
| 14:11.21 | starseeker | yep |
| 14:11.27 | starseeker | d_rossberg: thanks :-) |
| 14:11.33 | starseeker | now, what to do... |
| 14:15.44 | CIA-77 | BRL-CAD: 03starseeker * r43682 10/brlcad/trunk/src/librt/primitives/pipe/pipe.c: |
| 14:15.44 | CIA-77 | BRL-CAD: acos isn't happy if we go outside the domain -1,1 and it looks like floating |
| 14:15.44 | CIA-77 | BRL-CAD: point fuzz is taking us inside in some cases and out in others - peg it to -1 or |
| 14:15.44 | CIA-77 | BRL-CAD: 1 if we're within VUNITIZE_TOL to avoid uncertainty principle effects in |
| 14:15.44 | CIA-77 | BRL-CAD: conversion behavior |
| 14:16.58 | starseeker | actually, that may not be enough... |
| 14:18.36 | d_rossberg | starseeker: how about "angle = bn_pi - acos(min(1., max(-1., VDOT(v1, v2))));"? |
| 14:20.49 | ``Erik | or vmath's CLAMP() |
| 14:22.20 | starseeker | it's tricky, because we DO want pipes to fail the check if they really do define a pipe that's not within floating point fuzz of sane limits |
| 14:22.46 | starseeker | I'm just worried that borderline cases will still crop up... |
| 14:24.24 | starseeker | if the value is less than -1.0 + fuzz it should fail... but whether a particular value hits that threshold will vary from system to system... |
| 14:24.36 | starseeker | -1.0 - fuzz rather |
| 14:25.53 | starseeker | it's almost like if it starts straying into bad (fuzzy) territory we need to clamp not the VDOT result but the input geometry values themselves to keep them out of the danger zone |
| 14:27.21 | starseeker | but how do we do that? |
| 14:28.19 | d_rossberg | first you have to put meaningful values to acos() and tan() |
| 14:29.10 | d_rossberg | only if this was the case you may evaluate new_bend_dist |
| 14:30.03 | d_rossberg | and in my opinion the VDOT() problem is a double precision problem |
| 14:30.19 | d_rossberg | there you have to "help" a little bit |
| 14:32.22 | starseeker | I'm betting what happened was a modeler in mged pushed the pipe right to its limits, which worked on that system but not on another. We need another category of return value from the check which says "valid but dangerous" to keep the modeler in MGED from setting to that value but to allow existing geometry that already has the borderline values to work |
| 14:34.29 | brlcad | starseeker: yeah, that's what I would have needed wrt extrude.c |
| 14:39.48 | starseeker | uh... has somebody been monkeying with MGED mouse bindings? |
| 14:40.30 | starseeker | both left and right mouse buttons zoom in, and perspective is on whether I ask for it or not... |
| 14:41.53 | starseeker | needs to head in here... |
| 14:43.49 | brlcad | starseeker: yeah, I messed with mouse bindings recently because of that problem, but maybe didn't get it right |
| 14:44.07 | brlcad | let me know when you're stable to test a change |
| 14:45.39 | CIA-77 | BRL-CAD: 03brlcad * r43683 10/brlcad/trunk/TODO: report that comb editor isn't working and jeep conversion failure |
| 14:46.33 | starseeker | brlcad: go ahead - I'm done monkeying for the moment |
| 14:49.07 | starseeker | uh, pipe not torus (or are you seeing torus failures?) |
| 14:49.19 | brlcad | ups, right |
| 14:49.31 | brlcad | "torus bend" failure |
| 14:49.45 | starseeker | that change I made to pipe.c does work, but I don't know if it's "right" |
| 14:52.43 | starseeker | we need an "editing" check I think that is tighter than the import check, but will allow movement of settings towards safer directions |
| 14:54.55 | starseeker | in the case of an import that has settings meeting import tolerance (i.e. "this was valid on some system but is fuzzy/dodgy here") but not editing tolerance "on this system we don't want this value, but since we already have it don't fail" |
| 14:56.41 | starseeker | hits the road |
| 14:56.53 | d_rossberg | starseeker: you may move the cmake logic to trunk, the brlcad.dll won't work but it looks like it can be fixed with reasonable effort |
| 14:57.40 | d_rossberg | and don't bother the user with your numerical problems ;) |
| 14:58.16 | d_rossberg | prefer to solve the numerics to writing a dialog |
| 14:58.33 | starseeker | one last note - I dunno how reproducible it is, but perspective was on with the jeep in release build and off in debug build |
| 14:59.23 | d_rossberg | on my system (MSVC) acos() accepts invalid values, the result is a nan |
| 15:00.28 | d_rossberg | anyway, this kind of problem may arise always |
| 15:03.30 | d_rossberg | if you can not be sure that the result of VDOT() is between -1 and 1 (as the theory would say) _and_ acos() has a problem with it you have to test it |
| 15:15.29 | d_rossberg | btw, your test isn't optimal: e.g. local_vdot = -1.5 would still crash |
| 15:18.09 | brlcad | oops, there he goes :) |
| 15:22.19 | CIA-77 | BRL-CAD: 03bob1961 * r43684 10/brlcad/trunk/src/libtclcad/ged_obj.c: Fixed a problem with rect_mode that was causing an offset rectangle to be drawn. |
| 15:26.35 | *** join/#brlcad poolio (~poolio@BZ.BZFLAG.BZ) |
| 15:26.36 | *** join/#brlcad starseek1r (~starseeke@BZ.BZFLAG.BZ) |
| 15:28.02 | *** join/#brlcad Ralith (~ralith@S010600221561996a.vc.shawcable.net) |
| 15:39.27 | CIA-77 | BRL-CAD: 03brlcad * r43685 10/brlcad/trunk/src/librt/primitives/pipe/pipe.c: |
| 15:39.27 | CIA-77 | BRL-CAD: why there are custom blocks of code to unitize the vector instead of calling |
| 15:39.27 | CIA-77 | BRL-CAD: VUNITIZE() is curious and potentially related to the fuzzy instability. |
| 15:39.27 | CIA-77 | BRL-CAD: regardless, tweak the dot product result if it just barely over/under-shoots due |
| 15:39.27 | CIA-77 | BRL-CAD: to precision problems. using NEAR_ZERO/NEAR_EQUAL here isn't optimal since |
| 15:39.28 | CIA-77 | BRL-CAD: it'll clamp values already within the valid [1.0,-1.0] range to the limit of |
| 15:39.29 | CIA-77 | BRL-CAD: that range. |
| 15:40.26 | brlcad | d_rossberg: good point about the range, but the dot should be between 1,-1 since they're both unit vectors .. code just wasn't obvious that they were being unitized |
| 15:45.01 | CIA-77 | BRL-CAD: 03brlcad * r43686 10/brlcad/trunk/src/librt/primitives/pipe/pipe.c: still need the lengths of v1/v2 for subsequent input validation |
| 15:55.43 | d_rossberg | brlcad: if vdot > 1.0 => vdot = 1.0 and if vdot < -1.0 => vdot = -1.0 otherwise acos() may crash the program! |
| 15:57.04 | brlcad | they're already unit vectors so vdot shouldn't be more than fuzz, or you saying check it anyways because it may crash (e.g., if there is REALLY bad fuzz) |
| 15:57.21 | brlcad | works for me |
| 15:57.46 | d_rossberg | check it the simple way, you do not know for sure what "small" is |
| 16:00.13 | d_rossberg | otherwhise the code is hard to understand (why he checks for 1.0+VUNITIZE_TOL? what happens if vdot is >= 1.0+VUNITIZE_TOL?) |
| 16:01.20 | CIA-77 | BRL-CAD: 03brlcad * r43687 10/brlcad/trunk/src/librt/primitives/pipe/pipe.c: daniel has a good point, they're already unit so no harm saying anything outside of range is clamped to the range limit |
| 16:06.37 | CIA-77 | BRL-CAD: 03brlcad * r43688 10/brlcad/trunk/src/librt/primitives/pipe/pipe.c: um, call CLAMP() dummy |
| 16:09.42 | *** join/#brlcad yukonbob_ (~bch@20-144.wireless.kamloops.net) |
| 16:18.35 | *** join/#brlcad indianla1ry (~indianlar@BZ.BZFLAG.BZ) |
| 16:18.35 | *** join/#brlcad ``Erik_ (Here@c-69-140-109-104.hsd1.md.comcast.net) |
| 16:18.35 | *** join/#brlcad Ralith (~ralith@S010600221561996a.vc.shawcable.net) |
| 16:18.35 | *** join/#brlcad starseeker (~starseeke@BZ.BZFLAG.BZ) |
| 16:18.36 | *** join/#brlcad poolio (~poolio@BZ.BZFLAG.BZ) |
| 16:18.36 | *** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ) |
| 16:18.36 | *** join/#brlcad epileg (~epileg@unaffiliated/epileg) |
| 16:18.36 | *** join/#brlcad louipc (~louipc@archlinux/trusteduser/louipc) |
| 16:18.36 | *** join/#brlcad vtts (~vytautas@diz.ktu.lt) |
| 16:18.36 | *** join/#brlcad PrezKennedy (MK@whitecalf.net) |
| 16:18.36 | *** join/#brlcad alex_joni (~alex_joni@emc/board-of-directors/alexjoni) |
| 16:18.36 | *** join/#brlcad brlcad (~sean@BZ.BZFLAG.BZ) |
| 16:18.36 | *** join/#brlcad kanzure_ (~kanzure@131.252.130.248) |
| 16:18.36 | *** join/#brlcad b0ef (~b0ef@157.26.202.84.customer.cdi.no) |
| 16:18.36 | *** join/#brlcad dtidrow_ (~dtidrow@c-68-60-96-218.hsd1.mi.comcast.net) |
| 16:18.36 | *** join/#brlcad cjdevlin (~devlin@d118-75-252-178.try.wideopenwest.com) |
| 16:18.36 | *** join/#brlcad willdye (~willdye@fern.dsndata.com) |
| 16:18.36 | *** join/#brlcad _psilva (~psilva@static-96-255-52-7.washdc.fios.verizon.net) |
| 16:18.36 | *** join/#brlcad dloman (~claymore@BZ.BZFLAG.BZ) |
| 16:18.36 | *** join/#brlcad kanzure__ (~kanzure@bioinformatics.org) |
| 16:18.36 | *** join/#brlcad ChanServ (ChanServ@services.) |
| 16:18.36 | *** mode/#brlcad [+o ChanServ] by verne.freenode.net |
| 16:19.59 | *** join/#brlcad WhiteCalf (MK@2607:f0d0:3001:68::2) |
| 16:20.13 | *** join/#brlcad CIA-14 (~CIA@208.69.182.149) |
| 16:22.13 | *** join/#brlcad Ralith_ (~ralith@S010600221561996a.vc.shawcable.net) |
| 16:22.39 | *** join/#brlcad kanzure (~kanzure@131.252.130.248) |
| 16:30.01 | *** join/#brlcad starseek1r (~starseeke@BZ.BZFLAG.BZ) |
| 16:30.01 | *** join/#brlcad kanzure (~kanzure@131.252.130.248) |
| 16:30.01 | *** join/#brlcad Ralith_ (~ralith@S010600221561996a.vc.shawcable.net) |
| 16:30.01 | *** join/#brlcad CIA-14 (~CIA@208.69.182.149) |
| 16:30.01 | *** join/#brlcad WhiteCalf (MK@2607:f0d0:3001:68::2) |
| 16:30.01 | *** join/#brlcad indianla1ry (~indianlar@BZ.BZFLAG.BZ) |
| 16:30.01 | *** join/#brlcad ``Erik_ (Here@c-69-140-109-104.hsd1.md.comcast.net) |
| 16:30.01 | *** join/#brlcad Ralith (~ralith@S010600221561996a.vc.shawcable.net) |
| 16:30.01 | *** join/#brlcad poolio (~poolio@BZ.BZFLAG.BZ) |
| 16:30.01 | *** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ) |
| 16:30.01 | *** join/#brlcad epileg (~epileg@unaffiliated/epileg) |
| 16:30.01 | *** join/#brlcad vtts (~vytautas@diz.ktu.lt) |
| 16:30.01 | *** join/#brlcad alex_joni (~alex_joni@emc/board-of-directors/alexjoni) |
| 16:30.01 | *** join/#brlcad brlcad (~sean@BZ.BZFLAG.BZ) |
| 16:30.01 | *** join/#brlcad b0ef (~b0ef@157.26.202.84.customer.cdi.no) |
| 16:30.01 | *** join/#brlcad dtidrow_ (~dtidrow@c-68-60-96-218.hsd1.mi.comcast.net) |
| 16:30.01 | *** join/#brlcad cjdevlin (~devlin@d118-75-252-178.try.wideopenwest.com) |
| 16:30.01 | *** join/#brlcad willdye (~willdye@fern.dsndata.com) |
| 16:30.02 | *** join/#brlcad _psilva (~psilva@static-96-255-52-7.washdc.fios.verizon.net) |
| 16:30.02 | *** join/#brlcad dloman (~claymore@BZ.BZFLAG.BZ) |
| 16:30.02 | *** join/#brlcad kanzure__ (~kanzure@bioinformatics.org) |
| 16:30.02 | *** join/#brlcad ChanServ (ChanServ@services.) |
| 16:30.02 | *** mode/#brlcad [+o ChanServ] by verne.freenode.net |
| 16:42.00 | *** join/#brlcad epileg (~epileg@unaffiliated/epileg) |
| 16:45.19 | *** join/#brlcad indianlarry (~indianlar@BZ.BZFLAG.BZ) |
| 16:55.14 | *** join/#brlcad tofu (~sean@BZ.BZFLAG.BZ) |
| 17:05.01 | CIA-14 | BRL-CAD: 03brlcad * r43689 10/brlcad/trunk/TODO: torus bend pipe failure should be working now, needs one final test on the platform that had the float fail. |
| 17:36.21 | dloman | question about the tclIndex file: is that generated by something or do we/can we manually edit that (to add tcl scripts) ? |
| 17:37.29 | tofu | it's autogenerated |
| 17:38.43 | *** join/#brlcad ezzieyguywuf (~wolfie@cpe-071-070-255-232.nc.res.rr.com) |
| 17:39.25 | ezzieyguywuf | how do I delete a shape after I have made it with in? I know I can remove it from the framebuffer thing with erase, but I want to get rid of it completely. |
| 17:39.50 | brlcad | dloman: if you delete the file, it'll get regenerated |
| 17:40.24 | brlcad | same for pkgIndex.tcl |
| 17:40.31 | dloman | kk, so how do i add a new tcl script then... just put the .tcl file into the src/tclscripts dir? |
| 17:40.52 | brlcad | depends on what the script is |
| 17:41.07 | brlcad | somewhere in the src/tclscripts hierarchy, but the routines are organized by purpose |
| 17:41.27 | dloman | i fixed the 'grouper' script (by request) so it now works with 7.18 |
| 17:41.52 | dloman | figured id finally put it in the repo |
| 17:42.13 | brlcad | that'd be the mged subdir then, or a subdir under there |
| 17:43.00 | dloman | kk. danke |
| 17:43.01 | brlcad | suggest reading a few of the other tcl files in here |
| 17:43.05 | brlcad | *there |
| 17:43.14 | brlcad | to make sure that it'll self-validate and load correctly |
| 17:45.05 | brlcad | src/tclscripts/mged/reid.tcl is a simple example of mged-command validation |
| 17:45.15 | ezzieyguywuf | waits |
| 17:45.34 | brlcad | solclick.tcl is another |
| 17:46.00 | brlcad | ezzieyguywuf: kill |
| 17:46.12 | ezzieyguywuf | brlcad: excellent thanks. |
| 17:46.16 | brlcad | the mged quick reference sheet lists all of the basic commands |
| 17:46.23 | brlcad | avail on the website under docs |
| 17:46.40 | ezzieyguywuf | bah, I should look at that. I was going through the docs in order, and I'm still on the tutorial thing. |
| 17:46.44 | ezzieyguywuf | Making a mug as we speak :-P |
| 17:47.00 | brlcad | excellent |
| 17:48.47 | ezzieyguywuf | incidentally, I have a sort of general question about brl-cad: is it a good replacement for, say, SolidWorks or Pro/E. i.e. will I be able to make solid model represenations of parts, put assemblies together, and generate drawings in a relatively quick manner (once I'm proficient of course)? |
| 17:50.10 | brlcad | ezzieyguywuf: you will be able to make solid model representations of parts, put assemblies together, and do so in a relatively quick manner once you ar proficient, but it does take some time and practice to become proficient |
| 17:50.25 | brlcad | wouldn't say any worse than sw or proe, but definitely different |
| 17:50.37 | brlcad | now drawing, though, are a different matter. |
| 17:50.58 | brlcad | you can generate drawings, but not with dimensioning information |
| 17:51.02 | brlcad | at least not yet |
| 17:51.08 | ezzieyguywuf | brlcad: is there perhaps a third-party program you would recommend for doing drawings? with dimensioning and tolerances etc. |
| 17:51.44 | brlcad | open source options are pretty limited, qcad comes to mind for 2D |
| 17:52.11 | ezzieyguywuf | hm, but in that case I'd have build the part from scratch anew? |
| 17:52.19 | brlcad | we're the next closest, but then annotations and dimensioning are still under development (my task for the upcoming month actually) |
| 17:52.58 | yukonbob_ | annotations ++ |
| 17:53.11 | ezzieyguywuf | interesting. Well, I plan on spending some time getting familiar and proficient with brl-cad (or whichever open source CAD package I settle on) before I try using it for any big projects. That will probably be a year + out. |
| 17:53.18 | brlcad | ezzieyguywuf: example of what you can get now: http://brlcad.org/gallery/s/renderings/havoc_rtedge.png.html |
| 17:53.32 | brlcad | run "rtedge" in mged (or outside of mged) and you'll get a hidden-line rendering |
| 17:54.23 | ezzieyguywuf | nice. But say I wanted to get that rapid-prototyped: could I export it into an appropriate file format for doing so? |
| 17:55.18 | ezzieyguywuf | obviously if it was a part I wanted to have machined, I would need a drawing. but if it was going to be machined on a C&C machine, I think those just take solid-model files as well. |
| 17:58.28 | brlcad | ezzieyguywuf: http://brlcad.org/tmp/converters_page23.jpg |
| 17:58.49 | brlcad | we've had things rapid-prototyped from our files before with relative ease |
| 17:58.58 | brlcad | it depends how well modeled the object is |
| 17:59.22 | brlcad | most of the rapid prototypers handle STL (or iges for some of the better ones) |
| 18:00.16 | starseek1r | ezzieyguywuf: if you can't run qcad (I don't think the free version ever got updated to Qt4) you might try the fork librecad |
| 18:00.24 | brlcad | facetizing a model is REALLY tricky business, only working without assistance about 85-95% of the time |
| 18:00.41 | brlcad | (most exporters require facetization) |
| 18:00.55 | ezzieyguywuf | hm, I see. |
| 18:01.17 | brlcad | note even packages like proe aren't 100%, they're around 90-95% |
| 18:01.23 | ezzieyguywuf | I use gnome as my graphical environment, and gentoo just pulls in w/e qt libs it needs when I install stuff, so I don't think qcad will be a problem. |
| 18:01.30 | ezzieyguywuf | are you familiar with free-cad? how does that stack up? |
| 18:02.32 | brlcad | decent project, leverages opencascade for nearly everything is actually useful .. but not something I'd consider useful for production work |
| 18:03.09 | ezzieyguywuf | hm I see. |
| 18:03.21 | brlcad | really depends on your specific use case and data, though |
| 18:03.30 | brlcad | they might have just enough to do what you need |
| 18:03.32 | ezzieyguywuf | well thank you for your time. I'll keep working through the tutorials, and see where that takes me as far as long-term brl-cad use. |
| 18:03.35 | brlcad | they're just really in their infanccy |
| 18:03.48 | brlcad | no problem |
| 18:04.01 | brlcad | feedback is definitely welcome as you work your way through |
| 18:04.05 | *** join/#brlcad ezzieyguywuf (~wolfie@unaffiliated/ezzieyguywuf) |
| 18:04.24 | brlcad | if you run into a problem, folks are usually here to help |
| 18:05.42 | ezzieyguywuf | yea, well first bit of feedback would be that I've found some very minor discrepencies between the tutorial and the prog, i.e. the first time it tells you to do 'Edit >> Set H' it says "Hit Accept when you're done" but doesn't tell you that Accept is in the Edit menu :-P |
| 18:06.25 | brlcad | good point |
| 18:06.36 | brlcad | the "accept" command will also work |
| 18:09.00 | ezzieyguywuf | ah, good to know. |
| 18:09.56 | ezzieyguywuf | I'm kinda beating myself up for not taking notes on these discrepencies. Also when it mentions colors in the Combination Editor, you have to first click on Show Shader to get that option. |
| 18:11.24 | CIA-14 | BRL-CAD: 03brlcad * r43690 10/brlcad/trunk/doc/docbook/lessons/en/ (mged06_creating_a_goblet.xml mged09_globe_in_display_box.xml): apply suggestion from ezzieyguywuf to make sure we refer to the Edit *Menu* when telling then to select Accept. |
| 18:12.16 | ezzieyguywuf | brlcad: the menu itself is actually mentioned, but on about the third accept, two lessons later (I think. just for clarity) |
| 18:14.32 | brlcad | nods |
| 18:14.42 | CIA-14 | BRL-CAD: 03brlcad * r43691 10/brlcad/trunk/doc/docbook/lessons/en/ (2 files): update other references to Accept on the edit menu, change click to select |
| 18:15.08 | ezzieyguywuf | :-D |
| 18:16.13 | ezzieyguywuf | so BRL-CAD was originally written and used by the 'ballistics research laborator' right? And one of the selling points (that I read on the site) is that its more than just 'skin deep'. What does all this mean though? I mean, does it mean I can design a mug and then drop a rock on it and see what happens? |
| 18:18.44 | brlcad | the "Ballistic Research Laboratory" (BRL), yes |
| 18:19.17 | brlcad | more than just skin deep is a reference to our solid modeling underpinnings |
| 18:19.37 | brlcad | as well as complete modeling of object interiors |
| 18:20.23 | brlcad | so if I'm modeling a vehicle, we're geared to represent every little bit of detail, do so with incredible efficiency, and still be able to analytically evaluate the model |
| 18:21.06 | brlcad | every nut, bolt, wire, interior and exterior, and have it actually be volumetrically accurate and mathematically well-defined |
| 18:23.40 | *** join/#brlcad ezzieyguywuf (~wolfie@unaffiliated/ezzieyguywuf) |
| 18:23.50 | ezzieyguywuf | wow, irssi just froze for the first time in...years |
| 18:23.57 | brlcad | welcome back ;) |
| 18:24.05 | ezzieyguywuf | thanks :-) |
| 18:27.18 | *** join/#brlcad roberthl (~robert@mediawiki/RobertL) |
| 18:27.25 | brlcad | so don't know when you got cut off there, but hopefully answered your question |
| 18:28.34 | starseeker | awesome - DOJ is starting an antitrust investigation of MPEG-LA |
| 18:38.24 | *** join/#brlcad roberthl (~robert@mediawiki/RobertL) |
| 18:38.24 | *** join/#brlcad brlcad (~sean@BZ.BZFLAG.BZ) |
| 18:38.24 | *** join/#brlcad indianlarry (~indianlar@BZ.BZFLAG.BZ) |
| 18:38.24 | *** join/#brlcad epileg (~epileg@unaffiliated/epileg) |
| 18:38.24 | *** join/#brlcad starseeker (~starseeke@BZ.BZFLAG.BZ) |
| 18:38.24 | *** join/#brlcad kanzure (~kanzure@131.252.130.248) |
| 18:38.24 | *** join/#brlcad Ralith_ (~ralith@S010600221561996a.vc.shawcable.net) |
| 18:38.24 | *** join/#brlcad CIA-14 (~CIA@208.69.182.149) |
| 18:38.24 | *** join/#brlcad WhiteCalf (MK@2607:f0d0:3001:68::2) |
| 18:38.24 | *** join/#brlcad ``Erik_ (Here@c-69-140-109-104.hsd1.md.comcast.net) |
| 18:38.24 | *** join/#brlcad poolio (~poolio@BZ.BZFLAG.BZ) |
| 18:38.24 | *** join/#brlcad vtts (~vytautas@diz.ktu.lt) |
| 18:38.24 | *** join/#brlcad alex_joni (~alex_joni@emc/board-of-directors/alexjoni) |
| 18:38.24 | *** join/#brlcad b0ef (~b0ef@157.26.202.84.customer.cdi.no) |
| 18:38.24 | *** join/#brlcad dtidrow_ (~dtidrow@c-68-60-96-218.hsd1.mi.comcast.net) |
| 18:38.24 | *** join/#brlcad cjdevlin (~devlin@d118-75-252-178.try.wideopenwest.com) |
| 18:38.24 | *** join/#brlcad willdye (~willdye@fern.dsndata.com) |
| 18:38.24 | *** join/#brlcad _psilva (~psilva@static-96-255-52-7.washdc.fios.verizon.net) |
| 18:38.24 | *** join/#brlcad dloman (~claymore@BZ.BZFLAG.BZ) |
| 18:38.24 | *** join/#brlcad kanzure__ (~kanzure@bioinformatics.org) |
| 18:38.24 | *** join/#brlcad ChanServ (ChanServ@services.) |
| 18:38.25 | *** mode/#brlcad [+o ChanServ] by verne.freenode.net |
| 18:40.25 | ezzieyguywuf | I don't know where we got cut off either, let me check my logs |
| 18:40.52 | ezzieyguywuf | <PROTECTED> |
| 18:44.32 | ezzieyguywuf | ah yea, another quirk of the tutorial (and this is the second case of this, lesson 11. can't recall the frist): tute says to run mater mug.r<ENTER> but the mater command expects Usage: mater region_name shader r g b inherit |
| 18:45.10 | brlcad | just two lines missed then |
| 18:45.15 | brlcad | 13:20 < brlcad> so if I'm modeling a vehicle, we're geared to represent every little bit of detail, do so with incredible efficiency, and still be able to analytically evaluate the model |
| 18:45.19 | brlcad | 13:21 < brlcad> every nut, bolt, wire, interior and exterior, and have it actually be volumetrically accurate and mathematically well-defined |
| 18:45.49 | ezzieyguywuf | brlcad: but the actual analytical evaluation is done outside of brl-cad? |
| 18:45.51 | brlcad | ezzieyguywuf: yeah, that's a relatively recent change to 'mater' that I'm not happy with -- it's not supposed to require all usage parameters |
| 18:45.54 | brlcad | basically a bug |
| 18:46.20 | ezzieyguywuf | brlcad: ah. I thought maybe I (read gentoo) compiled it wrong, and this it wasn't interactive as it should have been. |
| 18:46.37 | brlcad | brl-cad performs _geometric_ evaluation quite robustly, more complex analytic evaluation is performed outside |
| 18:46.39 | ezzieyguywuf | I agree: why take away the interactive option of the tool? leave it in. |
| 18:46.54 | brlcad | it wasn't intentional |
| 18:46.57 | ezzieyguywuf | ah ok. |
| 18:47.05 | brlcad | just an oversight during a code change a while back |
| 18:47.53 | ezzieyguywuf | these complex analytic evaluations that are performed outside, they'd have to be done reading the brl-cad database though, right? or does brl-cad provide an api to easily access the data that the external program would be? also, what are some examples of external programs for performing these analyses? ansys? |
| 18:48.17 | brlcad | API |
| 18:48.22 | CIA-14 | BRL-CAD: 03brlcad * r43694 10/brlcad/trunk/TODO: mater command lost interactive functionality, need to restore |
| 18:48.42 | brlcad | there are literally dozens |
| 18:49.08 | brlcad | we provide a ray query interface which allows you to sample geometry in any matter you need for an analysis |
| 18:49.27 | brlcad | so lots of codes use that interface for a whole range of advanced purposes |
| 18:49.48 | brlcad | medical dosage analysis, vulnerability/lethality analysis, signal analysis, heat studies, structural |
| 18:50.14 | ezzieyguywuf | hrm, interesting. very interesting. |
| 18:50.16 | brlcad | our closest link is V/L, the code's name is MUVES -- a closed code developed by the usgov |
| 18:51.14 | brlcad | the geometric analyses we directly perform are presented and exposed area calculations, volume, weight/mass, moments of inertia, centroids, and aforementioned shotline queries |
| 18:51.43 | brlcad | ah, also overlap/interference detection |
| 18:51.50 | brlcad | maybe a couple others, but those immediately come to mind |
| 18:53.10 | ezzieyguywuf | so I can do a lot with a solid-model mode in BRL-CAD. |
| 18:53.56 | brlcad | right |
| 18:54.19 | brlcad | our weakness is converting to a surface model (polygonal) and direct design |
| 18:54.49 | brlcad | http://brlcad.org/Industry_Diagram.png might give you an idea |
| 18:55.50 | brlcad | still mostly accurate though we have expanded to right a little bit with NURBS and STEP support |
| 18:56.17 | ezzieyguywuf | hrm, I can't make heads or tails of that diagram :-P |
| 18:56.30 | brlcad | lots of layers of information to digest |
| 18:56.47 | ezzieyguywuf | ah, I see tha BRL-CAD shaded region now. |
| 18:57.03 | ezzieyguywuf | so, I'm most familiar with SolidWorks: where would that fall on that diagram? |
| 18:57.33 | ezzieyguywuf | or, more importantly, I'm starting work as a Mechanical Engineer soon: which aspects of that diagram would you think would be most useful to me professionaly? |
| 18:57.36 | ezzieyguywuf | for design work. |
| 18:58.05 | brlcad | might help to read it this way: CADD is basically AutoCAD industry, MCAD is systems like GibbsCAM, the center 'CAD' domain is where you'd place Solidworks, ProE, NX, CATIA |
| 18:59.05 | brlcad | CAID is rather specialized systems, but that'd be systems like Rhino3D |
| 18:59.54 | ezzieyguywuf | ah hah. the diagram is now making more sense. |
| 18:59.58 | brlcad | the dotted domains are different purposes that those domains tend to cater to |
| 19:00.47 | ezzieyguywuf | what is NURBS and STEP? |
| 19:01.08 | ezzieyguywuf | and can BRL-CAD produce a mesh to use in, say, OpenFOAM? |
| 19:01.22 | brlcad | STEP is a file exchange format |
| 19:02.13 | brlcad | similar to IGES, successor |
| 19:02.16 | brlcad | NURBS is a boundary representation format -- what a lot of commercial CAD systems use to represent surfaces |
| 19:02.27 | starseeker | (Non-Uniform Rational BSplines) |
| 19:02.33 | ezzieyguywuf | ah, I see. |
| 19:02.41 | brlcad | ezzieyguywuf: http://brlcad.org/d/node/82 <-- talks about converters in a bit more depth |
| 19:03.55 | ezzieyguywuf | ok, question about the tutorial (sorry to keep shifting the convo back and forth): I'm still working on the mug, and when I do tree mug.r it shows that body.c is composed of u bodyout.s - bodyin.s, but a) the inner rcc is not dotted and b) when I raytrace the inner rcc is not cut out from the outer one. rather they seem to be merged into one. |
| 19:04.06 | ezzieyguywuf | is it maybe that I have more things drawn on the screen than I want? |
| 19:04.14 | ezzieyguywuf | is there a way to ls everything that is currently active? |
| 19:04.29 | ``Erik_ | heh, pixdiff of regular vs -c "set rt_bot_mintie=1" ... http://brlcad.org/~erik/bot20110304.png (vs a while back with http://brlcad.org/~erik/bot20101229.png) |
| 19:04.44 | brlcad | ezzieyguywuf: type "who" .. you might have multiple objects displayed |
| 19:05.35 | brlcad | ``Erik: not too shabby! |
| 19:05.42 | ezzieyguywuf | who lists bodyout.s, bodyin.s, handle.s |
| 19:05.45 | ``Erik | (only on 64b, crashes on 32b still) |
| 19:05.48 | brlcad | ``Erik: mirrors fail to convert? |
| 19:06.05 | ``Erik | same source model, not sure why they're off |
| 19:06.27 | brlcad | looks like you fixed all of the original failures |
| 19:06.52 | ``Erik | yeah, backing off a tiny bit did that... more concerned about the 32b issue, then I need to get back to geomcore |
| 19:06.56 | brlcad | ezzieyguywuf: so when you raytrace, you're raytracing those three primitives, not mug.r |
| 19:07.34 | ezzieyguywuf | ah |
| 19:07.41 | brlcad | B mug.r will erase those three you're viewing and draw mug.r, then it should go to dotted for the subtracted objects and raytrace as you're expecting |
| 19:07.48 | ezzieyguywuf | B mug.r...you beat me to it :-P |
| 19:08.09 | brlcad | :) |
| 19:08.28 | ezzieyguywuf | ok. mug looks proper, and yet the inner rcc is still not dotted. |
| 19:08.49 | ezzieyguywuf | I guess its a 'minor' thing but it bugs me because the dots would make things easier to visualize pre-raytrace |
| 19:09.05 | brlcad | can you post up your .g file somewhere? |
| 19:09.32 | vtts | howdy, r43679 gives http://pastebin.com/BmmDXE2u when selectin Edit->Combination Editor (and few others), does anybody know how to fix it? |
| 19:09.36 | brlcad | anon ftp to brlcad.org if you don't |
| 19:09.39 | ezzieyguywuf | yea, one sec. wait, I can't exactly pastebin it... |
| 19:09.53 | brlcad | vtts: saw your report last night, it's on our list to verify |
| 19:10.12 | vtts | ok, thanks |
| 19:10.24 | brlcad | thanks for reporting it |
| 19:10.37 | ezzieyguywuf | http://ompldr.org/vN25zOQ <--- mug.g |
| 19:10.56 | brlcad | vtts: is this your own compile? |
| 19:11.12 | brlcad | vtts: if it is, retry with an --enable-all build |
| 19:11.28 | vtts | brlcad, it is with --enable-all |
| 19:11.38 | brlcad | okay, good to know |
| 19:12.18 | vtts | to be precise: --enable-optimized --enable-threads --enable-all --with-agl |
| 19:13.50 | vtts | is there a way to define a custom phong based custom shader (like plastic but with custom defaults)? |
| 19:14.24 | ezzieyguywuf | does brl-cad have a facility by which I can say, for example, "insert an rcc with its center at the same location as rcc1, a diameter that is 0.2 less, and a height that is 2 more (than that rcc1)" or do I have to manually check the dims of the first in order to make the second? |
| 19:14.27 | ``Erik | 'define' like write your own C evaluator, or just set different defaults? |
| 19:15.02 | vtts | i'd just like to assign my_plastic to a region |
| 19:15.17 | vtts | multiple regions that is |
| 19:15.53 | vtts | or any other way to change properties for multiple objects |
| 19:16.22 | vtts | i'm thinking about custom shader and change'ing it's default settings, but not sure if it is possible |
| 19:16.50 | brlcad | vtts: yes there is, you can customize any of the phong parameters |
| 19:16.57 | CIA-14 | BRL-CAD: 03erikgreenwald * r43695 10/brlcad/trunk/src/librt/primitives/bot/bot.c: we actually trigger this correctly now, so remove the extra debugging info |
| 19:17.28 | brlcad | vtts: the combination editor has a shader button, select it, enter your object name, hit enter, and you should see all of the parameters available |
| 19:17.42 | vtts | yeah i'm using it now |
| 19:17.58 | brlcad | ezzieyguywuf: does your wireframe look like this: http://brlcad.org/tmp/mug.png |
| 19:18.39 | *** join/#brlcad roberthl (~robert@v001.rhl.me.uk) |
| 19:18.42 | brlcad | (besides the line thickness) the inner rcc looks dashed here |
| 19:18.50 | *** join/#brlcad roberthl (~robert@mediawiki/RobertL) |
| 19:18.54 | vtts | but have few objects and was thinking if it would be possible to define custom shader, assign it to regions, and modify its parameters (instead of settings for every object) |
| 19:19.37 | ezzieyguywuf | brlcad: it does not. let me take a screenshot. |
| 19:20.06 | brlcad | vtts: ah, that'd be "shader objects" which we don't yet implement but is on our wish list |
| 19:20.17 | vtts | ok then |
| 19:20.23 | brlcad | vtts: you can copy shaders from objects to objects without too much difficulty |
| 19:20.54 | ezzieyguywuf | brlcad: http://ompldr.org/vN25zYw |
| 19:20.54 | vtts | ok, i guess i'll catch up with that with tutorials |
| 19:21.19 | ezzieyguywuf | vtts: which tutorial are you on? I'm on the mug :-P |
| 19:21.27 | brlcad | ezzieyguywuf: huh, that is bizzare |
| 19:21.29 | vtts | ezzieyguywuf, i guess the same |
| 19:21.46 | ezzieyguywuf | brlcad: crazy huh? Maybe I have an odd version? how can I check my vers? |
| 19:21.47 | brlcad | ezzieyguywuf: try "Z" |
| 19:22.01 | brlcad | then redraw the mug |
| 19:23.00 | brlcad | your version is on the window titlebar, 7.16.8 -- wireframe code hasn't really changed |
| 19:23.16 | ezzieyguywuf | brlcad: http://ompldr.org/vN25zZg |
| 19:23.20 | brlcad | you can try opening one of the example geometry database files, havoc.g for example, |
| 19:23.32 | vtts | what could you recommend to generate something like first/third-angle projections (with measurements if possible)? |
| 19:24.32 | brlcad | ezzieyguywuf: yeah, at a glance I would say we didn't have the same .g so apparently a bug of some sort |
| 19:24.54 | brlcad | ezzieyguywuf: hate to say it, but try restarting mged, redraw |
| 19:25.18 | ezzieyguywuf | I'll try, though this has persisted across multiple sessions of mged with different databases |
| 19:25.20 | brlcad | note that the raytrace rendering not changing underneath is correct, not a bug |
| 19:25.54 | brlcad | vtts: first/third-angle projections? |
| 19:25.55 | ezzieyguywuf | brlcad: yea I know, I zoomed into the wireframe to make it easier to see, but left the raytrace so you could see it really was hollowed out. |
| 19:26.09 | brlcad | vtts, do you mean a perspective view? |
| 19:26.20 | brlcad | ezzieyguywuf: k, just making sure :) |
| 19:26.25 | brlcad | some are confused by that |
| 19:26.30 | brlcad | it's intentional |
| 19:26.33 | vtts | brlcad, yes, but for printing with measurements and so on. |
| 19:27.22 | brlcad | vtts: Misc -> Perspective will turn on perspective viewing |
| 19:27.32 | ezzieyguywuf | http://ompldr.org/vN25zZw brlcad: also, I sometimes get a garbled mged screen, as seen in this screenshot. if I shift-translate the object, though, it draws appropriately. |
| 19:27.58 | brlcad | you can set the exact angle on the command line with "set perspective [value]" or "set perspective" to see the current value |
| 19:27.59 | ezzieyguywuf | brlcad: yea, restarted, still not dashed. |
| 19:28.03 | ezzieyguywuf | I'm doing 'draw mug.r' |
| 19:28.49 | brlcad | ezzieyguywuf: that's probably with the framebuffer enabled and you resize the window, yes? |
| 19:28.50 | vtts | brlcad, view'ing is not the problem, multiplane is quite good |
| 19:29.05 | vtts | but i'd like to generate some specs. with measurements |
| 19:29.25 | brlcad | ezzieyguywuf: you're seeing uninitialized framebuffer memory -- can either turn the framebuffer off, or (as you found out) refresh |
| 19:29.42 | brlcad | not the best, but has been low priority to address since data isn't affected |
| 19:30.03 | ezzieyguywuf | brlcad: ah ok. is framebuffer something that is brl-cad specific, or is it the same framebuffer that is referred it in my linux kernel etc? |
| 19:31.09 | brlcad | ezzieyguywuf: it's the same concept as referred to in the kernel, but different construct |
| 19:31.10 | CIA-14 | BRL-CAD: 03brlcad * r43696 10/brlcad/trunk/TODO: resizing embedded framebuffer sucks, fix it |
| 19:31.11 | ezzieyguywuf | === load framebuffer; +++ refresh framebuffer; === <rest of code> :-P |
| 19:32.08 | brlcad | vtts: ezzieyguywuf just asked about that earlier today (as do many) .. annotations and dimensions are currently being worked on but not yet ready |
| 19:32.39 | brlcad | you can get the model rendered as a hidden line rendering but annotations would have to be added manually in another tool unfortunately until that support is complete |
| 19:33.08 | vtts | ok, thanks |
| 19:33.24 | ezzieyguywuf | what does 'mater' stand for? |
| 19:34.00 | vtts | physical substance :) |
| 19:34.19 | ezzieyguywuf | :-P and how are the mater and shade commands different? |
| 19:34.28 | brlcad | until then, this is about as close as you'll get http://brlcad.org/gallery/s/renderings/havoc_rtedge.png.html and http://brlcad.org/gallery/s/screenshots/extractor.png.html |
| 19:34.46 | brlcad | easily scripted for a series of views, but still no annotations |
| 19:35.02 | vtts | ok, np |
| 19:35.11 | CIA-14 | BRL-CAD: 03starseeker * r43697 10/brlcad/trunk/TODO: Got a report of nirt not working correctly on Windows - Bob has reproduced this and is working on it |
| 19:35.46 | brlcad | 'help mater' .. mater is short for material |
| 19:35.52 | ezzieyguywuf | ah ok. |
| 19:36.29 | brlcad | which is a bit of a misnomer in that context, because it's technically just the shader for visualization -- the actual material code is set/used elsewhere |
| 19:36.57 | ezzieyguywuf | yea, I was getting confused. "Where's the density? Material properties? Etc?" |
| 19:37.41 | starseeker | brlcad: should we add a rename of mater->shader to the deprecation.txt file? |
| 19:37.56 | brlcad | oof |
| 19:38.13 | brlcad | probably, but that's hard even for me to swallow .. because it's been 'mater' forever :) |
| 19:38.37 | ezzieyguywuf | lol. its cool, I'll just keep thinking of that character from the Cars (tm) movie :-P |
| 19:39.05 | brlcad | mater is still better way to set the other combination properties, object color and inheritance |
| 19:39.12 | brlcad | shader only sets the shader |
| 19:39.18 | brlcad | so would have to resolve the other two |
| 19:40.42 | brlcad | starseeker: probably best to just hit up the lower hanging fruit first, that one requires figuring out new command(s) and options to cover mater's existing commands |
| 19:40.50 | brlcad | s/commands/settings/ |
| 19:41.05 | starseeker | nods |
| 19:41.11 | starseeker | just a thought while it came up |
| 19:44.47 | brlcad | yeah, I think you're right |
| 19:44.51 | brlcad | just maybe "not now" |
| 19:46.20 | ezzieyguywuf | so is there a way to print out the geometry of a given object? i.e. if I create an rcc and later want to see what its vertex, height and radius are? |
| 19:48.07 | brlcad | 'l' |
| 19:48.11 | *** join/#brlcad indianla1ry (~indianlar@BZ.BZFLAG.BZ) |
| 19:48.12 | brlcad | for list |
| 19:49.16 | brlcad | ezzieyguywuf: oh, and to answer your question from earlier, there are a few custom commands for creating objects based on cylinder end points |
| 19:49.31 | brlcad | rcc[tab][tab] should show them, help should describe them |
| 19:50.18 | starseeker | brlcad: sweeeeet. The head of the old simplesat project sent me about 180 autocad dwg files detailing the simplesat |
| 19:50.30 | ezzieyguywuf | I was asking more for in general though. For example, in SolidWorks I usually create an object, draw some costruction lines, and then place things 'tangen' or in the 'middle' or 'coincident' etc. |
| 19:50.43 | ezzieyguywuf | s/tangen/tangent/ |
| 19:50.47 | brlcad | starseeker: AWESOME! |
| 19:50.55 | brlcad | are they solid or drawings only? |
| 19:51.01 | ezzieyguywuf | I wonder if I can build things relative to other things in brl-cad as well. |
| 19:51.12 | starseeker | drawings only, but he says it was all him so they should be public domain |
| 19:51.21 | starseeker | awesome material for a modeling project :-) |
| 19:51.22 | ezzieyguywuf | brlcad: well, I guess drawings. but then I can 'mate' solid things in an assembly using similar relations. |
| 19:51.36 | ezzieyguywuf | oh, nwm you were asking him. |
| 19:52.05 | starseeker | ezzieyguywuf: heh, sorry - irc conversations are often kinda jumbled |
| 19:52.06 | brlcad | ezzieyguywuf: there are ways, but they're fairly manual ways and they won't (yet) stay constrained |
| 19:52.22 | ezzieyguywuf | hrm I see. |
| 19:52.40 | ezzieyguywuf | I can see that being an issue if I make a part and end up wanting to scale it, for whatever reason. |
| 19:52.48 | ezzieyguywuf | how would you approach that in brl-cad? |
| 19:53.00 | ezzieyguywuf | edit the database directly? |
| 19:53.04 | brlcad | they'll scale up just fine |
| 19:53.35 | brlcad | because you'll have combined associated objects together into common regions or groups, and the scale would apply to all members |
| 19:53.44 | ezzieyguywuf | well, in the mug example: if I wanted a mug twice as big, I'd have to double the size of the inner rcc, the outer rcc, and resize the handle appropriately. |
| 19:53.55 | brlcad | ah, no you woudln't |
| 19:54.06 | brlcad | you'd just apply a matrix edit to the mug, and scale it |
| 19:54.32 | ezzieyguywuf | hrm i see. the subject of a later lesson in the tutorial maybe? |
| 19:55.08 | brlcad | if you select Edit -> Matrix Edit, then select mug.r, then select any one of your primitives in the next window, you'll be able to select Scale on the Edit menu among a whole other range of edit options |
| 19:55.12 | brlcad | yep |
| 19:55.31 | ezzieyguywuf | cool cool, I'll keep trudging along then. |
| 19:55.32 | brlcad | it starts out really basic just because there are so many foreign concepts |
| 19:55.40 | ezzieyguywuf | yea I gotcha. |
| 19:55.49 | brlcad | even for people with CAD experience, we deviate in some respects |
| 19:55.53 | brlcad | s/some/many/ :) |
| 19:55.55 | ezzieyguywuf | its like learning to walk again, except its learning te solid model again :-P |
| 19:56.09 | ezzieyguywuf | lol. |
| 19:56.42 | brlcad | nods, I hear ya |
| 19:57.12 | brlcad | working on improving our usability is a bigger-picture area we're working on, but that's major long-term complicated work :) |
| 19:57.50 | brlcad | developing a new easier-to-use gui while not alienating existing expert modelers is pretty tricky.. |
| 19:58.10 | ezzieyguywuf | meh, I'm not afraid to spend a week or two learning a new software. |
| 19:58.19 | ezzieyguywuf | kinda got used to it working with linux :-P |
| 19:58.51 | ezzieyguywuf | brlcad: I kind of like that I can do everything from a command-line if I want |
| 19:59.05 | brlcad | with the exception of two of them, all the models on http://brlcad.org/gallery/s/renderings/ were completely designed within BRL-CAD in anywhere from a couple days to a couple months for the more complex models (which some of the experts have down to just a couple weeks for even the most complex) |
| 19:59.11 | ezzieyguywuf | one of the reasons I stuck around: I was mucking about in SolidWorks last week and had to do some repetitive stuff and thought to myself, "hey, this would be so easy to script" |
| 19:59.39 | brlcad | now scripting is actually one of our strengths! :) |
| 19:59.50 | brlcad | we do that better, more flexibly, than most |
| 20:00.15 | brlcad | you just have to know the command layer basics first :) |
| 20:00.16 | ezzieyguywuf | yea! that's why I want to learn brl-cad. |
| 20:02.18 | brlcad | the goliath is a pretty good example of what's possible in a short amount of time -- that was modeled by a summer student from scratch (starting with a ruler and pad of paper, and the mged tutorials) in about 6 weeks |
| 20:02.33 | brlcad | http://brlcad.org/gallery/s/renderings/goliath/ |
| 20:04.08 | ezzieyguywuf | so theoretically, I could take that goliath model and run it through an FEA program do a heat-transfer analysis on it somehow? |
| 20:04.22 | ezzieyguywuf | i.e. the project is useful for than just pretty pictures? |
| 20:05.07 | CIA-14 | BRL-CAD: 03starseeker * r43698 10/brlcad/branches/cmake/ (20 files in 6 dirs): MFC r43697 |
| 20:05.31 | brlcad | the actual one they measured: http://armor.callihan.cc/gallery/goliath/06-Aberdeen_0165.JPG |
| 20:05.42 | brlcad | sure |
| 20:06.48 | brlcad | the bridge to FEA is a pain because most require conversion from solid model to polygonal, but we do have a stable export path through Sandia National Lab's Cubit tool, which is one of the best at finite element meshing |
| 20:06.49 | ezzieyguywuf | mulitpane mode = awesome. |
| 20:11.11 | vtts | it would be even better if there was a way to make secondary planes react to view changes of the primary one :) |
| 20:11.54 | ezzieyguywuf | vtts: ah hah, that would be sweet |
| 20:12.06 | ezzieyguywuf | I like how its un-coupled though, that comes in handy too. |
| 20:12.14 | ezzieyguywuf | but I see how coupling two or more views would be nice. |
| 20:12.37 | brlcad | vtts: how would they react? |
| 20:13.58 | vtts | well they all have a center point |
| 20:14.14 | vtts | it would be nice to see changes relative to it |
| 20:14.46 | vtts | e.g. moving view, or changing azimuth |
| 20:15.52 | vtts | I'm not used to it, so shortly after starting using it got confused about orientation of the object in secondary panes |
| 20:16.00 | vtts | but thats just me |
| 20:16.17 | ezzieyguywuf | if I am in edit mode, how do I shift the screet without resizing the object I'm editing? |
| 20:16.26 | *** join/#brlcad kanzure (~kanzure@131.252.130.248) |
| 20:16.26 | *** join/#brlcad dloman (~claymore@BZ.BZFLAG.BZ) |
| 20:16.28 | ezzieyguywuf | I can zoom it/out with left/right click, but I want to pan too |
| 20:16.48 | *** join/#brlcad kanzure (~kanzure@131.252.130.248) |
| 20:17.09 | vtts | ezzieyguywuf, try using "x", "y", "z" keys |
| 20:17.14 | vtts | ezzieyguywuf, or ae command |
| 20:17.36 | brlcad | ezzieyguywuf: there are a slew of bindings (including pan) |
| 20:17.51 | brlcad | shift grips document lists them |
| 20:18.34 | starseeker | thinks tonight would be a good time to see how the libredwg project is coming... I can convert these to something else on-by-one if I have to, but scripting it would be so much nicer/easier... |
| 20:18.42 | vtts | by the way, ctrl+alt+mouse-click doesn't work as it's supposed to on mac :( |
| 20:27.16 | CIA-14 | BRL-CAD: 03erikgreenwald * r43699 10/brlcad/trunk/ (5 files in 2 dirs): more tfloat->fastf_t/TIE_3->vect_t|point_t conversion |
| 20:27.46 | ezzieyguywuf | so the diff between combinations and regions is that a combination is a combination of primitave objects to make a particular, more complex geometry, whereas a region is a combination of combinations and/or primitative objects to create a complex object with material props right? |
| 20:28.36 | starseeker | ezzieyguywuf: a region is regarded as a solid object - if two regions overlap, it is a modeling error |
| 20:28.52 | starseeker | combinations under a region can overlap |
| 20:31.38 | ezzieyguywuf | but how come I go to the combination editor to edit shading etc, and not the 'region editor' |
| 20:32.03 | starseeker | because the same editor can edit both regions and combinations |
| 20:32.08 | starseeker | regions are just combinations with a flag set |
| 20:32.09 | ezzieyguywuf | hrm, I see. |
| 20:32.50 | starseeker | in hindsight it would probably have been better to make the user interface respect the whole "regions are special" mantra a bit more, but it currently reflects the implementation reality (regions are combs with a flag) |
| 20:33.24 | ezzieyguywuf | also: is sloppy focus hard coded into mged? I have my window-manager set up so that focus does NOT follow the mouse, only mouse clicks. but between my framebuffer and mged command-line I see sloppy focus. |
| 20:33.40 | ezzieyguywuf | starseeker: good to know. |
| 20:33.50 | starseeker | not sure about the focus |
| 20:35.22 | *** join/#brlcad brlcad (~sean@BZ.BZFLAG.BZ) |
| 20:36.17 | ezzieyguywuf | ok question: how come when I change the color via the combination editor, I have to blash the respective region/combination in order to see the new color? |
| 20:36.53 | starseeker | you mean why isn't the color update reflected in the wireframe? |
| 20:37.53 | CIA-14 | BRL-CAD: 03erikgreenwald * r43700 10/isst/trunk/configure.ac: libtie is no more, just librt |
| 20:37.57 | ezzieyguywuf | starseeker: yea. |
| 20:38.26 | starseeker | if we're drawing a model with a LOT of lines (BoT models can have huge numbers) a wireframe view update is non-trivial from a resource perspective |
| 20:38.35 | starseeker | that'd be my guess |
| 20:38.39 | ezzieyguywuf | hrm, I see. |
| 20:38.44 | ezzieyguywuf | what is BoT? |
| 20:38.50 | starseeker | bag of triangles |
| 20:38.50 | CIA-14 | BRL-CAD: 03erikgreenwald * r43701 10/isst/trunk/gtk/ (gui.c isst.h local_worker.c main.c net_worker.c): update to compile against latest BRL-CAD |
| 20:39.22 | brlcad | ezzieyguywuf: in brl-cad language groups are assemblies, regions are parts, and combinations are the mechanism for structuring regions and groups |
| 20:39.55 | vtts | starseeker, is there a command to check if regions overlap? |
| 20:39.55 | ezzieyguywuf | so combinations are like drawings. |
| 20:40.08 | ezzieyguywuf | in SolidWorks that is (I caught the assemblies and parts reference) |
| 20:40.14 | starseeker | vtts: rtcheck |
| 20:40.20 | vtts | superb |
| 20:40.45 | brlcad | man, lot of irc network issues today |
| 20:40.56 | ezzieyguywuf | silly irc. |
| 20:42.15 | brlcad | ezzieyguywuf: sort of like "drawings", but since we're strictly 3D-only, we refer to them more as "shapes" |
| 20:42.36 | ezzieyguywuf | gotcha gotcha. |
| 20:42.38 | brlcad | a shape becomes solid and occupies space when you put it in a region |
| 20:43.11 | ezzieyguywuf | so it makes sense to use a 'region editor' then, and not a 'combination editor' yea? |
| 20:43.31 | ezzieyguywuf | since strictly speaking combinations are just representations of what will eventually be a solid object. |
| 20:43.56 | brlcad | it really should just be an "object editor" and show you parameters accordingly based on the object you're editing |
| 20:44.22 | brlcad | the next generation interface eliminates that distinction |
| 20:44.32 | brlcad | just shows a panel of parameters |
| 20:44.37 | ezzieyguywuf | ah hah. b/c I can change the color of the wireframe which represents the combination. |
| 20:44.43 | ezzieyguywuf | cool. |
| 20:44.49 | CIA-14 | BRL-CAD: 03erikgreenwald * r43702 10/isst/trunk/sdl/ (Makefile.am event.c isst.h main.c myplugin.c): disable texture fonts, make compile with current BRL-CAD |
| 20:46.58 | brlcad | notes our release TODO is getting LONGER faster than it's getting shorter.. urg! |
| 20:47.31 | ezzieyguywuf | lol. |
| 20:54.39 | CIA-14 | BRL-CAD: 03starseeker * r43703 10/geomcore/trunk/tests/svntest/main.c: Got lists of assemblies and regions, but a deep keep of the region is not quite so simple. This seems like it might be another case where librt functionality is in order, but might already be there... need to check |
| 21:22.52 | brlcad | starseeker: sorry to say it but search is nfg |
| 21:23.44 | brlcad | actually seems royally busted, all three tests failed on a simple model |
| 21:24.58 | starseeker | you're kidding |
| 21:25.08 | starseeker | what tests? |
| 21:26.40 | brlcad | tried: search . -name mug.g (returned error about failing to make a plan) search / -name mug.g (returned nothing) search . (crashed mged) |
| 21:26.41 | starseeker | debates between screaming and crying... |
| 21:28.20 | brlcad | probably best to just revert trunk to prior state for release, get it into the next release .. assuming tie bot raytracing works; if it doesn't then we have more time still |
| 21:28.48 | brlcad | s/mug.g/mug.r/ .. was using the .g ezzie posted earlier |
| 21:29.00 | brlcad | http://ompldr.org/vN25zOQ |
| 21:30.48 | brlcad | looks like "search /" has plan problems, returns unknown option passed to find_create() |
| 21:31.05 | brlcad | then Error: Failed to build find plan. |
| 21:31.22 | starseeker | I don't believe it |
| 21:31.30 | starseeker | how did it go south so fast? |
| 21:31.38 | starseeker | or maybe I was dreaming... |
| 21:31.41 | starseeker | will revert |
| 21:32.25 | brlcad | the librt code can probably stay, doesn't have to be full revert |
| 21:33.03 | starseeker | will need to revert raytrace.h |
| 21:33.14 | starseeker | grinds teeth... |
| 21:34.09 | CIA-14 | BRL-CAD: 03starseeker * r43704 10/geomcore/trunk/tests/svntest/main.c: something not right here... keep isn't creating much of anything in the way of geometry... |
| 21:34.28 | starseeker | not good... can't afford this right now |
| 21:35.07 | brlcad | you're in good company, lots of hard show-stoppers |
| 21:35.23 | brlcad | see if bob can fix the combination editor while's he's in there working on nirt :) |
| 21:36.57 | starseeker | brlcad: real quick - does search in its current form work on the command line? |
| 21:37.07 | CIA-14 | BRL-CAD: 03erikgreenwald * r43705 10/brlcad/trunk/src/librt/primitives/bot/tie_kdtree.c: clean up #if 0 stuff |
| 21:37.10 | starseeker | e.g. mged mug.g search . -name mug.r |
| 21:38.18 | brlcad | . works, / doesn't |
| 21:38.25 | brlcad | interesting |
| 21:38.45 | brlcad | search . also still crashes |
| 21:40.41 | starseeker | sees one error right off |
| 22:02.57 | starseeker | brlcad: before I revert, can you give r43706 a go? |
| 22:03.09 | CIA-14 | BRL-CAD: 03starseeker * r43706 10/brlcad/trunk/src/ (libged/search.c librt/search.c): Variety of fixes to both libged and librt search logic. |
| 22:04.59 | brlcad | sure |
| 22:07.57 | CIA-14 | BRL-CAD: 03erikgreenwald * r43707 10/brlcad/trunk/ (5 files in 2 dirs): revert to 43698, caused weird errors in output |
| 22:09.03 | CIA-14 | BRL-CAD: 03starseeker * r43708 10/brlcad/trunk/src/libged/search.c: Catch another odd input case |
| 22:09.18 | brlcad | wow, isn't that like all of your changes ``Erik |
| 22:10.55 | ``Erik | heh, this was a really weird one, bunches of misses showing up even on cubes |
| 22:11.02 | ``Erik | bastage O.o |
| 22:16.51 | starseeker | waits in suspense... |
| 22:19.24 | ezzieyguywuf | how can I do a primitive selection from the command-line? |
| 22:21.26 | brlcad | starseeker: rebuilding now, testing in a few |
| 22:21.35 | brlcad | ezzieyguywuf: sed |
| 22:21.35 | CIA-14 | BRL-CAD: 03brlcad * r43709 10/brlcad/trunk/TODO: combination editor bug confirmed, mged init on mac DISPLAY issue wasn't specific to mged so not a show-stopper (mged stall if started from Terminal, restarting X11 fixed it) |
| 22:21.57 | brlcad | sed and oed are the two ways to go into an edit mode from the command line |
| 22:22.17 | brlcad | the latter being pretty powerful, but a bit obtuse to use -- there is a tutorial dedicated to it on the website |
| 22:22.40 | brlcad | it's how you'd scale up, translate, rotate groups of geometry |
| 22:24.00 | ezzieyguywuf | brlcad: ah, thanks. |
| 22:24.20 | ezzieyguywuf | heh, funny how so many of mged commands are the same as unix commands. |
| 22:24.21 | CIA-14 | BRL-CAD: 03erikgreenwald * r43710 10/brlcad/trunk/ (4 files in 2 dirs): shift tie min/max to point_t |
| 22:39.28 | brlcad | starseeker: that's looking MUCH better already |
| 22:39.56 | brlcad | 'search .' and 'search /' don't do the right thing, but quick test with -name and -type seem to work as expected |
| 22:41.16 | brlcad | globbing doesn't seem to be working right |
| 22:41.38 | brlcad | e.g.: search . -name * |
| 22:42.31 | starseeker | try search . -name \* maybe? |
| 22:42.36 | brlcad | hm. same test that worked on the simple model is returning nothing for havoc for both "search . -type c" and "search / -type c" .. |
| 22:42.39 | starseeker | or from the command line search . -name \\* |
| 22:42.40 | brlcad | tried that, nothing |
| 22:43.02 | brlcad | yeah, variety of regression failures even for / |
| 22:43.06 | starseeker | odd, works here... |
| 22:43.22 | starseeker | oh wait, type... |
| 22:43.37 | starseeker | no, that works too... |
| 22:43.54 | brlcad | worked on the mug model, but not havoc |
| 22:44.35 | starseeker | tries havoc |
| 22:45.10 | starseeker | seems to work... |
| 22:45.32 | starseeker | uh... |
| 22:45.36 | starseeker | what platform? |
| 22:46.03 | brlcad | 10.6 |
| 22:46.39 | CIA-14 | BRL-CAD: 03starseeker * r43711 10/geomcore/trunk/tests/svntest/main.c: Woot - that was it, ignore nref in node write and we get content |
| 22:46.56 | brlcad | hm, worked if I restarted mged |
| 22:47.10 | brlcad | hope you're not using static variables somewhere... |
| 22:47.42 | starseeker | not intentionally... |
| 22:51.59 | brlcad | there we go, got it to repeat |
| 22:51.59 | brlcad | not sure how it's caused, but eventually, I can get it into a state where it stops working |
| 22:52.04 | starseeker | great |
| 22:52.11 | starseeker | starts reverting... |
| 22:52.32 | brlcad | sounds like it's really close, but just not very stable |
| 22:52.55 | starseeker | it just returns nothing? |
| 22:53.01 | brlcad | yea |
| 22:53.11 | brlcad | opened havoc, everything I tried worked |
| 22:53.13 | starseeker | and you just did searches for a while? |
| 22:53.14 | brlcad | including globbing |
| 22:53.40 | brlcad | then swapped to mug.r, repeated random -type -name searches |
| 22:54.07 | brlcad | some intentionally working but some not working (that should, like "search ." and "search /") |
| 22:54.22 | brlcad | then switched back to havoc (via opendb), and it was dead |
| 22:54.43 | starseeker | uh... what do you expect for search . and search / - there's no plan there |
| 22:54.54 | brlcad | plan is optional |
| 22:55.17 | brlcad | according to usage at least, which is how 'find' is too -- should return everything |
| 22:55.24 | brlcad | no plan |
| 22:57.15 | starseeker | I doubt that has ever been true - if it was, it was accidental |
| 22:57.15 | brlcad | search . becomes very similar to "ls *", search / becomes like "tree [tops]" |
| 22:57.15 | brlcad | I remember trying it earlier at one point and you had it working :) |
| 22:57.19 | starseeker | not intentionally |
| 22:57.24 | brlcad | subpath searching seemed to have issues too, search /havoc -type c |
| 22:57.36 | brlcad | search /havoc/. -type c was fun |
| 22:57.51 | brlcad | fun as in didn't do anything :) |
| 22:58.30 | starseeker | it's a pretty good bet the option parsing for the strings isn't up to all those options |
| 22:59.22 | brlcad | nods |
| 22:59.57 | starseeker | I had to be getting lucky on how things fell through earlier, 'cause I sure didn't have anything sophisticated in place |
| 23:00.08 | brlcad | that last one would have been fine, heck could even limit usage to just "search [.|] [plan]" but having it stop outright after a bit is disconcerting :) |
| 23:00.09 | starseeker | the "do nothing" thing worries me more |
| 23:00.24 | brlcad | yep |
| 23:00.35 | starseeker | you can't hook a debugger up and track it somehow? |
| 23:00.45 | starseeker | will try to reproduce... |
| 23:01.04 | brlcad | not at the moment, have build working on the other issue, but can poke on it some more in a bit |
| 23:01.34 | starseeker | cool - I'll lay off reverting for now then. From what ``Erik was saying, it sounds like he's got a bit more to go there |
| 23:02.05 | brlcad | ``Erik: think it'll be this weekend or you'll need more time? |
| 23:03.01 | starseeker | think he's on his way home |
| 23:10.23 | brlcad | k, sending an update to the list then |
| 23:18.35 | *** join/#brlcad indianlarry (~indianlar@BZ.BZFLAG.BZ) |
| 23:20.19 | ezzieyguywuf | you know, I start mged from a terminal. unless I explicitly type exit into mged, though, the process stays alive. i.e. I can X out the framebuffer window (which destroys the mged prompt window as well) and kill the term that I launched mged from and the process persists. I feel like this is a serious issue. |
| 23:20.38 | starseeker | brlcad: the iteration over dbip->dbi_Head is failing - all the directory pointers are coming back null |
| 23:20.49 | starseeker | how could that happen? |
| 23:33.20 | brlcad | starseeker: maybe something is freeing memory |
| 23:34.10 | starseeker | it's not that... I checked ls, it's working |
| 23:34.19 | starseeker | most are null, but clearly not all |
| 23:34.22 | ``Erik | it works for 64b, 32 gets off... I think there may be a rogue ptr += sizeof(bah*) that's not quite right or something... feel free to take a look if ya want, there's not that much code... the optimized split routine is a major portion, and it's not used with the default path |
| 23:34.26 | starseeker | forgot it's a hash table |
| 23:34.41 | ``Erik | (mebbe I'm too deep in it, fresh eyes might spot something obvious) |
| 23:35.43 | ``Erik | (my only 32b box is fbsd, which might align things different than other platforms, too...) |
| 23:36.34 | starseeker | is down in the pattern matching in the back trace now, which is scary scary turf... |
| 23:36.49 | brlcad | ezzieyguywuf: if you can characterize exact steps to reproduce the problem and what you're expecting it to do (even if it's exactly the steps you just mentioned), please report it as a bug to the bug tracker: https://sourceforge.net/tracker/?func=add&group_id=105292&atid=640802 |
| 23:37.09 | ezzieyguywuf | brlcad: sure. |
| 23:37.12 | brlcad | closing the graphics window is supposed to shut down mged (whereas closing the command window is not) |
| 23:37.30 | brlcad | I known issue on Mac OS X makes it not close there, but should work for linux |
| 23:37.47 | brlcad | and windows, don't know that it's been tested there in a while |
| 23:37.50 | ezzieyguywuf | maybe its cuz I'm running it in gnome and not a qt-based DE |
| 23:38.07 | brlcad | shouldn't matter, but can describe your setup in the report |
| 23:38.37 | ezzieyguywuf | you sure that link you gave me is right? |
| 23:44.11 | CIA-14 | BRL-CAD: 03brlcad * r43712 10/brlcad/trunk/TODO: yet another, gqa gets in line |
| 23:46.53 | brlcad | iirc, it's actually the job of the terminal program to decide whether to kill or detact processes that are still running if a terminal session is closed |
| 23:46.54 | brlcad | so that might be a gnome-terminal issue |
| 23:46.54 | brlcad | but closing the graphics window should have exited mged |
| 23:46.54 | brlcad | it's right if you already have an sf account, otherwise, can go here: https://sourceforge.net/tracker/?group_id=105292&atid=640802 |
| 23:46.54 | brlcad | bug reports require an sf account so we can interact with the submitter |
| 23:53.39 | starseeker | aaand I wiped out the process that reproduced it |
| 23:53.40 | starseeker | lovely |
| 23:55.31 | starseeker | ah ha |
| 23:55.58 | brlcad | needs a good shader example |
| 23:59.30 | CIA-14 | BRL-CAD: 03starseeker * r43713 10/brlcad/trunk/src/librt/search.c: |
| 23:59.31 | CIA-14 | BRL-CAD: Looks like that doggone global was stuck in 'on', and because it started that |
| 23:59.31 | CIA-14 | BRL-CAD: way the plans never formed properly - they assumed no output command was needed |
| 23:59.31 | CIA-14 | BRL-CAD: when it was. The global was inherited from the design of find, and I never |
| 23:59.31 | CIA-14 | BRL-CAD: cared for it, but it'll be a bit of work to do it any other way so for now just |
| 23:59.31 | CIA-14 | BRL-CAD: make sure it's zero before we start forming plans. |
){kind=link}
