> On Aug 30, 2017, at 6:38 AM, Mario Meissner <mr.rash....@gmail.com> wrote:
>
> Implemented the mentioned changes and fixed projections not being skipped
> correctly when they should. Unless my next tests fail, I think this version
> is quite stable.
>
> Code attached.
>
> In this test:
> https://puu.sh/xn8Hh/0d5c617dfe.png <https://puu.sh/xn8Hh/0d5c617dfe.png>
Can you diagram out what that test is supposed to look like? Not sure I can
quickly follow what the debug print statements line up with without some
tedious reconstruction.
> The reason why I worked on projections is because you told me to do so:
The devil is always in the details is it not? :) Projections are/were fine
for 2 points but then it simply didn’t generalize without needing additional
consideration. I think it still holds for any 2 points piecewise. The issue
is the N-point generalization, which you did find an interesting case that
required adjustment. That’s a good thing!
> Not the distance between points, but distance to their transition vectors.
> From the prior e-mail, the way this should fully generalize can be handled by
> projecting points onto the ray, and projecting any transition vectors onto
> the ray. Then for a given ray, it can fully handle just about any transition
> type.
>
> To see how this will work, it will likely be necessary to redo rtexample and
> get 2-points working without any vectors. You project each point onto the
> ray.
>
> ptA ptB
> | |
> IN v v OUT
> ray o--ptA'----ptB'---o
>
> Density from IN to ptA’ is density(ptA).
> Density from ptB’ to OUT is density(ptB).
> Density from ptA’ to ptB’ is density(ptA) until the midpoint between ptA’ and
> ptB’. Thus the section’s average density would be density(ptA)/2 +
> density(ptB)/2But
>
> But I now realize as well that taking the mid-point between projections does
> not give us the actual boundary between the polygons.
The midpoint was specific to the ptA/ptB case setup, for understanding, not to
suggest it always works out that way as the midpoint.
> We could work with the mesh like you mention, or we could do a slight
> modification to the current code to compute the actual boundaries while
> walking through the points (probably our already available projections, we'll
> see). It's probably a simple trigonometry problem, and I'll try to come up
> with the operation we need to do to obtain the boundaries in a segment.
If you do/did sort this out, I absolutely agree that it’d be a superior
solution.
Cheers!
Sean
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
BRL-CAD Developer mailing list
brlcad-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/brlcad-devel
