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
