> On Aug 4, 2017, at 4:36 PM, Mario Meissner <mr.rash....@gmail.com> wrote: > > Is there a new version of the code demonstrating them working? > > Yes, it is attached to today's email. It should compile and produce an > rtexample binary that runs the example I set up correctly.
Both this prior version and the latest viewweight.c suffer from the comment I originally made, namely that the 0 and 1 point cases are not what i would call “complete". That’s not to say that they’re not working — but that the code is not in a usable state yet such that it could be used by a user (e.g., today). That’s mostly because the code is not actually querying a density in query_density() which implies sorting out where these specifications are coming from, how they will be specified, etc. They’re hard-coded. When we talk about coding complete, it means taking a minimal feature to completion. In moving your code to rtweight, it’s important to actually finish cases 0 and 1 in production terms. Otherwise it could all be for naught. It means figuring out how a user is going to specify a point, storing that point, resolving how this new density specification is going to interplay with the .density file, and querying values during query_density() instead of hard-coded data. > On Aug 5, 2017, at 1:11 PM, Mario Meissner <mr.rash....@gmail.com> wrote: > > Other than that I just needed to add some lines to the end of the hit() > function to use my density() calls instead of using the .density file data. Hopefully we can figure out something better than an override as that has negative usability implications. An approach that avoids the issue is to piggyback on the old ID system and plan for this new system to utilize material objects (containing this new information), as discussed previously. This implies changing materialID to point to object names instead of a number, so there’s no dual specification, and implementing at least the bare bones to store a point as an object instead of as an id#. The calling code is then unambiguous, meaning one or the other. It’s possible there’s not enough time remaining in socis to even do 0-points in this manner… but it’s the approach needed to make this actually get used as soon as possible. > • overlapping points should return an error during the input phase in my > opinion, since it makes absolutely no sense that one point has more than one > density value. Agreed. The concern is simply that the code handles the case robustly, even if to simply report an error (as opposed to crashing, for example, which is often default behavior). > • Depending on how we decide to set up the vector list, this edge case could > potentially be handled by checking that no vector has magnitude 0. However > two overlapping points could both be drawing a vector to origin and result in > the exact same vector but with different factors, resulting in nonsense. I'll > think about how to properly check for this. I think this can also be handled by changing the way vectors are being defined (or perhaps what they mean). Instead of having a concept of origins and detachment of point densities, let density_vector actually refer to a density_point and let the other struct fields encode the nature of the contribution (effectively combining your struct combination data into one concept). That would mean you could have points with or without vectors. In a 0-point system, the density_point pointer would be null and is handled trivially as massless. In an N-point system without vectors, you can project each point onto the shotline to determine which field you are contained within. This would handle the earlier case of discontinuous density transitions. Then, defining vectors similarly will project onto the shotline and defines a different (linear / continuous) transition. That would be the fully general way to handle the half-space concept mentioned earlier. It also becomes easy to support things like radial transitions. You would define factors for the starting and end points in the density_vector struct along with the transition type (e.g., linear vs. radial vs. step). > • Points outside geometry should work just fine, and I'm working on an > example to prove that. This was another case of making sure it does something sensible, doesn’t crash. ;) It is a thought-provoking design question, though. If I had a region that was some advanced material — e.g., kevlar with different density for the horizontal and vertical strands — and I set a density in one horizontal strand, I would expect it to apply to the whole strand in flood-fill fashion (there are no vectors). Similarly, if I defined the material of the neighboring vertical strand, it would apply and the two should have no interaction. Perhaps a simpler case is three overlapping spheres intersected and wanting to specify density values in each zone. No transitions. > Reduced the box to half its width, so that we now only use half of the 5->10 > vector. Now the box starts with 5 and ends with 7.5 on the other edge. It > also has half the volume. So, 5e8 mm3 x 6.25g/mm3 = 3,125e9 g. That’s good! Cheers! Sean p.s. Remember that you should be submitting patches from here forward so it’s easier to review and test your code. ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ BRL-CAD Developer mailing list brlcad-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/brlcad-devel
