Hello Sean,
I wonder if I should continue working on rtweight now, or if the report can
be written with the code in the current state.
If so, we would need to discuss what changes should come next, and how.
Thanks,
Mario.
On 15 October 2017 at 19:58, Mario Meissner <mr.rash....@gmail.com> wrote:
> Hello again!
>
> Well, 'today' turned into 'tomorrow' but here I am again with good news.
> I managed to successfully implement my work into viewweight.
>
> User can input an arbitrary amount of points (in g/cm3) to generate a
> voronoi mesh and program will return the total mass of the material in kg.
>
> Obviously, now maybe 20% of the code inside viewweight is useless or wrong
> for the current implementation, but the main operation works (getting the
> mass of an object assuming only one material, who's density distribution is
> defined through the point mesh). Anything related to the density file right
> now is unused (we might wanna use it to store the points?). Some of the
> printf happening in the end is now wrong since we are not using
> per-material densities nor are we using a density table.
>
> Anyway, what changes should be carried out from now on still would need to
> be discussed.
>
> Code attached!!!
>
> Mario Meissner.
>
> On 14 October 2017 at 08:12, Mario Meissner <mr.rash....@gmail.com> wrote:
>
>> 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://sd
>>> m.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
