Better :) Try to come up with a first implementation for the volume soon. Daniel Am 18.06.2015 11:35 schrieb "Kalpit Thakkar" <ceasy...@gmail.com>:
> 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 > >
------------------------------------------------------------------------------
_______________________________________________ BRL-CAD Developer mailing list brlcad-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/brlcad-devel
