| 00:21.37 | learner | PrezKennedy, just need to buy yourself a car and then that wouldn't be a problem |
| 00:27.49 | PrezKennedy | not exactly what i had in mind |
| 00:27.50 | PrezKennedy | :-p |
| 00:28.43 | learner | :) |
| 01:45.37 | *** join/#brlcad polyspin (~polyspin@pcp0011463358pcs.chrchv01.md.comcast.net) |
| 01:47.37 | polyspin | Anybody home? |
| 02:43.12 | ewilhelm_ | guess not |
| 02:48.03 | polyspin | doesn't look like it |
| 02:53.50 | narnia | nobody here except us prisoners |
| 04:27.18 | Twingy | o.O |
| 04:28.22 | Twingy | these pesky microcontrollers are addictive |
| 04:29.41 | learner | nobody at all |
| 04:35.11 | CIA-5 | BRL-CAD: 03brlcad * 10brlcad/include/Makefile.am: config.h was renamed to brlcad_config.h |
| 05:02.40 | CIA-5 | BRL-CAD: 03brlcad * 10brlcad/HACKING: config.h is renamed to brlcad_config.h |
| 05:10.32 | learner | there are a handful of others that slipped under the radar |
| 05:10.35 | learner | fixing |
| 05:19.04 | CIA-5 | BRL-CAD: 03brlcad * 10brlcad/ (15 files in 10 dirs): more config.h references converted to brlcad_config.h (or common.h where appropriate) that apparently slipped under the radar |
| 05:19.51 | learner | that should do it |
| 05:20.13 | polyspin | fetching (rarf!) |
| 05:20.59 | learner | the existing generated config.h hid those files .. that weren't supposed to be directly using config.h anyways |
| 05:21.22 | learner | they must have been hiding since the original regex |
| 05:21.56 | learner | doing a distcheck now to verify, that should catch anything missed better |
| 05:23.54 | narnia | okay, when should the end-user receive error/warning messages during the conversion of an iso 10303 part21 (.stp) file to brl-cad? when each warning/error occurs or as a summary? also what should be included in the error/warning message? |
| 05:25.02 | learner | probably include the reference names and geometry types |
| 05:25.04 | narnia | i do not see much sense in telling an end-user that at line nnn entity instance #121231 has an error. |
| 05:25.46 | learner | probably not, but maybe that a brep failed might be |
| 05:26.04 | polyspin | The user wants to know what part it was in |
| 05:26.30 | learner | probably should be as forgiving as possibe too.. they don't have much they can do about invalid files |
| 05:27.05 | narnia | so telling the end-user that entity instance #121231=cartesian_point('CarPnt1', 1.0, 2.3, 12.0); at line nnn has an error. |
| 05:28.06 | learner | what kind of errors are you talking about? |
| 05:28.26 | narnia | part21 does not give much lead way in being forgiving. if an entity instance violates the governing schema there is no forgiving. |
| 05:28.27 | learner | there are fatal errors (in which case you should probably just abort), and more common non-fatal errors |
| 05:29.03 | learner | well, in your example -- what makes it an error? |
| 05:30.19 | learner | there are also syntax and semantic violations that you may or may not be able to recover from, of course |
| 05:30.21 | narnia | the error could be any number of things. |
| 05:31.14 | learner | that's part of my point too .. there are different classes of errors, treating them all as one or another will likely just lead to unexpected results |
| 05:31.59 | narnia | that entity instance may be used as an attribute to a trimmed_curve, polyline, etc. and local rules and/or global rules when constrain the values allowed for a cartesian_point. |
| 05:33.19 | learner | but in your example itself, that line wouldn't be the error -- it's usage somewhere as a referenced cartesian point might be an error |
| 05:33.48 | narnia | yes |
| 05:34.38 | narnia | the cartesian_point is syntatically and semantically correct it is the use of the cartesian_point that is the error. |
| 05:34.46 | learner | in that case, that'd be an error I'd expect the syntax/semantic parser library to catch on load, not necessarily the converter .. dunno |
| 05:35.29 | learner | i suppose you might be converting a portion of a step file that is correct, so you wouldn't know until parse time |
| 05:37.29 | learner | still, I imagine any converter is basically going to do just a handful of "phases" .. 1) read in the file 2) parse file contents into a parsed tree for in-memory representation 3) convert in-memory rep to brl-cad .g in-memory rep 4) write .g in-memory rep to disk |
| 05:38.20 | learner | errors in 1 and 4 would likely be fatal since they'd be file/disk read errors |
| 05:38.27 | narnia | converting a portion of a step file is a non-trivial task. most .stp files i am using to experiement and test with must be read entirely in and validated before you know there is an error. some depends on where the header section of the part21 .stp file specifies file_population. |
| 05:40.04 | learner | 2 is the complex step since it involves parsing the entire .stp -- if it doesn't validate, it could be considered fatal but that will require good validation that the reason it didn't validate was the file's fault and not the parser (practically a "hard" task, regardless) |
| 05:40.08 | narnia | currently it is an all or nothing on conversion. |
| 05:40.54 | learner | "errors" in step 3 are more likely "unsupported/incomplete" geometry types .. so I'd just warn |
| 05:42.43 | learner | sounds like you're mostly referring to the parsing of the step file (task 2 in my list), so sure, fail out -- might as well fail out early if there's nothing to be done about it |
| 05:43.00 | learner | it's not like I'll care knowing that there were 38 errors or 1 if it's just going to halt conversion |
| 05:43.50 | narnia | the more i work on 10303 the more i become convinced that there needs to be a true express language compiler. |
| 05:43.51 | learner | again, though, if they're not fatal, then I'd just keep a list of warnings and output them in the summary |
| 05:51.08 | narnia | the parser is being checked by wrting out a new copy of the parsed .stp file. the 'diff' of the two files is then taking. |
| 05:52.08 | narnia | basically, diff -u --ignore-all-space <orginal.stp> <copy.stp> |
| 05:53.29 | learner | heh, that sounds like harsh validation |
| 05:53.35 | learner | it's order dependant.. |
| 05:54.03 | learner | i suppose if you can guarantee that you're in-memory format will preserve the parsed order, it should match |
| 05:54.07 | narnia | complex entities are a nightmare. also entities which are a subtype of more than one supertype are also a nightmare. |
| 05:55.00 | learner | having the in-memory order preserve the parse order sort of defeats the purspose of having an in-memory representation a little |
| 05:58.26 | narnia | i have never done brep stuff. my project was all csg. brep is a new animal to me. |
| 06:00.13 | learner | not much different, just pitch topological connectivity information out the window for primitive shapes and you have brep ;) |
| 06:02.12 | *** join/#brlcad d_rossberg (~c28bf505@bz.bzflag.bz) |
| 06:02.25 | learner | guten tag, d_rossberg |
| 06:02.58 | d_rossberg | god morning, who ever you are |
| 06:04.19 | d_rossberg | isnt't it a little bit late for US, in Germany it't a nice time to start working |
| 06:04.41 | learner | a lil bit, more so in some parts |
| 06:05.03 | narnia | it is 0101 hours here. |
| 06:05.55 | d_rossberg | sorry, some keys seem not no be at the right position on my keyboard :-} |
| 06:06.14 | d_rossberg | yes, I see, 6h difference |
| 06:07.06 | d_rossberg | or, wait, this are 7h! |
| 06:07.38 | d_rossberg | so you are likely not at the east coast |
| 06:07.53 | learner | i seem to live on pacific time in an atlantic zone |
| 06:08.00 | narnia | no, i am 79 miles west of america's tallest target. |
| 06:09.49 | narnia | in case you do not know that is the sears building in chicago, illinois. |
| 06:11.06 | narnia | i hear the rent in the sears building is really cheap. it is also cheap in the buildings close to the sears building. |
| 06:11.21 | d_rossberg | no, i didn't know it |
| 06:11.56 | narnia | since 9/11 the sears building became the tallest building in u.s.a. |
| 06:12.37 | d_rossberg | this explains something |
| 06:13.31 | d_rossberg | I was once in NY but nevet in Chicago |
| 06:14.04 | narnia | so most of us who live here are just waiting for the sears building to be 'hit'. it is not a matter of 'if' just a matter of 'when' it will be 'hit'. |
| 06:15.10 | narnia | learner, any good urls that explain brep for the novice? |
| 06:15.49 | d_rossberg | nobody knows the sears building so why should anybody want to hit it ;-) |
| 06:16.03 | learner | http://www.cadcamcenter.com/cadcam/solid_modeling.htm |
| 06:16.16 | narnia | because of what it represents. |
| 06:17.23 | learner | it's worth noting that brl-cad technically supports all four of those, it's just csg that it emphasized and catered to |
| 06:17.53 | learner | the raytrace process almost completely through implicit equations |
| 06:18.42 | learner | brl-cad's stl format is technically one type of brep |
| 06:18.48 | *** join/#brlcad d_rossberg (~c28bf505@bz.bzflag.bz) |
| 06:18.54 | learner | bleh, s/stl/BoT/ |
| 06:18.59 | d_rossberg | sorry, wrong mouse buton |
| 06:19.10 | learner | no harm done :) |
| 06:19.32 | d_rossberg | I'm working with the web interface at brlcad.org |
| 06:19.59 | d_rossberg | and "page back" closes the conection |
| 06:20.04 | learner | your identifying information tells that when you join ;) |
| 06:21.00 | d_rossberg | OK, something about me: http://www.iabg.de/verteidigung/brlcad/index_en.php |
| 06:25.06 | d_rossberg | the program the is unfortunately old |
| 06:25.48 | d_rossberg | i couldn't get a permission distribute version build on BRL-CAD 6.02 |
| 06:26.14 | learner | that looks like it's less about you and more about a viewer that you wrote :) |
| 06:27.22 | learner | fortunately you don't need permission for version 7+ |
| 06:27.31 | learner | any plans to update to 7? |
| 06:27.50 | d_rossberg | i thought, my connection to BRL-CAD is of special interest here |
| 06:27.54 | learner | file format is the same as 6 |
| 06:28.19 | d_rossberg | yes, thats why i'm here (+ sth. other) |
| 06:29.29 | learner | your connection is definitely of special interest.. :) |
| 06:31.14 | learner | all will become more clear soon enough probably |
| 06:31.57 | brlcad | soon enough indeed :) |
| 06:33.50 | d_rossberg | btw, the viewer is build on the Qt libraries, therefore it isn't so MS specific as it look like |
| 06:34.34 | learner | narnia: the biggest issue that came out of the old brep vs csg wars was that it's generally much harder to perform "feature operations" in csg (blends for example) whereas csg is generally much more efficient and exact |
| 06:34.54 | brlcad | ooh, that I did not know.. nice |
| 06:40.05 | learner | narnia, in implementation it generally boils down to implicitly defined primitives, voxel shapes, spline surfaces, and polygonal surfaces |
| 06:41.43 | learner | traditional csg modeling generally refers to just implicit primitives, though the latter three can technically be primitives (as they are in brl-cad) and be successfully used in csg as well |
| 06:42.28 | learner | traditional finite element analysis modeling generally uses polygonal surfaces (meshes) or voxel shapes |
| 06:43.13 | learner | traditional brep is generally one of the later two (spline or polygonal) |
| 06:43.48 | learner | not much is traditional any more, though .. most have shades of all four of them to some degree |
| 07:06.12 | PrezKennedy | ping pong... |
| 09:54.15 | narnia | pong ping |
| 10:20.35 | narnia | okay this is not normal. may 3rd and it is 28?F outside. |
| 10:21.07 | narnia | a new record low temperature. |
| 10:58.59 | d_rossberg | 64°F (yesterday 86°F) |
| 12:41.13 | *** join/#brlcad learner (~brlcad@brlcad.bronze.supporter.pdpc) |
| 12:41.13 | *** join/#brlcad d_rossberg (~c28bf505@bz.bzflag.bz) [NETSPLIT VICTIM] |
| 12:41.13 | *** join/#brlcad CIA-5 (~CIA@flapjack.navi.cx) |
| 12:41.14 | *** join/#brlcad brlcad (~brlcad@bz.bzflag.bz) [NETSPLIT VICTIM] |
| 12:41.14 | *** join/#brlcad cad542 (~c28bf505@bz.bzflag.bz) [NETSPLIT VICTIM] |
| 12:41.14 | *** join/#brlcad guu (guu@myth.gibbscam.com) |
| 12:41.14 | *** mode/#brlcad [+o learner] by irc.freenode.net |
| 12:42.43 | *** join/#brlcad learner (~brlcad@brlcad.bronze.supporter.pdpc) |
| 12:42.43 | *** mode/#brlcad [+o learner] by ChanServ |
| 17:00.53 | *** join/#brlcad cad625 (~c0a02a63@bz.bzflag.bz) |
| 17:48.57 | narnia | how many dimensions does brl-cad grok? 2d and 3d i would consider the norm. does brl-cad grok dimensions higher than 3? |
| 20:14.51 | ewilhelm_ | are you trying to model temperature or time? |
| 20:29.52 | narnia | no, i noticed in iso 10303 that dimensions higher than 3 are allowed. |
| 20:57.47 | *** join/#brlcad Twingy2 (~justin@pcp0011643033pcs.aberdn01.md.comcast.net) |
| 21:08.20 | narnia | Twingy, i see you are into cloning. |
| 22:19.04 | brlcad | narnia: 3d in the format |
| 22:19.47 | brlcad | 2d is really 3d, and 4d is supported through the animation tools to a limited degree (time) |
| 22:20.01 | brlcad | but the geometry format itself is presently only 3d |
| 22:26.37 | CIA-5 | BRL-CAD: 03brlcad * 10brlcad/src/tab/tabinterp.c: ansify |
| 22:30.16 | CIA-5 | BRL-CAD: 03brlcad * 10brlcad/src/tab/tabsub.c: |
| 22:30.17 | CIA-5 | BRL-CAD: fix a bug on filesystems computing the buffer size on 64bit filesystems. we |
| 22:30.17 | CIA-5 | BRL-CAD: shouldn't directly attempt to allocate a buffer equal to the input file size, |
| 22:30.17 | CIA-5 | BRL-CAD: but with the size_t it should actually work (casting from off_t) so long as the |
| 22:30.17 | CIA-5 | BRL-CAD: size is less than max size_t. add some extra error checking while we're in here |
| 22:30.17 | CIA-5 | BRL-CAD: and get rid of a global. |
| 22:33.52 | CIA-5 | BRL-CAD: 03brlcad * 10brlcad/NEWS: fixed tabsub 64bit filesystem file read bug |