Re: [brlcad-devel] Enthusiastic about working with BRL-CAD in GSoC2013
Open Source Solid Modeling CAD
Brought to you by:
brlcad
From: Clifford Y. <cli...@gm...> - 2013-04-24 02:36:57
|
On Tue, Apr 23, 2013 at 1:41 PM, phoenix <284...@qq...> wrote: > Hi, > > I will still take some time to think further about this, and update my > proposal (maybe a lot) in a few days. > > I have updated my proposal at: > http://brlcad.org/wiki/User:Phoenix/GSoc2013/Proposal > > In my new proposal, I emphasis more about tests and verification, and the > goal is to make the surface-surface intersection routine robust to deal > with all inputs. > > I'd like to write a test program in a few days to test the current SSI > implementations. Two options come to mind - one is to write a text-based > interface program that can test several cases one after another, and the > other is to write a shell script to invoke MGED to display the result > graphically, but can only test one case at a time. So maybe I will > implement both of them. Are there any better suggestions on the tests? > Thank you. > Sean may have a better approach, but FWIW my thought on testing would be to have a series of test programs, geared for the various cases (P/P, P/C, C/C, C/S, etc.) that can accept a 3dm file or a .g file defining test cases, and allow the specification of specific inputs for a given test. (There's a somewhat related example in src/librt/tests, but part of me is inclined to suggest using 3dm files for these tests so we don't introduce an unnecessary librt dependency... the problem is that involves cobbling together the ability to create basic 3dm files, as well as reading them in. It may be better to just go with a .g based test setup now, and convert it later if it proves useful to do so.) So, for example, let's take the C/C intersection cases - if you have a 3dm file (or a .g file, but we'll use 3dm for the example) that defines curves c1 and c2 which are defined in such a way that they are known to share a subset curve, and c1_c2 holds the corresponding intersection that is the known "correct" answer, you could define a test that runs: <builddir>/src/libbrep/tests/cci_tester curves.3dm c1 c2 c1_c2 If the intersection of c1 and c2 produces c1_c2, the test succeeds, otherwise it fails. Similarly, if you have another curve c3 in the 3dm file that intersects at a single point c1_c3 with c1, you could then define another test: <builddir>/src/libbrep/tests/cci_tester curves.3dm c1 c3 c1_c3 In this fashion, you could add more and more test cases to the curves.3dm file, and corresponding tests that check those specific cases. Similarly, for P/C intersections: <builddir>/src/libbrep/tests/pci_tester curves.3dm c1 p1 c1_p1 and so on for the other cases. There's another aspect to this intersection question that might be worth investigating - earlier versions of opennurbs contained a header opennurbs_x.h that defined a ON_X_EVENT class to be used to report C/C and C/S intersections. It has been removed from opennurbs in newer versions, but the older version may provide some useful hints about how to structure and handle intersection data. Cliff |