Hi Sean!
Back from my trip now.
The reason why I worked on projections is because you told me to do so:
Not the distance between points, but distance to their transition vectors.
> From the prior e-mail, the way this should fully generalize can be handled
> by projecting points onto the ray, and projecting any transition vectors
> onto the ray. Then for a given ray, it can fully handle just about any
> transition type.
>
> To see how this will work, it will likely be necessary to redo rtexample
> and get 2-points working without any vectors. You project each point onto
> the ray.
>
> ptA ptB
> | |
> IN v v OUT
> ray o--ptA'----ptB'---o
>
> Density from IN to ptA’ is density(ptA).
> Density from ptB’ to OUT is density(ptB).
> Density from ptA’ to ptB’ is density(ptA) until the midpoint between ptA’
> and ptB’. Thus the section’s average density would be density(ptA)/2 +
> density(ptB)/2But
>
But I now realize as well that taking the mid-point between projections
does not give us the actual boundary between the polygons.
We could work with the mesh like you mention, or we could do a slight
modification to the current code to compute the actual boundaries while
walking through the points (probably our already available projections,
we'll see). It's probably a simple trigonometry problem, and I'll try to
come up with the operation we need to do to obtain the boundaries in a
segment.
In the attached picture we can see that we need the two blue lines to be
equal in length. Aligning some equations to fit that property may easily
give us the distance from each projected point where the boundary lays.
Unless I'm overseeing something important I think this way would be
sufficient and really easily implementable. The example I'll send this
afternoon may prove me wrong, in which case I'll consider the mesh.
I think I can implement this and leave the code clean before leaving.
Thank you for your feedback!
Mario.
On 20 August 2017 at 00:03, Christopher Sean Morrison <brl...@mac.com>
wrote:
>
> > On Aug 17, 2017, at 6:28 AM, Mario Meissner <mr.rash....@gmail.com>
> wrote:
> >
> > 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).
>
> Again, I don’t think you should introduce a notion of vectors. For now,
> points will be adequate and present plenty of challenges.
>
> Consider shooting a ray along the X-axis (pnt -1000 0 0; dir 1,0,0) with a
> density point at 0,10,0 and 10,-5,0. Say you enter geometry at 1,0,0 and
> exit at 9,0,0
>
> density
> point A
> o (0,10,0) ___(9,0,0) ray exits
> | /
> | v
> o-> o—x========x-o
> ray (1,0,0) |
> ray o (10,-5,0)
> enters B density point
>
>
>
> With just those two points (A & B), the voronoi density field splits
> halfway between A and B, which has a midpoint above the x-axis and runs
> diagonally across the ray path.
>
> If we simply project, it’ll be the wrong contribution. That’s where I was
> suggesting in the prior e-mail to actually construct the voronoi mesh and
> you’ll get that actual edge between A and B, and calculating where the ray
> intersects that edge becomes trivial.
>
> > • 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.
>
> We are in no way constrained by memory.
>
> > • 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.
>
> Shouldn’t need to sort with a voronoi mesh, but nothing wrong with using
> plain arrays + size variables.
>
> > • 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.
>
> If you eliminate vectors and projections, I think this one becomes moot.
> That said, definitely comment the code.
>
> > I will assume that what I propose doing is good unless I hear feedback
> telling me otherwise.
>
> Your e-mail that followed this was golden, as you essentially demonstrated
> that straight-up projections weren’t going to work for even a simple 3
> point case without changes. That implies you went in the right direction,
> learned something, and now need to adjust accordingly. ;)
>
> Cheers!
> Sean
>
>
>
> ------------------------------------------------------------
> ------------------
> 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
>
------------------------------------------------------------------------------
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
