| 00:15.16 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) |
| 01:47.35 | *** join/#brlcad R0b0t1 (~Enigma@unaffiliated/r0b0t1) |
| 01:57.49 | *** join/#brlcad crazy_imp (~mj@a89-182-216-29.net-htp.de) |
| 03:14.18 | *** join/#brlcad DX^ (~DX@c-71-59-50-121.hsd1.ga.comcast.net) |
| 03:14.20 | DX^ | Hello. |
| 03:14.51 | DX^ | I'm interested in creating a COLLADA exporter for BRL-CAD |
| 03:15.10 | DX^ | I was hoping I could possibly modify the X3D exporter. |
| 03:15.13 | DX^ | What do you guys think? |
| 03:23.40 | DX^ | Is anyone alive? hehe |
| 03:37.33 | louipc | DX^: many are quite alive, maybe just sleeping or busy |
| 03:37.40 | louipc | stay tuned for more ;) |
| 03:42.21 | DX^ | Hello! |
| 03:42.34 | DX^ | I'm poking around BRL-CAD's website |
| 03:42.47 | DX^ | but I can't find any extended documentation on the internal structure that the geometry is stored in |
| 03:42.50 | DX^ | perhaps I am blind? |
| 03:47.30 | louipc | hmm you might have more luck with files in the svn repo |
| 03:47.44 | louipc | you can generate doxygen docs I believe |
| 03:48.05 | louipc | they used to be hosted, but I'm not sure where they are or what happened to them |
| 03:49.19 | DX^ | ah, seems some framework code is in g-xxx_facets.c |
| 03:49.24 | DX^ | which is most probably what I need |
| 08:14.31 | *** join/#brlcad merzo (~merzo@193.254.217.44) |
| 12:08.30 | *** join/#brlcad Yoshi47 (~jan@64.235.102.210) |
| 12:25.25 | ``Erik | DX^: that's probably outdated, the libgcv approach is favored now... check out g-dxf, g-stl, g-egg ... |
| 13:28.05 | starseeker | IIRC, there is some open source code that might help with the Collada side of things... |
| 13:28.56 | starseeker | http://brlcad.svn.sourceforge.net/viewvc/brlcad/brlcad/trunk/src/libgcv/NOTES?revision=37930 |
| 14:04.44 | CIA-55 | BRL-CAD: 03starseeker * r41478 10/brlcad/trunk/src/libgcv/NOTES: Add notes from SIGGRAPH about Blender and gamekit |
| 14:09.20 | CIA-55 | BRL-CAD: 03brlcad * r41479 10/brlcad/trunk/configure.ac: fcntl.h seems to be safe, possibly others too so make a section for headers that don't need to be tested for even if they aren't c89 |
| 14:12.30 | CIA-55 | BRL-CAD: 03brlcad * r41480 10/brlcad/trunk/include/raytrace.h: |
| 14:12.32 | CIA-55 | BRL-CAD: rt_g structure was using int for debug information making the structure size |
| 14:12.32 | CIA-55 | BRL-CAD: variable and making the debug flags declarations potentially not match the |
| 14:12.32 | CIA-55 | BRL-CAD: variable they are compared against. make both debug vars (debug and NMG_debug) |
| 14:12.32 | CIA-55 | BRL-CAD: be uint32_t instead of int. |
| 14:13.03 | starseeker | brlcad: should we revert the tolerance changes until we get it sorted out? |
| 14:15.54 | CIA-55 | BRL-CAD: 03brlcad * r41481 10/brlcad/trunk/src/util/ (25 files): quiet LOTS of verbose compilation warnings for various issues including shadow vars, return from non-void, unused params, unused vars, floating point comparisons, missing headers, and signedness matching |
| 14:26.01 | brlcad | starseeker: I was running some tests to verify, and waiting on one more set to verify repeatability |
| 14:26.08 | starseeker | k |
| 14:26.11 | brlcad | first pass shows 4 additional failures with r41463 |
| 14:26.17 | starseeker | ow |
| 14:26.45 | brlcad | actually that's a good thing |
| 14:27.02 | brlcad | magic numbers like that are terrible to maintain |
| 14:27.13 | starseeker | true |
| 14:27.57 | brlcad | should know within the hour |
| 15:14.58 | brlcad | gamekit is akin to writing the pro/e plugin |
| 15:15.14 | brlcad | doable, but it'd belong in src/external |
| 15:15.52 | brlcad | (gamekit also isn't new -- been around for many years) |
| 15:20.04 | starseeker | brlcad: I'm not suggesting to use gamekit whole - I was thinking extract their blender file parsing code and roll into libgcv for blender-g |
| 15:25.33 | CIA-55 | BRL-CAD: 03indianlarry * r41482 10/brlcad/trunk/src/librt/primitives/brep/brep_debug.cpp: |
| 15:25.33 | CIA-55 | BRL-CAD: Added BREP knot plotting routing to 'brep' command for debugging. Also modified |
| 15:25.33 | CIA-55 | BRL-CAD: some of the 'brep' command logging to build a string and return to 'mged' |
| 15:25.33 | CIA-55 | BRL-CAD: through vls string(problems with 'mged' when dumping large amounts of blather to |
| 15:25.33 | CIA-55 | BRL-CAD: stderr) |
| 15:34.47 | CIA-55 | BRL-CAD: 03indianlarry * r41483 10/brlcad/trunk/ (include/brep.h src/librt/primitives/brep/brep.cpp): Try to iterate to a solution within BREP_INTERSECTION_ROOT_EPSILON, if cannot get to that resolution check result and accept if within BREP_INTERSECTION_ROOT_SETTLE. |
| 15:38.05 | brlcad | starseeker: ahh |
| 15:49.46 | ``Erik | any news on the tolerance issue? |
| 15:54.29 | brlcad | yeah, not within the hour |
| 16:05.29 | brlcad | feels compelled to run the conversion script on a much larger sample set... |
| 16:05.42 | brlcad | but with a shorter timeout.. |
| 16:07.46 | ``Erik | has a brutal ugly model that can be hit with it, many large bots with 6 other large bots subtracted type stuff |
| 16:08.20 | CIA-55 | BRL-CAD: 03indianlarry * r41484 10/brlcad/trunk/src/ (4 files in 2 dirs): Added DB5_MINORTYPE_BRLCAD_BREP 'brep' type hooks to type_table[] and 'db get_type' related functions. |
| 18:19.31 | CIA-55 | BRL-CAD: 03indianlarry * r41485 10/brlcad/trunk/ (include/opennurbs_ext.h src/librt/opennurbs_ext.cpp): (log message trimmed) |
| 18:19.32 | CIA-55 | BRL-CAD: Made some changes to our surface subdivision routines. Now the first step in our |
| 18:19.32 | CIA-55 | BRL-CAD: surface subdivision is to divide on the surface knots |
| 18:19.32 | CIA-55 | BRL-CAD: (subdivideSurfaceByKnots()). The idea here is that major surface directional |
| 18:19.32 | CIA-55 | BRL-CAD: changes take place at the knots and that the surface behavior between adjacent |
| 18:19.32 | CIA-55 | BRL-CAD: knots is fairly well behaved. After subdividing at knots we further divide using |
| 18:19.33 | CIA-55 | BRL-CAD: flatness criteria. Also loosened surface flatness criteria BREP_SURFACE_FLATNESS |
| 21:48.02 | *** join/#brlcad DX^ (~DX@c-71-59-50-121.hsd1.ga.comcast.net) |
| 21:52.39 | *** join/#brlcad Ralith (~ralith@d142-058-092-003.wireless.sfu.ca) |
| 22:41.34 | *** join/#brlcad Ralith (~ralith@d142-058-092-003.wireless.sfu.ca) |
| 23:13.19 | *** join/#brlcad alex_joni (~alex_joni@emc/board-of-directors/alexjoni) |
| 23:25.05 | *** join/#brlcad DX^ (~DX@c-71-59-50-121.hsd1.ga.comcast.net) |
| 23:25.12 | DX^ | Hello. |
| 23:29.51 | DX^ | Is there a quick way I can compile a single file and its dependencies? |
| 23:30.02 | DX^ | I just want to compile, say, g-xxx_facets.c and its dependencies |
| 23:44.07 | ``Erik | with the autoconf stuff, you can do "make depends" in a directory to try to build the minimal dependancy set... I don't think g-xxx_facets can be compiled (but g-stl or g-egg can, and might be better examples) |
| 23:45.38 | DX^ | I looked at the code |
| 23:45.44 | DX^ | Would something prevent its compilation? |
| 23:48.02 | ``Erik | oh, my bad it does compile heh |
| 23:49.16 | ``Erik | but it still does stuff by hand that we've moved into a library *shrug* |
| 23:53.22 | DX^ | Which library? I saw that someone had said something |
| 23:53.29 | DX^ | but I reconnected and IRC closed my screen |
| 23:54.04 | ``Erik | libgcv |
| 23:56.11 | DX^ | Ok, I'll take a look at that then |
| 23:58.55 | ``Erik | g-egg and g-stl are very simple exporters that use gcv |
| 23:59.39 | DX^ | I'll take a look at that |
| 23:59.44 | DX^ | I want to be able to export to COLLADA |