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
