IRC log for #brlcad on 20140703

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)

Generated by irclog2html.pl Modified by Tim Riker to work with infobot.