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