Jump to content

Mesh_Colliders not working correctly?


Recommended Posts


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.

The Mystery gets deeper...

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!

I bumped the scale up by 10 and everything works now.

Link to comment
Share on other sites

Ok now that I have got the scene set up, nothing is working the way I would expect...

My motor object I created worked just fine until I attached my arm and spinner objects.
I tried different joint types to get it to lock in rigged, and even tryed a physicslink but nothing really worked. now it just freaks out.


I got it kinda working by reducing the mass a whole bunch on the arm and spinner anything under 0.005 it goes crazy though.

there has to be a way to make the joints "stronger", also even though its kinda working it still freaks out at first and hangs a little bit.


even once ballancing the machine, it still has its problems... it really kinda seems like it stems from weak joints or maybe im doing things wrong?



Link to comment
Share on other sites

Hi Pryme8,

I was trying to understand exactly what you are doing, and I believe this is caused due to limit settings of the 2nd hinge of the hinge2 joint, but it is really hard for me to follow your code. Sorry... I understand what you are doing, I see how I would be able to change that, but I really wonder why you use jQuery and the rigger class. You also keep on changing the local references to the joints themselves (using jQuery's extend), so finding exactly which joint is supposed to be changed is not an easy task.

I also try to understand why you need the "run" method. If you use a motor, you can simply provide the motor with speed and it will do the angular work for you.

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.


Link to comment
Share on other sites

God I love you Raan ^_^,


I am using the jquery to extend my prefab objects, so that way they fit the format for my rigger.  I like to keep some of my variables and settings defined on a separate container object for generation purposes.

I am doing my own motor class because I want to have a little more control over the physics and will be extending it to become way more dynamic then the built i class which will include torque settings or linear force settings so thats why I have the motor run function (I also use this method for AI triggers) I have not ever added more then like 3 though so Im not sure how it will impact performance having the register before scene run through an each loop that is too large.

The rigger class will eventually be developed enough to be able to do simple to more advanced machines with some fairly easy construction methods.  The idea of it is if you want to create a lets say catapult or something, you would build your rigger and then if you needed to make copys of that prefab, you will be able to pass the rig object to a object/scene management object and make copys of it in the scene without having to construct it again.  I am also interested in making a "prefab" editor where like in my magic marble demo you will be able to construct objects then export them as a .js file for import later in scenes which is handled by what ever object management class I come up with.

Is there a way to boost the strength of the joint connections?  Also if we are having a error with the way Oimo does its units would it be prudent to pass all values through a converter before handling variables from or to the physics engine?  Like if it goes to Oimo from Babylon it gets multiplied by 100 and if it comes from Oimo to Babylon then divide it by 100,  I'm not sure if there would be some loss in the calculations though, because I have seen that before when I bounce numbers between ranges (which does not make since [effen math])...

Im really excited to see your deployment of a vehicle class, and will GO TO TOWN once, I have all the information in front of me. 

Also quick opinion, if one was to make a dynamic tank tread would I use physiclinks or joints for connecting my treads? and then how could I restrict them from going "offline" and throwing themselves from their axis on the drive.

----  Secondary response :
".physicsImpostor.physicsBody.rotation.elements" -- OOOOO What is this madness, could you explain this please? I have never seen the physicsBody.rotation.elements before, and it looks to me to be a WAY easier way to reference the rotation of the physics object.

".setMotor(10, 100, 0);"  -- is this just setting the forceAngle and value?  how do I change motors settings besides force factors, are there any (would it be smarter to extend the motor class in Oimo or develop my own like im doing?" 

I think Im gonna make a reference page for Babylon called "Skin a Cat"  and have examples of redundant methods... so like you wanna rotate a physics object? ok here are 8 examples how to all with different methods, have fun.

----- And last....

I commented out

    /*pole1.physicsImpostor.registerBeforePhysicsStep(function () {
        var boxRotation = box1.physicsImpostor.physicsBody.rotation.elements;
        var poleRotation = pole1.physicsImpostor.physicsBody.rotation.elements;
        var poleOrientation = pole1.physicsImpostor.physicsBody.orientation;
        //console.log(boxRotation, poleRotation)
        var axis1 = new BABYLON.Vector3(boxRotation[1], boxRotation[4], boxRotation[7]);
        var axis2 = new BABYLON.Vector3(poleRotation[0], poleRotation[3], poleRotation[6]);
        var axis3 = axis2.subtract(axis1.scale(BABYLON.Vector3.Dot(axis1, axis2)));

        poleOrientation.mul(new OIMO.Quat().arc(axis2, axis3.normalize()), poleOrientation);

this entire section and effectively saw no change in the scene.

Link to comment
Share on other sites


I do understand why you have the rigger class, I just mean that it will take me longer to understand how it works, than to implement this on my own ;)

About the 100-times calculations, you are right. theoretically, multiplying and dividing a number by 100 will get the same number. You are forgeting that we are dealing with a digital number, that has a real limitation. even 64bit architecture has a limit to the number of places after the dot. and this is the problem. Oimo inverts the values you provide, and when they come back to "real world", they are... "rounded". Oimo has a WORLD_SCALE variable for that reason, but setting it makes everything slower. I can try and debug this, or simply recommend you - make a larger world :)

so,answering questions:

0) there is no way to make a joint "stronger". this is what the (oimo) physics engine provides. you can try cannon and see how the constraints work there.

1) ".physicsImpostor.physicsBody.rotation.elements" is the 3x3 rotation matrix of the physics body. very Oimo-specific code. this won't wok in cannon, of course. the rotation of the physics object can be simply retrieved using mesh.rotationQuaternion. this would actually work as well (converting this quaternion to a transformation matrix and using it to run the computations). This is the magic of Babylon's physics engine architecture :)

2) this is setting the speed (first variable) and (max) force (second variable). the 3rd variable is the index of the motor (as hinge2 has two motors).

Oimo only provides functions that are already available in Babylon's joint class. setMotor, setLimit are both implemented. you can see the (very simple) motor class here - https://github.com/lo-th/Oimo.js/blob/gh-pages/src/constraint/joint/LimitMotor.js . I am not sure what other functionality you want to add, but as Oimo is open source, you can of course extend it :) 

3) As long as you don't really skin a cat, it sounds like a great plan!

4) of course this function is doing something. This keeps the motor from rotation in an axis it is not supposed to rotate in. you just don't see it when the collision box is there. here: with - http://www.babylonjs-playground.com/#1CW6PI#1 and without - http://www.babylonjs-playground.com/#1CW6PI 

5) lowering the timestep will create more stable physics joints, as oimo has more time to calculate the rotations and has more time to correct mistakes. Lowering the motor speed will do the same job.


Link to comment
Share on other sites

I feel like we are getting to some real meat and potato conversation now!

Wont lowering the timestep create a choppy playback issue in gameplay?  Like lagged calculations?  Is there a way to sacrifice fps for calculations like increase the solver iterations?

Where would I start looking to creating a way to add a strength factor to joints?

I assume solvers iterations are handled by this?:

OIMO.Constraint.prototype = {
constructor: OIMO.Constraint,
* Prepare for solving the constraint.
* @param timeStep
* @param invTimeStep
Link to comment
Share on other sites

On mobile so a quick answer ☺

This will have to be implemented in oimo itself. Babylon is just using the existing engine with its upsides and downsides. 

The first example I posted had a time step set to 1/120, two times slower than the default 1/60. You didn't notice. Because rendering is still the same, it's just the physics calculations. They are still smooth, just move slower. Or faster, of course.

You can increase the solver iterations in the constructor of the plugin. Default is 10. new OimoJSPlugin(20) will set it to 20.

Coming in the advanced tutorial.

Link to comment
Share on other sites

^_^, I love it, a lot of these answers are unlocking the secrets of developing a fully deployed piece of production software as opposed to dinky experiments!

One question I think we skipped over is which method would be better for "tank treads" physiclinks or joints?

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


  • Recently Browsing   0 members

    • No registered users viewing this page.
  • Create New...