Hello everyone.
Im currently working on what I consider to be the biggest challenge of the
current implementation. This is step one of my previously described
three-step plan. Basically, what we need to do is loop through all points
and for each one decide if its cell is crossed by the segment or not. This
is a big challenge and although I have already tried a few implementations
none of them are clean and precise (nor do they cover all cases).
Note that I have also considered computing the whole mesh first and then
just looking for intersections, but this task is even more complex than
mine. Some algorithms exist for 2D mesh computation but not much is
available for 3D, due to its difficulty. Also, I wouldn't know how to
represent the final mesh structure either.
If anyone has an idea for an algorithm that would solve this problem, I
would be really grateful if you could share it.
This algorithm would be the last piece of the puzzle to finish off the
project.
Mario.
On Oct 1, 2017 16:23, "Mario Meissner" <mr.rash....@gmail.com> wrote:
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
