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
