| 00:31.58 | *** join/#brlcad Axman6 (n=Axman6@pdpc/supporter/student/Axman6) | |
| 01:09.05 | *** join/#brlcad BigAToo (n=BigAToo@pool-96-230-124-196.sbndin.btas.verizon.net) | |
| 01:59.10 | CIA-32 | BRL-CAD: 03indianlarry * r34816 10/brlcad/trunk/ (include/opennurbs_ext.h src/librt/primitives/brep/brep.cpp): added trim distance return to isTrimmed() for determining when hit crack |
| 02:28.28 | CIA-32 | BRL-CAD: 03ralith * r34817 10/rt^3/trunk/src/other/ogre/Samples/Media/ (428 files in 21 dirs): Added Ogre SVN (r8739, latest as of this commit) due to serious bugs in features needed by g3d in Ogre stable. Partial commit. |
| 03:10.49 | CIA-32 | BRL-CAD: 03ralith * r34818 10/rt^3/trunk/src/other/ogre/Samples/Lighting/ (21 files in 11 dirs): Added Ogre SVN (r8739, latest as of this commit) due to serious bugs in features needed by g3d in Ogre stable. Partial commit. |
| 03:11.56 | CIA-32 | BRL-CAD: 03ralith * r34819 10/rt^3/trunk/src/other/ogre/Samples/ (77 files in 37 dirs): Added Ogre SVN (r8739, latest as of this commit) due to serious bugs in features needed by g3d in Ogre stable. Partial commit. |
| 03:14.55 | CIA-32 | BRL-CAD: 03ralith * r34820 10/rt^3/trunk/src/other/ogre/Samples/ (95 files in 49 dirs): Added Ogre SVN (r8739, latest as of this commit) due to serious bugs in features needed by g3d in Ogre stable. Partial commit. |
| 03:16.12 | CIA-32 | BRL-CAD: 03ralith * r34821 10/rt^3/trunk/src/other/ogre/Samples/ (86 files in 41 dirs): Added Ogre SVN (r8739, latest as of this commit) due to serious bugs in features needed by g3d in Ogre stable. Partial commit. |
| 03:16.35 | CIA-32 | BRL-CAD: 03ralith * r34822 10/rt^3/trunk/src/other/ogre/Scripts/ (.keepme m4/ m4/cppunit.m4 m4/sdl.m4 null.sh remove_debug.sh): Added Ogre SVN (r8739, latest as of this commit) due to serious bugs in features needed by g3d in Ogre stable. Partial commit. |
| 03:20.45 | CIA-32 | BRL-CAD: 03ralith * r34823 10/rt^3/trunk/src/other/ogre/Tests/ (97 files in 29 dirs): Added Ogre SVN (r8739, latest as of this commit) due to serious bugs in features needed by g3d in Ogre stable. Partial commit. |
| 03:58.51 | Ralith | wonders just how long a svn commit can take |
| 04:12.46 | Ralith | okay, it's locked up now. |
| 04:12.57 | louipc | wee! |
| 04:13.19 | Ralith | kill -9s and tries again |
| 04:13.34 | louipc | I feel your pain man |
| 04:14.23 | louipc | maybe I can help. let me know if there's anything |
| 04:14.50 | Ralith | thanks, I'll do that |
| 04:15.00 | Ralith | pretty sure it's just a matter of slogging through the heirarchy though. |
| 04:15.25 | Ralith | (and stomping the occasional bug) |
| 04:31.47 | Ralith | another lockup >:| |
| 05:15.32 | *** join/#brlcad madant (n=cb7baf0f@bz.bzflag.bz) | |
| 06:44.09 | *** join/#brlcad stevegt_1 (n=stevegt@c-24-130-122-25.hsd1.ca.comcast.net) | |
| 06:45.52 | stevegt_1 | wonders if there's any clean way to generate 2-D toolpaths to laser cut panels from a BRL-CAD model |
| 06:46.25 | stevegt_1 | wonders if anyone else is awake right now |
| 06:46.46 | stevegt_1 | probably have to poke in here tomorrow and ask again |
| 06:47.52 | Ralith | I'm here |
| 06:47.56 | Ralith | it's theoretically possible |
| 06:48.02 | Ralith | jonored wrote the code to do most of the work |
| 06:48.17 | Ralith | but he hasn't been around for a while and never published it |
| 06:48.50 | Ralith | the raytracer gives you enough info to do it |
| 06:49.24 | stevegt_1 | I just spend the weekend digging through g-xxx.c et al -- looks doable, but I'd hate to make a fool of myself if it's already been done |
| 06:49.35 | Ralith | it hasn't. |
| 06:49.41 | Ralith | it's nontrivial though |
| 06:50.11 | Ralith | let us know if you get it working |
| 06:50.20 | Ralith | it'd be a very useful for lots of things |
| 06:50.29 | stevegt_1 | maybe i'm thinking of it all wrong -- I'm seeing it as a 2-D dxf generation problem... you think I need to be looking at the raytracing code instead? |
| 06:51.04 | Ralith | well if you want to just convert a sketch to a dxf that's not hard |
| 06:51.12 | Ralith | or at least I imagine it's not, I don't know the relevant code |
| 06:51.29 | Ralith | but going from a 3D model to 2D toolpaths is significantly more involved. |
| 06:53.30 | stevegt_1 | well, what i'd want to be able to do is put together a model, mark the material attributes for the parts that are going to be laser-cut, then, in something like 'g-epilog', filter out just those parts, and generate a dxf or epilog (PCL) file for each one |
| 06:54.22 | stevegt_1 | i'm not sure that would solve the general g-code generation problem, except for driving CNC routers and lasers |
| 06:55.06 | Ralith | that's most of it |
| 06:55.15 | Ralith | and once you've solved that, any further uses could easily build on your work |
| 06:55.26 | stevegt_1 | huh |
| 06:58.14 | stevegt_1 | do you know if there's already a piece of code buried somewhere in the tree that i could call or copy which would help me rotate a part so it's normal to a reference plane, then get the resulting 2-D vertices? I don't know if I'm making any sense or not... for instance, I started looking at the "flatten" stuff in the NMG libs, not even sure if that's related |
| 06:59.06 | stevegt_1 | s/rotate a part so it's normal/rotate a part so the largest face is normal/ |
| 06:59.09 | stevegt_1 | or something like that |
| 07:01.07 | stevegt_1 | i mean, if we first assume that the shape is cut from a flat panel (extruded from a sketch, probably, but not always), then that means that there will always be exactly two flat faces which are identical, and we can just pick one |
| 07:01.24 | Ralith | stevegt_1: ...BRL-CAD isn't mesh-based. |
| 07:01.25 | Ralith | it's CSG. |
| 07:01.36 | Ralith | there's no such thing as "the corresponding vertices" |
| 07:01.47 | stevegt_1 | right, which means i'm probably confusing myself by looking at the g-xxx code |
| 07:01.53 | Ralith | everything is in terms of volumes |
| 07:02.02 | Ralith | extracting 2d toolpaths is nontrivial. |
| 07:02.19 | stevegt_1 | which is why you're mentioning the raytracer? |
| 07:02.48 | Ralith | that's how you work with the evaluated form of a BRL-CAD model. |
| 07:02.54 | Ralith | through raytracing. |
| 07:06.32 | stevegt_1 | looking at how the g-xxx triangulation code does it's job |
| 07:06.32 | Ralith | you don't want to do tesselation. |
| 07:06.32 | Ralith | that's a waste of information |
| 07:06.32 | Ralith | considering that gcode can do true arcs |
| 07:06.55 | stevegt_1 | that's what i was afraid you'd say |
| 07:07.06 | stevegt_1 | or glad, actually |
| 07:07.15 | stevegt_1 | 'cause i was ignoring it so far ;-) |
| 07:07.21 | stevegt_1 | the tesellation code, i mean |
| 07:08.02 | stevegt_1 | was thinking i didn't need it, but now i'm wondering how it does its job -- going to look |
| 07:13.55 | stevegt_1 | suddenly recalls that it's g-xxx_facets which does tesselation, which he doesn't need, while g-xxx does not do tesselation anyway -- it just iterates through the results of rt_dirbuild |
| 07:14.31 | stevegt_1 | and printf's what it finds |
| 07:17.15 | *** join/#brlcad _clock_ (n=_sushi_@77-58-151-159.dclient.hispeed.ch) | |
| 07:21.59 | stevegt_1 | looking at g2asc as well now... i'm confused -- if I have the record in hand that i got from the db, then i have its parameters in record.s.s_values -- why do i need to raytrace? to account for booleans? |
| 07:22.13 | stevegt_1 | must be that |
| 07:25.04 | stevegt_1 | i'm going to take a guess and say that the reason why 2-D toolpath generation has been considered to be a hard problem is that it's been generally accepted that we needed to invoke the raytracer to execute boolean operations first |
| 07:25.38 | Ralith | it's not HARD |
| 07:25.41 | Ralith | just hasn't been done yet |
| 07:25.58 | Ralith | there's lots of other stuff to do. |
| 07:26.11 | stevegt_1 | okay, deferred ;-) |
| 07:27.24 | Ralith | and yeah, the only way to evaluate booleans is to raytrace |
| 07:27.41 | Ralith | only data you can get without raytracing is the primitives |
| 07:31.11 | stevegt_1 | i'm thinking of gershenfeld's cad.py -- he used python's numpy 3-D matrix operations to do the booleans in very little code; part of my brain must have been assuming i'd do that instead of calling the brl-cad raytracer |
| 07:31.20 | Ralith | ... |
| 07:31.58 | Ralith | the raytracer's ability to evaluate booleans is one of BRL-CAD's major high points |
| 07:32.00 | stevegt_1 | yeah, whacky -- i should look at the raytracer first |
| 07:32.08 | Ralith | you'd basically be using BRL-CAD for nothing but its fileformat |
| 07:32.19 | Ralith | doing booleans well is hard. |
| 07:32.28 | Ralith | the raytracer will give you just about perfect precision. |
| 07:32.32 | Ralith | and reliably, too. |
| 07:34.18 | stevegt_1 | Any suggestion where I should start to get my head around it? I've been going back and forth through the PDF tutorials, including the Application_Develeopment slideshow -- am I missing some swath of developer docs somewhere else? |
| 07:35.02 | Ralith | what kind of docs do you want |
| 07:36.13 | stevegt_1 | I probably don't know enough yet to ask. ;-) I'll have to go through that slideshow again. I was ignoring the raytracing before, was just llooking at the DB access bits. |
| 07:44.14 | stevegt_1 | hmm. src/rt/viewarea.c looks like a real good place to start as well |
| 07:45.43 | stevegt_1 | actually all the view*.c stuff |
| 07:48.50 | stevegt_1 | expects to sit down someplace quiet tomorrow and grok view*.c -- "only" 11,568 lines ;-) |
| 07:49.16 | stevegt_1 | Ralith: thank you, very much -- I think you got me on the right track |
| 07:49.20 | Ralith | cool |
| 08:11.54 | *** join/#brlcad ChanServ (ChanServ@services.) | |
| 08:11.54 | *** mode/#brlcad [+o ChanServ] by irc.freenode.net | |
| 09:09.48 | *** join/#brlcad Elrohir (n=kvirc@p5B14C62F.dip.t-dialin.net) | |
| 09:50.56 | *** join/#brlcad CIA-32 (n=CIA@208.69.182.149) | |
| 10:55.08 | CIA-32 | BRL-CAD: 03ralith * r34824 10/rt^3/trunk/src/other/ogre/Tools/3dsmaxExport/ (116 files in 26 dirs): Added Ogre SVN (r8739, latest as of this commit) due to serious bugs in features needed by g3d in Ogre stable. Partial commit. |
| 10:55.17 | CIA-32 | BRL-CAD: 03ralith * r34825 10/rt^3/trunk/src/other/ogre/Tools/BitmapFontBuilderTool/ (. main.cpp): Added Ogre SVN (r8739, latest as of this commit) due to serious bugs in features needed by g3d in Ogre stable. Partial commit. |
| 10:56.03 | CIA-32 | BRL-CAD: 03ralith * r34826 10/rt^3/trunk/src/other/ogre/Tools/BlenderExport/ (24 files in 4 dirs): Added Ogre SVN (r8739, latest as of this commit) due to serious bugs in features needed by g3d in Ogre stable. Partial commit. |
| 10:56.07 | CIA-32 | BRL-CAD: 03ralith * r34827 10/rt^3/trunk/src/other/ogre/Tools/CMakeLists.txt: Added Ogre SVN (r8739, latest as of this commit) due to serious bugs in features needed by g3d in Ogre stable. Partial commit. |
| 10:56.24 | CIA-32 | BRL-CAD: 03ralith * r34828 10/rt^3/trunk/src/other/ogre/Tools/CommandLineTools_Readme.txt: Added Ogre SVN (r8739, latest as of this commit) due to serious bugs in features needed by g3d in Ogre stable. Partial commit. |
| 10:57.25 | CIA-32 | BRL-CAD: 03ralith * r34829 10/rt^3/trunk/src/other/ogre/Tools/Common/ (11 files in 5 dirs): Added Ogre SVN (r8739, latest as of this commit) due to serious bugs in features needed by g3d in Ogre stable. Partial commit. |
| 10:57.52 | CIA-32 | BRL-CAD: 03ralith * r34830 10/rt^3/trunk/src/other/ogre/Tools/LightwaveConverter/ (28 files in 4 dirs): Added Ogre SVN (r8739, latest as of this commit) due to serious bugs in features needed by g3d in Ogre stable. Partial commit. |
| 11:36.12 | CIA-32 | BRL-CAD: 03ralith * r34831 10/rt^3/trunk/src/other/ogre/Tools/MaterialEditor/ (178 files in 18 dirs): Added Ogre SVN (r8739, latest as of this commit) due to serious bugs in features needed by g3d in Ogre stable. Partial commit. |
| 11:37.32 | CIA-32 | BRL-CAD: 03ralith * r34832 10/rt^3/trunk/src/other/ogre/Tools/MayaExport/ (35 files in 6 dirs): Added Ogre SVN (r8739, latest as of this commit) due to serious bugs in features needed by g3d in Ogre stable. Partial commit. |
| 11:37.41 | CIA-32 | BRL-CAD: 03ralith * r34833 10/rt^3/trunk/src/other/ogre/Tools/MeshUpgrader/ (7 files in 3 dirs): Added Ogre SVN (r8739, latest as of this commit) due to serious bugs in features needed by g3d in Ogre stable. Partial commit. |
| 11:38.08 | CIA-32 | BRL-CAD: 03ralith * r34834 10/rt^3/trunk/src/other/ogre/Tools/MilkshapeExport/ (28 files in 9 dirs): Added Ogre SVN (r8739, latest as of this commit) due to serious bugs in features needed by g3d in Ogre stable. Partial commit. |
| 11:38.32 | CIA-32 | BRL-CAD: 03ralith * r34835 10/rt^3/trunk/src/other/ogre/Tools/VRMLConverter/ (26 files in 7 dirs): Added Ogre SVN (r8739, latest as of this commit) due to serious bugs in features needed by g3d in Ogre stable. Partial commit. |
| 11:38.36 | *** join/#brlcad louipc (n=louipc@69-196-134-147.dsl.teksavvy.com) | |
| 11:38.44 | CIA-32 | BRL-CAD: 03ralith * r34836 10/rt^3/trunk/src/other/ogre/Tools/Wings3DExporter/ (11 files): Added Ogre SVN (r8739, latest as of this commit) due to serious bugs in features needed by g3d in Ogre stable. Partial commit. |
| 11:41.03 | CIA-32 | BRL-CAD: 03ralith * r34837 10/rt^3/trunk/src/other/ogre/Tools/XMLConverter/ (22 files in 5 dirs): Added Ogre SVN (r8739, latest as of this commit) due to serious bugs in features needed by g3d in Ogre stable. Partial commit. |
| 11:42.24 | CIA-32 | BRL-CAD: 03ralith * r34838 10/rt^3/trunk/src/other/ogre/Tools/XSIExport/ (32 files in 6 dirs): Added Ogre SVN (r8739, latest as of this commit) due to serious bugs in features needed by g3d in Ogre stable. Partial commit. |
| 11:42.34 | CIA-32 | BRL-CAD: 03ralith * r34839 10/rt^3/trunk/src/other/ogre/Tools/dotXSIConverter/ (. include/ include/Exporter.h src/ src/Exporter.cpp): Added Ogre SVN (r8739, latest as of this commit) due to serious bugs in features needed by g3d in Ogre stable. Partial commit. |
| 11:42.44 | CIA-32 | BRL-CAD: 03ralith * r34840 10/rt^3/trunk/src/other/ogre/Tools/rcapsdump/ (. scripts/ src/ src/main.cpp): Added Ogre SVN (r8739, latest as of this commit) due to serious bugs in features needed by g3d in Ogre stable. Partial commit. |
| 11:42.57 | Ralith | :D |
| 11:42.58 | Ralith | done! |
| 11:45.12 | CIA-32 | BRL-CAD: 03Ralith 07http://brlcad.org * r1501 10/wiki/User:Ralith: Log for 2009-06-21 |
| 13:07.25 | *** join/#brlcad BigAToo (n=BigAToo@64.74.225.82) | |
| 13:19.33 | *** join/#brlcad mafm (n=mafm@165.Red-81-35-69.dynamicIP.rima-tde.net) | |
| 13:36.28 | brlcad | Ralith: hehe, well congrats on that .. ouch |
| 13:36.57 | brlcad | next time you have something that big, maybe could tar it up for one of the other devs to commit :) |
| 13:37.24 | brlcad | couldn't hurt to put in an sf.net ticket if only to have them check it out too just to make sure it's not something on their end |
| 13:38.09 | brlcad | stevegt_1: there is an overview on the website that explains the rt view*.c interface |
| 13:39.19 | brlcad | http://brlcad.org/w/images/3/3d/Application_Development.pdf (found under http://brlcad.org/wiki/Developing_applications ) |
| 13:39.48 | brlcad | stevegt_1: basically it amounts to about a half-dozen callbacks that you define and register |
| 13:40.45 | brlcad | ahh, reading more of the backlog, I see you found that pdf already |
| 13:42.38 | brlcad | so probably just asking questions in here is your best bet if you don't quickly make sense of the code -- each of those view*.c files is for a separate application like rt, rtarea, rtweight, rtcheck, etc .. |
| 13:43.01 | *** join/#brlcad Elrohir (n=kvirc@p5B14C62F.dip.t-dialin.net) | |
| 13:43.55 | brlcad | those half-dozen or so callbacks are all that is needed to define the entire application as the rt user interface is exactly the same across all of them for the front-end (argument processing, shooting a grid of primary rays, aggregating results, running in parallel, etc) |
| 13:56.28 | brlcad | case local folks don't see the e-mail or if others are close by and want to join up, we're looking to have dinner at Tidewater tonight in Havre de Grace, Maryland around 6pm |
| 13:56.48 | starseeker | ah, thanks :-) |
| 13:56.54 | brlcad | GMTA |
| 13:57.18 | brlcad | ~seen madant |
| 13:57.21 | ibot | madant <n=cb7baf0f@bz.bzflag.bz> was last seen on IRC in channel #brlcad, 1d 5h 16m 20s ago, saying: '~sleep'. |
| 14:30.56 | CIA-32 | BRL-CAD: 03Tbrowder 07http://brlcad.org * r1502 10/wiki/BRL-CAD%27s_core_C%2B%2B_interface: /* Application Domain */ |
| 14:31.48 | CIA-32 | BRL-CAD: 03Tbrowder 07http://brlcad.org * r1503 10/wiki/BRL-CAD%27s_core_C%2B%2B_interface: /* The interface should be self-contained */ |
| 15:34.08 | CIA-32 | BRL-CAD: 03bob1961 * r34841 10/brlcad/trunk/src/libged/expand.c: Modify ged_expand to return only database entries that match the pattern(s). |
| 15:37.55 | brlcad | woot! |
| 15:38.05 | brlcad | go go gadget tom |
| 15:42.29 | *** join/#brlcad jdoliner (n=jdoliner@c-68-51-75-169.hsd1.il.comcast.net) | |
| 15:43.36 | jdoliner | hey guys can someone give me a hand with ON_SimpleArrays? |
| 15:44.00 | jdoliner | particularly for somereason when I try to use them I get compile errors that there's no match found for [] operators |
| 15:44.49 | jdoliner | ON_SimpleArray<ON_Line> segments; |
| 15:45.48 | jdoliner | and then |
| 15:45.48 | jdoliner | ON_Line segment = segments[j]; |
| 15:45.52 | jdoliner | creates an error |
| 16:40.50 | CIA-32 | BRL-CAD: 03jdoliner * r34842 10/brlcad/trunk/src/proc-db/ (brepintersect.cpp brepintersect.h): Added function TriangleMeshIntersect which intersects a triangle with a mesh and returns as a polyline their intersection curve |
| 17:01.40 | brlcad | jdoliner: it returns a reference |
| 17:02.01 | brlcad | type have a type error |
| 17:03.35 | *** join/#brlcad samrose (n=samrose@c-24-11-214-181.hsd1.mi.comcast.net) | |
| 17:03.51 | jdoliner | so segments is of type ON_SimpleArray<ON_Line>&? |
| 17:04.04 | jdoliner | then how to I get at its contents? |
| 17:04.37 | brlcad | no, see the header, it returns a T& |
| 17:04.46 | brlcad | so needs to be an ON_Line& |
| 17:05.15 | brlcad | assuming the type problem isn't on the j |
| 17:05.16 | jdoliner | okay that makes sense then |
| 17:06.46 | jdoliner | k cool I get it now |
| 17:26.32 | CIA-32 | BRL-CAD: 03jdoliner * r34843 10/brlcad/trunk/src/proc-db/brepintersect.cpp: Modified TriangleMeshIntersect to be MeshMeshIntersect, now just directly intersects two meshes and returns an array of Polylines for their intersection |
| 17:49.06 | CIA-32 | BRL-CAD: 03bob1961 * r34844 10/brlcad/trunk/src/tclscripts/archer/ (33 files in 4 dirs): Added the first installment of the undo functionality (i.e. only handling mods to existing geometry) to Archer. More to follow for create, destroy and rename. |
| 17:50.00 | brlcad | wonders how much of the hackery that involved.. |
| 17:57.35 | *** join/#brlcad _sushi_ (n=_sushi_@80-219-42-101.dclient.hispeed.ch) | |
| 18:23.30 | CIA-32 | BRL-CAD: 03Jdoliner 07http://brlcad.org * r1504 10/wiki/User:Jdoliner: |
| 18:53.53 | *** join/#brlcad samrose (n=samrose@c-24-11-214-181.hsd1.mi.comcast.net) | |
| 19:45.15 | brlcad | jdoliner: curious what your current goal/milestone is |
| 19:46.00 | jdoliner | my current goal is to finish mesh on mesh intersections |
| 19:46.13 | brlcad | ON_Mesh objects are all polygonal, yes? |
| 19:46.18 | jdoliner | yes |
| 19:46.52 | brlcad | they are all untrimmed? |
| 19:47.08 | brlcad | or do they allow/require trimming evaluation? |
| 19:47.16 | jdoliner | I believe that they are untrimmed |
| 19:47.30 | jdoliner | at least nowhere in the definition do I say any mention of trimming |
| 19:47.38 | brlcad | okay cool -- there is a problem with one of your intersection routines if you allow trims |
| 19:48.34 | jdoliner | I see, actually I guess this is a good time for me to learn some things about trims |
| 19:48.50 | jdoliner | so meshes don't have trims which works well |
| 19:49.18 | jdoliner | so the way I see it, is that I do an intersection |
| 19:49.20 | brlcad | one thing that will be very interesting to test then once you have mesh on mesh intersections working is having an nmg->ON_Mesh conversion to perform the booleans using your routines instead of the (extensively complex) NMG library |
| 19:50.07 | jdoliner | yeah definitely |
| 19:50.26 | jdoliner | so then after the intersection I get back the polyline |
| 19:51.09 | jdoliner | and then I basically need to just make a new mesh where I trim off the parts outside of the polyline |
| 19:52.41 | jdoliner | but when I do stuff with nurbs, which support trimming curves I can just put them in as trimming curves |
| 19:52.57 | brlcad | right |
| 19:52.58 | jdoliner | and then my intersection algorithms need to take into account the trimming curves |
| 19:53.13 | brlcad | plus you'll have to deal with more generalized ON_Brep objects, not just ON_Mesh objects |
| 19:53.16 | brlcad | in order to get nurbs |
| 19:53.20 | jdoliner | yes |
| 19:53.36 | jdoliner | what does ON do with the trimming curves |
| 19:53.45 | jdoliner | are they just used in rendering |
| 19:54.06 | brlcad | a good test case might be to take the cube that is produced by breplicator or brep_test in src/proc-db, make a copy of it, translated slightly so it overlaps corners, then evaluate a boolean |
| 19:54.48 | brlcad | the trimming curves are part of the topological structure, they define the actual edge to a given surface |
| 19:54.49 | jdoliner | or is there some function which actually sort of freezes the nurbs in their trimmed form |
| 19:55.04 | brlcad | there is not (that I"m aware of) |
| 19:55.13 | jdoliner | k I'll poke around |
| 19:55.36 | brlcad | it would be useful to have a routine that took a given ON_Brep and evaluated all trims to give a resulting object that is trim-free |
| 19:55.44 | brlcad | or at least only outer trims |
| 19:56.24 | brlcad | so there is a 1-1 relationship with trims to edges, each edge corresponding to a curve you can test against |
| 19:56.59 | jdoliner | okay, that makes sense |
| 19:58.19 | brlcad | jdoliner: also, if you've not read it yet, this may be of some assistance organizationally |
| 19:58.23 | brlcad | http://brlcad.svn.sourceforge.net/viewvc/brlcad/brlcad/trunk/doc/TODO.BREP |
| 19:58.40 | brlcad | has all of the various pairwise evaluation possibilities |
| 20:01.42 | jdoliner | I see, are all those things unimplemented? |
| 20:03.36 | brlcad | oh no, much is, much isn't .. some IS implemented (particularly for polygonal types), but for different (non-opennurbs) data types |
| 20:04.24 | brlcad | some is very robust to numerical issues, some isn't -- it's a very large body of code that gets involved when you start talking about existing brep work |
| 20:08.48 | brlcad | code of relevance is src/librt/primitives/nmg (extensive polygonal mesh CSG library, radial-edge data structure), src/librt/primitives/bspline (old nurbs implementation, lacking support for trimmed nurbs surfaces), src/librt/opennurbs_ext.cpp and src/librt/primitives/brep (active new nurbs development) |
| 20:09.37 | brlcad | suggest at least taking a look at the nmg routines as they strongly relate to what you're doing with ON_Mesh |
| 20:13.51 | jdoliner | yes will do immediately |
| 20:17.14 | brlcad | nmg_evaluate_boolean() is particularly relevant, starting in src/librt/primitives/nmg/nmg_eval.c |
| 20:18.38 | brlcad | as you are going to end up with some sort of similar routine hopefully to evaluate two ON_Brep objects |
| 20:26.22 | CIA-32 | BRL-CAD: 03indianlarry * r34845 10/brlcad/trunk/ (include/opennurbs_ext.h src/librt/primitives/brep/brep.cpp): added NEAR_MISS points to hitlist, hitlist logic being worked |
| 21:09.41 | *** join/#brlcad stevegt_1 (n=stevegt@cislunar.TerraLuna.Org) | |
| 21:22.21 | CIA-32 | BRL-CAD: 03starseeker * r34846 10/brlcad/trunk/src/librt/primitives/brep/brep.cpp: |
| 21:22.27 | CIA-32 | BRL-CAD: Try to add a printout message that will detail the type of odd hit count |
| 21:22.34 | CIA-32 | BRL-CAD: behavior being observed - for reasons not quite clear, the reporting isn't doing |
| 21:22.38 | CIA-32 | BRL-CAD: what I expected it to - it's not reporting close points at all and only |
| 21:22.44 | CIA-32 | BRL-CAD: occasionally reporting entering/leaving status. |
| 21:36.02 | starseeker | indianlarry: am I doing something wrong with printing out the hit info? |
| 21:39.58 | CIA-32 | BRL-CAD: 03irpguardian * r34847 10/brlcad/trunk/TODO: Added human geometry generator item |
| 21:56.23 | *** join/#brlcad madant (n=cb7baf0f@bz.bzflag.bz) | |
| 22:07.25 | madant | what is the bn or bu random number generating function which i could use as an id |
| 22:23.14 | Ralith | brlcad: thanksâhopefully it won't come up again. |
| 22:36.28 | *** join/#brlcad Elrohir (n=kvirc@p5B14C62F.dip.t-dialin.net) | |
| 22:43.22 | *** join/#brlcad mafm_ (n=mafm@165.Red-81-35-69.dynamicIP.rima-tde.net) | |
| 23:05.48 | *** join/#brlcad samrose (n=samrose@adsl-99-147-180-206.dsl.lgtpmi.sbcglobal.net) | |
| 23:06.50 | *** join/#brlcad BigAToo (n=BigAToo@pool-96-230-124-196.sbndin.btas.verizon.net) | |
| 23:09.38 | *** join/#brlcad mafm_ (n=mafm@165.Red-81-35-69.dynamicIP.rima-tde.net) | |