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
> <mailto: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
> <mailto: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
> <mailto: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
> <mailto: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
> <mailto: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
> <mailto: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
> <mailto: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
> <http://sdm.link/slashdot>
> _______________________________________________
> BRL-CAD Developer mailing list
> brlcad-devel@lists.sourceforge.net <mailto:brlcad-devel@lists.sourceforge.net>
> https://lists.sourceforge.net/lists/listinfo/brlcad-devel
> <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
> <http://sdm.link/slashdot>
> _______________________________________________
> BRL-CAD Developer mailing list
> brlcad-devel@lists.sourceforge.net <mailto:brlcad-devel@lists.sourceforge.net>
> https://lists.sourceforge.net/lists/listinfo/brlcad-devel
> <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
> <http://sdm.link/slashdot>
> _______________________________________________
> BRL-CAD Developer mailing list
> brlcad-devel@lists.sourceforge.net <mailto:brlcad-devel@lists.sourceforge.net>
> https://lists.sourceforge.net/lists/listinfo/brlcad-devel
> <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_______________________________________________
> <http://sdm.link/slashdot_______________________________________________>
> BRL-CAD Developer mailing list
> brlcad-devel@lists.sourceforge.net <mailto:brlcad-devel@lists.sourceforge.net>
> https://lists.sourceforge.net/lists/listinfo/brlcad-devel
> <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
