Hi again! A few questions:
- If I were to initialize my vectorlist before we start shooting rays, and leave it prepared so that each call of hit() is able to access this list, where and how should I do it? - Might it be that the ray-shoots happen inside some loop in worker.c? If not, who shoots the rays and how? Is it a general purpose code that is used for all ray-tracing programs? If so, how does it know which hit() function to call (rtweight, rt...). - Trying to rescue this one comment you made a few weeks ago: "Note that this method does have a potential flaw in that we’re treating the density contributions uniformly when in reality, they should probably be weighted by distance to the vector. In your example, they’re equidistant, so it works out. But consider the implication of box that is 100 times taller, for example. Instead of 4 x 4, it’s 4 x 400. Point b should be a value far closer to 8 than 4, certainly not 6. That’s a problem that can be dealt with later, but something to keep in mind." How exactly would we approach this? "Distance to the vector" makes little sense to me. Do you mean distance between the points? (as in, point b is closer to point B than it is to point A, so it gets more influence from it's vector). I'm attaching the example we talked about here again for your convenience. Mario. 2017-08-06 10:10 GMT+02:00 Mario Meissner <mr.rash....@gmail.com>: > 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. >>> >> >> >
example_contributions.pdf
Description: Adobe PDF document
------------------------------------------------------------------------------ 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
