Disable physics mesh rotation help?

[Lightnet]

Need to help disable mesh rotation from physics. It used for character rotation for 3rd person camera control direction. It would help if there any thing about it. The controls are a bit hard to movement around.

 

Here an example:

http://www.babylonjs-playground.com/#1UFLF5#0

A,S,D,W = movement.

[GameMonetize]

Hello you can manually force mesh angular velocity on every frame:

http://doc.babylonjs.com/overviews/Using_The_Physics_Engine#angular-velocity

 

[Lightnet]

Nope it does not work. I read on the class of it and it over ride it I think. There should be better way to do it.

http://www.babylonjs-playground.com/#23MINU#0

I get the feeling it need some lead way for handling collisions. Example attaching collision while there animation but just trigger collision to update to bone location and rotation and not world physics.

[adam]

I would use linear velocity and angular velocity for movement instead of impulses.  

[Lightnet]

Much better movement?

----

It works I guess for model.physicsImpostor.setLinearVelocity(v2);. But I am not sure how to deal with the rotation mesh should be fixed. Just I don't like adding more work load to it.

Tested import model and it fail to stay on the ground and keep falling that I try to create the box and it didn't as same result of the ground. It just a sphere collision that I set to.

---

Here for what it look like but add more mesh to scene seem a waste.

Two mesh one for not visible with physics and add one for visible mesh move in the the point direction. It will update the object mesh since there some rotation I can't get to know where to disable it.

http://www.babylonjs-playground.com/#5UJXU#0

[Sonic_Serpentine]

I just did some experimentation with my own camera rig attached to a cannon.js physics object. Forcing the angular velocity every frame kind-of worked, but it leaks and doesn't absolutely stop rotation.

What absolutely stopped rotation for me is calling this.  ( just once, not on update )

object.physicsImpostor.executeNativeFunction(function (world, body) {
            body.fixedRotation = true;
            body.updateMassProperties();

});

So, its simple enough in cannon. I don't see an equivalent in Oimo yet.

[Wingnut]

Hi Sonic, and welcome!  http://www.babylonjs-playground.com/#23MINU#1

I'm just playing.  Changed to box impostor, and seriously reduced friction on ground and model. 

With high mass and high friction, sphere impostor will roll/rotate when applying linear velocity. 

(It drags against ground friction, which makes it roll.)

(Perhaps more truthful, there are repeated "micro-collisions" happening between cone sphereImpostor, and ground.  So I switched to box impostor, for the cone. Less chance for roll - with the help of reduced friction values everywhere.) 

I removed a bunch of other stuff... just to make the playground more simple.  Lines 82-94 do the thrusting. 

I kept the rotation killer in line 74.  I'm not sure it is working.  I am getting some TypeError: e.physicsBody is null errors on-console.   Not sure why, yet.  But it appears to be coming from keypresses, and not from renderLoop.  (errors only happen during keypresses, and not constantly)

Anyway, the WASD keys are having fun.  By bumping the cone into the boxes, you can make the cone rotate around Y, a little bit.  If line 74 were working properly, I think no rotation would be possible AT ALL.  In other words, bump-to-rotate works... so perhaps line 74 is not working.  Not sure, though.  Maybe line 74 is coded wrong.  *shrug*  Goofin' around. 

Models falling through ground... is a common problem.  Rumors say that increasing the size of the model... sometimes helps.  No promises. 

[Pryme8]

set the rotation values manually

body.angularVelocity.x =0;
body.angularVelocity.y =0;
body.angularVelocity.z =0;

Or create a vector that the physics engine likes and feed it to it, so body.angularVelocity = new Oimo.Vec3(0,0,0); or what ever the constructor is in Oimo and cannon which you may have to look up and if you dont have access readily to it need to make a function that grabs a Oimo or cannon Vector and extends it to a new object that you have access to.

" Rumors say that increasing the size of the model... sometimes helps.  No promises."

Not just rumors this is true.  It not just the model though you need to scale up the whole scene. the way the physics engines are set up are in a different unit scale then BJS I believe the ratio is like 1/10 or something like that and plus the larger the numbers the more accurate the solvers will be (to and extent)

[adam]

2 hours ago, Pryme8 said:

" Rumors say that increasing the size of the model... sometimes helps.  No promises."

Not just rumors this is true.

Do you have a simple PG that demonstrates this?  I don't think you should have any problems unless you are dealing with extremely small values.

edit: You will have problems with OIMO if you use the wrong scale value for your scene.

 

[Pryme8]

 

 

[dbawel]

@Lightnet -

