| 00:17.15 | CIA-62 | BRL-CAD: 03r_weiss * r45358 10/brlcad/trunk/src/librt/primitives/nmg/nmg_mod.c: |
| 00:17.15 | CIA-62 | BRL-CAD: Updated function 'nmg_shell_coplanar_face_merge' within file 'nmg_mod.c'. This |
| 00:17.15 | CIA-62 | BRL-CAD: update improves the success of boolean operations on nmg objects which contain |
| 00:17.15 | CIA-62 | BRL-CAD: coplanar faces. This change effects functions such as the mged 'facetize' and |
| 00:17.15 | CIA-62 | BRL-CAD: 'ev' commands. |
| 00:27.57 | *** join/#brlcad epileg (~epileg@unaffiliated/epileg) |
| 00:46.26 | *** join/#brlcad crazy_imp (~mj@a89-182-114-102.net-htp.de) |
| 01:01.59 | *** join/#brlcad KimK (~Kim__@ip174-71-95-176.om.om.cox.net) |
| 01:57.08 | *** join/#brlcad _psilva1 (~Adium@pool-74-96-114-18.washdc.fios.verizon.net) |
| 01:57.30 | _psilva1 | eh |
| 01:59.47 | _psilva1 | test |
| 01:59.52 | *** part/#brlcad _psilva1 (~Adium@pool-74-96-114-18.washdc.fios.verizon.net) |
| 02:00.06 | *** join/#brlcad _psilva1 (~Adium@pool-74-96-114-18.washdc.fios.verizon.net) |
| 02:00.17 | _psilva1 | test 2 |
| 02:01.42 | _psilva1 | anyone compile pkg-config lately? |
| 02:03.11 | *** join/#brlcad louipc (~louipc@archlinux/trusteduser/louipc) |
| 02:49.54 | ``Erik | we were doing a hard push on a release until someone did a metric fuckton of libged commits.. with any luck, we'll finish the release cycle this week with a build that is auto*, cmake and pkg friendly :/ |
| 02:55.00 | ``Erik | starseeker: you have access to the box that's causing issue, I'd not qualify it as a show stopper for the release, just a "needs to be looked into soon" issue |
| 03:31.31 | brlcad | bhinesley: probably opt for your previous suggestion, making different options -c # # # == -x # -y # -z # |
| 03:32.21 | bhinesley | alright |
| 03:33.08 | bhinesley | I have an idea to make the oed-ish commands more versatile |
| 03:33.25 | bhinesley | I'll show you later |
| 03:33.40 | brlcad | xyz or ijk |
| 03:33.41 | brlcad | ok |
| 03:34.18 | brlcad | could use xyz for points and ijk for angles or somesuch |
| 03:34.42 | brlcad | or gang them together, just a lil messier to validate |
| 03:36.20 | bhinesley | hmm so you don't like "translate 5 # 7 object2.c"? |
| 03:36.49 | bhinesley | I'm not quite following |
| 04:08.57 | brlcad | not particularly |
| 04:09.13 | brlcad | that would be introducing a new 'convention' of sorts |
| 04:09.28 | brlcad | and not one particularly obvious |
| 04:09.36 | bhinesley | yeah, I was hoping there was one |
| 04:15.10 | bhinesley | what about using the -x -y -z's as placeholders: "translate -k -x -y 5 -x -y 6 obj.c" would move obj.c from 5 to 6 on the z-axis |
| 04:16.11 | bhinesley | well not exactly... it would be equivalent to 'translate -x -y 1 obj.c' |
| 04:16.30 | brlcad | that doesn't make a whole lot of immediate sense to me either |
| 04:17.16 | bhinesley | the trouble with the way you mentioned, is that you can't tell the difference between a -x for a keypoint and a -x for a delta |
| 04:17.59 | bhinesley | there's something similar to this in AutoCAD called point filters... extremely useful and underused |
| 04:19.09 | brlcad | oh but there is, missing opts |
| 04:20.28 | brlcad | translate -a -c 1 2 3 foo ; translate -r -x 2 -y 1 foo ; foo is at 3 3 3 |
| 04:20.45 | brlcad | absolute and relative options |
| 04:21.46 | brlcad | or one could be the default so you only need the option to specify the other |
| 04:22.01 | brlcad | e.g., relative as default, then -a for absolute |
| 04:24.34 | brlcad | since all three commands need to work together and writing argv/argc parsing sucks, write out the synopsis first |
| 04:24.42 | brlcad | for tra, sca, rot |
| 04:25.10 | bhinesley | I did for my idea... I should show you now. |
| 04:25.28 | brlcad | so we don't end up with -c coordinate, -p point, -k keypoint, all meaning the same thing |
| 04:26.08 | bhinesley | Alright, keep in mind that I was thinking that using a placeholder like '-' would be okay when I wrote this: http://pastebin.mozilla.org/1261895 |
| 04:27.21 | bhinesley | formatting got a little screwed up |
| 04:29.50 | brlcad | halfway through |
| 04:30.05 | brlcad | that's actually looking pretty good |
| 04:31.50 | brlcad | still think the - is a bit screwy -- we do have a convention of using '.' with another command so that'd be the only relevant convention, but I think that explicit axis opts would provide more clarity and the '.'s would just be a shorthand for experts |
| 04:33.15 | bhinesley | that sounds good; there's one case that it may be problematic to use the -x/-y/-z with: 'translate -k -x 1 -y 2 -z 3 object' is ambiguous... but it may not be a valid command anyways |
| 04:33.28 | brlcad | another convention used is a field separator, e.g., "5/2/3" or "3,1,3" .. where you allow empty fields "/2/3" and ",,3" |
| 04:36.21 | brlcad | not a huge fan, though |
| 04:36.44 | bhinesley | I think the -x/-y/-z and '.' thing works |
| 04:36.50 | bhinesley | any ideas for alternatives to the '-' arguments for the -c/-o options? |
| 04:42.59 | bhinesley | I suppose I could allow use of '.' intended for experts as with -x/-y/-z, and everyone else just types out the path/obj again |
| 04:46.02 | bhinesley | or sets it to a TCL variable |
| 04:49.23 | epileg | starseeker: mged compiled with cmake has these more dependencies http://paste.debian.net/121565/ than the mged compiled with autotools |
| 04:50.27 | brlcad | bhinesley: avoid any interaction with tcl on the libged side of things |
| 04:50.38 | bhinesley | I meant that the user could |
| 04:50.46 | brlcad | k |
| 04:50.57 | brlcad | the goal is to make the core libs completely devoid of tcl, long term project |
| 04:51.16 | brlcad | basically undoing integration from the past 15 years :) |
| 04:51.23 | bhinesley | hehe |
| 04:53.34 | brlcad | bhinesley: I like the write up |
| 04:53.42 | brlcad | clearly put a good bit of thought into this |
| 04:53.51 | bhinesley | cool, thanks |
| 04:54.46 | bhinesley | ...thanks for taking it seriously |
| 04:54.58 | bhinesley | would have been easy to say "meh. do it my way." |
| 04:55.35 | brlcad | meh, it's not that bad ;) |
| 04:55.43 | bhinesley | hehe |
| 04:55.57 | brlcad | I think -x/-y/-z and '.' will help be more consistent |
| 04:56.55 | brlcad | except in this context... 0.0 vs 0. vs .0 vs . are all pretty similar :) |
| 04:58.26 | brlcad | something about this is bothersome: translate -k -23 4 17 9 2 1 bowl.c |
| 04:58.50 | brlcad | I think it's the slew of labeled and unlabeled numbers |
| 05:00.01 | bhinesley | could make a -d (delta) switch, that is optional/only required when -k is used |
| 05:00.25 | bhinesley | "translate -k -23 4 17 -d 9 2 1 bowl.c" |
| 05:00.49 | bhinesley | honestly, that is nothing more than a relative translation that does some math for you |
| 05:03.41 | brlcad | nods |
| 05:03.46 | brlcad | it's more important for rotate |
| 05:04.46 | brlcad | I think it gets back to an optional [-a|-r] for the TO |
| 05:05.12 | brlcad | translate -k -23 3 17 -r 9 2 1 bowl.c |
| 05:05.26 | brlcad | which is same as translate -k -23 4 17 9 2 1 bowl.c |
| 05:05.33 | bhinesley | good idea |
| 05:05.34 | brlcad | i.e., -r is optional and default |
| 05:05.42 | brlcad | but makes documenting instructions more clear |
| 05:06.17 | brlcad | and in that context -k with -a would be pointless since -a wins, but no harm to specify it |
| 05:07.35 | bhinesley | shouldn't it be "translate -k -23 3 17 -a 9 2 1 bowl.c" though, since the 9,2,1 are absolute coordinates |
| 05:07.57 | bhinesley | and then "translate -r 5 5 5 obj" == "translate 5 5 5 obj" |
| 05:09.05 | bhinesley | n/m I read your last sentence |
| 05:09.33 | *** join/#brlcad _psilvah (~prasad@pool-74-96-114-18.washdc.fios.verizon.net) |
| 05:09.39 | _psilvah | brlcad: w00t! :D |
| 05:10.06 | brlcad | heh |
| 05:10.08 | _psilvah | finally progress |
| 05:10.25 | _psilvah | thanks btw |
| 05:12.39 | brlcad | hey, it's for a good cause if it gets you back into useful coding ;) |
| 05:12.54 | _psilvah | 3 |
| 05:13.24 | _psilvah | bench is next |
| 05:13.39 | _psilvah | tho i need to brush up on svn commands |
| 05:13.55 | _psilvah | now how do i switch to window 3.. |
| 05:13.58 | _psilvah | :( |
| 05:14.12 | brlcad | bhinesley: my understanding is => translate -k 10 10 10 -a -10 0 10 bowl.c => -10,0,10 and... |
| 05:15.16 | brlcad | translate -k 10 10 10 -r -10 0 10 bowl.c => translate -k 10 10 10 -10 0 10 bowl.c => translate -k 10 10 10 -10 . 10 bowl.c => 0,10,20 |
| 05:18.16 | bhinesley | that's the exact opposite of what I was thinking :) |
| 05:18.39 | brlcad | hah, outstanding then |
| 05:19.46 | brlcad | how does a relative translate get you to absolute coordinates from a keypoint? |
| 05:21.58 | brlcad | would be nice to combine the -c -o -k options, to simplify usage |
| 05:22.08 | brlcad | -k object makes perfect sense to me |
| 05:23.41 | brlcad | just need to know which point in object |
| 05:25.21 | bhinesley | I think I just misunderstood what you were saying... translate -k 10 10 10 -a -10 0 10 bowl.c would move you a relative -20,-10,0, right? |
| 05:25.50 | bhinesley | when I'm thinking of "-a", I'm thinking, these coordinates are absolute |
| 05:26.25 | bhinesley | may be too tired to think straight |
| 05:26.33 | brlcad | you didn't misunderstand, that's not what I wrote -- but that would make sense |
| 05:26.41 | brlcad | I was thinking -k was completely meaningless with -a |
| 05:27.21 | brlcad | with the reasoning that if you translate to an absolute position (from ANY keypoint), you end up at that position |
| 05:27.56 | bhinesley | I see |
| 05:28.16 | brlcad | I get your idea too, rather different |
| 05:29.01 | brlcad | and from a utilitarian perspective, yours probably makes more sense since mine is achieved by simply dropping the -k |
| 05:30.21 | brlcad | whereas yours you can use to calculate |
| 05:31.50 | brlcad | basically "a - k = point" giving -20,-10,0 |
| 05:31.59 | bhinesley | right |
| 05:32.26 | brlcad | and "k + r = point" for relative |
| 05:33.35 | brlcad | ? |
| 05:33.39 | bhinesley | not exactly |
| 05:34.10 | bhinesley | r does movements relative to the current position |
| 05:34.21 | bhinesley | so a -r from any keypoint is the same |
| 05:37.24 | brlcad | if bowl.c is at 100,100,100, then I believe you're saying "translate -k 10 10 10 -a -10 0 10 bowl.c" puts it at 80,90,100 (calculated a -20,-10,0 vector) |
| 05:38.23 | bhinesley | correct |
| 05:38.34 | brlcad | if bowl.c is at 100,100,100, then "translate -k 10 10 10 -r -10 0 10 bowl.c" puts it at ... |
| 05:39.21 | bhinesley | -k is ignored; it's the same as "translate -r 10 0 10 bowl.c", so bowl.c is at 110,100,110 |
| 05:40.36 | brlcad | presuming you meant 90,100,110 ;) |
| 05:40.47 | bhinesley | yes |
| 05:40.56 | bhinesley | I have these fonts really small |
| 05:41.09 | bhinesley | missed the '-' |
| 05:41.20 | brlcad | that seems to defeat the meaning of a keypoint to me |
| 05:42.03 | bhinesley | I agree, that was just my understanding |
| 05:42.10 | bhinesley | I like what you said before |
| 05:42.21 | bhinesley | it's just a bit hard to understand |
| 05:42.44 | brlcad | translate -k bowl.c -r -10 0 10 bowl.c == translate -r -10 0 10 bowl.c |
| 05:42.54 | bhinesley | -r moves us to an absolute point, which is a relative distance away from the keypoint |
| 05:44.23 | brlcad | from that approach: translate -k bowl.c == translate -k 100 100 100, so tranlsate -k 100 100 100 -r -10 0 10 bowl.c => 90,100,110 make perfect sense |
| 05:44.48 | brlcad | but then it carries that translate -k 10 10 10 -r -10 0 10 bowl.c should not be the same |
| 05:46.17 | brlcad | k + r is consistent with both |
| 05:46.55 | bhinesley | ok |
| 05:47.02 | bhinesley | sounds good |
| 05:47.02 | brlcad | with the understanding that k is implicitly the object's position unless overridden |
| 05:48.22 | brlcad | keeps in line with your nice FROM TO setup |
| 05:48.37 | brlcad | the TO is wrt the FROM, not the object |
| 05:48.52 | brlcad | unless FROM isn't specified, then it's implicitly the object |
| 05:49.20 | brlcad | lesse, does that still hold for absolute too... |
| 05:49.21 | bhinesley | nice |
| 05:55.20 | brlcad | yeah, a bit to wrap the head around at this hour |
| 05:55.27 | brlcad | newpos = oldpos + rel = keypoint + rel .. pretty clear cut |
| 05:55.31 | bhinesley | haha, exactly |
| 05:56.03 | brlcad | my original was newpos = abs .. which is simple, but not too useful |
| 05:56.23 | brlcad | you made it derive a vector, to be applied to oldpos |
| 05:58.34 | brlcad | newpos = abs - keypoint = abs - oldpos = -10,0,10 - 100,100,100 = -110,100,110 .. that doesn't seem right |
| 05:59.47 | *** join/#brlcad Stattrav (~Stattrav@122.178.195.64) |
| 05:59.47 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) |
| 05:59.49 | brlcad | translate -a -10 0 10 bowl.c => -10,0,10 .. basically newpos = abs |
| 06:02.24 | brlcad | translate -k 10 10 10 -a -10 0 10 bowl.c => 100,100,100 + -20,-10,0 = 80,90,100 |
| 06:03.13 | bhinesley | correct |
| 06:03.50 | brlcad | the problem is consistency: translate -k 100 100 100 -a -10 0 10 bowl.c => ??? |
| 06:04.23 | brlcad | or maybe just not seeing the formulation correctly |
| 06:05.01 | brlcad | aha! |
| 06:05.23 | brlcad | 100,100,100 + -110,-100,-90 = -10,0,10 |
| 06:06.34 | brlcad | abs is not just "abs" .. it's abs' = abs - oldpos |
| 06:07.04 | brlcad | okay, cool .. that works |
| 06:07.49 | brlcad | the only other detail in the synopsis is the whole -c -o hullabaloo |
| 06:08.43 | bhinesley | well -o can go away, as you've shown |
| 06:08.55 | bhinesley | -k obj || -k -10 0 10 |
| 06:09.02 | brlcad | nods |
| 06:11.09 | brlcad | actually it's -c that disappeared |
| 06:11.38 | brlcad | or that could |
| 06:11.51 | bhinesley | the center of a primitive is 0,0,0? |
| 06:12.02 | brlcad | at least for arbitrary non-primitive obj, their "V" position is their bounding box center |
| 06:12.11 | bhinesley | oh. |
| 06:12.12 | brlcad | I wish |
| 06:12.32 | brlcad | each primitive defines their own "natural" origin |
| 06:12.44 | brlcad | for a box, it's one of the corners |
| 06:12.56 | brlcad | for a cylinder, it's the center of the bottom disc |
| 06:13.05 | brlcad | for a torus, it's the center |
| 06:13.10 | brlcad | etc |
| 06:13.30 | brlcad | it's undefined for combinations |
| 06:13.41 | brlcad | that's why OED makes you specify a path/to/primitive |
| 06:13.48 | bhinesley | right |
| 06:14.52 | brlcad | so we can define it to be the bb center for all combination objects |
| 06:15.08 | brlcad | that makes -k obj work for any object |
| 06:15.20 | brlcad | it's just whether to use that same center even for primitives or whether to use their V |
| 06:15.36 | brlcad | as a default at least |
| 06:15.45 | brlcad | and then an option to specify the other |
| 06:16.18 | brlcad | my inclination is default to center for everything |
| 06:17.51 | brlcad | translate [-n] [-k] [object | 3dpos] [-a | -r] 3dpos object(s) |
| 06:18.50 | brlcad | where 3dpos := [-x] {#|.} [-y] {#|.} [-z] {#|.} |
| 06:18.56 | bhinesley | yeah, I'd say that defaulting to center is more useful |
| 06:19.43 | brlcad | more precisely... |
| 06:22.06 | brlcad | translate [[-n] [-k {object | [-x] {#|.} [-y] {#|.} [-z] {#|.}}]] [-a|-r] [-x] {#|.} [-y] {#|.} [-z] {#|.} object(s) |
| 06:22.09 | brlcad | :) |
| 06:22.39 | bhinesley | don't we need another object in there somewhere |
| 06:23.14 | brlcad | oh that's right, you allowed the TO to be objects as well |
| 06:23.17 | brlcad | that's new to me ;) |
| 06:23.42 | bhinesley | very nice once you get the hang of it |
| 06:24.18 | bhinesley | say you have 3 wheels on a vehicle; you can copy one in place, and easily move it into position |
| 06:24.31 | bhinesley | ignoring z-axis |
| 06:24.41 | brlcad | translate [-n] [[-k] [object|3dpos]] [[-a|-r] [object|3dpos]] object(s) |
| 06:25.12 | bhinesley | great, that actually works ok for parsing too |
| 06:26.03 | bhinesley | I was worried about "translate -k obj -a obj2 obj3 obj4 obj5 at first |
| 06:26.04 | brlcad | probably actually end up needing [-n|-c] |
| 06:26.36 | bhinesley | how so |
| 06:26.36 | brlcad | and allowing it independently on the TO and the FROM |
| 06:26.49 | bhinesley | right |
| 06:27.17 | bhinesley | translate -c -k obj -n -a obj2 obj3 obj4 obj5 |
| 06:27.28 | brlcad | or at least need to respecify -n twice |
| 06:27.40 | bhinesley | even better |
| 06:28.07 | brlcad | so that it binds to the k|a|r options |
| 06:30.20 | brlcad | translate [[-n] [-k {object|3dpos}]] [[-n] -a|-r {object|3dpos}] object(s) |
| 06:30.41 | brlcad | not exact or useful synopsis syntax in that form... |
| 06:31.50 | brlcad | either way, really nice work there .. good brainstorming |
| 06:32.19 | bhinesley | thanks; it was a pleasure working with you |
| 06:33.18 | bhinesley | I should probably ask you: is it alright if I focus on just this oed stuff for my second milestone? |
| 06:33.30 | bhinesley | I have a feeling it will not all be done + another command |
| 06:33.50 | brlcad | absolutely |
| 06:33.58 | bhinesley | right on |
| 06:34.13 | brlcad | the milestones are completely insignificant if progress like this is being made ;) |
| 06:34.23 | bhinesley | excellent |
| 06:34.52 | bhinesley | sorry it's taken me like 3 weeks to do anything significant with this. I ran out of talent. |
| 06:35.10 | brlcad | was to be expected |
| 06:35.25 | brlcad | not a simple problem or we would have done it already |
| 06:37.07 | brlcad | easier to create yet another command that does some specific subset syntax and relies on a stupid oed selection state that is based around implementation detail keypoints insignificant to the modeler |
| 06:37.31 | brlcad | that's why this consolidates about a dozen commands into just three |
| 06:38.39 | brlcad | if you can recharacterize your writeup (which should be committed, btw, even as you work on it) after our talking, I'd jump over to scale and rotate to make sure the same syntax structure will work for them and make sense |
| 06:38.57 | brlcad | with angles and distances, rotate might be especially interesting |
| 06:39.22 | brlcad | degrees, radians |
| 06:39.30 | bhinesley | nods |
| 06:39.41 | bhinesley | I have it in translate.c right now, is that alright? |
| 06:39.51 | brlcad | oh sure, I missed it there |
| 06:40.00 | bhinesley | no, not commited |
| 06:40.10 | bhinesley | (yet) |
| 06:40.14 | brlcad | ah, okay |
| 06:40.24 | brlcad | was gonna say, it's not in my copy :) |
| 06:40.43 | bhinesley | hehe you need to do a 'svn up -r brandon's' |
| 06:41.55 | brlcad | if you get the urge to convert to actual docs, they live in doc/docbook/system/mann/en/ |
| 06:42.23 | brlcad | translate.xml would get added for the manpage, docbook xml format, lots of examples to follow |
| 06:42.48 | brlcad | goes walkabout |
| 06:43.02 | bhinesley | great, I was wondering how those were generated |
| 06:52.31 | CIA-62 | BRL-CAD: 03bhinesley * r45359 10/brlcad/trunk/src/libged/translate.c: Laid out a brand spankin new syntax for translate. It is already obsolete, per irc conversation with Sean. Many ged_translate/translate things are broken, but I'm too tired to go on, so it's commented out for now. |
| 07:15.43 | *** join/#brlcad Stattrav (~Stattrav@122.178.195.64) |
| 07:15.43 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) |
| 08:00.54 | *** join/#brlcad merzo (~merzo@193.254.217.44) |
| 08:25.20 | *** join/#brlcad Stattrav (~Stattrav@122.178.195.64) |
| 08:25.20 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) |
| 10:34.49 | *** part/#brlcad kunigami1 (~kunigami@loco-gw.ic.unicamp.br) |
| 10:36.45 | *** join/#brlcad kunigami (~kunigami@loco-gw.ic.unicamp.br) |
| 11:07.15 | CIA-62 | BRL-CAD: 03kunigami * r45360 10/brlcad/trunk/src/liboptical/ (liboslrend.h osl_rt.cpp): removing unused variables |
| 11:21.32 | kunigami | May I add an option to rt that reads the number of samples that will be made for each pixel? |
| 11:22.23 | kunigami | If yes, it's better to do it through rt script language, right? |
| 11:26.14 | kunigami | It would also be great if I could implement that kind of framebuffer that begins noisy and gains shape as more and more samples are done (but this would require to change the way rays are shot by rt) |
| 11:44.06 | starseeker | epileg: is that produced with the make package command? |
| 11:44.32 | epileg | yes, both |
| 11:45.19 | epileg | starseeker: mmmm, do You mean the binary or the shared libs list? |
| 11:50.58 | starseeker | epileg: well, basically that list looks like it's from untarring one of the tarballs (binary) built by make package |
| 11:51.23 | starseeker | which would be really annoying - I thought I had all that path stuff straightened out |
| 11:52.46 | epileg | starseeker: yes, htey are |
| 11:53.08 | starseeker | there will be a few things present in a CMake build that aren't in an autotools build, since the CMake build has some new stuff |
| 11:53.27 | starseeker | more disturbing is the /home/jordi/svn/brlcad_7.20.1-0_amd64-2/usr/brlcad/bin path |
| 11:54.15 | starseeker | I'm trying a make package here |
| 11:54.15 | epileg | starseeker: no no, forget this. I just created two deb packages and uncompress them |
| 11:54.23 | starseeker | Oh! |
| 11:54.37 | starseeker | the CMake package build for debs is completely untested |
| 11:54.42 | epileg | one with autotools and another with cmake |
| 11:55.13 | starseeker | well, for one thing the CMake build turns on OpenGL by default, while the autotools still has it off by default |
| 11:55.22 | epileg | well, I have done the autotools deb packages script |
| 11:55.25 | starseeker | that's probably where the libGLU is coming from |
| 11:55.56 | epileg | aha |
| 11:56.08 | starseeker | epileg: I need to look over the logic you've done for that and make sure the CMake build incorporates what is needed to reproduce it |
| 11:56.22 | epileg | ok |
| 11:56.27 | starseeker | I can't test deb except on a virtual machine though, so I'm not set up for it yet |
| 11:56.37 | epileg | I'll give You exactly what I've done |
| 11:57.02 | starseeker | for the tcl/tk stuff... at a glance it looks like the CMake build had enabled all local libs and the autotools build didn't |
| 11:57.41 | starseeker | libpoints is just how CMake is building the MGED points logic, so that's not surprising |
| 11:57.43 | epileg | but there are more libs in autotools packages than in cmake one |
| 11:58.09 | starseeker | wait - is the list I'm looking at autotools things that hte CMake build Doesn't have? |
| 11:58.40 | epileg | ok |
| 11:59.13 | epileg | about testing, don't worry, I've ready many virtual machines to test them |
| 12:00.20 | starseeker | bhinesley: getting this error: src/libged/translate.c:49: error: âtranslateâ defined but not used |
| 12:01.28 | starseeker | no worries, but may want to #if it out in the repository until you progress to the point where it's used by something |
| 12:02.00 | epileg | starseeker: in the autotools package, there are 747 elements, 69,9 MB, and in cmake package 671 elements, 46,3 MB |
| 12:02.13 | starseeker | erm. |
| 12:02.14 | epileg | in lib folder |
| 12:03.26 | epileg | in came i used: |
| 12:03.26 | epileg | cmake -DBRLCAD-ENABLE_OPTIMIZED_BUILD=ON \ |
| 12:03.26 | epileg | -DBRLCAD-ENABLE_ALL_LOCAL_LIBS=ON \ |
| 12:03.26 | epileg | -DBRLCAD-ENABLE_STRICT=OFF \ |
| 12:03.26 | epileg | -DCMAKE_BUILD_TYPE=Release \ |
| 12:03.27 | epileg | -DCMAKE_INSTALL_PREFIX=/usr/brlcad \ |
| 12:03.27 | epileg | -DDATA_DIR=share \ |
| 12:03.28 | epileg | -DMAN_DIR=share/man |
| 12:04.04 | epileg | cmake* |
| 12:05.15 | starseeker | ok |
| 12:05.49 | starseeker | epileg: for each of the two package directories (autotools and cmake) can you do the following? |
| 12:06.12 | epileg | and in autotools: |
| 12:06.12 | epileg | ./configure --enable-optimized --enable-almost-everything --with-ogl --disable-debug -disable-strict -prefix=/usr/brlcad |
| 12:06.25 | epileg | yes, tell me |
| 12:06.28 | starseeker | find . -type f |grep -v .svn|xargs stat --format='%n' > autotools.list |
| 12:06.34 | starseeker | find . -type f |grep -v .svn|xargs stat --format='%n%s' > autotools_size.list |
| 12:06.40 | starseeker | and the same for cmake |
| 12:06.46 | epileg | ok |
| 12:06.59 | starseeker | those four files will provide a way to compare what is ending up in the two package dirs |
| 12:07.11 | epileg | in the root package folder, right? |
| 12:07.15 | starseeker | yes |
| 12:07.21 | epileg | just a secont |
| 12:11.21 | epileg | starseeker: some email to send or paste on a web page? |
| 12:13.24 | starseeker | http://paste.debian.net should work |
| 12:13.29 | epileg | ok |
| 12:14.24 | epileg | ...Length of code is not allowed to exceed 90kb... |
| 12:14.30 | starseeker | phooey |
| 12:14.45 | starseeker | i'll pm you an email addy |
| 12:17.51 | *** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ) |
| 12:35.35 | epileg | starseeker: did You receive it? |
| 12:37.44 | epileg | starseeker: just one thing. as You can see, at the end of cmake.list and cmake_size.list, there is ./autotools_size.list and ./autotools.list instead of the cmake... filenames |
| 12:38.15 | epileg | this is because i've changed the filenames after run the command, sorry |
| 12:52.51 | starseeker | epileg: I'll check in a bit - dealing with multiple things at the moment |
| 12:52.59 | starseeker | (shredder broke, vacuum broke...) |
| 12:53.05 | epileg | ok, no problem |
| 12:53.31 | starseeker | np - I can spot the autotools.list filesw |
| 12:58.58 | CIA-62 | BRL-CAD: 03kunigami * r45361 10/brlcad/trunk/src/liboptical/ (osl_rt.cpp sh_osl.cpp): Still having problems rendering glass material. I've tried even calling OSL QueryColor directly (without mfuncs), but still no success |
| 14:10.52 | brlcad | kunigami: rt has a -H hypersample option already |
| 14:41.09 | brlcad | that used in conjunction with -s oversizing then downsampling are a common best-practice for producing smoothly anti-aliased images |
| 14:42.01 | brlcad | on that same note, there is a -j jitter flag that will modify the starting ray hit point in various ways depending on the jitter value |
| 15:05.39 | CIA-62 | BRL-CAD: 03starseeker * r45362 10/brlcad/trunk/doc/html/CMakeLists.txt: fix target directory for animmate |
| 15:09.14 | CIA-62 | BRL-CAD: 03starseeker * r45363 10/brlcad/trunk/src/util/CMakeLists.txt: pc_test isn't supposed to be installed. |
| 15:12.19 | starseeker | epileg: the CMake zlib build isn't installing the private zlib headers, while the autotools build is - unless we need to install them, I'm inclined to go with the CMake behavior |
| 15:13.14 | starseeker | epileg: the CMake build won't have the .la files that the autotools build has - that's expected |
| 15:13.41 | starseeker | some differences with library naming for itcl/itk, looks like... that shouldn't matter |
| 15:15.01 | epileg | starseeker: I'll be agree with any decision You take |
| 15:15.27 | starseeker | tcl/tkConfig.sh scripts aren't there yet for the CMake build of Tcl/Tk |
| 15:15.41 | starseeker | epileg: do the packages generated actually work when installed? |
| 15:15.55 | epileg | yes |
| 15:16.40 | epileg | just the rtwizard do not properly render, both cmake and autotools builds |
| 15:17.29 | starseeker | what's the issue with rtwizard? |
| 15:17.50 | starseeker | epileg: hmm, looks like I haven't gotten around to doing the man pages for iwidgets yet... |
| 15:19.07 | epileg | starseeker: do You remember the difference between cmake and autotools about text rendering? it's still there |
| 15:20.36 | epileg | error message from rtwizard |
| 15:20.39 | epileg | http://paste.debian.net/121606/ |
| 15:22.06 | starseeker | oh, I see - autotools build prefixed all of hte man pages before installing them |
| 15:22.35 | starseeker | epileg: is rt in your path? |
| 15:23.03 | epileg | nop |
| 15:23.33 | epileg | but rt is not provided by brlcad? |
| 15:26.31 | epileg | sorry, something wrong in my system |
| 15:32.33 | CIA-62 | BRL-CAD: 03starseeker * r45364 10/brlcad/trunk/src/other/iwidgets/ (CMakeLists.txt doc/CMakeLists.txt): Take care of iwidgets man pages. |
| 15:33.02 | starseeker | other major difference I see is CMake is installing Tcl/Tk man pages, where it looks like autotools isn't |
| 15:33.15 | epileg | aha |
| 15:34.34 | starseeker | somewhat surprisingly, autotools didn't build step-g? |
| 15:43.41 | *** join/#brlcad epileg (~epileg@unaffiliated/epileg) |
| 15:44.21 | epileg | starseeker: so sorry, rtwizard properly works. It was a problem on my environment variables |
| 15:45.13 | starseeker | np |
| 15:45.29 | starseeker | just glad it wasn't busted yet again :-P |
| 15:46.06 | epileg | :-) |
| 16:42.38 | *** join/#brlcad Elrohir (~kvirc@pD95EDF28.dip.t-dialin.net) |
| 17:00.40 | CIA-62 | BRL-CAD: 03bhinesley * r45365 10/brlcad/trunk/src/libged/translate.c: don't leave private translate function definition enabled if it's not used |
| 17:00.42 | bhinesley | starseeker: hah, yeah, I was lying in bed last night thinking "really should have just commented out that whole private function" |
| 17:17.28 | bhinesley | heh *laying |
| 18:37.22 | brlcad | prefixed the man pages? |
| 18:38.53 | *** topic/#brlcad by brlcad -> BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD release 7.20.2 being tagged today (20110701) || BRL-CAD has applied to participate in the ESA Summer of Code in Space! |
| 18:42.36 | CIA-62 | BRL-CAD: 03brlcad * r45366 10/brlcad/trunk/bench/Makefile.am: try without defining DISTCLEANFILES |
| 18:42.54 | brlcad | I see why the distcheck was still failing, missed committing a file a few days ago |
| 18:44.57 | CIA-62 | BRL-CAD: 03starseeker * r45367 10/brlcad/trunk/src/other/iwidgets/doc/Makefile.am: Add CMakeLists.txt file. |
| 18:59.50 | CIA-62 | BRL-CAD: 03kunigami * r45368 10/brlcad/trunk/src/liboptical/sh_osl.cpp: |
| 18:59.50 | CIA-62 | BRL-CAD: solved the glass shader. the problem was that the next application was set by |
| 18:59.50 | CIA-62 | BRL-CAD: next.a_hit = prev.a_hit, but if prev.a_hit was the refraction callback, |
| 18:59.50 | CIA-62 | BRL-CAD: next.a_hit would be also refraction. the expected behavior is to set mext.a_hit |
| 18:59.50 | CIA-62 | BRL-CAD: as the first callback (the one that was used by the first ray |
| 19:05.17 | CIA-62 | BRL-CAD: 03Kunigami 07http://brlcad.org * r2978 10/wiki/User:Kunigami/GSoc2011/Reports: /* Week 6 */ Reports updated |
| 19:10.23 | CIA-62 | BRL-CAD: 03starseeker * r45369 10/brlcad/trunk/NEWS: Richard improved facetization by updating routines to merge coplanar faces. |
| 19:11.58 | CIA-62 | BRL-CAD: 03starseeker * r45370 10/brlcad/trunk/include/conf/PATCH: Bump patch version number. |
| 19:14.53 | CIA-62 | BRL-CAD: 03starseeker * r45371 10/brlcad/trunk/ChangeLog: Update ChangeLog |
| 19:23.52 | *** join/#brlcad merzo (~merzo@94-20-133-95.pool.ukrtel.net) |
| 19:34.06 | CIA-62 | BRL-CAD: 03Kunigami 07http://brlcad.org * r2979 10/wiki/User:Kunigami/GSoc2011/Reports: /* Week 6 */ |
| 19:49.53 | CIA-62 | BRL-CAD: 03kunigami * r45372 10/brlcad/trunk/src/liboptical/sh_osl.cpp: instead of calling OSLQueryColor directly (with the hardcoded name glass), call mf_render. this is better because the refracted ray may not be inside a shader named glass |
| 19:52.53 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) |
| 20:04.12 | brlcad | kunigami: so lets see it! |
| 20:05.34 | brlcad | aha, http://dl.dropbox.com/u/1399996/GSoC/OSL_RT-Refraction-Corrected-2011-06-30.png |
| 20:06.34 | brlcad | kunigami: what glass parameters are you using? refraction index, specular and diffuse params, etc |
| 20:06.55 | CIA-62 | BRL-CAD: 03starseeker * r45373 10/brlcad/branches/STABLE/ (2197 files in 194 dirs): Sync STABLE to trunk r45358 |
| 20:08.49 | starseeker | woot |
| 20:10.57 | CIA-62 | BRL-CAD: 03starseeker * r45374 10/brlcad/branches/STABLE/ (17 files in 12 dirs): Sync STABLE to trunk r45373 |
| 20:11.28 | brlcad | thinks you meant trunk TO stable |
| 20:11.57 | brlcad | :) |
| 20:14.32 | starseeker | er, yeah |
| 20:14.44 | bhinesley | either way is good ;-) |
| 20:14.58 | starseeker | prepares to tag... drumroll please... |
| 20:15.34 | starseeker | double checks the release numbers this time... |
| 20:15.57 | brlcad | and mged acutally runs along with archer :) |
| 20:30.29 | starseeker | yep, they run |
| 20:30.40 | starseeker | here we go |
| 20:31.18 | CIA-62 | BRL-CAD: 03starseeker * r45375 10/brlcad/tags/rel-7-20-2/: Tag release 7.20.2 |
| 20:37.08 | kunigami | brlcad: reading the osl glass shader, it seems that the index of refraction is 1.5 |
| 20:39.14 | kunigami | I don't know the specular and diffuse parameters. would have to take a look at implementation |
| 20:40.08 | kunigami | The shader description: http://pastebin.mozilla.org/1262389 |
| 20:43.54 | kunigami | Scene with a BRLCAD shader (checkers) and a OSL shader (mirror). The way it is implemented, BRLCAD shaders will act as lights. |
| 20:43.57 | kunigami | http://dl.dropbox.com/u/1399996/GSoC/OSL-BRLCAD-Shader-Integration.png |
| 20:52.04 | brlcad | awesome starseeker |
| 20:57.14 | starseeker | tarballs up |
| 20:58.57 | CIA-62 | BRL-CAD: 03starseeker * r45376 10/brlcad/trunk/ (NEWS README include/conf/PATCH): Bump revision numbers. |
| 21:14.46 | brlcad | hm, rt inside mged is blocking |
| 21:23.58 | brlcad | here's what that scene looks like with rt: http://tinypic.com/view.php?pic=9kufk1&s=7 |
| 21:24.31 | brlcad | and as checker: http://tinypic.com/view.php?pic=i3hzjk&s=7 |
| 21:36.17 | CIA-62 | BRL-CAD: 03brlcad * r45377 10/brlcad/trunk/src/librt/primitives/nmg/nmg_fuse.c: gah, post-ta build failure! code is used unitialized. remove it... |
| 21:51.15 | CIA-62 | BRL-CAD: 03brlcad * r45378 10/brlcad/branches/STABLE/src/librt/primitives/nmg/nmg_fuse.c: merge r45377 from trunk to stable |
| 22:15.23 | CIA-62 | BRL-CAD: 03Sean 07http://brlcad.org * r2980 10/wiki/Main_Page: link to socis |
| 22:33.35 | *** join/#brlcad louipc (~louipc@archlinux/trusteduser/louipc) |
| 22:57.43 | CIA-62 | BRL-CAD: 03Sean 07http://brlcad.org * r2981 10/wiki/ESA_Summer_of_Code_in_Space/Project_Ideas: eliminate some ideas only loosely relevant to space work |
| 22:59.00 | CIA-62 | BRL-CAD: 03brlcad * r45379 10/brlcad/tags/rel-7-20-2/src/librt/primitives/nmg/nmg_fuse.c: source tarballs were posted but not announced, so merge r45377 from trunk to stable so we can regenerate them |
| 23:18.26 | starseeker | brlcad: O.o Sorry - what happened? |
| 23:20.23 | starseeker | bites back cuss words - how in the *bleep* did I get all those successful builds and then have a build failure?? |
| 23:21.16 | starseeker | the tarballs came out of a tagged distcheck build |
| 23:23.39 | starseeker | deletes source tarballs, regens |
| 23:44.14 | CIA-62 | BRL-CAD: 03Sean 07http://brlcad.org * r2982 10/wiki/ESA_Summer_of_Code_in_Space/Project_Ideas: |
| 23:46.17 | CIA-62 | BRL-CAD: 03Sean 07http://brlcad.org * r2983 10/wiki/ESA_Summer_of_Code_in_Space/Project_Ideas: reorder |
| 23:54.05 | brlcad | starseeker: did you compile optimized? |
| 23:54.14 | brlcad | optimized often enables even more warnings |
| 23:55.37 | brlcad | that's part of my compile script -- all+warn, all+opt+warn, all+32bit+warn, default+warn, default+opt+warn, .... etc etc :) |
| 23:55.55 | starseeker | hrm. No, I think I used the line in HACKING |
| 23:56.34 | brlcad | yeah, you did it right .. just slipped through |
| 23:57.11 | brlcad | release binaries aren't supposed to be optimized anyways (so they can be debugged) |
| 23:57.58 | brlcad | and some platforms don't behave well with optimized, so several reasons why it isn't in HACKING |
| 23:58.53 | brlcad | looks like my build script tests 13 build configurations testing make, make distcheck, and make test for all 13 ... :) |
| 23:59.36 | CIA-62 | BRL-CAD: 03bhinesley * r45380 10/brlcad/trunk/ (6 files in 4 dirs): |
| 23:59.36 | CIA-62 | BRL-CAD: Started rearranging things, to put translate/rotate/scale syntax handling in one |
| 23:59.36 | CIA-62 | BRL-CAD: place. Re-wrote proposed 'translate' manual per conversation with Sean. There |
| 23:59.36 | CIA-62 | BRL-CAD: were a couple more issues resolved and ideas added along the way. Next step is |
| 23:59.36 | CIA-62 | BRL-CAD: to ensure that rotate/scale will work alright with the same syntax. |
