Hi Sean,
Thank you for the update! I will come back with more changes today.
Cheers!
On Oct 13, 2017 21:02, "Christopher Sean Morrison" <brl...@mac.com> wrote:
> Hey Mario,
>
> That’s looking good. You don’t have anything to worry about. The past
> month has been solid effort.
>
> I talked with Adam yesterday and gave him an update and ETA on the report.
>
> Cheers!
> Sean
>
> On Oct 13, 2017, at 11:42 AM, Mario Meissner <mr.rash....@gmail.com>
> wrote:
>
> Hello again!
>
> Attached code is cleaner and more thoroughly tested.
> This is what I will implement into rtweight, which shouldn't be a too
> difficult task.
> I hope to be able to come back to you with rtweight changes tomorrow.
>
> Adam, the coordinator for SOCIS, contacted me again urging us to finish
> the report for me as soon as possible.
> I haven't heard much feedback about my progress in my last month of
> coding, which left me a bit uncertain. I hope we reached a decent milestone
> by now. We should get back to Adam as soon as possible with the report.
>
> Greetings,
> Mario.
>
> On 11 October 2017 at 09:52, Mario Meissner <mr.rash....@gmail.com> wrote:
>
>> 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
>>>>>
>>>>>
>>>>
>>>
> <rtexample.diff>--------------------------------------------
> ----------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org <http://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
