| 00:06.56 | *** join/#brlcad teepee (~teepee@unaffiliated/teepee) | |
| 00:29.14 | *** join/#brlcad kintel (~kintel@unaffiliated/kintel) | |
| 00:39.53 | *** join/#brlcad LordOfBikes (~armin@dslb-088-064-044-040.088.064.pools.vodafone-ip.de) | |
| 00:40.00 | *** join/#brlcad kintel (~kintel@unaffiliated/kintel) | |
| 02:29.02 | starseeker | OK, things do build and run without strict mode on for OpenBSD |
| 02:55.31 | *** join/#brlcad boj_ (~boj@2001:250:3c00:2074:f8d7:ba32:880b:9139) | |
| 03:34.21 | *** join/#brlcad kintel (~kintel@unaffiliated/kintel) | |
| 04:14.41 | *** join/#brlcad kintel (~kintel@unaffiliated/kintel) | |
| 05:21.31 | *** join/#brlcad Mathnerd314 (~quassel@supertux/Mathnerd314) | |
| 07:13.29 | *** join/#brlcad teepee (~teepee@unaffiliated/teepee) | |
| 07:24.02 | *** join/#brlcad d_rossberg (~rossberg@66-118-151-70.static.sagonet.net) | |
| 08:07.31 | *** join/#brlcad teepee` (bc5c2134@gateway/web/freenode/ip.188.92.33.52) | |
| 08:11.01 | *** join/#brlcad sniok (~sniok@89.252.2.135) | |
| 12:28.34 | *** join/#brlcad yorik (~yorik@187.35.19.227) | |
| 12:35.36 | *** join/#brlcad kintel (~kintel@unaffiliated/kintel) | |
| 13:01.01 | starseeker | wonders if BRL-CAD can support reproducible building without too much trouble - kinda sounds like Debian is trying to head in that direction |
| 13:01.37 | starseeker | Stragus: do you happen to know if your decimation code for BoTs has any requirements like needing closed topology? |
| 13:04.44 | starseeker | also, it looks like it's possible to decimate a bot down to empty with a large enough feature size relative to the bot - it would be nice to have some kind of limit... |
| 13:06.41 | *** join/#brlcad infobot (ibot@rikers.org) | |
| 13:06.41 | *** topic/#brlcad is Welcome to BRL-CAD! || Don't ask if someone is here, ask a better question. || We're participating in GSoC 2016! Patches required. || Major release 7.26 coming any day now... :P || New website deployed, feedback welcome! || Logs: http://ibot.rikers.org/%23brlcad/ | |
| 14:07.59 | *** join/#brlcad Mathnerd314 (~quassel@supertux/Mathnerd314) | |
| 14:12.59 | *** join/#brlcad kintel (~kintel@unaffiliated/kintel) | |
| 14:45.52 | *** join/#brlcad sniok (~sniok@89.252.2.135) | |
| 15:17.31 | *** join/#brlcad maths22_ (~maths22@66-118-151-70.static.sagonet.net) | |
| 15:17.31 | *** join/#brlcad maths22_ (~maths22@unaffiliated/maths22) | |
| 15:19.12 | *** join/#brlcad annisar_ (~kamil@mail.soltysik.in) | |
| 15:21.49 | *** join/#brlcad poxip (~poxip@2a01:115f:461:7d00:ba27:ebff:fef7:2541) | |
| 15:21.50 | *** join/#brlcad poxip (~poxip@unaffiliated/mrpoxipol) | |
| 16:12.59 | *** join/#brlcad kintel (~kintel@unaffiliated/kintel) | |
| 16:15.35 | *** join/#brlcad shubham (71c18b78@gateway/web/freenode/ip.113.193.139.120) | |
| 17:01.03 | *** join/#brlcad amarjeet (~Amarjeet@49.138.207.62) | |
| 17:08.18 | *** join/#brlcad amarjeet (~Amarjeet@49.138.207.62) | |
| 17:16.31 | *** join/#brlcad amarjeet (~Amarjeet@49.138.207.62) | |
| 17:24.05 | Stragus | starseeker, the decimation code doesn't require a closed topology, it has some factor somewhere for the resiliency of solitary edges |
| 17:24.33 | Stragus | But, very importantly, it expects correctly shaped geometry. A single edge between vertices A and B can only be shared by two triangles in the order: AB and BA |
| 17:25.15 | Stragus | If that edge AB is shared by 3 triangles, it's going to produce errors. It doesn't check for such errors, it assumes input data that makes sense, properly oriented |
| 17:27.18 | Stragus | That's for performance reasons but also because the input data at the time was guaranteed to be "sane". For other purposes, I agree better detection/handling of bad data would have been a nice addition... |
| 17:29.27 | Stragus | Now that I remember, I had also written a tiny piece of separate code that would "fix" the orientation of triangles and detect other issues, after someone tried to use decimation code on random (and broken) meshes |
| 17:30.18 | Stragus | That's nothing too complicated, I assume you already have something like that somewhere in BRL-CAD |
| 17:37.55 | *** join/#brlcad amarjeet (~Amarjeet@49.138.207.62) | |
| 17:45.03 | *** join/#brlcad amarjeet (~Amarjeet@49.138.207.62) | |
| 17:48.44 | Notify | 03BRL-CAD:n_reed * 67818 brlcad/branches/brep-debug/doc/docbook/system/implementation/en/bool_eval_development.xml: add descriptions of dplot ssx subcommands |
| 18:09.15 | *** join/#brlcad amarjeet (~Amarjeet@49.138.207.62) | |
| 20:29.21 | *** join/#brlcad MandeepSingh (~Mandeep_S@202.164.53.122) | |
| 20:32.03 | Notify | 03BRL-CAD:starseeker * 67819 brlcad/trunk/CHANGES: add solid.h to the deprecation list - currently public API, should ultimately be managed by libdm backends. Currently exposed in libtclcad, mged and libged - some refactoring and command rework will be needed to hide it successfully, but the idea will be for applications to specify *what* they want drawn (probably via ascii paths or db_full_path entries) and have |
| 20:32.05 | Notify | the dm manage *how* it is drawn. struct solid falls squarely into the 'how' category. |
| 20:32.07 | Notify | ... |
| 20:33.18 | Notify | 03BRL-CAD:n_reed * 67820 brlcad/branches/brep-debug/doc/docbook/system/implementation/en/bool_eval_development.xml: add descriptions of the dplot isocsx subcommands |
| 20:33.25 | starseeker | Stragus: not sure (mesh fixing code) - I think we may have some similar routines for some of the libgcv conversion work, but I'd have to dig |
| 22:05.12 | *** join/#brlcad yorik (~yorik@187.35.19.227) | |
| 22:49.45 | *** join/#brlcad teepee (~teepee@unaffiliated/teepee) | |
| 23:01.38 | *** join/#brlcad kintel (~kintel@unaffiliated/kintel) | |
| 23:27.23 | *** join/#brlcad kintel (~kintel@unaffiliated/kintel) | |