| 02:49.16 | *** join/#brlcad AchiestDragon (n=david@whipy.demon.co.uk) |
| 02:54.58 | CIA-4 | BRL-CAD: 03starseeker * 10brlcad/doc/book/VolumeII.xml: Additional markup |
| 04:54.16 | CIA-4 | BRL-CAD: 03starseeker * 10brlcad/doc/book/VolumeII.xml: Markup through Lesson 5 |
| 05:19.13 | *** join/#brlcad Z80-Boy (i=clock@217-162-111-201.dclient.hispeed.ch) |
| 08:10.16 | *** join/#brlcad Z80-Boy (n=clock@zux221-122-143.adsl.green.ch) |
| 08:33.43 | *** join/#brlcad Elperion (n=Bary@p5487536D.dip.t-dialin.net) |
| 11:58.43 | *** join/#brlcad elite01 (n=elite01@dslb-088-070-007-068.pools.arcor-ip.net) |
| 12:28.33 | Maloeran | Hum! Okay, I have quite a stupid question. How do you have command line tools pick file names that begin with - ( dash ) without complaining about an invalid option? |
| 12:29.15 | *** join/#brlcad Elperion (n=Bary@p5487536D.dip.t-dialin.net) |
| 12:29.37 | Maloeran | Ah right, a preceeding -- does it |
| 12:30.36 | archivist | Maloeran, you can quote a filename |
| 12:42.22 | Maloeran | "" would not help, it would still complain about an invalid option |
| 12:49.55 | brlcad | some commands take it, many in fact, but not all |
| 12:51.31 | Z80-Boy | brlcad: with my patch it's much easier to work with matrices in red |
| 13:08.00 | *** join/#brlcad cad52 (n=54095b3f@bz.bzflag.bz) |
| 13:33.42 | *** join/#brlcad thing0 (n=ric@124-169-43-146.dyn.iinet.net.au) |
| 13:34.02 | thing0 | hey |
| 13:34.08 | *** part/#brlcad thing0 (n=ric@124-169-43-146.dyn.iinet.net.au) |
| 14:00.09 | *** join/#brlcad elite01_ (n=elite01@dslb-088-070-117-055.pools.arcor-ip.net) |
| 14:06.27 | ``Erik | *yawn* |
| 14:33.40 | brlcad | Z80-Boy: okay, thanks! .. I was gone all weekend through Fri so it'll take me a bit to catch up with all the e-mail/trackers -- I did see them, though |
| 14:33.44 | brlcad | lots of good stuff |
| 14:33.58 | Z80-Boy | brlcad: you're welcome |
| 14:34.15 | Z80-Boy | brlcad: I could also get over that segfault and merge 2 databases together - someone already fixed it |
| 14:35.45 | brlcad | yeah, looked like john fixed it |
| 14:36.04 | brlcad | he reads your postings too ;) |
| 14:38.59 | *** join/#brlcad steko (n=steko@generic-nat.unisi.it) |
| 14:50.18 | brlcad | ciao steko |
| 14:50.30 | steko | ciao brlcad, |
| 15:36.48 | starseeker | Welcome back brlcad ;-) |
| 16:58.21 | ``Erik | heh |
| 16:58.35 | ``Erik | are you using push or xpush any? |
| 17:49.16 | CIA-4 | BRL-CAD: 03brlcad * 10brlcad/configure.ac: missing the second test command for the WITH_OPENGL conditional, irix shell no likey |
| 17:51.22 | ``Erik | is that one of those '"no" command not found' warnings? |
| 17:52.31 | brlcad | yep |
| 17:52.58 | brlcad | i'd fixed it week before last, but apparently forgot to commit it |
| 17:53.14 | ``Erik | good thing I didn't waste time digging into it :D |
| 17:53.54 | brlcad | it was the extra conditional you'd added on with_opengl to check for x11 too |
| 17:54.07 | ``Erik | now why would I be seeing "Sorry, this database is READ-ONLY" ? |
| 17:54.12 | brlcad | apparently newer versions of 'test' don't mind it |
| 17:54.16 | ``Erik | oh, woops |
| 17:54.23 | ``Erik | did I forget doublequotes or something? |
| 17:54.25 | brlcad | dunno what posix says about it |
| 17:54.38 | brlcad | nah, it was the command itself, being able to do multiple statements |
| 17:55.09 | ``Erik | I was just fixing those in a shell script on debian :/ |
| 17:55.16 | brlcad | you wrote: test foo -eq bar && boo -eq yah |
| 17:55.23 | ``Erik | yesh |
| 17:55.30 | brlcad | instead of: test foo -eq bar && test boo -eq yah |
| 17:56.01 | brlcad | new test apparently recognizes the && or silently ignores, or I just didn't notice it was erroring elsewhere |
| 17:56.07 | brlcad | doesn't matter, just added the second test, all better |
| 17:56.13 | brlcad | miniscule |
| 17:57.56 | CIA-4 | BRL-CAD: 03erikgreenwald * 10brlcad/sh/make_deb.sh: Migrate to using "test" instead of square brackets. Fix missing test on compound statement |
| 18:04.18 | *** join/#brlcad Z80-Boy (i=clock@77-56-92-121.dclient.hispeed.ch) |
| 18:09.57 | ``Erik | z80: if you use push after every matrix change, does it work better? O.o (push applies the matrix tot he primitives, so the comb matrices are reset back to identity) |
| 18:11.56 | Z80-Boy | ``Erik: I use red directly, is there a way to use push? |
| 18:12.16 | ``Erik | um, inside of red? I don't think so? |
| 18:27.17 | *** join/#brlcad Elperion (n=Bary@p5487536D.dip.t-dialin.net) |
| 18:27.29 | *** join/#brlcad yukonbob (n=yukonbob@199.247.232.95) |
| 18:27.35 | yukonbob | hello, cadders |
| 18:28.18 | brlcad | howdy yukonbobbers |
| 18:28.22 | yukonbob | ;) |
| 18:28.58 | yukonbob | hey brlcad, I'll take that committ bit from you now -- I've got docbook material to post ;) |
| 18:31.48 | brlcad | you been following starseeker's progress too? |
| 18:32.09 | yukonbob | yes -- we've been discussing the markup off-channel |
| 18:32.17 | brlcad | ah, neat |
| 18:34.24 | yukonbob | didn't want to fill this w/ docbook geekery, but probable should do it here, for logging's sake, everybody in loop :P |
| 18:34.51 | yukonbob | will do from now on; nothing crititcal lost though ;) |
| 18:48.13 | Z80-Boy | Now I understand why the threads are so slow |
| 18:48.33 | Z80-Boy | they are made of slanted cylinders, and that probably translated to TGC, and shooting TGC solves an equation of 4th order |
| 18:48.36 | Z80-Boy | brutal. |
| 18:52.14 | brlcad | anything even remotely cad-related is fair game ;) |
| 18:53.00 | brlcad | Z80-Boy: and the tgc's are actually fairly extensively optimized .. you could probably squeeze another 10% out, but it'd be really tough |
| 18:53.54 | brlcad | I suspect that the boolean is actually where you're spending most of your time, lots of CSG ops |
| 18:54.54 | Z80-Boy | boolean == ? |
| 18:55.19 | brlcad | the csg operations, union this with this with this, subtract this, etc |
| 18:55.44 | Z80-Boy | this is also optimized I guess |
| 18:55.49 | brlcad | very compact, but can quickly become very expensive if you have to evaluate many in a given cell |
| 18:56.13 | brlcad | heh, yeah .. i've tried rewriting the boolean weaver on at least three separate occasions now |
| 18:56.23 | brlcad | trying to get some speed out of it, and clean up the code |
| 18:56.44 | Z80-Boy | what about making a comb like a height field and rotating the comb radially? |
| 18:56.55 | Z80-Boy | Would it be faster than a lot of slanted cylinders stacked? |
| 18:57.15 | brlcad | not one of those tries did the performance actually increase though (and once even decreased significantly after the rewrite) |
| 18:58.12 | Z80-Boy | now I see the difference between BRL-CAD and the rest |
| 18:58.17 | Z80-Boy | BRL-CAD does proper bodie |
| 18:58.20 | Z80-Boy | bodies |
| 18:58.28 | Z80-Boy | most other programs use a quake-like triangular approximation |
| 18:58.38 | brlcad | not sure about using a height field .. my intuition would suggest that it'd be *massively* slower just due to the number of operations involved and the complexity of height field primitives |
| 18:59.43 | Z80-Boy | what else then? instead of cylinders rotate faceted things? |
| 19:01.19 | Z80-Boy | model screws as rivets, lol :) |
| 19:04.40 | Z80-Boy | but at least the screws look like real screws |
| 19:06.00 | Z80-Boy | is it possible to reference contents of another .g file in one .g file so that when the "another" file changes, it has an effect? |
| 19:08.54 | brlcad | Z80-Boy: yep, those "proper bodies" as you referred to them are what we mean when we say that BRL-CAD predominantly uses an implicit geometry representation -- not an explicit format or a polygonalized approximation |
| 19:09.22 | brlcad | and also why getting multi-representation working is so important.. so we can go back and forth between the two more readily |
| 19:09.56 | Z80-Boy | polygonalized is an approximation right? |
| 19:09.57 | brlcad | pipe is the only primitive that quickly jumps to mind for a screw thread |
| 19:10.00 | brlcad | yes |
| 19:10.11 | Z80-Boy | that's for games, not rendering |
| 19:10.49 | brlcad | referring to the contents in another .g is provided the "submodel" primtive .. but that is *rarely* ever used.. I can't even think of the last time it was tested, so it may or may not work frankly |
| 19:11.11 | brlcad | it's usually better to do keep/dbconcat as needed for merging/mixing geometry files |
| 19:11.17 | Z80-Boy | no help for submodel |
| 19:11.24 | brlcad | it's a primitive type |
| 19:11.36 | brlcad | in blah submodel |
| 19:13.25 | yukonbob | re: screws and hardware, I suggest checking out ronja.twibright.com |
| 19:15.03 | Z80-Boy | treetop == ? |
| 19:15.28 | Z80-Boy | space partitioning method == ? |
| 19:20.02 | Z80-Boy | Is concatenation of two binary databases also a binary database? |
| 19:20.33 | *** join/#brlcad iraytrace (n=iraytrac@c-76-23-15-187.hsd1.ut.comcast.net) |
| 19:24.28 | brlcad | Z80-Boy: yes, you can actually concat two dbs and end up with a valid db -- but if you concat that way, then it's entirely up to the user to know/resolve any naming conflicts beforehand |
| 19:24.49 | Z80-Boy | wow |
| 19:24.58 | Z80-Boy | I call this oldschool |
| 19:25.00 | brlcad | i.e. it's certainly doable, and often useful -- but wouldn't be the "usual" approach I'd suggest unless you know what you're doing |
| 19:25.13 | Z80-Boy | is there a unix command that does the same as "dbconcat" in mged? |
| 19:25.19 | Z80-Boy | Or can mged be fired in a script? |
| 19:25.26 | brlcad | you mean 'cat' ? |
| 19:25.38 | brlcad | mged can be fired in a script, that's probably best |
| 19:25.50 | Z80-Boy | how? mged << EOF commands EOF? |
| 19:25.54 | brlcad | mged -c existing.g dbconcat imported.g |
| 19:26.22 | brlcad | you could use an EOF herenow doc, but it will execute single commands if you list one after the filename |
| 19:26.28 | brlcad | e.g. mged -c file.g tops |
| 19:26.41 | Z80-Boy | but how do I get the output into a file then? |
| 19:26.53 | brlcad | get what output? |
| 19:26.55 | Z80-Boy | will it go into existing.g? |
| 19:27.11 | brlcad | it'll do whatever command you tell it |
| 19:27.28 | Z80-Boy | what does dbconcat -s and what -p? |
| 19:27.32 | brlcad | if you mean the text output that would normally be in the console, that's primarily stderr output |
| 19:27.40 | brlcad | sometimes content on stdout |
| 19:27.44 | brlcad | suffix/prefix |
| 19:28.08 | brlcad | it'll auto-append a prefix or suffix so you can guarantee there are no conflicting names |
| 19:28.12 | Z80-Boy | no I mean mged existing.g -c dbconcat add.g will store the resulting bigger database where? existing.g? |
| 19:28.14 | brlcad | during import |
| 19:28.47 | brlcad | it's as if you ran mged existing.g .. and then ran "dbconcat add.g" on th mged command prompt |
| 19:29.07 | Z80-Boy | and if I want to enter multiple commands on commandline? |
| 19:29.20 | Z80-Boy | omit -c, add "exit"? |
| 19:29.26 | brlcad | no |
| 19:29.34 | brlcad | -c is command/classic mode |
| 19:29.53 | brlcad | removing -c means that it' |
| 19:29.55 | Z80-Boy | call mged multiple times? |
| 19:29.58 | brlcad | it'll kick off the tcl gui |
| 19:30.01 | Z80-Boy | aha |
| 19:30.08 | Z80-Boy | so for a script, -c must be there...? |
| 19:30.12 | brlcad | yes |
| 19:30.32 | Z80-Boy | I think it will be best if I want to assemble two models together |
| 19:30.32 | brlcad | now, whether you list a command or not determines whether it's in single-command mode or not |
| 19:30.45 | Z80-Boy | make a.g, b.g and c_glue.g (source files) |
| 19:30.54 | Z80-Boy | and then cp c_glue.g c.g |
| 19:31.01 | Z80-Boy | mged -c c.g dbconcat a.g |
| 19:31.15 | Z80-Boy | mged -c c.g dbconcat b.g |
| 19:31.18 | Z80-Boy | and then rt c.g |
| 19:31.34 | Z80-Boy | then I'll have proper dependencies in the makefile |
| 19:31.36 | brlcad | yeah, you can reinvoke mged -c like that many times and it should be just fine -- it's really a lightweight binary in command-mode |
| 19:31.51 | Z80-Boy | how do I do it with only one mged invoke? |
| 19:32.05 | brlcad | a herenow doc like you suggested |
| 19:32.14 | brlcad | or source a tcl script |
| 19:32.23 | Z80-Boy | mged -c c.g < file_with_commands ? |
| 19:32.24 | brlcad | mged -c foo.g source file.tcl |
| 19:32.34 | brlcad | or mged -c foo.g <<EOF |
| 19:32.37 | brlcad | blah blah |
| 19:32.38 | brlcad | EOF |
| 19:32.54 | brlcad | yeah, you could use a redirect like that too |
| 19:33.07 | Z80-Boy | do I have to put "exit" as the last command? |
| 19:33.07 | brlcad | echo "tops" | mged -c foo.g |
| 19:33.19 | brlcad | nah, it quits on end-of-file |
| 19:33.24 | Z80-Boy | what sucks the most is not how it's slow, but that the dependences are missing |
| 19:33.36 | brlcad | dependencies? |
| 19:33.40 | Z80-Boy | I change one tiny nut and whole Ronja has to be recompiled, because i changed the Big Mighty ronja.g |
| 19:33.53 | Z80-Boy | I have all the hierarchy in ronja.g |
| 19:34.56 | Z80-Boy | but... a problem |
| 19:35.02 | Z80-Boy | I won't be able to edit the c_glue.g |
| 19:35.17 | Z80-Boy | since I won't see what I am doing :( |
| 19:35.35 | brlcad | heh, well depends what sorts of edits, and how often you need to do the editing |
| 19:35.43 | brlcad | if the editing can be scripted, you're golden |
| 19:36.07 | brlcad | pretty much everything that you can do via the gui can be done in classic mode |
| 19:36.16 | Z80-Boy | often |
| 19:36.24 | Z80-Boy | no scriptiing of editing |
| 19:36.39 | Z80-Boy | I think I need to use that seldom-used feature "dubmodel" |
| 19:36.43 | Z80-Boy | submodel |
| 19:36.48 | Z80-Boy | what's the "space partitioning"? |
| 19:36.56 | brlcad | well that's not a problem anything can really solve .. if you need to graphically edit, then .. well.. human in the loop |
| 19:37.23 | Z80-Boy | no it can be solved with the submodel |
| 19:37.33 | Z80-Boy | I just need to type explicit dependencies into the makefile |
| 19:37.39 | brlcad | i'm still not hearing what the problem you're actually trying to solve is |
| 19:37.48 | Z80-Boy | I basically need a brlcad equivalent of the C #include |
| 19:37.58 | brlcad | but what's the *problem* |
| 19:38.11 | brlcad | what do you need that for? |
| 19:38.19 | brlcad | not saying you don't, there just might be another/better way |
| 19:38.21 | Z80-Boy | for Ronja |
| 19:38.29 | brlcad | gah |
| 19:38.43 | brlcad | what is the *task* that you need it for? |
| 19:38.47 | Z80-Boy | If I change something on tiny part A, I don't want a video of tiny part B be rendered again |
| 19:39.04 | Z80-Boy | The task is to keep an up to date set of model videos of Ronja parts |
| 19:39.12 | Z80-Boy | throughout the development of the Ronja project |
| 19:39.18 | *** part/#brlcad iraytrace (n=iraytrac@c-76-23-15-187.hsd1.ut.comcast.net) |
| 19:39.49 | brlcad | okay, got that good .. next question then is why does editing part A now cause B to be rendered again? |
| 19:40.01 | Z80-Boy | Because they are both in the same file - ronja.g |
| 19:40.06 | Z80-Boy | Editing part A touches that file |
| 19:40.23 | Z80-Boy | The makefile process is driven by timestamps on files |
| 19:40.24 | brlcad | ah, because you're using something that checks the file timestamp, like make or something |
| 19:41.01 | brlcad | got it |
| 19:41.52 | Z80-Boy | someone calls "Ronja is crap, it bent in the wind". I fire up mged console.g, replace 2mm thickness with 3mm thickness, type "make rsync" and the website is updated |
| 19:41.52 | brlcad | you can still do what you want without resorting to submodels |
| 19:41.56 | Z80-Boy | How? |
| 19:42.03 | brlcad | keep each part in it's own .g file, edit that file as needed |
| 19:42.19 | brlcad | have a make rule that does the dbconcat of each of those files to make the bigger .g |
| 19:42.21 | Z80-Boy | and how do I render videos where several parts are assembled into an assembly? |
| 19:43.30 | Z80-Boy | But I still need the combination of the parts and the matrices that say how the parts are shifted and rotated |
| 19:43.41 | Z80-Boy | and when debugging this matrix, I need to have all parts loaded in mged |
| 19:43.45 | brlcad | the videos use whatever submodel portion is being rendered, so if you are rendering a bolt animation, it'd use bolt.g -- if you are rendering the whole thing, it'll necessarily be the whole.g and will rerender when anything it includes updates |
| 19:43.52 | Z80-Boy | The only solution I can see is use the submodel |
| 19:44.14 | Z80-Boy | As I said, no way to actually work on whole.g |
| 19:44.38 | Z80-Boy | What is the "space partitioning", or at least what should I type there? |
| 19:44.46 | Z80-Boy | And what is the "treetop"? |
| 19:44.47 | brlcad | if you work on pushed matrices, then there are no shift/rotation matrices to deal with during composition |
| 19:44.56 | Z80-Boy | what is a pushed matrix? |
| 19:45.28 | brlcad | basically think of it as order of operations when dealing with a hierarchy |
| 19:45.29 | Z80-Boy | In any case I need to tell brl-cad how the parts should be translated and rotated before assembled |
| 19:45.38 | Z80-Boy | For this I need to have all parts loaded at once to try it out |
| 19:45.56 | brlcad | you can have a hierarchy that has matrics, or the matrices can be *pushed* down to the leave nodes (i.e. all the way to the primitives) |
| 19:46.28 | brlcad | it's a good/bad tradeoff in that it makes composition a breeze, but can be harder since you loose a localized coordiante system |
| 19:46.33 | brlcad | (per part) |
| 19:46.36 | Z80-Boy | hmm, what is the space partitioning? |
| 19:49.20 | brlcad | just put a zero |
| 19:49.25 | brlcad | if that doesn't work, but a 1 |
| 19:49.25 | Z80-Boy | cool |
| 19:49.31 | brlcad | s/but/put/ |
| 19:49.32 | Z80-Boy | How do I know it works? |
| 19:49.43 | brlcad | probably if it doesn't crash on you |
| 19:49.44 | Z80-Boy | And the treetop is actually the thing I want to include? |
| 19:49.59 | brlcad | like I said, you're veering into code that hasn't been used really in many years |
| 19:50.21 | brlcad | yeah, treetop is the hierarchy you want to reference |
| 19:50.31 | Z80-Boy | Isn't there really something like #include? |
| 19:50.58 | Z80-Boy | that would just merge in another file, without actually adding it into the working database? |
| 19:51.23 | brlcad | that is the submodel object |
| 19:51.31 | brlcad | (didn't we already go through this??) |
| 19:51.54 | brlcad | the only difference is that it's asking you what line to start with |
| 19:52.06 | brlcad | (if you're going to compare to #include) |
| 19:52.52 | Z80-Boy | Works |
| 19:52.56 | Z80-Boy | but it made the part all gray |
| 19:53.08 | Z80-Boy | How do I make it to keep the region structure inside the part? |
| 19:56.46 | brlcad | hm, I don't think it is |
| 19:57.12 | brlcad | it knows the structure, i.e. it's still there, but there aren't any named references to it unless you make submodels on a per-region basis |
| 19:58.11 | Z80-Boy | I can't use that then |
| 19:58.21 | Z80-Boy | Can I have file a submodelling b and b submodelling c? |
| 19:58.23 | brlcad | how about just keeping the one ronja.g file that you edit, but then have your script do a 'keep bolt_test.g bolt', and check if bolt_test.g md5 is same as bolt.g to determine whether it needs to cp bolt_test.g bolt.g |
| 19:58.40 | brlcad | yeah, recursive submodels should work |
| 19:58.55 | brlcad | and you're probably screwed if you make a cyclic reference |
| 19:59.03 | Z80-Boy | what is "keep bolt_test.g bolt" supposed to do? |
| 20:00.06 | Z80-Boy | Oh yes |
| 20:00.11 | Z80-Boy | that solves the problem with editing |
| 20:00.16 | brlcad | keep is an mged command, you'd have your ronja.g and then just break out .g files for each of the pieces that you're rendering the in makefile |
| 20:00.29 | Z80-Boy | I edit the machine-generated file c.g and then do "keep c_glue.g c" and that's it |
| 20:00.42 | Z80-Boy | I have even the luxury to decide if I want to keep my experimental changes or discard them wow :) |
| 20:00.46 | brlcad | but only "create" the new .g files if the contents actually change using something like g_diff or md5 |
| 20:00.55 | Z80-Boy | No need to use the wipe-my-nice-colours command "submodel" |
| 20:01.03 | brlcad | yeah, that sucks |
| 20:01.21 | brlcad | submodels solve a particular class of problems, but not really the one you need |
| 20:01.24 | Z80-Boy | but it has the cyclic reference problem :D |
| 20:01.28 | Z80-Boy | My computer would go on fire |
| 20:01.41 | Z80-Boy | I think the makefile will be fine |
| 20:02.17 | Z80-Boy | does the "keep" automatically keep all referenced objects or just the one object? |
| 20:02.33 | Z80-Boy | i. e. if I have a.c consisting of a.s and b.s, does it save only a.c or everything? |
| 20:03.05 | brlcad | everything referenced/needed |
| 20:03.14 | Z80-Boy | omg |
| 20:03.19 | Z80-Boy | how do I turn that off? |
| 20:03.25 | brlcad | huh? |
| 20:03.46 | brlcad | you wouldn't ever want to turn that off, maybe you misunderstand.. |
| 20:03.48 | Z80-Boy | Is there a command which does the same as keep, just saves the object without references? |
| 20:04.00 | Z80-Boy | I would, otherwise it would just save everything. |
| 20:04.09 | brlcad | a.c is just a couple text labels without a.s and b.s |
| 20:04.17 | brlcad | there wouldn't be any geometry |
| 20:04.20 | brlcad | nothing to see |
| 20:04.32 | brlcad | a.c is the operations |
| 20:04.42 | brlcad | you'd have ops on nothing |
| 20:05.34 | brlcad | give it a try, I don't think it means what you maybe think it means |
| 20:05.38 | brlcad | there's a model hierarchy |
| 20:05.45 | brlcad | a directed acylic graph of geometry and operations |
| 20:06.24 | brlcad | do display/use/edit *any* node in the hierarchy *necessarily* requires the subtree below it (by definition) |
| 20:07.01 | Z80-Boy | It keeps all prerequisites |
| 20:07.13 | Z80-Boy | I don't want that. It's useless for me. I want just the single object. |
| 20:08.30 | brlcad | it is the single object... |
| 20:08.59 | Z80-Boy | no if I open the database then I see a whole load of object |
| 20:09.01 | Z80-Boy | sobjects |
| 20:09.04 | Z80-Boy | objects |
| 20:09.05 | brlcad | you're misunderstanding something really fundamental here about the geometry hierarchy |
| 20:10.07 | brlcad | 'ls' merely shows you the geometry hierarchy flattened .. but there are requisite inter-relationships |
| 20:10.30 | brlcad | if you have a combination that says use this primitive and that primtive, those *necessarily* need to exist or the combination is invalid |
| 20:11.16 | brlcad | the primitives are the leaf nodes of the hierarchy, they *are* the positive and negative space |
| 20:11.40 | brlcad | the combinations merely describe how to .. combine them together |
| 20:13.47 | Z80-Boy | Is it possible to have the combination saved in a separate file? |
| 20:14.15 | brlcad | yes? |
| 20:14.18 | Z80-Boy | If I have two parts A and B that come together then I have 3 videos: A, B, and A+B |
| 20:14.41 | *** mode/#brlcad [+o brlcad] by ChanServ |
| 20:15.13 | brlcad | okay |
| 20:15.24 | brlcad | A, B, and C (where C=A+B) |
| 20:17.45 | brlcad | so you have your ronja.g that has A,B,C ... your makefile will do a keep on A and B for certain, and on C if there are more contents than just A and B |
| 20:18.21 | brlcad | does the keep, do an md5 to see if they're different content-wise, if they are you cp |
| 20:35.19 | ``Erik | *ponder* |
| 20:37.04 | ``Erik | given a clone operation on a primitive, any rotation, translation, mirroring, etc. must alter the primitive in description as well as name, as solids have no matrix attached... should clone on a comb have the effect of push and hold identity matrix when given translation or rotation? |
| 20:37.32 | ``Erik | and when cloning, say, 10 copies, does mirror insinuate that all ten are flipped compared to the original, or that they alternate? |
| 20:49.18 | brlcad | some solids have a matrix, some don't .. but yeah it's all internal .. even the ones that do |
| 20:49.40 | brlcad | I wouldn't expect clone on a comb to push |
| 20:49.56 | brlcad | but it's probably option-worthy |
| 20:50.45 | brlcad | just mimic what the v4 code does |
| 20:50.47 | ``Erik | hm, by default, the state matrix is applied to all primitives on copy |
| 20:50.56 | brlcad | you can open a v4 and clone will work now already |
| 20:51.25 | ``Erik | man, that'd mean reading through the v4 format to figure ot what these direct hacks do :D |
| 20:51.43 | brlcad | I mean run the command, just see what it currently does |
| 20:51.53 | brlcad | i don't recall it doing a push |
| 20:52.05 | brlcad | but don't know what it did for -n 10 on a mirror |
| 20:52.15 | ``Erik | not explicitely, but in calling the v4_copy_solid, passing the matrix... |
| 20:52.23 | brlcad | my guess would be n mirrored copies, not flipflopping |
| 20:52.47 | brlcad | dbupgrade -r |
| 20:52.50 | brlcad | (revert) |
| 20:52.56 | brlcad | ssshh |
| 20:53.07 | brlcad | intentionally undoc'd |
| 20:53.15 | ``Erik | the source is the documentation O.o |
| 20:53.21 | brlcad | yep |
| 20:53.36 | brlcad | if they're smart enough to get that far, more power to them for using the option |
| 20:54.06 | ``Erik | I'm also kinda wondering if dbupgrade could do some magic testing to solve endian and other 'gotchas' |
| 20:54.38 | ``Erik | if it could, reliably... then v4 can start getting marked 'broken' in places to force adoption of v5 |
| 20:55.52 | brlcad | can't practically force it, just have to make enough of a good reason for them to upgrade/convert |
| 20:57.20 | ``Erik | yes, by slowly marking more and more v4 functions 'broken' (like, bu_log("broken"); return NULL; ) |
| 20:57.22 | ``Erik | :D |
| 20:57.22 | brlcad | would be interesting to add the corresponding #defines to dbupgrade.c before the headers to see if it could be forced to presume local is big or little on-demand, though ... "should" work if the right things are set/undef'd |
| 20:58.14 | ``Erik | if its' just endian, then having little and big endian tests for the file magic should tell you to swap... hopefully no 'middle endian' or funny width files are out there :/ |
| 20:58.34 | ``Erik | or, rather, a 'right' magic and a 'backwards' magic |
| 21:16.00 | *** join/#brlcad thing0 (n=ric@124-169-43-146.dyn.iinet.net.au) |
| 21:21.30 | *** join/#brlcad yukonbob (n=yukonbob@whthyt232-45.northwestel.net) |
| 21:22.39 | ``Erik | oh... hum... |
| 21:36.33 | *** join/#brlcad iraytrace (n=iraytrac@c-76-23-15-187.hsd1.ut.comcast.net) |
| 21:48.23 | yukonbob | brlcad: ping |
| 21:49.14 | iraytrace | yukonbob: pong! |
| 21:49.18 | iraytrace | ;-) |
| 21:50.13 | yukonbob | did you change your name sean? |
| 21:50.27 | brlcad | hum? |
| 21:50.33 | yukonbob | ah |
| 21:50.40 | brlcad | ah, heh no |
| 21:50.41 | yukonbob | iraytrace confused me. |
| 21:50.55 | iraytrace | sorry |
| 21:52.04 | yukonbob | brlcad: hey -- re: docs -- how long might it take to get commit access (do you need my sourceforge details?), or should I forward work to you for posting? |
| 21:53.13 | brlcad | yukonbob: yeah, need your sf.net user |
| 21:54.25 | brlcad | give me about an hour .. just now running out the door |
| 21:54.48 | yukonbob | np -- thx, brlcad :) |
| 21:54.50 | brlcad | time to cross the border *ding* taco bell |
| 22:02.37 | starseeker | yukonbob: How long is vol4 shaping up to be as docbook? |
| 22:12.10 | CIA-4 | BRL-CAD: 03starseeker * 10brlcad/doc/book/VolumeII.xml: Markup through Lesson 6 |
| 22:26.28 | CIA-4 | BRL-CAD: 03starseeker * 10brlcad/doc/book/VolumeII.xml: Markup through Lesson 7 |
| 22:42.11 | starseeker | Sweet! |
| 22:45.35 | yukonbob | getting all the references setup will be non-trivial, but I'm happy ;) |
| 22:48.07 | starseeker | Very nice! |
| 22:48.37 | yukonbob | how's your work going? |
| 22:48.58 | starseeker | and images... |
| 22:49.04 | starseeker | a ways to go |
| 22:49.11 | starseeker | But making progress! |
| 22:49.24 | yukonbob | ah -- /me has to do some images too -- I put in place-holder images currently |
| 22:50.48 | yukonbob | I'd like to thank $deity, my parents, all the other nominees... |
| 22:55.09 | yukonbob | starseeker: if you'd like my work to compare/contrast with what you've got going, let me know. |
| 22:58.01 | starseeker | that would be great - but if brlcad is going to give you commit privs, I'll get a look at it then |
| 22:58.41 | yukonbob | sure thing. |