[brlcad-devel] Example of heterogeneous density + mass calculation

[Mario Meissner]

Hello.

I have calculated the mass of an example of an heterogeneous object using a
function that defines the density of an object in each point in space, and
integration to obtain it's mass.
You can see it here:
https://drive.google.com/file/d/0Bz6hfFobLeoyZC1vQ1JwSU05NDg/view

I believe that this model can give support to most types of heterogeneous
density objects, and can be easily calculated with arbitrary precision by a
computer. Support for non-continuous densities may also be easy to
implement alongside this model by using functions with different
definitions for different regions.

However, as I do not yet understand how rtweight currently behaves, I do
not know if this model is viable and what other considerations one needs to
make.

I'll await feedback on this model, and help on understanding the source
code and current behaviour.

Mario.

[Daniel Roßberg]

Hi Mario,

Well, the rt in rtweight comes from ray-trace. I.e., this program shoots a
series of rays at the model. The hit() function in src/rt/viewweight.c
determines what shall be done when one of these rays hits a region.

First, it determines the length of the ray inside the region (line 133).
Then, beginning at line 157, it computes the volume which this ray
represents (base on the cell sizes and hypersampling), takes the
line-of-sight into account (which is 100% if the region is fully filled by
the assigned material), and writes the resulting mass into dp->weight.

For heterogeneous regions you need to know exactly where the ray intersect
the region. These intersection points are ihitp->hit_point
and ohitp->hit_point, I assume.

Hope this helps,
Daniel

Post by Mario Meissner
Hello.
I have calculated the mass of an example of an heterogeneous object using
a function that defines the density of an object in each point in space,
and integration to obtain it's mass.
You can see it here: https://drive.google.com/file/d/
0Bz6hfFobLeoyZC1vQ1JwSU05NDg/view
I believe that this model can give support to most types of heterogeneous
density objects, and can be easily calculated with arbitrary precision by a
computer. Support for non-continuous densities may also be easy to
implement alongside this model by using functions with different
definitions for different regions.
However, as I do not yet understand how rtweight currently behaves, I do
not know if this model is viable and what other considerations one needs to
make.
I'll await feedback on this model, and help on understanding the source
code and current behaviour.
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
https://lists.sourceforge.net/lists/listinfo/brlcad-devel

[Christopher Sean Morrison]

[snip]
However, as I do not yet understand how rtweight currently behaves, I do not know if this model is viable and what other considerations one needs to make.

I suggest reading through these links (from bottom to top) and studying them in detail: http://brlcad.org/wiki/Developing_applications <http://brlcad.org/wiki/Developing_applications>

Some headers and function arguments may have changed slightly, but the basic structure of a ray-trace application like rtweight is a pretty straightforward function callback application, which is what those documents cover.

Cheers!
Sean

[Mario Meissner]

Sean,
this was exactly what I was looking for. Will study through it. I'll get
back to you hopefully tomorrow with thoughts on this documentation.
To your questions in our last email:

- I believe that users could input the density properties of the
material into the properties file by writing the coefficients of the
function in some predefined way. For example, the function I used in my
example could be an entry in the file like this: 3; 2; 3; -5
I imagine that one way users can input the information though a
helper-script is to indicate specific densities at different points in the
body, and then indicating if the change is linear, quadratic... etc, for
each direction.
Example: a cylinder which is dense in the bottom and not so much in the
top, but constant in the horizontal plane. We could tell the script
something like: bottom is 30 g/cm3, and top is 10g/cm3. As we go from
bottom to top, density changes in a linear fashion. If we move in the
horizontal plane, there is no change.

However, one problem I see here is that, depending where the object is
placed and what it's dimensions are, the densities that it ends up having
are completely different. If one models a density function for a specific
sword, It would not be possible to use the same material for other swords
of different shapes and sizes. May it be better to define the function as
RELATIVE to the position of the body? For example, 0,0,0 for the bottom
front left of the object, and 1,1,1 for the top back right? What are your
thoughts on this?

- To the question of how we would be able to see the different density
values as we go through the object: No matter from which direction and in
which point of the object we go though, in the end the ray is a line in a
three dimensional space. We just need to join the two equations that define
the ray with the density function, and we will obtain a function that
returns the density for each point of the ray that is inside the region.
This function is also single-variable, since we only need to know the
distance to the origin of the ray to choose a point (thus,
geometry-agnostic, as you mentioned?). Is this what you meant?


Daniel,
thank you for the hints and details. After doing what Sean suggested, I
will come back to reading through viewweight.c and checking what you
mentioned.


Mario.

[snip]
However, as I do not yet understand how rtweight currently behaves, I do
not know if this model is viable and what other considerations one needs to
make.
I suggest reading through these links (from bottom to top) and studying
them in detail: http://brlcad.org/wiki/Developing_applications
Some headers and function arguments may have changed slightly, but the
basic structure of a ray-trace application like rtweight is a pretty
straightforward function callback application, which is what those
documents cover.
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
https://lists.sourceforge.net/lists/listinfo/brlcad-devel

[Christopher Sean Morrison]

I believe that users could input the density properties of the material into the properties file by writing the coefficients of the function in some predefined way. For example, the function I used in my example could be an entry in the file like this: 3; 2; 3; -5

But what function and how would it be specified? Would it be obvious or intuitive how many arguments are required or something dynamic?

I imagine that one way users can input the information though a helper-script is to indicate specific densities at different points in the body, and then indicating if the change is linear, quadratic... etc, for each direction.

Okay! That is getting somewhere.. The actual input method (e.g. Script or commands or whatever) aren't as important as the "what" being specified.

Example: a cylinder which is dense in the bottom and not so much in the top, but constant in the horizontal plane. We could tell the script something like: bottom is 30 g/cm3, and top is 10g/cm3. As we go from bottom to top, density changes in a linear fashion. If we move in the horizontal plane, there is no change.

So that sounds like test case #3 perhaps. Can you write all three up as a (language agnostic) statement? For example, specifying a radial property on a sphere might look like something like this in quasi-pseudocode:

make sphere

However, one problem I see here is that, depending where the object is placed and what it's dimensions are, the densities that it ends up having are completely different. If one models a density function for a specific sword, It would not be possible to use the same material for other swords of different shapes and sizes. May it be better to define the function as RELATIVE to the position of the body?

All entities have a local reference system that I think the points would/could be relative to by specification. See the V parameter on most primitives, or some other position that is considered their key point (origin). They also have a bounding box and natural orientation.

For example, 0,0,0 for the bottom front left of the object, and 1,1,1 for the top back right? What are your thoughts on this?

Check out the Mged tutorial series, and look at the appendix at the end for a list of primitives. Loves keep this simple for now just considering a box, cylinder, or sphere.

To the question of how we would be able to see the different density values as we go through the object: No matter from which direction and in which point of the object we go though, in the end the ray is a line in a three dimensional space. We just need to join the two equations that define the ray with the density function, and we will obtain a function that returns the density for each point of the ray that is inside the region. This function is also single-variable, since we only need to know the distance to the origin of the ray to choose a point (thus, geometry-agnostic, as you mentioned?). Is this what you meant?

It is exactly. What that means on a box and how to handle it is where is gets a bit tricky. We need a concrete example.

Cheers!
Sean

[Mario Meissner]

Hi Sean.


- You are right, given the endless possibilities of a function like
this, it may not be obvious to define the function in the file as I
mentioned. Some re-considerations would need to be made in order to support
any number of arguments, any polynomial degree. Who knows, maybe the user
wants to define the density as a function of the sine or cosine ... (Taylor
series could be used for these cases... but maybe better figure out the
basic stuff first).

- Attached goes an example of how to obtain a function that gives us the
density a ray sees at is crosses the object. Summing it up, I used the two
equations that define a line in a 3d space, and made substitution on the
original density function. The resulting function returns the density of
the material on each point of the ray. All the extra information gets
"wiped off" and thus the resulting function is only dependent on a single
variable. We could even transform this function to make it dependent on the
distance to the origin of the ray instead of one of the space coordinates,
thus eliminating "space" completely.

https://drive.google.com/file/d/0Bz6hfFobLeoyU01wMTFvcGVhUWc/view?usp=drivesdk

- For this new example box, I would define the density in
language-agnostic terms or pseudo-code as the following:
set box origin density 3; 1,0,0 linear density 5; 0,1,0 linear
density 6; 0,0,1 linear density 1.
Here I would read it in natural language like:
At the origin the density of the box is 3. If we go towards 1,0,0 we
will find that the density changes linearly until it is 5. If we go towards
0,1,0 it will change linearly until it is 6... etc.

