Basically make your own duplicates of the data in those structures that you
actually use to perform the ray tracing evaluation for the shots. Similar
to what is already done in the clt_*_pack functions.
Since the BREP is a complex datastructure, looking at the BoT (bag of
triangles) pack function should be a decent guide (it's a triangle list
with a spatial triangle tree).
So you need to convert the C++ BREP functions and methods called in the
_shot function into C. You also want to serialize the C++ data structure
into a memory buffer that will be passed over to the OpenCL side prior to
that. It's likely you won't need to transfer all the data in the structure
(this also happens with the intersection of other primitives). I typically
convert first the _shot code and then the _prep code as typically a lot of
the data computed on _prep isn't used on _shot. This way you only copy into
the buffer the data that actually is need for it. This reduces the amount
of OpenCL code you need to write.
You can basically start by manually inlining any C++ function calls and
methods invoked on _shot(). This will probably take you several steps of
manually inlining and merging code. You can start with breaking down the
invoked C++ classes into C++ functions and C++ structs with the data.
Then you need to convert the C++ functions and C++ structs into C functions
and C structs.
To do that you'll need to eliminate any templates and replace uses of C++
standard library data structures with your own ANSI C code. Like I said the
BoT code is a good example of a similarly complex data structure since it
also features a list and a BVH tree.
The BREP specific code in C++ should also be in:
https://svn.code.sf.net/p/brlcad/code/brlcad/trunk/src/libbrep/
https://svn.code.sf.net/p/brlcad/code/brlcad/trunk/include/libbrep/
https://svn.code.sf.net/p/brlcad/code/brlcad/trunk/src/other/openNURBS/
For example this is where BBNode and ON_Surface are declared:
https://svn.code.sf.net/p/brlcad/code/brlcad/trunk/include/brep/bbnode.h
https://svn.code.sf.net/p/brlcad/code/brlcad/trunk/src/other/openNURBS/opennurbs_surface.h
The 'ON' prefix means something is from the openNURBS library.
I suggest you use a C/C++ code browser to help you with this process. This
way you can follow functions and methods or declarations across the code
tree. For example I used Netbeans, in C/C++ mode, to code the hairier to
port bits.
Regards,
On Wed, Jul 25, 2018 at 10:59 AM, Sreyansh Jain <sreyanshjai...@gmail.com>
wrote:
> Hi,
>
> How do I go about using BBNode (details in BBNode.cpp) and ON_Surface in
> this OpenCL code?
>
> On Thu, Jul 12, 2018, 11:32 PM Sreyansh Jain <sreyanshjai...@gmail.com>
> wrote:
>
>> Okay. Google only needs the final documentation, I need not submit any
>> code to them right now for second evaluation. I'm attaching the code here
>> for your reference.
>>
>> On Sun, Jul 8, 2018 at 10:56 AM Vasco Alexandre da Silva Costa <
>> vasco.co...@gmail.com> wrote:
>>
>>> Show me what you have, by posting it to the list here, then submit the
>>> finished version.
>>> If Google demands that you send them something, also send them the code,
>>> AFAIK they only want the code in the final submission. But check.
>>>
>>> On Sun, Jul 8, 2018 at 6:44 AM, Sreyansh Jain <sreyanshjai...@gmail.com>
>>> wrote:
>>>
>>>> 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
>>>>>>>>>>>>>
>>>>>>>>>>>>>
--
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
