| 00:50.22 | starseeker | kanzure: do you have a write-up of what problems you ran into? |
| 00:52.50 | kanzure | no. off the top of my head, though, the problems were things like (1) not having enough domain expertise to come up with a full spectrum of tests to either confirm that my functions were working or to guide which results various intersection functions needed to produce, (2) not having a correctness proof of the algorithms i was using, (3) lack of domain knowledge for knowing how to sufficiently break up the problem (instead of having giant functions ... |
| 00:52.57 | kanzure | ... floating around everywhere, which was highly distressing to my inner source code enthusiast), and (4) not knowing other people with this domain expertise willing to do code reviews or be a place for me to send hate mail to for advice/support. |
| 00:53.56 | kanzure | one of my attempts was a verbatim rewrite of esolid into python.. which was a bad idea. |
| 00:54.44 | kanzure | it was a bad idea because, while i was able to successfully compile esolid, i did not have a reasonable idea of testing either version, and the intersection functions are thousands of lines of code each (for whatever reason), which means lots of coding before testing each function.. |
| 00:55.22 | kanzure | it occurs to me that you have recently practiced the art of maintaining two separate branches of a large, complex project in this space, so you're probably aware of the kinds of difficulties i am talking about, heh |
| 00:55.36 | kanzure | (SCL seems much larger than esolid's source code, though.) |
| 00:56.22 | starseeker | kanzure: my approach in that situation would be to first identify the conceptual pieces of the task, rather than going for the source code (which is a no-go for us in this case anyway, as I mentioned earlier) |
| 00:56.40 | starseeker | the biggie is of course surface/surface intersection, but that's not the only piece |
| 00:57.01 | kanzure | yeah, i understand the licensing issues. however, i would be happy to write competing implementations all day long once i can write a working one at all. |
| 00:57.20 | starseeker | there's also assembling the intersection curves into new bounding loops, figuring out how to assemble new breps from the new trimmed surfaces, etc. |
| 00:57.39 | kanzure | right, and things like singularities and how to deal with those |
| 00:57.43 | starseeker | nods |
| 00:57.58 | starseeker | mathematically, the intersection cases can be characterized |
| 00:58.08 | starseeker | hunts for old email from last year's gsoc... |
| 00:58.25 | kanzure | here's some of the python barf i wrote |
| 00:58.26 | kanzure | http://diyhpl.us/cgit/lolcad/tree/nurbs.py |
| 00:58.41 | kanzure | here's some of the esolid stuff i converted.. http://diyhpl.us/cgit/lolcad/tree/lolcad.py |
| 00:58.51 | kanzure | please note there's an awful STEP generator in there too |
| 00:59.01 | starseeker | heh |
| 00:59.03 | kanzure | it was because i didn't want to bother with EXPRESS at the time.. i know it's not a good excuse. |
| 00:59.10 | kanzure | forgive me :( |
| 00:59.50 | kanzure | oh wait, that's just the STEP crap. that's not what i wanted to show you. |
| 00:59.59 | kanzure | http://diyhpl.us/cgit/lolcad/tree/esolid/esolid.py |
| 01:01.09 | kanzure | as you can imagine, writing 4000+ lines of code without testing is really painful and not healthy and confusing |
| 01:01.21 | starseeker | can imagine |
| 01:02.50 | kanzure | i agree that breaking up the problem is a good approach |
| 01:03.22 | starseeker | here was my initial thinking on the assembly problem after Wu got basic surface/surface intersection working: http://www.mail-archive.com/brlcad-devel@lists.sourceforge.net/msg02110.html |
| 01:03.30 | kanzure | but i don't want to break up the problem, then spend 3 months writing a curve-curve intersector, only to have to throw it away in 5 months because i broke up the problem wrong and didn't think of the right architecture. |
| 01:03.42 | kanzure | oh brlcad has surface/surface working? |
| 01:04.26 | starseeker | kanzure: see http://brlcad.org/wiki/User:Phoenix/GSoc2012/Reports |
| 01:04.32 | starseeker | (last two pictures) |
| 01:04.44 | starseeker | three rather |
| 01:04.52 | kanzure | oh wonderful |
| 01:05.24 | kanzure | i'll read through that email thread and the wiki page. would that give me a clear summary of current status? |
| 01:05.45 | starseeker | should, yeah |
| 01:06.55 | starseeker | I don't think the current ssi stuff is exposed via command as yet, and cases like two surfaces intersecting along a surface rather than a curve (or, for that matter, a point instead of a curve) still need to be handled |
| 01:07.48 | kanzure | so non-parallel non-point surface-surface intersection is working? |
| 01:08.05 | starseeker | in the test cases tried so far |
| 01:09.44 | kanzure | that makes me really happy. maybe i will dig around in some papers for how others have chosen to solve those remaining edge cases. |
| 01:10.23 | starseeker | kanzure: it shouldn't be too hard for you to hook up the ssi function to a test command if you want to try it out |
| 01:10.46 | kanzure | i'm not sure i've ever understood what it conceptually means for two surfaces to intersect on a surface |
| 01:10.55 | kanzure | it makes sense for fusing two models together but for subtraction operations i'm really not sure |
| 01:11.19 | kanzure | for example, imagine two cubes touching each other on one side precisely |
| 01:11.26 | starseeker | yeah, that's one of the more tricky situations |
| 01:11.35 | kanzure | what happens in non-brep situations in that case? |
| 01:12.10 | kanzure | maybe the answer is "nothing happens". |
| 01:12.11 | starseeker | from the ray tracing perspective, I think it uses some internal ordering to pick one or the other to be "inside" |
| 01:12.33 | starseeker | it may also flag that as an overlap if the ray goes right down the plane of intersection |
| 01:12.42 | starseeker | not sure that facetiziation does with it |
| 01:13.07 | kanzure | when you subtract one object from the other as a user you usually carry on with only one of the objects.. and subtracting a surface doesn't have any explicit meaning so "nothing happens" might make sense. |
| 01:14.05 | starseeker | or "shave a planar thickness equal to minimum tolerance in the model" might also make sense |
| 01:15.19 | kanzure | would it? if that was the case then as a user i would expect the minimum tolerance to always be used when calculating intersections of any type. |
| 01:15.26 | starseeker | kanzure: for code, check out src/libbrep/opennurbs_ext.cpp around line 3221 |
| 01:16.39 | starseeker | kanzure: it depends - another expectation would be that subtraction of the one cube from the other guarantees that a ray passing through the subtracted cube's volume never hit anything solid, and reporting "solid" along the subtracted face would violate that expectation |
| 01:17.27 | kanzure | silly asymptotes |
| 01:17.33 | starseeker | it's indeed a tricky subject - I suspect most systems have to make *some* decision from among the options and then just try to be consistent about it |
| 01:18.49 | kanzure | for what it's worth, i don't have any particular use case that demands one choice to be made over the other, but consistency would be nice. |
| 01:19.23 | starseeker | nods |
| 01:19.40 | starseeker | our take on that I think was "worry about it after we've got the basics in place" |
| 01:23.55 | kanzure | it turns out i don't have a recent checkout.. will take a while (and i sorta refuse to use viewvc because it's viewvc). |
| 01:24.03 | starseeker | heh |
| 01:25.41 | kanzure | are there breps/nurbs defined for all the primitives? |
| 01:26.46 | kanzure | "Implemented degree reduction to Bezier curves to simplify the representation of the dsp top surface. But still a long way to go. As I tested it with terra.g, the result made me very upset. There were great differences in the middle of the curves. For dsp with smaller xcnt & ycnt, the result was quite accurate. But it's big xcnt & ycnt that counts, because this is introduced to shorten the raytrace time of dsp with large maps." |
| 01:27.16 | Notify | 03BRL-CAD Wiki:Starseeker * 4982 /wiki/Google_Summer_of_Code/Project_Ideas: /* Geometry Processing Projects */ libsvn db backend only makes sense (maybe) much farther into the project |
| 01:27.59 | starseeker | kanzure: dsp is a problem - technically a brep can be produced, but it's a nightmare to raytrace |
| 01:28.20 | starseeker | kanzure: we may do better with a fitted surface, which will come out of some other work in progress |
| 01:29.18 | starseeker | kanzure: dsps aren't as important as other functionality (IMHO, at least) - we can revisit them later |
| 01:29.51 | kanzure | sure. i was amused by his comment about being upset. |
| 01:29.56 | starseeker | kanzure: of course, if you feel like implementing practical degree reduction that would be awesome :-) |
| 01:31.04 | kanzure | ah i see you used the "Performing efficient NURBS modeling operations on the GPU" subdivision/triangle approximation approach for surface intersections |
| 01:32.35 | kanzure | "Fit the points into NURBS curves using polyline approximation." |
| 01:35.09 | kanzure | when is the conversion to brep made in the lifecycle of a model in brlcad? |
| 01:35.11 | Notify | 03BRL-CAD Wiki:Starseeker * 4983 /wiki/Google_Summer_of_Code/Project_Ideas: /* Mentors */ I don't know who-all is a mentor this year yet, but unless the admins have heard otherwise I don't think these folks are this year... |
| 01:36.35 | kanzure | oh i see you are planning a brep command |
| 01:37.18 | starseeker | kanzure: we already have one - that's how we convert implicits to breps :-) |
| 01:37.45 | kanzure | it seems like it makes more sense to keep everything implicit in brlcad as long as possible, and then dump to brep at the end of a work session? |
| 01:40.26 | starseeker | right |
| 01:43.44 | kanzure | i am curious why he was raytracing brep models. almost all computers these days have a version of opengl that comes with nurbs rendering in glut or something. |
| 01:43.50 | kanzure | *support a version of opengl |
| 01:44.20 | starseeker | eh? raytracing NURBS has been one of BRL-CAD's primary efforts for the last several years |
| 01:44.49 | starseeker | the built-in glut tessellation almost never holds up for real-world complex geometry |
| 01:44.57 | kanzure | oh really? i thought it would be much more performant. |
| 01:45.14 | kanzure | i have only a little experience with the glut tessellation, i never stress tested it.. |
| 01:46.10 | starseeker | shakes his head - we're just now getting our own tessellation capabilities online, which are much better at handling the sorts of geometry we're likely to see, and even then for raytracing planar triangles are typically an approximation |
| 01:46.39 | starseeker | not to mention tessellating models can get you all sorts of nasty overlap issues that weren't there to begin with |
| 01:47.55 | kanzure | what are proprietary cad vendors doing for rendering? |
| 01:48.54 | starseeker | presumably they have their own tessellation codes |
| 01:49.00 | kanzure | i don't even know what opencascade is doing. i sort of assumed they are using glut tessellation but i never checked.. |
| 01:49.07 | starseeker | doubts it |
| 01:49.14 | kanzure | they are probably using 10 things :) |
| 01:49.33 | starseeker | dunno - their codebase is another one that is useless to us due to licensing issues |
| 01:49.53 | kanzure | i know you guys have expressed a disinterest in even looking at their source code, but man, it's not in good shape |
| 01:50.12 | starseeker | well, that's another reason then :-) |
| 01:53.04 | kanzure | still checking out.. |
| 01:53.32 | kanzure | oh good "The intersection curve (green) of a sph (red) and an ehy (blue)." |
| 02:02.00 | kanzure | is there an official git-svn bridge for brlcad? |
| 02:02.09 | kanzure | .. or an unofficial maintained one? |
| 02:02.56 | kanzure | it's not easy to tell if http://brlcad.org/brlcad.git is the same as crit.brlcad.org/brlcad.git or not |
| 02:07.29 | kanzure | r53942 has a really long commit message. what's going on there? |
| 02:08.24 | kanzure | http://brlcad.svn.sourceforge.net/viewvc/brlcad?view=revision&revision=53942 |
| 02:13.17 | kanzure | "re-re-revert to r54338 before I started causing damage. apparently two different versions of opennurbs came out one month after the other, both labeled as v5.0 and the latter removing substantial functionality (3 functions) that we utilize." wtf |
| 02:27.36 | starseeker | openNURBS removed some features we were using, that they deemed unnecessary for openNURBS's primary purpose - enabling applications to read/write 3dm files |
| 02:53.58 | kanzure | why is the if/else not indented in the example in HACKING under the "The One True Brace Style" section? |
| 09:05.21 | *** join/#brlcad merzo (~merzo@user-94-45-58-138-1.skif.com.ua) |
| 09:31.38 | *** join/#brlcad sbongir (~chatzilla@59.160.74.254) |
| 09:38.56 | *** join/#brlcad filipt (~filip@89.205.42.139) |
| 10:07.26 | filipt | anyone here? I need some help with compiling the brl-cad source... |
| 10:56.43 | starseeker | likes Google's banner today |
| 10:56.57 | starseeker | bet Ed would too |
| 11:17.21 | Notify | 03BRL-CAD Wiki:Starseeker * 4984 /wiki/Google_Summer_of_Code/Project_Ideas: /* Project Categories */ Make a stab at shuffling the grouping/ordering based on project priorities |
| 11:36.16 | brlcad | yeah, good ol euler |
| 11:41.16 | Notify | 03BRL-CAD:bob1961 * 55161 brlcad/trunk/src/tclscripts/archer/ShaderEdit.tcl: Added support for the stack shader to Archer's comb edit panel. |
| 12:38.42 | brlcad | kanzure: crit.brlcad.org == brlcad.org now, they are one in the same |
| 12:39.50 | brlcad | r53942 was someone learning how to use svn commit for the first time (and making a mistake) |
| 12:41.03 | brlcad | filipt: you need to ask your question and wait around for an answer, not ask if anyone is here |
| 12:41.20 | brlcad | ~ask |
| 12:41.20 | ibot | Questions in the channel should be specific, informative, complete, concise, and on-topic. Don't ask if you can ask a question first. Don't ask if a person is there; just ask what you intended to ask them. Better questions more frequently yield better answers. We are all here voluntarily or against our will. |
| 13:05.54 | *** join/#brlcad anirban (cb6ef7dd@gateway/web/freenode/ip.203.110.247.221) |
| 14:15.59 | *** join/#brlcad nsomani (839ffce9@gateway/web/freenode/ip.131.159.252.233) |
| 14:17.07 | brlcad | hi nsomani and anirban |
| 14:19.49 | nsomani | hi |
| 14:21.10 | brlcad | does shape primitives using point clouds mean representing shapes with point clouds or reverse modeling shapes from point clouds? |
| 14:22.16 | nsomani | modeling shapes from point clouds |
| 14:22.38 | nsomani | rather, detecting shapes from point clouds data |
| 14:22.40 | brlcad | what representation are you working towards? |
| 14:22.56 | nsomani | i'm looking at NURBS right now |
| 14:23.10 | brlcad | excellent.. that's a tough problem |
| 14:23.39 | nsomani | yes, it is! I realized that once I got into it. but i think there's good potential for work in this direction |
| 14:24.09 | brlcad | starseeker has been working on a variation of that problem for the better part of a year |
| 14:25.09 | nsomani | okay. yeah, i'm not sure how much of this can be done within the GSoC timeframe. |
| 14:25.35 | brlcad | how much do you know about the underlying research in that area? |
| 14:25.50 | brlcad | read any of the research papers? |
| 14:26.28 | nsomani | i've read the NURBS book by piegl and a few papers, but i wouldn't call myself an expert. |
| 14:26.54 | brlcad | I think it's doable within GSoC timeframe, but it's certainly got some significant risks |
| 14:27.13 | brlcad | would have to be rather specific on the goals and result, what problem(s) get implemented |
| 14:27.17 | brlcad | what data is worked with, etc |
| 14:28.05 | nsomani | perhaps a discussion with starseeker would be beneficial for this |
| 14:28.08 | brlcad | iirc, he even used a piece of code from PCL to help solve the point mapping |
| 14:29.04 | nsomani | yes, i think this approach would be useful for the PCL community as well. they already have some work on NURBS. this could be a good extension |
| 14:29.42 | brlcad | our primary goal was the conversion of polygonal models to NURBS models |
| 14:30.51 | brlcad | the basic algorithm oversimplified was to chop up the mesh into patches, then for each patch project the vertices into a fitted nurbs surface (pcl solver helping with that), and then stitching the surfaces together at their boundaries |
| 14:32.00 | nsomani | i see. |
| 14:32.59 | nsomani | if the aim is to use point cloud data directly and not meshes, there needs to be a some sort of a pre-processing step which converts the clouds to meshes. |
| 14:33.02 | brlcad | which is basically a variation of locally grouping/segmenting 3d points together so we can get "good" surfaces |
| 14:33.32 | brlcad | if the starting point is point cloud, definitely -- you'd need to infer some boundary |
| 14:33.59 | brlcad | especially if it's noisy data or misaligned, etc |
| 14:35.11 | nsomani | true. there are a bunch of these local grouping/segmentation algorithms in PCL. and some of them are very time efficient too |
| 14:35.46 | nsomani | so, handling noisy data should not be a problem if this pre-processing step is involved. |
| 14:36.28 | brlcad | I guess we're mostly interested with the data after it's already gone through that processing since quality is indeterminate at that point |
| 14:37.01 | brlcad | at least once there's a mesh, we can talk about error, deviation, and fitting confidence for a corresponding nurbs surface |
| 14:37.49 | brlcad | with points, I think the most you can say is deviation |
| 14:40.11 | nsomani | yes. so, i guess all this combined could be a good project for GSoC |
| 14:40.57 | nsomani | feasibility depends on how much progress has already been done in BRL-CAD on this. |
| 14:42.09 | brlcad | starseeker has a nice presentation that gives an overview of the issues and progress he's made to date |
| 14:43.35 | brlcad | gsoc could focus on solving those few remaining issues, defining some BRL-CAD and PCL API boundaries, and then making sure it's all packaged up properly (and working, obviously) |
| 14:44.34 | nsomani | starseeker: could you please share this presentation. it would be very helpful in defining the scope of this proposal. |
| 14:46.17 | nsomani | brlcad: yes, that seems interesting. |
| 14:48.15 | brlcad | nsomani: the code in question in a brl-cad checkout is src/libbrep/opennurbs_fit.* src/librt/test_nurbsfit.cpp src/librt/test_bot2nurbs.cpp |
| 14:48.20 | brlcad | ~cadsvn |
| 14:48.20 | ibot | To obtain BRL-CAD from Subversion: svn checkout https://brlcad.svn.sourceforge.net/svnroot/brlcad/brlcad/trunk brlcad |
| 14:49.10 | brlcad | "bot" is our nomenclature for a "bag of triangles", i.e., a triangle mesh |
| 14:49.35 | anirban | brlcad: sorry was away from keyboard at that point of time.......went through your discussion with nsomani |
| 14:50.33 | nsomani | brlcad: okay. i'll take a look at it. |
| 14:51.00 | anirban | yes the approach of chopping the meshes into patches and using pcl seems interesting |
| 14:56.08 | brlcad | I could see a proposal to 1) implement a PCL function that takes a set/patch of filtered surface points and provides a corresponding NURBS surface, 2) integrate that call/functionality into BRL-CAD for getting a set of surfaces given a set of mesh patches, and 3) stitching it all together via an integrated brl-cad libged command |
| 14:56.39 | brlcad | or some variation thereof, so PCL gets a new nugget and we get that functionality hooked into a useful CAD purpose |
| 14:59.42 | starseeker | would prefer not to tie into PCL if it can be avoided - that's a rather large dependency to introduce. For point cloud to wrapped mesh I would expect libqhull to be the key piece |
| 15:00.12 | brlcad | not so much to tie into them, but to make it an extractable function like you did in opennurbs_fit |
| 15:00.33 | brlcad | thinking of it like a sub-library that doesn't tie into either sides types |
| 15:00.50 | brlcad | so it can be mutually useful |
| 15:01.06 | brlcad | then from there, if they want to customize or if we need to, we can |
| 15:01.07 | starseeker | nods - I'd have to look again, but I kinda thought they were using qhull for the heavy lifting there - so qhull may already be the "sub-library" |
| 15:01.36 | brlcad | we'd still just be concerned with the point after we have a mesh |
| 15:02.07 | brlcad | which is effectively the same as an API call that worked on filtered points |
| 15:03.03 | brlcad | i.e., what'd you'd get *after* running through qhull or whatever other filtering |
| 15:03.17 | Notify | 03BRL-CAD Wiki:Phoenix * 4985 /wiki/User:Phoenix: /* Experience */ |
| 15:04.00 | Notify | 03BRL-CAD Wiki:Phoenix * 4986 /wiki/User:Phoenix: /* Interest */ |
| 15:04.17 | Notify | 03BRL-CAD Wiki:Phoenix * 4987 /wiki/User:Phoenix: /* Who I am */ |
| 15:04.34 | starseeker | uh... doens't PCL already have a functoin that takes in points and returns a NURBS surface? http://docs.pointclouds.org/trunk/classpcl_1_1nurbs_1_1_nurbs_fitter.html |
| 15:04.46 | nsomani | yes. it does |
| 15:05.58 | brlcad | nsomani: how does your work relate to that? |
| 15:06.31 | brlcad | starseeker: ever tested how their method compares to yours? |
| 15:06.52 | starseeker | shakes his head |
| 15:06.54 | nsomani | i think the idea about primitives got lost somewhere here. i was trying to focus on fitting shape primitives to these points. |
| 15:07.49 | nsomani | part (1) in the idea already exists. |
| 15:07.51 | starseeker | I wouldn't expect anything different - the boundary edges are where the issues seem to be, and I don't think they are addressed by Morwald's original work |
| 15:08.34 | starseeker | nsomani: you're thinking something more along these lines? http://efpisoft.sourceforge.net/ |
| 15:09.32 | nsomani | starseeker: yes. |
| 15:09.34 | starseeker | (unfortunately we can't use the code from that project, since it's GPL) |
| 15:09.53 | nsomani | starseeker: but i'm looking for point cloud data as the starting point, and not meshes |
| 15:10.26 | Notify | 03BRL-CAD Wiki:Phoenix * 4988 /wiki/User:Phoenix: /* GSoC 2012 Project */ |
| 15:10.55 | Notify | 03BRL-CAD Wiki:Phoenix * 4989 /wiki/User:Phoenix: /* GSoC 2013 Project */ |
| 15:11.05 | starseeker | wouldn't that just involve fitting the point cloud with a mesh and proceeding from there? |
| 15:11.27 | brlcad | a joint PCL project that would be more interesting, a stand-alone mit-licensed high-performance generic kd-tree library (ideally with gpgpu and coherency leveraged where available) |
| 15:11.37 | Notify | 03BRL-CAD Wiki:Phoenix * 4990 /wiki/User:Phoenix/GSoc2013/Proposal: Created page with "Coming soon... :)" |
| 15:11.42 | brlcad | s/more // |
| 15:12.08 | brlcad | nsomani: when you say primitive, what do you mean? |
| 15:12.18 | brlcad | I think he's talking about shape detection |
| 15:12.31 | brlcad | "this is a torus" |
| 15:12.39 | starseeker | brlcad: starting with this? http://code.google.com/p/kdtree/ or a scratch/ground-up design? |
| 15:13.00 | brlcad | starseeker: whatever |
| 15:13.30 | starseeker | brlcad: yeah, that's what I got too - recognizing surfaces that are well fitted by simple quadratic/quartic surfaces |
| 15:13.36 | nsomani | the idea is similar to efpisoft. I'm looking to decompose a point cloud of an object(say) into a set of simpler shapes(planes, cylinders, etc. ) to represent it. |
| 15:14.21 | nsomani | i'm looking into nurbs representations right now which seems interesting. |
| 15:14.29 | brlcad | starting with google's would be fine, but it'd be hard to outperform it without restructing the data types and processing flow |
| 15:14.57 | brlcad | nsomani: well you could certainly craft a "hybrid" proposal with elements of that and other work we need |
| 15:18.04 | brlcad | deconstructing an input data (point cloud or mesh) into one of our primitives would be an interesting feature and is something we've even discussed recently |
| 15:18.48 | brlcad | it's hard to describe a tangible user benefit other than data reduction, though ... would require some thinking about how the feature is exposed |
| 15:19.34 | nsomani | okay. I'll give this more thought and come up with a proposal. |
| 15:20.53 | nsomani | in my experiments, i use this for representing object CAD models and then recognizing them in point cloud data. |
| 15:22.11 | nsomani | this also has applications in shape retrieval and shape-based database indexing. |
| 15:45.08 | brlcad | nsomani: yes, I get that except without other "filtering" methods, the image processing domain long showed that you need far more than a shape to do useful shape recognition on real data |
| 15:48.42 | *** join/#brlcad gdh (~quassel@pool-71-177-13-144.lsanca.dsl-w.verizon.net) |
| 15:57.29 | Notify | 03BRL-CAD:bob1961 * 55162 brlcad/trunk/src/tclscripts/archer/Archer.tcl: This fixes a bug (i.e. the various object panels no longer appear when an object is selected) that shows up when a database is opened when in "Rt Image View" mode. |
| 16:05.05 | nsomani | brlcad: true. i've done a lot of work on shape matching and recognition, based on this decomposition. A stable and robust shape decomposition is crucial to that work. |
| 16:05.37 | *** join/#brlcad merzo (~merzo@user-94-45-58-138-1.skif.com.ua) |
| 16:05.39 | nsomani | This is why I'm focusing more on getting a good shape decomposition algorithm working. |
| 16:11.31 | *** join/#brlcad Ch3ck (~Ch3ck@41.205.13.86) |
| 16:57.50 | *** join/#brlcad Ch3ck (~Ch3ck@41.205.13.125) |
| 17:26.50 | *** join/#brlcad hsrai (~hsrai@202.164.53.116) |
| 17:28.45 | hsrai | Is there any plan to have DWG (AutoCAD format) import / export? Rather is there any need / demand for this? |
| 17:48.30 | *** join/#brlcad ncsaba (~ncsaba@p54983C23.dip.t-dialin.net) |
| 19:00.34 | Ch3ck | hi |
| 19:00.37 | Ch3ck | hsrai |
| 19:00.47 | Ch3ck | i wish to work with brlcad too..?? |
| 19:00.50 | Ch3ck | u der? |
| 21:20.55 | Notify | 03BRL-CAD:carlmoore * 55163 brlcad/trunk/src/conv/comgeom/cvt.c: add comment about versions 1, 4 |
| 22:15.26 | ``Erik | http://divshot.github.io/geo-bootstrap/ I need to add this bootstrap theme to my webpage O.o |