| 00:06.43 | CIA-23 | BRL-CAD: 03Stattrav 07http://brlcad.org * r4153 10/wiki/User:Stattrav/GSoC2012_log: Updation of the logs. Web API is live. |
| 01:16.42 | *** join/#brlcad archivist (~archivist@host81-149-189-98.in-addr.btopenworld.com) |
| 02:17.15 | CIA-23 | BRL-CAD: 03Al Da Best 07http://brlcad.org * r4154 10/wiki/User:Al_Da_Best/devlog: Update for 10th July |
| 02:38.19 | crdueck | hello, hopefully someone who's been using the openNURBS interface can help me here. I want to evaluate the tangent at the start and end points of a bezier curve. the function ON_BezierCurve::TangentAt seems to be what i want, but it takes a double as its arguement instead of a point. what does the double represent? distance from the beginning of the curve? how can i get the tangent at the end point of the curve? thanks |
| 02:51.59 | cristina | is it just happening to me or brlcad.org is not loading because it's down? |
| 03:04.50 | CIA-23 | BRL-CAD: 03cprecup * r51449 10/brlcad/trunk/src/libged/dag.cpp: Removed entries from the solids hash table whenever a object is discovered to be a region or a group. Switched to working with pointers for bu_hash_tbl structures. Freed memory for each allocation. |
| 05:04.29 | CIA-23 | BRL-CAD: 03crdueck * r51450 10/brlcad/trunk/src/librt/primitives/sketch/sketch_tess.cpp: added new sketch_tess.cpp file which will contain functions used to tesselate a sketch primitive. WIP |
| 05:05.48 | CIA-23 | BRL-CAD: 03crdueck * r51451 10/brlcad/trunk/src/librt/CMakeLists.txt: added sketch_tess.cpp to librt CMakeLists |
| 05:15.48 | CIA-23 | BRL-CAD: 03brlcad * r51452 10/brlcad/trunk/src/librt/primitives/sketch/sketch_tess.cpp: new files don't get copyrights into the past unless their contents are derivatives or copies. they begin now. |
| 05:27.30 | CIA-23 | BRL-CAD: 03crdueck * r51453 10/brlcad/trunk/src/librt/Makefile.am: added sketch_tess.cpp to librt/Makefile.am |
| 05:36.19 | CIA-23 | BRL-CAD: 03crdueck * r51454 10/brlcad/trunk/src/librt/primitives/sketch/sketch_tess.cpp: change biarc() to use ON_BezierCurve instead of bezier_seg and rt_sketch_internal |
| 06:14.39 | *** join/#brlcad stas (~stas@188.24.49.125) |
| 09:23.47 | *** join/#brlcad mik_ (~mik@atommuell.mum.jku.at) |
| 09:36.18 | andrei_ | I tuned the unit test a bit. I made just one function. If it's ok the rest will be finished rather soon. Here is the current version : http://slexy.org/view/s2oDKF06Zg |
| 09:38.47 | andrei_ | The 4th parameter of pkg_permserver is errlog, I shouldn't " test " errlog ? Is the structure better ? ( tried to reduce code duplication, might have more ideas ). I redirected stderr to /dev/null because I considered it irrelevant for the purpose of the test. is it portable or shouldn't I redirect it at all ? |
| 12:01.24 | *** join/#brlcad anuragmurty (~anurag@14.139.128.11) |
| 12:16.47 | CIA-23 | BRL-CAD: 03phoenixyjll * r51455 10/brlcad/trunk/src/librt/primitives/hf/hf_brep.cpp: Initialize tmp_internal. |
| 12:40.08 | *** join/#brlcad yiyus (1242712427@server1.bouncer4you.de) |
| 12:55.58 | CIA-23 | BRL-CAD: 03phoenixyjll * r51456 10/brlcad/trunk/src/librt/primitives/hf/hf_brep.cpp: Put tmp_internal to the stack instead of using dynamic memory allocation. |
| 13:32.08 | *** join/#brlcad Al_Da_Best (Al_Da_Best@5e0e150d.bb.sky.com) |
| 13:34.21 | *** part/#brlcad anuragmurty (~anurag@14.139.128.11) |
| 13:46.51 | CIA-23 | BRL-CAD: 03phoenixyjll * r51457 10/brlcad/trunk/src/librt/primitives/brep/brep.cpp: This file contains several different approaches of ray tracing. Some functions are not currently used, so mark them to make things clear. |
| 14:24.43 | CIA-23 | BRL-CAD: 03Phoenix 07http://brlcad.org * r4155 10/wiki/User:Phoenix/GSoc2012/Reports: /* Week 8 */ |
| 14:34.45 | *** join/#brlcad mik_ (~mik@atommuell.mum.jku.at) |
| 15:05.36 | *** join/#brlcad brlcad (~sean@BZ.BZFLAG.BZ) |
| 15:05.50 | *** join/#brlcad n_reed (~molto_cre@BZ.BZFLAG.BZ) |
| 16:16.28 | *** join/#brlcad yiyus (1242712427@je.je.je) |
| 16:23.39 | *** join/#brlcad phoenixyjll (9308c434@gateway/web/freenode/ip.147.8.196.52) |
| 16:52.06 | CIA-23 | BRL-CAD: 03cprecup * r51458 10/brlcad/trunk/src/libged/dag.cpp: Use connection pins for each link between two shapes |
| 18:17.24 | CIA-23 | BRL-CAD: 03starseeker * r51459 10/brlcad/trunk/src/other/step/doc/CMakeLists.txt: Don't use absolte path for install directory. |
| 18:29.17 | CIA-23 | BRL-CAD: 03starseeker * r51460 10/brlcad/trunk/CMakeLists.txt: Tweak package naming a bit. |
| 19:45.11 | *** join/#brlcad cristina (~quassel@188.24.49.125) |
| 19:46.38 | *** join/#brlcad andrei_ (~andrei@188.25.27.225) |
| 19:48.06 | andrei_ | brlcad, the machine running the 1 - 2048 script on 8mb file just got toasted. I ll have to recover the data, I believe the script is at approximatively 1200 |
| 19:50.12 | andrei_ | I can resume it but testing will be a bit delayed... |
| 19:52.08 | *** join/#brlcad starseeker (~starseeke@BZ.BZFLAG.BZ) |
| 19:53.31 | kanzure | starseeker: hi |
| 19:53.34 | kanzure | http://diyhpl.us/wiki/cad/method |
| 19:53.42 | kanzure | i'm tired of not making progress on these problems |
| 20:02.27 | starseeker | kanzure: howdy |
| 20:04.42 | kanzure | hihi |
| 20:05.20 | starseeker | did I miss something? |
| 20:05.30 | starseeker | one of our gsoc students is going to look into this... |
| 20:06.24 | starseeker | kanzure: did SISL not prove suitable for your particular problem? |
| 20:06.29 | kanzure | yeah i've been reading that thread, but i don't see why you would choose the triangle intersection approach over any other lossy approach if your goal is lossyness |
| 20:06.40 | kanzure | SISL was unreadable |
| 20:07.03 | starseeker | we're not going with the triangle intersection - I'll be bounding box subdivision based |
| 20:07.19 | starseeker | we already have that logic for our raytracer, so we can build on it for this problem |
| 20:07.38 | starseeker | s/I'll/it'll |
| 20:08.40 | kanzure | the solidworks paper that you guys were eyeballing (section 6.1) uses triangle intersections to approximate the intersection curve in a marching bounding box method |
| 20:09.20 | starseeker | kanzure: with our bounding box approach, we subdivide until "near-flatness" criteria are satisfied |
| 20:10.37 | starseeker | kanzure: what I'm hoping is once we have good "initial guesses" from those intersections, we'll be able to iterate to exact point solutions in some fashion (sort of like we do for the raytrace, but maybe a different formulation of the problem) |
| 20:11.32 | kanzure | which paper most closely mentions this approach? |
| 20:11.48 | starseeker | what, using the bounding boxes? |
| 20:12.07 | kanzure | the whole approach for calculating your intersection curves, curve merging, etc. |
| 20:12.24 | kanzure | i know what a bounding box is :p |
| 20:12.59 | starseeker | the TVCG09.pdf paper is probably the closest so far, but whether we'll end up doing something different once we have the localized regions is open |
| 20:13.28 | starseeker | kanzure: I take it you've tried implementing the TVCG09 approach? |
| 20:14.00 | kanzure | the methods that i'm aware of start with things like "decompose the domain of the intersection curve into a bivariate algebraic planar projection", or "use bounding boxes and then approximate the intersection with four triangles" (like that GPU paper), or "compute an unevaluated determinant that represents the intersection curve" etc |
| 20:14.23 | kanzure | i've read the TVCG09 approach, and that's the one with triangle approximation of intersection curves |
| 20:15.11 | starseeker | we'll start with the bounding boxes, but what we do when we get them isn't clear yet |
| 20:16.28 | kanzure | but that's the important part.. |
| 20:17.41 | starseeker | using flatness criteria to drive the bounding boxes, planer intersection calculations as an approximation may actually be quite good - the linear segments could then be fitted with a curve |
| 20:18.27 | starseeker | if that doesn't get us within tolerance, the line segment intersections may be suitable initial guesses for an iterative solution to arrive at exact points - that'll take some exploration |
| 20:20.15 | starseeker | if we need that level of refinement, the first place I'd look would be our existing raytracing solver, and the techniques it uses |
| 20:20.38 | kanzure | so brlcad is okay with doing approximations of the intersection curves (say with polylines based on some max-depth bounding box hierarchy)? |
| 20:21.30 | kanzure | i was assuming the goal would be some algebraic solution that would produce exact curves w/o floating point math in between? |
| 20:22.19 | starseeker | my initial thought is we may use polylines as something to fit a NURBS curve to... |
| 20:23.04 | starseeker | kanzure: if I understand the problem correctly, NURBS curves are actually insufficiently general to describe exactly all of the intersection curves that may result from two arbitrary NURBS surfaces |
| 20:24.13 | starseeker | http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.146.3590 |
| 20:25.44 | starseeker | so if we can't be exact, we have to approximate the intersection "closely enough" |
| 20:27.16 | kanzure | one of the papers i was reading was talking about how ACIS also has degenerate tolerances in their intersection curves |
| 20:27.27 | kanzure | and if you do the right set of operations a number of times you can cause huge glitches that shouldn't occur |
| 20:27.43 | kanzure | but due to drift from one intersection attempt to the next, things get out of whack |
| 20:28.23 | starseeker | nods - we'll have to think about how to manage such things |
| 20:32.33 | starseeker | kanzure: did they happen to say what the operation(s) were that caused the trouble? |
| 20:33.10 | kanzure | no i mean just some boolean operations in general |
| 20:33.31 | kanzure | it's an interesting statement |
| 20:33.37 | kanzure | i guess i've never tried to break ACIS before :) |
| 20:34.09 | starseeker | nods - that's part of it too. ACIS obviously has solved the problem "well enough" to be usable for many real-world applications |
| 20:34.31 | starseeker | it may not handle some difficult situations well, but that's not a reason to throw out the baby with the bath water |
| 20:36.07 | kanzure | sure it is.. by carefully considering options and how to tackle the problem, we can solve it in one swoop instead of multiple attempts |
| 20:42.20 | starseeker | kanzure: OK, what do you suggest? |
| 20:43.15 | starseeker | recalls you tried re-implementing the esolid approach at one point? |
| 20:43.35 | kanzure | yes but let's not mention that :p |
| 20:43.47 | starseeker | sees getting the subdivision step working as the "first stage" |
| 20:43.49 | kanzure | are you claiming that approximations of the intersections are actually okay for, e.g., high tolerance projects? |
| 20:44.00 | kanzure | maybe you're right and approximations are totally acceptable |
| 20:44.07 | kanzure | i haven't considered this particular issue either way yet |
| 20:44.26 | kanzure | i just naively assumed that approximations would be unacceptable |
| 20:44.47 | starseeker | kanzure: if that "Watertight Trimmed NURBS" paper is right, it's actually impossible to get exact curve solutions in general without being willing to distort the NURBS surfaces in the neighborhood of the intersection |
| 20:45.58 | kanzure | but what about from a mechanical engineering perspective: approximations of shape intersections leads to bad modeling results, doesn't it? |
| 20:46.47 | starseeker | my guess is that would depend on the exact definition of "approximations" and "bad results" |
| 20:48.25 | starseeker | kanzure: do any existing CAD systems claim to solve intersections exactly? (Sounds like ACIS at least doesn't, from what you were saying) |
| 20:50.24 | kanzure | some academic papers claim to solve intersections in an exact/algebraic manner |
| 20:50.33 | kanzure | caveat: please don't take my word as an exhaustive survey :P |
| 20:50.50 | starseeker | usually with a considerable (as in prohibitive) performance hit though |
| 20:51.01 | kanzure | i was surprised to learn that solidworks might be doing a polyhedral intersection method |
| 20:51.10 | starseeker | (see esolid) |
| 20:51.23 | kanzure | it's very annoying that it's not just written somewhere that "solidworks does x, acis does y, parasolid does z" |
| 20:51.42 | starseeker | <snort> they have no incentive to publish their solutions, as a rule |
| 20:52.42 | starseeker | dunno if that's what they're doing - they're "supporting research", but that may or may not end up getting incorporated |
| 20:55.08 | starseeker | kanzure: here's a question - given N points shared by two surfaces of degree D, with the proviso that for each region between knots there are at least Ns sampled points, if a curve of degree C is fit to those points, what's the maximum delta that can occur between the surfaces and the curve? |
| 20:59.32 | kanzure | i thought the curve was on the surface (where else do the sampled points come from)? |
| 21:00.13 | starseeker | if we can calculate a series of points that are shared by two surfaces, that would be our starting point set |
| 21:01.11 | kanzure | so why would there be a delta |
| 21:01.52 | starseeker | if we're fitting the curve to the points, by definition there are points on the surfaces that we are not constraining the curve to intersect |
| 21:02.19 | starseeker | because we cannot calculate all intersection points between the two surfaces - that's infinitne |
| 21:07.44 | starseeker | so the question is - for points on the fitted curve that are not known to map exactly to intersection points, how far can they be from the theoretical "correct" intersection point they *should* be describing? |
| 21:09.54 | kanzure | starseeker: what about cases where there are known solutions, like suppose a sphere intersecting a surface - we know the intersection curve is a circle, which does have a basic NURBS curve model... |
| 21:11.26 | starseeker | kanzure: ok - what happens if we take a "dense" sample of intersection points, based on bounding box intersections where the bounding boxes bound "near flat" subsets of the surfaces |
| 21:11.36 | starseeker | then fit that with a NURBS curve. |
| 21:11.45 | starseeker | how close to a circle would that fit be? |
| 21:12.34 | kanzure | no idea |
| 21:13.02 | starseeker | if the fit is any good, I would expect it to be very very close to circular |
| 21:13.50 | starseeker | and if it proves useful, we might even be able to add some checks for "special cases" where we can spot exact shapes |
| 21:14.52 | starseeker | but we can't assume "easy" shape intersections, most of the time |
| 21:16.14 | starseeker | (bty - that curve is only a circle if that surface is planar) |
| 21:16.47 | starseeker | or a few other special cases |
| 21:38.39 | kanzure | well, there are other near-circular objects like ovals and obliques that can fit that scenario |
| 21:43.31 | kanzure | <@jblake> arguably, you should be aiming for within the square of the tolerance or some such smaller limit in order to avoid magnification of errors from the interactions between approximated surfaces |
| 22:57.27 | CIA-23 | BRL-CAD: 03n_reed * r51461 10/brlcad/trunk/src/other/step/ (4 files in 3 dirs): combine multiple definitions of LISTempty |
| 23:20.30 | *** join/#brlcad xth1 (~thiago@187-79-8-116.user.veloxzone.com.br) |