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
