| 00:00.12 | Notify | 03BRL-CAD:starseeker * 61561 (brlcad/branches/openscenegraph/BUGS brlcad/branches/openscenegraph/CMakeLists.txt and 30 others): Sync through trunk r61560 |
| 00:00.32 | Notify | 03BRL-CAD:starseeker * 61562 (brlcad/branches/gecode/BUGS brlcad/branches/gecode/CMakeLists.txt and 29 others): Sync through trunk r61560 |
| 00:00.51 | Notify | 03BRL-CAD:starseeker * 61563 (brlcad/branches/bullet/BUGS brlcad/branches/bullet/CMakeLists.txt and 29 others): Sync through trunk r61560 |
| 00:29.56 | Notify | 03BRL-CAD:starseeker * 61564 brlcad/branches/openscenegraph/include/ged.h: Start thinking about what a new display list structure is going to look like. |
| 00:31.32 | starseeker | brlcad: with autoview, should it actually calculate view bounds or just add an event for the displays to size themselves to show all objects? |
| 00:32.22 | starseeker | it appears to be using solid wireframes to calculate the view size currently... if it stays in libged I'd prefer to have it actually ask for bounding boxes, if that's not prohibitively slow |
| 00:36.19 | starseeker | brlcad: can we add a deprectation notice for all code that interacts with v4 databases that is not involved with dbupgrading them to v5? |
| 00:38.17 | starseeker | concedes that it may be necessary for unpacking the data to retain a fair bit of that code, but I'd much rather it live in dbupgrade and maybe src/librt/db_v4_read.c than places like src/libged/color.c... |
| 00:42.28 | starseeker | makes a note to add an audit of the state of librt's bounding box routines to some student task list... |
| 00:43.47 | starseeker | if any primitives still require the "plot it and bound the plot" fudgery, it should be in their bbox callback and not the responsibility of libged's draw.c... |
| 00:50.24 | starseeker | hmm... do we want libged's commands to be able to specify the mode of viewing? (wireframe vs shaded vs hidden_line vs...?) |
| 00:50.57 | starseeker | might be worth an enum, if we could be reasonably comprehensive... |
| 01:08.36 | Notify | 03BRL-CAD:starseeker * 61565 brlcad/branches/openscenegraph/include/ged.h: More thinking on 'what information do we need for display list entries to have all the information a display will need?' |
| 02:01.27 | *** join/#brlcad infobot (~infobot@rikers.org) |
| 02:01.27 | *** topic/#brlcad is BRL-CAD || http://brlcad.org || logs: http://ibot.rikers.org/%23brlcad/ || GCI winners: Jacob Burroughs and Peter Amidon! || GSoC 2014 selections are announced! Thank you to all we got to work with. Remember that SOCIS is coming up right around the corner and you don't need a summer of code to get involved with open source. |
| 02:05.46 | *** join/#brlcad infobot (~infobot@rikers.org) |
| 02:05.46 | *** topic/#brlcad is BRL-CAD || http://brlcad.org || logs: http://ibot.rikers.org/%23brlcad/ || GCI winners: Jacob Burroughs and Peter Amidon! || GSoC 2014 selections are announced! Thank you to all we got to work with. Remember that SOCIS is coming up right around the corner and you don't need a summer of code to get involved with open source. |
| 03:38.00 | brlcad | starseeker: excellent questions... oof! |
| 03:42.43 | brlcad | for autoview, there's actually substantial logic -- a method -- to setting up a particular view, so it's guts can/should be in libged |
| 03:43.12 | brlcad | note though that it should also generate a "view changed" event if/when it changes the view |
| 03:43.44 | brlcad | the app gets to decide what to do with that event and the view specified |
| 04:10.36 | brlcad | no opinion on bbox vs wireframe ... aabb's and even obb's are going to create views more padded than they are now -- the wireframe points are basically a poorman convex hull. oob would probably be okay; a real convex hull would probably be best (perhaps off the brep edges). I agree that using plot data (especially if LoD is in play) isn't desirable going forward. |
| 04:13.00 | brlcad | yes to the deprecation notice, but I think we should do the actual incremental removal on the rel8 branch |
| 04:18.50 | brlcad | the last one is tricky but my initial inclination is "no" in part to keep it simple, but also because that really gets into how data is presented, which is the apps (and libdm's) job |
| 04:29.35 | brlcad | from libged's perspective, I'm not even sure it needs to know what representation data to provide other than commands that specialize in returning a particular type of data (e.g., 'ls' returns objects in text form, 'get' in tcl text form, maybe 'facetize' in mesh form and 'brep' in nurbs form) |
| 04:30.50 | brlcad | and for that, the first two generalize to a text blob result, and the latter two can be viewed as creating an object and generating OBJECT_ADDED events |
| 04:31.43 | brlcad | keepin it simple is good |
| 05:39.15 | *** join/#brlcad albertcoder (~albertcod@202.164.53.117) |
| 06:46.03 | *** join/#brlcad teepee (~teepee@gateway/tor-sasl/teepee) |
| 07:14.41 | *** join/#brlcad Zhao_Anqing (~clouddrif@183.157.160.13) |
| 07:34.11 | *** join/#brlcad albertcoder (~albertcod@101.215.119.112) |
| 07:36.56 | *** join/#brlcad d_rossberg (~rossberg@66-118-151-70.static.sagonet.net) |
| 08:19.26 | *** join/#brlcad oana_ (~elf11@p5.eregie.pub.ro) |
| 08:20.35 | *** join/#brlcad pandrei (~pandrei@188.25.173.120) |
| 08:39.09 | pandrei | Daniel: I've been looking at mode method |
| 08:39.13 | pandrei | you ve told me to investigate |
| 08:39.39 | pandrei | and the mode unsigned char struct field |
| 08:40.26 | pandrei | and it's pretty obvious that it sets the bot's type, like RT_BOT_SURFACE, RT_BOT_SOLID, RT_BOT_PLATE and RT_BOT_PLATE_NOCOS |
| 08:45.40 | d_rossberg | fine, then the interface should have a self-explaining/self-consistent method for setting this mode |
| 08:45.46 | d_rossberg | maybe with an enum? |
| 08:47.00 | pandrei | hmm |
| 08:47.49 | pandrei | I'm not sure if I get your point, enum like {surface, solid, plate, nocos} ? |
| 08:48.38 | *** join/#brlcad teepee- (bc5c2133@gateway/web/freenode/ip.188.92.33.51) |
| 08:52.32 | d_rossberg | yes, or do you have another idea? |
| 08:59.13 | pandrei | hm, not really, but I'm a bit confused of an aspect |
| 08:59.19 | pandrei | enum values are actually integer |
| 09:00.13 | pandrei | ah, no, no, it makes sense now |
| 09:00.16 | pandrei | apparently RT_BOT_SURFACE is 1 |
| 09:03.26 | d_rossberg | the values are still saved as chars in the _internal structure |
| 09:04.12 | d_rossberg | and you should explicitely cast them, e.g. "case surface: value = RT_BOT_SURFACE" |
| 09:05.06 | d_rossberg | don't trust in the actual order as somebody could change it |
| 09:06.34 | pandrei | ah, that's good to know |
| 09:08.15 | pandrei | but the cast should be done in the implementation, right? |
| 09:08.41 | d_rossberg | right :) |
| 09:10.34 | pandrei | since you're already here, aside of mode, was there any issue I should address before resubmitting the interface? |
| 09:10.51 | pandrei | I've removed Face class and moved Thickness and Normal methods into Triangle |
| 09:38.22 | *** join/#brlcad teepee (~teepee@gateway/tor-sasl/teepee) |
| 09:49.58 | Notify | 03BRL-CAD Wiki:130.216.215.253 * 7452 /wiki/Talk:Google_Summer_of_Code: AP242 P21 file |
| 09:52.05 | *** join/#brlcad Zhao_Anqing (~clouddrif@183.157.160.7) |
| 10:04.28 | *** join/#brlcad teepee- (bc5c2133@gateway/web/freenode/ip.188.92.33.51) |
| 10:20.45 | d_rossberg | pandrei: orientation and flags? |
| 10:26.01 | Notify | 03BRL-CAD Wiki:Ankeshanand * 7453 /wiki/User:Ankeshanand/GSoC14/logs: /* Week 7 */ |
| 10:48.51 | *** join/#brlcad FreezingCold (~FreezingC@135.0.41.14) |
| 11:27.16 | starseeker | brlcad: the trick with returning "text blobs" though is the dm needs some context to know how to interpret the result - vlists could be a wireframe or they could be instructions for polygons, and unless that gets encoded directly into the vlist serialization (which I guess might be the right way) we'll need some sort of notion of data type |
| 11:29.12 | starseeker | braces himself for a rel8 branch sync... that's been a while... |
| 11:29.38 | starseeker | how do we word the deprecation notice for that one? |
| 11:31.50 | starseeker | hmm... unless we carry the plot around in the display list object, we'll need to have autoview calculate all the plots from the display list on the fly - that'll probably slow autoview down a lot |
| 11:32.47 | *** join/#brlcad teepee- (bc5c2133@gateway/web/freenode/ip.188.92.33.51) |
| 11:35.03 | starseeker | grumble... I guess we might have to carry around that info, since a lot of the commands seem to directly use it in their operations... |
| 11:35.31 | starseeker | can't do a proper brep edge approach until the booleans are in shape |
| 11:36.21 | starseeker | and even then it might not be fast enough |
| 11:39.34 | pandrei | daniel: what do you mean with orientation and flags? Should orientation be bool ? |
| 11:40.46 | d_rossberg | what are the possible values for the orientation? |
| 11:41.47 | pandrei | well if I look in rtgeom.h |
| 11:42.04 | pandrei | @brief 0 -> ccw, !0 -> cw |
| 11:42.10 | pandrei | so I figured bool will do |
| 11:43.24 | pandrei | as for flags, I don't fully understand why it's & between the flags var |
| 11:43.46 | d_rossberg | ??? are we looking at the same file? see lines 679 to 681 in rtgeom.h |
| 11:44.22 | pandrei | ah |
| 11:44.29 | pandrei | now I figured the confusion |
| 11:44.40 | pandrei | I was looking in /usr/brlcad/dev/include/rtgeom.h |
| 11:44.42 | pandrei | which is the old one |
| 11:44.52 | pandrei | not in brlcad updated sources |
| 11:44.55 | pandrei | yeah, it makes sense |
| 11:45.06 | pandrei | ignore my last patch on sourceforge until I edit it |
| 11:45.55 | d_rossberg | for the flags: i see 3 possible flags, each one is a bool |
| 11:46.13 | pandrei | ok, so the flags are "split" like that |
| 11:46.29 | pandrei | I would make the orientation in two bools |
| 11:46.49 | pandrei | one for cw and one for unoriented, or should I make an enum as well? |
| 11:49.11 | d_rossberg | i'm in favor for an additional enum |
| 11:49.53 | d_rossberg | btw, if you look at the flags you'll see tha each one sets/unsets a bit |
| 12:25.48 | pandrei | I've noticed that |
| 12:26.26 | pandrei | but I was wondering why that method was chosen, instead of some values(i.e 1, 2, 3) |
| 12:39.09 | d_rossberg | these bits are boolean flags, you can set/reset/test for this flags with masks and bitwise boolean operations (|, &, ...) |
| 12:39.41 | d_rossberg | || =! | |
| 12:40.42 | d_rossberg | äh || != | |
| 12:42.01 | pandrei | yeah |
| 12:42.14 | pandrei | I've edited the interface submitted on sourceforge |
| 13:23.20 | starseeker | winces - last rel8 sync was Dec. 31st, 2010 |
| 13:23.23 | *** join/#brlcad kintel (~kintel@unaffiliated/kintel) |
| 13:23.46 | starseeker | almost 20000 commits ago |
| 13:24.04 | starseeker | sets up the merge command and grabs popcorn |
| 13:28.46 | *** join/#brlcad FreezingCold (~FreezingC@135.0.41.14) |
| 14:08.38 | *** join/#brlcad piyushparkash (~piyushpar@59.91.255.141) |
| 15:08.47 | *** join/#brlcad kintel (~kintel@unaffiliated/kintel) |
| 15:11.39 | brlcad | starseeker: you should tell it to merge everything so it has the proper mergeinfo set |
| 15:11.56 | brlcad | I think that branch was started when svn wasn't doing so hot with merge tracking |
| 15:13.49 | brlcad | d_rossberg: did you have an algorithm in mind for turning mesh/point data into pipe lines? |
| 15:16.38 | brlcad | starseeker: seems wrong to me on the surface for libged to return vlists data as that is arguably presentation of data (and as I mentioned, we don't have commands that I can think of that directly needs to know about that data) |
| 15:17.48 | brlcad | so like the draw command, it wouldn't ask librt for plot vlist data and return it -- it would simply return the list of objects/paths to be drawn and create "draw me" events |
| 15:18.19 | brlcad | the app would figure out that it's in wireframe mode or whatever mode and ask libdm or librt to do some work |
| 15:19.14 | brlcad | starseeker: as for deprecation notice, I think that every place there's support that is user-exposed, it should probably be itemized in CHANGES .. |
| 15:19.47 | brlcad | otherwise it's going to be a very broad statement... which would also be fine, but less trackable :) |
| 15:20.09 | d_rossberg | brlcad: i think no, but i'm not sure what you mean |
| 15:21.13 | brlcad | d_rossberg: I think it was you? maybe it was Tom? .. there's a gsoc project idea to convert mesh wires (e.g., imported from Pro/E or other systems) into pipe solids |
| 15:22.15 | brlcad | http://brlcad.org/wiki/Convert_BoT_to_Pipe |
| 15:23.03 | brlcad | never mind, that IP address looks like it was probably Tom :) |
| 15:25.06 | d_rossberg | ok, found it: https://google-melange.appspot.com/gsoc/proposal/review/org/google/gsoc2014/foposseleger/5629499534213120 |
| 15:25.25 | d_rossberg | and it wasn't me ;) |
| 15:28.23 | brlcad | okay thanks .. let me know if you think of a great algorithm for it ;) |
| 15:30.59 | Notify | 03BRL-CAD:carlmoore * 61566 brlcad/trunk/misc/CMake/BRLCAD_CheckFunctions.cmake: remove trailing blanks/tabs; misc/tools stuff is now automatically removed from such listing |
| 15:44.32 | *** join/#brlcad clock (~clock@77-58-143-135.dclient.hispeed.ch) |
| 15:45.06 | *** join/#brlcad teepee (~teepee@gateway/tor-sasl/teepee) |
| 15:46.19 | n_reed | starseeker, brlcad: wrt to autoview, halfspace comes to mind as the thing whose bbox (if you say it has one) doesn't tell you how to size the view for its plot |
| 15:48.24 | n_reed | I've also noticed autoview doesn't work well in a perspective projection (at least in Archer) |
| 15:58.01 | *** join/#brlcad albertcoder (~albertcod@202.164.53.117) |
| 16:37.21 | *** join/#brlcad albertcoder (~albertcod@202.164.53.117) |
| 16:43.29 | Notify | 03BRL-CAD:n_reed * 61567 brlcad/branches/brep-debug/src/libbrep/boolean.cpp: move duplicate code to function, renaming vars and adding comments |
| 16:53.23 | Notify | 03BRL-CAD:starseeker * 61568 (brlcad/branches/rel8/include/analyze.h brlcad/branches/rel8/include/anim.h and 55 others): Sync rel8 with trunk through r61565 - part 1 |
| 17:01.32 | Notify | 03BRL-CAD:starseeker * 61569 (brlcad/branches/rel8/misc/win32-msvc/CMakeLists.txt brlcad/branches/rel8/misc/win32-msvc/Dll/BrlcadCore.def and 5 others): Sync rel8 with trunk through r61565 - part 2 |
| 17:12.15 | *** join/#brlcad kintel (~kintel@unaffiliated/kintel) |
| 17:45.32 | Notify | 03BRL-CAD:indianlarry * 61572 brlcad/trunk/misc/CMake/BRLCAD_CheckFunctions.cmake: Fix the brlcad_config.h.in logic |
| 17:47.00 | *** join/#brlcad albertcoder (~albertcod@101.208.22.91) |
| 17:56.08 | Notify | 03BRL-CAD:carlmoore * 61573 brlcad/trunk/doc/docbook/system/man1/en/pix-ps.xml: add -l info, remove -h info, and add commas |
| 18:04.34 | Notify | 03BRL-CAD:n_reed * 61574 brlcad/trunk/src/conv/3dm/conv3dm-g.cpp: need limits for std::numeric_limits |
| 18:10.15 | Notify | 03BRL-CAD:ejno * 61575 brlcad/trunk/src/conv/3dm/conv3dm-g.cpp: cleanups; use int for loops |
| 18:11.24 | *** join/#brlcad clock (~clock@77-58-143-135.dclient.hispeed.ch) |
| 18:12.07 | Notify | 03BRL-CAD:n_reed * 61576 (brlcad/branches/brep-debug/BUGS brlcad/branches/brep-debug/CMakeLists.txt and 24 others): sync from trunk through r61575 |
| 18:19.05 | Notify | 03BRL-CAD:ejno * 61577 brlcad/trunk/src/conv/3dm/conv3dm-g.cpp: add comments |
| 18:31.52 | Notify | 03BRL-CAD:ejno * 61578 brlcad/trunk/src/conv/3dm/conv3dm-g.cpp: cleanups |
| 18:46.50 | *** join/#brlcad kintel (~kintel@unaffiliated/kintel) |
| 18:52.23 | *** join/#brlcad piyushparkash (~piyushpar@59.91.255.141) |
| 19:02.01 | *** join/#brlcad clock (~clock@77-58-143-135.dclient.hispeed.ch) |
| 19:09.57 | *** join/#brlcad albertcoder (~albertcod@101.215.123.48) |
| 19:12.28 | Notify | 03BRL-CAD:starseeker * 61580 brlcad/branches/openscenegraph/include/ged.h: Rather than get into libged at all, is there enough information in the various GED structures to map information to a new libdm structure? Test that first, because libged refactoring needs a lot of design thought. |
| 19:12.35 | Notify | 03BRL-CAD:starseeker * 61579 (brlcad/branches/rel8/misc/NIST_DENSITIES brlcad/branches/rel8/misc/archlinux/PKGBUILD and 16 others): Sync rel8 with trunk through r61565 - part 4 |
| 19:14.30 | starseeker | brlcad: so (for example) with rtcheck's overlap visualization, how do you envision returning that from libged to libdm? |
| 19:18.51 | *** join/#brlcad Izakee (~Isaac@195.24.220.134) |
| 19:19.06 | starseeker | votes that g5-g4 and g4-g5 go away - any functionality they offer can be functions/options in dbupgrade |
| 19:20.11 | Notify | 03BRL-CAD:starseeker * 61581 (brlcad/branches/rel8/doc/BRL-CAD.bib brlcad/branches/rel8/doc/PROJECTS and 392 others): Sync rel8 with trunk through r61565 - part 5 |
| 19:33.24 | Notify | 03BRL-CAD:ejno * 61582 brlcad/trunk/src/conv/3dm/conv3dm-g.cpp: check for and ignore meshes with zero vertices or faces |
| 19:55.20 | *** join/#brlcad jasleen (~jasleen@117.255.245.124) |
| 20:10.44 | Notify | 03BRL-CAD:starseeker * 61583 (brlcad/branches/rel8/src/other/boost/LICENSE_1_0.txt =================================================================== and 26 others): Sync rel8 with trunk through r61565 - part 6 |
| 20:15.29 | Notify | 03BRL-CAD:brlcad * 61584 brlcad/trunk/src/rt/viewweight.c: Account for the hypersample rays in the volume calculation so that the volume and mass calculations are correct |
| 20:16.32 | *** join/#brlcad albertcoder (~albertcod@202.164.53.117) |
| 20:18.23 | Notify | 03BRL-CAD:brlcad * 61585 brlcad/trunk/BUGS: rtweight is fixed |
| 20:19.46 | Notify | 03BRL-CAD:brlcad * 61586 brlcad/trunk/AUTHORS: rishub helped fix the aforementioned commit that fixed rtweight hypersampling |
| 20:37.09 | *** join/#brlcad albertcoder (~albertcod@202.164.53.117) |
| 20:44.49 | *** join/#brlcad javampire (~ncsaba@p4FF714BF.dip0.t-ipconnect.de) |
| 20:45.53 | javampire | brlcad: I just read your discussion with starseeker about libged/libdm entanglements related to the view concept which both need |
| 20:46.44 | javampire | starseeker: did you consider to extract the part which both of those need in a extra library which is used by both libdm and libged ? |
| 20:48.14 | javampire | just write something like a "libview" and make them both use it |
| 20:48.39 | javampire | not sure if that makes sense, just my 2c |
| 20:49.43 | Notify | 03BRL-CAD Wiki:Albertcoder * 7454 /wiki/User:Albertcoder/GSoC2014/logs: /* Week 7 */ |
| 20:49.47 | javampire | (I will leave now IRC, but will read up on the logs later) |
| 21:06.20 | ankesh11 | Screenshot of the results view I have been working on: http://i.imgur.com/HN3fc97.png |
| 21:06.46 | ankesh11 | brlcad: hsrai: Feedback? |
| 21:32.53 | starseeker | yeah, bot raytracing is totally broken - even a sphere facetization fails |
| 21:40.54 | Notify | 03BRL-CAD:starseeker * 61587 (brlcad/branches/rel8/src/other/URToolkit/Makefile.am brlcad/branches/rel8/src/other/URToolkit/cnv/Makefile.am and 677 others): Sync rel8 with trunk through r61565 - part 7 |
| 21:47.03 | Notify | 03BRL-CAD:starseeker * 61588 (brlcad/branches/openscenegraph/AUTHORS brlcad/branches/openscenegraph/BUGS and 9 others): Sync through trunk r61587 |
| 21:47.17 | Notify | 03BRL-CAD:starseeker * 61589 (brlcad/branches/gecode/AUTHORS brlcad/branches/gecode/BUGS and 9 others): Sync through trunk r61587 |
| 21:47.28 | Notify | 03BRL-CAD:starseeker * 61590 (brlcad/branches/bullet/AUTHORS brlcad/branches/bullet/BUGS and 9 others): Sync through trunk r61587 |
| 21:53.46 | starseeker | ponders the advisability of a script to run that syncs trunk to all the branches (or at least, the subset of them for which that makes sense...) |
| 21:54.58 | *** join/#brlcad ``Erik_ (~erik@pool-74-103-94-19.bltmmd.fios.verizon.net) |
| 22:12.23 | starseeker | 61337 is where the problem appeared |
| 22:12.30 | starseeker | (bot raytracing) |
| 22:17.05 | *** join/#brlcad clock (~clock@77-58-143-135.dclient.hispeed.ch) |
| 22:17.31 | Notify | 03BRL-CAD Wiki:Ankeshanand * 0 /wiki/File:ResultsInterface.png: |
| 22:18.24 | Notify | 03BRL-CAD Wiki:Ankeshanand * 7456 /wiki/User:Ankeshanand/GSoC14/logs: /* Week 7 */ |
| 22:38.47 | Notify | 03BRL-CAD:starseeker * 61591 (brlcad/branches/rel8/AUTHORS brlcad/branches/rel8/BUGS and 1791 others): Sync rel8 with trunk through r61565 - part 8 |
| 22:44.34 | starseeker | the problem (locally, at least, is line 73 of g_bot_include.c - m4 >= tol->para is failing for all points. |
| 22:46.38 | starseeker | arrgh - the failur in trunk is different from the failure at 61337 |
| 22:47.34 | starseeker | n_reed: well, I guess that explains why you weren't seeing the failure - it's not the 61337 problem, that must have been fixed |
| 22:48.16 | Notify | 03BRL-CAD:starseeker * 61592 (brlcad/branches/rel8/AUTHORS brlcad/branches/rel8/BUGS and 9 others): Sync rel8 with trunk through r61591 |
| 22:50.02 | starseeker | weird |
| 22:50.08 | starseeker | alright, later for this |
| 23:15.23 | *** join/#brlcad archivist (~archivist@host81-149-189-98.in-addr.btopenworld.com) |
| 23:15.40 | *** join/#brlcad teepee (~teepee@gateway/tor-sasl/teepee) |
