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
