Jump to content

llSetKeyFramedMotion affected by avatars


LindaB Helendale
 Share

Recommended Posts

Wiki-page  http://wiki.secondlife.com/wiki/LlSetKeyframedMotion states that collisions with physical objects will be computed and reported, but the keyframed object will be unaffected. There's no mention about collision with avatar, but in tests avatars work differently than other physical tasks.

Collision with avatar affects the moving object and it won't reach the final destination.

 

The test was simple bar that makes a 360 deg rotation on click with code

touch_start(integer num){
  float FT=45.0;
  list opt=[KFM_MODE, KFM_FORWARD, KFM_DATA , KFM_ROTATION]; 
  integer i;
  integer N=4;
  float Trev=2; // secs per rev
  float t=(float)llRound(Trev/(float)N*FT)/FT; // integer multiple of 1/45 sec
  list keyFrames; 
  for(i=0;i<N;i++) {
    keyFrames += [llEuler2Rot(<0,0,360.0/N>*DEG_TO_RAD),t];
  }
  llSetKeyframedMotion(keyFrames, opt);
}

and when I stand on the way of the bar it slows down and won't end up in 360 deg turn.

Should this be mentioned in the wiki as a feature (someone with edit rights there?), or is it bug, or something purposeful on the way to make the key framed motion interact with physical tasks?

 

UPDATE:

Hovering avatars do not appear to affect the key framed motion, while dropping an anvil on hovering avatar causes normal collision effects.

The effect of collision with avatar on the moving object seems to depend on the mass of it, like with normal physics.

 

Link to comment
Share on other sites


Linda Hillsdale wrote:

Should this be mentioned in the wiki as a feature (someone with edit rights there?), or is it bug, or something purposeful on the way to make the key framed motion interact with physical tasks?

If you think it should be mentioned, you should do it.

All residents can log in and make changes and additions to the wiki.

There are some rules to follow of course.

You can read them when you log in.

I think it is worth mentioning and I think you should do it:smileyhappy:

Link to comment
Share on other sites


Dora Gustafson wrote:

If you think it should be mentioned, you should do it.

All residents can log in and make changes and additions to the wiki.

There are some rules to follow of course.

You can read them when you log in.

I think it is worth mentioning and I think you should do it:smileyhappy:

I tried to, logged in and  when I tried to save, it complained about user not having rights to edit the page.

If you think it should be possible, I'll try again ;)  

 

Link to comment
Share on other sites


LindaB Helendale wrote:


Dora Gustafson wrote:

If you think it should be mentioned, you should do it.

All residents can log in and make changes and additions to the wiki.

There are some rules to follow of course.

You can read them when you log in.

I think it is worth mentioning and I think you should do it:smileyhappy:

I tried to, logged in and  when I tried to save, it complained about user not having rights to edit the page.

If you think it should be possible, I'll try again
;)
 

I am not sure  about who has got what rights with respect to editing.

I am premium and has been for more than 4 years.

Nothing special about my account and I can edit and add.

It must be written somewhere.

Maybe someone out there will help. HELP!!!

If you have written it all down in the form you want to present, maybe someone (like me) could add it to the wiki:smileyhappy:

ADDED: Try reading these editing guidelines

Link to comment
Share on other sites

I don't see this as unusual or unexpected behavior.  A KeyframedMotion object is physical, so its collision with an avatar is like any physical object's collision.  I made a pair of double doors with llKeyframedMotion last week.  If I stand in the way of the doors as they open, they swat me out of the way.  If I make tiny doors, though, they don't have enough oomph to move me, so they stall.  That's the way with any physical object I've ever worked with.

Link to comment
Share on other sites


Rolig Loon wrote:

I don't see this as unusual or unexpected behavior.  A KeyframedMotion object is physical, so its collision with an avatar is like any physical object's collision.  I made a pair of double doors with
llKeyframedMotion
last week.  If I stand in the way of the doors as they open, they swat me out of the way.  If I make tiny doors, though, they don't have enough oomph to move me, so they stall.  That's the way with any physical object I've ever worked with.

The way it works is quite different from what the wiki page says, 

Collisions with physical objects will be computed and reported, but the keyframed object will be unaffected by those collisions. (The physical object will be affected, however.)"

So it should swat you out of the way but the door would not stall, according to the description.

The key framed object is not physical, but part of the physics is simulated: "This function can only be called on NON-physical objects. In the future it could be extended to support physical objects, but this is more complicated as collisions could prevent the object from reaching its goal positions on time."

The implemented part of physics in interaction of a keyframed object and a physical task differs from normal physical objects, depending on whether the other party is object or avatar. If there's a big physical object on the way, the keyframed object just throws it away and wont stall, while an avatar affects the keyframed object causing  the problem mentioned above, why it is not yet implemented on physical objects too. 

 

 

Link to comment
Share on other sites


Dora Gustafson wrote:

I
am not sure  about who has got what rights with respect to editing.

I am premium and has been for more than 4 years.

Nothing special about my account and I can edit and add.

It must be written somewhere.

Maybe someone out there will help. HELP!!!

If you have written it all down in the form you want to present, maybe someone (like me) could add it to the wiki:smileyhappy:

ADDED: Try reading these

Me blonde... I tried to add a comment on this on the discussion page and it said I need special permission, so i thought it's the same for the main page, but it was possible to edit that page. 

Additional tests show that translation is not affected by collision with avatar, only the angular movement is. I added it in Caveats.

 

Link to comment
Share on other sites


LindaB Helendale wrote:

Me blonde... I tried to add a comment on this on the discussion page and it said I need special permission, so i thought it's the same for the main page, but it was possible to edit that page. 

Additional tests show that translation is not affected by collision with avatar, only the angular movement is. I added it in Caveats. 

Link to the wiki

It looks great to me:smileyhappy:

If you could move it up, so it becomes #2 in the list, it would be better in my opinion because #1 is about reaching the goal position

Link to comment
Share on other sites

Random wandering has brought me to this topic.

This sounds more like a bug than an undocumented feature. I've been following the development of the function and I don't recall this ever being mentioned.

I think you should report this on JIRA. - http://jira.secondlife.com

If you want I can do that for you and/or mod the documentation. I'm kinda an expert on the wiki documentation.

EDIT: Oh I didn't read the last post, the documentation change looks good. Will it reach the final rotation of subsequent frames that come later or does it screw up the animation?

Link to comment
Share on other sites

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now
 Share

×
×
  • Create New...