| 00:41.28 | *** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol) | |
| 01:37.28 | Maloeran | This might be a stupid question... but why is BRL-CAD's ./configure trying to find OpenGL/OpenGL.h and -lopengl32? (rather than GL/gl.h and -lGL ) And hence apparently doesn't want to enable OpenGL |
| 01:38.26 | Maloeran | (Trying to install on an Ubuntu laptop, hunting down missing -dev packages...) |
| 02:13.21 | CIA-48 | BRL-CAD: 03brlcad * r49223 10/brlcad/trunk/src/libged/trace.c: another unused vls |
| 02:16.35 | CIA-48 | BRL-CAD: 03brlcad * r49224 10/brlcad/trunk/src/libged/ls.c: and another unused vls masked by a bu_vls_init() |
| 02:25.23 | CIA-48 | BRL-CAD: 03brlcad * r49225 10/brlcad/trunk/src/ (113 files in 12 dirs): (log message trimmed) |
| 02:25.24 | CIA-48 | BRL-CAD: replace 580 calls to bu_vls_init() with static initialization via |
| 02:25.24 | CIA-48 | BRL-CAD: BU_VLS_INIT_ZERO. this eliminated the need for more than 100 conditionalized |
| 02:25.24 | CIA-48 | BRL-CAD: inits, which in turn eliminates the risk that a vls might get used prior to |
| 02:25.24 | CIA-48 | BRL-CAD: initialization (whereby it crashes). this improves memory management as well |
| 02:25.24 | CIA-48 | BRL-CAD: eliminating the function call and memory allocation should the vls not actually |
| 02:25.25 | CIA-48 | BRL-CAD: be needed; and it eliminates a memory leak if a vls were initialized but not |
| 02:25.39 | brlcad | Maloeran: hey, long time no see .. not a stupid question but definitely misunderstood |
| 02:26.37 | brlcad | Maloeran: it searches for OpenGL/OpenGL.h but *also* searches for GL/gl.h (and a variety of other headers found on various platforms), same for library searches too |
| 02:27.25 | brlcad | undoubtedly a missing dev package, if you read the config.log and find the GL/gl.h header test, it will say why |
| 02:28.27 | brlcad | more importantly, though .. if this is at all a recent source, you should be using the newer cmake build system instead of the configure-based autotools build system. mkdir .build && cd .build && cmake .. && ccmake .. |
| 02:52.12 | Maloeran | Hey, long time no see indeed |
| 02:52.38 | Maloeran | So you are moving away from autoconf and friends after all, nice |
| 03:31.06 | brlcad | already done, few months back |
| 03:32.53 | brlcad | took a few months to get a near-equivalent cmake build in place, but cliff bootstrapped a good setup |
| 03:40.13 | Maloeran | Nice. I'm integrating my ball pivoting point cloud mesh reconstruction into Lee's VSL hence the need for BRL-CAD |
| 03:44.10 | Maloeran | I'm not quite convinced that raytracing, gathering point and reconstruction is the best way to convert CSG geometry to triangles (the edges of a cube will appear rounded), but it's probably good enough, I guess |
| 03:45.59 | brlcad | heh, that's funny |
| 03:46.49 | brlcad | I implemented a proof of concept for that about 7 years ago |
| 03:46.54 | Maloeran | Oh? |
| 03:47.11 | brlcad | got it working, but then abandoned the project because I thought it sucked |
| 03:48.15 | Maloeran | I'm sure there would be a much better way to generate surface points than raytracing, by inspecting the actual primitives. Or just converting each primitive to a triangle mesh and doing boolean operations on triangle meshes... |
| 03:48.27 | brlcad | then erik worked on something similar about two years ago (again for lee), and came to similar results but after many more months trying to bring it up to production-quality |
| 03:48.40 | brlcad | similarly abandonded |
| 03:48.44 | Maloeran | What was the approach? |
| 03:49.32 | brlcad | mine was a textbook marching cubes eval |
| 03:49.33 | Maloeran | I think my point cloud mesh reconstruction code is very nice (very robust, extremely fast), but I'm not sure it's the right solution to the problem to begin with |
| 03:49.43 | brlcad | like I said, just proof of concept reconstruction |
| 03:50.00 | Maloeran | Marching cubes from point cloud data? You'll get rounded cubes too... |
| 03:50.24 | brlcad | i saw that "yeah.. this can .. sorta work ..." but not for lots of types of geometry, not very robustly, and not well at all for flat surfaces and hard edges without a lot more work |
| 03:50.43 | Maloeran | Yes, I see |
| 03:51.48 | Maloeran | The ball pivoting algorithm was terribly unreliable and unstable too. It took about 2 months to fix the whole thing with a truly robust algorithm |
| 03:52.52 | Maloeran | (including the time to write it multithreaded, algorithms built of atomic instructions for perfecty scalability, NUMA-aware, etc.) |
| 03:53.04 | brlcad | lee seems enamored by the approach, but I guess I just fundamentally dislike the premise of point-sampling CSG |
| 03:53.43 | Maloeran | So do I, it's not the right approach... unless your points are generated from the actual primitive surfaces |
| 03:54.14 | Maloeran | If you have a cube, you should have points right on all the edges and corners, or your geometry gets messed up |
| 03:55.02 | Maloeran | Maybe it's just a first step until a better point sampling method is implemented |
| 03:55.15 | brlcad | you don't need point sampling -- you have perfect surface information |
| 03:55.36 | brlcad | the real solution is to just construct the boundary information, then evaluate your boundaries |
| 03:55.41 | Maloeran | Sure. You could convert to triangle meshes and perform boolean operations on triangle meshes |
| 03:55.43 | brlcad | that's what we've been working towards |
| 03:56.05 | brlcad | no no .. that's what we already do, it's terribly difficult to do robustly |
| 03:56.10 | Maloeran | Oh? I see |
| 03:56.32 | brlcad | polygonal boundary representation is only sufficient when your starting geometry is polygonal |
| 03:56.57 | brlcad | that's where nurbs/brep come in (and why pretty much EVERY other commercial CAD system uses them) |
| 03:57.00 | Maloeran | Well, a conversion to a polygon based representation has many advantages these days |
| 03:57.10 | brlcad | you can still convert to polygonal |
| 03:58.02 | brlcad | the issue is when the boolean is evaluated |
| 03:58.07 | Maloeran | Can I ask what you mean exactly by constructing the boundary information, and evaluating boundaries? |
| 03:58.51 | brlcad | so take two overlapping mathematical spheres in implicit form (point+radius) being unioned together |
| 03:59.30 | brlcad | I can evaluate polys for both then join those two meshes, eliminate the interior faces, slice the boundary faces, etc |
| 03:59.53 | Maloeran | That's what you presently do, and it's difficult to do robustly, right? |
| 04:00.01 | brlcad | but the problem is that you're attempting to perform the boolean evaluation on already lossy data |
| 04:00.11 | brlcad | very, np-hard iirc |
| 04:00.46 | brlcad | it ends up being a search domain problem with an undefined solution with real geometry |
| 04:00.49 | Maloeran | A different approach would be to generate points all over the spheres, then points precisely on the intersection disk between the two spheres, then reconstruct a mesh from these points |
| 04:01.00 | Maloeran | That approach doesn't sound too hard |
| 04:01.21 | brlcad | it's knowing that intersection disk |
| 04:01.28 | Maloeran | My problem is mostly with the present point sampling method, raytracing... |
| 04:01.30 | Maloeran | Oh. |
| 04:02.04 | Maloeran | So you are saying that generating actual points for the intersection between 2 boolean primitives is difficult |
| 04:02.10 | brlcad | point sampling the implicit definitely has better potential than trying to stitch a mesh that has already thrown away the curve of intersection |
| 04:02.19 | Maloeran | I guess the primitives involved must be complex than the basic ones I have in mind |
| 04:02.39 | Maloeran | must be more* complex |
| 04:02.40 | brlcad | not saying that, but yes for many of the primitives it's insanely difficult |
| 04:02.46 | Maloeran | I see. |
| 04:02.48 | Maloeran | Interesting |
| 04:02.56 | brlcad | polynomial equations of nth order where n can be in the hundreds |
| 04:03.29 | brlcad | the robust way to do it is convert those implicit spheres into explicit spheres using a spline-suface representation |
| 04:03.44 | Maloeran | Well, that complicates things a little. I can understand why Lee would want to bombard a CSG object with billions of rays and just reconstruct the geometry |
| 04:03.48 | brlcad | then perform surface-surface evaluation to evaluate the actual curve of intersection |
| 04:04.15 | brlcad | you use the curve of intersection to trim the actual original surfaces, resulting in two trimmed surfaces joined by a curve |
| 04:04.31 | brlcad | from there you can tessellate the two surfaces precisely to whatever resolution one desires |
| 04:04.38 | Maloeran | Right |
| 04:04.42 | brlcad | robust, fault and floating point tolerant |
| 04:05.24 | Maloeran | That surface-surface evaluation sounds tricky with high degree nurbs and such |
| 04:05.51 | brlcad | it is, but there are some pretty straightforward algorithms out there (and even the dead simple approaches work well enough) |
| 04:06.17 | Maloeran | I can imagine doing it by bruteforce and converging |
| 04:06.24 | brlcad | sure |
| 04:06.32 | brlcad | even that is better than point-sample raytracing ;) |
| 04:06.34 | Maloeran | If there's some better mathematical magic, I don't presently see it |
| 04:06.40 | Maloeran | Agreed :D |
| 04:07.00 | brlcad | for lower-order surfaces, you actually can evaluate the exact curve with some simple reductions |
| 04:08.29 | Maloeran | Sounds good. It's probably a very complex approach given the wide range of techniques and specialized codes required to handle intersection between any kind of primitive |
| 04:08.55 | brlcad | not as complex as one would think |
| 04:09.17 | Maloeran | Ah perhaps... Though I feel I understand Lee a little better in his desire to just bombard billions of rays and get something "close enough" |
| 04:09.28 | brlcad | getting a nurbs representation in place was a big step, but not as big as directly ray-tracing nurbs, which is done now |
| 04:09.59 | brlcad | also done was the complex piece of turning each of our primitives into nurbs/brep geometry |
| 04:10.22 | Maloeran | So every primitive is nurbs/brep? |
| 04:10.32 | Maloeran | That would simplify things quite a bit |
| 04:10.59 | brlcad | the only piece remaining (which is slated for later this year) is the surface-surface trimming evaluation |
| 04:12.12 | Maloeran | I'm a little surprised that both you and Erik worked on something similar years ago |
| 04:12.24 | Maloeran | And Doug at SURVICE also wrote a new marching cube implementation |
| 04:12.39 | Maloeran | Then I was asked to write a fast ball pivoting based implementation |
| 04:15.15 | brlcad | the other problem I have with the sampled approach is that it's inadequate for anything but visualization as there's no way to guarantee that you didn't change topology or miss geometry |
| 04:15.35 | brlcad | at best you can say you think you got everything within some tolerance |
| 04:15.56 | Maloeran | Exactly. You can say you didn't miss anything below X milimeters |
| 04:16.21 | brlcad | if you're lucky and the implementation is sufficiently robust, you might be able to say topology seems to be consistent .. but you can't guarantee that |
| 04:17.01 | Maloeran | I'm quite confident in my ball pivoting implementation... but I'm biased, and I certainly see your point |
| 04:18.02 | Maloeran | I guess there's a point where details below a defined size of X can be overlooked for some purposes |
| 04:18.06 | brlcad | the biggest practical problem I recall running into is how the algorithm responds to real geometry where there are cracks, voids, overlaps, etc |
| 04:18.18 | brlcad | that and thin-walled geometry being a royal pain |
| 04:18.37 | brlcad | sheet metal surfaces that are infinitely thin .. and absurdly common |
| 04:18.44 | Maloeran | Yes, marching cubes have problems with that |
| 04:19.09 | Maloeran | Ball pivoting has problems too, but of a very different nature |
| 04:19.15 | brlcad | nods |
| 04:20.13 | brlcad | so that's why I abandonded the approach 7+ years ago :) |
| 04:20.48 | Maloeran | I wrote some automatic testing code, generating a big random point cloud kind-of thorus shaped, and I had it running for days on a 24 cores machines, doing thousands of runs to find any kind of error |
| 04:20.57 | brlcad | I figured even spending just a couple months to get something working robustly enough was wasted time, time I could spend getting closer towards a provably robust, accurate, and the defacto industry approach |
| 04:21.01 | Maloeran | So until proved otherwise, I remain confident in my code :) |
| 04:21.17 | Maloeran | Ah yes, I can agree with that |
| 04:21.44 | Maloeran | But I also see beyond VSL, good point cloud reconstruction code can find uses elsewhere |
| 04:21.50 | brlcad | oh, I saw that "it 'could' work" even back then .. just not worth it to me :) |
| 04:22.02 | Maloeran | Ah :) |
| 04:22.17 | brlcad | worth it to lee, which is why he's kept pressing on |
| 04:22.55 | brlcad | and if your work is as robust as he hopes, he'll finally have what he was looking for :) |
| 04:23.18 | Maloeran | In some rare cases, the code can generate a topology that looks a little "weird", but certainly no holes, overlaps or any such error |
| 04:23.22 | brlcad | surface reconstruction from point cloud data is very useful in itself, no doubt |
| 04:24.06 | brlcad | hell, that'd be great functionality I've had in mind to add to brl-cad for a while, it's just such a limited domain |
| 04:24.12 | brlcad | usually model acquisition |
| 04:24.38 | Maloeran | Yes. Mark from SURVICE said they probably could use that in Metrology |
| 04:24.50 | brlcad | and if you can get point clouds, you have a lot more surface information right in front of you :) |
| 04:24.55 | Maloeran | (Instead of paying tens of thousands for software that doesn't always work that well) |
| 04:27.11 | Maloeran | Completely different topic: compilation of OpenSceneGraph fails due to a lack of -fPIC, do you know their build system for the best way to plug that in? |
| 04:27.28 | Maloeran | I would fix manually but there are about 300 Makefiles |
| 04:40.55 | starseeker | Maloeran: which version of OpenSceneGraph are you using? |
| 04:41.54 | *** join/#brlcad IriX64 (~kvirc@64.229.211.15) | |
| 04:41.55 | starseeker | They're CMake based, IIRC... |
| 04:42.28 | starseeker | usually they build without too much fuss |
| 04:42.44 | Maloeran | Trying to manually install the latest, my Ubuntu is too old and its packages are worthless ;) |
| 04:42.58 | starseeker | heh |
| 04:43.12 | starseeker | and the latest fails complaining about -fPIC? |
| 04:43.15 | starseeker | that's surprising |
| 04:43.20 | Maloeran | Yes... but -fPIC is already there and it complains anyway. Trying to figure out what's going on. |
| 04:43.32 | starseeker | yeah, that doesn't sound right |
| 04:43.57 | Maloeran | More precisely : "/usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/4.4.3/../../../../lib/libavdevice.a(alldevices.o): relocation R_X86_64_32 against `alsa_muxer' can not be used when making a shared object; recompile with -fPIC" |
| 04:44.32 | starseeker | uh... that sounds like it's complaining about a system library - libavdevice.a |
| 04:44.43 | Maloeran | Yes, sounds like I have to rebuild that |
| 04:45.09 | starseeker | alsa is the sound architecture... you need sound support? |
| 04:46.08 | Maloeran | Not at all, I'll try disabling that, thanks for the tip |
| 04:46.53 | starseeker | Bob did some quick OpenSceneGraph tests with MGED's display manager, but we didn't see much in the way of performance improvement - are there some settings to turn on with OSG to get speed-ups? |
| 04:47.49 | Maloeran | I'm totally unfamiliar with OSG, I'm just trying to build Lee's VSL on my laptop (for the last 3 hours ;)) |
| 04:49.53 | brlcad | Maloeran: on a related topic, any chance of getting your point cloud code open sourced and added to brl-cad? ;) |
| 04:50.28 | Maloeran | That would be nice, but VSL is going to be open-source or not? |
| 04:50.50 | brlcad | not |
| 04:50.58 | brlcad | make it a stand-alone lib |
| 04:51.07 | Maloeran | Ow.. but I don't think I own the copyright on that code |
| 04:51.16 | brlcad | so to whomever owns it :) |
| 04:51.54 | Maloeran | I'll ask Lee, I know Mark wanted to use it somewhere too |
| 04:52.43 | Maloeran | I'm surprised VSL isn't going to be open-source, but I'm not too informed about the politics |
| 04:52.52 | brlcad | if it was under contract, mark may have finagled gpr (gov purpose rights) in which case open sourceability is entirely mark's decision |
| 04:53.23 | Maloeran | I see, I'll have to ask |
| 04:53.25 | starseeker | Maloeran: just curious - you know anything about this? http://pointclouds.org/ |
| 04:53.28 | brlcad | if it's gov unlimited rights, then it's lee's call |
| 04:53.51 | Maloeran | Never heard of it, starseeker, reading |
| 04:54.48 | Maloeran | I know Lee made me investigate MeshLab months ago, their ball pivoting mesh reconstruction was terrible |
| 04:55.10 | Maloeran | It was 400 times slower than mine, and it created tons of holes, overlaps |
| 04:55.42 | starseeker | PCL claims to have surface reconstruction and are BSD licensed... |
| 04:56.11 | starseeker | Maloeran: too bad about Meshlab, but then they're GPL so BRL-CAD can't snarf code from them anyway... |
| 04:56.42 | Maloeran | Ah right. MeshLab is most horrible anyway |
| 04:57.05 | starseeker | they can be handy when converting bot formats (stl, obj, etc.) - that's mostly what I use it for |
| 04:57.12 | starseeker | and they're not a bad viewer |
| 04:57.29 | starseeker | compiling it... sucks. royally. |
| 04:57.40 | Maloeran | Eheh |
| 04:58.05 | starseeker | has pondered feeding points into PCL from raytracing to see what they can do, but it's not been a high priority |
| 04:58.06 | Maloeran | I'm not finding how to disable sound in OSG, do you have another tip in reserve? |
| 04:58.23 | starseeker | um. which component is failing? |
| 04:58.36 | starseeker | (i.e. what are you trying to build when the linker fails) |
| 04:58.41 | Maloeran | osgdb_ffmpeg.so |
| 04:58.56 | starseeker | maybe video support? |
| 04:59.02 | starseeker | FFMPEG is video |
| 04:59.11 | Maloeran | Under osgPlugins-3.0.0, so it's probably not essential |
| 04:59.44 | Maloeran | Exactly. Except I'm not finding how to disable it, I never bothered to familiarize myself with the build systems (I mostly hate them) |
| 04:59.56 | starseeker | you're using cmake-gui? |
| 05:00.08 | Maloeran | ./configure && make |
| 05:00.15 | starseeker | erm |
| 05:00.29 | starseeker | I'd suggest installing cmake, if osg supports it |
| 05:00.44 | starseeker | Ubuntu does have a CMake package, even if it's a bit old |
| 05:01.19 | starseeker | I'll stand a lot better chance of helping you if you're building with CMake ;-) |
| 05:01.32 | Maloeran | Okay :), let me try this |
| 05:01.56 | starseeker | downloads latest osg |
| 05:02.47 | starseeker | Maloeran: too bad you hadn't run into PCL before, was hoping you might have some insight into it - now I'll have to do some work :-P |
| 05:02.47 | Maloeran | Interesting little thing, this cmake-gui |
| 05:02.55 | Maloeran | Sorry :D |
| 05:05.16 | starseeker | hmm. well, if it does need ffmpeg you may need to build that from source |
| 05:05.19 | Maloeran | I can change paths but that doesn't help much. I guess I'll reinstall ffmpeg with more -fPIC |
| 05:06.25 | starseeker | Maloeran: if you go with the CMake build, you'll probably need to replace all the FFMPEG_* variables with the values for your local build of ffmpeg |
| 05:06.40 | starseeker | configure might give you some options |
| 05:07.05 | Maloeran | Yes I saw. Running an outdated Ubuntu and having to install everything manually is a lot of trouble actually |
| 05:07.15 | Maloeran | I have been installing packages manually for 3-4 hours |
| 05:07.22 | starseeker | you *might* be able to set FFMPEG_ROOT from the get-go, e.g. cmake .. -DFFMPEG_ROOT=/my/ffmpeg/install |
| 05:07.36 | starseeker | Maloeran: ``Erik would tell you to upgrade to FreeBSD :-P |
| 05:08.09 | starseeker | finds Gentoo a good step in the BSD direction without losing all his Linux frame of reference... |
| 05:08.57 | Maloeran | Yes, my desktop runs Gentoo, it was a bad call to try Ubuntu on the laptop |
| 05:18.04 | Maloeran | Wonderful, with the latest ffmpeg, OSG just spits out a bunch of compilation errors |
| 05:18.31 | Maloeran | I think I'll just carry my desktop to keep working on the week-end :) |
| 05:31.06 | starseeker | or upgrade your laptop OS :-) |
| 05:35.18 | starseeker | hmm - looks like PCL takes advantage of qhull |
| 05:35.41 | starseeker | really needs to bug the qhull author about his license (or figure out if it's compatible as-is...) |
| 05:40.03 | CIA-48 | BRL-CAD: 03brlcad * r49226 10/brlcad/trunk/ (include/bu.h src/libbu/str.c): add a bu_strcasecmp companion for bu_strcmp. |
| 05:41.08 | starseeker | brlcad: did we ever decide if qhull's license is OK for our use? |
| 05:46.39 | CIA-48 | BRL-CAD: 03brlcad * r49227 10/brlcad/trunk/include/bu.h: add a BU_STR_SIMILAR() macro for converting the return value from bu_strcasecmp() into a boolean. future version may wrap a different function if it's expanded to disconsider insignificant whitespace too. |
| 05:51.03 | Maloeran | I looked at the website, there doesn't seem to be much of a license in the legal sense |
| 06:14.57 | brlcad | starseeker: my relatively brief reading is that qhull seems fine |
| 06:15.05 | brlcad | I don't see any new terms that lgpl doesn't already require implicit or explicit |
| 06:15.31 | brlcad | I'd expect to see some serious feature already using it, not just planned, before it gets integrated though.. |
| 06:16.03 | brlcad | rather specific algorithms to just toss in without regard to our own api and duplicate functionality |
| 06:20.57 | CIA-48 | BRL-CAD: 03brlcad * r49228 10/brlcad/trunk/include/bu.h: rename to BU_STR_EQUIV for equivalence since it's slightly less ambiguous (but shortened to match BU_STR_EQUAL length). |
| 06:22.15 | CIA-48 | BRL-CAD: 03brlcad * r49229 10/brlcad/trunk/src/ (5 files in 3 dirs): propagate BU_STR_EQUIV() where strcasecmp() was being used |
| 06:24.10 | CIA-48 | BRL-CAD: 03brlcad * r49230 10/brlcad/trunk/HACKING: bu_strcasecmp() and BU_STR_EQUIV() instead of stricmp()/strcasecmp() |
| 06:46.45 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) | |
| 07:03.40 | Maloeran | In case anyone was curious, the -fPIC error was caused by a direct reference in assembly in ffmpeg, and the latest OSG can only compile with a ffmpeg 6 months old |
| 10:29.41 | *** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol) | |
| 12:52.10 | *** join/#brlcad csanyipal (~csanyipal@185-169-85-95.dynamic.stcable.net) | |
| 12:52.22 | csanyipal | Hi, |
| 13:00.10 | csanyipal | can one make an aeroplan with brlcad and after that to investigate it's aerodynamic attributes? |
| 13:00.27 | csanyipal | a model of aeroplan, of course.. |
| 13:45.58 | CIA-48 | BRL-CAD: 03brlcad * r49231 10/brlcad/trunk/src/ (28 files in 21 dirs): since 'new' is a reserved c++ keyword, avoid using it throughout our code. one step closer to being able to compile everything as c++ sources. |
| 13:53.42 | CIA-48 | BRL-CAD: 03brlcad * r49232 10/brlcad/trunk/src/mged/ (chgview.c sedit.h): what? eliminate evil unused global strings |
| 14:36.37 | starseeker | brlcad: oh, I wasn't planning on snarfing it in now - just wanted to be sure condition 3 requiring name, date and reason for modification to be present if changes were made, wasn't over and above LGPL requirements |
| 14:37.13 | starseeker | if it is, no point in even investigating qhull without first trying to discuss the license question with the author |
| 14:37.26 | CIA-48 | BRL-CAD: 03brlcad * r49233 10/brlcad/trunk/src/remrt/remrt.c: straggler bu_vls_init() to = BU_VLS_INIT_ZERO conversion |
| 14:39.08 | starseeker | csanyipal: um... we don't have much in the way of tools specific to aerodynamic analysis - my understanding is that's a rather specialized sort of analysis |
| 14:43.31 | starseeker | a quick look around the web turns up XFoil from MIT... http://web.mit.edu/drela/Public/web/xfoil/ |
| 14:44.43 | starseeker | from the finite element perspective there's also http://sourceforge.net/projects/elmerfem/ (GPL) which seems to have some active development... |
| 14:46.20 | starseeker | there's CEASIOM, but it's not open source... http://www.ceasiom.com/index.php |
| 14:50.29 | starseeker | might be something of interest here: http://www.dept.aoe.vt.edu/~mason/Mason_f/MRsoft.html |
| 14:53.51 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) | |
| 14:54.54 | starseeker | csanyipal: if you have access to Rhino, this might be of interest: http://wiki.mcneel.com/developer/scriptsamples/airfoil |
| 14:55.05 | starseeker | BRL-CAD can import 3dm files |
| 14:56.33 | starseeker | also http://sourceforge.net/projects/xflr5/ |
| 14:56.59 | starseeker | (might be more friendly than xfoil) |
| 14:57.44 | starseeker | (intended for model aircraft though) |
| 15:01.48 | starseeker | original NACA report on airfoil shapes... http://hdl.handle.net/2060/19930091108 |
| 15:04.18 | starseeker | and the "5-digit" report... http://hdl.handle.net/2060/19930091610 |
| 15:43.24 | brlcad | starseeker: that clause is interesting, but I didn't read that condition as conflicting lgpl requirements |
| 15:43.59 | starseeker | um. so the notion of *requiring* something like ChangeLog updates isn't an issue? |
| 15:45.13 | brlcad | copyright doesn't allow you to claim ownership of something you didn't write, so requiring changes be annotated fulfills that requirement (outside of lgpl) |
| 15:45.22 | brlcad | i.e., it's something you have to do anyways in some form |
| 15:45.31 | starseeker | ah. hadn't considered that |
| 15:45.55 | starseeker | so I guess the only problem spot would be requiring a notation about the reason for the mod |
| 15:46.03 | brlcad | I mean, I wouldn't bet the farm on it, but the intent is pretty clear to me |
| 15:46.49 | brlcad | the real question would be if someone downloaded brl-cad that had code from it included, could they comply with both |
| 15:46.56 | starseeker | nods |
| 15:47.00 | brlcad | and I'm thinking that they can |
| 15:47.44 | starseeker | doesn't look to be viral either, if I'm understanding it right - i.e. linking in libqhull doesn't propoagate those requirements to all code |
| 15:48.03 | CIA-48 | BRL-CAD: 03starseeker * r49234 10/brlcad/trunk/src/other/CMakeLists.txt: whoops, get the lib dir symlinks too. |
| 15:48.24 | brlcad | doesn't even require source, if I recall |
| 15:48.47 | brlcad | just IFF you provide source code, you have to make it clear what you've changed |
| 15:49.11 | starseeker | nods - so pretty much like Apache then - we can't mix it straight in, but we can use it |
| 15:49.52 | brlcad | still, the fundamental issue also comes back to what they provide that would be more useful than another less complicated lib or even a more minimal subset that we'd write ourselves |
| 15:50.29 | brlcad | convex hull is a function someone could write in a day |
| 15:50.41 | brlcad | and wouldn't require data massaging |
| 15:51.09 | starseeker | doesn't know for sure - just keep seeing qhull pop up when things like triangulation come into play |
| 15:53.12 | starseeker | Shewchuk's Triange code is a definite no-go - crappy licensing |
| 15:54.43 | brlcad | qhull's main feature is for supporting convex polyhedra, which is basically a form of our arbn primitive |
| 15:56.13 | starseeker | wonder what PCL is using it for then |
| 15:56.52 | brlcad | convex hull undoubtedly |
| 15:56.58 | brlcad | or delauney triangulation |
| 15:57.46 | brlcad | given a set of 3d points, get the convex hull, you build up a surface |
| 15:59.06 | *** join/#brlcad KimK (~Kim__@209.248.147.2.nw.nuvox.net) | |
| 16:00.07 | brlcad | by itself though, it's just a solution in search of a problem ... :) |
| 16:00.26 | brlcad | now pcl, that's more interesting and immediately useful ;) |
| 16:01.23 | starseeker | sure - but I'm guessing pcl's features would probably require qhull's presense, based on my attempt to compile it last night |
| 16:01.40 | starseeker | hence the qhull question :-) |
| 16:02.27 | brlcad | from what i read, it's not required |
| 16:03.13 | brlcad | but I could still see them using qhull under the hood for point cloud processing .. "get me a bounding surface around these points" |
| 16:03.29 | brlcad | part of pcl's segmentation feature |
| 16:05.39 | starseeker | nods - k. My initial thought was they were probably using it to triangulate the point cloud into a mesh, but I admit I didn't look closely |
| 16:06.03 | starseeker | pcl looks to be a mean compile... yay C++ |
| 16:06.04 | brlcad | that'd be why you'd get a bounding surface around points, gives a mesh |
| 16:06.43 | starseeker | ah, right |
| 16:06.58 | starseeker | doesn't normally think in terms of meshes as bounding surfaces :-) |
| 16:07.14 | starseeker | usually come up in geometry conversion questions |
| 16:07.15 | brlcad | it's fringe interest .. getting it to play with our points primitive would be the main use, and that's not a great modeling interface |
| 16:07.58 | starseeker | was thinking raytrace to get points -> stuff into PCL -> get back bot... |
| 16:08.09 | brlcad | yep |
| 16:09.13 | brlcad | that's the whole discussion from last night |
| 16:09.42 | brlcad | sure you can do that ... but is it actually less work (to do it well, reliably, robustly) than implementing surface-surface intersections? I think not |
| 16:10.24 | brlcad | it's data explosion, a sampled approximation, you throw away everything you know about the geometry's structure and then try to recreate it .. .wtf? :) |
| 16:10.59 | starseeker | heh |
| 16:11.19 | starseeker | sure - was thinking more of the case of a scanner barfing a point cloud than our own geometry |
| 16:11.53 | brlcad | yeah, that's the main usefulness to us |
| 16:12.33 | brlcad | metrology equipment, lidar, vulcan |
| 16:13.15 | starseeker | even there, would be better to get a NURBS surface than a mesh... |
| 16:14.06 | brlcad | if you're starting with points, there's not much difference |
| 16:14.28 | brlcad | you could extract nurbs from mesh, or mesh from nurbs, either derived from point cloud |
| 16:16.13 | starseeker | true |
| 16:22.04 | brlcad | that's basically what geomagic does, which comes with most scanners |
| 16:22.44 | brlcad | and you'd be hard-pressed to implement something better than them without device drivers |
| 16:23.27 | brlcad | that said, you know it's on our must-do this year to implement bot->nurbs right? if you're looking for a fun project ;) |
| 16:25.28 | brlcad | and nurbs->mesh |
| 16:30.03 | Maloeran | Is anyone familiar with Lee's VSL source here? |
| 16:35.29 | starseeker | Maloeran: nope, sorry :-/ |
| 16:50.50 | *** join/#brlcad KimK (~Kim__@209.248.147.2.nw.nuvox.net) | |
| 17:11.56 | CIA-48 | BRL-CAD: 03starseeker * r49235 10/brlcad/trunk/doc/docbook/resources/other/standard/ (3 files in 2 dirs): Will need some tweaks to the docbook resources setup. This will break things temporarily, but need to change files then move them. |
| 17:17.12 | CIA-48 | BRL-CAD: 03starseeker * r49236 10/brlcad/trunk/doc/docbook/resources/other/docbook-schema/docbook-5.0.tar.bz2: Another change-before-move commit |
| 17:42.11 | CIA-48 | BRL-CAD: 03starseeker * r49237 10/brlcad/trunk/doc/docbook/resources/other/ (19 files in 6 dirs): Move some docbook stuff around |
| 17:44.03 | CIA-48 | BRL-CAD: 03starseeker * r49238 10/brlcad/trunk/doc/docbook/resources/other/ (docbook-schema/ standard/svg/ standard/xsl/): Remove empty dirs |
| 17:45.09 | brlcad | some exciting possibilities with gsoc 2012 |
| 17:46.12 | starseeker | cusses out the article TEMPLATE.xml file... why did you suddenly stop validating??? |
| 17:46.23 | starseeker | not just the last few commits, either... |
| 17:46.35 | brlcad | huh, validated when I added it I thought |
| 17:46.40 | brlcad | at least it spit out html |
| 17:46.59 | starseeker | yeah, it generates html - I tried enabling the xmllint validation |
| 17:47.08 | starseeker | sort of "strict flags for docbook" |
| 17:47.44 | starseeker | oh, wait - is that that new example file you added? |
| 17:48.04 | starseeker | oh, OK - no wonder, I probably hadn't hit it with xmllint |
| 17:48.07 | starseeker | phew |
| 17:48.13 | starseeker | nevermind, carry on |
| 17:49.00 | starseeker | if you're curious, variable is BRLCAD_EXTRADOCS_VALIDATE |
| 17:49.13 | starseeker | (marked as advanced for now - set it to ON and you'll see why...) |
| 17:52.04 | starseeker | eventually, once we get our xml cleaned up, I'd like to tie the default setting of BRLCAD_EXTRADOCS_VALIDATE to the overall strict compilation variable |
| 17:52.36 | brlcad | ah, okay |
| 17:52.44 | brlcad | it was pulled together by hand so no surprise |
| 17:54.04 | brlcad | yep and concur, the same reasons and maintainability benefits for adhering strict applies to xml "code" too :) |
| 18:05.43 | *** join/#brlcad kanzure (~kanzure@131.252.130.248) | |
| 18:10.11 | CIA-48 | BRL-CAD: 03starseeker * r49239 10/brlcad/trunk/src/other/libpng/projects/vstudio/pngstest/: empty directory |
| 18:28.55 | CIA-48 | BRL-CAD: 03starseeker * r49240 10/brlcad/trunk/ (3 files in 3 dirs): Turn on the distclean rule. This should be a real distclean, working both in and out of the source directory. Needs more testing. Currently is only likely to work with systems using Makefiles |
| 18:33.46 | starseeker | cool - http://google-opensource.blogspot.com/2012/01/data-and-code-open-sourced-from-googles.html |
| 18:38.10 | starseeker | brlcad: it will take more testing, and I'm sure it's not the fastest distclean in the world, but hopefully that will do the job |
| 18:38.33 | starseeker | suddenly in-src-dir development of BRL-CAD becomes viable again :-/ |
| 18:38.36 | starseeker | sort of |
| 18:49.45 | csanyipal | starseeker: Thanks!! |
| 19:15.03 | *** part/#brlcad csanyipal (~csanyipal@185-169-85-95.dynamic.stcable.net) | |
| 19:34.17 | *** join/#brlcad Yoshi47 (~jan@d72-39-60-53.home1.cgocable.net) | |
| 20:44.22 | *** join/#brlcad bmoez_ (~bmoez@197.1.11.223) | |
| 22:23.32 | *** part/#brlcad bmoez_ (~bmoez@197.1.11.223) | |
| 22:25.06 | starseeker | hah - cool, Leslie (former GSoC organizer) has a chapter in the open-advice.org book |
| 22:44.10 | starseeker | heh - awesome lines from Rich Bowen |
| 22:44.17 | starseeker | paraphrase: |
| 22:44.38 | starseeker | "This is the true laziness - not merely shirking work, but doing the work once so well that it never has to be done again." |
| 22:46.04 | starseeker | programmer zen :-) |
| 22:56.49 | starseeker | this Open Advice book is actually really cool |
| 23:41.33 | *** join/#brlcad n_reed_ (~molto_cre@BZ.BZFLAG.BZ) | |
| 23:44.27 | *** join/#brlcad yiyus_ (1242712427@je.je.je) | |
| 23:51.13 | *** join/#brlcad kanzure (~kanzure@131.252.130.248) | |