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