Cheers,
Mario.

Post by Mario Meissner
- I believe that users could input the density properties of the
material into the properties file by writing the coefficients of the
function in some predefined way. For example, the function I used in my
example could be an entry in the file like this: 3; 2; 3; -5
But what function and how would it be specified? Would it be obvious or
intuitive how many arguments are required or something dynamic?
- I imagine that one way users can input the information though a
helper-script is to indicate specific densities at different points in the
body, and then indicating if the change is linear, quadratic... etc, for
each direction.
Okay! That is getting somewhere.. The actual input method (e.g. Script
or commands or whatever) aren't as important as the "what" being specified.
- Example: a cylinder which is dense in the bottom and not so much in
the top, but constant in the horizontal plane. We could tell the script
something like: bottom is 30 g/cm3, and top is 10g/cm3. As we go from
bottom to top, density changes in a linear fashion. If we move in the
horizontal plane, there is no change.
So that sounds like test case #3 perhaps. Can you write all three up as a
(language agnostic) statement? For example, specifying a radial property
make sphere
- However, one problem I see here is that, depending where the object
is placed and what it's dimensions are, the densities that it ends up
having are completely different. If one models a density function for a
specific sword, It would not be possible to use the same material for other
swords of different shapes and sizes. May it be better to define the
function as RELATIVE to the position of the body?
All entities have a local reference system that I think the points
would/could be relative to by specification. See the V parameter on most
primitives, or some other position that is considered their key point
(origin). They also have a bounding box and natural orientation.
- For example, 0,0,0 for the bottom front left of the object, and
1,1,1 for the top back right? What are your thoughts on this?
Check out the Mged tutorial series, and look at the appendix at the end
for a list of primitives. Loves keep this simple for now just considering
a box, cylinder, or sphere.
- To the question of how we would be able to see the different density
values as we go through the object: No matter from which direction and in
which point of the object we go though, in the end the ray is a line in a
three dimensional space. We just need to join the two equations that define
the ray with the density function, and we will obtain a function that
returns the density for each point of the ray that is inside the region.
This function is also single-variable, since we only need to know the
distance to the origin of the ray to choose a point (thus,
geometry-agnostic, as you mentioned?). Is this what you meant?
It is exactly. What that means on a box and how to handle it is where is
gets a bit tricky. We need a concrete example.
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
https://lists.sourceforge.net/lists/listinfo/brlcad-devel

[Christopher Sean Morrison]

Post by Mario Meissner
Hi Sean.
• You are right, given the endless possibilities of a function like this, it may not be obvious to define the function in the file as I mentioned. Some re-considerations would need to be made in order to support any number of arguments, any polynomial degree. Who knows, maybe the user wants to define the density as a function of the sine or cosine ... (Taylor series could be used for these cases... but maybe better figure out the basic stuff first).

In the general case, we do not necessarily know the “shape" of the geometry, particularly having an equation for the geometry to substitute in a line equation like in your case. For example, the sword blade case might be constructed as a union of several objects, like if you model this example: Loading Image...

That would make for a really good simple test case! Try and model either of them.

Post by Mario Meissner
• Attached goes an example of how to obtain a function that gives us the density a ray sees at is crosses the object. Summing it up, I used the two equations that define a line in a 3d space, and made substitution on the original density function. The resulting function returns the density of the material on each point of the ray. All the extra information gets "wiped off" and thus the resulting function is only dependent on a single variable. We could even transform this function to make it dependent on the distance to the origin of the ray instead of one of the space coordinates, thus eliminating "space" completely.

Instead of considering the ray line, whose intersection with geometry is already covered in a *_shot() function, consider line segments. Basically, sets of in/out points (segments) are what you get during geometry evaluation. Example of two segments (s0 and s1) with two in-points (t0 and t2) and two out-points (t1 and t3):

s0 s1
o———————————o o———————o
t0 t1 t2 t3

With segments, it begs for some function that says — for a given object — what the density is at point t2, for example, or what the density is from t1 to t2 and t2 to t3. If calling code knows the density goes from 0.1 at t0 and 0.5 at t1, then it can integrate to know the average density is 0.3 and represents a 3D mass of XXX*0.3 mm^3.

What’s missing is a density specification that, given t0, t1, or both, can report the 0.1, 0.5, or 0.3 values.

The simplest starting point that comes to my mind would be simple 3D density points that are interpolated. Something like this becomes relevant: http://docs.qgis.org/2.2/pt_PT/docs/gentle_gis_introduction/spatial_analysis_interpolation.html

Post by Mario Meissner
set box origin density 3;
1,0,0 linear density 5;
0,1,0 linear density 6;
0,0,1 linear density 1.

I think this is on the right track for density specification. The important bits are that we define a set of 3D points, a density at each point, and an interpolation method for in between. Lets keep it that simple.

Post by Mario Meissner
At the origin the density of the box is 3. If we go towards 1,0,0 we will find that the density changes linearly until it is 5. If we go towards 0,1,0 it will change linearly until it is 6... etc.

Agreed, this is good! Only suggestion I think would be to normalize the values into a 0.0 to 1.0+ range as a density multiplier. This way, would could apply the same distribution to different materials. It will also avoid having conflicting specifications. We can still say “this is bone” which has 1.75 g/cm^3 and which would equate to a 1.0 density function value. What do you think?


As an aside, here’s a nifty real-world application where we might instruct a 3D printer to adjust the density of a car’s frame (e.g., the density of some internal lattice structure) based on how rigid that part of the frame needs to be: https://ucarecdn.com/1e2fd4d4-da99-41e0-86ff-3f357dab8181/-/preview/1440x1080/

For that case, you’d pick any one of the densities as your normalized density (or use the density of the plastic being used), and then have a 3D point cloud specifying the densities of various zones.

Cheers!
Sean

[Mario Meissner]

Hello Sean.

In the general case, we do not necessarily know the “shape" of the

Post by Christopher Sean Morrison
geometry, particularly having an equation for the geometry to substitute in
a line equation like in your case. For example, the sword blade case might
be constructed as a union of several objects, like if you model this
example: http://www.shopwingchun.com/ewcblog/uploads/blade-tapers.jpg
That would make for a really good simple test case! Try and model either of them.

Good idea to have a test case like this one that is not as straightforward
as as a box :). Will start modeling it!

Post by Christopher Sean Morrison
Instead of considering the ray line, whose intersection with geometry is
already covered in a *_shot() function, consider line segments. Basically,
sets of in/out points (segments) are what you get during geometry
evaluation. Example of two segments (s0 and s1) with two in-points (t0 and
s0 s1
o———————————o o———————o
t0 t1 t2 t3
With segments, it begs for some function that says — for a given object —
what the density is at point t2, for example, or what the density is from
t1 to t2 and t2 to t3. If calling code knows the density goes from 0.1 at
t0 and 0.5 at t1, then it can integrate to know the average density is 0.3
and represents a 3D mass of XXX*0.3 mm^3.
What’s missing is a density specification that, given t0, t1, or both, can
report the 0.1, 0.5, or 0.3 values.
The simplest starting point that comes to my mind would be simple 3D
density points that are interpolated. Something like this becomes
relevant: http://docs.qgis.org/2.2/pt_PT/docs/gentle_gis_
introduction/spatial_analysis_interpolation.html

• For this new example box, I would define the density in
set box origin density 3;
1,0,0 linear density 5;
0,1,0 linear density 6;
0,0,1 linear density 1.

I think this is on the right track for density specification. The
important bits are that we define a set of 3D points, a density at each
point, and an interpolation method for in between. Lets keep it that
simple.

You suggest that instead of having an exact function like I proposed, we
should specify a set of segments with their densities and interpolations?
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?

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.

Post by Christopher Sean Morrison

At the origin the density of the box is 3. If we go towards 1,0,0 we

will find that the density changes linearly until it is 5. If we go towards
0,1,0 it will change linearly until it is 6... etc.
Agreed, this is good! Only suggestion I think would be to normalize the
values into a 0.0 to 1.0+ range as a density multiplier. This way, would
could apply the same distribution to different materials. It will also
avoid having conflicting specifications. We can still say “this is bone”
which has 1.75 g/cm^3 and which would equate to a 1.0 density function
value. What do you think?

Yes, good idea. So there are two elements here: material and density
distribution?. Density distributions are normalized and can be applied to
many materials, each one with a different base density. Nice!

As an aside, here’s a nifty real-world application where we might instruct

Post by Christopher Sean Morrison
a 3D printer to adjust the density of a car’s frame (e.g., the density of
some internal lattice structure) based on how rigid that part of the frame
needs to be: https://ucarecdn.com/1e2fd4d4-da99-41e0-86ff-3f357dab8181/-/
preview/1440x1080/
For that case, you’d pick any one of the densities as your normalized
density (or use the density of the plastic being used), and then have a 3D
point cloud specifying the densities of various zones.

Interesting! This could be an advanced example case. Looks difficult to
model though.

Mario.

[Mario Meissner]

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.

Post by Mario Meissner
Hello Sean.
In the general case, we do not necessarily know the “shape" of the

Post by Christopher Sean Morrison
geometry, particularly having an equation for the geometry to substitute in
a line equation like in your case. For example, the sword blade case might
be constructed as a union of several objects, like if you model this
example: http://www.shopwingchun.com/ewcblog/uploads/blade-tapers.jpg
That would make for a really good simple test case! Try and model either of them.

Good idea to have a test case like this one that is not as straightforward
as as a box :). Will start modeling it!

