Hello everyone!
I'm facing a wall. I need to find a perpendicular vector with the condition
that it will intersect a third vector.
Basically, I have the ray and a vector drawn from my current point to the
previous point.
I want the perpendicular bisector of that vector to cross my ray, so that I
can obtain the intersection between the bisector and the ray.
For that I need two things:
1) Obtain the perpendicular vector. in 3D there are infinite options, but
only one will cross the ray. How do I get the one I need?
2) Obtain the intersection point.
I browsed through vmath.h but I didn't find anything that could help me. Do
you know any macro that could be useful here?
Otherwise I will need to make some of my own for this! If so, any ideas on
how to approach it?
Mario.
On 6 September 2017 at 18:39, Mario Meissner <mr.rash....@gmail.com> wrote:
> 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
