I would also like to get some more info about how you mentioned we could
model those complex examples I sent. You said something about
half-spaces...How would it work exactly?
2017-08-07 14:47 GMT+02:00 Mario Meissner <mr.rash....@gmail.com>:
> 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.
>>>>
>>>
>>>
>>
>
------------------------------------------------------------------------------
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
