Hello! I had been trying to write the implementation for volume already and here is it's first implementation. I haven't kept API design in mind right now as you can see in there, but this one is just to make sure I'm following the logic correctly or not. Please have a look.
volume implementation : https://gist.github.com/dracarys-stormborn/c894daa679fb670892c8 A header having the structures defined : https://gist.github.com/dracarys-stormborn/5f64359e90334728df70 This is a very very naive implementation right now. But things are slowly getting clearer to me and analysis on this will make it much clearer. :) With Regards, Kalpit Thakkar On Thu, Jun 18, 2015 at 9:00 PM, Christopher Sean Morrison <brl...@mac.com> wrote: > > On Jun 18, 2015, at 5:35 AM, Kalpit Thakkar <ceasy...@gmail.com> wrote: > > 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. > > > Also keep in mind that we will likely want to replace the method for > calculating volume at some point in the future, and this should be possible > without changing the API you design. This will be particularly necessary > if you only shoot from a single direction, even with refinement, as that > has proven to be highly unreliable/inaccurate on production models. Too > many surfaces are axis-aligned causing unstable oscillation in the volume > summation. Certainly good enough for a first step here, but the API design > should be sufficiently generic to allow a completely different method. > > Having a way to control the volume “quality” (e.g., via some convergence > tolerance) might be useful for getting an estimate quickly, or the API > could simply document and guarantee a given quality (e.g., volume converges > to at least 0.0005 mm^3 across successive iterations). > > >>>> 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. >>> >> > You may want to consider breaking up the calculation into two sets of > routines. One API call that creates “an evaluation context” and is where > you'd actually sample the geometry via rt_shootray(s). Then the different > analysis API calls (volume, centroid, etc.) that would take an evaluation > context and compute their value(s). They could further refine the > evaluation context as needed if you create API up to support this. > > Why do this? It would avoid reshooting the same rays for different types > of calculations, effectively caching previous results in the evaluation > context. So you might create a context and evaluate volume, which maybe > converged after 1M rays. To process a centroid, it would reuse the > partition data stored in the evaluation context. > > A primary consumer of this new API is going to be the ‘analyze’ command > which is supposed to report volume, centroid, and surface area > simultaneously. > > > Should the final implementation in libanalyze be also written in a >>>> single file? Or should it be modular? >>>> >>> > Modular. > > > 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? >>>> >>> > Given a set of ray samples and a density factor, this is fairly simple to > estimate. Every hit point is a surface sample, which you can think of as > being small circular patches. As the density increases, the patches get > smaller and the surface area is refined. > > > 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). >>>> >>> > This is a great resource written by someone with a lot of experience in > API design: > http://www4.in.tum.de/~blanchet/api-design.pdf > > > There are some more implementation level questions (like whether to >>>> prefer >>>> > bu_vls over fprintf for printing messages in MGED?). >>>> >>> > The HACKING file speaks to some of these questions, but it’s almost always > preferred to leverage routines in our basic runtime (BU, BN). You > shouldn’t be calling fprintf() … when in doubt, just ask. ;-) > > Cheers! > Sean > > > > > ------------------------------------------------------------------------------ > > _______________________________________________ > 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
