| 00:47.07 | *** join/#brlcad crazy_imp (~mj@a89-182-123-98.net-htp.de) |
| 01:26.50 | *** part/#brlcad milamber (~devlin@d118-75-70-176.try.wideopenwest.com) |
| 04:15.18 | CIA-62 | BRL-CAD: 03brlcad * r45320 10/brlcad/trunk/src/libged/concat.c: reorder to remove forward decls, remove misleading ged_ prefix from static functions |
| 04:27.16 | CIA-62 | BRL-CAD: 03brlcad * r45321 10/brlcad/trunk/src/libged/draw.c: reorder to remove forward decls, remove misleading ged_ prefix from static functions |
| 04:38.02 | CIA-62 | BRL-CAD: 03brlcad * r45322 10/brlcad/trunk/src/libged/ (9 files): even more reordering to remove forward decls, remove misleading ged_ prefix from static functions |
| 05:02.36 | CIA-62 | BRL-CAD: 03bhinesley * r45323 10/brlcad/trunk/src/libged/translate.c: added support for translating 'only a particular instance' of an object (like 'oed obj1.c obj2.c/kp.s') |
| 05:05.37 | bhinesley | really feeling like I understand what needs to happen now. The rest should be muuuch faster :) |
| 05:06.10 | bhinesley | took every neuron in my central nervous system to figure it out, though |
| 05:08.19 | bhinesley | yawns |
| 05:24.32 | CIA-62 | BRL-CAD: 03bhinesley * r45324 10/brlcad/trunk/src/libged/translate.c: Enable support for 'instance only' and 'all instances' translation of primitives. The main things left to do, are: enabling support for absolute/keypoint positioning and accepting multiple object arguments. |
| 05:28.38 | CIA-62 | BRL-CAD: 0399.125.86.110 07http://brlcad.org * r2975 10/wiki/User:Bhinesley: /* Log */ today |
| 05:29.54 | CIA-62 | BRL-CAD: 03brlcad * r45325 10/brlcad/trunk/src/libged/ (20 files): remainder of reordering to remove forward decls and removal of misleading ged_ prefix from static non-public api functions |
| 05:31.17 | brlcad | bhinesley: haha, outstanding :) |
| 05:33.17 | brlcad | you got/get how the current way oed behaves is to use the natural (aka arbitrary coded keypoint) coordinate system origin of a specified primitive as the origin to use for a keypoint? |
| 05:34.49 | bhinesley | I get what you're saying |
| 05:37.03 | bhinesley | should the 'new' way allow the user to specify any coordinate as well as any object's origin? |
| 05:37.28 | brlcad | ideally, yeah |
| 05:37.46 | bhinesley | anything else? |
| 05:40.57 | brlcad | three use cases that come to mind are an arbitrary xyz, a 'natural' origin keypoint akin to what oed does now, and a 'default' origin on an object's minimum bounding box center |
| 05:41.51 | brlcad | there isn't presently a routine to get the third one at the moment, but that's probably the ideal default |
| 05:42.28 | brlcad | for now it can just be the AABB center or stubbed into the command-line api but unimplemented |
| 05:43.00 | bhinesley | ok |
| 05:43.01 | brlcad | need some syntax to differentiate an object name refering to the natural vs centered keybpoint |
| 05:43.56 | bhinesley | could just use different switches (-n -c) |
| 05:44.06 | brlcad | sure |
| 06:44.04 | *** join/#brlcad Stattrav (~Stattrav@122.178.252.52) |
| 06:44.04 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) |
| 07:28.21 | *** join/#brlcad Stattrav (~Stattrav@122.178.211.204) |
| 07:28.21 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) |
| 07:46.23 | *** join/#brlcad merzo (~merzo@193.254.217.44) |
| 10:54.45 | *** join/#brlcad kunigami (~kunigami@loco-gw.ic.unicamp.br) |
| 11:09.01 | CIA-62 | BRL-CAD: 03brlcad * r45326 10/brlcad/trunk/src/libged/ged.c: yet another tweak that 'should be safe' but might not be. release the ged_gdp that we allocated during init. assume that init isn't being called on something already initialized too. |
| 11:52.08 | *** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ) |
| 12:24.23 | CIA-62 | BRL-CAD: 03brlcad * r45327 10/brlcad/trunk/ (259 files in 7 dirs): |
| 12:24.23 | CIA-62 | BRL-CAD: change ged_log an ged_result_str from being directly embedded bu_vls structs to |
| 12:24.23 | CIA-62 | BRL-CAD: being pointers. this makes the struct smaller but more importantly lets us |
| 12:24.23 | CIA-62 | BRL-CAD: manage memory and initialization more easily. sure, the pointer might now be |
| 12:24.23 | CIA-62 | BRL-CAD: null, but that'll be wrapped soon anyways (and can be validated). happens to |
| 12:24.24 | CIA-62 | BRL-CAD: save a lot of '&' typing too. ;) |
| 12:32.44 | brlcad | starseeker: do you happen to have a set of already-rendered nifty NURBS images handy? |
| 12:33.12 | brlcad | ideally showcasing relatively simple objects that would be rather complicated to implement as CSG |
| 12:33.47 | brlcad | I know there's the phone images, any others? |
| 12:35.40 | brlcad | ideally something that doesn't require release approval, looking to publish an overview of step on the wiki and mailing list really soon |
| 12:36.27 | CIA-62 | BRL-CAD: 03brlcad * r45328 10/brlcad/trunk/src/bwish/ (cadAppInit.c main.c): not calling ged_init() |
| 12:37.07 | *** join/#brlcad epileg (~epileg@unaffiliated/epileg) |
| 12:38.47 | CIA-62 | BRL-CAD: 03brlcad * r45329 10/brlcad/trunk/src/libged/ged.c: have to bu_free() the gedp itself now since ged_free() releases the internal memory (so it can still release memory for ged structs on the stack) |
| 12:58.29 | CIA-62 | BRL-CAD: 03brlcad * r45330 10/brlcad/trunk/src/libged/ged.c: |
| 12:58.29 | CIA-62 | BRL-CAD: fix compile, missed commit. don't free the gedp itself during ged_free() so we |
| 12:58.29 | CIA-62 | BRL-CAD: can still pass static struct ged entities and have their memory allocations |
| 12:58.29 | CIA-62 | BRL-CAD: released. this matches with other bu structs and their respective free |
| 12:58.29 | CIA-62 | BRL-CAD: functions (e.g. bu_vls_free()). |
| 13:00.24 | epileg | I'm using -DBRLCAD_INSTALL_DATA_DIR= and -DDDATA_DIR= to set share folder, but without success. How can I properly set it? |
| 13:00.49 | CIA-62 | BRL-CAD: 03brlcad * r45331 10/brlcad/trunk/src/shapes/ (human.c tire.c): we can now call ged_free() so we're not leaking memory (albeit during exit) |
| 13:08.49 | brlcad | is DDDATA_DIR a typo? |
| 13:09.42 | CIA-62 | BRL-CAD: 03brlcad * r45332 10/brlcad/trunk/src/ (libged/wdb_obj.c mged/mged.c mged/setup.c): plug various ged memory leakages. if we fail, reset back to null. |
| 13:10.21 | epileg | brlcad: is as starseeker typed |
| 13:11.06 | brlcad | looks like one too many D's to me |
| 13:11.52 | epileg | ok, i'll try removing a D |
| 13:15.53 | brlcad | starseeker: cmake --help-variable-list and all the other various --help-* commands seem to be somewhat useless ... can all the various BRL-CAD vars get added to a BRLCAD module? |
| 13:17.03 | brlcad | epileg: I do see that CMAKE_INSTALL_PREFIX is the equivalent of ./configure --prefix= |
| 13:18.05 | epileg | yes, i know. what 's BRLCAD_PREFIX? |
| 13:19.00 | brlcad | presumably the same thing, where do you see that? |
| 13:19.58 | epileg | I' see it with "cmake-gui" |
| 13:20.05 | brlcad | starseeker: also, INSTALL.cmake looks like it's incomplete? still has all the configure options, no itemized cmake build options |
| 13:21.52 | brlcad | epileg: ah, yeah -- the CMakeLists file says it's also the install prefix, an advanced option of some sort |
| 13:22.26 | brlcad | it's set to CMAKE_INSTALL_PREFIX, so perhaps just an internal variable |
| 13:23.15 | epileg | brlcad: ok, thanks. removing a D for share folder properly worked! |
| 13:24.00 | brlcad | form is -D VAR=VAL |
| 13:24.13 | brlcad | so it was suspicious that there'd be a DDATA_DIR var |
| 13:24.20 | epileg | aha |
| 13:25.21 | brlcad | from my reading of the usage, the space is even optional so it'd probably be more clear to put the space in our docs |
| 13:25.25 | ``Erik | BRLCAD_PREFIX is something starseeker added to prevent using old installed BRL-CAD libs to link during build, should be marked as advanced |
| 13:26.06 | ``Erik | CMAKE_INSTALL_PREFIX is the one you want to use |
| 13:27.28 | epileg | Thanks brlcad ``Erik |
| 13:27.30 | CIA-62 | BRL-CAD: 03starseeker * r45333 10/brlcad/trunk/CMakeLists.txt: Readibility improvement. |
| 13:27.46 | epileg | now I only need text to properly rendering. Is there a way to do that in cmake? |
| 13:30.56 | kunigami | I made a scene consisting of a sphere with center (0,0,0) and radius 1 and shot a ray from (-10, 0, 0) with direction (1, 0, 0) |
| 13:31.51 | kunigami | when I call the first rt_shootray it returns (-1, 0, 0) as the hit point (OK). OSL code returns the direction (1, 0, 0) (OK) |
| 13:32.45 | kunigami | then I forward the hit point a little bit to (-0.9999, 0, 0) and shoot a new ray from there with direction (1, 0, 0). rt_shootray returns (-0.9999, 0, 0) as the hit point |
| 13:34.01 | kunigami | I'll send this information to the mail list as suggested. I'm probably not setting something right before calling rt_shootray the second time |
| 13:56.45 | d_rossberg | kunigami: (-0.9999, 0, 0) is OK but you are probable interested in the pt_outhit |
| 14:35.38 | starseeker | brlcad: seeing a crash: http://pastebin.mozilla.org/1261320 |
| 14:35.55 | starseeker | brlcad: urm. NURBS images... probably just the phone image handy |
| 14:36.30 | starseeker | http://bzflag.bz/~starseeker/phone_large.png |
| 14:40.59 | starseeker | let me see if I can get an openbook image rendered |
| 14:44.49 | starseeker | http://bzflag.bz/~starseeker/openbook_d2.png |
| 14:53.45 | starseeker | brlcad: um... the cmake help commands are help for cmake developers, not about a particular project |
| 14:55.16 | starseeker | INSTALL.cmake was/is a work in progress. I haven't pushed to finish it up yet |
| 14:55.58 | starseeker | I didn't figure we would be pushing the CMake build as primary until after this release, so I wasn't worried about it yet. |
| 14:59.40 | *** join/#brlcad Ralith_ (~ralith@S010600221561996a.vc.shawcable.net) |
| 15:00.44 | *** part/#brlcad Ralith_ (~ralith@S010600221561996a.vc.shawcable.net) |
| 15:05.07 | brlcad | kunigami: ah, probably because you're inside an object, so it's instantly a hit. since you know you're a refraction ray, you may want to set onehit to false and skip the first partition |
| 15:05.47 | brlcad | otherwise, you have no idea how far forward you'll need to nudge forward to get past that object |
| 15:06.21 | brlcad | ah, or what d_rossberg said :) |
| 15:07.02 | kunigami | :) I'm implementing that. For a render with few samples it seems to have worked. Checking with more samples now |
| 15:07.41 | brlcad | starseeker: yeah, looking for something better than those |
| 15:07.57 | brlcad | phone_large is interesting, but isn't "nurbs-compelling" |
| 15:08.14 | brlcad | openbook_d2 is "nurbs-compelling", but just not very interesting |
| 15:08.49 | starseeker | brlcad: yeah, then I don't have anything handy |
| 15:09.17 | brlcad | evan a simple closed surface deformed to all hell wibbly wobbly would probably work, but a real object would be better |
| 15:09.19 | starseeker | sorry :-/ |
| 15:10.03 | starseeker | are you seeing that bomb issue with ged_init? |
| 15:10.28 | brlcad | looking at that now |
| 15:10.46 | brlcad | everyone should see it given that report |
| 15:11.04 | brlcad | didn't you read it? :) |
| 15:11.28 | starseeker | I did - but figured you'd probably tested the recent commits, so I thought perhaps there was another uncommitted file or some such |
| 15:13.06 | brlcad | tested, but apparently not code that exercised ged_init() |
| 15:13.52 | CIA-62 | BRL-CAD: 03brlcad * r45334 10/brlcad/trunk/src/libged/ged.c: have to allocate memory now before init can occur since they're just pointers |
| 15:19.22 | starseeker | yep, that's got it - thanks |
| 15:33.03 | *** join/#brlcad Stattrav (~Stattrav@117.192.146.37) |
| 15:33.03 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) |
| 16:15.46 | starseeker | kunigami: might want to update the Makefile.am in liboptical |
| 16:16.01 | kunigami | ouch, I always forget |
| 16:17.23 | starseeker | brlcad: I doubt it's "nurbsy" enough, but here's a rendering of the bugbase model: http://bzflag.bz/~starseeker/bugbase.png |
| 16:19.42 | CIA-62 | BRL-CAD: 03kunigami * r45335 10/brlcad/trunk/src/liboptical/Makefile.am: changed osl-renderer to liboslrend in Makefile.am |
| 16:20.20 | brlcad | better, but similarly kind of bland |
| 16:21.01 | starseeker | kunigami: thanks |
| 16:30.07 | kunigami | http://dl.dropbox.com/u/1399996/GSoC/OSL_RT-2011-06-30.png |
| 16:30.31 | kunigami | The light is a bit too strong, but I think the glass is being rendered right now. |
| 16:32.23 | starseeker | kunigami: nice! |
| 16:50.14 | *** join/#brlcad dtidrow (~dtidrow@c-68-84-167-135.hsd1.mi.comcast.net) |
| 16:52.21 | starseeker | brlcad: hmm - still getting complaints about leftover files from distcheck in the bench directory: http://pastebin.mozilla.org/1261343 |
| 16:53.40 | brlcad | kunigami: awesome .. curious interaction on the ground but not yet clear whether it's "right" or not |
| 16:53.44 | brlcad | definitely better though |
| 16:54.49 | brlcad | one thing I remembered to ask you about... are you running through rt or is this through that osl front-end tracer set up to shoot librt rays? |
| 16:55.42 | brlcad | reason I ask, the image looks flipped |
| 16:56.06 | kunigami | I'm running from the second one. My next step is to port is to rt so that I can try to integrate with BRL-CAD shaders |
| 17:01.38 | CIA-62 | BRL-CAD: 03brlcad * r45336 10/brlcad/trunk/bench/Makefile.am: try making these 'local' overrides since something is apparently stopping regular generated files from getting cleaned up during distcheck. |
| 17:01.40 | brlcad | yeah, getting that same output, even without any other brl-cad shaders, via rt would be good |
| 17:02.41 | brlcad | and gets closer towards answering those outstanding questions I had regarding how secondary rays are going to play with arbirary osl shaders |
| 17:06.13 | CIA-62 | BRL-CAD: 03brlcad * r45337 10/brlcad/trunk/TODO: mater command bustage?? |
| 17:28.11 | CIA-62 | BRL-CAD: 03kunigami * r45338 10/brlcad/trunk/src/liboptical/ (CMakeLists.txt Makefile.am osl_rt.cpp): added suport for refraction to osl_rt. Also added it no Makefile.am |
| 17:28.24 | kunigami | *to |
| 17:36.00 | CIA-62 | BRL-CAD: 03brlcad * r45339 10/brlcad/trunk/include/bu.h: add some assertions and protections to the bu_list insertion/dequeue macros. make them not dereference null or at least assert gracefully so we don't crash. |
| 17:39.10 | CIA-62 | BRL-CAD: 03brlcad * r45340 10/brlcad/trunk/ (NEWS src/liboptical/sh_light.c): |
| 17:39.10 | CIA-62 | BRL-CAD: encountered a crash during raytrace rendering a scene that had just one light |
| 17:39.10 | CIA-62 | BRL-CAD: with an invalid parameter specification. structparse failed causing |
| 17:39.10 | CIA-62 | BRL-CAD: light_free() to be called, which crashed on the light list (that had none added |
| 17:39.10 | CIA-62 | BRL-CAD: yet). fixed the bug on both ends, making the list dequeue safe and initializing |
| 17:39.11 | CIA-62 | BRL-CAD: the list properly. |
| 17:46.06 | *** join/#brlcad yukonbob (~bch@S0106002191d1591c.ok.shawcable.net) |
| 18:14.52 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) |
| 18:47.49 | CIA-62 | BRL-CAD: 03kunigami * r45341 10/brlcad/trunk/src/liboptical/ (osl_rt.cpp sh_osl.cpp): rt now correctly renders reflection |
| 18:48.41 | kunigami | For refraction, I'll probably have to create a new callback in the fashion of rr_render |
| 19:04.06 | *** join/#brlcad Stattrav (~Stattrav@117.192.146.37) |
| 19:04.06 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) |
| 19:41.19 | CIA-62 | BRL-CAD: 03starseeker * r45342 10/brlcad/trunk/ (NEWS TODO src/libged/mater.c): |
| 19:41.19 | CIA-62 | BRL-CAD: Fix a bug in the mater command - wasn't respecting the attribute syncing needed |
| 19:41.19 | CIA-62 | BRL-CAD: for the new system. Ultimately this should be rewritten to just act on |
| 19:41.19 | CIA-62 | BRL-CAD: attributes and not the comb structure, but that's a bit more extensive. |
| 19:44.32 | CIA-62 | BRL-CAD: 03starseeker * r45343 10/brlcad/trunk/ (NEWS TODO): Bob fixed a number of issues with rtwizard by porting it to use the new ArcherCore framework (handling unknown units, freezing on some .g files.) |
| 19:45.41 | starseeker | ``Erik: I'm assuming that osX link line TODO is the one for CMake? |
| 19:47.44 | CIA-62 | BRL-CAD: 03starseeker * r45344 10/brlcad/trunk/TODO: Move a few tasks that aren't going to be handled this go-around. |
| 19:49.51 | starseeker | brlcad: um. is "revolve typein" the MGED command line input for our revolve primitive? |
| 19:51.29 | starseeker | fires off distcheck again |
| 19:56.21 | brlcad | starseeker: i'm not sure the mater color problem was occuring before 7.20.0, only noticed it afterwards |
| 19:56.53 | brlcad | and yes, "in rev revolve ..." |
| 19:57.12 | brlcad | that avs code seems incredibly complicated for what it's doing |
| 19:59.34 | kunigami | http://dl.dropbox.com/u/1399996/GSoC/OSL_RT-Refraction-Corrected-2011-06-30.png |
| 20:00.43 | kunigami | I was using a wrong index of refraction inside BRL-CAD, so it could be calculating hitting points wrongly |
| 20:33.58 | starseeker | woot - distcheck passed on linux |
| 20:37.36 | CIA-62 | BRL-CAD: 03starseeker * r45345 10/brlcad/trunk/misc/Makefile.am: Need the Doxygen.in file in extradist |
| 20:58.11 | CIA-62 | BRL-CAD: 03bhinesley * r45346 10/brlcad/trunk/src/libged/translate.c: Clean up some logic, clarify comments |
| 21:05.11 | starseeker | ``Erik: With the inclusion of Doxygen.in, I think the CMake build is now functioning from the autotools tarball |
| 21:12.03 | brlcad | kunigami: yeah, *that* is looking much better :) |
| 21:12.20 | brlcad | did you make the light bigger? |
| 21:13.28 | kunigami | yup :P but I did not the right way. Now when I render I get way more overlap messages (just scaled both the ceiling hole and the rectangle by hand) |
| 21:15.54 | starseeker | brlcad: in rev.s revolve 0 0 0 0 0 1 0 1 0 190 test_sketch works for me |
| 21:16.14 | starseeker | was there something specific that was a concern? |
| 21:17.39 | CIA-62 | BRL-CAD: 03brlcad * r45347 10/brlcad/trunk/src/libged/mater.c: improve handling of the color arguments by properly trimming whitespace before making comparisons or parsing values. |
| 21:18.24 | CIA-62 | BRL-CAD: 03kunigami * r45348 10/brlcad/trunk/src/liboptical/sh_osl.cpp: added a callback to be called whenever a refraction ray is shoot. I'm getting some runtime errors like mis-aligned struct hit pointer. |
| 21:20.13 | CIA-62 | BRL-CAD: 03brlcad * r45349 10/brlcad/trunk/src/libged/mater.c: free the right vls |
| 21:21.40 | kunigami | Current render by rt for a mirror shader (tall box): http://dl.dropbox.com/u/1399996/GSoC/OSL_Shader_Mirror_Test_2011-06-30.png |
| 21:22.08 | kunigami | ... and for glass shader (tall box): http://dl.dropbox.com/u/1399996/GSoC/OSL_Shader_Glass_Test_2011-06-30.png |
| 21:22.50 | kunigami | wrong, by the way |
| 21:22.51 | brlcad | kunigami: avoid forward decls unless you have a cyclic loop |
| 21:23.11 | kunigami | brlcad: ok! I'll fix that |
| 21:25.47 | CIA-62 | BRL-CAD: 03starseeker * r45350 10/brlcad/trunk/TODO: revolve in seems to function. |
| 21:25.50 | CIA-62 | BRL-CAD: 03kunigami * r45351 10/brlcad/trunk/src/liboptical/sh_osl.cpp: avoiding forward decls |
| 21:26.39 | starseeker | brlcad: I'm guessing that mater bug probably does appear in 7.20.0 - it's almost certainly a consequence of the attribute/red work |
| 21:27.08 | brlcad | starseeker: nope, just a quick sanity check since the typein interface for it was changed -- maybe try that same in command interactively if it wasn't so it builds up the args |
| 21:27.28 | starseeker | brlcad: that's how I generated that command - interactively :-P |
| 21:27.33 | starseeker | didn't know the parameters |
| 21:27.38 | brlcad | k, cool |
| 21:27.45 | brlcad | good enough! |
| 21:28.23 | starseeker | I think that OSX thing is the CMake logic not sorting out multiple X11 installs on a Mac - probably don't need to swat that right now, that'll involve some fairly heavy duty mucking with FindX11.cmake |
| 21:34.46 | CIA-62 | BRL-CAD: 03starseeker * r45352 10/brlcad/trunk/TODO: Move the OSX X11 search issue, add some more notes about what will need to be done. |
| 21:37.50 | CIA-62 | BRL-CAD: 03brlcad * r45353 10/brlcad/trunk/src/libged/mater.c: remove the debug avs printing |
| 21:39.29 | brlcad | does the build automatically look in the ports dir or did the user specify an additional dyld_library_path? |
| 21:39.40 | brlcad | it shouldn't be looking in the ports dir automatically in the first place |
| 21:39.57 | brlcad | unless someone points there with flags |
| 21:41.15 | brlcad | if it's a user setting, then we can try to detect that and/or tell people to unset their paths |
| 21:41.48 | starseeker | dunno - have to look at FindX11 and what the find paths are by default on OSX |
| 21:43.50 | starseeker | it can probably be handled cleanly, but I don't have time to tackle it for this release |
| 21:44.06 | brlcad | I don't see /opt in the list (except a stray include dir) |
| 21:44.20 | starseeker | would want to include ``Erik in that discussion, since he spotted the issue first |
| 21:44.33 | brlcad | also don't see the default mac install location either, though |
| 21:44.54 | starseeker | nods - that's why I want to check ``Erik's setup in more detail |
| 21:49.50 | CIA-62 | BRL-CAD: 03brlcad * r45354 10/brlcad/trunk/misc/CMake/FindX11.cmake: look in /usr/X11/lib followed by the older convention, X11 subdirs in the system lib. |
| 21:56.24 | CIA-62 | BRL-CAD: 03brlcad * r45355 10/brlcad/trunk/src/libged/mater.c: if the avs isn't initialized before it's needed, then we don't need to free it on all the error conditions. also emphasizes the curious double-standardize... intentional? |
| 21:56.25 | CIA-62 | BRL-CAD: 03starseeker * r45356 10/brlcad/trunk/src/other/libpng/CMakeLists.txt: Tweak the png linking mechanism a bit - test this on a few more platforms. |
| 21:57.29 | starseeker | brlcad: urm. IIRC, I think I standardized on import to make sure any changes to the color attribute would override any pre-existing color attributes... |
| 21:58.33 | starseeker | not sure if both are still needed |
| 21:58.58 | starseeker | that whole thing needs to be rewritten - it shouldn't be acting on the comb structure directly at all, except for the avs |
| 21:59.21 | starseeker | i gotta run, bbl |
| 22:13.45 | brlcad | nods |
| 22:14.53 | brlcad | curious that the old way has stopped working through -- that's not bidirectional, I'd expect the write of a db_comb_internal to sync comb to attr, then attr to comb, then write out |
| 22:16.10 | brlcad | since the comb fields are "fixed" and have flags when fields are invalid, they can be used to detect deletions and such that you don't get otherwise |
| 22:23.46 | CIA-62 | BRL-CAD: 0376.252.190.26 07http://brlcad.org * r2976 10/wiki/STEP: update/reword scl, esa/nasa sections |
| 22:35.46 | CIA-62 | BRL-CAD: 0383.85.24.171 07http://brlcad.org * r2977 10/wiki/ESA_Summer_of_Code_in_Space: |
| 22:38.04 | bhinesley | is there a standard character we should use for commands skipping coordinate arguments? |
| 22:38.05 | bhinesley | Ex: translate - - 5 sph.s ;# move sph.s up z-axis 5 units |
| 22:39.39 | bhinesley | In that case, zero would work, but there are cases zero would not suffice |
| 22:40.28 | bhinesley | Ex: translate -c - - 5 sph.s ;# move center of sph.s 5 units up z-axis |
| 22:41.07 | bhinesley | er to z=5, rather |
| 23:42.22 | CIA-62 | BRL-CAD: 03r_weiss * r45357 10/brlcad/trunk/src/librt/primitives/nmg/nmg_fuse.c: |
| 23:42.22 | CIA-62 | BRL-CAD: Updated functions 'nmg_two_face_fuse' and 'nmg_model_face_fuse' within file |
| 23:42.22 | CIA-62 | BRL-CAD: 'nmg_fuse.c'. These changes improve the fusing of coplanar faces during boolean |
| 23:42.22 | CIA-62 | BRL-CAD: operations of nmg objects. The changes can be seen on curved objects such as |
| 23:42.22 | CIA-62 | BRL-CAD: spheres which are not distorted due to improper face fusing. The changes effect |
| 23:42.23 | CIA-62 | BRL-CAD: functions such the mged 'facetize' and 'ev' commands. |
