Good morning / afternoon !
I've started considering the inclusion of vectors into the current code,
and realized that linear vectors may not make much sense in terms of new
value.
Yes, with a vector we can define a smooth transition between points instead
of an abrupt change in the middle of two points. However, the final result
will be the same. The points meaning abrupt or linear transition, after
all, is only relevant if we want to know the density at a specific point in
space, which we don't really use here currently (because I find that it's
much more comfortable to work with segments directly).
If we only needed to define a density model for the purpose of returning
the correct value with the segment_density() function, then linear vectors
are superfluous. We can perfectly just define the two points that make up
the vector (origin and termination) and compute the result using the
current code. Results should be exactly the same. Voronoi distribution and
linear transitions are equivalent in this regard. Now, if this model is
going to be used by some external agent as well then we may need to
properly define it.
My question here is, how should I model these vectors if at all,
considering that they won't be of any use in my current code? I thought one
way we could implement it is with a struct transition (probably rendering
obsolete density_vector) that references two points, and contains a
coefficient value that tells us how 'fast' the transition is (with 1
meaning linear). This way we include linear transitions in an elegant way
but give freedom to define any kind of them. Implementing them may be a
challenge but it seems like our best bet. I'll start working on this. If
you think this is a bad idea then early feedback is welcome so I don't step
too deep into the mud.
Mario.
2017-08-17 12:28 GMT+02:00 Mario Meissner <mr.rash....@gmail.com>:
> So I think now that n-points are working for convex regions, I think the
> next steps would be:
>
> - Integrate vectors into existing point system.
> - Let the user input vectors through the existing input interface.
> - Consider one of the vectors and make it work.
> - Consider all vectors. N-point and N-vectors working.
> - Check that all edge cases work correctly (no points, no vectors,
> many of everything, etc.) and clean up code.
> - Modify implementation so that it properly works in all situations
> (i.e. concave shapes).
>
> I'm also noticing that the current code is getting quite messy so I think
> its time to make a cleanup before continuing. A few aspects I want to work
> on:
>
> - What data should the projection structure contain?
> - Do we need the absolute position (point) of the projection? I think
> no, because in my code I am assuming everything is relative to inhit, so
> currently the point and its computation are commented out.
> - Is it a good idea to compute the distance to the previous point
> and store it into the structure in a loop before starting with density
> evaluation? I think it would clean up the last part of the code
> considerably, but also uses more memory. I like the idea so I probably
> will
> do so.
> - Are we really good to go using an array? I decided to do so because
> I needed the sort function, but there might be alternatives I'm not aware
> of.
> - As mentioned, everything in my code is relative to the inhit point.
> Is this a good approach? For example, projection struct has a vector that
> goes from inhit to the projection point, but I don't store the origin of
> the vector anywhere, so someone using the vector that does not know this
> fact may not know what it's origin is. My thought is that these variables
> will not leave my environment so a simple comment explaining that
> everything is relative should be enough.
>
> I will assume that what I propose doing is good unless I hear feedback
> telling me otherwise.
> Today I will work on a bit of cleanup and then the first point of my
> proposed steps.
> Attached goes code with minor cleanup changes over yesterday. If possible,
> use this for review.
> Happy coding!
> Mario.
>
> 2017-08-15 22:28 GMT+02:00 Mario Meissner <mr.rash....@gmail.com>:
>
>> Sean!
>> Implemented the math and did some bug hunting. I successfully ran an
>> N-Point Voronoi example (without vectors for now).
>> I shoot a ray from above at my 1000mm box. I set density points at
>> heights 600, 400 and 200 with density values of 20, 10 and 5 respectively.
>> Expected result is 13.5 average density throughout the segment from height
>> 1000 to 0.
>> Attached goes today's code and output.
>>
>> Notice that I have left my debugging logs on since I think they will be
>> very useful for you to see how code behaves, and for me now that I'm gonna
>> start including vectors.
>>
>> I desperately need some feedback now, hope you'll have some time to
>> review this.
>>
>> https://puu.sh/xaUwS/c2f30fc275.png
>> Mario.
>>
>> 2017-08-14 19:44 GMT+02:00 Mario Meissner <mr.rash....@gmail.com>:
>>
>>> The sorting function is now correctly implemented and works as expected
>>> with projection structs, sorting them by distance to inhit. Some debug code
>>> is included that prints the unsorted and then the sorted array of
>>> projections.
>>> Also much of the 'basement' for Voronoi is now ready, so now only the
>>> overlaying math required to compute the average density is missing.
>>> I think it can be done by tomorrow. I however am not sure at all if this
>>> is what you meant when we talked about this model, I'm working a bit
>>> towards unknown territory at the moment.
>>> Attached goes diff.
>>> Mario.
>>>
>>> 2017-08-11 23:46 GMT+02:00 Mario Meissner <mr.rash....@gmail.com>:
>>>
>>>> Hello Sean.
>>>> Things got a bit messy on the previous thread, I apologize for that.
>>>> I somehow managed to send emails only to myself for the last three
>>>> days.
>>>>
>>>> I decided to start a new fresh thread and include the text of the last
>>>> three emails here, as well as the newest code I have. It is a new iteration
>>>> over email3 with some of today's code commented out so that it compiles and
>>>> performs the 'complete' functionality I mentioned on my email2. You can get
>>>> a feel of what I pretend to do next by having a look at these commented out
>>>> lines of code as well.
>>>>
>>>> You can ignore the old thread and just reply to this one email instead.
>>>> Sorry again for the mess.
>>>>
>>>> EMAIL 1
>>>>
>>>> Okay,
>>>>
>>>> So since stuff doesn’t seem to work very well on viewweight yet, and
>>>> since we need to heavily modify existing code anyways, I decided to move
>>>> back to rtexample.
>>>>
>>>> If we want to use Voronoi tesselation as our base model and expand it
>>>> with transition vectors, many we have to rethink how we query data as well.
>>>> It makes no sense anymore to just query the density at a specific point
>>>> since we cannot just interpolate. Somewhere in between the two points, a
>>>> sudden change of density might occur. Interpolation would asume some kind
>>>> of transition, which there might not be (the value we obtain by
>>>> interpolation might be way off the real value). So, instead of asking for
>>>> the density at a specific point, lets give our function the whole segment
>>>> so that it can correctly return the average density, or even the mass. This
>>>> way the function knows where the segment starts and ends, can compute the
>>>> projections and apply Voronoi tesselation to determine the different
>>>> densities. Then with that info we compute the average density and return
>>>> it.
>>>>
>>>>
>>>>
>>>> With rtexample I won’t have the problem of sharing a pointer to my
>>>> point/vector list since I have a main function where I can do all that. My
>>>> readDensityPoints() function will also work as expected here.
>>>>
>>>>
>>>>
>>>> I’ll start working on this, maybe with just 0 and 1 points for now, and
>>>> hopefully make my first ‘complete’ piece of code.
>>>>
>>>>
>>>> EMAIL 2
>>>>
>>>> Sean,
>>>>
>>>> I’ve started working on Voronoi model for non-continuous density
>>>> evaluation using points. For now only 0 and 1 point works, but one complete
>>>> functionality is there, which is what you requested. User inputs 0 or 1
>>>> points and then program returns mass of what the ray saw when it crossed
>>>> geometry. Feedback on the code I started writing to evaluate Voronoi points
>>>> is appreciated and welcomed. Note that its by no means complete and
>>>> probably full of mistakes. However knowing that it is the right direction
>>>> is quite helpful.
>>>>
>>>>
>>>>
>>>> I think for tomorrow I can finish n-point Voronoi evaluation
>>>> (especially if I got feedback).
>>>>
>>>> I’m also pretty confused about why my user input function doesnt work
>>>> on viewweight. I’d love to get that working to go back to it.
>>>>
>>>> Until then I’ll work on functions to save my structs to a file and load
>>>> them again.
>>>>
>>>>
>>>>
>>>> Hereby goes diff rtexample.
>>>>
>>>> Cheers!!
>>>>
>>>>
>>>> EMAIL 3
>>>> Hi!
>>>> I've tried to clean up the code a bit more, and continued with the
>>>> implementation of Voronoi points. I hit a wall though:
>>>> I need to order my projections from the inhit to the outhit points. I
>>>> was all happy using my bu_list to store them but now I realize that this is
>>>> a really inconvenient option to manage them if I want to sort them
>>>> afterwards. I thus switched to an array so that I can use stdlib qsort().
>>>> Is this a good decision? WIP.
>>>>
>>>> As for storing the data into a file... how should I do it so that it
>>>> has the shape or structure of a 'material density object'?
>>>> Unfortunately today's code is not yet working. I send it anyways in the
>>>> hopes of receiving much appreciated feedback.
>>>>
>>>> Cheers!!
>>>> 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
