No collisions working on blender model

[user12345]

Hello!

I created a simple semi cylinder on Blender and imported it inside my game but for some reason the .checkCollisions of the model is not working. It is set to true , and the free camera's .checkCollisions is also set to true but the camera can still go through the model. I've tried with babylon meshes and checkCollisions is working fine. I even enabled collisions in the physics tab in Blender but nothing seems to be working. I am guessing the problem is with the model itself. But any thoughts on why it's not working? I attached the model here if you need to check it. Help would be really appreciated.

cylinder1.blend

[Wingnut]

Hi there, welcome to the forum.  No answers yet, eh?  hmm.

Ok, here's some things to try. 

- In Blender ensure your pivot point and ORIGIN... are set to center of mesh.  Make sure there are no scene transformations... where the entire scene is off-set, even though the mesh has a nice origin.  Sometimes, things can be learned... if you paste your .babylon file into an online JSON file viewer.

- Borrow lines 1-33 from this playground,  a badly-coded .showEllipsoid func.  You can see how to call it... in lines 110 and 120.  It might be handy... but no promises. 

About the PG:  WASDQE moves the left cylinder, shifted-WASDQE for the right one.  This playground is for an OPEN ISSUE where one collider climbs too high (in order to climb-over the other).  This issue should not affect you, yet.    Maybe later.  heh

- Dump mesh.ellipsoid (which is a size) and mesh.ellipsoidOffset (which is a distance)... to console.  They are both Vector3-type values I believe.  Give 'em a sniff.  These values should also be "see-able" within the .babylon file (should you decide to sniff-around within its JSONic ascii stuff.)   

If you scale a mesh, the mesh.ellipsoid MIGHT need scaling, too.  It might not be automatic.  This is what setEllipsoidPerBoundingBox func is used-for (line 35).  Borrow/use it, too... have fun.  These funcs were coded by me, so they are almost SURELY weak/un-versatile/inflexible.  heh

I guess that's all I have, for now.  Feel free to make more versions of that playground, possibly adding your mesh-importer into it, and trying to bring your model into that playground (if you have the .babylon file published somewhere, like a free github acct).  Perhaps others will have more ideas.  Stay tuned, and welcome again.

[JCPalmer]

You need to enable physics for Rigid Body, not Collision, because that's when you get UI for picking your Rigid Body Collision shape.  It is call a physics imposter in BJS.

You also need to check for collision in the custom properties of the mesh

[user12345]

On 8/22/2017 at 10:16 PM, Wingnut said:

Hi there, welcome to the forum.  No answers yet, eh?  hmm.

Ok, here's some things to try. 

- In Blender ensure your pivot point and ORIGIN... are set to center of mesh.  Make sure there are no scene transformations... where the entire scene is off-set, even though the mesh has a nice origin.  Sometimes, things can be learned... if you paste your .babylon file into an online JSON file viewer.

- Borrow lines 1-33 from this playground,  a badly-coded .showEllipsoid func.  You can see how to call it... in lines 110 and 120.  It might be handy... but no promises. 

About the PG:  WASDQE moves the left cylinder, shifted-WASDQE for the right one.  This playground is for an OPEN ISSUE where one collider climbs too high (in order to climb-over the other).  This issue should not affect you, yet.    Maybe later.  heh

- Dump mesh.ellipsoid (which is a size) and mesh.ellipsoidOffset (which is a distance)... to console.  They are both Vector3-type values I believe.  Give 'em a sniff.  These values should also be "see-able" within the .babylon file (should you decide to sniff-around within its JSONic ascii stuff.)   

If you scale a mesh, the mesh.ellipsoid MIGHT need scaling, too.  It might not be automatic.  This is what setEllipsoidPerBoundingBox func is used-for (line 35).  Borrow/use it, too... have fun.  These funcs were coded by me, so they are almost SURELY weak/un-versatile/inflexible.  heh

I guess that's all I have, for now.  Feel free to make more versions of that playground, possibly adding your mesh-importer into it, and trying to bring your model into that playground (if you have the .babylon file published somewhere, like a free github acct).  Perhaps others will have more ideas.  Stay tuned, and welcome again.

 

On 8/22/2017 at 10:34 PM, JCPalmer said:

You need to enable physics for Rigid Body, not Collision, because that's when you get UI for picking your Rigid Body Collision shape.  It is call a physics imposter in BJS.

You also need to check for collision in the custom properties of the mesh

