| 00:05.53 | Notify | 03BRL-CAD:starseeker * 69738 (brlcad/trunk/src/external/CREO/assembly.cpp brlcad/trunk/src/external/CREO/part.cpp): Only do the skeleton check if we have a model on which to run that check... |
| 00:19.21 | *** join/#brlcad infobot (ibot@rikers.org) |
| 00:19.21 | *** topic/#brlcad is GSoC students: if you have a question, ask and wait for an answer ... responses may take minutes or hours. Ask and WAIT. ;) |
| 00:22.33 | *** join/#brlcad teepee_ (~teepee@unaffiliated/teepee) |
| 00:44.04 | *** join/#brlcad kintel (~kintel@unaffiliated/kintel) |
| 02:16.02 | Notify | 03BRL-CAD:brlcad * 69739 (brlcad/trunk/src/libnmg/nurb_bezier.c brlcad/trunk/src/libnmg/nurb_oslo_calc.c and 2 others): more static analyzer quellage, all valid |
| 02:20.43 | starseeker | brlcad: hmm... I'll have to see if I can construct a minimal test case |
| 02:20.46 | starseeker | it was on Windows |
| 02:21.06 | starseeker | reid calling get_regions was what triggered it |
| 02:25.53 | brlcad | k, reid works on that case I made too |
| 02:26.33 | brlcad | only issue I'm seeing so far is that you can't "l -foo.r" because of the dash, you have to "l -- -foo.r" |
| 02:27.22 | starseeker | nods |
| 02:27.36 | starseeker | how are you creating the region named -foo.r ? |
| 02:27.44 | starseeker | can't get one dash in front |
| 02:34.35 | *** join/#brlcad yorik (~yorik@2804:431:f721:6332:290:f5ff:fedc:3bb2) |
| 02:40.24 | brlcad | cp whatever -foo.r |
| 02:40.34 | starseeker | ah :-) |
| 02:40.46 | starseeker | was trying to get make to do it - didn't think of cp |
| 02:41.20 | starseeker | (quoting rules kinda suck for this - apparently it's impossible to quote a name like -foo.r for make) |
| 02:41.51 | Stragus | Hey guys, I don't know if you ever used meshdecimation.c somewhere, but it was in the BRL-CAD tree |
| 02:42.09 | brlcad | Stragus: yep, it's still there |
| 02:42.14 | Stragus | Anyway, I did an update with minor API breakage, improved robustness (will handle broken topology) and other goodies |
| 02:42.28 | starseeker | sweet! |
| 02:43.23 | starseeker | https://sourceforge.net/p/brlcad/code/HEAD/tree/brlcad/trunk/src/librt/primitives/bot/gct_decimation/ |
| 02:43.23 | gcibot_ | [ BRL-CAD / Code / [r69739] /brlcad/trunk/src/librt/primitives/bot/gct_decimation ] |
| 02:43.33 | starseeker | our copy is living in there atm |
| 02:43.54 | Stragus | It now has the features required to be able to decimate meshes with per-triangle data, like materials, with a per-edge "custom weight" callback where materials differ, and so on |
| 02:44.01 | Stragus | http://www.rayforce.net/meshdecimation.c http://www.rayforce.net/meshdecimation.h |
| 02:44.13 | Stragus | You would have to check the API though, it has changed |
| 02:44.18 | brlcad | well, and src/other/gct/MeshDecimation ... but needs to be cleaned up |
| 02:46.40 | starseeker | Stragus: do you have any standard set of CMake detection tests for the various CPU_ENABLE_SSE style flags? |
| 02:47.06 | brlcad | notes there were 16 patches made |
| 02:47.12 | brlcad | er, 61 |
| 02:47.36 | Stragus | CPU_ENABLE_SSE is basically optional to force it. #if __SSE__ || _M_X64 || _M_IX86_FP >= 1 should be pretty reliable |
| 02:47.39 | starseeker | doesn't know that he ever got the proper tests in there for all the high performance SSE stuff - some of those patches may have been disabling stuff.. |
| 02:48.04 | starseeker | Stragus: ah, so the compiler itself (or rather its internals) should do the job? |
| 02:48.08 | Stragus | Yes |
| 02:48.21 | Stragus | Well, it works for GCC, clang, ICC and MSVC. I guess that's enough |
| 02:48.27 | starseeker | heh :-) |
| 02:49.02 | starseeker | most likely problem children are probably older gcc verisons |
| 02:50.29 | starseeker | Stragus: did you ever put together your nanovg/nanogui slaying high performance OpenGL widget set? |
| 02:50.44 | starseeker | remembers catching it for being interested in fontstash... |
| 02:51.09 | Stragus | Not really, if you only want font rendering... I could share my Freetype-based font manager |
| 02:51.44 | Stragus | The GUI itself isn't unfinished and undocumented with a monstrous API, so that's probably not a good idea :) |
| 02:51.52 | starseeker | heh |
| 02:52.14 | starseeker | regrettably, our own GUI layers are still primitive enough that it'll probably be a while before we need to worry about it :-( |
| 02:52.44 | starseeker | we're still using the glx/wgl specific libdm backends |
| 02:52.55 | starseeker | quietly beats head on desk... |
| 02:54.11 | starseeker | Stragus: are teh mmatomic, mmhash, etc files still pretty much the same, or have they been updated as well? |
| 02:54.50 | Stragus | Okay, here's probably everything that matters: http://www.rayforce.net/brlcad/ |
| 02:54.50 | gcibot_ | [ Index of /brlcad ] |
| 02:56.27 | Stragus | I uploaded fontmanager.* but it's independent of the "renderer" itself, basically a struct with a bunch of function pointers |
| 02:56.39 | brlcad | Stragus: do you happen to keep that in a repo? |
| 02:57.01 | Stragus | Sorry, not really, git and I... don't get along |
| 02:57.28 | brlcad | i recall we ran into a ton of portability issues, and redoing all of them doesn't sound too fun :) |
| 02:57.36 | Stragus | Agreed |
| 02:57.53 | Stragus | I probably fixed many of them myself... mmthread.h even compiles on MSVC and uses native windows threads |
| 02:57.59 | brlcad | looking at the log, looks like about 14,000 lines got edited |
| 02:58.04 | Stragus | Darn |
| 02:58.10 | brlcad | but might be a lot of formatting updates, could be misleading |
| 02:58.45 | starseeker | vaguely remembers the older gccs Redhat and OpenBSD use being issues... |
| 02:58.46 | brlcad | I do know a few specific things like instead of requiring c++11, it was ported to tinycthread |
| 02:59.06 | brlcad | and runtime sse detection was added |
| 02:59.25 | Stragus | Runtime SSE detection should be less an issue these days |
| 03:00.24 | Stragus | Well, the old meshdecimation had this little "problem" that if the mesh's topology was incorrect/broken, it could crash |
| 03:00.40 | starseeker | https://access.redhat.com/solutions/19458 - Stragus, how do these gcc versions do? |
| 03:00.43 | gcibot_ | [ What gcc versions are available in Red Hat Enterprise Linux? - Red Hat Customer Portal ] |
| 03:01.00 | starseeker | < gcc4 obviously don't count... |
| 03:01.34 | Stragus | It shouldn't require any modern GCC feature, I know it compiles with 4.9.3 |
| 03:01.57 | brlcad | runtime sse was for deployment, still very much an issue |
| 03:02.18 | brlcad | you compile on an sse system, but binaries get installed on somebody's machine without support -- crash |
| 03:02.39 | Stragus | True. But that machine would have to be from 2002 or something |
| 03:02.56 | brlcad | crash was hit before we even released just 2 years ago iirc |
| 03:03.12 | brlcad | yeah ... and? :) |
| 03:03.30 | starseeker | dinosaurs still walk the earth ;-) |
| 03:04.07 | Stragus | Eh. :) |
| 03:04.10 | brlcad | it wasn't hard to add runtime detection -- we already had a routine |
| 03:04.17 | brlcad | just had to hook it in the right places |
| 03:04.20 | Stragus | Right |
| 03:05.20 | brlcad | still worth getting this update because crashing on non-solid meshes sucks too |
| 03:05.30 | starseeker | very much worth doing if we can get additional robustness |
| 03:05.41 | brlcad | just wondering if there's a way we can get you any repatching for round 3 later? :) |
| 03:05.48 | Stragus | Non-solid was okay, the problem was two triangles sharing the exact same edge, like AB twice |
| 03:06.06 | brlcad | or get you commiting directly to repo or something |
| 03:06.23 | starseeker | will have to hit this with the faa models in brlcad/db/faa |
| 03:06.51 | starseeker | iirc, they blew up pretty spectacularly earlier (not much solid in the Generic_Twin...) |
| 03:07.00 | brlcad | decides he can wait and closes the browser window of 70" oled's |
| 03:07.14 | starseeker | hehehe |
| 03:08.50 | starseeker | is hoping the Dell 8K monitors come down from $5K in the next few years - that'll probably be the last monitor I ever need to buy |
| 03:09.21 | starseeker | Stragus: are you not set up to commit to BRL-CAD? |
| 03:09.22 | brlcad | Stragus: then there may be some other bugs still lurking -- the cases I ran into weren't duplication/sharing |
| 03:09.32 | Stragus | Oh, and we talked about sorting faster than qsort() a w hile... ccradixsort.h is all inlined and should be pretty good |
| 03:10.13 | Stragus | starseeker: I don't think so, and I would have difficulties testing my commits without tracing where it's used |
| 03:10.42 | Stragus | a while* ago |
| 03:10.55 | starseeker | nods - we could set up some unit testing - I'm thinking this would actually make sense at the libbg level, although brlcad may disagree |
| 03:12.15 | starseeker | checks where it's currently hooked in... |
| 03:13.19 | brlcad | all that's needed is to PRE-define what data types go with what libs, then there's not really much room for agreement or disagreement |
| 03:13.40 | brlcad | it's adding types for convenience that I resist, too many types makes for a bad lib |
| 03:14.03 | brlcad | overlapping types makes for confusion |
| 03:14.10 | brlcad | (and overhead) |
| 03:14.16 | starseeker | nods |
| 03:15.05 | starseeker | looks like rt_bot_decimate_gct is what's calling into gct right now |
| 03:16.58 | starseeker | Stragus: I think that may be the only bridge, so our API updating should be confined to that one function |
| 03:17.14 | Stragus | All right |
| 03:21.29 | starseeker | Stragus: I'll try to sneak some time to do some experimentation in the next couple days - I don't know if the FAA model decimations will be sensible, but I'm fairly sure they'll be mean ;-) |
| 03:21.46 | Stragus | What are these models? |
| 03:22.43 | starseeker | They're from an old FAA study back in 2004: http://www.tc.faa.gov/its/worldpac/techrpt/AR04-16.pdf |
| 03:23.29 | starseeker | we initially sucked them in for testing our FASTGEN importer, but they've also proven useful for BoT testing |
| 03:23.44 | Stragus | The models in the PDF seem pretty simple |
| 03:24.27 | starseeker | reasonably - otherwise we wouldn't want them in the main repo - but they're also not solid |
| 03:24.51 | Stragus | Well, let me know if something breaks |
| 03:25.21 | starseeker | nods - will do. They're obviously intended as a "stress test" for invalid inputs, not something that really *needs* decimation |
| 03:25.43 | starseeker | can always go grab the bigger stanford models for that :-) |
| 03:26.10 | starseeker | although I imagine you're there ahead of us |
| 03:26.37 | Stragus | And if you liked that guy's radix sort doing 50% faster (or whatever it was) than std::sort, try the SSE optimized ccradixsort (~500% times faster) |
| 03:26.52 | starseeker | :-) |
| 03:27.03 | starseeker | that's pretty cool |
| 03:27.43 | starseeker | Stragus: thanks for the heads up! |
| 03:28.06 | Stragus | :) You are welcome |
| 03:29.48 | starseeker | Stragus: now, how do we get you interested in robust boolean operations on meshes? ;-) |
| 03:30.25 | starseeker | ducks and runs |
| 03:31.12 | Stragus | Ah! :) I don't know much about that, it seems tricky |
| 03:31.36 | starseeker | there've been a number of interesting papers out in the last few years |
| 03:32.03 | starseeker | http://www.gilbertbernstein.com/resources/booleans2009.pdf for example |
| 03:33.57 | Stragus | I assume you already have "state of the art robust Boolean operations"? It's just slow? |
| 03:34.02 | starseeker | nope |
| 03:34.23 | starseeker | our facetize command is prone to crashing |
| 03:34.57 | Stragus | That sounds bad |
| 03:35.12 | starseeker | preferred approach was/is to convert CSG to NURBS brep, do the booleans in brep space, then mesh the final result |
| 03:35.44 | starseeker | we got some good GSoC work on that, and nreed has done some as well, but there is a ways to go yet to get that really working right |
| 03:35.59 | starseeker | in the meantime, we're stuck with the old NMG pipeline |
| 03:36.41 | Stragus | So the actual problem is converting a soup/hierarchy of CSG into triangles? |
| 03:37.12 | starseeker | well, that's one of them. There are also use cases for the NURBS model, but for shaded displays we've got to get to triangles |
| 03:38.09 | Stragus | Well, it does sound interesting. I'm so tired of physics. And I think I'm getting good with geometry problems |
| 03:38.21 | Stragus | The last little thing was a Constrained Delaunay Triangulation that's many times faster than supposed state of the art |
| 03:38.28 | starseeker | cool! |
| 03:38.45 | starseeker | we use poly2tri for that currently |
| 03:39.27 | Stragus | Here's my CDT in action: http://www.rayforce.net/cdttestgood.png in a couple milliseconds |
| 03:39.33 | starseeker | was kinda hoping to get some GSoC proposals on the geometric guts, but they're tough projects for a summer |
| 03:40.53 | starseeker | wow |
| 03:41.04 | starseeker | that's a mean input |
| 03:41.14 | Stragus | Yup, I was trying to break it :) |
| 03:42.52 | Stragus | And rendered with SSE optimized perfect antialised rendering... I'm writing weird stuff sometimes |
| 03:43.01 | starseeker | hehe |
| 03:44.27 | starseeker | if you really want to fry your brain, look into exact geometric computation: https://hal.inria.fr/inria-00344355/file/p.pdf |
| 03:45.17 | starseeker | for people who Really Care About Robustness |
| 03:45.31 | starseeker | *that's* some tough stuff to make fast |
| 03:47.30 | Stragus | It's always a good idea to design algorithms that consider the numerical accuracy of your floats |
| 03:48.50 | starseeker | nods - most geometry algorithms can't/don't though - if you have a point and a line in space, and your algorithm cares if the point is to the left or right of the line, you've got trouble |
| 03:49.23 | starseeker | https://www.mpi-inf.mpg.de/~mehlhorn/ftp/classroomExamplesNonrobustness.pdf |
| 03:49.43 | Stragus | The idea is generally to have a third scenario, "somehere about on the line", and have some way to manage that and still produce meaningful results |
| 03:49.54 | Stragus | I had to do that in the triangulation too |
| 03:50.47 | starseeker | Stragus: you'll probably have a better appreciation for the classroom examples of nonrobustness then :-) |
| 03:52.13 | starseeker | as I understand it, there are also different "categories" of robustness - once you add repeatability, things like "about on the line" get tricky because you can also get floating point noise interfering with when the call of "close" is made if platforms vary |
| 03:53.56 | Stragus | The idea is that whenever something is "close", you make it robust, you pick a decision and that's how it stays. "I decree and declare that A is on the LEFT of line B, forever and ever" |
| 03:53.59 | starseeker | Stragus: someday (in my infinite free time) i'd like to do some experimenting with ECG and other strategies like snap rounding |
| 03:54.25 | Stragus | That result can be stored in some space partitioning, hash table, or whatever; and you look it up whenever you are within the range of inaccuracy |
| 03:54.50 | starseeker | neat stuff |
| 03:56.02 | starseeker | has to call it a night - thanks again Stragus for letting us know about the robustness updates! |
| 03:56.08 | Stragus | Good night! |
| 05:47.48 | *** join/#brlcad KimK (~Kim__@2600:8803:7a81:7400:7d42:b42c:3d3:a22e) |
| 06:30.05 | *** join/#brlcad Caterpillar (~caterpill@unaffiliated/caterpillar) |
| 06:42.29 | *** join/#brlcad chenzhe (~Thunderbi@d66-222-134-161.abhsia.telus.net) |
| 09:39.00 | *** join/#brlcad HoloIRCUser3 (~holoirc@182.69.180.229) |
| 11:33.24 | *** join/#brlcad teepee (~teepee@unaffiliated/teepee) |
| 12:36.50 | *** join/#brlcad kintel (~kintel@unaffiliated/kintel) |
| 13:05.22 | *** join/#brlcad Sound (~Sound@94-37-105-8.adsl-ull.clienti.tiscali.it) |
| 13:05.36 | *** join/#brlcad Sound (~Sound@unaffiliated/sound) |
| 13:35.17 | starseeker | makes a note of https://github.com/Mysticial/FeatureDetector - might be worth comparing to our runtime detection... |
| 14:46.03 | *** join/#brlcad CuriousErnestBro (~CuriousEr@unaffiliated/curiousernestbri) |
| 15:54.16 | *** join/#brlcad teepee (~teepee@unaffiliated/teepee) |
| 16:00.30 | *** join/#brlcad yorik (~yorik@2804:431:f721:6332:290:f5ff:fedc:3bb2) |
| 16:30.27 | *** join/#brlcad sagarwal (~holoirc@182.69.180.229) |
| 16:34.09 | *** join/#brlcad sagarwal (~holoirc@182.69.180.229) |
| 17:07.04 | *** join/#brlcad gabbar1947 (uid205515@gateway/web/irccloud.com/x-hrjmxwfhoiqxkckz) |
| 17:22.59 | *** join/#brlcad chenzhe (~Thunderbi@2620:101:c040:7f7:34b5:80ef:37e:dc22) |
| 20:14.25 | *** join/#brlcad chenzhe (~Thunderbi@2620:101:c040:7f7:4c10:8311:f4b1:b44b) |
| 20:18.00 | Notify | 03BRL-CAD:starseeker * 69740 brlcad/trunk/src/external/CREO/part.cpp: Go with .s for solid extension. |
| 20:49.30 | *** join/#brlcad yorik (~yorik@2804:431:f721:bd20:290:f5ff:fedc:3bb2) |
| 21:28.44 | Notify | 03BRL-CAD:starseeker * 69741 brlcad/trunk/src/external/CREO/creo-brl.dat.in: Allow stopping of the plug-in |
| 22:20.12 | Stragus | starseeker: You could also compare with this: http://www.rayforce.net/brlcad/cpuinfo.c http://www.rayforce.net/brlcad/cpuinfo.h |
| 22:20.44 | Stragus | It also extracts information about the size of the caches, how they are shared between cores, etc. |
| 22:22.54 | Stragus | You just cpuGetInfo() and look what's in the struct |
| 23:15.51 | *** join/#brlcad teepee (~teepee@unaffiliated/teepee) |
| 23:16.30 | Notify | 03BRL-CAD:starseeker * 69742 brlcad/trunk/src/external/CREO/util.cpp: bu_log and CREO seem to be arguing about locking somehow or other... |
| 23:18.57 | Notify | 03BRL-CAD:starseeker * 69743 brlcad/trunk/src/external/CREO/main.cpp: tweak file opening logic... may switch to specifying strings in GUI, now that we've figured out how to increase the input buffer max length... |
