Re: [brlcad-devel] gqa + rtweight - Our First World Problem?

[Kalpit T. <cea...@gm...>]

Hello Daniel!

On Thu, Jun 18, 2015 at 2:16 PM, Daniel Roßberg <dan...@gm...>
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" <cea...@gm...>:
>
>> On Sun, Jun 14, 2015 at 10:23 PM, Daniel Roßberg <
>> dan...@gm...> 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 <cea...@gm...>:
>>> > 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
>>> > brl...@li...
>>> > https://lists.sourceforge.net/lists/listinfo/brlcad-devel
>>> >
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> _______________________________________________
>>> BRL-CAD Developer mailing list
>>> brl...@li...
>>> https://lists.sourceforge.net/lists/listinfo/brlcad-devel
>>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>>
>> _______________________________________________
>> BRL-CAD Developer mailing list
>> brl...@li...
>> https://lists.sourceforge.net/lists/listinfo/brlcad-devel
>>
>>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> BRL-CAD Developer mailing list
> brl...@li...
> https://lists.sourceforge.net/lists/listinfo/brlcad-devel
>
>