Hi Sean.
It's the same test as in my third email from this thread. I added one extra
point that should be more far away and thus be ignored.
I'll perform more thorough tests once I'm set up here, but I have no
scanner to make diagrams. I'll do my best to represent it through text.
Mario.

On Sep 1, 2017 09:58, "Christopher Sean Morrison" <brl...@mac.com> wrote:

>
> 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
>
>
> 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
>
>
------------------------------------------------------------------------------
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

Reply via email to