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
