Hi!
I forgot to mention it before leaving. I went on a spontaneous trip to
Prage for a few days. I will be back with more updates on monday.
Mario.
On 25 September 2017 at 13:13, Mario Meissner <mr.rash....@gmail.com> wrote:
> Attached goes new code with the changes I mentioned. Only tested once on a
> simple case.
> Should give you an idea of what I meant with Saturdays mail.
> Feedback is as always very welcome.
>
> I will now test it more thoroughly and then move on to revamp the first
> step too, which is severely flawed still.
> I have yet to come up with a more elegant way of checking which 'tiles'
> our segment will cross and which not.
>
> Back with more tomorrow.
> Mario.
>
> On 23 September 2017 at 20:20, Mario Meissner <mr.rash....@gmail.com>
> wrote:
>
>> Hello everyone.
>>
>> I wrote this on my log a few hours ago but I thought it's a good idea to
>> go into more detail here since it's major change in direction.
>>
>> First, I will get rid of the projection structure, which is now just a
>> contribution. Its projection is now just something secondary that can be
>> used to predict if we need to skip the point or not.
>>
>> So, my new approach will be clearly separated into three steps:
>> -Create a list of contributions. This stage is completely recycled from
>> my current code, and for now the methodology to detect points that will
>> contribute to our segment will remain the same. It will be the weakest part
>> of the implementation once this major revamp is done, and may require some
>> work.
>> -Compute the boundaries between the contributions. This means computing
>> when each contribution starts and ends within the segment. They are stored
>> inside the contribution structure.
>> -Loop through the contributions and take average density proportional to
>> how big each intersection is.
>>
>> Notice how much simpler the average_density computation is now. Stage two
>> is also simple because I have already implemented the intersection function.
>>
>> As this is a major change it will take me a few days to implement. I've
>> spent most of my time today to refactor step 1 to use contributions instead
>> of projections. I hope by tomorrow I can send an in-progress version with
>> some cases working.
>>
>> I really think this new version cleans up the mess quite a lot,
>> simplifies the concepts, makes it all more readable, and most importantly,
>> will support more situations than before, removing several flaws.
>>
>> Mario.
>>
>> On 23 September 2017 at 18:01, Mario Meissner <mr.rash....@gmail.com>
>> wrote:
>>
>>> 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.
>>>> 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?
>>>>
>>>
>>> I guess I should just do the same I did with intersection, since in the
>>> end it's the same issue.
>>>
>>> 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 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
