| 01:05.17 | starseeker | arrrrrrgh!!!! |
| 01:05.35 | starseeker | http://www.wikistep.org/index.php/PDM-UG:_Implicit_Relationships_Between_Assembly_Components |
| 01:06.45 | starseeker | "Another possibility is the definition of the assembly construction history via a cartesian_transformation_operator. The Part 42 definition of cartesian_transformation_operator also allows for scaling and mirroring. But scaling and mirroring shall not to be applied in the context of assemblies." |
| 01:06.53 | starseeker | no wonder |
| 01:18.59 | starseeker | adds http://www.steptools.com/support/stdev_docs/express/pdm/pdmug_release4_3.pdf to the list of useful STEP docs... |
| 01:34.03 | Notify | 03BRL-CAD:starseeker * 59611 brlcad/trunk/src/conv/step/g-step/Assembly_Product.cpp: Document in some detail why we're going to have a problem with scaling matricies in our comb hierarchies when exporting to STEP. Need to think about our options here - in principle we could do an 'in-memory' application of the matricies ourselves, but that amounts to a duplication of the xpush logic in the converter. We don't want |
| 01:34.05 | Notify | to simply run xpush on the existing .g database, because conversion shouldn't change the existing data. For now, simply print a message warning about the problem and pointing the user to xpush - that'll at least be informative until we decide on a solution. |
| 02:36.13 | Notify | 03BRL-CAD:starseeker * 59612 (brlcad/trunk/src/conv/step/g-step/AP203.h brlcad/trunk/src/conv/step/g-step/Assembly_Product.cpp and 5 others): Re-use some context objects - for the m35 export, takes the object count from 219464 to 203252 |
| 02:45.00 | Notify | 03BRL-CAD:starseeker * 59613 brlcad/trunk/src/conv/step/g-step/ON_Brep.cpp: The empty brep trick 'works' in the sense of letting things function, but technically speaking the step file will cause parsers to report an invalid entity. Not sure that's a bad thing, honestly, since we do have a real issue if we can't export objects... |
| 03:02.33 | Notify | 03BRL-CAD:starseeker * 59614 brlcad/trunk/src/conv/step/g-step/g-step.cpp: Allow for a list of objects to export, instead of just one. |
| 03:28.20 | Notify | 03BRL-CAD:starseeker * 59615 brlcad/trunk/doc/docbook/system/man1/en/CMakeLists.txt: Stub in a basic man page for g-step |
| 04:33.30 | brlcad | starseeker: VUNITIZE_TOL is smaller than RT_LEN_TOL |
| 04:34.09 | brlcad | ah, not on some platforms, never mind |
| 04:34.47 | brlcad | it's either 1e-7 or 1e-15 (was thinking it was latter) |
| 04:36.40 | brlcad | sounds like you maybe needed RT_DOT_TOL |
| 05:30.25 | Notify | 03BRL-CAD:brlcad * 59616 brlcad/trunk/src/libbu/tests/bitv-tests.txt: the lib utilizes libbu, so it needs to declare that dependency or we'll get unresolved symbols |
| 07:20.24 | *** join/#brlcad FOSScookie (~brian@107-200-34-31.lightspeed.tulsok.sbcglobal.net) |
| 08:14.11 | *** join/#brlcad zxq9 (~ceverett@FL9-125-199-207-150.okn.mesh.ad.jp) |
| 08:58.29 | *** join/#brlcad Anaphaxeton (~george@unaffiliated/anaphaxeton) |
| 09:19.21 | *** join/#brlcad FOSScookie (~brian@107-200-34-31.lightspeed.tulsok.sbcglobal.net) |
| 09:41.33 | *** join/#brlcad localhost (~localhost@195.24.220.16) |
| 09:42.42 | localhost | ls |
| 10:06.51 | *** join/#brlcad localhost (~localhost@195.24.220.16) |
| 11:55.41 | *** join/#brlcad Anaphaxeton (~george@unaffiliated/anaphaxeton) |
| 13:04.59 | Notify | 03BRL-CAD:starseeker * 59617 brlcad/trunk/misc/CMake/validate_style.cmake.in: Add a non-fatal mode to the astyle checks, tying it to BRLCAD_ENABLE_STRICT - analogous to how XML validation is handled in DocBook processing. |
| 14:34.29 | Notify | 03BRL-CAD Wiki:Nabilibrahim * 0 /wiki/User:Nabilibrahim: |
| 14:52.59 | Notify | 03BRL-CAD:starseeker * 59618 brlcad/trunk/src/conv/step/g-step/ON_Brep.cpp: Avoid a crashing condition where the EdgeCurveIndexOf is greater than the number of edge curves actually present in the Brep structure. |
| 15:24.26 | starseeker | brlcad: does libbu have some function or functions that will identify and extract parts of a filename? |
| 15:24.34 | starseeker | if not, would it be appropriate to add them? |
| 15:25.19 | starseeker | I can see, for example, converters wanting to strip the .png or .pix off of an input file name to autogenerate an output name... |
| 15:27.10 | starseeker | although I suppose if the convention is supposed to be write to stdout by default that's a moot point... |
| 16:23.52 | Notify | 03BRL-CAD:starseeker * 59619 brlcad/trunk/src/conv/step/g-step/Assembly_Product.cpp: Uh-oh - we seem to have a difference of opinions between CAD systems about which way is right - Creo shows the correct results *without* flipping outorig, but Rhino wants the other way. Perhaps I need to explicitly specify something somewhere? |
| 16:50.27 | Notify | 03BRL-CAD:starseeker * 59620 brlcad/trunk/src/conv/step/g-step/Comb.cpp: Use the comb's name in a few more places - shows up in Creo now. Still working on lower level objects |
| 16:59.39 | Notify | 03BRL-CAD:starseeker * 59621 (brlcad/trunk/src/conv/step/g-step/ON_Brep.cpp brlcad/trunk/src/conv/step/g-step/Shape_Definition_Representation.cpp brlcad/trunk/src/conv/step/g-step/Shape_Definition_Representation.h): Also get solid names showing up in Creo |
| 18:06.56 | Notify | 03BRL-CAD:starseeker * 59622 (brlcad/trunk/src/conv/step/g-step/AP203.h brlcad/trunk/src/conv/step/g-step/Assembly_Product.cpp brlcad/trunk/src/conv/step/g-step/g-step.cpp): Until I can figure out the right way to get uniform behavior, provide a flag to flip the direction |
| 18:15.46 | Notify | 03BRL-CAD:n_reed * 59623 brlcad/trunk/src/libbrep/intersect.cpp: simplify error handling when building surface/curve tree roots |
| 18:52.13 | Notify | 03BRL-CAD:carlmoore * 59624 (brlcad/trunk/doc/PROJECTS brlcad/trunk/doc/docbook/system/man1/en/g-step.xml brlcad/trunk/src/conv/step/g-step/Assembly_Product.cpp): fix spellings |
| 19:40.44 | starseeker | interesting discussion on automatic source code formatting: http://www.cmake.org/pipermail/cmake/2014-January/056892.html |
| 19:41.07 | starseeker | may have to take a look at uncrustify - seems to be getting a lot of positive reviews |
| 19:42.08 | Notify | 03BRL-CAD:n_reed * 59625 brlcad/trunk/src/libbrep/intersect.cpp: Move tolerance calculation to function. There was actually a minor error in the original code, because the surfB calculations were using surfA's bbox diagonal length. |
| 20:01.18 | brlcad | starseeker: re 59619 is that because of a difference in coordinate systems? |
| 20:02.47 | brlcad | starseeker: and I'll have to take a look about filename parts. there is dirname and basename obviously, but my gut is that the few tools that do try to automanage the name do so themselves manually |
| 20:07.59 | brlcad | fitting in with the existing functions, a general solution would be to simply tokenize a string into an argv, replace the last argv with new suffix |
| 20:13.08 | brlcad | something like: size_t bu_tokenize(char *argv[], size_t lim, const char *str, int sep); |
| 20:17.59 | brlcad | char *av[MAXPATH] = {0}; char *file = "my_filename.tar.gz"; size_t pieces = bu_tokenize(av, MAXPATH, file, '.'); do { printf("[%d] => %s\n", pieces-1, av[pieces-1]); } while(pieces--); |
| 20:18.06 | brlcad | would print |
| 20:18.08 | brlcad | [2] => gz |
| 20:18.13 | brlcad | [1] => tar |
| 20:18.18 | brlcad | [0] => my_filename |
| 20:19.41 | brlcad | and you could av[pieces-1] = "bz2" if you wanted to create a my_filename.tar.bz2 filename without knowing any of the front or av[1] = "zip"; av[2] = NULL; if you wanted my_filename.zip, etc |
| 20:21.27 | brlcad | strsep(), strtok(), strchr() are the common ways to do this |
| 20:26.41 | brlcad | alternatively, just creating a bu_extension() and bu_extension_replace() pairing to get/change an extension would be cool too ... that'd be just as useful |
| 20:29.21 | Notify | 03BRL-CAD:n_reed * 59626 brlcad/trunk/src/libbrep/intersect.cpp: move curve tolerance calculation to function |
| 20:29.30 | Notify | 03BRL-CAD:starseeker * 59627 brlcad/trunk/src/conv/step/g-ap214/CMakeLists.txt: Rename ap214 header |
| 21:05.47 | Notify | 03BRL-CAD:starseeker * 59628 (brlcad/trunk/src/conv/step/CMakeLists.txt brlcad/trunk/src/conv/step/g-ap214/AP214e3.h and 25 others): Generalize the code some more to re-enable sharing of AP203 code in AP214's exporter. |
| 21:07.14 | starseeker | brlcad: re 59619 - I don't know what's causing it. On the surface Rhino and Creo are doing different things with the same input file |
| 21:10.24 | starseeker | I would like to jump to the conclusion they're interpreting something differently, but it's more likely I'm not specifying something I need to specify that would get me to the same behavior... I just don't have a clue as to what it would be |
| 21:38.27 | brlcad | that's why I'm wondering if it's a coordinate system specification |
| 21:38.32 | brlcad | right hand vs left hand |
| 21:38.34 | brlcad | and what is up |
| 21:39.02 | brlcad | I'd hope the step handbook talks about that somewhere |
| 21:58.20 | Notify | 03BRL-CAD:n_reed * 59629 brlcad/trunk/src/libbrep/intersect.cpp: move overlap calculation to separate function |
| 22:04.40 | starseeker | it's a little hard to search for online, but I haven't seen anything that indicates Rhino and Creo use different conventions... |
| 22:14.34 | Notify | 03BRL-CAD:starseeker * 59630 (brlcad/trunk/src/conv/step/g-ap214/AP214e3.h brlcad/trunk/src/conv/step/g-ap214/Add_Tree.cpp brlcad/trunk/src/conv/step/g-ap214/G_Objects.cpp): Get the test tree walk running again. |
| 22:18.34 | *** join/#brlcad FOSScookie (~brian@107-200-34-31.lightspeed.tulsok.sbcglobal.net) |
| 23:04.49 | Notify | 03BRL-CAD:tbrowder2 * 59631 brlcad/trunk/regress/repository.sh: add '*.cc' for src and hdr files |
| 23:11.38 | Notify | 03BRL-CAD:starseeker * 59632 brlcad/trunk/src/conv/step/g-ap214/Add_Tree.cpp: More tree exploration. It may be that an xpush is a necessity for these containers to work... |
| 23:30.06 | Notify | 03BRL-CAD:starseeker * 59633 brlcad/trunk/src/conv/step/g-ap214/Add_Tree.cpp: Make some notes on how we're going to need to break out combs into regions and assemblies. |
| 23:39.54 | *** join/#brlcad FOSScookie (~brian@107-200-34-31.lightspeed.tulsok.sbcglobal.net) |