After considering a dozen of different options, I think I may have found
one solution that doesn't involve too much rewriting. However I have this
bugging feeling that it might still not cover 100% of the cases and we will
just continue on and on adding 'fix' code that ends up cluttering up
everything. I seriously hope this is not the case. If it keeps happening we
will need to step back and take a different path.
Anyway, my thought was that, if we find a skip candidate, we do the
following to check if its a false positive or not:
Take the current user_point and the previous one, and connect them. Now
draw the perpendicular bisector, and find the intersection with our ray. If
this intersection point has a user_point closer to it than our current
user_point, then it means we will never cross the region of our current
point (because both at the projection point and at this other intersection
point we find closer points than this one). If there is no closer point, so
this means that our current user_point AND the previous user_point are the
closest to the intersection. Thus, once the ray crosses the intersection
point, it will inevitably enter the region of our current user_point.
Of course, we will also need to check that the intersection lays inside the
limits of the segment, otherwise the region may actually exist but is too
far away (farther than in or out points) and thus we will not reach it.
We could also make use of these intersections and actually save them to use
them for the boundary calculation phase, replacing my current equation. We
can think about it later.
I will start working on this unless you think there is a superior approach
to this.
Mario.
On 6 September 2017 at 17:33, Mario Meissner <mr.rash....@gmail.com> wrote:
> 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
