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.
2017-07-14 9:03 GMT+02:00 Christopher Sean Morrison <brl...@mac.com>:
>
> On Jul 13, 2017, at 10:45 AM, Mario Meissner <mr.rash....@gmail.com>
> wrote:
> [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
> brlcad-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/brlcad-devel
>
>
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
BRL-CAD Developer mailing list
brlcad-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/brlcad-devel
