Dear all,
Try to answer these questions as briefly yet informatively as possible:
What CODE have you completed, why that code first, what are you working on
now, and what's immediately next? Try to keep it under five sentences but
don't be vague. Be detailed, specific. Pics, if applicable, is awesome. :)
In order to prepare the BRL-CAD source code for the heart primitive , I
hooked the heart primitive into the BRL-CAD source by adding a magic number
for the heart in include/magic.h and src/libbu/magic.c, stubbing an empty
heart in include/db5.h, include/rtgeom.h, include/raytrace.h,
src/librt/db5_types.c and /src/librt/primitives/table.c and adding typing
support for the heart in the mged interface in include/wdb.h,
src/libwdb/wdb.c and src/libged/typein.c. As regards the ray tracing
callback functions in src/librt/primitives/hrt/hrt.c , I have built the
hrt_specific structure, written the rt_hrt_shot() and rt_hrt_prep()
functions and I am currently testing these.I intend to continue working on
other callback functions like rt_hrt_import(), rt_hrt_print(), etc and
finally hook the heart primitive to the mged and archer interfaces with
associated clean up and documentation.
Cheers
Izak
On Tue, Jul 23, 2013 at 4:46 AM, <[email protected]
> wrote:
> Send brlcad-devel mailing list submissions to
> [email protected]
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.sourceforge.net/lists/listinfo/brlcad-devel
> or, via email, send a message with subject or body 'help' to
> [email protected]
>
> You can reach the person managing the list at
> [email protected]
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of brlcad-devel digest..."
>
>
> Today's Topics:
>
> 1. Doxygen: Limited Project for Libs Only (Tom Browder)
> 2. Re: Conversion of .g file format (Christopher Sean Morrison)
> 3. Re: Doxygen: Limited Project for Libs Only
> (Christopher Sean Morrison)
> 4. Re: Doxygen: Limited Project for Libs Only (Clifford Yapp)
> 5. Re: Perl API? (Tom Browder)
> 6. Re: Perl API? (Christopher Sean Morrison)
> 7. GSoC Progress Update (Christopher Sean Morrison)
> 8. Re: GSoC Progress Update ( phoenix )
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Sat, 20 Jul 2013 16:27:44 -0500
> From: Tom Browder <[email protected]>
> Subject: [brlcad-devel] Doxygen: Limited Project for Libs Only
> To: Developer discussions <[email protected]>
> Message-ID:
> <CAFMGiz-cDVi48YOa4k3=btZwosKd-hN62dhWcVw=
> [email protected]>
> Content-Type: text/plain; charset=ISO-8859-1
>
> While browsing the results of the integration of patch #53 (?), I said
> this on the patch list about lib* man pages:
>
> On Wed, Jul 17, 2013 at 8:56 AM, Tom Browder
> <[email protected]> wrote:
> ...
> > ./doc/docbook/system/man3/en/librt.xml
> >
> >I have the first three files cleaned up I think rather nicely, but the
> >last, for librt, is a mess. Apparently when it was originated librt
> >had only a few variables and functions, but now the header is over
> >8,000 lines! Maintaining it manually (if it could be made current)
> >would be a nightmare.
> >
> >I know there are plans for a new doc system but I think we should look
> > at one of several options for the lib* man pages (xml source) now.
> >
> >1. Delete the current lib* docs.
> >2. If we want lib* docs, create a semi-auto-generated set consisting
> >of several parts. Possibly something like:
> ...
> >+ an auto-generated list of the headers associated with each lib (and
> >maybe links to the man page for each header--which could be generated
> >by Doxygen)
>
> Well, I just found that we have a dox/doygen target and gave it a try
> and it looks good for a start. Is anyone working on it?
>
> Maybe a limited Doxy output could generate the man pages for the libs?
>
> Best,
>
> -Tom
>
>
>
> ------------------------------
>
> Message: 2
> Date: Sat, 20 Jul 2013 21:14:48 -0400
> From: Christopher Sean Morrison <[email protected]>
> Subject: Re: [brlcad-devel] Conversion of .g file format
> To: BRL-CAD Developer Mailing List
> <[email protected]>
> Message-ID: <[email protected]>
> Content-Type: text/plain; charset=windows-1252
>
>
> On Jul 20, 2013, at 1:43 PM, Talwinder saini wrote:
>
> > I was reading a "BRL-CAD documentation Volume IV ? Converting Geometry
> > Between BRL-CAD and Other Formats" on page no 37,38,39 the conversion
> > commands of .g file in to .DXF, .IGES and .STL file are not give the
> > result as accurate it is in .g format.
> > For example [..snip..]
> > Is it an error in the converter it is expected output. If it is
> > expected output, how can I increase the number of faces?
>
> Talwinder,
>
> Polygonal conversion rarely ever is as accurate as CAD representation in
> parametric form (e.g., as CSG+implicits, NURBS, or other spline surface
> forms). That's the point of CAD formats and why the industry doesn't use
> triangles (except for display). :)
>
> It's the expected output. You can increase the number of faces by
> specifying different tolerance values. The -a, -r, -n, and -D options all
> control the type, shape, and quantity of polygons that will result during
> export.
>
> Note that changing the defaults can be tricky. For a simple cylinder,
> it's easy, but for models with a variety of geometry, you have to read the
> docs to understand what each of those options do and experiment with the
> settings. You can very easily end up specify tolerances that generate too
> many polygons and you'll run out of memory or fill up your hard drive.
> General rule of thumb: start with big numbers and make them smaller.
>
> For your cylinder, try setting the -n (normal) tolerance to 5: g-stl -n 5
> -o file.stl file.g object
>
> That ensures there's a polygon for every five degree difference, which
> will approximately increase the number of triangles about an order of
> magnitude (about 1500). Using a 1 degree angle will increase the count to
> somewhere around 200 times as many. You can play with different values,
> depending on your model.
>
> Cheers!
> Sean
>
>
>
>
> ------------------------------
>
> Message: 3
> Date: Sat, 20 Jul 2013 21:28:51 -0400
> From: Christopher Sean Morrison <[email protected]>
> Subject: Re: [brlcad-devel] Doxygen: Limited Project for Libs Only
> To: BRL-CAD Developer Mailing List
> <[email protected]>
> Message-ID: <[email protected]>
> Content-Type: text/plain; charset=us-ascii
>
>
> On Jul 20, 2013, at 5:27 PM, Tom Browder wrote:
>
> > While browsing the results of the integration of patch #53 (?), I said
> > this on the patch list about lib* man pages:
>
> There is no list. I believe responding to a patch e-mail posts a comment
> to that patch.
>
> >> I have the first three files cleaned up I think rather nicely, but the
> >> last, for librt, is a mess. Apparently when it was originated librt
> >> had only a few variables and functions, but now the header is over
> >> 8,000 lines! Maintaining it manually (if it could be made current)
> >> would be a nightmare.
>
> I agree.
>
> Librt has grown to the point where we need to make serious efforts to
> break it up into separate libraries. One is already a pending patch
> (separation of libnmg) which is about a 1/3rd reduction. Another will be
> the core geometry including the core database I/O routines and the database
> objects (perhaps a "libg"). That will really help librt really just be
> about ray tracing.
>
> >> I know there are plans for a new doc system but I think we should look
> >> at one of several options for the lib* man pages (xml source) now.
> >>
> >> 1. Delete the current lib* docs.
> >> 2. If we want lib* docs, create a semi-auto-generated set consisting
> >> of several parts. Possibly something like:
> > ...
> >> + an auto-generated list of the headers associated with each lib (and
> >> maybe links to the man page for each header--which could be generated
> >> by Doxygen)
>
> Sounds like a good plan in addition to the Doxygen efforts.
>
> > Well, I just found that we have a dox/doygen target and gave it a try
> > and it looks good for a start. Is anyone working on it?
>
> I was actively working on the Doxygen files and probably the last to have
> been doing so, but I was really trying to focus on getting just one library
> in an ideal state so it could be an example for the others. I started with
> libbu and got maybe 80% there before I had to shift gears.
>
> > Maybe a limited Doxy output could generate the man pages for the libs?
>
> Absolutely. What the manual pages offer is the human-readable explanation
> of the API, which Doxygen has mechanisms for and which we utilize to a
> limited extent. If it can generate proper man pages, that'd be really
> awesome.
>
> Cheers!
> Sean
>
>
>
>
> ------------------------------
>
> Message: 4
> Date: Sat, 20 Jul 2013 22:33:49 -0400
> From: Clifford Yapp <[email protected]>
> Subject: Re: [brlcad-devel] Doxygen: Limited Project for Libs Only
> To: BRL-CAD Developer Mailing List
> <[email protected]>
> Message-ID:
> <
> cahsgyas+dnfdidysjwndnq4wkjhouuf5gkwgg_phd1af_2s...@mail.gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
>
> On Sat, Jul 20, 2013 at 5:27 PM, Tom Browder <[email protected]>
> wrote:
>
> > Well, I just found that we have a dox/doygen target and gave it a try
> > and it looks good for a start. Is anyone working on it?
> >
> > Maybe a limited Doxy output could generate the man pages for the libs?
> >
>
> Tom,
>
> I've been thinking a little about Doxygen, but from the perspective of the
> build system rather than the libraries themselves (I want to have a way to
> build just a dox-libbrep target, say, if I don't want to take the time to
> generate the whole interlinked doxygen output for all of BRL-CAD.) If you
> have any insights into the specific inputs and invocations needed to get
> Doxygen to generate the man pages, I'd be glad to take a stab at
> integrating that into a spruced up Doxygen documentation building setup.
>
> Cheers,
> CY
> -------------- next part --------------
> An HTML attachment was scrubbed...
>
> ------------------------------
>
> Message: 5
> Date: Mon, 22 Jul 2013 07:09:42 -0500
> From: Tom Browder <[email protected]>
> Subject: Re: [brlcad-devel] Perl API?
> To: BRL-CAD Developer Mailing List
> <[email protected]>
> Message-ID:
> <
> cafmgiz_qtg2psnwc0mwecbn8nartactuy8vtgb+on0eb637...@mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> On Mon, Mar 11, 2013 at 8:27 PM, Tom Browder <[email protected]>
> wrote:
> > On Mon, Mar 11, 2013 at 2:09 PM, Greenwald, Erik G CIV (US)
> > <[email protected]> wrote:
> >> On 3/11/13 8:24 AM, "Tom Browder" <[email protected]> wrote:
> > ...
> >> include/brlcad.i was added for the 7.22.0 release and requires swig 2.0
> or
> >> later. It's not heavily tested, but it's a start.
>
> Okay, I would like to pursue this. It seems to me that a perl
> subdirectory would be helpful, but where should it go?
>
> I think maybe ./misc/perl (at least for now) since it will mainly be
> configuration files for directing traffic in ${CMAKE_BINARY_DIR}.
>
> Best,
>
> -Tom
>
>
>
> ------------------------------
>
> Message: 6
> Date: Mon, 22 Jul 2013 10:22:17 -0400
> From: Christopher Sean Morrison <[email protected]>
> Subject: Re: [brlcad-devel] Perl API?
> To: BRL-CAD Developer Mailing List
> <[email protected]>
> Message-ID: <[email protected]>
> Content-Type: text/plain; charset=us-ascii
>
>
> On Jul 22, 2013, at 8:09 AM, Tom Browder wrote:
>
> > Okay, I would like to pursue this. It seems to me that a perl
> > subdirectory would be helpful, but where should it go?
> >
> > I think maybe ./misc/perl (at least for now) since it will mainly be
> > configuration files for directing traffic in ${CMAKE_BINARY_DIR}.
>
> Sounds like a good place for it to me.
>
> Cheers!
> Sean
>
>
>
>
> ------------------------------
>
> Message: 7
> Date: Mon, 22 Jul 2013 20:08:12 -0400
> From: Christopher Sean Morrison <[email protected]>
> Subject: [brlcad-devel] GSoC Progress Update
> To: BRL-CAD Developer Mailing List
> <[email protected]>
> Message-ID: <[email protected]>
> Content-Type: text/plain; charset=us-ascii
>
>
> GSoC Participants,
>
> All around, most of you are doing a fantastic job as we are approaching
> the mid-point evaluations. Remember that you are expected to post details
> about your progress daily to your development logs. Several of you are
> doing great to take advantage of the mentors to help you with development
> questions. Please do post questions here or hang out on IRC to help
> accelerate your development.
>
> TODO: Over the next couple days, I'd like each of you post a quick
> 1-paragraph summary of your progress.
>
> Try to answer these questions as briefly yet informatively as possible:
> What CODE have you completed, why that code first, what are you working on
> now, and what's immediately next? Try to keep it under five sentences but
> don't be vague. Be detailed, specific. Pics, if applicable, is awesome. :)
>
> Remember, this is a summary. This is meant to be (really) brief, quick,
> and informative. I suggest just hitting reply and telling what you've
> done. Can't wait to see the seven summaries. ;)
>
> Cheers!
> Sean
>
>
>
> ------------------------------
>
> Message: 8
> Date: Tue, 23 Jul 2013 11:46:03 +0800
> From: " phoenix " <[email protected]>
> Subject: Re: [brlcad-devel] GSoC Progress Update
> To: " Sean " <[email protected]>
> Message-ID: <[email protected]>
> Content-Type: text/plain; charset="iso-8859-1"
>
> > Try to answer these questions as briefly yet informatively as possible:
> What CODE have you completed, why that code first, what are you working on
> now, and what's immediately next? Try to keep it under five sentences but
> don't be vague. Be detailed, specific. Pics, if applicable, is awesome. :)
>
> I have completed some code for independent NURBS intersections (P/P, P/C,
> P/S, C/C, C/S and S/S) and the code for testing. This is the basis of NURBS
> evaluation. What I'm doing now is modifying the surface-surface
> intersections, cleaning up the code and add documentations. The next I'm
> going to do (on August) is start working on NURBS evaluations.
>
>
> Cheers!
> Wu
> -------------- next part --------------
> An HTML attachment was scrubbed...
>
> ------------------------------
>
>
> ------------------------------------------------------------------------------
> See everything from the browser to the database with AppDynamics
> Get end-to-end visibility with application monitoring from AppDynamics
> Isolate bottlenecks and diagnose root cause in seconds.
> Start your free trial of AppDynamics Pro today!
> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
>
> ------------------------------
>
> _______________________________________________
> brlcad-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/brlcad-devel
>
> End of brlcad-devel Digest, Vol 352, Issue 1
> ********************************************
>
------------------------------------------------------------------------------
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
_______________________________________________
BRL-CAD Developer mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/brlcad-devel
