Parenting with high velocity objects

[Ywa]

Hello. I'm currently using a framework for my application. After spawning a model (which basically is a mesh parented to a phys object) and applying it global velocity ( around Vec3( 100,100,100 ) ), I notice that the physics body is actually in front of the mesh. Is there any way to fix this? Thanks.

 

 

The code for the loading the model is this:

  Test := LoadModel( 'abstract::oildrum.gmf' );
 PositionEntity( Test, Light.GetPos + Vec3( 0,5,0 ), 1 );
 SetBodyMass( Test, 1 );
 SetBodyVelocity( Test, Vec3( 100,100,100 ) );

[VeTaL]

Check your main loop, update and render functions.

[Ywa]

In my main loop, I'm calling RenderFramework first, then UpdateFramework, then Flip. Even switching UpdateFramework with RenderFramework doesn't make any difference in my case.

[Wchris]

In my main loop, I'm calling RenderFramework first, then UpdateFramework, then Flip. Even switching UpdateFramework with RenderFramework doesn't make any difference in my case.

I can reproduce the problem , the meshs out of sync with their parent body at hight speed.

It has nothin to do with the setvelocity command, it also occurs when a body is collided and bounces at high speed, the attached mesh lags behind.

 

I have no idea how to solve this, you probably should PM Josh and point him to this thread.

 

 

*screenshot edited with paint net and combined layers so you approximately see what's on screen (a normal paused screenshot would only show one body and one mesh cude)

[Canardia]

You need call first UpdateFramework(), then your code, then RenderFramework(), then Flip(0).

But also your code first, then UpdateFramework, then RenderFramework(), then Flip(0) works in most cases.

I'm not 100% which one is the better approach, but the worst is to call UpdateFramework(), then RenderFramework(), then your code, then Flip(0), because then the physics bodies are totally out of sync with the meshes.

[Wchris]

You need call first UpdateFramework(), then your code, then RenderFramework(), then Flip(0).

But also your code first, then UpdateFramework, then RenderFramework(), then Flip(0) works in most cases.

I'm not 100% which one is the better approach, but the worst is to call UpdateFramework(), then RenderFramework(), then your code, then Flip(0), because then the physics bodies are totally out of sync with the meshes.

i don't think it's a coding problem, in my sample i have attached the body to another one with joint and i start the body looping with a collision by throwing a very fast cube body on it. So the movement is initiated by the colilsion and there is no specific code to render the looping cube, the engine is doing this alone.

But i still think this is not a bug, it's just a visual artefact when debugphysics is activated on a very fast parented body. The physic is probably continuing to update asynchronously during the renderframework command, so with very fast bodies the mesh is drawn at the body position but the "debug physic"s is not done at same time, instead it's drawn on top later ... so in the little timelapse, between meshs drawing end debugphysics drawing, the body has already moved and is drawn at a different place by debugphysics. But this just affects debugging visuals and not real gameplay.

Of course only josh can confiirm this is how debugphysics works.

 

but Lumooja is right do Updateframewrok before renderframework. First you set the positions of the 3D objects in the world with updateworld, then you render the world with renderworld. It's more logic than the opposite.

[Wchris]

I notice that the physics body is actually in front of the mesh. Is there any way to fix this? Thanks.

 

In this thread Flexman says he encountered a similar problem too http://leadwerks.com/werkspace/index.php?/topic/3009-helicopter/page__p__27820__hl__%2Bhigh+%2Bspeed__fromsearch__1#entry27820

 

He is probably one of the most skilled LE devellopers around, so if he says there is a problem with physics at high speed i tend to believe him.

Maybe there is a synchronisation problem between the physics engine and graphics engine after all. Only josh can tell.

[Canardia]

One thing is also that the physics debug wireframes are not accurate, they are only a rough approximation, so you shouldn't trust what they show, as the physics bodies might actually be at your mesh already.

 

You can probably best test this by turning of physics debug mode and see if the meshes collide accurately with eachother at high speeds. Just make sure you don't move a body more than the size of it is, because then there won't be any collision, even if sweptcollision tries to fix that, it doesn't work always.

[Ywa]

I got this fixed, I think it was my engine.dll causing it. Not sure why.