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}
(38) 
_{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: 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 
From: phoenix <284281400@qq...>  20120730 15:42:15

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: plussai <55549227@qq...>  20120729 00:11:27

Hi! At first, as I know floatpoint comparison in computer is not accurate, So, It needs some comparison function within error precision, for example, 'NEAR_EQUAL' and 'NEAR_ZERO' in 'vmath.h'. So, I plan to add some other comparison functions,like: GREATER(_a, _b, TOL), NOLESS(_a, _b , TOL), SMALLER(_a, _b , TOL), NOGREATER(_a, _b, TOL); Secondly, I noticed that it renders primitives by raytracing only once and then, I can view it from any perspective. I'm just curious that how to do it? Cheers! Laijiren 
From: Clifford Yapp <cliffyapp@gm...>  20120725 11:48:26

On Wed, Jul 25, 2012 at 6:05 AM, Ksenija Slivko <ksuzee91@...> wrote: > Hello, Cliff! > > Thanks for your checking my patches! > > As for patch #3533010  yes, it really must go together with 3534958, > because Makefile.am and CMakeLists.txt are the same for them. I could put > these two into one patch, but it would be huge and it isn't welcome. That's OK, but be sure to document that a patch needs other patches applied first (and which ones) so we know in what order we need to review them. > As for #3534954 I can't understand. I really didn't remove anything...Added > parameter for fprintf only. Also after regular updating I saw that this > patch was accepted too. I backed it out when I realized it was removing more than it replaced. If you look at the plfb.patch file, you will see quite a lot is removed from GetDCoords  if I'm understanding correctly, that call to dCoords should still be wrapped insided the if(debug) check and the rest of GetDCoords shouldn't change. > I've already written in my previous email: > >>During this period, not wasting time I'm going to start >>reduction in duplications which take place in different directiories. As >>Sean told to leave alone duplicatios from libged to mged, I'd want to start >>from libgedlibdm. In both libraries there's file clip.c and there're quite >>enough functions  the same in libged and libdm. So how would you adviced >>to reduct this? Maybe to leave this functions in libged and in this case >>libdm will depend on libged? I'm looking forward to your answer. > > Sorry for copypaste :), but I really need this help. Looking at clip.c, that logic might be a candidate for refactoring as a libbn function. Something that would be helpful  if you start with a vanilla source tree, can you provide the order in which you would apply your existing patches with the expectation that they all apply cleanly and correctly? That will tell us how to review them. Cheers, Cliff 
From: Ksenija Slivko <ksuzee91@gm...>  20120725 10:05:57

Hello, Cliff! Thanks for your checking my patches! As for patch #3533010  yes, it really must go together with 3534958, because Makefile.am and CMakeLists.txt are the same for them. I could put these two into one patch, but it would be huge and it isn't welcome. As for #3534954 I can't understand. I really didn't remove anything...Added parameter for fprintf only. Also after regular updating I saw that this patch was accepted too. I've already written in my previous email: >During this period, not wasting time I'm going to start >reduction in duplications which take place in different directiories. As >Sean told to leave alone duplicatios from libged to mged, I'd want to start >from libgedlibdm. In both libraries there's file clip.c and there're quite >enough functions  the same in libged and libdm. So how would you adviced >to reduct this? Maybe to leave this functions in libged and in this case >libdm will depend on libged? I'm looking forward to your answer. Sorry for copypaste :), but I really need this help. Thanks, Ksenija 
From: Kristaps Baumanis <kristaps.baumanis@gm...>  20120725 06:35:37

Hi Thank you for the response. Most likely I won't be able to spare anything near 40 hours per week seeing as my academic advisor expects quite a bit of work from me in Atlanta. And thus I will apply next year, when I have more time, when uni doesn't start until end of September. Cheers, Kristaps On 25 July 2012 03:57, Christopher Sean Morrison <brlcad@...> wrote: > > On Jul 24, 2012, at 9:56 AM, Kristaps Baumanis wrote: > > 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. > > > Hi Kristaps and welcome! In general, it's expected that SOCIS > participants are putting forth fulltime effort for the duration of the > program, which is generally 40+ hours per week. You don't get assigned a > project but, rather, propose (in detail) what it is you would like to work > on, what you intend to accomplish, and how you intend to accomplish it with > milestones and a development plan. If your proposal is selected among all > proposals submitted, you work towards your project goals. > > What you can do (now) is propose a development plan that accounts for your > exchange student transition, perhaps by planning to work more hours per > week at the beginning and less later on. So long as it's fully documented > in detail and you're forthcoming upfront, it's generally not a problem. > > Cheers! > Sean > > > >  > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > BRLCAD Developer mailing list > brlcaddevel@... > https://lists.sourceforge.net/lists/listinfo/brlcaddevel > > 
From: Christopher Sean Morrison <brlcad@ma...>  20120725 02:57:08

On Jul 24, 2012, at 9:56 AM, Kristaps Baumanis wrote: > 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. Hi Kristaps and welcome! In general, it's expected that SOCIS participants are putting forth fulltime effort for the duration of the program, which is generally 40+ hours per week. You don't get assigned a project but, rather, propose (in detail) what it is you would like to work on, what you intend to accomplish, and how you intend to accomplish it with milestones and a development plan. If your proposal is selected among all proposals submitted, you work towards your project goals. What you can do (now) is propose a development plan that accounts for your exchange student transition, perhaps by planning to work more hours per week at the beginning and less later on. So long as it's fully documented in detail and you're forthcoming upfront, it's generally not a problem. Cheers! Sean 
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 
From: Ksenija Slivko <ksuzee91@gm...>  20120723 10:29:53

Hello! During last week I updated all the patches where duplications take place in different files  one directory according HACKING file: now there're no unnecessary headers and necessary comments are added. So i wiil wait for your checking. But during this period, not wasting time I'm going to start reduction in duplications which take place in different directiories. As Sean told to leave alone duplicatios from libged to mged, I'd want to start from libgedlibdm. In both libraries there's file clip.c and there're quite enough functions  the same in libged and libdm. So how would you adviced to reduct this? Maybe to leave this functions in libged and in this case libdm will depend on libged? I'm looking forward to your answer. Best, Ksenija 
From: Daniel Roßberg <danielmrossberg@gm...>  20120723 06:22:28

2012/7/20 Oliver Gloth <ogloth@...>: > Daniel, > > I thought it was a known behaviour; if not, I'll first have a look at my > stuff and make sure that I didn't make any silly mistake. > > Another question came up, however: Is there a method to determine if a > given point (x,y,z) is inside or outside of a given BRLCAD object? If the inhitpoint (pt_inhit>hit_point of struct partition or PointIn() of class ConstDatabase::Hit) is behind the ray's start point then the start point is inside the component, i.e. (inhitpoint  startpoint) \dot raydirection < 0 ==> startpoint is inside Daniel 
From: Suryajith Chillara <suryajith1987@gm...>  20120722 21:31:02

On 07/22/2012 10:25 AM, H.S.Rai wrote: > On Wed, Jul 11, 2012 at 11:16 PM, H.S.Rai<hardeep.rai@...> wrote: >> Nice to see documentation. If you are comfortable with LaTeX, it is >> good. I really enjoy pdf created from .tex. >> >> In .tex, file, if you use "verbatim" to wrte code and data structure. > If you still want to use LaTeX, then use package upquote to make look > of quotes acceptable as per coding norms. > Sure, I shall take that into consideration. I was thinking of using pygments for the code.  Regards, Suryajith Chillara. 
From: H.S.Rai <hardeep.rai@gm...>  20120722 04:55:33

On Wed, Jul 11, 2012 at 11:16 PM, H.S.Rai <hardeep.rai@...> wrote: > > Nice to see documentation. If you are comfortable with LaTeX, it is > good. I really enjoy pdf created from .tex. > > In .tex, file, if you use "verbatim" to wrte code and data structure. If you still want to use LaTeX, then use package upquote to make look of quotes acceptable as per coding norms.  H.S.Rai 
From: crdueck <crdueck@uw...>  20120720 20:09:40

Oliver, One method i've seen used in the librt library is to count the number of times a ray originating at the point in question intersects with the surface of the object. If the number of times is even, the point is outside the object. If odd, the point is inside. What specific BRLCAD object are you interested in? Chris On 07/20/2012 02:40 AM, Oliver Gloth wrote: > Daniel, > > I thought it was a known behaviour; if not, I'll first have a look at my > stuff and make sure that I didn't make any silly mistake. > > Another question came up, however: Is there a method to determine if a > given point (x,y,z) is inside or outside of a given BRLCAD object? > > Cheers, > Oliver > > On 19/07/12 11:15, Daniel Roßberg wrote: >> Oliver, >> >> I tried to reproduce your problem with a simple example (booleanops.g >> from BRLCAD's example geometries) but didn't succeed. Could you >> please provide us an example (geometry, start point, direction) and >> the result you got? >> >> Daniel >> >> >> 2012/7/17 Oliver Gloth<ogloth@...>: >>> Hello, >>> >>> I am working on a mesh generation algorithm based on BRLCAD. As >>> geometry interface I intend to use the raytracing functionality. From >>> any point in space I would like to shoot a ray in a given direction and >>> get the first intersection with the surface of the volume. The original >>> point could be inside or outside of the volume. Unfortunately >>> rt_shootray will also return intersections with internal shapes which >>> have been used to create the volume (boolean tree). Is there a way to >>> specify that I do not want this? Or do I have to shoot another ray in >>> the same direction and check if it reenters with zero distance? >>> >>> Cheers, >>> Oliver >>> >>> >>>  >>> Live Security Virtual Conference >>> Exclusive live event will cover all the ways today's security and >>> threat landscape has changed and how IT managers can respond. Discussions >>> will include endpoint security, mobile security and the latest in malware >>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ >>> _______________________________________________ >>> BRLCAD Developer mailing list >>> brlcaddevel@... >>> https://lists.sourceforge.net/lists/listinfo/brlcaddevel >>  >> Live Security Virtual Conference >> Exclusive live event will cover all the ways today's security and >> threat landscape has changed and how IT managers can respond. Discussions >> will include endpoint security, mobile security and the latest in malware >> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ >> _______________________________________________ >> BRLCAD Developer mailing list >> brlcaddevel@... >> https://lists.sourceforge.net/lists/listinfo/brlcaddevel >  > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > BRLCAD Developer mailing list > brlcaddevel@... > https://lists.sourceforge.net/lists/listinfo/brlcaddevel > 
From: plaes <plaes@pl...>  20120720 08:12:07

