## ICE - Interactive Creative Environment

Topic Options

- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic to the Top
- Bookmark
- Subscribe
- Printer Friendly Page

# Questions regarding ICE kinematics

- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Highlight
- Email to a Friend
- Report Inappropriate Content

240 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

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

# Re: Questions regarding ICE kinematics

- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Highlight
- Email to a Friend
- Report Inappropriate Content

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.

I'd break this down into smaller bits and then build it back up again.

# Re: Questions regarding ICE kinematics

- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Highlight
- Email to a Friend
- Report Inappropriate Content

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.

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.

# Re: Questions regarding ICE kinematics

- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Highlight
- Email to a Friend
- Report Inappropriate Content

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...

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...

# Re: Questions regarding ICE kinematics

- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Highlight
- Email to a Friend
- Report Inappropriate Content

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...

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...

# Re: Questions regarding ICE kinematics

- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Highlight
- Email to a Friend
- Report Inappropriate Content

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.

Get the current position and feed it in, or combine the calculated rotation and translation into one matrix to set kine.global.

# Re: Questions regarding ICE kinematics

- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Highlight
- Email to a Friend
- Report Inappropriate Content

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...

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...

# Re: Questions regarding ICE kinematics

- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Highlight
- Email to a Friend
- Report Inappropriate Content

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.

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.

# Re: Questions regarding ICE kinematics

- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Highlight
- Email to a Friend
- Report Inappropriate Content

02-10-2013 06:28 AM in reply to:
Raschko

Thank you Graham for your time and efforts. Not only does my little Tool work now, I also know I didn’t make a complete stupid error, and therefore are much more motivated to dig deeper in Softimage ICE… ;-)