I found a flaw in my current code.
I considered all points to be valid and projected them to calculate the
final density. However, not always do we need all points to be projected.
In the attached picture we can see that the diagonal red line doesn't use
the black region so we shouldn't be projecting it.
I think one way to solve it is to project only those who's distance to the
original point is closer than to any other point. We will need to loop
through all points for every point though, which is at least O(n^2).
I also ended up using absolute points to compute those distances so ignore
my talk about stuff being relative.
Currently working on the fix so I'll send new code for that tomorrow.
Just wanted to let you know that I found the flaw and am working on it.
Also sorry for the avalanche of emails, but I prefer mailing too much than
too little.
Mario.
2017-08-18 19:02 GMT+02:00 Mario Meissner <mr.rash....@gmail.com>:
> Sean,
> So I've given the transition concept a deep thought and I think I may have
> found one way it could work.
> We define a transition object that links to two points and has a float
> value stored. This value indicates the rate of change between the two
> points. How does it indicate it in a way that is useful for us to perform
> computations on it?
> Let's consider a transition situation. One point higher (value) than the
> other, and separated by a certain distance. Lets now take the value of the
> function right in the middle between those two points. If the transition
> were linear, then that value should exactly be the mean value of the two
> points. If it's not, then some sort of quadratic rate of change is
> happening (let's assume for now that in between the points the values can't
> grow above or below the higher and lower points respectively, and let's for
> now only give support to parabolas). The value we store in the structure
> could somehow represent where the value in the middle of the points sits.
> For example a value of 1 could represent that it's exactly the mean value,
> meaning linear transition. A value closer to 0 would mean below the mean
> value, and above 1 greater. Once we have this new point (and we might want
> to compute some more points as well using that value) we can safely compute
> the numerical integral using Newton-Cotes or Simpson. Now, before starting
> to work on this I would highly recommend to discuss it a bit more.
>
> I'm also a bit worried about what might happen if there are non-transition
> points in between a transition. Should it be an illegal state? It's almost
> impossible to avoid it, since depending from where you shoot the rays, a
> projection could always potentially land inside a transition vector.
>
> Id also love to see something like the Voronoi diagram you showed me but
> with support for transitions. I'm still not sure how it would work. If I
> look at the diagrams and try to imagine how it would look like with one
> transition on it, I can't come up with anything logical. How does the
> transition interact with non-transition points? Between non-transition
> points there is a line indicating when we change from one value to another.
> What happens between a non-transition point, and a transition point? Is
> there a line, or not? There should be because there is no transition
> between that point and the vector, but ... how and where? Is there any
> example available? I tried looking for it but didn't find anything.
>
> I hope you'll find some time to discuss this soon.
> Mario.
>
> 2017-08-18 17:40 GMT+02:00 Mario Meissner <mr.rash....@gmail.com>:
>
>> Hello everyone.
>> Quick question regarding bu_lists.
>>
>> When I BU_LIST_PUSH to the tail of the list, and then BU_LIST_FOR through
>> them, why do I get the last element first? I expected PUSH to put the
>> element behind all other elements, and then FOR to roll through them from
>> front to back, showing me the elements in the order I pushed them.
>>
>> Do I need to use APPEND and keep a pointer to my last added element to
>> get the behaviour I need? Why?
>>
>> Mario.
>>
>> 2017-08-18 13:38 GMT+02:00 Mario Meissner <mr.rash....@gmail.com>:
>>
>>> 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
