On Tue, Apr 23, 2013 at 1:41 PM, phoenix <284281...@qq.com> 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
------------------------------------------------------------------------------
Try New Relic Now & We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service
that delivers powerful full stack analytics. Optimize and monitor your
browser, app, & servers with just a few lines of code. Try New Relic
and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr
_______________________________________________
BRL-CAD Developer mailing list
brlcad-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/brlcad-devel
