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. 2017-07-14 22:41 GMT+02:00 Christopher Sean Morrison <brl...@mac.com>: > > > - 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 > set sphere density 0 @ 0,0,0 linear 1 @ 1,0,0 > > > - 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 > brlcad-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/brlcad-devel > >
density_function_ray_reduction.pdf
Description: Adobe PDF document
------------------------------------------------------------------------------ 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
