You can subscribe to this list here.
2004 
_{Jan}

_{Feb}

_{Mar}

_{Apr}

_{May}

_{Jun}

_{Jul}

_{Aug}
(1) 
_{Sep}

_{Oct}

_{Nov}

_{Dec}


2005 
_{Jan}
(4) 
_{Feb}
(2) 
_{Mar}
(7) 
_{Apr}
(2) 
_{May}
(2) 
_{Jun}
(8) 
_{Jul}

_{Aug}
(4) 
_{Sep}
(3) 
_{Oct}
(10) 
_{Nov}
(1) 
_{Dec}
(10) 
2006 
_{Jan}
(6) 
_{Feb}
(2) 
_{Mar}
(4) 
_{Apr}
(6) 
_{May}
(21) 
_{Jun}
(8) 
_{Jul}
(3) 
_{Aug}
(7) 
_{Sep}
(1) 
_{Oct}
(1) 
_{Nov}
(1) 
_{Dec}

2007 
_{Jan}
(2) 
_{Feb}
(5) 
_{Mar}
(5) 
_{Apr}
(3) 
_{May}
(2) 
_{Jun}
(1) 
_{Jul}
(9) 
_{Aug}

_{Sep}
(4) 
_{Oct}
(5) 
_{Nov}

_{Dec}
(2) 
2008 
_{Jan}
(3) 
_{Feb}
(1) 
_{Mar}
(15) 
_{Apr}
(10) 
_{May}
(11) 
_{Jun}
(31) 
_{Jul}
(16) 
_{Aug}
(71) 
_{Sep}
(15) 
_{Oct}
(7) 
_{Nov}
(15) 
_{Dec}

2009 
_{Jan}
(8) 
_{Feb}
(4) 
_{Mar}
(44) 
_{Apr}
(36) 
_{May}
(14) 
_{Jun}
(30) 
_{Jul}
(19) 
_{Aug}
(1) 
_{Sep}
(5) 
_{Oct}
(2) 
_{Nov}
(5) 
_{Dec}
(10) 
2010 
_{Jan}
(19) 
_{Feb}
(21) 
_{Mar}
(1) 
_{Apr}
(38) 
_{May}
(10) 
_{Jun}
(8) 
_{Jul}
(1) 
_{Aug}
(23) 
_{Sep}
(30) 
_{Oct}
(19) 
_{Nov}
(4) 
_{Dec}
(13) 
2011 
_{Jan}
(129) 
_{Feb}
(51) 
_{Mar}
(39) 
_{Apr}
(20) 
_{May}
(12) 
_{Jun}
(30) 
_{Jul}
(38) 
_{Aug}
(24) 
_{Sep}
(164) 
_{Oct}
(92) 
_{Nov}
(33) 
_{Dec}
(27) 
2012 
_{Jan}
(77) 
_{Feb}
(29) 
_{Mar}
(251) 
_{Apr}
(159) 
_{May}
(219) 
_{Jun}
(142) 
_{Jul}
(180) 
_{Aug}
(50) 
_{Sep}
(4) 
_{Oct}
(7) 
_{Nov}
(45) 
_{Dec}
(22) 
2013 
_{Jan}
(16) 
_{Feb}
(6) 
_{Mar}
(34) 
_{Apr}
(211) 
_{May}
(97) 
_{Jun}
(95) 
_{Jul}
(219) 
_{Aug}
(170) 
_{Sep}
(175) 
_{Oct}
(191) 
_{Nov}
(78) 
_{Dec}
(90) 
2014 
_{Jan}
(77) 
_{Feb}
(84) 
_{Mar}
(232) 
_{Apr}
(56) 
_{May}
(110) 
_{Jun}
(97) 
_{Jul}
(69) 
_{Aug}
(58) 
_{Sep}
(54) 
_{Oct}
(76) 
_{Nov}
(53) 
_{Dec}
(30) 
2015 
_{Jan}
(28) 
_{Feb}
(22) 
_{Mar}
(268) 
_{Apr}
(54) 
_{May}
(66) 
_{Jun}
(90) 
_{Jul}
(75) 
_{Aug}
(61) 
_{Sep}
(4) 
_{Oct}
(5) 
_{Nov}
(41) 
_{Dec}
(3) 
2016 
_{Jan}
(5) 
_{Feb}
(40) 
_{Mar}
(422) 
_{Apr}
(33) 
_{May}
(74) 
_{Jun}
(80) 
_{Jul}
(43) 
_{Aug}
(79) 
_{Sep}
(11) 
_{Oct}