Lots of good info on this post. As @Pryme8 has correctly concluded, in oimo.js - object scale considerably affects performance - and of course, he provided a brief example which is part of what I would consider from experience to be a viable solution to your current usage of Oimo. However, as of right now(which often changes from project to project), I personally prefer cannon.js over Oimo.js; simply because in my own opinion, it's more straight forward for me to use. And (for me) the results are generally more predictable and obvious - such as discovering that for my last project, I found less concern for mesh and world scale using cannon.js; whereas using Oimo.js these attributes have far greater influence over resulting behaviors, impulse, angularVelocity, etc.. In addition to working through the R&D process specific to your scene, meshes, and imposter scale (which there is not seperate controls on transforms for the imposter attached to the mesh); Thus I now find it necessary to set the Oimo World Scale manually in the scene script. A code example of this is as follows:

OIMO.WORLD_SCALE = 1;
OIMO.INV_SCALE = 1;

This should be defined in your scene following the definition of the physics engine if using oimo.js - whereas cannon doesn't require setting the world scale value. Add the above to your playground scene, adjust the values if necessary, and you'll see a big improvement - as this will provide more practical and predictable collision results. And if you want no rotation resulting from collisions at all, then declare your friction (always declare friction and do not remove this attribute, as no declaration of friction often provides undesired results. So declare friction but set the value to 0.0 This will assure that collisions will not result in any additional rotation for your meshes.

On my last project, I was determined to utilize oimo.js, and discovered after much time spent testing that cannon.js worked much better for my needs, and provided me with far more predictable collision behaviors. However, this was a personal choice, so I want to be clear that I'm not at all saying that cannon.js is currently a better solution - as it all depends upon the requirements of your scene specifically. But I do highly recommend that you replace oimo.js with cannon.js in your scene to test for perhaps one hour to compare the differences in collision behaviors and ease of use; as it's definately worth an hour of your time. Best of luck, and as you can already see, members on this forum take great interest in the physics extensions currently compatible with babylon.js - as I hope we will see a new physics engine working with BJS in the near future. I've seen hints of something new on the horizon. However as of today, there's basically only the two extensions to choose from; and there are allot of members here with considerable experience using both - so you should be in good shape for now.

Welcome - it's always good to see new developers discovering babylon.js as they try to navigate through all avalable frameworks for WebGL - which is still a new standard on devices and in browsers - and what a great place to help you discover if this is the framework which is best for your project. Looking forward to checking out your work in the future.

 

Cheers,

DB
 

[adam]

17 minutes ago, dbawel said:

As @Pryme8 has correctly concluded, in oimo.js - object scale considerably affects performance - and of course, he provided a brief example

Sorry, I'm not seeing the brief example.

 

[Pryme8]

http://www.babylonjs-playground.com/#IXJQI#9 looks like the new update broke the pg :-( that is from the above post linked threads.


Quote from me:"

http://www.babylonjs-playground.com/#2KHPSP#1

In my scene, I am trying to add phsyics to an object like I have done a bunch of times, but for some reason the scaling this time has make the object not react correctly...
I tried adding part.mesh.refreshBoundingInfo(); but to no avail.
If I make the object scaled back to 1 it works.

Is it because it is a copy of another mesh and not its own drawcall, I figured that would not effect it but not sure.

**UPDATE**
The Mystery gets deeper...

http://www.babylonjs-playground.com/#2KHPSP#1
I fixed my extend error, and tried to change the way I cloned and that still did not work... then I tried to make a whole new box and as soon as I set its dimensions down it acts the same way!


***ANOUTHER UPDATE***
http://www.babylonjs-playground.com/#2KHPSP#2
I bumped the scale up by 10 and everything works now.

"

On 3/25/2016 at 2:51 AM, RaananW said:

Hi Pryme8,

...

About the scaling - Oimo is to blame here. To work correctly with Oimo, the objects need to be in big units (multiply everything by 100, and it will work better). There is a reason for that, but I don't see Oimo changing it any time soon.

I will find the time to create a demo close to yours and see how I can help further.

 

And quote from Raanan on the first thread.

[adam]

I created a simple PG:

scale of 100:
http://www.babylonjs-playground.com/#169Y3Q#0

scale of 10:
http://www.babylonjs-playground.com/#169Y3Q#1

scale of 1:
http://www.babylonjs-playground.com/#169Y3Q#2

scale of .1:
http://www.babylonjs-playground.com/#169Y3Q#3

scale of .01:
http://www.babylonjs-playground.com/#169Y3Q#4

scale of .001 (some trouble, sphere radius =  0.0002):
http://www.babylonjs-playground.com/#169Y3Q#5

 

 

 

[Pryme8]

Do something more complicated then a sphere on a box. and the results will be more visible.

[dbawel]

Hi @adam-

I was referring to the following:

7 hours ago, Pryme8 said:

set the rotation values manually

body.angularVelocity.x =0;
body.angularVelocity.y =0;
body.angularVelocity.z =0;

Or create a vector that the physics engine likes and feed it to it, so body.angularVelocity = new Oimo.Vec3(0,0,0); or what ever the constructor is in Oimo and cannon which you may have to look up and if you dont have access readily to it need to make a function that grabs a Oimo or cannon Vector and extends it to a new object that you have access to.

It's not a PG scene, but simply an example to to use the above to set and/or restrict the rotation transform for an imposter. Also, yor PG scenes with varying scale clearly demonstrate how important scale is when using the oimo engine. I'm sure this will help others understand the relationship between scale in Oimo.js - although changing the scale responds differently when using cannon.js - at least it did using babylon.2.4.js. However, I'm now having isues running scenes which use to run correctly in babylon.2.2.js - and now won't run - not sure why, but if I replace with v2.4, the scenes run fine again.

DB

Edited December 28, 2016 by dbawel

[adam]

21 minutes ago, Pryme8 said:

Do something more complicated then a sphere on a box. and the results will be more visible.

This is what I used when discussing this with topic with RaananW a few weeks ago.

scale of 100:
http://www.babylonjs-playground.com/#SFELK#21

scale of 10:
http://www.babylonjs-playground.com/#SFELK#22

scale of 1:
http://www.babylonjs-playground.com/#SFELK#23

scale of .1:
http://www.babylonjs-playground.com/#SFELK#24

scale of .01:
http://www.babylonjs-playground.com/#SFELK#25

scale of .001 (trouble):
http://www.babylonjs-playground.com/#SFELK#26

 

 

[Pryme8]

I am definitally seeing a soother response at the scale of 100.  the springs seem to work better.

[Lightnet]

@Sonic_Serpentine oh, that might help if reworking.

I had to switch to cannon.js since I can't find terrain height map to work well for Oimo. I doing some open world terrain zone visible thing that is mostly manual scripting. Just odd error saying that sphere error. Saying sphere only collision with another sphere only. And it gone.

[Wingnut]

@Lightnet  Did you mean 'meshImpostor only collides against spheres."?  *nod*  It is a common error when working-with Cannon meshImpostor (heightMap physics).

Sometimes, the error happens, even when we are doing things correctly.  Here is a demo with a sphereImposter rolling on a Cannon meshImposter.  The demo has some problems, sorry, but it is a decent sphereImposter/meshImposter test scene.  That error... is seen in the console, even though we use sphereImposter only. The bobsled model is not physics-active at all.  Only the sphere that it .position-tracks... is physics-active.  *shrug*

Keep in mind, if you please, that you don't NEED TO use a physics-active terrain... to make a player/vehicle/robot follow terrain contours.  We have a distance-to-terrain function/feature that will keep your player on the ground, following landscape contours nicely (without a physics engine).  Performance is MUCH faster with non-physics terrain. 

There's a user named @jerome, here, that has made demos with his own high-performance bare-bones physics calculations... and they are wonderful.  His math... is a little gruesome, but it sure has proved itself powerful.

Give it some thought.  If you run my bobsled demo a few times, you might see the sled fall through the ground, sometimes.  Fall-thru is a common problem with physics-active grounds/walls.  Sometimes, physics-active grounds are better... if they are BOXES, but you can't have physics mountains and valleys... with a box imposter. 

So, if you have a sphereImposter'd player/vehicle with a Cannon meshImposter, then you might have fall-throughs, sometimes.  Perhaps not, though.  *shrug*    There IS an option for an "emergency fall-through tester" in the render loop, but that can slow-down a physics-heavy scene... even more, yet.  Someday, someone will invent "the physics fall-thru prevention" and become famous. 

[Pryme8]

You do not need physics most he time if you understand linear Algerbra and Trig.  Even for collision detection AABB for convex shapes is easy and most the time if you can get away with manual calculations your gonna get better performance.  I would learn how to do vector projection and get really good with the concept in 2d before moving on to 3D if your looking to do your own physics models though.  Also you need to decide if your going for a physical model that is based off science or a simulated one that is just kinda make it work mentality which works great for game design and stylized physic models.

 

im really hung over so I hope this is not jibberish.