| 02:03.50 | *** join/#brlcad Nohla (~jesica@201.255.246.101) | |
| 02:15.00 | CIA-73 | BRL-CAD: 03brlcad * r38543 10/brlcad/trunk/src/libdm/rect.c: downcast colors to unsigned chars, quellage |
| 02:15.30 | CIA-73 | BRL-CAD: 03brlcad * r38544 10/brlcad/trunk/src/libdm/labels.c: more quellage, POINT_LABEL wants a char. |
| 02:17.06 | brlcad | starseeker: looks like your opennurbs update is missing something |
| 02:19.16 | brlcad | opennurbs_brep_tools.cpp fails on ON_Brep::m__SplitFaces .. which looks like a correct failure, no m__SplitFaces in the ON_Brep class |
| 02:30.25 | starseeker | brlcad: ermm... oopps |
| 02:30.31 | starseeker | proceeds to fix |
| 02:33.09 | CIA-73 | BRL-CAD: 03starseeker * r38545 10/brlcad/trunk/src/other/openNURBS/opennurbs_brep_tools.cpp: OK, these functions were calling a non-existant function - broke the build. |
| 02:33.26 | CIA-73 | BRL-CAD: 03brlcad * r38546 10/brlcad/trunk/src/libdm/dm_obj.c: no need to switch over the various *_close_existing() functions, call fb_close_existing() instead. |
| 02:36.44 | CIA-73 | BRL-CAD: 03brlcad * r38547 10/brlcad/trunk/src/libdm/dm_obj.c: remove lots of dead code. de-k&r funcs. |
| 02:36.52 | brlcad | just that one file? |
| 02:40.05 | CIA-73 | BRL-CAD: 03brlcad * r38548 10/brlcad/trunk/src/libfb/fb_generic.c: provide declarations for the various *close_existing() implementations as it will be removed from fb.h |
| 02:42.19 | CIA-73 | BRL-CAD: 03brlcad * r38549 10/brlcad/trunk/src/libfb/tcl.c: no longer need decls on the *close_existing() impls. |
| 02:43.21 | CIA-73 | BRL-CAD: 03brlcad * r38550 10/brlcad/trunk/include/fb.h: should no longer need to declare any of the *_close_existing() funcs as they all hidden behind fb_close_existing() in libfb's fb_generic.c |
| 02:45.40 | brlcad | starseeker: keep in mind that they may very well remove functionality we use/need/want .. code that perhaps slips out by mistake that isn't really needed for obj parsing |
| 02:45.54 | starseeker | nods |
| 02:46.06 | brlcad | but that could be rather useful for ray evaluation, spatial partitioning, surface evaluation, etc |
| 02:46.09 | starseeker | I'll give it a more detailed read tomorrow - too shot now |
| 02:46.28 | brlcad | that splitting faces code sounds right up that alley potentially |
| 02:46.55 | starseeker | I originally tagged it with a comment and left it in, but somehow it built on the mac and didn't build here |
| 02:47.39 | starseeker | just did the quick fix, but I'll give it a more careful read tomorrow |
| 02:48.25 | starseeker | 'course, the more things like that happen, the more we'll become a true fork |
| 02:53.07 | brlcad | all the more reason to sort our changes out into an encapsulated friend class |
| 02:53.23 | brlcad | so we don't have to mod them, but can overlay our changes |
| 02:53.48 | starseeker | nods |
| 02:53.54 | brlcad | hm, so the harder part of the *_open_existing() evil is going to be much harder to sort out... |
| 02:54.01 | starseeker | I'd need some help with the details of that... |
| 02:54.28 | starseeker | doesn't see any code for m__SplitFaces in the previous release |
| 02:54.30 | brlcad | could probably implement it as either a vararg function or require an FBIO be filled in manually beforehand |
| 02:55.08 | starseeker | hasn't even reached that part of the Tk fb/dm logic - been dreading it |
| 02:56.21 | brlcad | heh, lookie what I found |
| 02:56.22 | brlcad | https://svn.blender.org/svnroot/bf-blender/branches/nurbs/blender/intern/nurbana/intern/ |
| 02:56.40 | brlcad | at the bottom.. looks like they're including opennurbs now too |
| 02:56.57 | starseeker | hehehe |
| 02:57.10 | brlcad | certainly wasn't released when justin wrote nurbana |
| 02:58.18 | brlcad | http://brlcad.org/xref/source/src/other/openNURBS/opennurbs_brep.h |
| 02:58.27 | brlcad | lists an m__SplitFaces member |
| 02:59.27 | brlcad | looks like it is a RhinoSDK function |
| 02:59.32 | starseeker | nods |
| 02:59.36 | brlcad | http://brlcad.org/xref/source/src/other/openNURBS/opennurbs_mesh.cpp#L32 |
| 03:02.29 | starseeker | ok, so they took out logic we probably want to save, even though there was a RhinoSDK function at the root of it? |
| 03:02.55 | brlcad | yeah, looks like it |
| 03:03.02 | brlcad | though it may have just moved to elsewhere |
| 03:03.06 | starseeker | confound it |
| 03:03.10 | starseeker | will revert |
| 03:03.18 | starseeker | we'll sort it out tomorrow |
| 03:03.20 | brlcad | that was a pretty big update from what we had |
| 03:03.44 | *** join/#brlcad alex_joni (~alex_joni@emc/board-of-directors/alexjoni) | |
| 03:03.52 | brlcad | that added support for the v5 3dm file format (ours only went up to v4) |
| 03:04.24 | brlcad | slew of new entities and extensions from glances through the commit |
| 03:07.51 | CIA-73 | BRL-CAD: 03brlcad * r38551 10/brlcad/trunk/src/libbu/brlcad_path.c: avoid assignment withing expression, make logic more explicit/clear. |
| 03:08.34 | CIA-73 | BRL-CAD: 03brlcad * r38552 10/brlcad/trunk/src/libbu/brlcad_path.c: ws |
| 03:09.55 | brlcad | don't see a particular reason to revert it just yet |
| 03:11.14 | brlcad | and wow .. it's noticably warning-cluttered now with the new rev.. particularly exact flaoting point comparisons. someone there is getting sloppy.. it was pretty clean. |
| 03:12.12 | brlcad | wonders why weiss wrote a triangulate_face() function... |
| 03:14.34 | brlcad | nmg_triangulate_model() ftw. or nmg_triangulate_shell() or nmg_triangulate_fu() .. |
| 03:28.12 | starseeker | thinks he recalls suggesting that earlier to him, but apparently I should have been more specific... |
| 03:28.33 | starseeker | just suggested investigating the nmg code to see if the functionality he needed was already there... |
| 03:30.38 | starseeker | brlcad: actually, I believe it was commit-before-last that upped it to v5 - this last one makes an "old 5" and "new 5", if I was interperting opennurbs_archive.h correctly |
| 04:51.34 | *** join/#brlcad Nohla (~jesica@201.255.246.101) | |
| 06:15.35 | *** join/#brlcad cosurgi (~cosurgi@atak.bl.pg.gda.pl) | |
| 10:07.07 | *** join/#brlcad mafm (~mafm@81.35.69.130) | |
| 11:07.48 | *** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ) | |
| 11:45.36 | d-lo | Mernin |
| 12:19.24 | *** join/#brlcad Ralith (~ralith@69.90.48.97) | |
| 12:19.57 | CIA-73 | BRL-CAD: 03davidloman * r38553 10/rt^3/trunk/src/alf/: Modified SVN:IGNORE to ignore more build byproducts. |
| 12:20.59 | brlcad | starseeker: hm, that's odd then because that last commit implemented a lot of functionality |
| 12:21.11 | brlcad | specific to new v5 features |
| 12:36.49 | CIA-73 | BRL-CAD: 03davidloman * r38554 10/rt^3/trunk/ (6 files in 3 dirs): Add *.backup to /src/gs/Jobs' SVN:Ignore prop. Formatting on AbstractJob.* Introduce PrintToStdOut class in prep for JobManager functional test. |
| 12:44.44 | CIA-73 | BRL-CAD: 03davidloman * r38555 10/rt^3/trunk/ (50 files in 9 dirs): Move libNetwork/ out of GS/ for better organization. |
| 12:48.23 | brlcad | the scope and complexity keep expanding there... really not a good sign |
| 12:49.34 | d-lo | to what are you referring to? |
| 12:50.09 | brlcad | the changes over the past week and a half |
| 12:50.37 | d-lo | gs or something else? |
| 12:50.43 | brlcad | ge/gs |
| 12:51.02 | d-lo | care to be more specific? what's bugging yas? |
| 12:51.33 | brlcad | it's more feature creep and staged planning instead of base functionality |
| 12:51.46 | brlcad | coding wide |
| 12:52.16 | d-lo | Well, tbh, I am still trying to get an org scheme that works :/ |
| 12:52.42 | brlcad | a class dedicated to printing to stdout instead of just printing to stdout is a good example, but just one out of several dozen complexity-inducing issues |
| 12:53.03 | brlcad | sorting out org is "coding wide" |
| 12:53.13 | brlcad | at least it lends to it |
| 12:53.27 | d-lo | PrintToStdOutJob is only for the test I am about to write ;) |
| 12:53.27 | brlcad | as you'll continually refactor the org until it fits some mental model |
| 12:54.05 | d-lo | True, as I have had the 'mental model' solidify over the last month due to looking at it via TDD. |
| 12:55.39 | brlcad | the problem is that mental models can change rapidly, and should be able to |
| 12:56.02 | brlcad | if each refactoring gets longer and harder, that's a sign that complexity is getting too big |
| 12:56.50 | brlcad | if not great, but I'm betting I'd have to touch a ton of code if I wanted to change a particular piece of functionality |
| 12:57.08 | d-lo | Well you should be a bit smug then :) Initially, I re orged everything to what I thought would be best, and, over time, I am working back to the way you had it setup initially :P |
| 12:57.32 | brlcad | heh |
| 12:57.37 | brlcad | no smugness |
| 12:57.46 | brlcad | it is never right :) |
| 12:58.07 | brlcad | there's always room for improvement, but that's even more to the point |
| 12:58.07 | d-lo | understood ;) |
| 12:58.21 | brlcad | why it's more important to keep the code as simple as possible so it can be adapted |
| 12:58.38 | brlcad | and understood or picked up by someone else without needing to comprehend "the architecture" |
| 12:59.01 | brlcad | take the openNURBS API for example -- it's a pretty big chunk of code, but it's very simple |
| 12:59.07 | d-lo | I agree. Which is partially why I am mvonig back to a simpler org. |
| 12:59.49 | brlcad | there are no tessellation managers, job queues, printing managers, task scheduling, etc, even though it has functionality that covers those areas |
| 12:59.50 | d-lo | Your test harness and a few days spend reading up on TDD has given me much needed direction and starting points. |
| 13:00.17 | brlcad | not saying those are bad to have, quite the contrary particularly for the GS |
| 13:00.27 | brlcad | but have to really keep it all in check |
| 13:00.56 | d-lo | and I am trying to //TODO and/or stub in functionality 'to be implemented later' while trying to stay on target for my goal. |
| 13:01.13 | brlcad | I wouldn't even bother stubbing it |
| 13:01.23 | brlcad | that's just complexity that has to be waded through |
| 13:02.33 | brlcad | and stubs that may be invalid as refactoring continues, then it's wasted effort |
| 13:03.12 | d-lo | well seeing as this is one huge learning process for me (on many facets) I have accepted the fact that there will be lots of wasted effort. |
| 13:03.55 | brlcad | which is why I'm just trying to encourage that you just KISS more :) |
| 13:04.44 | d-lo | Oh trust me, I think I am :) Especially compared to what I had penciled out a few months ago. |
| 13:05.02 | brlcad | then even more :) |
| 13:05.49 | brlcad | did see the code you ripped out, that was good :) |
| 13:06.02 | brlcad | less is definitely going to be more at this point |
| 13:06.10 | d-lo | still working on more, um, 'KiSS-ing' |
| 13:06.14 | d-lo | if thats even a term |
| 13:06.35 | brlcad | http://en.wikipedia.org/wiki/KISS_principle |
| 13:07.56 | brlcad | basically making things only *exactly* as complex as they need to be to fulfill a feature |
| 13:07.58 | d-lo | Oh I am familiar with KISS as a concept, just don't know if it can be turned into a verb and still keep the meaning the same. |
| 13:08.07 | brlcad | if that can be done with one less class, then better |
| 13:08.24 | d-lo | right, and in steps the experience I don't have ;) |
| 13:08.31 | brlcad | the point that you have to repeat that funcionality, you refactor |
| 13:08.45 | d-lo | which leads back to the learning process thingy :) |
| 13:08.50 | brlcad | that's the "Don't Repeat Yourself" principle |
| 13:08.58 | brlcad | DRY or DIE |
| 13:09.03 | brlcad | Duplication is Evil |
| 13:09.52 | brlcad | identified approximately 200,000 lines of evil in BRL-CAD :) |
| 13:10.17 | brlcad | we should have dev names for our releases |
| 13:10.32 | brlcad | BRL-CAD 7.18.0 "Now with Less Evil" |
| 13:10.54 | d-lo | lol |
| 13:11.44 | d-lo | Well, as a padawan, I am still learning what's evil and what's not. Have patience Massa! |
| 13:12.50 | d-lo | question, if you have the time |
| 13:13.27 | brlcad | from a marketing/developer perspective, a key point to continually keep in mind is that we are aiming for exactly two target productsP: a C++ GE API (library) and a network-based GS daemon (application) |
| 13:13.38 | brlcad | everything that derives that is implementation detail |
| 13:13.58 | brlcad | and shouldn't be concern to external devs or users |
| 13:13.59 | d-lo | Since I am building the portions of rt^3 I care about with CMAKE, but I am pretty sure Dr Rossberg is using autotools for his portions.... should I unwire all my stuff from autotools? |
| 13:15.11 | CIA-73 | BRL-CAD: 03indianlarry * r38556 10/brlcad/trunk/include/opennurbs_ext.h: |
| 13:15.11 | CIA-73 | BRL-CAD: Tightened up BREP flatness criterior to work around cases where 3D surface |
| 13:15.11 | CIA-73 | BRL-CAD: volumes genertated from surface subdivision not fully containing the |
| 13:15.11 | CIA-73 | BRL-CAD: sub-surface. Need to fix both the flatness test and the min/max bounding |
| 13:15.11 | CIA-73 | BRL-CAD: routines. |
| 13:15.13 | brlcad | what of yours is wired into autotools? |
| 13:15.19 | brlcad | didn't think it was |
| 13:16.12 | d-lo | looking to see the extent. |
| 13:16.20 | brlcad | I wouldn't intentionally break things for him or break the autotools build, but there's no sense in maintaining two build systems |
| 13:16.32 | brlcad | at least for the same product |
| 13:16.51 | brlcad | it really should all migrate to cmake and get sorted out |
| 13:17.07 | d-lo | I have SOME things wired in to build, but I switched to CMAKE and appearently never went back and un wired stuff from autotools. |
| 13:17.22 | brlcad | I'd just leave it for now then |
| 13:17.25 | brlcad | not pressing |
| 13:18.19 | d-lo | I have been leaving his stuff alone, since I haven't really had the time to get it into cmake |
| 13:18.41 | d_rossberg | d-lo: i'm using cmake on windows (brlcad/misc/win32-msvc/CMakeLists.txt) and i was able to build libcoreInterface.so with rt^3/CMakeLists.txt |
| 13:19.09 | d-lo | awesome :) so you are not using autotools at all anymore in rt3? |
| 13:19.30 | d_rossberg | only for the brlcad standard build |
| 13:20.46 | d_rossberg | i accidentally used autotools for rt^3 because of the autogen.sh etc. in the root directory |
| 13:21.07 | d_rossberg | but they don't work any more |
| 13:21.40 | d_rossberg | CMake works (in general) |
| 13:21.51 | d-lo | kk thanks! |
| 13:24.26 | d-lo | So if I started pulling out all the autotools stuff, that's okay then? |
| 13:27.18 | d_rossberg | i would say yes: it is ok for me and rt^3 is a playground anyway (there isn't more trafic there than our own, i would say) |
| 13:35.25 | CIA-73 | BRL-CAD: 03davidloman * r38557 10/rt^3/trunk/ (24 files in 8 dirs): Continuing to simplify things by moving src/GS/Jobs/ to src/libJob |
| 13:35.46 | d-lo | newb question: the file: 'include/brlcad/belcadversion.h' should it be on the SVN:IGNORE prop? |
| 13:36.45 | d_rossberg | yes, it will be generated by CMake |
| 13:38.30 | CIA-73 | BRL-CAD: 03davidloman * r38558 10/rt^3/trunk/include/brlcad/: Add CMAKE generated file 'brlcadversion.h' to SVN:IGNORE |
| 13:40.17 | CIA-73 | BRL-CAD: 03davidloman * r38559 10/rt^3/trunk/ (13 files in 11 dirs): Remove outdated autotools stuff due to the switch to CMAKE. |
| 13:40.27 | CIA-73 | BRL-CAD: 03indianlarry * r38560 10/brlcad/trunk/src/librt/primitives/brep/brep.cpp: |
| 13:40.27 | CIA-73 | BRL-CAD: Added code so that if an iterative step in the newton solver gets farther away |
| 13:40.27 | CIA-73 | BRL-CAD: from the target point back up a half step. Fixes a problem where under the right |
| 13:40.27 | CIA-73 | BRL-CAD: surface conditions the solver would keep stepping over and past the target point |
| 13:40.28 | CIA-73 | BRL-CAD: until it hit a built-in iterative limit for non convergence. |
| 13:57.40 | brlcad | that solves that then |
| 14:14.04 | d-lo | what is BRLCAD's pastebin addy? |
| 14:20.02 | d-lo | Seeing a brlcad build error: http://pastebin.org/150992 |
| 14:20.48 | Ralith | newton solver? |
| 14:21.19 | d-lo | by the looks of it, it seems to be related to Tk and the FrameBuffer. |
| 14:51.39 | brlcad | turn off the tk framebuffer interface |
| 14:52.24 | brlcad | it's using the wrong Tk_PhotoPutBlock() signature |
| 15:03.44 | brlcad | Ralith: NURBS ray tracing uses a root solver that employs newtonian iteration |
| 15:05.01 | brlcad | classic newton iteration where you basically subdivide to get close to a solution |
| 15:05.07 | brlcad | in steps |
| 15:07.39 | CIA-73 | BRL-CAD: 03brlcad * r38561 10/brlcad/trunk/src/libfb/if_tk.c: Tk_PhotoPutBlock() with a Tk_PhotoHandle only works with Tk 8.5+, so test accordingly. |
| 15:07.42 | Ralith | that's called newtonian iteration? |
| 15:07.44 | Ralith | neat! |
| 15:07.55 | brlcad | yeah |
| 15:08.44 | brlcad | http://en.wikipedia.org/wiki/Newton's_method |
| 15:11.59 | CIA-73 | BRL-CAD: 03brlcad * r38562 10/brlcad/trunk/NEWS: keith has made a number of improvements and bug fixes to nurbs ray tracing |
| 15:14.22 | CIA-73 | BRL-CAD: 03brlcad * r38563 10/brlcad/trunk/NEWS: cliff has made a bunch of new tree-view images and button images (replacements and new ones) for archer. |
| 15:20.49 | CIA-73 | BRL-CAD: 03brlcad * r38564 10/brlcad/trunk/TODO: need to improve the min/max bounding box routines for BREP/NURBS |
| 15:23.26 | CIA-73 | BRL-CAD: 03brlcad * r38565 10/brlcad/trunk/NEWS: cliff updated openNURBS to 5.0 (2010-04-09) |
| 15:42.09 | CIA-73 | BRL-CAD: 03starseeker * r38566 10/brlcad/trunk/src/tclscripts/archer/images/ (5 files): Add icons for metaball primitive. |
| 15:49.10 | CIA-73 | BRL-CAD: 03bob1961 * r38567 10/brlcad/trunk/src/tclscripts/archer/ArcherCore.tcl: Mods to improve the speed of the treeview widget. |
| 16:00.24 | CIA-73 | BRL-CAD: 03starseeker * r38568 10/brlcad/trunk/src/tclscripts/archer/images/ (bot.png bot_intersect.png bot_subtract.png bot_union.png): Change BoT icons |
| 16:39.16 | starseeker | + |
| 16:39.24 | starseeker | whoops |
| 16:47.33 | CIA-73 | BRL-CAD: 03starseeker * r38569 10/brlcad/trunk/src/tclscripts/archer/Archer.tcl: |
| 16:47.33 | CIA-73 | BRL-CAD: Only do the contents of the man page viewer if the Introduction file is present |
| 16:47.33 | CIA-73 | BRL-CAD: - really should disable the viewer altogether based on this check, but make this |
| 16:47.33 | CIA-73 | BRL-CAD: change for now so archer can start with the extra docs disabled. |
| 16:58.44 | CIA-73 | BRL-CAD: 03bob1961 * r38570 10/brlcad/trunk/src/tclscripts/archer/ArcherCore.tcl: Updated for bot and metaball tree images. |
| 17:33.56 | brlcad | starseeker: any interetsing features making it worthwhile to update from 8.5.6 to 8.5.8 ? |
| 17:49.51 | starseeker | urm |
| 17:49.54 | starseeker | good question |
| 17:50.05 | starseeker | has been focused on 8.6 of late |
| 17:50.09 | starseeker | have to check |
| 17:55.19 | yukonbob | bets negligable. |
| 18:51.48 | mafm | so aren't you participating in gsoc this year? |
| 19:00.41 | brlcad | mafm: nope, not this year |
| 19:01.27 | brlcad | it takes a big time investment and we have some high-priority dev activities that will benefit from consolidated effort |
| 19:03.20 | brlcad | would have given it more consideration if previous year students were a little more active than they've been... but everyone gets busy :) |
| 19:03.30 | brlcad | maybe next year |
| 19:04.37 | mafm | yeah, bastard students from hell :P |
| 19:05.49 | poolio | oooops :) |
| 19:11.23 | mafm | :) |
| 19:22.04 | CIA-73 | BRL-CAD: 03erikgreenwald * r38571 10/brlcad/trunk/src/libgcv/region_end_mc.c: remove explicit fusing in favor of nmg_model_fuse(). add call to nmg_shell_coplanar_face_merge(). |
| 19:26.46 | CIA-73 | BRL-CAD: 03brlcad * r38572 10/brlcad/trunk/NEWS: |
| 19:26.46 | CIA-73 | BRL-CAD: fixed a bug with the solids command (which subsequently also affects the regions |
| 19:26.46 | CIA-73 | BRL-CAD: and idents commands) reported by tom browder (tbrowder2) via sf bug report |
| 19:26.46 | CIA-73 | BRL-CAD: 2974586 (Core Dump with mged 'solids' Command) where a provided stack trace |
| 19:26.46 | CIA-73 | BRL-CAD: showed a bad vls. the problem was a call to bu_vls_init_if_uninit() on a vls |
| 19:26.46 | CIA-73 | BRL-CAD: that was not initialized but had non-zero data so never becomes initialized. |
| 19:26.47 | CIA-73 | BRL-CAD: fix was to call bu_vls_init() instead. |
| 19:30.26 | starseeker | brlcad: when was the fix committed? |
| 19:32.40 | brlcad | http://brlcad.svn.sourceforge.net/viewvc/brlcad?view=rev&revision=38382 |
| 19:33.01 | starseeker | oh, a while ago |
| 19:33.07 | brlcad | heh, apparently less than a week ago |
| 19:33.10 | brlcad | thought it was several weeks |
| 19:33.16 | brlcad | lost in an msvc time warp |
| 19:33.24 | starseeker | was that the crash? |
| 19:34.08 | brlcad | pretty sure |
| 19:34.22 | starseeker | wow, quick card :-P |
| 19:34.31 | brlcad | yeah, forgot it was already fixed |
| 19:34.39 | brlcad | he took the rt/rtedge request |
| 19:35.20 | brlcad | that same code problem has happened before, bu_vls_init_if_unint() should probably be deprecated because of it's potential for that.. only works for zero-initialized memory |
| 20:08.56 | *** join/#brlcad R0b0t1 (~Enigma@unaffiliated/r0b0t1) | |
| 20:23.16 | *** join/#brlcad prasad_ (~psilva@static-96-255-52-7.washdc.fios.verizon.net) | |
| 20:23.24 | prasad_ | hi :) |
| 20:23.29 | brlcad | oh my :) |
| 20:23.31 | brlcad | howdy |
| 20:23.45 | brlcad | who sobered you up enough to type?? |
| 20:23.56 | prasad_ | hehe |
| 20:24.05 | prasad_ | what's new |
| 20:24.28 | prasad_ | i heard rumblings about a new ui |
| 20:24.31 | brlcad | a lot new a lot the same |
| 20:24.39 | brlcad | yeah, couple projects going on there |
| 20:24.40 | prasad_ | came to see some shiny gfx |
| 20:24.51 | prasad_ | screens? |
| 20:24.56 | brlcad | nurbs are implemented |
| 20:25.27 | brlcad | archer is coming along nicely getting mged features integrated |
| 20:26.20 | brlcad | all in good time, :) |
| 20:27.02 | brlcad | here's one a bit dated of archer: http://brlcad.org/~starseeker/archer.png |
| 20:27.17 | brlcad | looks a lot different already |
| 20:27.31 | starseeker | makes a new one for the heck of it... |
| 20:27.55 | prasad_ | ah cool |
| 20:28.03 | brlcad | http://brlcad.org/~starseeker/g3d_latest.png from last summer |
| 20:28.25 | brlcad | that's a separate "new gui" effort coming along .. that's mged embedded there |
| 20:28.31 | prasad_ | looks like a gl canvas? |
| 20:28.39 | prasad_ | (the g3d one) |
| 20:28.40 | brlcad | yeah, ogre3d |
| 20:28.45 | prasad_ | ah ha |
| 20:28.54 | prasad_ | with their own widgets i guess |
| 20:29.20 | brlcad | widgets were some simple toolkit whose name I forget at the moment |
| 20:29.30 | brlcad | not cegui |
| 20:29.37 | brlcad | maybe rbgui |
| 20:29.43 | prasad_ | ic |
| 20:29.45 | prasad_ | looks nice :) |
| 20:29.53 | prasad_ | better than what i remember |
| 20:30.04 | *** join/#brlcad roberthl (~robert@mediawiki/RobertL) | |
| 20:31.37 | brlcad | we're moving towards Qt, though, for widgets -- customized gl-rendered widgets |
| 20:31.41 | brlcad | now that they're lgpl |
| 20:31.58 | brlcad | I don't recall if that screenshot was before or after Qt was integrated |
| 20:32.03 | brlcad | you remember starseeker ? |
| 20:32.26 | brlcad | http://brlcad.org/wiki/User:Ralith |
| 20:32.36 | brlcad | looks like after, so that is Qt there |
| 20:33.45 | starseeker | that one is after Qt I believe |
| 20:34.11 | starseeker | yeah - that's the Qt widgets there |
| 20:36.36 | starseeker | http://brlcad.org/~starseeker/archer_latest.png |
| 20:36.42 | starseeker | prasad_: there ya go |
| 20:37.05 | prasad_ | sexy ;) |
| 20:46.27 | brlcad | starseeker: need a better icon for assemblies (combs above regions), parts (regions), and combs (below regions) |
| 20:46.32 | *** join/#brlcad Ralith (~ralith@69.90.48.97) | |
| 20:46.42 | brlcad | speak of the devil -- there be Ralith |
| 20:47.02 | starseeker | brlcad: bob has a red icon for regions - that fix isn't in yet |
| 20:47.43 | starseeker | as for parts... there's a fair bit of processing needed up front just to recognize that something is an assembly |
| 20:48.19 | starseeker | one of the problems has been to balance features with load time - for big databases even search gets expensive |
| 20:49.02 | brlcad | it could great an idle update queue where objects are expanded as they are identified |
| 20:49.22 | brlcad | should also use a fixed-width font for the tree view |
| 20:50.12 | brlcad | at least for the operators (which should be smaller and aligned better) |
| 20:51.27 | starseeker | the operators are graphical (actually part of the image) |
| 20:51.49 | brlcad | e.g., Inner-Hub-215-55R17.c .. the three prims below it all shift back and forth because of the font |
| 20:52.05 | brlcad | that 'u' and '-' are graphical? |
| 20:52.19 | starseeker | yes - that's a limitation of the tree widget |
| 20:52.29 | starseeker | that's why there are 4 images per primitive |
| 20:52.31 | brlcad | hm, then the icons need tweaking |
| 20:52.35 | starseeker | yeah |
| 20:52.38 | brlcad | to be all exactly the same dimensions |
| 20:52.50 | starseeker | that was a quick and dirty "let's test out this idea for a tree widget" icon set |
| 20:52.51 | brlcad | at least the same width |
| 20:54.02 | starseeker | anticpated you not caring for them, but figured post-alpha was the logical time to refine them, if the idea sells with users |
| 20:54.09 | brlcad | or rather, at least the same with for ops and same width for shape icons, |
| 20:54.50 | Ralith | brlcad: eep! |
| 20:54.56 | brlcad | any ideas on a good icon for combs? |
| 20:55.10 | brlcad | Ralith: prasad_ was asking about your gui work, showed him some shots :) |
| 20:55.12 | starseeker | was actually OK with the folder - it makes sense |
| 20:55.33 | starseeker | I don't really have any better ideas (don't like the toolbar comb icon at all) |
| 20:55.53 | starseeker | is a poor graphic artist :/ |
| 20:56.19 | Ralith | brlcad: cool; hopefully I can get back in and extend that some this summer |
| 20:56.52 | prasad_ | starseeker, 'poor' depends on perception ;) |
| 20:57.13 | brlcad | starseeker: a variant of our classic CSG example would probably work |
| 20:57.15 | prasad_ | Ralith, u did the g3d one? |
| 20:57.33 | brlcad | http://brlcad.org/gallery/d/242-3/csg_example.png .. iirc, there's a proc-db or sample .g that has it |
| 20:57.40 | Ralith | prasad_: in its current form, yeah, unless somebody extended it a ton while I wasn't looking. |
| 20:57.53 | Ralith | prasad_: I owe a lot ot mafm's original work. |
| 20:57.55 | starseeker | for comb? oh, you mean the boolean illustration? |
| 20:58.20 | Ralith | he actually laid most of it out and built the higher level design that I worked from |
| 20:58.21 | starseeker | the upper left one might work, but I dunno how well it would compress to 18 pixels high |
| 20:58.23 | brlcad | I don't like the folder at all, it implies the wrong concept |
| 20:59.03 | prasad_ | Ralith, cool |
| 20:59.18 | Ralith | prasad_: what's your interest, if I might ask? |
| 20:59.24 | prasad_ | iirc brlcad wont be in gsoc this year? |
| 20:59.27 | starseeker | OK... and I suppose have the mult-colored one be the comb and a uniform color for regions? |
| 20:59.42 | prasad_ | just curious to see the progress of a project i used to work on :) |
| 21:00.02 | Ralith | cool |
| 21:00.22 | Ralith | isn't planning on gsoc this year either, has some in-person job opportunities to hope for |
| 21:00.38 | prasad_ | nice |
| 21:00.42 | prasad_ | where abouts? |
| 21:00.46 | Ralith | seattle |
| 21:01.31 | prasad_ | nice |
| 21:02.15 | brlcad | starseeker: regions are the one to call out with emphasis |
| 21:02.42 | brlcad | ideally indicating solidity above regions and non-solidity below regions (they're just shapes) |
| 21:02.54 | brlcad | barring that, same icon without color for non-regions |
| 21:06.40 | starseeker | nods... |
| 21:10.41 | prasad_ | brlcad, got an ipad? |
| 21:18.31 | ``Erik | a1/cl |
| 21:20.51 | prasad_ | hey ``Erik |
| 21:23.12 | *** join/#brlcad Stattrav (~Stattrav@202.3.77.204) | |
| 21:37.17 | mafm | no love for gsoc this year :) |
| 22:11.50 | *** join/#brlcad Nohla (~jesica@201.255.246.101) | |
| 22:27.04 | ``Erik | yargh, prasad, wormed your way into firaxis yet? :D |
| 22:27.56 | starseeker | eyes the hv3 required components list... if I'm not mistaken, we won't need Tls or tclsee for a help browser, and if we're using all png images we won't need Img... |
| 22:28.26 | starseeker | that leaves Tkhtml3 and sqlite3, and I'm curious how deep the sqlite requirement is |
| 22:28.29 | starseeker | hmm... |
| 22:29.22 | prasad_ | ``Erik, funny u ask |
| 22:29.29 | prasad_ | two leads at firaxis joined us |
| 22:29.32 | prasad_ | heh |
| 22:29.43 | prasad_ | they're not too happy about that |
| 22:31.10 | CIA-73 | BRL-CAD: 03starseeker * r38573 10/brlcad/trunk/src/mged/ (Makefile.am cmd.h info.c setup.c): Make the l command show the info for a primitive being edited, when it is edit state. |
| 22:31.14 | ``Erik | left firaxis to work with ya'll? |
| 22:32.43 | ``Erik | mebbe ya lucked out and landed at the better place O.o |
| 22:36.06 | ``Erik | http://www.youtube.com/watch?v=P9xKQm5d1uU |
| 22:36.54 | ``Erik | betty white ++ |
| 23:24.04 | *** join/#brlcad tofu_ (~sean@BZ.BZFLAG.BZ) | |
