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.
- I would recommend to start with a single source file for every
functionality you want to transfer to libanalyze.
- 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.
> 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.
> 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.
Regards,
Daniel
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