_{Nov}

_{Dec}

S  M  T  W  T  F  S 

1
(1) 
2
(1) 
3
(5) 
4
(6) 
5
(2) 
6
(10) 
7
(28) 
8
(8) 
9
(6) 
10
(13) 
11
(19) 
12
(4) 
13
(9) 
14
(2) 
15
(1) 
16
(21) 
17
(8) 
18
(9) 
19
(4) 
20
(3) 
21

22
(2) 
23
(2) 
24
(6) 
25
(4) 
26

27

28

29
(1) 
30
(1) 
31
(4) 




From: Clifford Yapp <cliffyapp@gm...>  20120731 19:09:35

On Tue, Jul 31, 2012 at 2:16 PM, phoenix <284281400@...> wrote: > Yes, it does make sense. As for the case above, for a tours, only one > circular intersection curve cannot divide the torus' surface into two parts, > so I hope it won't cause much problem. I will try this and find out whether > it works... Ah, right  I would expect that to be a degenerate curve in UV space, come to think of it. Definitely a good test case. > As for splitting a surface using the intersection curves, it still needs > some consideration. There are several different cases. But it's the first > step before we do the rest. Creating several trimming NURBS surfaces from > the original one (splitting) is the first thing I need to focus on now. Does > it make sense? Yes  new surfaces will need to be made first, before we can work with them. Since you have uv space curves, they will be used to either alter existing inner and outer trimming loops, add completely new inner loops, or redefine outer loops. The cases are: 1. trimming loop found by intersection test does not intersect any existing inner or outer loop on the original surface. a. Surface 1  copy original surface, create new interior trimming loop using loop from intersection test. b. Surface 2  copy original surface, replace original outer trimming loop with loop from intersection test. 2. trimming loop found by intersection test does intersect an outer trimming loop on the original surface. a. Surface 1  copy the original surface  when working with the copy, the intersected outer loop can either be adjusted to incorporate the curve from the intersection test, or a new interior loop can be created using the intersected segment of the outer loop and the intersection curve. I'd opt for the first, personally, but either could work. b. Surface 2  copy the original surface, find the curve segment from the outer loop that, in combination with the intersection curve, forms a closed loop, and make that the new outer trimming curve. 3. trimming loop found by intersection test intersects an inner trimming loop on the original surface. a. Surface 1  copy the original surface. Find the portion of the inner trimming loop that is intersected by the intersection curve. Remove that portion from the original inner trimming loop, and replace it with the curve from the intersection test. b. Surface 2  copy the original surface. Use the curve segment discarded from Surface 1 and the intersection test curve to form a new outer loop. Then, of course, you can have multiple intersections with multiple sorts of curves from the original surface. In essence, this part of the process is where curve/curve intersection functions are necessary. You can probably create those with a 2D variation on the same approach used for the 3D intersection curves  get the UV space bounding boxes for two candidate intersection curves, and subdivide down to get close to the intersections, then linear (rather than planar) approximations to get the final points. (Or there may be other, faster/better algorithms  that's just the one that suggests itself in context.) Your earlier tgc/epa intersection example is an example where there will be curve/curve intersections to find, and of course it's quite simple to construct others. It's up to you  it may be simpler, initially, to create breps consisting of surfaces made from each of the original intersected breps, and verify that the new surfaces reproduce successfully the original breps  that would allow postponement of how to assemble the surfaces into the final brep form. Cheers, Cliff 
From: phoenix <284281400@qq...>  20120731 18:16:47

> 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... Yes, it does make sense. As for the case above, for a tours, only one circular intersection curve cannot divide the torus' surface into two parts, so I hope it won't cause much problem. I will try this and find out whether it works... As for splitting a surface using the intersection curves, it still needs some consideration. There are several different cases. But it's the first step before we do the rest. Creating several trimming NURBS surfaces from the original one (splitting) is the first thing I need to focus on now. Does it make sense? Cheers! Wu 
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...>  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 