Followup, As promised, I checked whether or not points outside of geometry behave like expected, and so they do. I did the following to test it:

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. https://puu.sh/x2Wp2/af48012d6a.png Cheers, Mario. 2017-08-05 19:11 GMT+02:00 Mario Meissner <mr.rash....@gmail.com>: > Hello again! > > I moved my code over to viewweight.c. For now I just put my density() > function alongside the other functions inside the file, and my own > structures below the already defined ones. > > 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. > > Currently, average is taken between the values. In the future we might > want to take more values alongside the segment to get higher precision > during interpolation. This way, non-linear variations between points could > be easily supported. > > Running rtweight on a 1m-side box returns the expected value of 7.5e6 Kg > for the points that I hardcoded for the previous examples. Of course, > taking any other box size won't work well since the vectors are only > defined for this specific size and shape. > > About the edge cases you mentioned: > > - 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. Encountering this situation during the evaluation phase > should also probably yield an error and terminate. 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. > - Points outside geometry should work just fine, and I'm working on an > example to prove that. > > After that, I will now proceed to finish off the 4point example I talked > about, both on paper and then on code. Lets see if I can get the code to > return the expected mass for that as well. I will also work on the more > advanced vector examples we talked about, with the hope of getting feedback > on it and keeping up the discussion about the final implementation (now > that we are slowly catching up with code on the simple examples). > > Attached goes output of current code, the code itself, and the box I used. > > Output: https://puu.sh/x2n0W/406b7a0bb9.png > > Have a nice weekend! > Mario. > > 2017-08-04 22:36 GMT+02:00 Mario Meissner <mr.rash....@gmail.com>: > >> >> 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. >> >> There are a variety of cases with 2points that should also be explored >> and ensure are being handled too like having coincident points, >> external/distant, etc. this can be done on the rt example code or... >> >> >> Okay, I'll make some more 2point examples with different situations like >> the ones you mention. >> >> Before doing that, the next step should be getting 0-1 points working on >> the production tools. Now that you have a feel for rtexample's single ray >> case, that should make rtweight a lot easier to understand and get >> working. See if you can make the changes necessary to rtweight for cases 0 >> & 1 points. >> >> >> Got it. Will work on that. >> >> Working with the rtweight sources, you will now be able to now submit >> changes in proper patch form. Make sure you have an svn trunk checkout, >> then run svn diff to see your changes. >> >> >> Okay. I'll stay on rtexample for the new test cases mentioned above and >> move to rtweight for new work. >> >> Mario. >> > >

------------------------------------------------------------------------------ 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