Screenshot instructions:
Windows
Mac
Red Hat Linux
Ubuntu
Click URL instructions:
Rightclick on ad, choose "Copy Link", then paste here →
(This may not be possible with some types of ads)
From: phoenix <284281400@qq...>  20120717 16:54:24
Attachments:
Message as HTML

> One other thought is that in addition to an interactive visual, you > may also want to generate a series of .pl files (plot files that can > be viewed with the overlay command) corresponding to each individual > segment of the curve  i.e. for each curve segment generated, generate > a pl file containing the surface plots, the bounding boxes from both > surfaces that went into that specific curve segment, and the curve > segment itself. That will let you pull up the subset of the plots > that pertain to a specific curve, if you need to focus in on a problem >  avoiding the visual clutter is often very helpful when debugging. I > don't know if the data are stored in such a way that you can easily do > that, but if so it may be a worthwhile addition. It seems that the bounding boxes that went into a *specific* curve segment cannot be directly known, but we can easily get all the bounding boxes along the intersection curves. I will implement this addition once I find it necessary. At present I'd like to focus on extending the brep command and plotting surfaces and intersection curves. > Let us know if you need examples of generating .pl files. Nice progress! I will mail this list once I need them. Thank you. Cheers! Wu 
From: phoenix <284281400@qq...>  20120718 12:48:03
Attachments:
Message as HTML

Hi, Today I find something interesting in procdb/brepintersect.h(cpp). After skimming the code I found it's doing something very similar to my current surfacesurface intersection. Is it an unfinished SSI implementation a few years ago? I'm just very curious about this. Now I have added an option to the brep command in MGED and can tested surfacesurface intersection conveniently with it. The intersection function still needs lots of improvements, though. I will upload some test results on my log page in a few days. Cheers! Wu 
From: Clifford Yapp <cliffyapp@gm...>  20120718 13:33:23

