On Tue, Jun 14, 2016 at 9:11 PM, Vasco Alexandre da Silva Costa <
vasco.co...@gmail.com> wrote:
> On Tue, Jun 14, 2016 at 9:10 AM, Param Hanji <param.catchch...@gmail.com>
> wrote:
>
>> Yup, I did all of that and still same error. I copied every individual
>> field of seg_in and seg_out separately.
>>
>> Just a thought. Shouldn't we be dealing with a 2D array here. The weaving
>> is done for every pixel and input to weave function is a list of segments.
>> But I only have a single array to work with, which translates to one seg
>> per pixel - which is fine for only primitives I suppose, but not for
>> complex objects.
>>
>> Do I have to change this?
>>
>
> There are two code paths in OpenCL librt:
> - One code path only returns the segments of the first intersected
> primitive. At most one segment for something like a sphere, at most two
> segments for something like a torus.
> - The other path returns all the segments of all the primitives along the
> ray. You can enable this with the 'rt' command line options "-z1 -l5".
>
> You basically want to use the latter code path, i.e. '-z1 -l5', for the
> boolean weaving mode.
> All the segments for an entire frame (i.e. all the pixels) are stored in
> the 'psegs' variable, in device (e.g. GPU) memory, as a linearized 2D array
> of 1D arrays. To know the range indexes for a given pixel you can access
> the offset array 'h' thus: segments(x,y) -> h[y*width+x]..h[y*width+x+1].
>
> So you can copy 'psegs' to CPU memory e.g. into a variable named 'segs'
> then traverse it like this:
> for (i=0; i<width*height; i++) { /* iterate over all pixels */
> for (j=h[y*width+x]; j<h[y*width+x+1]; j++) { /* iterate over all
> segments in a pixel */
> seg = segs[j];
> }
> }
>
Duh. I meant:
You can copy 'psegs' to CPU memory e.g. into a variable named 'segs' then
traverse it like this:
for (i=0; i<width*height; i++) { /* iterate over all pixels */
for (j=h[i]; j<h[i+1]; j++) { /* iterate over all segments in a pixel */
seg = segs[j];
}
}
>
> If you have more doubts about this we can schedule an IRC session this
> week.
>
The offer still stands. :-)
>
> Regards,
>
>
>
>> On Sat, Jun 11, 2016 at 7:16 PM Vasco Alexandre da Silva Costa <
>> vasco.co...@gmail.com> wrote:
>>
>>> On Sat, Jun 11, 2016 at 8:42 AM, Param Hanji <param.catchch...@gmail.com
>>> > wrote:
>>>
>>>> Also I'm having trouble creating the double linked list of segments. I
>>>> followed the documentation at include/bu/list.h and created the list as
>>>>
>>>> BU_LIST_INIT(&waiting_segs.l);
>>>> temp_seg = (struct seg*)bu_malloc(sizeof(struct seg), "Temporary
>>>> pointer to segment");
>>>> for(i=0; i<num_segs; i++) {
>>>> copy_seg(temp_seg, &segs[i]);
>>>> BU_LIST_INSERT(&(waiting_segs.l), &(temp_seg->l));
>>>> }
>>>>
>>>> Here copy_seg() transfers each data member individually.
>>>>
>>>> However this gives the following error.
>>>>
>>>> ERROR: bad pointer 0x3490f70: s/b struct seg(x98bcdef1), was
>>>> Unknown_Magic(x45b878e8)
>>>>
>>>>>
>>>>> Well if I understand it correctly you are allocating a single memory
>>>>> block and then overriting it num_segs times. That's why it doesn't work.
>>>>> You should allocate one memory memory block per 'struct seg' node. In
>>>>> this case moving the malloc inside the for loop should work.
>>>>>
>>>>> Moving it inside the for loop did help by properly copying the in_hit
>>>> and out_hit information, but the bad pointer error persists. This is
>>>> generated by line 41 of bu_badmagic() in src/libbu/badmagic.c. I
>>>> temporarily enabled NO_BOMBING_MACROS and the weaving process completed (I
>>>> think). I can only test this after boolfinal().
>>>>
>>>
>>> There is probably something wrong in copy_seg(). Copy all the data
>>> fields (seg_in, seg_out, seg_stp) and initialize the list field (l) with
>>> BU_LIST_INIT().
>>>
>>>
> --
> Vasco Alexandre da Silva Costa
> PhD in Computer Engineering (Computer Graphics)
> Instituto Superior Técnico/University of Lisbon, Portugal
>
--
Vasco Alexandre da Silva Costa
PhD in Computer Engineering (Computer Graphics)
Instituto Superior Técnico/University of Lisbon, Portugal
------------------------------------------------------------------------------
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are
consuming the most bandwidth. Provides multi-vendor support for NetFlow,
J-Flow, sFlow and other flows. Make informed decisions using capacity planning
reports. http://pubads.g.doubleclick.net/gampad/clk?id=1444514421&iu=/41014381
_______________________________________________
BRL-CAD Developer mailing list
brlcad-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/brlcad-devel