Thank you for replying and welcoming me here! Since posting my question, I have played around with Blender and its options on my cylinder but sadly the only thing I've been able to acheive is to enable the checkCollisions option in Blender like JCPalmer mentioned. This option allowed for non physics contact between a Babylon sphere and the cylinder. But the problem is, it's required to apply physics on both the sphere and the imported model (the game is about rolling the ball while moving forward when the cylinder rotates about its pivot point. It's basicly a clone of a mobile game called "Tricky Trip"). I can't seem to be able to apply physics on the cylinder, have tried all imposters in the cannon engine, sometimes the sphere rests at the center of the cylinder(probably where its center is in Blender) and sometimes it just goes through the cylinder like it's not there. Tried adding rigid body collisions with different settings but nothing does the job of just rolling the ball over the cylinder or even inside it when they are in contact together. Here is a github link with a sample I've made to show you guys the problem, everything you need is in the folder. It may end up being a silly problem but I've spent days trying to get the physics working and without physics I think the game idea would be useless. Thank you again!

Github link: https://github.com/MoussaMohsen/webgl-project

[Wingnut]

*nod*  And you can ignore what I said, because I was talking about .checkCollisions, ellipsoid, ellipsoidOffset, non-physics engine stuff.  I misunderstood the first post.

We should not confuse the non-physics engine collider stuff (built-into BJS framework)... with the physics engine stuff (Oimo and Cannon libs).  They are separate systems.  Everything I stated... was about the non-physics-engine built-into-BJS collider stuff, created primarily for camera-to-mesh collisions.  Sorry.

By the way, a physics engine will not roll a sphere thru a tube, as far as I know.  There is no such thing as a tube impostor.  The best you can do is collide a sphere with the outside of a cylinder, I think.  You might be able to use a half-pipe (a sphere-rolling trough - like a gutter)... along with a cannon meshImpostor.  But a closed-volume like a tube... I don't think a cannon meshImpostor can do that (make the inside surface of the tube... physics-active).

Rough stuff.  Physics down the inside of tubes would be sweet, eh?  I think others have tried.  You COULD put maybe 8 invisible boxes on the inside of the tube... like chop sticks... long and thin.  Set boxImpostor physics on all 8 "guide sticks"... and the ball should "appear" to roll down a straight tube-like thing.

[user12345]

Yes , I figured that out. But it was actually my fault because I did not clearly explain my problem at first so no need to be sorry :). However, please if you have any idea on how to get it working I would be really grateful. We're finished with almost everything in the game and left with the most important part, the gameplay itself.

EDIT: actually they're supposed to be half pipes or with different angles , here's the game we're clonig (it's a university project nothing serious :D). 

Sadly, I've tried mesh imposters with those half pipes but no luck at all.

But yeah , this is getting really depressing not working as we intended. I guess I'll try other ideas without using those cylinders or even figuring out a different way to move the ball inside. We'll figure something out! Thank you for the quick replies Wingnut  .

a youtube video if you'd like to check the original game: https://www.youtube.com/watch?v=xV5RSKLXo-U

 

[Wingnut]

I wasn't quite done editing my last post... when you replied.     I added junk to it.

Wisest thing... leave Blender model behind, for now.  Use a stupid box or something... for your "vehicle".  No need for .checkCollisions, or moveWithCollisions(), or any of that.  In a playground or somewhere, set a few basic shapes, turn on scene physics and pick your engine. Set your shapes with basic sphere/box impostors.  Now start trying to "drive" the box vehicle with either applyImpulses or setLinearVelocity/setAngularVelocity.  Spheres have no surface area on bottom, so friction essentially doesn't stop them from rolling forever.  Boxes with high mass and friction, WILL eventually skid to a stop against the ground.  You can also fire "retros"... reverse applyImpulses or inverted linearVelocities... to stop things.

Rumor has it... that you CAN "force"-position the vehicle mesh itself, and its impostor MIGHT come-along.  But more think this is "overriding" the physics engine and that its a bad thing to do.  Our friend Adam and/or Fenomas... suggest we put an invisible mesh ABOVE our physics-active player, hook a physics joint between the two bodies, and then force-move the invisible mesh, and let the joint drag-along the actual player/vehicle.   High mass helps keep players/vehicles from tipping-over.

How's that for a pile of TMI? 

[user12345]