On Wed, Jul 18, 2012 at 8:47 AM, phoenix <284281400@...> wrote: > Hi, > > Today I find something interesting in procdb/brepintersect.h(cpp). After > skimming the code I found it's doing something very similar to my current > surfacesurface intersection. Is it an unfinished SSI implementation a few > years ago? I'm just very curious about this. Ah, yeah that's right  that code is from an earlier GSoC attempt. Feel free to incorporate anything there you find useful, but I don't know how functional the various bits of that code are. I'm pretty sure that code doesn't have any logic using surface tree bounding boxes. By the way, there are line segment/line segment intersection routines in libbn that may be handy for this  see bn_isect_line3_line3. > Now I have added an option to the brep command in MGED and can tested > surfacesurface intersection conveniently with it. The intersection function > still needs lots of improvements, though. I will upload some test results on > my log page in a few days. Excellent! Nice progress. Looking ahead a little bit (while I'm thinking about work already done)  once you are happy with the curves being produced by the intersection routine, the next step will be to "pull back" the 3D curve into the UV parameter spaces of the intersecting surfaces in order to create 2D trimming curves (and hence new trimmed surfaces that will be used to form the evaluated breps). There is logic for that task in the stepg converter  it needs to be moved into librt, but that will probably be a lot less work than recreating it. Again, that's down the road after the intersection issue itself has been worked out, but I thought I'd mention it. Cliff 
From: phoenix <284281400@qq...>  20120730 15:42:15
Attachments:
Message as HTML

Hi, > Looking ahead a little bit (while I'm thinking about work already > done)  once you are happy with the curves being produced by the > intersection routine, the next step will be to "pull back" the 3D > curve into the UV parameter spaces of the intersecting surfaces in > order to create 2D trimming curves (and hence new trimmed surfaces > that will be used to form the evaluated breps). There is logic for > that task in the stepg converter  it needs to be moved into librt, > but that will probably be a lot less work than recreating it. Again, > that's down the road after the intersection issue itself has been > worked out, but I thought I'd mention it. The 2D curves in UV parameter spaces can be created within the intersection process, and I have finished it now. It works quite well at present, although it might still need some improvement. So I wonder how to deal with these 2D trimming curves. How to use them to generate new trimmed brep surfaces? That is, if we want to form the evaluated breps, we need to know the topological structure of the whole solid. For example, we evaluate a union of two intersecting spheres, we need to know which side of the intersecting curve is inside the union, and which side is the outer boundary of the union. Could you please describe this in more detail? As for the threshold of bounding boxes' sizes, I think using INTERSECT_MAX_DEPTH is just OK. If we use a constant value to decide whether a bounding box is small enough, it's not quite suitable because the original sizes of the surfaces can vary significantly. So using a max depth we guarantee that we arrive at a constant proportion of the original size in UV parameter spaces (because after each split the UV domains both become half). What's your opinion? Cheers! Wu 
From: Clifford Yapp <cliffyapp@gm...>  20120731 03:16:13

On Mon, Jul 30, 2012 at 11:41 AM, phoenix <284281400@...> wrote: > The 2D curves in UV parameter spaces can be created within the intersection > process, and I have finished it now. It works quite well at present, > although it might still need some improvement. Excellent! > So I wonder how to deal with these 2D trimming curves. How to use them to > generate new trimmed brep surfaces? That is, if we want to form the > evaluated breps, we need to know the topological structure of the whole > solid. For example, we evaluate a union of two intersecting spheres, we need > to know which side of the intersecting curve is inside the union, and which > side is the outer boundary of the union. Could you please describe this in > more detail? Here are my initial thoughts on this topic: 1. If no curve is generated, then the structure is dictated by the boolean operations only: A U B: a. If one of A or B contains the other, return the containing brep. (So if B fits within A, just return A) b. Otherwise... as a first guess I'd say try creating two breps  combname_A and combname_b  which would be duplicates of the A and B breps with local matricies applied and the substitute those two breps into expressions further up the tree. Not entirely sure about that  there are some more subtle issues there that require some thought  but that should do for a first cut. A  B: a. B contains A  the geometry is completely subtracted away, nothing to generate. Return nothing (or a null brep, if that makes more sense in context.) b. A contains B  B becomes the "inner" surface of A  essentially, B gets flipped and turned into an interior face of A c. A and B do not overlap at all  just return A. A + B: a. If one of A or B contains the other, return the brep that is contained. (So if B fits within A, just return B) b. If A and B do not overlap, return nothing (or a null brep, if that makes more sense in context.) 2. If an intersection point is generated: A U B: Hmm... don't worry about this case yet, I need to discuss how we want to handle it with some of the other devs. Hopefully it will be relatively rare, so you can focus on the other cases while we decide what the "correct" behavior is. A  B: Use the intersection point and the surface normal of A at that point to form a plane. Shift that plane bn_tol in the direction opposite that of the surface normal, find the intersection curve of the result, and remove that from B. Not ideal in some ways, but will ensure that A' does not intersect B. A + B: No volume described by a single intersection point  return nothing. (or a null brep, if that makes more sense in context.) 3. If an intersection curve is generated, applying the trimming curves will result in multiple surfaces (depending on whether the curves are used as part of a new outer loop, or a new inner loop): A U B: For each surface generated for A and B, test whether it is inside the other brep. Once you know which surfaces are fully inside the other breps, those surfaces may be discarded. A  B: For each surface from B, check whether it is inside A. If so, it is flipped and forms a new surface in the evaluated A (call it A'). If not, the surface is discarded. A + B: For each surface, is it inside both A and B? If so, it is part of the new brep. 4. If an intersection surface is generated: A U B: Remove the matching surfaces patches from both breps, and merge to form a new brep. A  B: This is a bit trickier  in this situation, the only thing I can think to do is to find the plane of intersection of the surfaces patches, move it bn_tol in the direction opposite that of the surface normal of A's patch, find the new intersection curve between that plane and A, and use that surface patch as the new surface for A' in that region. That's not mathematically ideal, but it will achieve the expected and desired result of A' not intersecting B. A + B: This produces a plane, not a solid brep, so return nothing. (or a null brep, if that makes more sense in context.) Testing inside/outside when you have intersection curve(s)... I'm not sure what the best approach is there yet. Some kind of bbox approach might be possible, but I'm not sure if there's a better way... perhaps you could take the 3D bbox of the intersection curve, subtract it from the bboxes of the two input breps, and then for each surface subdivide until you got a box that was unambiguously in only one of the brep bbox  curve bbox boxes? > As for the threshold of bounding boxes' sizes, I think using > INTERSECT_MAX_DEPTH is just OK. If we use a constant value to decide whether > a bounding box is small enough, it's not quite suitable because the original > sizes of the surfaces can vary significantly. So using a max depth we > guarantee that we arrive at a constant proportion of the original size in UV > parameter spaces (because after each split the UV domains both become half). > What's your opinion? As long as performance and results both seem good, that sounds fine. Cheers, CY 
From: Clifford Yapp <cliffyapp@gm...>  20120731 16:26:56

> 2. If an intersection point is generated: > > A  B: Use the intersection point and the surface normal of A at > that point to form a plane. Shift that plane bn_tol in the direction > opposite that of the surface normal, find the intersection curve of > the result, and remove that from B. Not ideal in some ways, but will > ensure that A' does not intersect B. Sorry  the above should be "remove that from A"  since you're subtracting from A, that'd be the brep you'd be removing volume from. > Testing inside/outside when you have intersection curve(s)... I'm not > sure what the best approach is there yet. Some kind of bbox approach > might be possible, but I'm not sure if there's a better way... > perhaps you could take the 3D bbox of the intersection curve, subtract > it from the bboxes of the two input breps, and then for each surface > subdivide until you got a box that was unambiguously in only one of > the brep bbox  curve bbox boxes? Another possible approach here (a much cleaner one, if it works) is to use the knowledge of shared curves and whether the curve is an inner or outer trimming loop in the new surfaces created... below is an illustration of how I think this might work, but I'm not sure yet if it holds up  needs more thinking. If a sphere is subtracted from another sphere (A  B) and one intersection curve is found, four surfaces get created  A1, A2, B1, B2. A1 is created by using the trimming curve as an inner trimming curve on A, A2 is generated by using the same trimming curve as a new outer curve on A. (Same for B1 and B2.) Since B is being subtracted from A, any surfaces from B that end up as part of the result will need to be flipped  creating B1' and B2'. Since the original operation is A  B, we remove the surface that has the curve as part of a new outer trimming loop from A (A2) and substitute in the flipped surface from B that shares that same curve as part of a new outer trimming loop : A  B = (A  A2) + B2' = A1 + B2' Does that seem to make sense? Need to consider some other cases, like a sphere sitting "on top of" a torus  there will be a circular intersection curve there, but zero volume  how do we recognize that... CY 
From: Clifford Yapp <cliffyapp@gm...>  20120717 18:03:31

On Tue, Jul 17, 2012 at 12:54 PM, phoenix <284281400@...> wrote: > It seems that the bounding boxes that went into a *specific* curve segment > cannot be directly known, but we can easily get all the bounding boxes along > the intersection curves. I will implement this addition once I find it > necessary. At present I'd like to focus on extending the brep command and > plotting surfaces and intersection curves. Sounds good  it makes sense to wait on that feature until it is needed, if it cannot be done trivially with the existing setup. CY 
Sign up for the SourceForge newsletter:
No, thanks