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/brlc
>>>>>>>> ad/code/brlcad/trunk/src/librt/primitives/primitive_util.c:
>>>>>>>> clt_frame() which is called in https://svn.code.sf.net/p/brlc
>>>>>>>> ad/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
