> 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
