> On Jul 17, 2017, at 2:42 PM, Mario Meissner <mr.rash....@gmail.com> wrote:
>
> It took me way longer than it should have and I don't know how to round up
> the edges but here goes an initial rough model of the blade using two arb6
> primitives.
Looks like you tried features of both blade types, but that results in
something that is (incorrectly) both a distal and profile taper instead of one
or the other. For the overall shape, you have the right idea that you want to
intersect with an arb6 that runs the length (for distal) or height (for
profile). Think about the shape without the curve. You probably want a
box/rpp/arb8 on top of an arb6 wedge underneath, intersected with an arb6
running the length. That'd give a basic (long) tapered axe shape. Try that?
The curve is definitely hard. Anyone have an idea how to model that accurately?
> You suggest that instead of having an exact function like I proposed, we
> should specify a set of segments with their densities and interpolations?
No. The segments are what you actually get during geometry evaluation (during
ray tracing) with tools like rtweight. A ray is evaluated against geometry and
you get back a list of partitions, each partition consisting of one or more
segments, each segment having an in and out hit point.
> If I'm understanding you correctly, we should let the user define any
> arbitrary number of segments in a manner that is similar to the pseudo-code I
> wrote, and this set of segments should then be somehow managed in a way that
> the calling code can request the information about those (and any other as
> well?) segments of the material?
This is where it’d probably be beneficial to revisit the viewweight.c code and
the code tutorials to make sure you understand how they evaluate. They shoot a
grid of rays (which represent cross-sectional area per ray), with hits on
geometry resulting in segments, and then tabulate up all of the segments (which
give a cross-sectional volume estimate). The function in your example doesn’t
relate to how the code works, so there’s a bit of a mismatch.
I was suggesting how to perform the assessment in relation to what you’ll have
to do in code, so make sure you really do understand what is going on there.
> If we used my function, we could technically extract the information we need
> about those segments, don't we? The start and end points are straightforward,
> as that's what the function returns. We just feed it the coordinates. For the
> interpolation, we just need to take the derivative alongside the segment to
> see how it behaves (I guess this could be the problematic part). But
> transforming the information the user gives through those commands into a
> function, and then extracting it again out of the function may be an
> unnecessary step, I realize.
Understanding mismatch. ;) I think you’re relating this in abstract terms and
it’ll be more clear when you realize what that means in terms of code.
> Interesting! This could be an advanced example case. Looks difficult to model
> though.
Easy to import something like it, but that was just an example to aid in
understanding practical utility, not for setting up a test case.
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
