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
