VOL is voxel map (which might be generated from a CAT or MRI scan).
You need to pass a 3D texture file as an argument upon creation. The page
you linked to references a Stanford University webpage with some example
dataset files. These need to be converted according to the instructions in
the VOL webpage (from 16-bit uint slices to a 8-bit uchar 3D bitmap IIRC).
Regards,
On Sun, Aug 19, 2018 at 9:10 PM, Sreyansh Jain <sreyanshjai...@gmail.com>
wrote:
> Hi,
>
> How can I create VOL primitive other than the one mentioned at
> brlcad.org/wiki/VOL. It is giving me error: *fatal - cannot open file
> "hu16", mode "r".*
>
> Also, I tried with command '*rt -z1 -o ell_cl.png -s2048 -H32*' which
> seems to invoke OpenCL and, as you suggested earlier, even after making
> drastic changes to ell_shot.cl, no changes were reflected on the output
> time/image. How can I check if there's any issue somewhere else in the
> pipeline?
>
>
>
> Warm Regards,
>
> *Sreyansh Kumhar Jain*
> Associate, PwC India
> *+91-9933958066*
>
> sreyanshjai...@gmail.com
> Facebook <https://www.facebook.com/sreyansh.sonu> | LinkedIn
> <https://www.linkedin.com/in/sreyansh-kumhar-jain-a61428104/> | GitHub
> <https://github.com/sreyanshjainrkl>
>
>
> On Tue, Aug 14, 2018 at 3:30 AM Christopher Sean Morrison via brlcad-devel
> <brlcad-devel@lists.sourceforge.net> wrote:
>
>> 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>
>> 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>
>>> wrote:
>>>
>>>> Hi,
>>>>
>>>> I've made the detailed report of my work here: 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> 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>
>>>>> 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
>>>>>>>
>>>>>> <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_______________________________________________
>> 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
