Interested in making Indie games? Register for a Meet the Experts webinar with Digital-Tutors today!
Discussion Groups

## ICE - Interactive Creative Environment

Contributor
Posts: 15
Registered: ‎12-11-2008

# Questions regarding ICE kinematics

223 Views, 8 Replies
12-28-2012 04:11 AM
Hi,
after working here and there with ICE for particles and deformations I'm trying to do something with kinematics now.
Unfortunatly I don't seem to get the whole point. I'm having trouble with this particular tree which is included for a while now and I just don't seem to get the whole point.
So I thought maybe some of you could have a look over it and could maybe help me?

The Scene includes 4 Objects:

- A Null "Rig" which has the ICE Tree
- A Polymesh "Character" (shown purple in the Screenshot)
- A Polymesh "blobShadow" (shown green in the Screenshot)
- A Polymesh "Floor"
All the objects are frozen and have zerod-out

My aim was to simulate a simple blob-shadow-technique as it could be used in video games.
The point normals of "character" are projected onto "floor". An Average of the resulting points (in this case 4 as "character" has 4 vertices) is calculated
and "blobShadow" is placed where this average is. So far so good, if I am moving character (or moving the points) the shadow-object moves along the floor under it.

With the nodes in the middle of the ICE Tree I'm trying to get the ponit normal on the location of "floor" which is nearest to "average" and rotate the shadow-plane correspondently.
I have the following problems/questions:

1.) As soon as i plug in the PointNormal in the tree (marked "B" in the screenshot of the tree included) instead of the vector constant the shadow-object moves to 0,0,0.
The yellow debug Null ("A" in the tree) is on a complete different location on the floor.
2.)If I plug the vector constant back in (replacing the PointNormal) I still see the yellow debug null ("A") and it moves if I move the points of the "chacter"-mesh, but it seems to have some kind of offset..
3.)Completly no sense for me makes the following: If i plug in the vector constant again ("B") and rotate the shadow-object with this setup (by giving different values then <0,0,0> for the vector constant, the yellow debug null rotates with it.
Can anyone explain me why this is happening? This is an "dead end" of the tree and in my opinion shouldn't even be calculated, but even if, there should be no connection betwen this debug value and the rotate vector. (?)

I would be very happy if anyone coud give me a glue what could be the problem, as I'm struggeling with this simple task for a while now...

Thanks,
Raschko

Distinguished Contributor
Posts: 606
Registered: ‎04-28-2009

# Re: Questions regarding ICE kinematics

01-29-2013 01:36 PM in reply to: Raschko
I suspect you're mixing up coordinate systems. Everything is in local coords, remember.

I'd break this down into smaller bits and then build it back up again.
Distinguished Contributor
Posts: 310
Registered: ‎02-18-2008

# Re: Questions regarding ICE kinematics

01-29-2013 03:48 PM in reply to: Raschko
When you get Character.PointPosition, you are getting the position values as offsets from the Character object's center. However, when you plug those values into Raycast, they are interpreted relative to the object with the tree which you say is the Rig null. So you first need to get the point positions in global coordinates by using a Multiply Vector by Matrix node to multiply Character.PointPosition by Character.kine.global. Now those values will work as long as the Rig null is not transformed in any way. If it is, then you will also need to multiply the result by the inverse of Rig.kine.global. Note that it is a bit more efficient to first multiply Character.kine.global (argument 1) and the inverse of Rig.kine.global (argument 2) in that order (matrix multiplication is not commutative, i.e., AB does not equal BA) and then use the result to multiply Character.PointPosition.

You've got the same issue with Character.PointNormal but that is a "true" vector and not a position so it must be treated a little differently. You can either use the 3x3 version of the kine.global matrices (i.e. scaling and rotation but no translation) as above, or convert Character.PointNormal to 4D vectors with W = 0, use the same 4x4 matrices as above, and then convert back to 3D vectors throwing away the W component. That should work as long as there isn't non-uniform scaling involved with any of the elements -- I'll spare you the maths for that case.

When you get PointPosition and PointNormal at locations, they are already expressed in terms of the object with the tree so you don't need to do any more processing there. Unless, of course, the Rig null has been transformed in which case you need to multiply by the inverse of Rig.kine.global again.

The last problem that I can spot off the top of my head is how you are calculating the rotation. You can't just use the surface normal. Instead use Increment Rotation with 2 Vectors to calculate what rotation is required to increment a rotation of zero (i.e. <1, 0, 0, 0>) to go from the vector (0, 1, 0) (i.e. +Y) to the surface normal.
Contributor
Posts: 15
Registered: ‎12-11-2008

# Re: Questions regarding ICE kinematics

01-31-2013 01:49 AM in reply to: grahamef
Wow, thank you very much! Great explanation! I only overflew it so far (lot of work) but I'm pretty sure it is be extreme helpful to me. I will have a closer look in a free minute at the weekend and post my results if I am succesful.
It seems like I had more mathematical errors then I thought, I think it's time to have a look at my old books again...
Contributor
Posts: 15
Registered: ‎12-11-2008

# Re: Questions regarding ICE kinematics

02-03-2013 09:06 AM in reply to: Raschko
I think I've got the global/local-thing when getting the objects now. I get correct results for the position now even if I transform the object (until that I did'nt do that)

But I still have problems with the rotation. I tried to break it down to just the rotation-thing...
(Ice Tree on Null "Rig": get a sphere, get a null ("marker"), find the closest location, get the Normal and rotate a fourth object ("plane" corresponding)

There seems to be a principal error in my understanding of the SRT to Matrix-Node. There is something like a self-referencing if I put a rotation in a "SRT-to-Matrix"-Node and put that into kine.global of an object. As soon as I do this the whole tree behaves strange (For example: Get closest location doesn't give correct results anymore). I tried to put it in kine.local, but this doesn't seem to be allowed...

Distinguished Contributor
Posts: 310
Registered: ‎02-18-2008

# Re: Questions regarding ICE kinematics

02-04-2013 04:18 PM in reply to: Raschko
In that image, you are resetting the translation to its default (scaling too, but I'm assuming there's no scaling involved).

Get the current position and feed it in, or combine the calculated rotation and translation into one matrix to set kine.global.
Contributor
Posts: 15
Registered: ‎12-11-2008

# Re: Questions regarding ICE kinematics

02-05-2013 09:57 AM in reply to: grahamef
This tree was just an example, I was conventrating on the rotation here to make things as easy as possible.
It works in principle, I think I'm irritated that the debug Null (right after Get closest location) doesn't move correctly. If I let SI give me the values (not the location) it seems to do it right.
I'm getting a little frustrated about the debugging tools... ;-)

edit: The debug Null seems to be correct if I tick on "Use global coordinates for display". Why should there be a differenece betwen local and global coordinates, everything is zero-ed out?

edit 2: Oh, and the PointNormal should go into "To Vector" in the above example for it to give correct results, forgot to add that...
Distinguished Contributor
Posts: 310
Registered: ‎02-18-2008

# Re: Questions regarding ICE kinematics

02-08-2013 08:49 AM in reply to: Raschko
I tried it myself and it seems to work fine for the position. However as soon as you plug the calculated position into Find Closest Location in order to look up the normal, the tree stops working.

I found that one workaround was to save the position as a temp attribute, and then use that with Find Closest Location. See attached image.

I'll investigate a bit more and log a bug if necessary.