Hey Sean!
Glad to hear back from you! Hope your trip went fine.
Tons of new information! Let me try to dig through it.
Both this prior version and the latest viewweight.c suffer from the comment
> I originally made, namely that the 0 and 1 point cases are not what i would
> call “complete". That’s not to say that they’re not working — but that the
> code is not in a usable state yet such that it could be used by a user
> (e.g., today). That’s mostly because the code is not actually querying a
> density in query_density() which implies sorting out where these
> specifications are coming from, how they will be specified, etc. They’re
> hard-coded. When we talk about coding complete, it means taking a minimal
> feature to completion.
>
Fair enough. My next goal will be to make our initial minimal feature
working. In this case this means having a way to let the user define points
that will be used for query_density(), instead of hardcoding them. I guess
for now I will use the .density file as I have no idea how the whole
"material objects" thing should work, yet.
An approach that avoids the issue is to piggyback on the old ID system and
> plan for this new system to utilize material objects (containing this new
> information), as discussed previously. This implies changing materialID to
> point to object names instead of a number, so there’s no dual
> specification, and implementing at least the bare bones to store a point as
> an object instead of as an id#. The calling code is then unambiguous,
> meaning one or the other. It’s possible there’s not enough time remaining
> in socis to even do 0-points in this manner… but it’s the approach needed
> to make this actually get used as soon as possible.
I guess it's up to you to decide what I should focus on. I could work on
the basics of this new approach so that future work on it can then build on
it and eventually finish it, but that would mean quite a change to what our
initial goal for the socis period was. I'm totally fine with either way.
In a 0-point system, the density_point pointer would be null and is handled
> trivially as massless. In an N-point system without vectors, you can
> project each point onto the shotline to determine which field you are
> contained within. This would handle the earlier case of discontinuous
> density transitions.
>
> Then, defining vectors similarly will project onto the shotline and
> defines a different (linear / continuous) transition. That would be the
> fully general way to handle the half-space concept mentioned earlier. It
> also becomes easy to support things like radial transitions. You would
> define factors for the starting and end points in the density_vector struct
> along with the transition type (e.g., linear vs. radial vs. step).
>
> If I had a region that was some advanced material — e.g., kevlar with
> different density for the horizontal and vertical strands — and I set a
> density in one horizontal strand, I would expect it to apply to the whole
> strand in flood-fill fashion (there are no vectors). Similarly, if I
> defined the material of the neighboring vertical strand, it would apply and
> the two should have no interaction.
>
I agree and understand all of this. Sounds like we will need to reshape
lots of stuff to make this all fit. I guess bit by bit is the way to go, as
always.
However... ->
I think this [checking if there are overlapping points] can also be handled
> by changing the way vectors are being defined (or perhaps what they mean).
> Instead of having a concept of origins and detachment of point densities,
> let density_vector actually refer to a density_point and let the other
> struct fields encode the nature of the contribution (effectively combining
> your struct combination data into one concept).
>
I'm afraid I'm not following you here. Could you detail this out a bit
more? The referenced density_point would be the origin of the vector? (if
not, what is it?). The 'nature' of the contribution would be something like
rate: linear, quadratic, etc.? And how does this change help us check if
there are overlapping points?
>From the rest of the answers in your emails I think I got the idea that you
want to let the user specify both points and vectors as if they were two
means of describing density. Then a vector should be something like a
superset of the point, where we can specify some more information about it
to describe the continuous transition between the two points the vector
spans. Don't we need to reference two density_points then?
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.
>
[omitted]
>
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)/2.
Doesn't this method depend too much on the direction from which the rays
come? For example, ptA could be really far from 'IN' if you shoot from
above but really close to it if you shoot from the side. If ptA was the
heaviest point, then shooting from above will turn a huge part of the
material into really heavy, and shooting from the side should weight much
less. I'm not sure if I'm talking nonsense here, I'll check with an actual
example to see it working, but this was my first thought when I saw it.
For now I'll make my code fully 'complete', as you mention. Then I will get
rid of my 'origins' and make projections onto the shotline (but this will
require some more discussions as I'm not 100% sure how this would all work
and fit together, especially points with no vectors [the question above]).
At some point in the future we will need to take the distance to the
shotline into consideration to make a 'fair' average of contributions, as
you suggested.
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
