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}
(9) 
_{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}

_{Apr}

_{May}

_{Jun}

_{Jul}

_{Aug}

_{Sep}

_{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: phoenix <284281400@qq...>  20120724 15:27:46

> Actually, you might even be able to go with the "build successive sets > of intersecting bounding boxes" approach without ever needing the tree > overhead in the first place. Thanks for your detailed description of the algorithm. Really make sense. Yeh, all we need is to split the surface into four parts using the ON_NurbsSurface::Split method, and this is what the SurfaceTree() routine actually does. Splitting a surface and calculate the subsurfaces' bounding boxes is just like generating a BBNode's four children. That's also what I intend to do as I said in the last Email. I will try it out tomorrow. Cheers! Wu 
From: Clifford Yapp <cliffyapp@gm...>  20120724 15:03:40

On Tue, Jul 24, 2012 at 9:55 AM, phoenix <284281400@...> wrote: > Maybe the first step is to look deeper into how we build > a surface tree and find a way to integrate it into the intersection > calculation process  that is, only useful parts of the tree will be > generated. When this is finished, maybe a tolerance value will be adapted so > that we do not use a constant INTERSECT_MAX_DEPTH, which is not quite > elegant. Actually, you might even be able to go with the "build successive sets of intersecting bounding boxes" approach without ever needing the tree overhead in the first place. The surface tree as currently implemented is primarily used for ray intersections  each ray is starting "from the beginning" when approaching the surface, and hence needs the full tree to be present ahead of time. The SSI calculation, on the other hand, is concerned only with the parts of the surfaces that intersect  the "tree" is just a temporary structure used to find those parts. For SSI, you don't even need a tree at all in the sense of defining parent and child bounding boxes  you just need the intersecting box sets from the two surfaces. My guess is the following  the "piece" you will need from the surface tree building routine is the logic that takes an input surface and generates four subsurfaces. The routines for calculating bboxes I believe come from openNURBS and aren't specific to the surface tree. The quad surface split may be a good candidate to refactor into a separate function call, if it's not already set up that way. The the algorithm then becomes something along these lines: 1. take two input surfaces, S1 and S2, and calculate their bounding boxes. Check if they overlap. 2 If they do, establish four sets of a structure holding a bounding box and a surface  S1_set1, S2_set1, S1_set2 and S2_set2. The structure would be something like: struct Surface_And_Box { ON_BoundingBox bbox; ON_NurbsSurface surf; } 3. Break S1 into 4 subsurfaces (using the quadsplit functionality broken out from the tree routines) 4. Calculate the bboxes for the 4 subsurfaces of S1 5. Make structure instances holding the bboxes and the corresponding subsurfaces and insert them into S1_set1. 6. Repeat 35 for S2. 7. Check that all boxes in S1_set1 intersect at least one box in S2_set1, and vice versa. Remove any nonintersecting boxes from the sets. 8. Now that we have S1_set1 and S2_set1, the iterative refinement can begin. Iterate over the boxes in S1_set1, checking to see if they are dimensionally small enough to serve the SSI algorithm's purposes. For each instance that is small enough, simply move it to S1_set2. If it is not small enough, perform steps 35 with the subsurface associated with the given bounding box, except results are inserted into S1_set2 rather than S1_set1 9. Perform the steps from #8 for S2_set1, putting the results in S2_set2. 10. Clear S1_set1 and S2_set1. 11. Test all the bboxes in S1_set1 and S2_set1 for intersection with bboxes in the other set. Move the structures associated with any boxes that do intersect to S1_set1 and S2_set1 respectively. 12. Clear S1_set2 and S2_set2 (anything left in them is nonintersecting and of no further interest.) 13. Repeat steps 812 until all boxes in S1_set1 and S2_set1 have suitable size for SSI fitting, then proceed with the remainder of the SSI algorithm. Cheers, Cliff 
From: Kristaps Baumanis <kristaps.baumanis@gm...>  20120724 13:56:46

Hello I am a student at University of Strathclyde, in Glasgow. I am studying Electrical and Mechanical Engineering and I just finished my third year. I am currently contemplating applying to SOCIS 2012. My programming experience includes two years of Pascal during highschool, a onesemester course in C programming at university and a onesemester course in microcontroller programming (also C). Also during the last academic session my third year project (together with four other people) was designing a hexapod for which I wrote the software. All programming was done in C. In my own time I have studied a bit of Python and Java as well. BRLCAD seems to suit my interest, in particular I have been looking at the http://brlcad.org/wiki/Bending_light and http://brlcad.org/wiki/Astronomical_units. My question is how much time should I expect to be putting in (provided I actually apply and get assigned a project)? I am very interested to participate, however in midaugust I am going to Atlanta for an exchange year within Georgia Institute of Technology (I will still technically be a student at Strathclyde, so I am eligible for the program) which means my university year will start a month early and I will have less time for sidework. Regards, Kristaps 
From: phoenix <284281400@qq...>  20120724 13:55:47

Hi, > Noticed in your log you ran into a tradeoff between tree build depth > and curve quality. This is actually a useful thing to consider in > more detail  once you have the initial bounding box set, I think > there may be a refinement approach you can take that involves a lot > less overhead than deeper tree builds. I also think about this approach when I write my code  but it's not implemented yet because it needs further looking into the surface tree building process. Now I just use the constructor of SurfaceTree to build a surface tree with a max depth for a face (because it is easy to implement with the existing functions), but when calculating the intersection, I only consider the useful parts (not the entire tree of course). You are right, to build a surface tree with deeper hierarchy takes a long time and consumes lots of memory resources, but only a small subset of it is used in the latter calculation. Maybe the first step is to look deeper into how we build a surface tree and find a way to integrate it into the intersection calculation process  that is, only useful parts of the tree will be generated. When this is finished, maybe a tolerance value will be adapted so that we do not use a constant INTERSECT_MAX_DEPTH, which is not quite elegant. Cheers! Wu 
From: Clifford Yapp <cliffyapp@gm...>  20120724 12:42:55

Wu, Noticed in your log you ran into a tradeoff between tree build depth and curve quality. This is actually a useful thing to consider in more detail  once you have the initial bounding box set, I think there may be a refinement approach you can take that involves a lot less overhead than deeper tree builds. If you need more refinement than is offered by the initial surface tree intersection (guaranteed with a shallow, fast tree build): 1. Take the set of leaf intersected bounding boxes from the two surfaces. For each surface, insert its bounding boxes that are part of the intersection set into their own container. Those are your initial sets. 2. For each box, if the dimensions look "too large" for the preferred line segment distance for the current situation, iterate over the boxes in the containers and for each box generate the four child bounding boxes the way the SurfaceTree depth building would. Stash those in two more containers and use those new bbox sets to regenerate an intersection set consisting of smaller, refined boxes. Once the finer intersection box set is generated, you can discard the previous courser sets and use the new intersection set  unless I'm missing something (possible) you shouldn't need to preserve the full tree hierarchy in this situation. 3. Repeat step 1 and 2 until you have small enough boxes for the local situation. This avoids having to build the entire tree to great depth, which is where we get into performance trouble (particularly memory consumption) and lets you get as much dimensional refinement as you need in tricky local situations. This way, you're only storing what you need, and only generating the deep boxes you need. That approach (or some variation of it) may give you more flexibility when intersecting. Cheers, Cliff 
From: Tom Browder <tom.browder@gm...>  20120724 01:15:04

I just spotted this which may be useful in the future when someone tackles GPU use for BRLCAD: http://www.codeproject.com/Articles/415058/VexCLVectorexpressiontemplatelibraryforOpenC Best, Tom 