Hello Daniel! On Thu, Jun 18, 2015 at 2:16 PM, Daniel Roßberg <danielmrossb...@gmail.com> wrote:
> Hm, you shouldn't hook the functions from libanalyze directly into > rt_functab. The functions there usually have different parameters than > ry_functab requires. I.e. you need adapter functions. > Okay, gotcha. :) > And comparing gqa and rtweight I'm in doubt if rtweight has the better > solution for computing volumes. The possibility to set the required > tolerance is a nice feature which I would consider as useful. However, I > personally wouldn't have much interest in setting the ray trace direction > when I want to know the volume only. > Yes, after sending the previous mail, I considered both, the rtweight and gqa way, and I realized it's better if I stick with the gqa way. Yes, even I wouldn't bother about the raytrace direction, and so I can do something like : *Use a tolerance which keeps in check the difference in volumes computed after consecutive grid refinements, and the volume is computed shooting only from a single direction. *For now, I am computing the volume with a fixed grid spacing and not refining the grid. Once I succeed in getting a reasonably well working program for that, I'll add the refinement and tolerance. Sounds better? :) With Regards, Kalpit Thakkar Am 17.06.2015 18:06 schrieb "Kalpit Thakkar" <ceasy...@gmail.com>: > >> On Sun, Jun 14, 2015 at 10:23 PM, Daniel Roßberg < >> danielmrossb...@gmail.com> wrote: >> >>> Kalpit, >>> >>> Some comments (I wouldn't call them answers): >>> - gqa and rtweight both have parameters for azimuth and elevation, but >>> the gqa manual says that they are not implemented there. >>> >> >> Yes, gqa has not implemented azimuth and elevation. However, rtweight has >> and I can take help from there to support arbitrary views in the final >> implementation. >> >> >>> - I would recommend to start with a single source file for every >>> functionality you want to transfer to libanalyze. >>> >> >> Roger that. :) >> >> >>> - How the result will be displayed isn't part of the >>> volume/area/centroid computation but of the program using these >>> functions. So, leave it in gqa and rtweight. >>> >> >> Okay, cool. So, if I'm getting this correctly, I need to write 3 source >> files -- one each for volume, centroid and surface area. Each file >> essentially computes the required values and reports them to the program >> that is using it. Am I following? >> >> >>> >>> > In the final implementation, should I include all the analysis options >>> that gqa has right now or only focus on volume, centroid and surface area? >>> I see the problem. gqa doesn't simply compute the volume when it >>> shoots rays through a grid, it collects additional data about gaps, >>> overlaps, etc. too. However, our goal should be to have well defined >>> functions in libanalyse which don't compute an arbitrary set of >>> additional values only because of they are easy to add to the >>> algorithm. >>> >> >> Yes, I thought so too. I will try to eliminate as much useless >> calculations as I can. >> >> >>> >>> > How exactly do I start designing the public API layout that I have to >>> put in src/libanalyze? >>> Maybe you should start with this: Designing a function in libanalyse >>> which computes the volume. How should such a function look like? >>> Sure, it should return a double (the volume in mm^3) but which >>> parameters does it need? We want to use it for (not as ;-) a generic >>> rt_functab function for the complex elements. But can it be written >>> such that it could be used in rtweight (or even gqa) too? >>> >>> You should turn your attention to writing generic functions for >>> rt_functab. If they can be used in other functions as e.g. gqa or >>> rtweight too it's nice, but if not you still succeeded. >>> >> >> Okay hmm. So, according to me, this means : >> >> - My *analyze_*() (kind of the main()) *function of each source file >> will be the one filled in as the generic function for rt_functab. >> - It will compute the volume / centroid / surface area of the complex >> element using the ideology of rtweight -- no grid refinement, just one >> time >> shooting of rays and then the values are reported. Arbitrary views will >> work. >> >> I'll have to think about how to make this work with other analysis >> applications like *gqa*. But for now, I guess I'll just focus on writing >> source files which give me a function that returns the volume / centroid / >> surface area of element in question and is eligible for a rt_functab entry. >> Does that sound good? >> >> I hope the idea about using *rtweight's *ideology for now is fine. >> Support for "N" views can be added after I do it for one view I guess? >> >> With Regards, >> Kalpit Thakkar >> >>> >>> 2015-06-13 14:52 GMT+02:00 Kalpit Thakkar <ceasy...@gmail.com>: >>> > No, I don't think so this is a First World Problem for us. It is >>> nasty. Esp. >>> > rtweight. Never mind, let's get to the point. >>> > >>> > Hi, >>> > So I looked at some files in src/rt (mainly main.c, do.c, worker.c, >>> opt.c + >>> > rtuif.h and ext.h) and had a look at gqa.c in src/libged. I also had a >>> look >>> > at rtexample.c and rtdummy.c. Now, after thinking and thinking, I >>> couldn't >>> > figure out where to start exactly. I figured out that the basis of my >>> final >>> > implementation should be laid on gqa.c -- awesome! But then a lot of >>> doubts >>> > popped up in my mind. So here I go : >>> > >>> > The present implementation of gqa is pretty amazing and that's good >>> for me. >>> > Well, so basically my work is to add two things in the present >>> functionality >>> > of gqa. I figure they are (Am I right about this understanding of >>> mine? If >>> > not, what else is there that needs to be improved in the final >>> > implementation?) : >>> > >>> > Support for specifying azimuth and elevation (arbitrary views). >>> > Support N number of views rather than 3. >>> > >>> > As we can see, gqa is written in a single source file. Should the final >>> > implementation in libanalyze be also written in a single file? Or >>> should it >>> > be modular? >>> > Now, gqa doesn't have option to allow a new frame buffer to be opened >>> to >>> > display the results while rtweight has that functionality. Should we >>> include >>> > an option for opening a new frame buffer in the final implementation? >>> > How are we going to find the surface area of a model using the ray >>> shooting >>> > method (I guess rtarea doesn't find the total surface area)? Is there >>> an >>> > implementation for it right now? >>> > In the final implementation, should I include all the analysis options >>> that >>> > gqa has right now or only focus on volume, centroid and surface area? >>> > Is it a good idea to look at gqa.c and keep it as a base and start >>> writing >>> > the final implementation right away? Or is it preferable to use simpler >>> > files like rtexample.c and travel up from there? >>> > Is there a better factor (other than 2) which can be used for the grid >>> > refinement? >>> > Should this work in MGED right away? Or it should be developed as a >>> command >>> > line tool first? >>> > How exactly do I start designing the public API layout that I have to >>> put in >>> > src/libanalyze? (Yes, I guess it is pretty open ended a question. If I >>> > should come up with a better question, shoot! I’ll come up with one in >>> some >>> > time). >>> > >>> > There are some more implementation level questions (like whether to >>> prefer >>> > bu_vls over fprintf for printing messages in MGED?). But those are for >>> > later. I don't want to take too much at a time. Once the above >>> mentioned >>> > doubts are solved, I'll be able to have a better understanding of how >>> to >>> > proceed further. >>> > >>> > With Regards, >>> > Kalpit Thakkar >>> > >>> > PS : I'll speed up to catch up with the upcoming weeks of coding >>> period. >>> > Pardon me for my slow progress. >>> > >>> > >>> ------------------------------------------------------------------------------ >>> > >>> > _______________________________________________ >>> > BRL-CAD Developer mailing list >>> > brlcad-devel@lists.sourceforge.net >>> > https://lists.sourceforge.net/lists/listinfo/brlcad-devel >>> > >>> >>> >>> ------------------------------------------------------------------------------ >>> _______________________________________________ >>> BRL-CAD Developer mailing list >>> brlcad-devel@lists.sourceforge.net >>> https://lists.sourceforge.net/lists/listinfo/brlcad-devel >>> >> >> >> >> ------------------------------------------------------------------------------ >> >> _______________________________________________ >> BRL-CAD Developer mailing list >> brlcad-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/brlcad-devel >> >> > > ------------------------------------------------------------------------------ > > _______________________________________________ > BRL-CAD Developer mailing list > brlcad-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/brlcad-devel > >
------------------------------------------------------------------------------
_______________________________________________ BRL-CAD Developer mailing list brlcad-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/brlcad-devel