Nah that's great information  . Maybe I will leave those models, after all it'll be a waste of time.  We'll probably try to enhance those basic concepts and add some ideas to create another game without those models. Again, I thank you for the time you took to reply and help, Wingnut. Really great forum! 

[Wingnut]

https://www.babylonjs-playground.com/#15AFCG#22

There's a playground with some physics things and applyImpulses hooked-to I, J, K, L keys, and also to some numeric keypad keys.  It gets you started with moving physics-active things.  They slide and slide and slide, eh?  Friction up, mass up. 

But if your vehicle/model is a fully physics-active car, with real physics wheels and stuff... then... umm. 

[Wingnut]

The models CAN be used later, of course.  The Cannon meshImpostor can do almost ANY model... and will try to honor its shape, no matter how strange-shaped.  But that can cost ya, perf-wise.  If your model, no matter how fancy... ONLY uses a basic box impostor as its impostor... then it stays fast, but its unrealistic.  For example, a box impostor around a helicopter... won't realistically collide its tail-boom... into telephone poles... when it swings around.  To get more realistic, a "compound impostor" is formed... via parenting.  The tail boom would have its own box impostor, each landing gear would have a box impostor, and the main rotor (perhaps each blade)... and the tail rotor (perhaps each blade).  We have seen parented mesh with parented impostors like this... work.  They create an oddly shaped "compound impostor"... yet maintain good speeds because each "child impostor" is a boxImpostor (as opposed to using a cannon-only meshImpostor to impostorize the entire helicopter shape).

With some imagination, some very "techy-looking" vehicles can be made... by parenting-together many different basic BJS shapes (with code).  It takes patience, but you can write a func that generates a "friggin awesome vehicle from standard shapes", and it automatically puts a box impostor on each little piece (if you wish).  Try not to let ANY two impostors... positionally overlap.  No overlapping mesh.  If any mesh on the multiple-parts vehicle... overlaps, their impostors will fight with each other... because they are colliding.

The built-into-BJS colliding system seems easier, eh?  nod.  Lots less power, though.  No "precision" physics, no mass, friction, restitution.  Just gravity and camera bumping into stuff.  A lightweight colliding system... but fast. 

My flying bobsled... is a grown-by-code model.  It's not textured very well... but it flies.  Its central white box parent... has 24 thrusters active.  SHIFTED or CONTROL + numeric keypad keys, flies it.  Also shifted or control arrow keys (with pageUP and pageDOWN).  It uses micro-pulsing, so HOLDING these keys... is often used. 

Zero-G vehicles are SUCH a pain-in-the-butt to fly, huh? 

Borrow all code at will.  Notice I used ALL applyImpulses for my vehicle controller, but it could be done easier with setLinearVelocity and setAngularVelocity.  I coded this before I knew about those.    Still, I really like the bobsled.  It's fun.

[user12345]

There's too much to learn, I've only started about a month ago so practice makes perfect! Unfortunately, the project's almost due in a few days so we'll not have enough time to play around and try everything. But I will definitely be learning more on my own. The parenting-together idea to generate a single body actually sounds interesting, I'd like to try that sometime. 

Looks like I cannot open your flying bobsled at all  getting this: "Line 10987:29 - this._gl.createQuery is not a function".

[Wingnut]

Ok, then, to help you out quick... bring the models into the scene without ANY physics impostors or collisions set in the export.  Get the mesh to display well.  THEN, add impostors in the JS.  Put a boxImpostor on the vehicle model, put some physics active boxes out in front of it, and then vehicle.phsyicsImpostor.setLinearVelocity(new BABYLON.Vector3(0, 0, powerlevel).  With low enough mass and friction, the box/vehicle SHOULD move forward and crash into the other temporary phsyics-active test mesh.  You've built a bulldozer.  Yay!

Now goof around until you can turn it... with vehicle.physicsImpostor.setAngularVelocity(new BABYLON.Vector3(0, -powerlevel, 0);  Now you've got a turn-able bulldozer.  Maybe build an ALL-STOP func, that kills all linear and angular velocity... using the methods above to set (0, 0, 0) values.

That's a pretty good quick-jump into physics.  Controlling the vehicle/player... when they are physics-active... sucks, eh?  Hard to build a "oneStepForward" func and similar... because these damn things slide/skid. 

Good luck, my friend.  It is a shame you are under a deadline.  I hate them things. 

[user12345]

Yeah no one likes deadlines, they are a pain-in-the-butt just like flying Zero-G vehicles  Thank you, sir .