 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Being dissatisfied with Point_At_Trans and Reorient_Trans, for use in my
inverse kinesics skeleton, I decided to break out the math and try to
write a replacement. And I ended up with this macro:
#macro Point_To(tvector)
#declare rho = sqrt (
abs (tvector.x * tvector.x) +
abs (tvector.y * tvector.y) +
abs (tvector.z * tvector.z)
);
#declare sigma = sqrt (
abs (tvector.x * tvector.x) +
abs (tvector.y * tvector.y)
);
#declare phi = degrees(acos (tvector.z / rho));
#if (tvector.x < 0)
#declare theta = 180 - degrees(asin (tvector.y / sigma));
#else
#declare theta = degrees(asin (tvector.y / sigma));
#end
#if
<90 - phi, 0, theta - 90>
#end
No doubt someone could make use of this. :)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le 15/02/2012 05:01, Tail Kinker a écrit :
> No doubt someone could make use of this.
A bit of documentation might help.
Such as : the output is a vector for use with rotate, which will
transform the x direction into the a vector aligned with the parameter.
The other vectors of the base (y & z) are not constrained and might jump
when the parameter evolves (do not be surprised in animation!).
An input parameter of <0,0,0> is not supported and might stop your scene.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 15-2-2012 5:01, Tail Kinker wrote:
> Being dissatisfied with Point_At_Trans and Reorient_Trans, for use in my
> inverse kinesics skeleton, I decided to break out the math and try to
> write a replacement. And I ended up with this macro:
>
> #macro Point_To(tvector)
> #declare rho = sqrt (
> abs (tvector.x * tvector.x) +
> abs (tvector.y * tvector.y) +
> abs (tvector.z * tvector.z)
> );
> #declare sigma = sqrt (
> abs (tvector.x * tvector.x) +
> abs (tvector.y * tvector.y)
> );
> #declare phi = degrees(acos (tvector.z / rho));
> #if (tvector.x < 0)
> #declare theta = 180 - degrees(asin (tvector.y / sigma));
> #else
> #declare theta = degrees(asin (tvector.y / sigma));
> #end
> #if
> <90 - phi, 0, theta - 90>
> #end
>
> No doubt someone could make use of this. :)
That last #if is not correct. (...) and #end are missing...
Thomas
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le 15/02/2012 10:15, Thomas de Groot a écrit :
> On 15-2-2012 5:01, Tail Kinker wrote:
>> Being dissatisfied with Point_At_Trans and Reorient_Trans, for use in my
>> inverse kinesics skeleton, I decided to break out the math and try to
>> write a replacement. And I ended up with this macro:
>>
>> #macro Point_To(tvector)
>> #declare rho = sqrt (
>> abs (tvector.x * tvector.x) +
>> abs (tvector.y * tvector.y) +
>> abs (tvector.z * tvector.z)
>> );
>> #declare sigma = sqrt (
>> abs (tvector.x * tvector.x) +
>> abs (tvector.y * tvector.y)
>> );
>> #declare phi = degrees(acos (tvector.z / rho));
>> #if (tvector.x < 0)
>> #declare theta = 180 - degrees(asin (tvector.y / sigma));
>> #else
>> #declare theta = degrees(asin (tvector.y / sigma));
>> #end
>> #if
>> <90 - phi, 0, theta - 90>
>> #end
>>
>> No doubt someone could make use of this. :)
>
> That last #if is not correct. (...) and #end are missing...
While we are at it, #local would be safer than #declare.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 12-02-15 05:16 AM, Le_Forgeron wrote:
> Le 15/02/2012 10:15, Thomas de Groot a écrit :
>> That last #if is not correct. (...) and #end are missing...
>
>
> While we are at it, #local would be safer than #declare.
>
I copied the macro out of the file I used to test it, not the version I
saved. In other words, the slightly erroneous one. Yes, the last #if
is superfluous and should be deleted. In the version I saved, all the
#declare had been changed to #local. They were made #declare in the
testing version in order to be able to read those variables outside the
macro, for debugging purposes.
The output is a vector, to be used with rotate, that will align the
object about the origin so that its y axis will now point towards
tvector. Jumps will occur when tvector.y = 0 and tvector.x crosses 0.
And yes, an input vector of 0 will break the macro.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Tail Kinker <the### [at] gmail com> wrote:
> Being dissatisfied with Point_At_Trans and Reorient_Trans, for use in my
> inverse kinesics skeleton, I decided to break out the math and try to
> write a replacement.
......
Would you care to explain what problems you experience with those macros ?
--
Tor Olav
http://subcube.com
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 12-02-15 06:14 PM, Tor Olav Kristensen wrote:
> Would you care to explain what problems you experience with those macros ?
>
The biggest problem was that they tended to jump about as y approached
zero for the target point. For use in an IK skeleton, this was
problematic. Mine jumps as well, but along a different axis - y at
zero, and as x approached zero. This is better for an IK skeleton.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
