| 00:13.55 | yukonbob | brlcad vs. The Bug |
| 00:13.57 | yukonbob | ttp://coolkits.net/G%20vs%20Mothra.jpg |
| 00:14.02 | yukonbob | *http |
| 00:44.24 | CIA-27 | BRL-CAD: 03brlcad * 10brlcad/src/librt/ (dg_obj.c wdb_obj.c): remove dead code. there's closedb instead of overriding default close command, tol is a wdb_obj command. |
| 03:36.58 | *** join/#brlcad IriX64 (n=mariodot@bas2-sudbury98-1177726729.dsl.bell.ca) | |
| 04:01.44 | *** join/#brlcad IriX64 (n=mariodot@bas2-sudbury98-1177726729.dsl.bell.ca) | |
| 06:12.13 | *** join/#brlcad louipc (n=louipc@bas8-toronto63-1096734938.dsl.bell.ca) | |
| 06:53.42 | *** join/#brlcad CIA-MIA (n=relay@bz.bzflag.bz) | |
| 07:05.27 | *** join/#brlcad CIA-28 (n=CIA@208.69.182.149) | |
| 07:11.15 | *** join/#brlcad elite01 (n=elite01@195.37.106.60) | |
| 07:31.11 | CIA-28 | BRL-CAD: 03brlcad * 10brlcad/src/librt/nmg_rt_isect.c: yet another place to report an unknown class instead of bombing out. |
| 07:32.16 | CIA-28 | BRL-CAD: 03brlcad * 10brlcad/src/librt/nmg_class.c: if we exhaust the retry count, just give up instead of bombing out. otherwise this can cause havoc for even simple optional operations like trying to fix normals. |
| 07:37.40 | CIA-28 | BRL-CAD: 03brlcad * 10brlcad/src/librt/nmg_misc.c: |
| 07:37.40 | CIA-28 | BRL-CAD: if we encounter an invalid shell with bad results, stop processing entirely. |
| 07:37.40 | CIA-28 | BRL-CAD: this avoids an avalanche of cascaded failures and potential bomb situations |
| 07:37.40 | CIA-28 | BRL-CAD: where we can usually proceed. this particular problem was encountered during |
| 07:37.40 | CIA-28 | BRL-CAD: g-iges that had a shell that could not be classified (resulted in infinite loop |
| 07:37.43 | CIA-28 | BRL-CAD: and array indices that went out of bounds, eventually crashing). |
| 07:50.33 | *** join/#brlcad Defcon (n=def@74.17-246-81.adsl-static.isp.belgacom.be) | |
| 07:53.01 | CIA-28 | BRL-CAD: 03brlcad * 10brlcad/NEWS: (log message trimmed) |
| 07:53.01 | CIA-28 | BRL-CAD: fixed variety of g-iges and other exporter crashes and graceful handling of mesh |
| 07:53.01 | CIA-28 | BRL-CAD: normal failures. started with a particular model that was failing in the bot's |
| 07:53.01 | CIA-28 | BRL-CAD: tess() routine during the expensive nmg_fix_normals() processing. turned out |
| 07:53.01 | CIA-28 | BRL-CAD: that the model was going amuck while trying to determine shell orientation |
| 07:53.04 | CIA-28 | BRL-CAD: eventually overflowing a char in an inf loop until it crashed. the specific |
| 07:53.06 | CIA-28 | BRL-CAD: cause of the inf loop wasn't determined, but it does now detect the shell |
| 08:22.53 | *** join/#brlcad Z80-Boy (n=clock@zux221-122-143.adsl.green.ch) | |
| 08:51.29 | *** join/#brlcad elite01 (n=elite01@195.37.106.60) | |
| 09:12.01 | *** join/#brlcad elite01 (n=elite01@195.37.106.60) | |
| 09:45.22 | *** join/#brlcad lachyg (n=lachlan@ppp121-45-2-37.lns10.adl2.internode.on.net) | |
| 09:46.04 | lachyg | Hi. Is there a way in which I can rotate a combination? Or am I going about things in the wrong way? |
| 09:46.43 | lachyg | I've created a combination led.c = u led.plastic.r u led.metal.r, and want to rotate it around. Is there a way to do this? |
| 09:47.13 | Z80-Boy | lachyg: I do it by putting the combination into another combination, then opening the another combination in vi using red, loading a unit matrix from /home/clock/m and then editing the matrix to get the desired rotation. I need only rotation in multiples of 90 degrees. |
| 09:47.39 | Z80-Boy | the unit matrix is 1 0 0 0 0 1 0 0 0 0 1 0 0 0 0 1 |
| 09:47.55 | lachyg | So there's nothing simple like rot led.c 0 0 90? |
| 09:48.42 | Z80-Boy | maybe is but for me figuring out which command it is what parameters it has and what meaning these parameters have and what exactly it does is about 2 days, whereas the aforementioned sequence is about 1 minute. |
| 09:49.18 | Z80-Boy | Cause the documentation is missing a lot of important information and I always forget it when I figure it out, because I use BRL-CAD not continuously, but intermittently. |
| 09:49.33 | lachyg | Ok. I'll probably have to write a script for it then, as I have not the patience to do it 12 times ;) |
| 09:49.38 | lachyg | Ah, I see. |
| 09:49.42 | lachyg | Thanks for your help. |
| 09:49.51 | Z80-Boy | you might benefit in finding out the command |
| 09:50.07 | Z80-Boy | Don't worry, you don't find it in the official doc. You either have to ask brlcad or reverse engineer the huge codebase. |
| 09:50.12 | Z80-Boy | Or maybe experiment out |
| 09:50.25 | lachyg | heh |
| 09:50.43 | Z80-Boy | Like I never know if the angles are counter or clockwise, which axis is the first rotation around, if it rotates in the source or destination space etc. |
| 09:50.51 | Z80-Boy | With the matrix it's simple |
| 09:51.28 | Z80-Boy | You start with your sub-model then apply the matrix and then you get what's one level higher in the hierarchy. |
| 09:51.44 | Z80-Boy | The first 4 numbers are what goes into X upper in the hieararchy |
| 09:52.18 | Z80-Boy | the first, fifth, ninth numbers are concerning X in the original submodel. |
| 09:52.34 | Z80-Boy | Was also hell figuring if it's like this or lower/upper is swapped |
| 09:53.31 | lachyg | Hmm, I probably should read my linear algebra book again. |
| 09:53.32 | Z80-Boy | and in the cross, where is the letter X that's pointing into the positive direction |
| 09:53.40 | Z80-Boy | no you don't need linear algebra |
| 09:53.46 | Z80-Boy | It's just like drink mixing |
| 09:54.09 | Z80-Boy | you have 3 bottles x y z and 3 glasses X Y Z |
| 09:54.20 | Z80-Boy | the matrix tells you how much x, y, z should go into X |
| 09:54.25 | Z80-Boy | how much x, y, z should go into Y |
| 09:54.32 | Z80-Boy | how much x, y, z should go into Z |
| 09:54.49 | *** join/#brlcad elite01 (n=elite01@195.37.106.60) | |
| 09:55.34 | lachyg | Yeah---I just need to figure out the theory behind it again. Thanks for your help. |
| 09:55.45 | lachyg | Ah, looks like matrices are the only way to go. |
| 09:56.50 | Z80-Boy | lachyg: no it was actually assumed that people will use those commands to make it simpler so they don't have to crunch matrices in their heads |
| 09:56.59 | Z80-Boy | But because of bad documentation, crunching matrices is easier for me ;-) |
| 09:57.24 | lachyg | http://www.nabble.com/20-questions-t3863486.html |
| 09:57.26 | lachyg | #2 there |
| 09:59.28 | Z80-Boy | Oh lol this should be in the official doc and not on google resul page number 1137 |
| 10:01.14 | lachyg | I suspect so. |
| 10:01.41 | Z80-Boy | Also if you create a complicated model like I do then redrawing the display takes a minute |
| 10:01.53 | Z80-Boy | so one minute to shift, one minute to zoom, one minute to change view etc... |
| 10:02.01 | Z80-Boy | really blazing workflow speed ;-) |
| 10:02.27 | Z80-Boy | ANd I have 1500 MHz Pentium III! |
| 10:02.57 | lachyg | heh |
| 10:03.09 | lachyg | Could be worse. |
| 10:03.12 | lachyg | Could be paper. |
| 10:03.12 | Z80-Boy | I suspect because someone got an idea to wedging a blotware called X Windows system between the CPU and the AGP bus |
| 10:03.21 | Z80-Boy | X Window is fast in theory but slow in practice ;-) |
| 10:03.39 | Z80-Boy | Moving a piece of paper 20cm right doesn't take a minute, but a second. |
| 10:04.30 | Z80-Boy | You can draw a line in a microsecond, but if you first have to email the coordinates to the X Window System through a socket it gets horrible |
| 10:06.04 | Z80-Boy | I think I should report a bug |
| 10:06.08 | Z80-Boy | "mged dead slow" ;-) |
| 10:06.43 | Z80-Boy | and that's wireframe! |
| 10:07.56 | Z80-Boy | Cause it took me a whole bus trip to put model piece A to model piece B so that they touch each other |
| 10:12.08 | lachyg | Ah, think I've figured it out. |
| 10:12.20 | lachyg | Made a new combination like you said, then used arced |
| 10:15.59 | Z80-Boy | oh what does it do? |
| 10:16.34 | lachyg | Applies a matrix transformation to an element of a combination. |
| 10:17.00 | lachyg | arced led.1.t/led.c matrix rmul rot 0 0 90 |
| 10:17.02 | Z80-Boy | omg why is it called arced? With such a name I would expect to do something with arcs |
| 10:17.33 | Z80-Boy | lachyg: where did you find out you should type "arced led.1.t/led.c matrix rmul rot 0 0 90"? |
| 10:18.07 | lachyg | In the documentation (Volume 2), appendix A, page 158 |
| 10:19.48 | Z80-Boy | Interesting I'll look there. |
| 10:26.35 | *** join/#brlcad Blue_D (n=bluedolf@192.57-67-87.adsl-dyn.isp.belgacom.be) | |
| 10:41.35 | lachyg | Ah, now I've got it. You have to remember that your transformations are in the element's co-ordinate space. |
| 11:43.17 | *** join/#brlcad alex_jon1 (n=juve@81.196.65.201) | |
| 12:10.52 | *** join/#brlcad docelic (n=docelic@77.237.110.248) | |
| 12:26.53 | *** join/#brlcad elite01 (n=elite01@dslb-088-070-014-132.pools.arcor-ip.net) | |
| 12:33.13 | *** join/#brlcad tarzeau (i=gurkan@bee.ethz.ch) [NETSPLIT VICTIM] | |
| 12:38.11 | *** join/#brlcad brlcad (n=sean@pdpc/supporter/silver/brlcad) [NETSPLIT VICTIM] | |
| 12:38.11 | *** join/#brlcad Defcon (n=def@74.17-246-81.adsl-static.isp.belgacom.be) [NETSPLIT VICTIM] | |
| 12:38.11 | *** join/#brlcad PrezKennedy (i=Matt@74.86.45.130) [NETSPLIT VICTIM] | |
| 12:38.11 | *** join/#brlcad ``Erik (i=erik@c-68-54-174-162.hsd1.md.comcast.net) [NETSPLIT VICTIM] | |
| 12:38.11 | *** mode/#brlcad [+o brlcad] by irc.freenode.net | |
| 12:41.42 | *** join/#brlcad elite01 (n=elite01@dslb-088-070-014-132.pools.arcor-ip.net) [NETSPLIT VICTIM] | |
| 12:41.42 | *** join/#brlcad Maloeran (n=maloeran@glvortex.net) [NETSPLIT VICTIM] | |
| 12:41.47 | *** join/#brlcad lachyg (n=lachlan@ppp121-45-2-37.lns10.adl2.internode.on.net) [NETSPLIT VICTIM] | |
| 12:41.47 | *** join/#brlcad louipc (n=louipc@bas8-toronto63-1096734938.dsl.bell.ca) [NETSPLIT VICTIM] | |
| 12:41.47 | Defcon | wb all :) |
| 12:42.29 | Defcon | [13:31:07] <@brlcad> lachyg: oed / led.c/led.plastic.r/path/to/some/prim |
| 13:27.07 | *** join/#brlcad Blue_D (n=bluedolf@192.57-67-87.adsl-dyn.isp.belgacom.be) | |
| 13:50.08 | Defcon | <Z80-Boy> It's just like drink mixing |
| 13:50.15 | Defcon | .. |
| 13:50.18 | Defcon | how... :) |
| 14:06.48 | Z80-Boy | Defcon: how what? |
| 14:08.12 | Defcon | i didn't get your logic |
| 14:08.18 | Defcon | but i guess i do now |
| 14:11.50 | *** join/#brlcad Elperion (n=Bary@p5487721C.dip.t-dialin.net) | |
| 14:14.20 | brlcad | lachyg: was starting to say that the 'oed' command is another way to do what you were asking, you go into "object edit mode" on an object specifying where you want to apply a matrix and what primitive to use a coordinate system reference |
| 14:14.56 | brlcad | then you can use the 'orot' or 'objrot' commands to do a rotate |
| 14:15.14 | brlcad | those and other commands are listed on the mged cheat sheet reference |
| 14:16.44 | Defcon | hmmm.. ok |
| 14:16.46 | Defcon | :) |
| 14:26.55 | brlcad | in mged lingo, an "arc" is the same as an object "path", not a 2D/3D geometric arc but a logical arc through the geometry hierarchy |
| 14:27.26 | brlcad | arced could have just as readily been named pathed, but the 'arc' convention goes back to early 80's |
| 14:29.14 | brlcad | so when you're specifying an 'oed' object edit, think of all paths to primitives in your model, /comb/path/to/region/to/primitive .. you can apply a matrix after any one of those '/'s so you separate that to a left and right-hand side |
| 14:30.25 | brlcad | so if I wanted to apply a matrix over the instance of region used in that 'path' object, I would have specified oed /comb path/to/region/to/primitive |
| 14:32.58 | Defcon | impressive |
| 14:33.11 | Defcon | a matrix = an array(in vb)? |
| 14:35.35 | brlcad | hm? |
| 14:35.46 | brlcad | a matrix can be stored as an array in most languages |
| 14:36.05 | brlcad | it's just a list of 4 or 9 or 12 or 16 numbers usually :) |
| 14:36.20 | Defcon | ah |
| 14:36.21 | brlcad | usually 16 for 3D homogeneous coordinates |
| 14:36.31 | Defcon | lol |
| 14:36.34 | brlcad | 4x4 matrix |
| 14:36.41 | Defcon | still way to advanced for me |
| 14:36.42 | Defcon | :) |
| 14:40.34 | Z80-Boy | I never know which *ed command can be used in which mode |
| 14:40.41 | Z80-Boy | So I never use them that's the safest ;-) |
| 14:42.01 | Defcon | :) |
| 14:42.03 | Defcon | true |
| 14:42.08 | Z80-Boy | Matrix is just a way how to mix outputs from inputs |
| 15:12.04 | ``Erik | I thought it was where neo used to live |
| 15:12.47 | Defcon | :D |
| 15:30.02 | CIA-28 | BRL-CAD: 03erikgreenwald * 10brlcad/NEWS: note fix to xpush |
| 15:37.03 | Z80-Boy | brlcad: do you use CRT or LCD? |
| 15:38.29 | Defcon | whow first line in this channel i fully understand :) |
| 15:41.05 | ``Erik | people still use crt's? O.O |
| 15:50.10 | Z80-Boy | ``Erik: I just had to replace a LCD with CRT - if I ran compilation there were horizontal stripes randomly jumping on the screen |
| 15:50.18 | Z80-Boy | I tried a different LCD and the same problem |
| 15:50.41 | Z80-Boy | Then I tried CRT and it's OK. Plus I have more uniform white, better black and brighter colours. |
| 15:53.33 | PrezKennedy | and 3x less desk space! |
| 15:55.22 | Z80-Boy | The video is unbeliavebly smooth on CRT!P |
| 15:55.55 | Z80-Boy | PrezKennedy: I rather sacrifice some desk space than having to watch stripes |
| 15:57.03 | PrezKennedy | only when you compile right? |
| 16:01.01 | ``Erik | crt's are analog only, lcd's can take digital... if you were using a full digital path, mebbe your videocards digital part is messed up, or mebbe the analog just 'blurs' over the lines and ya don't see the bad signal.... crt running close to full resolution will usually be 60fps, where an lcd will be around 40fps, but the lcd won't have any kind of 'tearing' since the pixel stays 'lit' the same until next update, where a crt has a decay e |
| 16:02.09 | ``Erik | oops, too much geek, skeered him off |
| 16:03.06 | ``Erik | if it was just during compilation, may've been crosstalk effecting things... I know one of my old computers had problems with that, heavy load and I'd start hearing it on the speakers, and for some reason the mouse set it off, too O.o |
| 16:03.48 | PrezKennedy | i hear that once in awhile with a computer thats quite new... |
| 16:04.18 | Z80-Boy | Well it was analog |
| 16:04.30 | *** join/#brlcad prasad_ (n=psilva@static-70-108-244-218.res.east.verizon.net) | |
| 16:04.30 | Z80-Boy | and it was because the card apparently gets a clock jitter. |
| 16:04.34 | ``Erik | heh |
| 16:04.41 | Z80-Boy | But clock jitter should display as shifting of a line. |
| 16:04.57 | Z80-Boy | Shifting an object doesn't change it's brightness. But in this case the brightness flickered tremendously. |
| 16:05.06 | ``Erik | didja try moving the video cable around while compiling to see if it altered the behavior? |
| 16:05.08 | Z80-Boy | That means the LCD is showing something else than is in the signal, period. |
| 16:05.24 | prasad_ | gameboy? |
| 16:05.26 | Z80-Boy | No but I tried moving the LCD around, away from my desk. |
| 16:05.30 | Z80-Boy | That helped. |
| 16:05.44 | PrezKennedy | do you compile often? |
| 16:05.56 | Z80-Boy | That's completely irrelevant. |
| 16:05.57 | ``Erik | if two seperate lcd's showed the same thing, then the lcd is properly showing the signal, the signal is improper... crt's tend to be a lot more robust to 'funny data' in analog mode O.o |
| 16:06.06 | prasad_ | gameboy has a z80 :o |
| 16:06.22 | Z80-Boy | No the LCD is showing something else |
| 16:06.29 | Z80-Boy | The problem is the sampling is done improperly. |
| 16:06.45 | Z80-Boy | They leave out the sampling filter to satisfy the Nyquist criterion |
| 16:06.58 | Z80-Boy | CRT doesn't do any sampling. |
| 16:07.10 | Z80-Boy | So you either 1) do no sampling, or 2) do sampling properly |
| 16:07.17 | ``Erik | crt isn't digital, it's a "natural" sampling mechanism |
| 16:07.39 | Z80-Boy | I don't care how they implement it inside the monitor, it just has to show what's on the line |
| 16:07.56 | ``Erik | ... a crt DOESN'T show exactly what's ont he line, that's my point, dude |
| 16:08.02 | Z80-Boy | For me it's a blackbox. Shows the right picture? stays on the desk. Doesn't? Flies away. |
| 16:08.25 | ``Erik | smells to me like you're fixing the symptom, not the problem *shrug* |
| 16:08.26 | Z80-Boy | It doesn't but it's better than with LCD |
| 16:08.37 | Z80-Boy | And also I tried playing a music video... much smoother movements! |
| 16:08.45 | ``Erik | 'sup, prasad? |
| 16:08.50 | Z80-Boy | Like fast dance and rapid camera movements... |
| 16:08.53 | Z80-Boy | It was like in real! |
| 16:09.08 | Z80-Boy | With LCD I am feeling like losing track of the movement. |
| 16:09.24 | Z80-Boy | Sorry, but if I am more happy with CRT then it's better for me. |
| 16:09.29 | PrezKennedy | you need a faster LCD screen! |
| 16:10.15 | Z80-Boy | I suspect LCD's have an internal refresh rate that runs asynchronously with the VGA refresh rate and causes temporal aliasing |
| 16:10.40 | Z80-Boy | And the black on LCD is horrible and on white I see Haidinger's brushes all around |
| 16:10.41 | prasad_ | even with vsync on? |
| 16:11.05 | Z80-Boy | The vsync was on all the time |
| 16:11.13 | Z80-Boy | Without vsync the picture loses vertical sync |
| 16:15.13 | *** join/#brlcad ucrit (n=lucky@202.152.172.3) | |
| 16:15.43 | ``Erik | hum, older/cheaper lcd's have a 25ms response rate, which is sorta kinda the same as a refresh rate of 40hz, opposed to a 'normal' crt (at max res) of around 60hz... the lcd's I'm sitting at have 14ms response, which maths out to 71hz O.o prezkennedy may have a point there :D |
| 17:33.33 | *** join/#brlcad ucrit (n=lucky@202.152.172.3) | |
| 17:42.51 | *** join/#brlcad Elperion (n=Bary@p5487721C.dip.t-dialin.net) | |
| 18:13.25 | *** join/#brlcad yukonbob (n=yukonbob@198.235.198.234) | |
| 18:17.08 | *** join/#brlcad docelic (n=docelic@212.15.179.226) | |
| 18:48.34 | ``Erik | howdy ho |
| 19:10.20 | ``Erik | heheh e http://www.collegehumor.com/video:1788161 |
| 19:21.00 | *** join/#brlcad prasad_ (n=psilva@static-70-108-244-218.res.east.verizon.net) | |
| 19:27.15 | *** join/#brlcad Z80-Boy (i=clock@77-56-86-16.dclient.hispeed.ch) | |
| 19:53.17 | brlcad | Z80-Boy: both at home, but lcd predominantly |
| 19:58.28 | Z80-Boy | brlcad: is there a way to get rid of the warning when I put a region into another region? |
| 19:58.40 | Z80-Boy | I thought the "inherit" flag would logically turn it off but it doesn't |
| 20:19.42 | CIA-28 | BRL-CAD: 03brlcad * 10brlcad/misc/win32-msvc8/Makefile.am: typo, brrrrcad |
| 20:26.44 | *** join/#brlcad yukonbob (n=yukonbob@198.235.198.234) | |
| 20:27.58 | Z80-Boy | ``Erik: do you know how to get rid of the warning when I put a region into another region? |
| 20:36.27 | ``Erik | um, no? :) |
| 20:39.27 | Z80-Boy | It's very handy because I have a complex thing where each part is coloured a different way and now I want to make a variant which is all grey |
| 20:39.27 | *** join/#brlcad nedko (n=nedko@89.253.148.98) | |
| 20:39.37 | Z80-Boy | So I just put it into a region and override it all |
| 20:39.48 | ``Erik | it's just a warning, though, right? it still works? |
| 20:40.10 | Z80-Boy | I don't want all the matrices to be duplicated because that's a bad practice |
| 20:40.15 | Z80-Boy | Yes it works but warns |
| 20:40.40 | Z80-Boy | Warning: you are using an efficient method. |
| 20:40.50 | ``Erik | heh |
| 20:41.25 | ``Erik | um, one of the bigger reasons BRL-CAD gets funded is to support another piece of software that pukes all over itself when any primitive is seen twice in the tree... |
| 20:42.18 | ``Erik | we say it's their problem, they say it's ours, the warning keeps the poor users from stepping on landmines in a battle between developer groups |
| 20:43.02 | ``Erik | (if I'm guessing correctly... brlcad might be able to confirm or correct me on that) |
| 20:44.31 | Z80-Boy | What ?!? |
| 20:45.09 | Z80-Boy | If I have a grille with 100x100 holes, I have to crate 10,000 primitives to satisfy this idea of nonrepeating primitives? |
| 20:45.24 | ``Erik | ayup |
| 20:45.32 | ``Erik | why do ya think I've been working on 'clone' lately? |
| 20:45.41 | ``Erik | (I think it's idiotic, too...) |
| 20:46.42 | Z80-Boy | And if I realize the filtering action of the grille needs to be adjusted and change the holes from 4mm to 5mm, I have to edit ebery single primitive? |
| 20:46.48 | Z80-Boy | OMG WTF |
| 20:47.06 | ``Erik | um, everything in the database can be expressed without confusion using the path, right? well, these guys only look at the last entry on the path list and map it to their own names... so they require a 1-1 mapping of geometric primitives to a physically unique 'thing' |
| 20:47.35 | ``Erik | which is why ya see request tickets to warn or remove "instancing" in the sf bugs and feature requests... |
| 20:48.13 | ``Erik | and it's been that way for 20 years now :( |
| 20:50.57 | Z80-Boy | I don't know if "everything in the database can be expressed without confusion using the path, right? |
| 20:51.01 | Z80-Boy | " |
| 20:51.55 | Z80-Boy | if you have 2 M5x20 hex head bolts, do you have two physically unique things or two instances of one physical thing? |
| 20:51.58 | ``Erik | /part1/hole1/generichole /part1/hole2/generichole ... ? |
| 20:52.25 | Z80-Boy | yes that's how I do it |
| 20:52.40 | ``Erik | that would be instancing... 'generichole' only exists once, but you know where it goes due to the full path being a unique identifier... |
| 20:53.14 | ``Erik | opposed to just taking the last part, how do you distinguish between "generichole" and "generichole", even though you know they are in different physical locations? |
| 20:53.57 | ``Erik | we say "use the full path", they say "don't allow instancing" |
| 20:53.58 | ``Erik | :) |
| 20:54.24 | Z80-Boy | It's TIA/EIA - Training In Absurdity, Exercise In Absurdity |
| 20:54.51 | dtidrow_work | good grief |
| 20:54.51 | ``Erik | and I THINK that might be the reason for that specific warning being in there, because now you have /part1/hole1/generichole vs /greyview/part1/hole1/generichole... or 'generichole' vs 'generichole' for this certain consumer |
| 20:55.07 | ``Erik | I *THINK* |
| 20:55.23 | dtidrow_work | somebody needs to go over there and start swinging the cluebat around |
| 20:55.36 | ``Erik | again, if brlcad were to drag his arse in and either correct me or add something... :D |
| 20:56.26 | dtidrow_work | still |
| 20:56.32 | Z80-Boy | now the machines are fast but BRL-CAD is still slow |
| 20:56.35 | dtidrow_work | unnecessary bloat |
| 20:56.44 | Z80-Boy | my most complex model takes 1 minute to redraw in mged |
| 20:56.58 | Z80-Boy | open menu, close menu, wait a minute until the black rectangle left by the menu redraws... |
| 20:57.04 | Z80-Boy | change the zoom, wait a minute. |
| 20:57.08 | Z80-Boy | Shift the zoom, wait a minute. |
| 20:57.15 | ``Erik | hey, man, I don't like the practice eather, I'm just trying to guess at the reason for that warning being in there :) |
| 20:57.41 | ``Erik | heh, we have people routinely blowing the 2g limit on 32b builds here |
| 20:57.57 | dtidrow_work | how many parts are in that model, Z80-Boy? |
| 20:58.24 | Z80-Boy | I don't know how do I figure out? |
| 20:58.32 | ``Erik | don: fear his p233 ;) |
| 20:58.39 | Z80-Boy | I have p1500 |
| 20:58.49 | dtidrow_work | ``Erik: lol |
| 20:59.51 | ``Erik | being a command line dork, I'd sdo something like "mged -c file.g ls -l | grep -v 'comb\|region' | wc -l |
| 21:00.44 | ``Erik | errr, "mged -c /usr/brlcad/share/db/moss.g ls -l 2>&1 | grep -v 'comb\|region' | wc -l" |
| 21:00.47 | ``Erik | (on fbsd, using bash) |
| 21:03.06 | Z80-Boy | 0 |
| 21:03.11 | Z80-Boy | should I count >&2 instead? |
| 21:04.08 | Z80-Boy | 444 |
| 21:06.17 | dtidrow_work | brlcad: morning ;-) |
| 21:06.37 | ``Erik | I d'no, I'm not a csh user... bash, ksh, zsh, I'm there... but not csh |
| 21:07.40 | brlcad | inherit is only for visual property inheritance (i.e. shader properties) |
| 21:07.54 | brlcad | howdy dtidrow_work |
| 21:08.23 | brlcad | not quite the reason -- there is a code that craps on itself if there's particular combinations of regions in regions, but in this case that's not even the issue |
| 21:08.59 | brlcad | Z80-Boy: from what I'm hearing, it sounds like a misunderstanding of what it means to have that region bit set/unset |
| 21:09.21 | brlcad | it has nothing to do with the color properties, it has to do with space occupancy |
| 21:10.53 | Z80-Boy | brlcad: so how do I do that properly? |
| 21:10.53 | brlcad | you've basically said "this thing is wood, and now this _same_ thing used in a higher-level context is now not wood" |
| 21:10.56 | brlcad | so it (very correctly) warns you that you've just changed the material *type* (which again has nothing to do with color or shader properties, has to do with physical occupancy) |
| 21:11.36 | brlcad | Z80-Boy: the easy thing is unset the region bit on the higher level combination |
| 21:11.46 | brlcad | there should only be one region on any path down the hierarchy |
| 21:12.24 | brlcad | think of it as the "region" simply being when it goes from shape (blueprint/pattern) to solid (occupies space, has mass) |
| 21:12.50 | brlcad | you're just wanting a color override, that has nothing to do with regions |
| 21:13.06 | brlcad | you can color override any combination node |
| 21:14.33 | brlcad | dtidrow_work: there is a cluebat needed on that other code's behavior, but entirely unrelated to this issue ;) |
| 21:14.47 | ``Erik | <-- toldja he was guessing :D |
| 21:14.53 | brlcad | they do have an instancing name conflict problem, but they deal with it in their own "special" way |
| 21:15.17 | ``Erik | and I have a tendancy to go heavy on the code side, not so much the geometry/modeling side *shrug* O:-) |
| 21:15.28 | dtidrow_work | heh |
| 21:17.22 | Z80-Boy | brlcad: yes but if I unset the bit, the things starts being colourful again. |
| 21:17.58 | Z80-Boy | It's this one: http://ronja.twibright.com/3d/tetrax_0.png |
| 21:17.59 | brlcad | what do you mean? |
| 21:18.09 | Z80-Boy | Normally the thing is one welded piece and all grey from zinc plating |
| 21:18.35 | Z80-Boy | But I had to paint each piece individually to be able to refer to it in the assembly manual. |
| 21:19.12 | Z80-Boy | So each colour is an individual region and the resulting thing is a complicated combination of these regions, because they must not overlap so where they join one has to "give way" |
| 21:19.18 | ``Erik | what about making every piece a combination... then having two things that refer to it, a color manual copy with many regions, and a seperate display copy with all zinc |
| 21:19.24 | Z80-Boy | Now I want to paint the whole thing gray. Now making it over whole again. |
| 21:19.33 | *** join/#brlcad Elperion (n=Bary@p5487721C.dip.t-dialin.net) | |
| 21:19.50 | ``Erik | then the colorful regions all get grouped in their own assembly or something to give an easy handle... :) |
| 21:20.31 | Z80-Boy | ``Erik: Once I group them I cannot paint them individually later |
| 21:20.40 | Z80-Boy | So they have to be first painted then grouped |
| 21:20.52 | ``Erik | yes |
| 21:21.09 | Z80-Boy | I could just merge all the *.r things into one huge and remove the "give ways" and retain the matrices |
| 21:21.15 | ``Erik | /display/comb1/parts... /manual/region1/comb1/parts... |
| 21:21.31 | Z80-Boy | But that's bad practice. It can lead to shape inconsistency between the two copies |
| 21:21.35 | ``Erik | no |
| 21:21.39 | ``Erik | because comb1 is comb1 |
| 21:21.57 | ``Erik | two seperate regions point to the same combination underneath (yes, instancing, pheer) |
| 21:22.10 | *** join/#brlcad dtidrow (n=dtidrow@host131.objectsciences.com) | |
| 21:22.16 | Z80-Boy | I don't want that |
| 21:22.22 | Z80-Boy | I just want to overpaint a region grey |
| 21:22.33 | Z80-Boy | Sorry, a combo of regions |
| 21:22.51 | ``Erik | then suck it up and take the warning :) |
| 21:23.32 | Z80-Boy | what do you mean with "display" and "manual" |
| 21:23.55 | ``Erik | 'display' would be a region containing all your 'part' combinations. |
| 21:24.15 | ``Erik | 'manual' would be a combination, containing a set of regions (one for each part), and each region contains one 'part' combination |
| 21:24.37 | Z80-Boy | yes |
| 21:24.50 | ``Erik | so if you change a bolt size, BOTH regions see it, and you don't violate the 'one region per path' restriction |
| 21:25.53 | Z80-Boy | Now for example the "blue" region constains some elements with matrices |
| 21:26.17 | Z80-Boy | so I have to copy the region into a combo, unset the region flags and insert the combo into a region right? |
| 21:26.39 | Z80-Boy | I can not only change sizes of things but also their mutual positions. |
| 21:28.18 | Z80-Boy | What all do I have to do to properly deregionize? |
| 21:31.27 | ``Erik | um, I'd try to create a new region with the material and only one 'child', the old region... then figure out how to turn off the region bit on the old region, so it's just a plain combination |
| 21:31.51 | ``Erik | <-- doesn't know jack about USING the software, just a tiny bit about what's under the hood |
| 21:32.12 | ``Erik | I'm a mechanic, not a pilot |
| 21:32.44 | Z80-Boy | What happens if I only turn off the region bit but don't remove LOS, material ID shader colour etc.? |
| 21:32.51 | Z80-Boy | does BRL-CAD get into an inconsistent state or not? |
| 21:32.58 | ``Erik | (kinda more the machinist building the tools and parts for the mechanics... but that's going awful far on an analogy tangent) |
| 21:35.53 | brlcad | Z80-Boy: again, color has nothing to do with it being a region or not |
| 21:36.11 | brlcad | you just happened to make regions via the commands you used (presumably the r command) |
| 21:36.26 | brlcad | you can "unset" them as regions using the combination editor on the edit menu |
| 21:36.35 | brlcad | yep |
| 21:36.50 | brlcad | being a region really is just a 0/1 bit flip on a combination |
| 21:37.05 | brlcad | and relating to physical space _occupancy_ |
| 21:37.40 | ``Erik | on disk... right? regions and combinations have a few different 'in-memory' data bits, I think? |
| 21:38.00 | brlcad | so you have whatever grey hierarchy of objects, you can create another hierarchy separate from that with all of the colors set, or set the colors at two levels with an override |
| 21:39.36 | brlcad | ``Erik: not really for what he's doing, but yes -- there are a few other relevant parameters like LOS thickness, aircodes, the actual region ident code, etc |
| 21:39.59 | brlcad | basically things that affect spatial occupancy or evaluation of that occupancy |
| 21:40.05 | ``Erik | is it possible to demote a region to a combination? |
| 21:40.13 | ``Erik | without killing and rebuilding it? |
| 21:40.16 | brlcad | yep |
| 21:40.24 | brlcad | just open the combination editor and uncheck the region box |
| 21:40.37 | ``Erik | there ya go, karel :D |
| 21:40.56 | Z80-Boy | ``Erik: just did it :) |
| 21:40.59 | brlcad | it really is just an on/off flag on combinations from mge's perspective |
| 21:41.00 | ``Erik | (is there a command backed way to do it? for a geek who doesn't wanna keep grabbing the mouse? or someone doing it in a script?) |
| 21:41.14 | brlcad | hrm, there is.. |
| 21:41.18 | Z80-Boy | I did it with red |
| 21:41.28 | brlcad | something like attr put region 0 |
| 21:41.29 | Z80-Boy | I just had to turn off the plastic and the colour otherwise it complained warning |
| 21:41.40 | brlcad | forget the exact |
| 21:41.45 | brlcad | there's a half-dozen ways |
| 21:42.09 | brlcad | Z80-Boy: it complained probably because color override wasn't set |
| 21:42.24 | Z80-Boy | brlcad: what is color override good for? |
| 21:42.47 | Z80-Boy | can you have a combo with assigned color that overrides color of underlying regions? |
| 21:42.48 | brlcad | says whether the top-level color overrides lower-level colors |
| 21:43.35 | *** join/#brlcad prasad_ (n=psilva@static-70-108-244-218.res.east.verizon.net) | |
| 21:44.46 | Z80-Boy | Hmm when you do B before the previous B finishes, it often hangs or segfaults. |
| 21:44.57 | Z80-Boy | Advanced treatment of cricial sections, I would guess. |
| 21:45.24 | brlcad | really? huh |
| 21:45.35 | brlcad | i've not seen that |
| 21:45.38 | Z80-Boy | ``Erik: I could save al lthe work you said |
| 21:45.57 | Z80-Boy | I just got it. All I need to do is put the colourful thing into a combo tick up inherit set colour and plastic |
| 21:46.01 | Z80-Boy | and it doesn't complain! |
| 21:46.05 | CIA-28 | ow |
| 21:46.09 | Z80-Boy | If it's gonna segfault is a different question ;-) |
| 21:46.26 | Z80-Boy | brlcad: is that a correct method? |
| 21:46.53 | brlcad | yep |
| 21:47.00 | Z80-Boy | Why didn't you tell? |
| 21:47.01 | brlcad | (thought that's what I said) :) |
| 21:47.23 | brlcad | said create a separate hierarchy, set colors and inherit |
| 21:47.30 | ``Erik | ok, yeah, that sounds a bit easier than doing a per-combination hoist |
| 21:47.46 | Z80-Boy | what's a separate hierarchy and a hoist? |
| 21:48.05 | Z80-Boy | now I understand what the inherit is for |
| 21:48.12 | brlcad | great :) |
| 21:48.14 | Z80-Boy | it should be called "overpain" or something like that |
| 21:48.17 | Z80-Boy | overpaint |
| 21:49.01 | brlcad | it says during mater command "Lower nodes inherit this node's material settings" or something pretty similar |
| 21:49.24 | brlcad | likewise the help option on the comb editor |
| 21:49.27 | Z80-Boy | does it also inherit the material weight? |
| 21:49.41 | Z80-Boy | density I mean |
| 21:50.04 | *** join/#brlcad SWPadnos_ (n=Me@216.114.141.246) | |
| 21:51.21 | brlcad | good question.. I don't believe so |
| 21:51.32 | Z80-Boy | so it's just a cosmetic thing |
| 21:51.36 | Z80-Boy | and refraction index? |
| 21:51.45 | brlcad | yeah, afairemember, it's the shader |
| 21:51.48 | brlcad | and color |
| 21:52.31 | brlcad | refraction index is a shader parameter for phong, so yeah |
| 21:53.30 | Z80-Boy | OK thanks now it's all easy |
| 21:53.37 | brlcad | lets you quickly do things like create a new top-level combination called "glasstank" and turn a whole tank into glass (if you wanted such an effect), and likewise up and down a hierarchy |
| 21:53.51 | Z80-Boy | exactly! That's almost what I want! |
| 21:54.51 | prasad_ | mmm glass |
| 21:54.56 | *** join/#brlcad SWPadnos_ (n=Me@dsl245.esjtvtli.sover.net) | |
| 21:57.51 | *** join/#brlcad CIA-MIA (n=relay@bz.bzflag.bz) | |
| 21:58.15 | *** join/#brlcad SWPadnos__ (n=Me@dsl245.esjtvtli.sover.net) | |
| 22:06.05 | nedko | brlcad: can you please add lash project (http://cia.vc/stats/project/LASH) to CIA-MIA,#lac |
| 22:06.54 | CIA-28 | BRL-CAD: 03brlcad * 10brlcad/src/tclscripts/ (geometree/Makefile.am swidgets/scripts/Makefile.am): missed a couple dirs, include pkgIndex.tcl and tclIndex in the dist |
| 22:07.08 | CIA-28 | BRL-CAD: 03brlcad * 10brlcad/src/tclscripts/archer/images/Themes/Windows/Makefile.am: missed command.png, add to dist |
| 22:07.38 | *** join/#brlcad SWPadnos___ (n=Me@dsl107.esjtvtli.sover.net) | |
| 22:08.01 | brlcad | nedko: done |
| 22:08.14 | nedko | brlcad: thanks! |
| 22:09.11 | brlcad | np |
| 22:16.40 | ``Erik | heh, nifty |
| 22:17.50 | ``Erik | such a brlcad move... http://icanhascheezburger.files.wordpress.com/2007/11/alreadylicked128392284542500000.jpg |
| 22:18.07 | brlcad | hehe |
| 22:30.51 | CIA-28 | libirc: 03JeffM2501 * r341 10/trunk/libirc/examples/stupidBot/src/stupidBot.cpp: ws |
| 22:31.29 | CIA-28 | libirc: 03JeffM2501 * r342 10/trunk/libirc/botlib/ (inc/botlib.h src/botlib.cpp): methods to let the bot respond to methods privately instead of public if it's a channel message. |
| 22:37.45 | *** part/#brlcad nedko (n=nedko@89.253.148.98) | |
| 22:47.45 | CIA-28 | libirc: 03JeffM2501 * r343 10/trunk/libirc/botlib/ (inc/botlib.h src/botlib.cpp): |
| 22:47.45 | CIA-28 | libirc: make stuff that is supposed to be private to the bot class, be well private. |
| 22:47.45 | CIA-28 | libirc: move the isForMe method to protected, and make it virtual in case anyone wants to override it's logic with more complex logic. |
| 23:02.36 | *** join/#brlcad docelic (n=docelic@212.15.179.226) | |
| 23:03.39 | CIA-28 | libirc: 03JeffM2501 * r344 10/trunk/libirc/botlib/ (inc/botlib.h src/botlib.cpp): data utils for the config class |
| 23:04.03 | *** join/#brlcad illethal (n=oden@c-69-137-199-63.hsd1.fl.comcast.net) | |
| 23:04.23 | *** part/#brlcad illethal (n=oden@c-69-137-199-63.hsd1.fl.comcast.net) | |
| 23:16.04 | yukonbob | !ah right -- Heroes night tonight... |
| 23:17.29 | brlcad | :) |
