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
