Hello everyone.
I received an email from the SOCIS organizer saying that the coding period
is finishing really soon. However I haven't received any news from your
side. What is gonna happen now? Can we (and will we if so) extend it any
further? I would be able to continue, but in an intermittent basis. This
week I will integrate my code into rtweight.
Mario
On Oct 9, 2017 11:05, "Mario Meissner" <mr.rash....@gmail.com> wrote:
> Hi people!
>
> I proudly present my latest work, attached here. It features a clean
> algorithm to compute the average density of a segment that goes through a
> cloud of density regions arranged in a Voronoi Tesselation. For now
> confirmed to work for one and two point cases, but I suppose only minor
> bugs will hinder it from properly handling any arbitrary amount of points.
>
> Note that it still requires some refactoring and cleaning since there are
> some remains of the old code laying around.
>
> The last step would be to integrate this into rtweight, which shouldn't be
> too much of a problem.
>
> As always, feedback welcome.
>
> Thank you,
> Mario.
>
>
>
> On 6 October 2017 at 19:41, Mario Meissner <mr.rash....@gmail.com> wrote:
>
>> Hi Daniel,
>> thank you! In the end the problem was that I didn't run cmake after svn
>> up.
>>
>> Attached goes today's work. I coded the function 'region_boundary()'
>> which is an upgrade to the now unused intersection(). It does the same
>> thing but now also checks if the intersection point lays inside or outside
>> the segment, AND if the intersection is a valid region boundary or not (by
>> checking distances to all other points, something I was doing outside of
>> the intersection call until now). All in all a much cleaner function that
>> will allow stages 1 and 2 to be much simpler and possibly run in one single
>> loop.
>>
>> On Sunday I will probably finish implementing my new algorithm (which is
>> now trivial since the hard work was this function).
>>
>> Note that current code is only meant to be a testing platform for the new
>> function. On line 386 I included a snippet that calls my new function and
>> prints its results, then I break out with a return. Feel free to try out
>> some new intersections. Currently I tested with three points, first one
>> ignored, and the second and third ones acting as 'previous' and 'current'
>> respectively.
>>
>> Cheers!
>>
>> On 6 October 2017 at 17:41, Daniel Roßberg <danielmrossb...@gmail.com>
>> wrote:
>>
>>> spectrum.c was recently removed. So, update your checked out sources
>>> and check your librt CMakeaLists.txt that it matches with the one on the
>>> head of the reposity (you've probably made changes to it).
>>>
>>> Regards,
>>> Daniel
>>>
>>> Am 06.10.2017 5:27 nachm. schrieb "Mario Meissner" <
>>> mr.rash....@gmail.com>:
>>>
>>>> I am getting compilation errors again, on 70355.
>>>>
>>>> fatal error C1083: Cannot open source file:
>>>> 'C:\Users\MEISSNERBLANCOJOHANN\Desktop\brlcad\trunk2\src\librt\spectrum.c':
>>>> No such file or directory
>>>>
>>>> And indeed no such file exists (I cannot find it anywhere).
>>>>
>>>> Hints? :/
>>>>
>>>> On 4 October 2017 at 23:14, Mario Meissner <mr.rash....@gmail.com>
>>>> wrote:
>>>>
>>>>> So I ended up designing a new algorithm and would love to get some
>>>>> feedback before I implement it.
>>>>> Here it goes:
>>>>>
>>>>> * Sort the points from 'left to right' (distance of projection to
>>>>> inhit)
>>>>> * Look for the closest point to inhit.
>>>>> * Add this point to the list of contributions.
>>>>> * Discard every point 'to the left' of this point.
>>>>> * From the next point onwards, do, for each point:
>>>>> * Take the next point and the last one we added to contributions
>>>>> * Check if the intersection of their middle-plain and the segment
>>>>> lays inside the segment and
>>>>>
>>>>> has no closer point than the two we are using..
>>>>> * If so, this point's region is crossed by the segment, so we add it
>>>>> to the contribution list.
>>>>> * If not, then this point's region is not crossed.
>>>>> * Look for the closest point to the outhit.
>>>>> * If this point is the same as the last point we added, finish.
>>>>> * If not, add it and finish.
>>>>>
>>>>> Attached go three pics that are a sample of the example situations I
>>>>> used to develop the algorithm.
>>>>> Ideally, I would need someone to find a situation where this algorithm
>>>>> fails.
>>>>>
>>>>> Thank you in advance,
>>>>> Mario.
>>>>>
>>>>> On 3 October 2017 at 04:14, Christopher Sean Morrison <brl...@mac.com>
>>>>> wrote:
>>>>>
>>>>>>
>>>>>> Hi Mario,
>>>>>>
>>>>>> As always, thank you for all the updates. Here are some responses to
>>>>>> questions you posted last week.
>>>>>>
>>>>>> I'm passing two arguments to my segment_density, which are inhit and
>>>>>>> outhit points.
>>>>>>> I now realize that these are pointers and could change unexpectedly
>>>>>>> within the call if we run multiple threads.
>>>>>>>
>>>>>>
>>>>>> The in/out hit point pointers shouldn’t be changing within the call.
>>>>>> I suspect something else is going on...
>>>>>>
>>>>>> How can I make this safe? Should I BU_GET safe heap memory to store
>>>>>>> the points for the call, or pass the coordinates one by one as actual
>>>>>>> numbers?
>>>>>>>
>>>>>>
>>>>>> In general, the calling code should pass structures to functions
>>>>>> (which can be on the heap or on the stack) and those functions should
>>>>>> just
>>>>>> fill them in or read from them (but not both, separate functions for
>>>>>> reading and writing).
>>>>>>
>>>>>> For debugging purposes I would like to set only one thread for
>>>>>> rtweight, how can I do that? The fact that I get 4 or more threads
>>>>>> running
>>>>>> my segment_density at the same time makes it difficult to track down
>>>>>> issues.
>>>>>>
>>>>>>
>>>>>> Check out rtweight’s manual page (run "brlman rtweight” outside
>>>>>> mged), it’s the -P# option.
>>>>>>
>>>>>> 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
>>>>
>>>>
>>> ------------------------------------------------------------
>>> ------------------
>>> 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
