Cool, can you show a different view like “ae 35 25”?
Cheers,
Sean
> On Aug 13, 2018, at 10:45 AM, Sreyansh Jain <sreyanshjai...@gmail.com> wrote:
>
>
> PFA screenshots for HYP primitive.
>
>
> Warm Regards,
>
> Sreyansh
>
> On Mon, Aug 13, 2018 at 11:05 PM Sreyansh Jain <sreyanshjai...@gmail.com
> <mailto:sreyanshjai...@gmail.com>> wrote:
>
> Hi,
>
> You can deploy the final superell patch submitted. It's working fine now.
> I've attached the screenshot also for your reference. I have used -H32 -s2048
> in both.
> I'll let you know as and when I'm done with others.
>
>
> Warm Regards,
>
> Sreyansh
>
>
> On Sun, Aug 12, 2018 at 10:42 PM Sreyansh Jain <sreyanshjai...@gmail.com
> <mailto:sreyanshjai...@gmail.com>> wrote:
>
> Hi,
>
> I've made the detailed report of my work here:
> https://github.com/sreyanshjainrkl/GSoC-18
> <https://github.com/sreyanshjainrkl/GSoC-18>. I've also submitted OpenCL code
> for VOL primitive apart from the others mentioned earlier in the project
> plan. Do let me know your reviews on the report so that I can submit it for
> my final evaluation.
>
>
> Warm Regards,
>
> Sreyansh
>
>
> On Fri, Aug 10, 2018 at 10:54 AM Sreyansh Jain <sreyanshjai...@gmail.com
> <mailto:sreyanshjai...@gmail.com>> wrote:
> 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
> <mailto: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 <mailto: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/src/libbrep/>
> https://svn.code.sf.net/p/brlcad/code/brlcad/trunk/include/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/
> <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/include/brep/bbnode.h>
> https://svn.code.sf.net/p/brlcad/code/brlcad/trunk/src/other/openNURBS/opennurbs_surface.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
> <mailto: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
> <mailto: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 <mailto: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
> <mailto: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 <mailto: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 <mailto: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
> <mailto: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 <mailto: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
>
> <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
>
> <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
> <mailto: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
>> <mailto: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
>> <mailto: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
>> <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
>> <mailto: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
>> <mailto: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
>> <mailto: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 <mailto:vasco.co...@gmail.com>> wrote:
>>> On Tue, Jun 5, 2018 at 7:29 AM, Sreyansh Jain <sreyanshjai...@gmail.com
>>> <mailto: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()
>>>
>>> <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()
>>> <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 <http://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
> <http://sdm.link/slashdot>_______________________________________________
> BRL-CAD Developer mailing list
> brlcad-devel@lists.sourceforge.net <mailto:brlcad-devel@lists.sourceforge.net>
> https://lists.sourceforge.net/lists/listinfo/brlcad-devel
> <https://lists.sourceforge.net/lists/listinfo/brlcad-devel>
> <hyp_c.png><hyp_cl.png>------------------------------------------------------------------------------
> 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_______________________________________________
> <http://sdm.link/slashdot_______________________________________________>
> BRL-CAD Developer mailing list
> brlcad-devel@lists.sourceforge.net <mailto:brlcad-devel@lists.sourceforge.net>
> https://lists.sourceforge.net/lists/listinfo/brlcad-devel
> <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
