The code is simply walking the list. It ignores the nodes with 'deleted'
mode on.
Also, for the second evaluation, do I submit an incomplete patch or submit
later after completing?
On Thu, Jul 5, 2018 at 8:23 PM Vasco Alexandre da Silva Costa <
vasco.co...@gmail.com> wrote:
> PS: Does the BREP code do indexed accesses to the data structure or does
> it simply walk the list?
>
> On Thu, Jul 5, 2018 at 3:40 PM, Vasco Alexandre da Silva Costa <
> vasco.co...@gmail.com> wrote:
>
>> Instead of deleting items with 'delete' or 'free' simply add a 'deleted'
>> bit to the nodes and set or reset it depending if the node is used or not.
>> Then when walking the list, add an 'if' check to ignore the nodes with
>> the 'deleted' bit on. Or you can move the 'deleted' nodes into a free nodes
>> list.
>>
>> This is a technique often used on lazy memory allocation/de-allocation
>> algorithms and with node memory pools.
>>
>> On Wed, Jul 4, 2018 at 5:45 PM, Sreyansh Jain <sreyanshjai...@gmail.com>
>> wrote:
>>
>>> Hi,
>>>
>>> I've converted most of the 'rt_brep_shot' code to C and some of it to
>>> OpenCL already.
>>>
>>> I wanted to know the best way to implement the *erase* function. I've
>>> taken 'hits' as pointer to array (*struct brep_hit *hits;*). While
>>> *begin* and *end* are easily implemented, I'm stuck at direct
>>> implementation of *erase*.
>>>
>>>
>>>
>>> Warm Regards,
>>>
>>> Sreyansh
>>>
>>>
>>> On Thu, Jun 21, 2018 at 9:19 PM Vasco Alexandre da Silva Costa <
>>> vasco.co...@gmail.com> wrote:
>>>
>>>> Basically the game plan to tackle NURBS I can think of is the one I
>>>> sent to the list on March 20th:
>>>>
>>>> "With regards to BREP support, that should be more complex, since, for
>>>> one, that is coded in C++ and also uses an auxiliary library also in C++.
>>>> In order to run that on OpenCL 1.2 you would likely need to port C++
>>>> parts of the library to OpenCL/C, including the generic ray-BREP
>>>> intersection code, and the primitive-BREP conversion functions for any
>>>> primitives you need to support.
>>>>
>>>> It should also be possible, as a first step, to basically just make a
>>>> function that serializes the NURBS surfaces, etc, of the BREP form of
>>>> the primitive, pass that serialized form to the GPU, and then port just the
>>>> generic ray-BREP intersection code, rather than doing the whole BREP
>>>> conversion on the OpenCL side as well. i.e. serialize just the 'ON_Brep *'
>>>> of the primitives, then pass that to the OpenCL side which then performs
>>>> the actual intersections.
>>>>
>>>> For example, this is the Ellipsoid->BREP conversion function: (you need
>>>> to serialize and send to OpenCL the output of this)
>>>>
>>>> https://svn.code.sf.net/p/brlcad/code/brlcad/trunk/src/librt/primitives/ell/ell_brep.cpp
>>>>
>>>> It outputs the 'ON_Brep *' for that primitive.
>>>>
>>>> This contains the generic ray-BREP intersection function
>>>> 'rt_brep_shot': (what you need to convert to OpenCL)
>>>>
>>>> https://svn.code.sf.net/p/brlcad/code/brlcad/trunk/src/librt/primitives/brep/brep.cpp
>>>>
>>>> In case you decide to tackle this, it is probably best to first make a
>>>> simplified ANSI C version of 'rt_brep_shot' since that should be easier to
>>>> port to OpenCL/C."
>>>>
>>>>
>>>> On Thu, Jun 21, 2018 at 2:35 PM, Christopher Sean Morrison <
>>>> brl...@mac.com> wrote:
>>>>
>>>>> Sreyansh,
>>>>>
>>>>> rt_brep_prep() and rt_brep_shot() are the entry points for BREP/NURBS
>>>>> ray tracing. They use the openNURBS toolkit for data structures and our
>>>>> libbrep library for surface evaluation. That’s currently a very
>>>>> complicated C/C++ interaction between librt, libbrep, and openNURBS.
>>>>>
>>>>> Vasco may have a better idea, but what may make sense is to extract
>>>>> all of the evaluation functions in openNURBS used by rt_brep_shot() into
>>>>> libbrep. Then you'll only have to concern yourself with OpenCL code in
>>>>> one
>>>>> place and not worry about openNURBS for ray tracing — it would only be
>>>>> used
>>>>> for import/export (reading from and writing to disk).
>>>>>
>>>>> As for examples, openNURBS is the 3DM file format. So that means you
>>>>> can import a 3DM model (e.g., from GrabCAD or Google searches). You could
>>>>> also just use our db/nist examples.
>>>>>
>>>>> Cheers!
>>>>> Sean
>>>>>
>>>>>
>>>>> On Jun 21, 2018, at 4:55 AM, Sreyansh Jain <sreyanshjai...@gmail.com>
>>>>> wrote:
>>>>>
>>>>> Hi,
>>>>>
>>>>> Can you give me a detailed procedure with examples on what exactly to
>>>>> do for BREP support? Right now, I'm converting the rt_brep_shot() function
>>>>> from C++ to C since that would be easy to port to OpenCL/C.
>>>>>
>>>>>
>>>>> On Sat, Jun 16, 2018 at 3:07 AM Sreyansh Jain <
>>>>> sreyanshjai...@gmail.com> wrote:
>>>>>
>>>>>> Also, I've worked it out that after installing Ubuntu 16.04, apart
>>>>>> from the dependencies mentioned in https://brlcad.org/wiki/Compiling,
>>>>>> you need to install package* libgl1-mesa-dev *for opengl support.
>>>>>> It's working for me now in Ubuntu 16.04 as well. Can you check once and
>>>>>> update?
>>>>>>
>>>>>> On Sat, Jun 16, 2018 at 2:16 AM Sreyansh Jain <
>>>>>> sreyanshjai...@gmail.com> wrote:
>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> @Vasco: Thank you for the first evaluation results and feedback. I'm
>>>>>>> done with both the METABALL and PIPE shot routines. I'm unable to do do
>>>>>>> OpenCL kernels for memory size computation for bu_lists/arrays and
>>>>>>> allocation. Any previous example which I can refer to?
>>>>>>>
>>>>>>> @Sean: I deployed the superell patch in my local system, but results
>>>>>>> were not showing up. I'm sure they don't have any unintended changes.
>>>>>>> I've
>>>>>>> checked my code thoroughly. It should be my local installation problem.
>>>>>>> Can
>>>>>>> you check and let me know if it's working?
>>>>>>>
>>>>>>> On Fri, Jun 8, 2018 at 1:14 AM Christopher Sean Morrison <
>>>>>>> brl...@mac.com> wrote:
>>>>>>>
>>>>>>>> Sorry to hear your system crashed. Good job backing up your data.
>>>>>>>> We need to get you set up so you are able to directly save changes as
>>>>>>>> you
>>>>>>>> go.
>>>>>>>>
>>>>>>>> Have you made sure your changes still apply to trunk? You should
>>>>>>>> manually inspect it also to make sure it doesn’t have unintended
>>>>>>>> changes.
>>>>>>>> If you have, I may be able to test it later today.
>>>>>>>>
>>>>>>>> Thank you for letting us know!
>>>>>>>>
>>>>>>>> Cheers!
>>>>>>>> Sean
>>>>>>>>
>>>>>>>> On Jun 6, 2018, at 5:54 PM, Sreyansh Jain <sreyanshjai...@gmail.com>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>> Hey,
>>>>>>>>
>>>>>>>> My system crashed. While I've had the backup of most of the files,
>>>>>>>> the very recent ones got lost. I wanted to inform that my work will be
>>>>>>>> a
>>>>>>>> bit slowed for few days while I'll be working on my friend's laptop
>>>>>>>> and get
>>>>>>>> mine fixed.
>>>>>>>>
>>>>>>>> Also, did you check whether there's problem with my superell patch
>>>>>>>> or did I not properly apply it in my system?
>>>>>>>>
>>>>>>>> Thanks.
>>>>>>>>
>>>>>>>> On Tue, Jun 5, 2018, 9:11 PM Vasco Alexandre da Silva Costa <
>>>>>>>> vasco.co...@gmail.com> wrote:
>>>>>>>>
>>>>>>>>> On Tue, Jun 5, 2018 at 7:29 AM, Sreyansh Jain <
>>>>>>>>> sreyanshjai...@gmail.com> wrote:
>>>>>>>>>
>>>>>>>>>> Okay, let me look into it.
>>>>>>>>>>
>>>>>>>>>> I've started with METABALL primitive, although it is incomplete I
>>>>>>>>>> believe (metaball method). Should I retain both new and old code
>>>>>>>>>> (shootalgo=2 and shootalgo=3) or just one in OpenCL?
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> For starters just pick one of those. You can start with the
>>>>>>>>> default (new) code.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> Also, how do I take input/define *ap->a_onehit *, *rp->r_min*
>>>>>>>>>> and *rp->r_max *in OpenCL?
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> You can start by just assuming that ap->a_onehit is TRUE. If you
>>>>>>>>> do need that in the rendering phase, you can pass it as a parameter
>>>>>>>>> to the
>>>>>>>>> respective kernels in
>>>>>>>>> https://svn.code.sf.net/p/brlcad/code/brlcad/trunk/src/librt/primitives/primitive_util.c:clt_frame()
>>>>>>>>> which is called in
>>>>>>>>> https://svn.code.sf.net/p/brlcad/code/brlcad/trunk/src/rt/do.c:clt_run()
>>>>>>>>> .
>>>>>>>>>
>>>>>>>>> As for rp->r_min, and rp->r_max IIRC those are the rmin,rmax
>>>>>>>>> bounds determined in rt_in_rpp() in rt.cl. You can get their
>>>>>>>>> values from bounds->p_min,bounds->p_max in rt.cl:shootray().
>>>>>>>>> You'll have to pass those to the shot() function and then the
>>>>>>>>> respective
>>>>>>>>> METABALL shot function.
>>>>>>>>>
>>>>>>>>> Regards,
>>>>>>>>> -vasc
>>>>>>>>>
>>>>>>>>> ------------------------------------------------------------------------------
>>>>>>>>> Check out the vibrant tech community on one of the world's most
>>>>>>>>> engaging tech sites, Slashdot.org <http://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
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Vasco Alexandre da Silva Costa
>>>> PhD in Computer Engineering (Computer Graphics)
>>>> Instituto Superior Técnico/University of Lisbon, Portugal
>>>>
>>>> ------------------------------------------------------------------------------
>>>> 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
>>>
>>>
>>
>>
>> --
>> 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
>
> ------------------------------------------------------------------------------
> 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
