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
