| 00:16.14 | *** join/#brlcad kintel (~kintel@unaffiliated/kintel) | |
| 01:18.56 | *** join/#brlcad kintel (~kintel@unaffiliated/kintel) | |
| 01:23.01 | *** join/#brlcad FreezingCold (~FreezingC@135.0.41.14) | |
| 01:44.14 | *** join/#brlcad kintel (~kintel@unaffiliated/kintel) | |
| 02:23.05 | starseeker | Well, looks like the community edition of Visual Studio 2013 can build BRL-CAD |
| 03:30.23 | Notify | 03BRL-CAD Wiki:AnshulaRudhraraju * 0 /wiki/User:AnshulaRudhraraju: |
| 04:18.42 | *** join/#brlcad kintel (~kintel@unaffiliated/kintel) | |
| 04:18.59 | *** join/#brlcad FreezingCold (~FreezingC@135.0.41.14) | |
| 07:13.03 | *** join/#brlcad infobot (ibot@rikers.org) | |
| 07:13.03 | *** topic/#brlcad is BRL-CAD || http://brlcad.org || logs: http://ibot.rikers.org/%23brlcad/ || GCI winners: Jacob Burroughs and Peter Amidon! || GSoC 10th Year Reunion, 7 CAD community members meeting up in California! | |
| 07:19.01 | *** join/#brlcad infobot (ibot@rikers.org) | |
| 07:19.01 | *** topic/#brlcad is BRL-CAD || http://brlcad.org || logs: http://ibot.rikers.org/%23brlcad/ || GCI winners: Jacob Burroughs and Peter Amidon! || GSoC 10th Year Reunion, 7 CAD community members meeting up in California! | |
| 07:48.44 | *** join/#brlcad infobot (ibot@rikers.org) | |
| 07:48.44 | *** topic/#brlcad is BRL-CAD || http://brlcad.org || logs: http://ibot.rikers.org/%23brlcad/ || GCI winners: Jacob Burroughs and Peter Amidon! || GSoC 10th Year Reunion, 7 CAD community members meeting up in California! | |
| 08:32.12 | *** join/#brlcad ries (~ries@D979EA84.cm-3-2d.dynamic.ziggo.nl) | |
| 08:38.38 | *** join/#brlcad ishwerdas (3b5be9ce@gateway/web/cgi-irc/kiwiirc.com/ip.59.91.233.206) | |
| 08:42.04 | ishwerdas | @maths22 |
| 08:42.29 | ishwerdas | what is happening regarding getting the website updated |
| 08:44.26 | ishwerdas | I just saw that theme has been changed |
| 08:48.14 | ishwerdas | *the wiki theme has been changed, are there any plans to change wp theme too ? |
| 09:01.13 | *** join/#brlcad andrei (~andrei@5-12-112-217.residential.rdsnet.ro) | |
| 09:22.41 | *** join/#brlcad ishwerdas (3b5be9ce@gateway/web/cgi-irc/kiwiirc.com/ip.59.91.233.206) | |
| 09:44.47 | *** join/#brlcad simran (~simran@101.58.5.151) | |
| 12:03.06 | *** join/#brlcad simran (~simran@101.58.24.191) | |
| 12:50.15 | *** join/#brlcad FreezingCold (~FreezingC@135.0.41.14) | |
| 13:51.16 | *** join/#brlcad clock (~clock@212.203.58.127) | |
| 16:12.16 | *** join/#brlcad ishwerdas (3b5be9ce@gateway/web/cgi-irc/kiwiirc.com/ip.59.91.233.206) | |
| 16:25.06 | *** join/#brlcad kintel (~kintel@unaffiliated/kintel) | |
| 16:28.30 | *** join/#brlcad teepee (~teepee@gateway/tor-sasl/teepee) | |
| 16:29.17 | *** join/#brlcad deepak_ (~chatzilla@117.220.173.181) | |
| 16:34.50 | *** join/#brlcad kintel (~kintel@unaffiliated/kintel) | |
| 17:20.27 | *** join/#brlcad ries (~ries@D979EA84.cm-3-2d.dynamic.ziggo.nl) | |
| 17:44.35 | *** join/#brlcad sofat (~sofat@202.164.45.204) | |
| 18:02.26 | sofat | brlcad, hello |
| 18:28.20 | *** join/#brlcad Izakey (~Isaac@41.205.22.13) | |
| 18:47.26 | *** join/#brlcad gaganjyot (~gaganjyot@124.253.70.210) | |
| 18:59.56 | *** join/#brlcad ries (~ries@D979EA84.cm-3-2d.dynamic.ziggo.nl) | |
| 19:18.28 | *** join/#brlcad gaganjyot (~gaganjyot@124.253.197.6) | |
| 19:20.32 | *** join/#brlcad ``Erik_ (~erik@pool-74-103-94-19.bltmmd.fios.verizon.net) | |
| 19:20.57 | *** join/#brlcad Ch3ck__ (~Ch3ck@66-118-151-70.static.sagonet.net) | |
| 19:22.17 | *** join/#brlcad javampir1 (~javampire@unaffiliated/javampire) | |
| 20:00.34 | *** join/#brlcad ejno_ (~ejno@unaffiliated/kazaik) | |
| 20:01.25 | *** join/#brlcad gaganjyot (~gaganjyot@124.253.193.212) | |
| 20:09.14 | *** join/#brlcad n_reed_ (~molto_cre@66-118-151-70.static.sagonet.net) | |
| 20:10.59 | *** join/#brlcad kanzure (~kanzure@131.252.130.248) | |
| 20:29.21 | *** join/#brlcad ejno (~ejno@unaffiliated/kazaik) | |
| 20:30.50 | Notify | 03BRL-CAD:ejno * 63453 (brlcad/trunk/src/libged/simulate/physics_world.cpp brlcad/trunk/src/libged/simulate/physics_world.hpp brlcad/trunk/src/libged/simulate/simulate.cpp): fix bug in which the WorldObject's btMotionState was not initialized correctly |
| 21:08.42 | brlcad | starseeker: awesome ... now I don't need to make a gci task to test that ;) |
| 21:11.12 | deepak_ | brlcad: Hi |
| 21:16.21 | deepak_ | brlcad, I'm done with the installation of OGV and I tested it on my local machine. I faced certain problems which I reported on devel-mailing list, now it's running well. I want to send a patch for installation step as discussed with you yesterday, but I'm confused whether to include it in .txt file or ReadME.md as provided on github. |
| 21:20.48 | *** join/#brlcad andrei__ (~andrei@5-12-112-217.residential.rdsnet.ro) | |
| 21:21.25 | *** join/#brlcad kintel (~kintel@unaffiliated/kintel) | |
| 22:15.57 | Notify | 03BRL-CAD:starseeker * 63454 brlcad/trunk/src/tclscripts/util/CMakeLists.txt: I think we may have this functionality elsewhere, and it really should live as a sub-command of a 'bot' command that should mimic what brep does for NURBS, but until it gets sorted toss in this convenience script for converting all regions in a .g file into bots while preserving the tree structure. |
| 22:44.57 | *** join/#brlcad ries (~ries@D979EA84.cm-3-2d.dynamic.ziggo.nl) | |
| 22:58.51 | ``Erik_ | wonders if archer is far enough along to use as the main program if someone were to, say, make an app bundle |
| 22:59.23 | starseeker | ``Erik: probably not, in my estimate |
| 23:00.00 | starseeker | some of MGED's functionality is still missing or very hard to use |
| 23:00.48 | ``Erik | hm, is that functionality something a new user would care about? |
| 23:00.58 | starseeker | hard to say |
| 23:01.45 | ``Erik | I'm guessing that having a single icon to click to "get started" would be a huge win, even if it's not the whole enchillada |
| 23:02.01 | starseeker | nods - one of the reasons I've been putting work into the Qt gui |
| 23:02.26 | starseeker | isn't comfortable enough with Tcl/Tk (especially Itcl/Itk) to make Archer what it really needs to be |
| 23:02.37 | ``Erik | *shrug* it's been a topic on and off for years, figured I'd throw it out again since we're about to have very newbie users hit us :) |
| 23:03.46 | ``Erik | (and I gotta ask if we're shooting ourselves in the foot by not throwing an 'easy' version in front of people even if it's not 100%) |
| 23:03.50 | starseeker | unfortunately, I'm just now starting to hit the really hard stuff: a) 3D display interaction MGED-style without MGED, b) how to tell what object or objects have been changed by various commands (and hence what needs to be updated in the GUI) c) probably lots of other stuff... |
| 23:04.29 | starseeker | for a) it's quite likely that a significant chunk of MGED's logic is going to have to be moved down into libs, which is a mean job |
| 23:04.55 | ``Erik | lemme try to come up with a car analogy... it'd be like not letting kids use a drivers ed car because the turbo doesn't have a boost selector hooked up yet... :D |
| 23:05.00 | starseeker | for b), I basically need a way to have libged commands return a list of directory pointers that I need to process (string results just won't cut it) |
| 23:05.12 | starseeker | heh |
| 23:06.29 | starseeker | ``Erik: you're the OpenGL/game guru, feel like diving into the display code? |
| 23:08.09 | ``Erik | um, d'no if "guru" is applicable... I was getting ready to jump back into some low level darwin code to extract kernel info (making an osX app to graph memory usage xload style in the dock and do things like purge cache pages) |
| 23:08.25 | starseeker | heh |
| 23:08.56 | starseeker | doesn't that already exist? or do you plan to expose lower level operations? |
| 23:09.03 | ``Erik | if ya want someone to bounce ideas off of, I can comment some... |
| 23:09.32 | ``Erik | the monitor part exists sorta in Activity Monitor.app if you open the window and select the memory pane... it doesn't put memory in the dock... |
| 23:09.53 | starseeker | ``Erik: as near as I can tell, it boils down to the fact that MGED exerts very low level control over what is drawn, and that manipulation logic lives inside MGED itself |
| 23:10.21 | starseeker | for example, illumination mode in MGED constitutes of drawing white lines instead of the "standard" wireframe, and that is totally managed at the application level |
| 23:10.23 | ``Erik | and the purge type activities can be done with a third party app called "MemoryKeeper", but it likes to phone home a lot and is klunky to use |
| 23:10.31 | starseeker | nods |
| 23:11.09 | ``Erik | I wrote a program to force cache expirations many many years ago when I was benchmarking some hardcore stuff on linux, it happens to work on osX, but is a manual process... "soil 1000" in a terminal |
| 23:11.26 | starseeker | so if I want another application to be able to "illuminate" geometry, I either have to implement a whole new mechanism for doing that or move the concept of "illumination" down into libdm |
| 23:11.44 | starseeker | ``Erik: cool - that'll be a nifty tool :-) |
| 23:12.00 | ``Erik | mged's draw logic is from a very archaic way of using opengl... :/ |
| 23:12.31 | starseeker | ditto for labeling during editing - drawing the labels and such is all up to the application |
| 23:12.36 | ``Erik | "these are the pixels to update", where the normal opengl approach for the last 20 years has been "blast it all, draw it all every frame" |
| 23:13.20 | starseeker | it is a sore temptation to just ignore MGED and try to implement a new way from scratch, but that's just too dangerous |
| 23:13.42 | ``Erik | seperating the state from the drawing might help... |
| 23:14.05 | starseeker | nods - separating is basically the key word to the whole problem |
| 23:14.22 | ``Erik | the isst ogl texture approach is probably how the rt results should be done, GL_LINES is good for wireframe |
| 23:14.39 | starseeker | but there's a lot of very old, archic stuff that has to be messed with - half the time I don't even know how to test whatever is being worked to see if I'm breaking it |
| 23:14.50 | ``Erik | yeh |
| 23:15.07 | starseeker | with the new OpenSceneGraph work, I'm using the isst ogl approach for the raytracing |
| 23:15.35 | starseeker | with the old way as a fallback for environments like VirtualBox that have really old/crappy OpenGL support |
| 23:16.24 | ``Erik | *ponder* either the direction of communication has to change, or the dm has to be changed to retain the entire draw state, I'd think? |
| 23:16.40 | starseeker | right - my thought is the latter |
| 23:16.52 | ``Erik | instead of saying "ok, dm, draw this vlist.", the dm would say "yup, I'm drawing, gimme your vlists" |
| 23:16.57 | starseeker | the application should be dealing in higher level objects, primarily |
| 23:17.10 | ``Erik | for the communication direction change |
| 23:17.46 | starseeker | for "view" objects the application would define a vlist, but for database objects (geometry) it should just tell the dm what objects are up and let the dm figure out with librt what the best way to do things is |
| 23:20.13 | ``Erik | I guess since the scenegraph is really simple for current mged, it probably wouldn't take to much to write a dm that holds the state correctly... a list of lists for the wireframes, a list of labels, ... and a single origin point/quaternion for drawing the compass? |
| 23:20.15 | starseeker | I suppose the app should be able to override and provide its own vlists for a geometry object if it insists, but by default it shouldn't have to |
| 23:21.09 | ``Erik | then bang out a thread to crank the opengl window as needed and call it a day |
| 23:21.13 | starseeker | ``Erik: probably, but any change at all to the libdm/MGED interaction touches a *lot* of code in libdm, libged and MGED |
| 23:21.51 | ``Erik | oh, I know... the entire architecture is ... backwards for the current reality :D |
| 23:21.53 | starseeker | I refactored some of that a couple months back, but I didn't get to rip into MGED at all |
| 23:22.35 | starseeker | some of the libged drawing C logic makes me dizzy - it's either a lot more complicated than it needs to be or there are aspects of the problem I haven't properly understood yet |
| 23:23.30 | ``Erik | probably a little bit of both |
| 23:25.06 | starseeker | if I'm not mistaken, there's a flag that lets you draw all objects that meet certain attribute criteria |
| 23:25.31 | starseeker | I'd rather delegate that to search, sort of like I did for the new gdiff command line tool |
| 23:26.47 | ``Erik | that'd be cool, then the matching could be generalized... "just show me rha, just show me regions with "powertrain" in the path, just show me ..." |
| 23:28.10 | starseeker | right - draw -F "-name sector_3*.r -attr part=1998-A3" or some such |
| 23:30.04 | starseeker | but in that scenario, the draw command's only job would be to process its args, pass the filters on to search for assembly of the display list, update the display list, and pass the updated list to dm" |
| 23:30.46 | starseeker | right now, it seems to be either MGED or libged's responsibility to assemble a list of solids, and it is that solids list which is used for much of the real drawing work |
| 23:30.49 | ``Erik | or say "yo, dm, this is the new current filter." |
| 23:31.41 | starseeker | the solids list is actually the major incompatibility with modern scene graph managment as far as I can tell, but it's also central to how MGED handles things like illumination and editing |
| 23:32.47 | ``Erik | bleh, kernel function with no man page |
| 23:32.55 | ``Erik | and weird results |
| 23:33.08 | starseeker | that's an interesting concept - have the dm use a filter to establish its own display list. |
| 23:33.32 | ``Erik | yeh, like libregex does with it's compiled regex programs |
| 23:34.06 | ``Erik | except for ... cliffex (the most irregular of the irregular expressions) |
| 23:34.22 | starseeker | heh - regular is just so boring... |
| 23:34.56 | starseeker | if you set (say) a drawing filter that matched all regions, any time you used "r" to create a new region it would automatically get drawn |
| 23:36.55 | starseeker | interesting idea. It's probably an option to have in addition to an explicitly maintained list, but I can see some cool possibilities |
| 23:40.07 | starseeker | I think the ged_drawtrees logic is one of the pieces that'll need to move into into libdm for this to work properly |
| 23:42.18 | starseeker | the utility of the solids list is that it provides an easy way to know what object or objects need to have their representations changed if a solid is edited... of course, that solids list has to be updated every time anything under a given object is changed (e.g. tree edit in a comb) |
| 23:42.49 | starseeker | which, come to think of it, might be why MGED doesn't let you sed if an object is in the view multiple times - it complicated the syncing problem |
| 23:43.39 | ``Erik | if the dm were managing the state (or live querying state to completely pack before displaying), that would simplify a lot |
| 23:44.17 | ``Erik | but that assumes the dm wants to draw the whole context frequently... great approach for modern hw, not how BRL-CAD is wired |
| 23:44.28 | starseeker | nods |
| 23:45.21 | starseeker | it's similar in some ways to the problem of showing related objects in the tree view - whenever something changes, anything (or potentially everything, for that matter) about the previous representational state is invalid and must be reassessed |
| 23:46.27 | starseeker | finding out what changed can be expensive when objects can be re-used everything in the hiearchy, which is probably why they punted the way they did back in the day |
| 23:49.46 | Notify | 03BRL-CAD:starseeker * 63455 brlcad/trunk/src/conv/CMakeLists.txt: Apply the updated ply-g importer from patch #291 by Rishub Jain (https://sourceforge.net/p/brlcad/patches/291/) |
| 23:52.27 | ``Erik | changes an 'if' to a 'while' and sees if his computer explodes O.o |
| 23:52.43 | starseeker | heh - ah, the joys of while loops |