Hi,
In the rt_brep_shot patch, do I have to include the glue code which packs
and unpacks it like it was done in case of primitives? If yes, will
functions in this C++ snippet be similar to the one in C?
On Fri, Aug 3, 2018, 1:07 AM Sreyansh Jain <sreyanshjai...@gmail.com> wrote:
> How do I check which Domain() and Dimension() function to use? These are
> defined in many opennurbs_*.cop but not in the ones they're referenced.
> (For example, Domain() is used in On_Curve::EvTangent(..) but not defined
> in opennurbs_curve.cpp).
>
> On Thu, Jul 26, 2018, 1:56 AM Vasco Alexandre da Silva Costa <
> vasco.co...@gmail.com> wrote:
>
>> 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
>>
>
------------------------------------------------------------------------------
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