Ühel kenal päeval, N, 19.07.2012 kell 17:07, kirjutas Tom Browder: > Enough said. http://en.wikipedia.org/wiki/Posting_style#Topposting Päikest, Priit Laes :) 
From: Oliver Gloth <ogloth@en...>  20120720 06:40:11

Daniel, I thought it was a known behaviour; if not, I'll first have a look at my stuff and make sure that I didn't make any silly mistake. Another question came up, however: Is there a method to determine if a given point (x,y,z) is inside or outside of a given BRLCAD object? Cheers, Oliver On 19/07/12 11:15, Daniel Roßberg wrote: > Oliver, > > I tried to reproduce your problem with a simple example (booleanops.g > from BRLCAD's example geometries) but didn't succeed. Could you > please provide us an example (geometry, start point, direction) and > the result you got? > > Daniel > > > 2012/7/17 Oliver Gloth<ogloth@...>: >> Hello, >> >> I am working on a mesh generation algorithm based on BRLCAD. As >> geometry interface I intend to use the raytracing functionality. From >> any point in space I would like to shoot a ray in a given direction and >> get the first intersection with the surface of the volume. The original >> point could be inside or outside of the volume. Unfortunately >> rt_shootray will also return intersections with internal shapes which >> have been used to create the volume (boolean tree). Is there a way to >> specify that I do not want this? Or do I have to shoot another ray in >> the same direction and check if it reenters with zero distance? >> >> Cheers, >> Oliver >> >> >>  >> Live Security Virtual Conference >> Exclusive live event will cover all the ways today's security and >> threat landscape has changed and how IT managers can respond. Discussions >> will include endpoint security, mobile security and the latest in malware >> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ >> _______________________________________________ >> BRLCAD Developer mailing list >> brlcaddevel@... >> https://lists.sourceforge.net/lists/listinfo/brlcaddevel >  > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > BRLCAD Developer mailing list > brlcaddevel@... > https://lists.sourceforge.net/lists/listinfo/brlcaddevel 
From: Tom Browder <tom.browder@gm...>  20120719 22:08:19

Enough said. Best, Tom 
From: crdueck <crdueck@uw...>  20120719 19:26:26

Thanks Sean, I added an explanation in r51599. Let me know if anything is still unclear. On 07/19/2012 08:30 AM, Christopher Sean Morrison wrote: > Chris, > > Can you document, i.e., add a NOTE comment, as to why 0.01 is more reasonable than RT_LEN_TOL? Adding a #define above that function with the comment would help explain what that value means and/or why it's better than other values. Like if that's in uvspace, maybe that walks in increments that are approximately 1% linearly across the uv space? If it's absolute valued, maybe it guarantees you'll find inflection points within 0.01mm accuracy (in which case it should change to 0.0005? If it's meant to test curvature flatness and that's the dot product, then you could document that as well. > > Whatever the reasoning, any time there is a "bare" number like that, it should be clearly documented even if only to say this number was pulled out of thin air but seems to work (hopefully not though). > > At a glance, it looks like RT_DOT_TOL might be what you want to use (notice how it's documented in raytrace.h). > > Cheers! > Sean > > > On Jul 19, 2012, at 2:42 AM, crdueck@... wrote: > >> Revision: 51585 >> http://brlcad.svn.sourceforge.net/brlcad/?rev=51585&view=rev >> Author: crdueck >> Date: 20120719 06:42:39 +0000 (Thu, 19 Jul 2012) >> Log Message: >>  >> approx_bezier interval step size now varies with curvature. Step size is small when curvature is large (more likely to deviate from approximation arc). updated minimum step size for approx_bezier and bezier_inflection to a more reasonable 0.001 instead of RT_LEN_TOL >> >> Modified Paths: >>  >> brlcad/trunk/src/librt/primitives/sketch/sketch_tess.cpp >> >> Modified: brlcad/trunk/src/librt/primitives/sketch/sketch_tess.cpp >> =================================================================== >>  brlcad/trunk/src/librt/primitives/sketch/sketch_tess.cpp 20120719 04:53:52 UTC (rev 51584) >> +++ brlcad/trunk/src/librt/primitives/sketch/sketch_tess.cpp 20120719 06:42:39 UTC (rev 51585) >> @@ 91,6 +91,7 @@ >> HIDDEN bool >> bezier_inflection(const ON_BezierCurve& bezier, fastf_t& inflection_pt) >> { >> + int sign; >> fastf_t t, step, crv; >> ON_3dVector d1, d2; // first derivative, second derivative >> ON_3dPoint tmp; // not used, but needed by Ev2Der >> @@ 99,10 +100,10 @@ >> bezier.Ev2Der(0, tmp, d1, d2); >> crv = CURVATURE(d1, d2); >> // maximum step size is 0.1, but decreases as crv > 0 with minimum step >>  // size RT_LEN_TOL >>  step = fabs(crv) > 0.1 ? 0.1 : (fabs(crv) < RT_LEN_TOL ? RT_LEN_TOL : fabs(crv)); >> + // size 0.01 >> + step = fabs(crv) > 0.1 ? 0.1 : (fabs(crv) < 0.01 ? 0.01 : fabs(crv)); >> >>  int sign = SIGN(crv); >> + sign = SIGN(crv); >> >> for (t = step; t <= 1.0; t += step) { >> bezier.Ev2Der(t, tmp, d1, d2); >> @@ 112,7 +113,7 @@ >> inflection_pt = t; >> return true; >> } >>  step = fabs(crv) > 0.1 ? 0.1 : (fabs(crv) < RT_LEN_TOL ? RT_LEN_TOL : fabs(crv)); >> + step = fabs(crv) > 0.1 ? 0.1 : (fabs(crv) < 0.01 ? 0.01 : fabs(crv)); >> } >> return false; >> } >> @@ 127,17 +128,24 @@ >> approx_bezier(const ON_BezierCurve& bezier, const ON_Arc& biarc, const struct bn_tol *tol, std::vector<ON_Arc>& approx) >> { >> fastf_t t, step = 0.1; >>  fastf_t err, max_t, max_err = 0.0; >> + fastf_t crv, err, max_t, max_err = 0.0; >> ON_BezierCurve head, tail; >> + ON_3dPoint test; >> + ON_3dVector d1, d2; >> >> // walk the bezier curve at interval given by step >> for (t = 0; t <= 1.0; t += step) { >>  err = fabs((bezier.PointAt(t)  biarc.Center()).Length()  biarc.Radius()); >> + bezier.Ev2Der(t, test, d1, d2); >> + err = fabs((test  biarc.Center()).Length()  biarc.Radius()); >> // find the maximum point of deviation >> if (err > max_err) { >> max_t = t; >> max_err = err; >> } >> + crv = CURVATURE(d1, d2); >> + // maximum step size is 0.1, but decreases as crv > 1 with minimum step >> + // size 0.01 >> + step = 1.0  fabs(crv) > 0.1 ? 0.1 : (1.0  fabs(crv) < 0.01 ? 0.01 : 1.0  fabs(crv)); >> } >> >> if (max_err + VDIVIDE_TOL < tol>dist) { >> @@ 225,6 +233,7 @@ >> } while (!rest.empty()); >> } >> >> + >> #define SKETCHPT(idx) sketch_ip>verts[(idx)] >> >> HIDDEN inline fastf_t >> >> This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. >> >> >>  >> Live Security Virtual Conference >> Exclusive live event will cover all the ways today's security and >> threat landscape has changed and how IT managers can respond. Discussions >> will include endpoint security, mobile security and the latest in malware >> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ >> _______________________________________________ >> BRLCAD Source Commits mailing list >> brlcadcommits@... >> https://lists.sourceforge.net/lists/listinfo/brlcadcommits > >  > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > BRLCAD Developer mailing list > brlcaddevel@... > https://lists.sourceforge.net/lists/listinfo/brlcaddevel > 