Post by Christopher Sean Morrison
Instead of considering the ray line, whose intersection with geometry is
already covered in a *_shot() function, consider line segments. Basically,
sets of in/out points (segments) are what you get during geometry
evaluation. Example of two segments (s0 and s1) with two in-points (t0 and
s0 s1
o———————————o o———————o
t0 t1 t2 t3
With segments, it begs for some function that says — for a given object —
what the density is at point t2, for example, or what the density is from
t1 to t2 and t2 to t3. If calling code knows the density goes from 0.1 at
t0 and 0.5 at t1, then it can integrate to know the average density is 0.3
and represents a 3D mass of XXX*0.3 mm^3.
What’s missing is a density specification that, given t0, t1, or both,
can report the 0.1, 0.5, or 0.3 values.
The simplest starting point that comes to my mind would be simple 3D
density points that are interpolated. Something like this becomes
relevant: http://docs.qgis.org/2.2/pt_PT/docs/gentle_gis_introduction/
spatial_analysis_interpolation.html

• For this new example box, I would define the density in
set box origin density 3;
1,0,0 linear density 5;
0,1,0 linear density 6;
0,0,1 linear density 1.

I think this is on the right track for density specification. The
important bits are that we define a set of 3D points, a density at each
point, and an interpolation method for in between. Lets keep it that
simple.

You suggest that instead of having an exact function like I proposed, we
should specify a set of segments with their densities and interpolations?
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?
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.

Post by Christopher Sean Morrison

At the origin the density of the box is 3. If we go towards 1,0,0 we

will find that the density changes linearly until it is 5. If we go towards
0,1,0 it will change linearly until it is 6... etc.
Agreed, this is good! Only suggestion I think would be to normalize the
values into a 0.0 to 1.0+ range as a density multiplier. This way, would
could apply the same distribution to different materials. It will also
avoid having conflicting specifications. We can still say “this is bone”
which has 1.75 g/cm^3 and which would equate to a 1.0 density function
value. What do you think?

Yes, good idea. So there are two elements here: material and density
distribution?. Density distributions are normalized and can be applied to
many materials, each one with a different base density. Nice!
As an aside, here’s a nifty real-world application where we might instruct

Post by Christopher Sean Morrison
a 3D printer to adjust the density of a car’s frame (e.g., the density of
some internal lattice structure) based on how rigid that part of the frame
needs to be: https://ucarecdn.com/1e2fd4d4-
da99-41e0-86ff-3f357dab8181/-/preview/1440x1080/
For that case, you’d pick any one of the densities as your normalized
density (or use the density of the plastic being used), and then have a 3D
point cloud specifying the densities of various zones.

Interesting! This could be an advanced example case. Looks difficult to
model though.
Mario.

[Christopher Sean Morrison]

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

[Mario Meissner]

Okay, so let's make sure I understand the current code before continuing
with the new specifications.

About the blade, yes I tried to just mix both because that made it simpler.

Tomorrow I'll make the new blade (without the curve) and get going with the
code. It seems like I'm missing some basic concepts on what's going on
inside. I'll try to understand it as good as I can and then ask some
questions on what isn't clear to me. Is there any documentation on what
exactly happens during geometry evaluation and ray tracing in general?

Thank you for your time.
Mario.

Post by Mario Meissner
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

Post by Mario Meissner
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

Post by Mario Meissner
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

Post by Mario Meissner
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

Post by Mario Meissner
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
https://lists.sourceforge.net/lists/listinfo/brlcad-devel

[Christopher Sean Morrison]

Okay, so let's make sure I understand the current code before continuing with the new specifications.
About the blade, yes I tried to just mix both because that made it simpler.
Tomorrow I'll make the new blade (without the curve) and get going with the code. It seems like I'm missing some basic concepts on what's going on inside. I'll try to understand it as good as I can and then ask some questions on what isn't clear to me. Is there any documentation on what exactly happens during geometry evaluation and ray tracing in general?

This example is about as simple as it gets code-wise:

http://brlcad.org/wiki/Example_Application

For the abstract conceptual concepts of ray tracing, anything that talks about “solid” or “full path” ray tracing is generally relevant (as opposed to ray tracing for image synthesis, rendering pictures). Coincidentally relevant: http://slideplayer.com/slide/9271245/

What usually gets in the way are preconceptions. Consider for example an object, some unknown object. You don’t (yet) know what it looks like, how big it is, etc. All you have is a special ray/gun that shoots an infinitely thin ray through the object and tells you when you entered and exited the object. So you shoot a ray and hit it:

shoot entry exit
o-> ray . . . . . hit o–-–––o hit
6mm

All you know at this point is that you hit it and 6mm later, the ray exited the object. That by itself isn’t very useful, but we can shoot a whole set of rays, each from a different position, and we start to get a picture of what the object looks like:

o-> ray1 o–o
o-> ray2 o–––––o
o—> ray3 o––––––––—o
o-> ray4 o–––––––––––——o
o—> ray5 o—––––––——o
o-> ray6 o–––––o
o-> ray7 o–o

We start to see it looks a bit like a rotated cube. Moreover, knowing the length of each segment and the spacing of the rays, we could actually get an estimate of area:

o-> ray1 o–o 2mm
o-> ray2 o–––––o 6mm
o—> ray3 o––––––––—o 10mm
o-> ray4 o–––––––––––——o 14mm
o—> ray5 o—––––––——o 10mm
o-> ray6 o–––––o 6mm
o-> ray7 o–o 2mm
––––
with 2mm spacing between rays: 50mm x 2mm = 100mm^2 area

It’s probably a 10mm x 10mm square. Extend that example into layer after layer of samples and you don’t just have an area estimate, but now you have a (3D) volume estimate because each ray represents a 2D cross section (e.g., 2mm^2) which can be multiplied by each segment length:

with 2mm spacing between rays: 50mm x 2mm x 2mm = 200mm^3 volume

With a volume estimate and knowing density, you can obviously calculate mass too (mass = volume x density). And all of that was done without knowing anything about the geometry. That’s essentially what rtweight is doing.

With your project, we’re changing the last step. In mathematical terms, we were doing a summation over all the individual volume bits, multiplying each by a constant density. New form, everything stays the same except we’re either going to multiply the volume by a different (e.g., average) density based on a function or we’re going to further parameterize the volume so an volume/mass integral can be estimated.

Cheers!
Sean

[Mario Meissner]

Sean,
thank you for the extensive explanation, and sorry for the
misunderstanding. When you said that "instead of considering the ray line
lets consider segments" I thought that these segments were something else
not related to the rays. Let me attempt to summarize everything into a
bullet-list, see if things start getting clearer. I'll try to be specific,
and there probably will be mistakes but that's intentional as I want to
make sure I understand everything well before moving on. Please correct me
on anything inaccurate or wrong.

- During ray-tracing, the calling code prepares the application and
ray-tracing instance and shoots rays at the geometry. The library code
containing the hit, miss and other functions handles the information it
receives when a ray hits geometry.
- The hit function receives a set of partitions in a circular linked
list, (taken from the example:) "each [partition] describing one in and
out segment of one region for each region encountered". So each
partition is basically a set of segments, and all partitions together tell
us all the stuff the ray went through. I assume there are many different
"partitions" because we put the segments of different regions in different
partitions, but also partitions can have more than one segment because we
can cross a region more than once with a ray.
- In rtweight specifically, each ray gets fired some distance away from
the other rays, in a grid. Thus we can think of the rays as a square tube,
that has 2mm side length for the square and goes through the geometry (I
assume these are the "cells" that appear in the code of viewweight.c) All
the volume captured inside will be handled by one call of the hit function.
Looping through all the partitions and obtaining the volume we crossed, and
the density assigned to the region, we compute the mass for each partition
and store it in some data structure (which seems to be this "datapoint"
thing). Finally we just need to add it all up and obtain our total mass.
- In order to support heterogeneous densities we need a representation
that allows us to provide the necessary information to the hit function,
who will query our representation to obtain the density of the in and out
points, and possibly the rate of change between the two. We then
integrate/interpolate to obtain the "average" density of our segment, so
that we can continue the same way we did in the point above.
- I guess the biggest "difficulty" here is to define a proper way of
telling the hit function what this rate of change between the points is.
Also storing a proper definition of the material density that allows for
this information to be queried easily. This is why storing functions and
taking derivatives is not a good idea. Instead we may want to store vectors
that tell the rate of change in several directions. Density at a specific
point could be retrieved by combining vectors and the rate of change
between two arbitrary points can be obtained through the vectors as well.

Will send new blade soon.

Mario.

Post by Mario Meissner

Post by Mario Meissner
Okay, so let's make sure I understand the current code before continuing

with the new specifications.

Post by Mario Meissner
About the blade, yes I tried to just mix both because that made it

simpler.

Post by Mario Meissner
Tomorrow I'll make the new blade (without the curve) and get going with

the code. It seems like I'm missing some basic concepts on what's going on
inside. I'll try to understand it as good as I can and then ask some
questions on what isn't clear to me. Is there any documentation on what
exactly happens during geometry evaluation and ray tracing in general?
http://brlcad.org/wiki/Example_Application
For the abstract conceptual concepts of ray tracing, anything that talks
about “solid” or “full path” ray tracing is generally relevant (as opposed
to ray tracing for image synthesis, rendering pictures). Coincidentally
relevant: http://slideplayer.com/slide/9271245/
What usually gets in the way are preconceptions. Consider for example an
object, some unknown object. You don’t (yet) know what it looks like, how
big it is, etc. All you have is a special ray/gun that shoots an
infinitely thin ray through the object and tells you when you entered and
shoot entry exit
o-> ray . . . . . hit o–-–––o hit
6mm
All you know at this point is that you hit it and 6mm later, the ray
exited the object. That by itself isn’t very useful, but we can shoot a
whole set of rays, each from a different position, and we start to get a
o-> ray1 o–o
o-> ray2 o–––––o
o—> ray3 o––––––––—o
o-> ray4 o–––––––––––——o
o—> ray5 o—––––––——o
o-> ray6 o–––––o
o-> ray7 o–o
We start to see it looks a bit like a rotated cube. Moreover, knowing the
length of each segment and the spacing of the rays, we could actually get
o-> ray1 o–o 2mm
o-> ray2 o–––––o 6mm
o—> ray3 o––––––––—o 10mm
o-> ray4 o–––––––––––——o 14mm
o—> ray5 o—––––––——o 10mm
o-> ray6 o–––––o 6mm
o-> ray7 o–o 2mm
––––
with 2mm spacing between rays: 50mm x 2mm = 100mm^2 area
It’s probably a 10mm x 10mm square. Extend that example into layer after
layer of samples and you don’t just have an area estimate, but now you have
a (3D) volume estimate because each ray represents a 2D cross section
with 2mm spacing between rays: 50mm x 2mm x 2mm = 200mm^3 volume
With a volume estimate and knowing density, you can obviously calculate
mass too (mass = volume x density). And all of that was done without
knowing anything about the geometry. That’s essentially what rtweight is
doing.
With your project, we’re changing the last step. In mathematical terms,
we were doing a summation over all the individual volume bits, multiplying
each by a constant density. New form, everything stays the same except
we’re either going to multiply the volume by a different (e.g., average)
density based on a function or we’re going to further parameterize the
volume so an volume/mass integral can be estimated.
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
https://lists.sourceforge.net/lists/listinfo/brlcad-devel

[Mario Meissner]

Hereby goes blade with a box (arb8) on top, intersected with with an arb6
that narrows towards the tip, and another arb6 added below and also
intersected with the other arb6, that makes the bottom of the blade sharp.
If we now also manage to model that curve, it should look pretty similar to
the Distal Taper.

Mario.

Post by Mario Meissner
Sean,
thank you for the extensive explanation, and sorry for the
misunderstanding. When you said that "instead of considering the ray line
lets consider segments" I thought that these segments were something else
not related to the rays. Let me attempt to summarize everything into a
bullet-list, see if things start getting clearer. I'll try to be specific,
and there probably will be mistakes but that's intentional as I want to
make sure I understand everything well before moving on. Please correct me
on anything inaccurate or wrong.
- During ray-tracing, the calling code prepares the application and
ray-tracing instance and shoots rays at the geometry. The library code
containing the hit, miss and other functions handles the information it
receives when a ray hits geometry.
- The hit function receives a set of partitions in a circular linked
list, (taken from the example:) "each [partition] describing one in
and out segment of one region for each region encountered". So each
partition is basically a set of segments, and all partitions together tell
us all the stuff the ray went through. I assume there are many different
"partitions" because we put the segments of different regions in different
partitions, but also partitions can have more than one segment because we
can cross a region more than once with a ray.
- In rtweight specifically, each ray gets fired some distance away
from the other rays, in a grid. Thus we can think of the rays as a square
tube, that has 2mm side length for the square and goes through the geometry
(I assume these are the "cells" that appear in the code of viewweight.c)
All the volume captured inside will be handled by one call of the hit
function. Looping through all the partitions and obtaining the volume we
crossed, and the density assigned to the region, we compute the mass for
each partition and store it in some data structure (which seems to be this
"datapoint" thing). Finally we just need to add it all up and obtain our
total mass.
- In order to support heterogeneous densities we need a representation
that allows us to provide the necessary information to the hit function,
who will query our representation to obtain the density of the in and out
points, and possibly the rate of change between the two. We then
integrate/interpolate to obtain the "average" density of our segment, so
that we can continue the same way we did in the point above.
- I guess the biggest "difficulty" here is to define a proper way of
telling the hit function what this rate of change between the points is.
Also storing a proper definition of the material density that allows for
this information to be queried easily. This is why storing functions and
taking derivatives is not a good idea. Instead we may want to store vectors
that tell the rate of change in several directions. Density at a specific
point could be retrieved by combining vectors and the rate of change
between two arbitrary points can be obtained through the vectors as well.
Will send new blade soon.
Mario.

Post by Mario Meissner
Okay, so let's make sure I understand the current code before

continuing with the new specifications.

Post by Mario Meissner
About the blade, yes I tried to just mix both because that made it

simpler.

Post by Mario Meissner
Tomorrow I'll make the new blade (without the curve) and get going with

the code. It seems like I'm missing some basic concepts on what's going on
inside. I'll try to understand it as good as I can and then ask some
questions on what isn't clear to me. Is there any documentation on what
exactly happens during geometry evaluation and ray tracing in general?
http://brlcad.org/wiki/Example_Application
For the abstract conceptual concepts of ray tracing, anything that talks
about “solid” or “full path” ray tracing is generally relevant (as opposed
to ray tracing for image synthesis, rendering pictures). Coincidentally
relevant: http://slideplayer.com/slide/9271245/
What usually gets in the way are preconceptions. Consider for example an
object, some unknown object. You don’t (yet) know what it looks like, how
big it is, etc. All you have is a special ray/gun that shoots an
infinitely thin ray through the object and tells you when you entered and
shoot entry exit
o-> ray . . . . . hit o–-–––o hit
6mm
All you know at this point is that you hit it and 6mm later, the ray
exited the object. That by itself isn’t very useful, but we can shoot a
whole set of rays, each from a different position, and we start to get a
o-> ray1 o–o
o-> ray2 o–––––o
o—> ray3 o––––––––—o
o-> ray4 o–––––––––––——o
o—> ray5 o—––––––——o
o-> ray6 o–––––o
o-> ray7 o–o
We start to see it looks a bit like a rotated cube. Moreover, knowing
the length of each segment and the spacing of the rays, we could actually
o-> ray1 o–o 2mm
o-> ray2 o–––––o 6mm
o—> ray3 o––––––––—o 10mm
o-> ray4 o–––––––––––——o 14mm
o—> ray5 o—––––––——o 10mm
o-> ray6 o–––––o 6mm
o-> ray7 o–o 2mm
––––
with 2mm spacing between rays: 50mm x 2mm = 100mm^2 area
It’s probably a 10mm x 10mm square. Extend that example into layer after
layer of samples and you don’t just have an area estimate, but now you have
a (3D) volume estimate because each ray represents a 2D cross section
with 2mm spacing between rays: 50mm x 2mm x 2mm = 200mm^3 volume
With a volume estimate and knowing density, you can obviously calculate
mass too (mass = volume x density). And all of that was done without
knowing anything about the geometry. That’s essentially what rtweight is
doing.
With your project, we’re changing the last step. In mathematical terms,
we were doing a summation over all the individual volume bits, multiplying
each by a constant density. New form, everything stays the same except
we’re either going to multiply the volume by a different (e.g., average)
density based on a function or we’re going to further parameterize the
volume so an volume/mass integral can be estimated.
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
https://lists.sourceforge.net/lists/listinfo/brlcad-devel

[Christopher Sean Morrison]

Hereby goes blade with a box (arb8) on top, intersected with with an arb6 that narrows towards the tip, and another arb6 added below and also intersected with the other arb6, that makes the bottom of the blade sharp. If we now also manage to model that curve, it should look pretty similar to the Distal Taper.

That looks much better! It’s possible that flattened ellipsoids, intersected, will give a good result for the taper, but that looks complex enough to serve as a test case.

thank you for the extensive explanation, and sorry for the misunderstanding.

No need to apologize.

• During ray-tracing, the calling code prepares the application and ray-tracing instance and shoots rays at the geometry. The library code containing the hit, miss and other functions handles the information it receives when a ray hits geometry.

Yes.

• The hit function receives a set of partitions in a circular linked list, (taken from the example:) "each [partition] describing one in and out segment of one region for each region encountered". So each partition is basically a set of segments, and all partitions together tell us all the stuff the ray went through. I assume there are many different "partitions" because we put the segments of different regions in different partitions, but also partitions can have more than one segment because we can cross a region more than once with a ray.

Yes. Good understanding too … this is a common stumbling block.

• In rtweight specifically, each ray gets fired some distance away from the other rays, in a grid. Thus we can think of the rays as a square tube, that has 2mm side length for the square and goes through the geometry (I assume these are the "cells" that appear in the code of viewweight.c) All the volume captured inside will be handled by one call of the hit function. Looping through all the partitions and obtaining the volume we crossed, and the density assigned to the region, we compute the mass for each partition and store it in some data structure (which seems to be this "datapoint" thing). Finally we just need to add it all up and obtain our total mass.

Yes except that the grid cell size isn’t necessarily 2mm. It’s configurable and by default is derived from a 512x512 grid centered on the object’s bounding box.

• In order to support heterogeneous densities we need a representation that allows us to provide the necessary information to the hit function, who will query our representation to obtain the density of the in and out points, and possibly the rate of change between the two. We then integrate/interpolate to obtain the "average" density of our segment, so that we can continue the same way we did in the point above.

Yes! There are certainly other possibilities, but that will be a minimal set of code changes, achievable in the project timeframe, and easy to validate.

• I guess the biggest "difficulty" here is to define a proper way of telling the hit function what this rate of change between the points is. Also storing a proper definition of the material density that allows for this information to be queried easily. This is why storing functions and taking derivatives is not a good idea.

It’s not that it’s not a good idea, it’s fine … but then we need to talk what that code is and looks like. I was imagining that you would end up with a functional description of the density change. In code, though, most density functions I can think of are described by point values and interpolation methods (i.e., linear for now).

Instead we may want to store vectors that tell the rate of change in several directions. Density at a specific point could be retrieved by combining vectors and the rate of change between two arbitrary points can be obtained through the vectors as well.

Can you describe an example? Describing rate of change might be difficult for a user if that’s not commonly available information. For our knife example, I can easily look up the density for hardened and unhardened steel and describe a transition between them over some distance that would likely be based in actual measurements. Whether it transitions fast (cubic) or slow (linear) or in steps (discontinuous) becomes a specification.

Cheers!
Sean

[Mario Meissner]

Yes! There are certainly other possibilities, but that will be a minimal
set of code changes, achievable in the project timeframe, and easy to
validate.


Okay! Let's focus on that first and we'll see how far we can go.


It’s not that it’s not a good idea, it’s fine 
 but then we need to talk
what that code is and looks like. I was imagining that you would end up
with a functional description of the density change. In code, though, most
density functions I can think of are described by point values and
interpolation methods (i.e., linear for now).


Can you describe an example? Describing rate of change might be difficult
for a user if that’s not commonly available information. For our knife
example, I can easily look up the density for hardened and unhardened steel
and describe a transition between them over some distance that would likely
be based in actual measurements. Whether it transitions fast (cubic) or
slow (linear) or in steps (discontinuous) becomes a specification.


Attached goes an example of one way I think it might work. In the end we
want one vector for each axis, that tells, through a multiplier, how the
density changes as we move in its direction. Choosing any point in the
region is taking the right combination of the vectors to go from the origin
to the point, and applying the multipliers of the vectors to the density of
the origin. Do this twice and you get in-point and out-point of the
segment. Now you can interpolate and calculate mass.

The user could also define non-axis vectors and we should then break them
down into axis ones.

This method only covers some really simple density distributions and fails
to represent more complex ones like density values that go up and down as
we advance in a certain direction. I see no easy way of modeling this
without complicating the whole think a lot. What do you think?

Mario.

[Christopher Sean Morrison]

Post by Mario Meissner
Attached goes an example of one way I think it might work.

This is an excellent example to work through!

Post by Mario Meissner
In the end we want one vector for each axis, that tells, through a multiplier, how the density changes as we move in its direction. Choosing any point in the region is taking the right combination of the vectors to go from the origin to the point, and applying the multipliers of the vectors to the density of the origin. Do this twice and you get in-point and out-point of the segment. Now you can interpolate and calculate mass.

I think I’m following you, but via different calculations. Where is your “3 + 3/2” coming from for segment a? I would have calculated it as a density field going from 3 (pt V) to 6 (pt B), divided by the contribution ratio of each. Showing all steps, undoubtedly with a mistake or three because this was done in just a few minutes:

density(V) density(B) 3 6
———————–––––––––––– + ––––—––——–––––––––– = – + – = 4.5 = contrib(a1, VB)
vect(VB)/vect(a1'V) vect(BA)/vect(a1’B) 2 2

Obviously same result, but is that essentially the same method? What’s throwing me is that I don’t get the same result for the out point, which means I probably have something wrong. I get:

contrib(a2, VB) + contrib(a2, VA) 4.5 + 9
––––––––––––––––––––––––––––––––– = ––––––- = 6.75
2 2


Regardless, I’m not sure I understand how your result (10.5) is even possible as the largest value should be 3*V=9, no?

Post by Mario Meissner
The user could also define non-axis vectors and we should then break them down into axis ones.

Yes, it’s important to note that geometry is often not axis-aligned like in your setup, so deriving vectors from the points will probably be desirable. That is, derive vectors VA, VB, VC, VD from the five density field points.

Post by Mario Meissner
This method only covers some really simple density distributions and fails to represent more complex ones like density values that go up and down as we advance in a certain direction. I see no easy way of modeling this without complicating the whole think a lot. What do you think?

This makes me think we’re using different methods. Summing contributions from the different points/vectors should give values that go up and down…

Cheers!
Sean

[Mario Meissner]

We probably have some different ideas on how it should work, because of
your "the largest value should be 3*V=9". I thought that if we have a
horizontal vector going right, and a vertical vector going down, and we
take the diagonal that goes the full distance down and right (so basically
a 2D square where up left is origin and bottom right is point we want to
calculate) the result should be the combination of both multipliers. If the
axis vectors were 3 right and 2 down, that point should have a multiplier
of 6 because it fully uses both axis vectors. From your statement I assume
that you didn't think of it this way.

If you think that the maximum value achievable is 3 in my imaginary square
of the first paragraph, what would you say is the value in the bottom
right? If it is 3, why does the horizontal vector count more than the
vertical one? It's like the bigger vector overrides the smaller one without
taking into account the smaller vector's value. What if we only go half
way? What's the density in the middle of the square? I would expect the
following: We go halfway to the right, so we don't multiply by the full
value but rather only by 1.5. So we are sitting at 1.5 and now we need to
go down halfway. Going all the way down would mean multiplying by 3 but
halfway would be 2. (this is because 1 original copy + 2 extra copies make
the 3 of the multiplier, but going halfway would mean 1 + 2/2 = 2, if this
is confusing I'll clarify it with more examples). So 1.5 x 2 = 3. This also
makes sense to me if I think that the bottom right is 6 and we are half way
through reaching it, so half of 6.

Now, if you look at the last part of yesterdays example document, I tried
to "re-do" the "a" segment showing all the steps the code might do. I first
decompose the vector into a combination of axis vectors, and using
coefficients to show "how much" of each vector we have to take. Next I take
the original density, 3, and add, for each axis vector I needed to use, the
following: origin_density x (multiplier - 1) x vector_coefficient. (Note
that I subtract 1 because of what I mentioned in the parenthesis above,
it's an accumulation so we have to subtract 1 to the multiplier, otherwise
we count the "original amount" twice). This worked for some cases but after
some deeper thought on it today I realized that this is wrong. Instead of
just summing one on top of the other, we have to make the operations step
by step and use the result of the first step as input for the second step.
Hereby goes attached the FIXED VERSION

Lets consider the box of the first paragraph.

Post by Christopher Sean Morrison

Post by Mario Meissner
Attached goes an example of one way I think it might work.

This is an excellent example to work through!

Post by Mario Meissner
In the end we want one vector for each axis, that tells, through a

multiplier, how the density changes as we move in its direction. Choosing
any point in the region is taking the right combination of the vectors to
go from the origin to the point, and applying the multipliers of the
vectors to the density of the origin. Do this twice and you get in-point
and out-point of the segment. Now you can interpolate and calculate mass.
I think I’m following you, but via different calculations. Where is your
“3 + 3/2” coming from for segment a? I would have calculated it as a
density field going from 3 (pt V) to 6 (pt B), divided by the contribution
ratio of each. Showing all steps, undoubtedly with a mistake or three
density(V) density(B) 3 6
———————–––––––––––– + ––––—––——–––––––––– = – + – = 4.5 = contrib(a1, VB)
vect(VB)/vect(a1'V) vect(BA)/vect(a1’B) 2 2
Obviously same result, but is that essentially the same method? What’s
throwing me is that I don’t get the same result for the out point, which
contrib(a2, VB) + contrib(a2, VA) 4.5 + 9
––––––––––––––––––––––––––––––––– = ––––––- = 6.75
2 2
Regardless, I’m not sure I understand how your result (10.5) is even
possible as the largest value should be 3*V=9, no?

Post by Mario Meissner
The user could also define non-axis vectors and we should then break

them down into axis ones.
Yes, it’s important to note that geometry is often not axis-aligned like
in your setup, so deriving vectors from the points will probably be
desirable. That is, derive vectors VA, VB, VC, VD from the five density
field points.

Post by Mario Meissner
This method only covers some really simple density distributions and

fails to represent more complex ones like density values that go up and
down as we advance in a certain direction. I see no easy way of modeling
this without complicating the whole think a lot. What do you think?
This makes me think we’re using different methods. Summing contributions
from the different points/vectors should give values that go up and down

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
https://lists.sourceforge.net/lists/listinfo/brlcad-devel

[Mario Meissner]

Sorry my last email got sent accidentally while I was writing (pressed some
weird hotkey). This is complete version:

We probably have some different ideas on how it should work, because of
your "the largest value should be 3*V=9". I thought that if we have a
horizontal vector going right, and a vertical vector going down, and we
take the diagonal that goes the full distance down and right (so basically
a 2D square where up left is origin and bottom right is point we want to
calculate) the result should be the combination of both multipliers. If the
axis vectors were 3 right and 2 down, that point should have a multiplier
of 6 because it fully uses both axis vectors. From your statement I assume
that you didn't think of it this way. (If we set the original density to 1
the "multiplier" value and the actual density would be the same so lets do
that for the below considerations).

If you think that the maximum value achievable is 3 in my imaginary square
of the first paragraph, what would you say is the value in the bottom
right? If it is 3, why does the horizontal vector count more than the
vertical one? It's like the bigger vector overrides the smaller one without
taking into account the smaller vector's value. What if we only go half
way? What's the density in the middle of the square? I would expect the
following: We go halfway to the right, so we don't multiply by the full
value but rather only by 1.5. So we are sitting at 1.5 and now we need to
go down halfway as well. Going all the way down would mean multiplying by 3
but halfway would be 2. (this is because 1 original copy + 2 extra copies
make the 3 of the full multiplier, but going halfway would mean 1 + 2/2 =
2, if this is confusing I'll clarify it with more examples). So 1.5 x 2 =
3. This also makes sense to me if I think that the bottom right is 6 and we
are half way through reaching it, so half of 6.

Now, if you look at the last part of yesterdays example document, I tried
to "re-do" the "a" segment showing all the steps the code might do. I first
decompose the vector into a combination of axis vectors, and using
coefficients to show "how much" of each vector we have to take. Next I take
the original density, 3, and add, for each axis vector I needed to use, the
following: origin_density x (multiplier - 1) x vector_coefficient. (Note
that I subtract 1 because of what I mentioned in the parenthesis above,
it's an accumulation so we have to subtract 1 to the multiplier, otherwise
we count the "original amount" twice). This worked for some cases but after
some deeper thought on it today I realized that this is wrong (doesnt work
for the half way diagonal example I mentioned above). Instead of just
summing one on top of the other, we have to make the operations step by
step and use the result of the first step as input for the second step.
I'll send a fix in one hour for yesterdays document so that it actually
does what I said it would.

Mario.

Post by Mario Meissner
We probably have some different ideas on how it should work, because of
your "the largest value should be 3*V=9". I thought that if we have a
horizontal vector going right, and a vertical vector going down, and we
take the diagonal that goes the full distance down and right (so basically
a 2D square where up left is origin and bottom right is point we want to
calculate) the result should be the combination of both multipliers. If the
axis vectors were 3 right and 2 down, that point should have a multiplier
of 6 because it fully uses both axis vectors. From your statement I assume
that you didn't think of it this way.
If you think that the maximum value achievable is 3 in my imaginary square
of the first paragraph, what would you say is the value in the bottom
right? If it is 3, why does the horizontal vector count more than the
vertical one? It's like the bigger vector overrides the smaller one without
taking into account the smaller vector's value. What if we only go half
way? What's the density in the middle of the square? I would expect the
following: We go halfway to the right, so we don't multiply by the full
value but rather only by 1.5. So we are sitting at 1.5 and now we need to
go down halfway. Going all the way down would mean multiplying by 3 but
halfway would be 2. (this is because 1 original copy + 2 extra copies make
the 3 of the multiplier, but going halfway would mean 1 + 2/2 = 2, if this
is confusing I'll clarify it with more examples). So 1.5 x 2 = 3. This also
makes sense to me if I think that the bottom right is 6 and we are half way
through reaching it, so half of 6.
Now, if you look at the last part of yesterdays example document, I tried
to "re-do" the "a" segment showing all the steps the code might do. I first
decompose the vector into a combination of axis vectors, and using
coefficients to show "how much" of each vector we have to take. Next I take
the original density, 3, and add, for each axis vector I needed to use, the
following: origin_density x (multiplier - 1) x vector_coefficient. (Note
that I subtract 1 because of what I mentioned in the parenthesis above,
it's an accumulation so we have to subtract 1 to the multiplier, otherwise
we count the "original amount" twice). This worked for some cases but after
some deeper thought on it today I realized that this is wrong. Instead of
just summing one on top of the other, we have to make the operations step
by step and use the result of the first step as input for the second step.
Hereby goes attached the FIXED VERSION
Lets consider the box of the first paragraph.

Post by Christopher Sean Morrison

Post by Mario Meissner
Attached goes an example of one way I think it might work.

This is an excellent example to work through!

Post by Mario Meissner
In the end we want one vector for each axis, that tells, through a

multiplier, how the density changes as we move in its direction. Choosing
any point in the region is taking the right combination of the vectors to
go from the origin to the point, and applying the multipliers of the
vectors to the density of the origin. Do this twice and you get in-point
and out-point of the segment. Now you can interpolate and calculate mass.
I think I’m following you, but via different calculations. Where is your
“3 + 3/2” coming from for segment a? I would have calculated it as a
density field going from 3 (pt V) to 6 (pt B), divided by the contribution
ratio of each. Showing all steps, undoubtedly with a mistake or three
density(V) density(B) 3 6
———————–––––––––––– + ––––—––——–––––––––– = – + – = 4.5 = contrib(a1, VB)
vect(VB)/vect(a1'V) vect(BA)/vect(a1’B) 2 2
Obviously same result, but is that essentially the same method? What’s
throwing me is that I don’t get the same result for the out point, which
contrib(a2, VB) + contrib(a2, VA) 4.5 + 9
––––––––––––––––––––––––––––––––– = ––––––- = 6.75
2 2
Regardless, I’m not sure I understand how your result (10.5) is even
possible as the largest value should be 3*V=9, no?

Post by Mario Meissner
The user could also define non-axis vectors and we should then break

them down into axis ones.
Yes, it’s important to note that geometry is often not axis-aligned like
in your setup, so deriving vectors from the points will probably be
desirable. That is, derive vectors VA, VB, VC, VD from the five density
field points.

Post by Mario Meissner
This method only covers some really simple density distributions and

fails to represent more complex ones like density values that go up and
down as we advance in a certain direction. I see no easy way of modeling
this without complicating the whole think a lot. What do you think?
This makes me think we’re using different methods. Summing contributions
from the different points/vectors should give values that go up and down

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
https://lists.sourceforge.net/lists/listinfo/brlcad-devel

[Mario Meissner]

As promised, a patch (literally) for yesterdays document. Instead of the
sum used and explained in my last email I found it more convenient (appart
from the fact that I was also doing it wrong) to compute the multipliers
(according to how much of each vector we used) and then multiply by the
original density value. Doing this yields the results I expected from my
model.

I'm interested in knowing what your idea was and if we can fit them both
together.

By the way, I also attach a second example that I think we cannot model
correctly with the model I propose. Density goes up and down as we advance
in the same direction, so one vector with a set multiplier is not enough.
It needs to have a function assigned.

PD. Your ASCII Sketches with dash characters get all messed up no matter
with which client I try to visualize the email with (not even with
monospaced fonts). I usually get the idea but it's sometimes difficult to
decipher.

Post by Mario Meissner
Sorry my last email got sent accidentally while I was writing (pressed
We probably have some different ideas on how it should work, because of
your "the largest value should be 3*V=9". I thought that if we have a
horizontal vector going right, and a vertical vector going down, and we
take the diagonal that goes the full distance down and right (so basically
a 2D square where up left is origin and bottom right is point we want to
calculate) the result should be the combination of both multipliers. If the
axis vectors were 3 right and 2 down, that point should have a multiplier
of 6 because it fully uses both axis vectors. From your statement I assume
that you didn't think of it this way. (If we set the original density to 1
the "multiplier" value and the actual density would be the same so lets do
that for the below considerations).
If you think that the maximum value achievable is 3 in my imaginary square
of the first paragraph, what would you say is the value in the bottom
right? If it is 3, why does the horizontal vector count more than the
vertical one? It's like the bigger vector overrides the smaller one without
taking into account the smaller vector's value. What if we only go half
way? What's the density in the middle of the square? I would expect the
following: We go halfway to the right, so we don't multiply by the full
value but rather only by 1.5. So we are sitting at 1.5 and now we need to
go down halfway as well. Going all the way down would mean multiplying by 3
but halfway would be 2. (this is because 1 original copy + 2 extra copies
make the 3 of the full multiplier, but going halfway would mean 1 + 2/2 =
2, if this is confusing I'll clarify it with more examples). So 1.5 x 2 =
3. This also makes sense to me if I think that the bottom right is 6 and we
are half way through reaching it, so half of 6.
Now, if you look at the last part of yesterdays example document, I tried
to "re-do" the "a" segment showing all the steps the code might do. I first
decompose the vector into a combination of axis vectors, and using
coefficients to show "how much" of each vector we have to take. Next I take
the original density, 3, and add, for each axis vector I needed to use, the
following: origin_density x (multiplier - 1) x vector_coefficient. (Note
that I subtract 1 because of what I mentioned in the parenthesis above,
it's an accumulation so we have to subtract 1 to the multiplier, otherwise
we count the "original amount" twice). This worked for some cases but after
some deeper thought on it today I realized that this is wrong (doesnt work
for the half way diagonal example I mentioned above). Instead of just
summing one on top of the other, we have to make the operations step by
step and use the result of the first step as input for the second step.
I'll send a fix in one hour for yesterdays document so that it actually
does what I said it would.
Mario.

Post by Mario Meissner
We probably have some different ideas on how it should work, because of
your "the largest value should be 3*V=9". I thought that if we have a
horizontal vector going right, and a vertical vector going down, and we
take the diagonal that goes the full distance down and right (so basically
a 2D square where up left is origin and bottom right is point we want to
calculate) the result should be the combination of both multipliers. If the
axis vectors were 3 right and 2 down, that point should have a multiplier
of 6 because it fully uses both axis vectors. From your statement I assume
that you didn't think of it this way.
If you think that the maximum value achievable is 3 in my imaginary
square of the first paragraph, what would you say is the value in the
bottom right? If it is 3, why does the horizontal vector count more than
the vertical one? It's like the bigger vector overrides the smaller one
without taking into account the smaller vector's value. What if we only go
half way? What's the density in the middle of the square? I would expect
the following: We go halfway to the right, so we don't multiply by the full
value but rather only by 1.5. So we are sitting at 1.5 and now we need to
go down halfway. Going all the way down would mean multiplying by 3 but
halfway would be 2. (this is because 1 original copy + 2 extra copies make
the 3 of the multiplier, but going halfway would mean 1 + 2/2 = 2, if this
is confusing I'll clarify it with more examples). So 1.5 x 2 = 3. This also
makes sense to me if I think that the bottom right is 6 and we are half way
through reaching it, so half of 6.
Now, if you look at the last part of yesterdays example document, I tried
to "re-do" the "a" segment showing all the steps the code might do. I first
decompose the vector into a combination of axis vectors, and using
coefficients to show "how much" of each vector we have to take. Next I take
the original density, 3, and add, for each axis vector I needed to use, the
following: origin_density x (multiplier - 1) x vector_coefficient. (Note
that I subtract 1 because of what I mentioned in the parenthesis above,
it's an accumulation so we have to subtract 1 to the multiplier, otherwise
we count the "original amount" twice). This worked for some cases but after
some deeper thought on it today I realized that this is wrong. Instead of
just summing one on top of the other, we have to make the operations step
by step and use the result of the first step as input for the second step.
Hereby goes attached the FIXED VERSION
Lets consider the box of the first paragraph.

Post by Christopher Sean Morrison

Post by Mario Meissner
Attached goes an example of one way I think it might work.

This is an excellent example to work through!

Post by Mario Meissner
In the end we want one vector for each axis, that tells, through a

multiplier, how the density changes as we move in its direction. Choosing
any point in the region is taking the right combination of the vectors to
go from the origin to the point, and applying the multipliers of the
vectors to the density of the origin. Do this twice and you get in-point
and out-point of the segment. Now you can interpolate and calculate mass.
I think I’m following you, but via different calculations. Where is
your “3 + 3/2” coming from for segment a? I would have calculated it as a
density field going from 3 (pt V) to 6 (pt B), divided by the contribution
ratio of each. Showing all steps, undoubtedly with a mistake or three
density(V) density(B) 3 6
———————–––––––––––– + ––––—––——–––––––––– = – + – = 4.5 = contrib(a1, VB)
vect(VB)/vect(a1'V) vect(BA)/vect(a1’B) 2 2
Obviously same result, but is that essentially the same method? What’s
throwing me is that I don’t get the same result for the out point, which
contrib(a2, VB) + contrib(a2, VA) 4.5 + 9
––––––––––––––––––––––––––––––––– = ––––––- = 6.75
2 2
Regardless, I’m not sure I understand how your result (10.5) is even
possible as the largest value should be 3*V=9, no?

Post by Mario Meissner
The user could also define non-axis vectors and we should then break

them down into axis ones.
Yes, it’s important to note that geometry is often not axis-aligned like
in your setup, so deriving vectors from the points will probably be
desirable. That is, derive vectors VA, VB, VC, VD from the five density
field points.

Post by Mario Meissner
This method only covers some really simple density distributions and

fails to represent more complex ones like density values that go up and
down as we advance in a certain direction. I see no easy way of modeling
this without complicating the whole think a lot. What do you think?
This makes me think we’re using different methods. Summing
contributions from the different points/vectors should give values that go
up and down

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
https://lists.sourceforge.net/lists/listinfo/brlcad-devel

[Mario Meissner]

Hello again.

Another situation that bothers me is also attached hereby. If we set both a
vertical and a horizontal vector and take the diagonal, we are forced to
predefined values by those vectors. But that if I want the diagonal to be
something else instead of what the horizontal and vertical vectors are
telling me? These situations make me think that this axis vector system is
quite limited and is also origin dependent (my blade would be impossible to
model with axis vectors if we put the origin in a corner instead of where I
placed it, for the same reasons that the other two examples cannot be
modeled either).

I'm not sure if we wan keep this model, it depends on whether we want to be
able to represent any (continuous, for now) possible distribution, or if we
are happy with the current limitations. To be able to fully describe any
continuous distribution we will probably need to use a function like I
suggested. Querying the density for points of a segment is as simple as
calling the function and returning it's value. Instead of also giving the
rate of change I suggest we just also give some intermediate values and
then the calling code can interpolate the values in a way that the
resulting density distribution alongside the segment is precise up to any
arbitrary precision to the original.

The function could be modeled using the same system we already mentioned.
The user can input a series of points or vectors that indicate densities at
certain points and/or rates of change between them, and then we use some
method to approximate a function that covers all the points (similar to how
a Taylor function approximates to functions like the sine).

I will need thoughts on this so I know if it's worth doing an example.
Can't do much on this end without feedback so I will try to make sense of
the existing code in the meantime.

Mario.

Post by Mario Meissner
As promised, a patch (literally) for yesterdays document. Instead of the
sum used and explained in my last email I found it more convenient (appart
from the fact that I was also doing it wrong) to compute the multipliers
(according to how much of each vector we used) and then multiply by the
original density value. Doing this yields the results I expected from my
model.
I'm interested in knowing what your idea was and if we can fit them both
together.
By the way, I also attach a second example that I think we cannot model
correctly with the model I propose. Density goes up and down as we advance
in the same direction, so one vector with a set multiplier is not enough.
It needs to have a function assigned.
PD. Your ASCII Sketches with dash characters get all messed up no matter
with which client I try to visualize the email with (not even with
monospaced fonts). I usually get the idea but it's sometimes difficult to
decipher.

Post by Mario Meissner
Sorry my last email got sent accidentally while I was writing (pressed
We probably have some different ideas on how it should work, because of
your "the largest value should be 3*V=9". I thought that if we have a
horizontal vector going right, and a vertical vector going down, and we
take the diagonal that goes the full distance down and right (so basically
a 2D square where up left is origin and bottom right is point we want to
calculate) the result should be the combination of both multipliers. If the
axis vectors were 3 right and 2 down, that point should have a multiplier
of 6 because it fully uses both axis vectors. From your statement I assume
that you didn't think of it this way. (If we set the original density to 1
the "multiplier" value and the actual density would be the same so lets do
that for the below considerations).
If you think that the maximum value achievable is 3 in my imaginary
square of the first paragraph, what would you say is the value in the
bottom right? If it is 3, why does the horizontal vector count more than
the vertical one? It's like the bigger vector overrides the smaller one
without taking into account the smaller vector's value. What if we only go
half way? What's the density in the middle of the square? I would expect
the following: We go halfway to the right, so we don't multiply by the full
value but rather only by 1.5. So we are sitting at 1.5 and now we need to
go down halfway as well. Going all the way down would mean multiplying by 3
but halfway would be 2. (this is because 1 original copy + 2 extra copies
make the 3 of the full multiplier, but going halfway would mean 1 + 2/2 =
2, if this is confusing I'll clarify it with more examples). So 1.5 x 2 =
3. This also makes sense to me if I think that the bottom right is 6 and we
are half way through reaching it, so half of 6.
Now, if you look at the last part of yesterdays example document, I tried
to "re-do" the "a" segment showing all the steps the code might do. I first
decompose the vector into a combination of axis vectors, and using
coefficients to show "how much" of each vector we have to take. Next I take
the original density, 3, and add, for each axis vector I needed to use, the
following: origin_density x (multiplier - 1) x vector_coefficient. (Note
that I subtract 1 because of what I mentioned in the parenthesis above,
it's an accumulation so we have to subtract 1 to the multiplier, otherwise
we count the "original amount" twice). This worked for some cases but after
some deeper thought on it today I realized that this is wrong (doesnt work
for the half way diagonal example I mentioned above). Instead of just
summing one on top of the other, we have to make the operations step by
step and use the result of the first step as input for the second step.
I'll send a fix in one hour for yesterdays document so that it actually
does what I said it would.
Mario.

Post by Mario Meissner
We probably have some different ideas on how it should work, because of
your "the largest value should be 3*V=9". I thought that if we have a
horizontal vector going right, and a vertical vector going down, and we
take the diagonal that goes the full distance down and right (so basically
a 2D square where up left is origin and bottom right is point we want to
calculate) the result should be the combination of both multipliers. If the
axis vectors were 3 right and 2 down, that point should have a multiplier
of 6 because it fully uses both axis vectors. From your statement I assume
that you didn't think of it this way.
If you think that the maximum value achievable is 3 in my imaginary
square of the first paragraph, what would you say is the value in the
bottom right? If it is 3, why does the horizontal vector count more than
the vertical one? It's like the bigger vector overrides the smaller one
without taking into account the smaller vector's value. What if we only go
half way? What's the density in the middle of the square? I would expect
the following: We go halfway to the right, so we don't multiply by the full
value but rather only by 1.5. So we are sitting at 1.5 and now we need to
go down halfway. Going all the way down would mean multiplying by 3 but
halfway would be 2. (this is because 1 original copy + 2 extra copies make
the 3 of the multiplier, but going halfway would mean 1 + 2/2 = 2, if this
is confusing I'll clarify it with more examples). So 1.5 x 2 = 3. This also
makes sense to me if I think that the bottom right is 6 and we are half way
through reaching it, so half of 6.
Now, if you look at the last part of yesterdays example document, I
tried to "re-do" the "a" segment showing all the steps the code might do. I
first decompose the vector into a combination of axis vectors, and using
coefficients to show "how much" of each vector we have to take. Next I take
the original density, 3, and add, for each axis vector I needed to use, the
following: origin_density x (multiplier - 1) x vector_coefficient. (Note
that I subtract 1 because of what I mentioned in the parenthesis above,
it's an accumulation so we have to subtract 1 to the multiplier, otherwise
we count the "original amount" twice). This worked for some cases but after
some deeper thought on it today I realized that this is wrong. Instead of
just summing one on top of the other, we have to make the operations step
by step and use the result of the first step as input for the second step.
Hereby goes attached the FIXED VERSION
Lets consider the box of the first paragraph.

Post by Christopher Sean Morrison

Post by Mario Meissner
Attached goes an example of one way I think it might work.

This is an excellent example to work through!

Post by Mario Meissner
In the end we want one vector for each axis, that tells, through a

multiplier, how the density changes as we move in its direction. Choosing
any point in the region is taking the right combination of the vectors to
go from the origin to the point, and applying the multipliers of the
vectors to the density of the origin. Do this twice and you get in-point
and out-point of the segment. Now you can interpolate and calculate mass.
I think I’m following you, but via different calculations. Where is
your “3 + 3/2” coming from for segment a? I would have calculated it as a
density field going from 3 (pt V) to 6 (pt B), divided by the contribution
ratio of each. Showing all steps, undoubtedly with a mistake or three
density(V) density(B) 3 6
———————–––––––––––– + ––––—––——–––––––––– = – + – = 4.5 = contrib(a1,
VB)
vect(VB)/vect(a1'V) vect(BA)/vect(a1’B) 2 2
Obviously same result, but is that essentially the same method? What’s
throwing me is that I don’t get the same result for the out point, which
contrib(a2, VB) + contrib(a2, VA) 4.5 + 9
––––––––––––––––––––––––––––––––– = ––––––- = 6.75
2 2
Regardless, I’m not sure I understand how your result (10.5) is even
possible as the largest value should be 3*V=9, no?

Post by Mario Meissner
The user could also define non-axis vectors and we should then break

them down into axis ones.
Yes, it’s important to note that geometry is often not axis-aligned
like in your setup, so deriving vectors from the points will probably be
desirable. That is, derive vectors VA, VB, VC, VD from the five density
field points.

Post by Mario Meissner
This method only covers some really simple density distributions and

fails to represent more complex ones like density values that go up and
down as we advance in a certain direction. I see no easy way of modeling
this without complicating the whole think a lot. What do you think?
This makes me think we’re using different methods. Summing
contributions from the different points/vectors should give values that go
up and down

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
https://lists.sourceforge.net/lists/listinfo/brlcad-devel