| 01:04.12 | *** join/#brlcad Nohla (~Nohla@64.76.19.227) | |
| 04:16.11 | starseeker | O.o https://github.com/pyb/zen |
| 04:16.26 | starseeker | too bad it's GPL, but that's still nifty |
| 06:57.52 | Ralith | oo, neat |
| 06:58.08 | Ralith | mightn't it be better to target that X replacement canonical is backing though? |
| 07:37.49 | *** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ) | |
| 07:42.48 | *** join/#brlcad merzo (~merzo@193.254.217.44) | |
| 09:07.45 | *** join/#brlcad Stattrav (~Stattrav@122.172.6.40) | |
| 09:07.45 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 10:03.06 | *** join/#brlcad Ralith (~ralith@S010600221561996a.vc.shawcable.net) | |
| 11:10.21 | *** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ) | |
| 11:32.13 | dloman | Mernin |
| 11:36.54 | dloman | brlcad: gource is a fun little tool =D |
| 11:37.20 | dloman | brlcad: did you do all of the brlcad commit history? If, so, I'd love to see the visualization! |
| 12:30.18 | brlcad | dloman: yeah, the whole thing -- had to modify the source to get it to behave, but it works reasonably well |
| 12:31.29 | brlcad | the physics unfortunately goes nuts with the whole tree causing the graph to get stuck |
| 12:37.22 | dloman | so did it turn out at all? |
| 12:37.54 | brlcad | oh yeah, it works great "most" of the time |
| 12:38.27 | brlcad | it might work if it's allowed to incrementally build up from scratch |
| 12:38.52 | brlcad | it'll rebuild the tree from any point on the timeline, which is how you skip forward/backward .. and those tend to get stuck |
| 12:39.01 | brlcad | trying to rebuild the massive tree after massive edits |
| 12:39.18 | dloman | cool, drop something on youtube if/when you get a chance :) |
| 12:39.31 | brlcad | haven't found a good way to capture to video yet |
| 12:40.21 | brlcad | plus, even sped up to about 4days per sec, it's still like a half-hour video :) |
| 12:40.38 | brlcad | any faster and it's just a ton of whizzing about |
| 12:41.00 | dloman | tee hee |
| 12:43.55 | starseeker | hah, that is cool |
| 12:44.12 | starseeker | like how it uses the little figures to indicate who's changing what |
| 12:45.20 | starseeker | brlcad: if you could capture video(s), that'd be a really cool briefing tool |
| 12:45.32 | starseeker | dloman: you in today? |
| 12:46.08 | brlcad | starseeker: I'm working on getting video .. I have one video screencast tool working, but it's shareware and watermarks the video |
| 12:46.31 | brlcad | the tool itself will output ppm that would be a hell of a lot of frame data |
| 12:46.44 | starseeker | brlcad: ah. I think I stumbled on one or two tools that do opengl video specifically |
| 12:47.18 | starseeker | http://taksi.sourceforge.net/ |
| 12:47.31 | brlcad | just found that :) |
| 12:48.24 | brlcad | the question du jour is whether it'll run .... bah, looks like it's windows only? |
| 12:48.47 | brlcad | dloman: so we're good to go needing a poster ;) |
| 12:49.08 | brlcad | one page of awesome |
| 12:49.10 | dloman | starseeker: not today no, tomorrow. Whats up? |
| 12:49.16 | starseeker | yukon might be an option: https://devel.neopsis.com/projects/yukon/ |
| 12:49.38 | starseeker | dloman: I'm wondering how close we are to having commands in geomclient that could retrieve and send .g files |
| 12:49.47 | dloman | brlcad: I can work on it *after* march 31 =D |
| 12:49.51 | dloman | close. |
| 12:50.03 | brlcad | oh, that's way too late :( |
| 12:50.07 | dloman | can't promise COB today, but def by COB tomrrrow |
| 12:50.39 | Ralith | looks like gource can output a ppm stream itself |
| 12:50.46 | Ralith | which could then be encoded |
| 12:50.47 | starseeker | is trying to remember if yukon is how he made the videos of g3d... |
| 12:51.07 | brlcad | Ralith: 08:46 < brlcad> the tool itself will output ppm that would be a hell of a lot of frame data |
| 12:51.27 | brlcad | missing a 'but' in there |
| 12:51.47 | dloman | brlcad: sorry, but RL has kicked me square in the nuts and I have had to take a lot of time off... so i am behind with the GS. |
| 12:54.21 | brlcad | someone else will have to come up with something then, hopefully |
| 12:54.22 | Ralith | that's what I get for not keeping up. |
| 12:54.24 | brlcad | students are submitting applications by the 28th, so that's just way too late |
| 12:54.31 | Ralith | still, too much data? |
| 12:55.24 | starseeker | brlcad: ah - https://devel.neopsis.com/projects/yukon/wiki/RewriteBranch |
| 12:55.36 | brlcad | looks |
| 12:56.51 | brlcad | starseeker: looks like that only works with x11 glx contexts? |
| 12:57.36 | starseeker | possibly |
| 12:57.56 | brlcad | I'd hate to go through all the steps again, but I might be able to crunch the frames out on a remote linux box with tons of disk, and convert to video there |
| 12:58.53 | brlcad | it was just a bit of a time sink to compile with all its deps, paying some lil shareware dev becomes appealing :) |
| 12:58.55 | starseeker | nods - surprisingly, there just aren't a whole lot of good solutions (that I know of, anyway) |
| 13:01.25 | starseeker | dloman: do you think you could spare a little time from the java side to get the .g files moving back and forth? |
| 13:04.25 | dloman | that's what Im doing ;) |
| 13:04.36 | starseeker | dloman: cool, thanks :-) |
| 13:05.06 | starseeker | got his butt kicked by a bunch of topics he knows disturbingly little about last week - sorry for not being of more concrete assistance |
| 13:05.21 | dloman | no worries |
| 13:05.33 | dloman | i havent exactly been productive recently |
| 13:06.04 | starseeker | dloman: that's not up to you - hope everything is going a little bette |
| 13:06.07 | starseeker | better even |
| 13:07.54 | dloman | heh, its when things start going better that i get scared. Murphey and his laws are having a field day ;) |
| 13:09.07 | dli | starseeker, like undo/redo? |
| 13:09.25 | starseeker | dli: how's that? |
| 13:09.53 | dli | starseeker, when you mentioned 'moving back and forth' |
| 13:10.31 | starseeker | dli: the most basic function of any client/server system is to communicate between client and server |
| 13:10.53 | dloman | brlcad: is there a quick way to print a bu_vlb to console or string as HEX ? |
| 13:11.01 | starseeker | dli: we have that (thanks to dloman) but we need to be able to send geometry back and forth |
| 13:11.29 | starseeker | dli: once we can communicate geometry files, we can think about how to store revisions of them |
| 13:12.15 | starseeker | dli: the next stage beyond that is to communicate just specific changes to parts of the .g files, and be able to retrieve specific versions of geometry from the server |
| 13:12.27 | starseeker | dli: the latter means revision control and is not easy |
| 13:13.31 | starseeker | dloman: yeah, if I ever run into Murphy I'm gonna have a word with him... |
| 13:13.51 | dli | starseeker, not easy with .g format :( maybe, easier as database entries |
| 13:14.31 | starseeker | dli: basically what's needed is to customize version control software for our specific purposes |
| 13:16.41 | starseeker | gathers up his stuff and heads in - first stop gym... |
| 13:25.09 | ``Erik | unsigned char *p = bu_vlb_addr(myvlb); for(i=0;i<bu_vlb_buflen(myvlb);i++){ printf("%02x ",*p); p++; } |
| 13:28.07 | dloman | ``Erik: thanks |
| 13:30.37 | ``Erik | (there're tricks to make that shorter, but starseeker starts sobbing when I do those) |
| 13:36.08 | CIA-52 | BRL-CAD: 03brlcad * r43890 10/brlcad/trunk/src/libbu/bitv.c: don't try to cat the str/title if it is null |
| 13:38.37 | CIA-52 | BRL-CAD: 03brlcad * r43891 10/brlcad/trunk/ (include/bu.h src/libbu/vlb.c): |
| 13:38.37 | CIA-52 | BRL-CAD: add a new bu_pr_vlb() routine for printing out diagnostic information for vlb |
| 13:38.37 | CIA-52 | BRL-CAD: structures. optionally prefixed with a title, this prints out each byte as a |
| 13:38.37 | CIA-52 | BRL-CAD: space-separated hex value. could probably use some pretty printing to group |
| 13:38.38 | CIA-52 | BRL-CAD: together for readability, but go simple for starters. |
| 13:38.55 | brlcad | dloman: turned erik's one-liner into a new bu routine, bu_pr_vlb(), see if that's suitable |
| 13:40.43 | dloman | kk will try |
| 13:40.44 | brlcad | dli: unless I missed part of the conversation, it's not specific to .g data |
| 13:41.34 | brlcad | the service allows transactional edits with history preserved, so it's just a matter of how to encode the transactions as commits |
| 13:42.55 | brlcad | the simple way is to commit the honking .g file after each change, but that's not really efficient since it's an opaque entity to revision control systems - it's not easy to extract the semantic differences between two changes |
| 13:47.42 | dli | brlcad, does it make sense to use a database backend, so, database queries can be logged (reverted), efficiency problem left to the database side |
| 13:48.26 | brlcad | that's basically what's being done with the revision control system -- it uses a database backend |
| 13:49.23 | dli | brlcad, oh, didn't realize that :( |
| 13:49.37 | brlcad | we could implement revision tracking on top of some existing rdbms, but then that would basically amount to reimplementing a version control system (like git, svn, whatever) |
| 13:50.09 | brlcad | and even then, you'd still have the problem of storing/retrieving *semantic* information from the commit |
| 14:00.13 | CIA-52 | BRL-CAD: 03davidloman * r43892 10/geomcore/trunk/src/interfaces/java/src/org/brlcad/geometryservice/net/ (GSConnection.java msg/AbstractNetMsg.java): Move message serialization entirely over to AbstractNetMsg. Consolidates serialization logic. |
| 14:16.44 | *** join/#brlcad Nohla (~Nohla@64.76.19.227) | |
| 14:26.42 | CIA-52 | BRL-CAD: 03davidloman * r43893 10/geomcore/trunk/src/interfaces/java/src/org/brlcad/geometryservice/net/msg/AbstractNetMsg.java: Forgot to serialize type. Ooops. |
| 14:27.22 | CIA-52 | BRL-CAD: 03davidloman * r43894 10/geomcore/trunk/src/interfaces/java/src/org/brlcad/geometryservice/net/GSConnection.java: Remove debug printing. Kills performance when trying to print large bytebuffers. |
| 14:27.54 | brlcad | could maybe add a size parameter |
| 14:28.30 | dloman | it was a t-shooting debug print statement anyways :) |
| 14:28.48 | dloman | turns out, printing a 1 meg byte array to console is slow. who knew?! |
| 14:32.23 | brlcad | probably someone ;) |
| 14:32.33 | dloman | most likely everyone :) |
| 14:54.58 | ``Erik | a lot faster if you dump it in a screen and swap, or pipe through less O.o the effort to display a linux kernel build in an xterm was a significant slowdown on my old 120mhz cyrix, went way faster when I put it in a screen and dropped it :) |
| 14:56.41 | dloman | now that's a new one. localhost just resolved to 127.0.1.1 |
| 14:57.07 | ``Erik | neat |
| 16:02.17 | dloman | oh bloody hell. the silly null character at the end of the string has the UUID parsing all bent out of shape :/ |
| 16:06.35 | CIA-52 | BRL-CAD: 03davidloman * r43895 10/geomcore/trunk/src/interfaces/java/src/org/brlcad/geometryservice/net/ByteBufferReader.java: Validate parsed string is == 36 characters long to allow for proper UUID generation. The UUID 'standard' for the GSNet Proto needs to be standardized. |
| 16:09.50 | CIA-52 | BRL-CAD: 03davidloman * r43896 10/geomcore/trunk/src/interfaces/java/src/org/brlcad/geometryservice/net/NetMsgFactory.java: Fill out the NetMsgFactory's switching table so that NetMsg's can actually be deserialized |
| 17:13.07 | CIA-52 | BRL-CAD: 03starseeker * r43897 10/brlcad/trunk/BUGS: Need to do some testing and confirm this, but have a report that keep is changing units to unknown on output files and dbconcating a file with unknown units wipes out the units in the parent .g |
| 17:34.55 | *** join/#brlcad Stattrav (~Stattrav@117.192.135.62) | |
| 17:34.56 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 19:02.45 | *** join/#brlcad chinu (~chinu@27.97.161.172) | |
| 19:11.32 | *** join/#brlcad Stattrav_ (~Stattrav@117.192.134.3) | |
| 19:26.47 | *** join/#brlcad chinu (~chinu@27.97.124.40) | |
| 19:28.15 | *** join/#brlcad sofichinu (~sofichinu@27.97.124.40) | |
| 19:46.10 | sofichinu | hii all, can anyone help me out for gsoc 2011 project idea - Qt Display Manager |
| 19:47.13 | starseeker | sofichinu: you've seen the posting on the website? |
| 19:48.27 | starseeker | http://brlcad.org/wiki/Qt_Display_Manager |
| 19:51.12 | sofichinu | yes i have gone through that link, and it says to review current display manager code. From where do i get to access that code? |
| 19:51.36 | starseeker | BRL-CAD's subversion repository: http://sf.net/projects/brlcad |
| 19:51.48 | starseeker | specifically, the trunk branch: |
| 19:52.01 | starseeker | svn co https://brlcad.svn.sf.net/svnroot/brlcad/brlcad/trunk brlcad |
| 19:52.42 | starseeker | also a good idea to get BRL-CAD (specifically MGED) compiled and running to see what a display manager does |
| 19:52.46 | sofichinu | thnx :) |
| 19:52.58 | starseeker | no problem |
| 19:56.01 | sofichinu | do one has to use any ide for compiling the code, because I usually use g++ compiler in ubuntu for coding in c++ |
| 19:56.23 | starseeker | nope - most of use go with command line gcc |
| 19:57.10 | sofichinu | ok |
| 19:57.48 | starseeker | sofichinu: you have Qt experience? |
| 19:59.11 | sofichinu | nopes, I started using it only after getting to know about it via gsoc |
| 19:59.33 | starseeker | nods. Just curious - what appealed to you about that project? |
| 20:01.08 | sofichinu | to be honest , requirement skills for the project is C++ and I am good at this only :P |
| 20:01.46 | sofichinu | this all made me interested in this |
| 20:02.00 | starseeker | fyi, OGRE is also C++ |
| 20:03.17 | sofichinu | yes, many other organizations are, and I am trying to go deep into project ideas to find out which one is best for me. |
| 20:03.35 | starseeker | I was thinking more about the other display manager task - the OGRE display manager :-P |
| 20:04.10 | sofichinu | oh i am sorry, |
| 20:04.19 | sofichinu | I had started using Qt |
| 20:04.29 | starseeker | the openNURBS library is also C++, if you're into mathematical stuff |
| 20:04.33 | starseeker | sofichinu: Qt is fine too |
| 20:04.34 | sofichinu | before and heard about OGRE now only |
| 20:04.48 | starseeker | we're interested in both - if you're more comfortable with Qt that's great |
| 20:05.28 | starseeker | openNURBS would pertain to the NURBS tasks on that list |
| 20:06.24 | sofichinu | which one gives more chance for getting into gsoc ? |
| 20:06.38 | starseeker | depends on your proposal and the other proposals |
| 20:07.02 | starseeker | Qt vs. OGRE won't be a make-or-break |
| 20:07.09 | sofichinu | hm... |
| 20:08.30 | sofichinu | do i need to make out some patch like usually many organizations demand that? |
| 20:08.31 | starseeker | sofichinu: I'd suggest taking a quick look at both and see which one looks more managable to you |
| 20:09.18 | starseeker | see step 9: http://brlcad.org/wiki/Google_Summer_of_Code/Checklist |
| 20:10.21 | starseeker | sofichinu: what's your background/interest? |
| 20:11.07 | sofichinu | I am a student of 2nd year in Computer Science and Engineering |
| 20:13.20 | starseeker | well, my advice would be to take a very quick look at Qt and OGRE - get a basic window up and draw a line, say, in both - just to get a feel which one you would prefer working with |
| 20:14.55 | sofichinu | ok |
| 20:15.39 | starseeker | OGRE is an accelerated 3D context, and Qt is unaccelerated but runs (or should run) pretty much anywhere without requiring any fancy hardware |
| 20:16.09 | starseeker | sort of the difference between our dm-ogl and dm-X |
| 20:16.44 | starseeker | (which is why OpenGL embedded in Qt is ruled out - the point of a Qt display manager would be "it always works") |
| 20:17.03 | sofichinu | sorry but i did not get the difference still. |
| 20:17.55 | starseeker | OpenGL provides an accelerated graphics context - when you see objects rotating around in real time in 3D, it's usually OpenGL based (unless you're on Windows, which tends to use DirectX more these days) |
| 20:18.15 | starseeker | typically, the graphics card in the computer is assisting with the drawing when OpenGL is used |
| 20:18.42 | starseeker | Raw X11 (dm-X) does NOT use any specialized acceleration hardware - it uses only the X calls themselves |
| 20:19.41 | starseeker | which means the CPU has to do a lot of work instead of offloading it to the graphics card, but ALSO means if the graphics card (or drivers) aren't working you can still bring up the display |
| 20:20.29 | sofichinu | so can we say that Qt is better |
| 20:21.12 | starseeker | Qt will work under more conditions |
| 20:21.40 | starseeker | but it also won't be able to do things like shaded display and take advantage of graphics hardware when displaying really large models |
| 20:21.52 | starseeker | it's a tradeoff - that's why we're interested in both |
| 20:22.13 | starseeker | Ideally, you do accelerated when it's available and fall back to unaccelerated when it's not |
| 20:23.10 | sofichinu | hmm.... |
| 20:23.43 | starseeker | so Qt would be using the 2D graphics stack: http://cworth.org/talks/lca_2009/html/lca-2009-006.html |
| 20:23.57 | starseeker | and OGRE would be using the 3D http://cworth.org/talks/lca_2009/html/lca-2009-007.html |
| 20:24.23 | starseeker | (OK so those are Linux specific, but the general idea is the same) |
| 20:25.40 | sofichinu | and what about in windows terms |
| 20:27.12 | starseeker | The Windows stacks look similar, just with different components at the various stages |
| 20:27.14 | starseeker | (e.g. DirectX instead of OpenGL) |
| 20:27.24 | starseeker | OGRE and Qt should abstract all that for us |
| 20:27.38 | sofichinu | ok |
| 20:28.29 | sofichinu | cant we implement the similar thing for OpenGL too? |
| 20:28.35 | starseeker | sofichinu: I'd try playing with QtCanvas and see how it behaves - for example, can you get it to draw and update 2D lines quickly? |
| 20:29.01 | starseeker | sofichinu: we can (in fact, we do - that's dm-ogl and dm-wgl) but OpenGL itself is not a fully cross platform API |
| 20:29.36 | starseeker | that's why we have one for wgl (Windows), one for GLX (Linux), and we would need one for Mac if we wanted to get the native Aqua interface running |
| 20:30.33 | sofichinu | oh, I am actually downloading Qt, for sum reasons, I lost it |
| 20:31.14 | starseeker | Ideally, we would replace all of the platform specific display managers with one accelerated (OGRE) and one unaccelerated (Qt) display manager - between those two, we should get broad coverage of machine configurations and operating systems for minimal code |
| 20:32.34 | starseeker | My guess would be that the main challenge with Qt will be figuring out how to do "fast enough" 2D drawing without relying on OpenGL |
| 20:33.22 | dli | or ogre simply figure out how to run without no 3d support underneath |
| 20:33.54 | starseeker | dli: that's a bit like saying you're going to figure out how to drive without a car :-P |
| 20:34.22 | dli | starseeker, yes, because a bike is always available |
| 20:34.54 | starseeker | the main point and benefit of OGRE is that it does take advantage of 3D acceleration |
| 20:35.57 | starseeker | if someone wants to propose an alternative toolkit for either the unaccelerated or the accelerated display manager that's fine, but they'll need to make a very good case for it |
| 20:37.40 | starseeker | issues to consider there are license compatibility, portability, how well maintained and widely used the toolkit is, etc. |
| 20:38.34 | starseeker | we don't want to take over maintainance for a cross platform graphical toolkit - we want to use one that is already in good shape |
| 20:39.02 | starseeker | OGRE and Qt have a lot of momentum behind them and are licensed in a way we can use them |
| 20:39.51 | sofichinu | Its just like making a best deal from both of them. |
| 20:46.57 | starseeker | sofichinu: this may be of interest: http://labs.qt.nokia.com/2009/12/16/qt-graphics-and-performance-an-overview/ |
| 20:52.30 | *** join/#brlcad niels_horn (~niels@187.14.62.166) | |
| 22:32.38 | *** join/#brlcad ibot (~ibot@rikers.org) | |
| 22:32.38 | *** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD release 7.18.4 ETA 20110321 || BRL-CAD is participating in the 2011 Google Summer of Code! Students: speak up, ask quesions! :) | |
| 23:23.12 | brlcad | thinks we're good with a simple socket connection for the forseeable next couple years |
| 23:23.54 | brlcad | local port performance is going to be the main customer at first, not even over tcp, for the beginning (e.g., mged use) |
| 23:24.57 | brlcad | getting beyond that and I'd want to start considering more advanced network services like automatic replication and persistance .... but only long after the protocol is established for simple net |