Hey Sean!
I identified the reason why the first projection was skipped when it
shouldn't have.
The first projection that my code works on is the last one (with value 9)
in my diagram because of the nature of the bu_list stack nature.
I approached skipping projections with the following procedure: If we find
a point that is closer to our projection than its original is, then the
projection does not need to be made. This seemed logical in our little
color diagram I made a few weeks back. However if we look at my new test
case, projection of point 9 happens to fall inside the region 8 (point 8 is
closer to it than the actual point 9). We DO however need point 9 to be
projected because we are going to cross the region 9.
I believe that if we correctly project 9 onto the segment then the result
will be correct since 9 is heavier and its the last 0.20 we need to reach
7.25. These cases should be correctly handled by my later boundary
calculation formula, so it should suffice to find a better projection
skipping method. I'm however struggling to find one.
Do you have any suggestions?
Mario.
On 5 September 2017 at 22:52, Mario Meissner <mr.rash....@gmail.com> wrote:
> Hello again!
> Now that things are working on the Ubuntu subsystem, I could start with
> the tests.
> I came up with this one test that is supposed to cover some of the
> complicated scenarios, and calculated the result by hand, then threw the
> points into my voronoi code.
>
> We have five points, values 5 to 9, from left to right. Some are 100mm
> away from the ray, some are 250mm away. Cell regions have been drawn as
> well, to see how much of each cell the ray sees.
> We agree that the result should be 7.25, right?
>
> Code returns 7.05. Which is off. Not TOO off, but still not accurate. I
> will need to track this issue down. In fact I already suspect that the
> problem is the line between 8 and 9. It cuts our ray to the right of point
> 9, but I don't think I properly took care of this case in my code yet.
> It also said its skipping two projections when it should only be skipping
> one.
>
> Mario.
>
> On 2 September 2017 at 10:58, Mario Meissner <mr.rash....@gmail.com>
> wrote:
>
>> 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
