| 00:53.27 | brlcad | starseeker: yep, that came out earlier last year |
| 00:54.04 | brlcad | rather s/came out/was noticed/ |
| 01:57.56 | starseeker | ah |
| 03:55.41 | *** join/#brlcad KimK (~Kim__@wsip-184-176-200-171.ks.ks.cox.net) |
| 08:19.20 | *** join/#brlcad luca79 (~luca@net-37-116-125-167.cust.dsl.vodafone.it) |
| 08:42.45 | *** join/#brlcad merzo (~merzo@user-94-45-58-138-1.skif.com.ua) |
| 10:51.32 | Posterdati | hi |
| 10:51.43 | Posterdati | brlcad: did you implement taper in brlcad? |
| 12:55.27 | *** join/#brlcad luca79 (~luca@net-37-116-125-167.cust.dsl.vodafone.it) |
| 12:57.21 | brlcad | Posterdati: if we had, you'd think I would have mentioned that really early in yesterday's discussion, no? :) |
| 12:59.48 | brlcad | certainly useful for nurbs editing, but we haven't started in that area yet |
| 13:08.39 | Posterdati | ok |
| 13:12.06 | Posterdati | it is strange |
| 13:12.27 | Posterdati | they implemented Opennurbs to ease 3d data interchange |
| 13:13.09 | Posterdati | but honestly speaking is quite not simple nor useful to implement and use |
| 13:30.03 | Posterdati | I've to use rhino sdk |
| 13:39.06 | Posterdati | grrr |
| 13:48.19 | Posterdati | and this is a problem, because I don't develop under windows |
| 14:10.26 | brlcad | Posterdati: how is providing tapering helpful for 3d data interchange? :) |
| 14:10.46 | Posterdati | no, I was talking in general |
| 14:10.49 | Posterdati | anyway |
| 14:10.52 | Posterdati | it seems that |
| 14:11.03 | Posterdati | one could use ON_MorphControl |
| 14:11.16 | Posterdati | then call ON_Geometry::Morph |
| 14:11.32 | brlcad | I guess my experience is nearly opposite |
| 14:11.34 | brlcad | as a library, it's actually one of the most cleanly implemented and well documented APIs I've seen |
| 14:11.50 | Posterdati | well documented? |
| 14:11.54 | Posterdati | where? |
| 14:12.14 | brlcad | the headers pretty extensively document the API |
| 14:12.44 | brlcad | sure there are things they don't provide that I wish they did at times, but by large it does exactly what it says it will do |
| 14:13.46 | Posterdati | ok |
| 14:13.50 | Posterdati | for example |
| 14:14.15 | Posterdati | is explained how to use the ON_MorphControl class? |
| 14:14.23 | brlcad | beside qt, what's something better you've seen? |
| 14:14.44 | brlcad | (and open source ideally) |
| 14:14.49 | Posterdati | common lisp |
| 14:17.46 | brlcad | eh, that's like saying english is a better written book than lord of the rings |
| 14:19.39 | brlcad | I love lisp, but that's not exactly usefully comparable |
| 14:20.03 | Posterdati | why not? |
| 14:20.06 | brlcad | really love some of the self-documenting setups like elisp where you can probe on the spot |
| 14:20.24 | Posterdati | anyway |
| 14:20.31 | brlcad | really? |
| 14:20.45 | Posterdati | it seems that I can use ON_MorphControl at least |
| 14:20.57 | brlcad | assuming they implement it |
| 14:21.06 | brlcad | that still goes down an editing route |
| 14:21.26 | brlcad | and they explicitly say they do not support editing, so maybe or maybe not |
| 14:21.35 | ``Erik | brlcad: bumped postgresql to 9.2, didn't bother pre-announcing since it looks like I'm the only user at the moment |
| 14:22.07 | brlcad | I would assume it's provided as a means to import/convert morphcontrol entities if they're persistable |
| 14:22.16 | Posterdati | but again there aren't examples |
| 14:22.17 | brlcad | if they are, then you're probably in luck |
| 14:22.50 | Posterdati | apering is a deformation operation, thus requiring a ON_SpaceMorph object |
| 14:22.50 | Posterdati | that defines the morphing, followed by a call to ON_Geometry::Morph() to do |
| 14:22.50 | Posterdati | the actual morphing. |
| 14:22.50 | Posterdati | <PROTECTED> |
| 14:22.50 | Posterdati | The openNURBS toolkit does not provided a pre-defined taper space morph. The |
| 14:22.51 | Posterdati | Rhino SDK does |
| 14:23.20 | Posterdati | I don't need a predefined taper function |
| 14:23.33 | Posterdati | I need something I could apply the taper matrix |
| 14:23.38 | ``Erik | I vagually recall someone talking about doing a common lisp wrapper (like cffi or something) on opennurbs in #lisp a bit back, was that you, posterdati? O.o |
| 14:24.33 | brlcad | ``Erik: yeah, you're the lone wolf there thusfar |
| 14:24.34 | Posterdati | yes |
| 14:24.43 | Posterdati | but I've no time now |
| 14:26.45 | brlcad | ``Erik: any chance you could look at migrating named.conf? |
| 14:27.03 | brlcad | I think that spans a major bind version |
| 14:27.48 | brlcad | bzflag folks when up in arms when I pointed bz.bzflag.bz to crit because bind hadn't been migrated (and it's a secondary dns) |
| 14:34.17 | brlcad | 63.246.136.16 is old IP |
| 14:34.31 | brlcad | Posterdati: looks like you just might be in luck |
| 14:34.42 | ``Erik | yeh, dns is updated, I'm in the old thing |
| 14:35.11 | Posterdati | brlcad: why? |
| 14:35.17 | brlcad | Posterdati: ON_NurbsCage::Read() |
| 14:35.31 | Posterdati | ? |
| 14:35.43 | brlcad | that means they are persisted, written to file |
| 14:35.51 | Posterdati | yes |
| 14:36.02 | brlcad | so 3dm parsers need to be able to read and apply them for them to be meaningful |
| 14:36.10 | brlcad | which means Evaluate() probably works |
| 14:36.10 | Posterdati | may I cast an ONX_Model_Object to a ON_NurbsCage? |
| 14:37.10 | brlcad | why would you do that? |
| 14:37.13 | brlcad | I'd think you'd want to confirm it does something useful first, no? |
| 14:37.27 | brlcad | create one, apply it, see if it evaluates |
| 14:42.29 | Posterdati | ok |
| 14:43.41 | Notify | 03BRL-CAD Wiki:GeomModeler * 0 /wiki/User:GeomModeler: |
| 14:43.54 | Posterdati | it is useful |
| 14:44.22 | brlcad | you got it to work already? that was fast... |
| 14:44.34 | Posterdati | no I'm reading the .h file |
| 14:44.36 | Posterdati | so |
| 14:44.41 | Posterdati | if I did understand |
| 14:45.06 | Posterdati | a nurbs cage is a cage surrounding the object |
| 14:45.28 | brlcad | yeah, my really quick read indicated it takes a control box around the object, you can deform the cage and then Evaluate() and it'll deform the underlying geometry |
| 14:46.06 | brlcad | looking at the implementation, it looks like it's even set up to support arbitrary deformations, not just affine linear ones |
| 14:46.18 | brlcad | which is pretty awesome actually .. we may have to use that as well |
| 14:46.52 | Posterdati | good |
| 14:49.24 | Posterdati | so |
| 14:49.52 | Posterdati | have I to create a nurbs cage first using the object bounding box? |
| 14:54.43 | brlcad | I would just try to construct one manually for testing to understand it, but using the object's bounding box would be a logical starting point for production use |
| 15:06.10 | Posterdati | ok I did |
| 15:06.18 | Posterdati | now I could trasnform only the cage |
| 15:08.16 | Posterdati | let's see |
| 15:20.56 | Notify | 03BRL-CAD:n_reed * 54497 brlcad/trunk/src/tclscripts/lib/Ged.tcl: remove duplicate pane_scale_mode method body |
| 15:32.42 | Posterdati | ok |
| 15:33.03 | Posterdati | how it is supposed to use Transform and Evaluate for a ON_NurbsCage ??? |
| 15:37.59 | Notify | 03BRL-CAD:carlmoore * 54498 brlcad/trunk/src/libged/draw.c: fix spelling |
| 15:49.20 | Notify | 03BRL-CAD:indianlarry * 54499 (brlcad/trunk/src/other/poly2tri/AUTHORS =================================================================== and 11 others): Initial checkin of the 'poly2tri' C++ library for creating a constrained Delaunay triangulation (CDT) of a polygon using a sweep-line algorithm. This package will be used during the generation of facet meshes for BRL-CAD NURBS. This version of 'poly2tri' was |
| 15:49.22 | Notify | obtained from github at 'git://github.com/jhasse/poly2tri.git' and based of a google code project of the same name. The methodology implemented is based on the paper "Sweep-line algorithm for constrained Delaunay triangulation" by V. Domiter and and B. Zalik. This checkin is a snapshot of the initial repository code before being integrated into the BRL-CAD build system. |
| 15:53.26 | *** join/#brlcad dtidrow (~dtidrow@c-68-84-167-135.hsd1.mi.comcast.net) |
| 16:03.38 | *** join/#brlcad d_rossberg (~rossberg@66-118-151-70.static.sagonet.net) |
| 16:28.51 | Notify | 03BRL-CAD:d_rossberg * 54500 (brlcad/trunk/AUTHORS brlcad/trunk/src/libbu/semaphore.c): apply patch from Arjun Govindjee (http://www.google-melange.com/gci/task/view/google/gci2012/7999206) implement mutex locking for windows |
| 16:32.01 | Notify | 03BRL-CAD:d_rossberg * 54501 brlcad/trunk/src/libbu/semaphore.c: corrected test for failed mutex locking in Windows |
| 16:34.50 | d_rossberg | mutex locking on windows still needs some tests, but it's easier with the patch applied on the repository |
| 16:34.54 | d_rossberg | exit |
| 17:08.08 | Posterdati | :( |
| 17:17.12 | Notify | 03BRL-CAD:indianlarry * 54502 (brlcad/trunk/src/other/CMakeLists.txt brlcad/trunk/src/other/poly2tri/poly2tri/common/utils.h): Split 'utils' class into declaration and definition files utils.h and utils.cc. Also added cmake changes for integration into BRL-CAD build. |
| 19:07.36 | Notify | 03BRL-CAD:r_weiss * 54503 brlcad/trunk/src/libged/nirt.c: Fixed a bug in the mged nirt command when running on windows. Changed an array to variable length. When a large number of objects is displayed, the array length would be exceeded causing nirt to fail with a message that an object could not be found. |
| 20:06.16 | Notify | 03BRL-CAD:r_weiss * 54504 brlcad/trunk/src/libged/nirt.c: More updates to function ged_nirt. |
| 20:45.17 | Notify | 03BRL-CAD:r_weiss * 54505 brlcad/trunk/include/raytrace.h: Increased size of librt db hash table. Improves performance of some operations when the model has a large number of objects (ie > 40k). |
| 20:50.53 | brlcad | hm, slew of named tmp file errors |
| 21:45.27 | brlcad | fixed, apparently now need full file paths in the conf |
| 21:49.18 | ``Erik | yup, probably safer that way |
| 21:49.23 | ``Erik | you did the timr ones? |
| 21:50.53 | ``Erik | (the dir is git-ified, so'z you can git commit) |
| 22:22.06 | *** join/#brlcad PrezKennedy (~DarkCalf@173.231.40.98) |
| 22:46.09 | Notify | 03BRL-CAD:carlmoore * 54506 brlcad/trunk/src/util/bwrect.c: clarify error messages, and fix wrong argv member in one of them |
| 22:46.50 | Notify | 03BRL-CAD:carlmoore * 54507 brlcad/trunk/src/util/bwrect.c: oops, needed to refer to bwrect, not to pixrect |