Cannon JS Problems

[Aerion]

Hi all. I'm not really new here, but technically I am since I haven't logged on in about 4 years. I need some help fixing this cannon JS playground I created. 1st thing's 1st. Why are all the spheres rendering slowly once they touch the ground of the terrain height map? I want this to run at a persistent 60 Frames Per Second.

Second thing. I want to have the camera as a "player" in which he can walk all around the heightmap terrain and up NON-STEEP slopes where he slowly slides down STEEP slopes. Forgive me if I'm being a little too less descriptive. I will try my best to explain if that is the case.  Anyways, thank you ALL VERY much for all the help! <3

Here is the link to the playground : 

https://playground.babylonjs.com/#7JDXMW#22

Mythros

[Aerion]

Can someone help?

[Wingnut]

Hi Mythros.  http://playground.babylonjs.com/#7JDXMW#29

Not really solved, but better.  Let's see, I removed some things that are only needed for non-playgrounds.  I also removed the dispose/createBall (in the renderLoop) and instead, I null-out the linear and angular velocities and then re-position the balls... whenever they fall off the ground.

I also reduced to 50 balls, and drop them from a lower altitude.  For some reason, when we were up at 100 balls, things got slow and garbage-collectful.   Not sure why, yet.  It still seems to want to drop FPS periodically, but recovers after a few moments.  hmm.

Anyway, I'm pretty fried from a rough day, but I'll be back in 10 hours and we'll check some more things and see what we learn.  Sorry for the slow replies.  Be well, talk again soon.  Other forum helpers... jump-in and make comments and adjustments, thanks.

[Aerion]

Thank you bro for the awesome response! I wish it wouldn't drop FPS. I'm gonna need to be around potentially hundreds of big objects at once. Think in terms of an MMO setting. Is there a way to cap it off and interpolate it or something so that CAN happen?

Thank you once again for all the help! <3

Mythros

 

[Wingnut]

Cool.  Yeah, I don't know if you are going to get wanted performance numbers from JS-based physics engines.  Even non-JS physics such as Ammo and Bullet... they will be running full-throttle to do "hundreds of big objects".  It is nice to have big dreams, but, you know, reality can get in the way. 

Box impostors would be faster than sphere impostors, I would think, but, they don't always give realistic physics motions on complex models.

IF your models will ALWAYS be spheres or need only sphere-like "tumbling" or "rolling", then there are some options.  You would leave-behind the 3rd-party physics engines (Cannon/Oimo), and do your own "thing".  (That thing is by @jerome, using his marvelous Solid Particle System.  He has many demos, so do a little sniffin', as wanted.)

Notice how much more "zippy" (fast) the SPS system is?  But it doesn't do SUPER-realistic physics-motions/forces.  Jerome used his math skills to make "bare bones" motions... and because he is not doing super-precise calculations, that is why the speeds are SO GOOD.

All in all, keep in mind that we are in JS land, not in assembly language land.  What you describe... would REQUIRE near GTA5-grade physics and LOD management.  I don't know if you can attain that... with JS.

Tell me more.  CAN all your physics impostors... be boxImpostors (won't "roll" like a sphereImpostor, but WILL "tumble" across landscapes)?  With ALL-boxImpostors... that would be your best chance (while using 3rd party physics).  Sorry if this is bad news for you.  Perhaps JS things will improve in the future.

[Raggar]

I think it might be due to the Heightmap/field.

Here are 2 quick tests, both creating 200 spheres..

1) Impostor system using a normal CannonJS ground/infinite plane:

http://playground.babylonjs.com/#MN5IV7#2

2) Native CannonJS, ground as well:

http://playground.babylonjs.com/#H1CEDV#1

As Wing mentioned, if you need hundreds, or even thousands, of individual bodies, you'll hit the CPU hard. You might instead have to do some trickery to make it appear as you have actual collisions.

Another interesting thing that might potential be usable in the future, is a project by @schteppe (The creater of CannonJS):

https://github.com/schteppe/gpu-physics.js

https://schteppe.github.io/gpu-physics.js/demos/boxes.html

I have no idea whether this would eat too much GPU resources, though. It would need to be modified to use BabylonJS's renderer, though. Nothing I know anything about. I'm not even sure this would be beneficial in game development.

[Aerion]

This is upsetting.. There should be a correctly working ammo / cannon / oimo demo dealing with walking around a heightmap terrain without fear of FPS drop or fear of walking onto a SMALL slope and experiencing not being able to walk up the smallest of slopes. Need to be able to slowly slide down a VERY steep slope. : (

Mythros

 

[Wingnut]

Yep, let your "upset" motivate you to code-up a nice demo for us.  We're an all-volunteer team, and not a customer service center.  We can use your help - Mythros' HeightMap Physics FPS Game Starter Kit. 

BabylonJS is a framework for user-friendly accessing of webGL via JS, and the physics engines are 3rd party (with their own help forums).  It is the users of BJS that build the advanced toys, and you are one of those users.  The core team for BJS... is primarily concerned that the webGL 1.0 and now, 2.0 specs... have their API as exposed to JS as is possible, and that it works as best it can.  A side-team works tirelessly to ensure that exporting models from popular modeling software... works (even with ever-evolving modelling features).  Another side-team is working on importing all the newest filetypes for models and textures.

This affords a sweet open-horizon and potentially lucrative opportunity for people like you.  You can start a company of video game-making tools, based-upon the BabylonJS WebGL framework.  Pretty nice of Deltakosh and the core team... to provide you with that opportunity AT NO COST TO YOU.  It is as if Deltakosh (and the 3rd party physics engine authors) GAVE YOU a wonderful building and property... to open a game-tools company.  Other users GAVE YOU an interface between BJS and the 3rd party physics engines, FREE.

And let me tell you about performance considerations.  Thousands of hours by core team and testers have been dedicated to making JS->BJS->WebGL run just as fast as it can... all without ANY work done by you.  Think of what has been provided to you.... for free.  An opportunity for success SO LARGE and SO tweaked... that you are ALMOST guaranteed a successful game series and business opportunity.  It is as if 1000 webGL experimenters... put all their tools into a semi-truck, and backed it up to your computer room window... for you to use... for free.

Has ANYONE EVER done something SO NICE for you, before?  Do ALL the tools in the truck.... have hand-holding documentation on how to use all those tools?  No, but we're working on that very sternly and steadily.  Problem is, people are inventing tools faster than we can tell folks all the cool things those tools can do.  That is because these cool tools can do SO MANY THINGS, and we can't even start to imagine-up all the scenarios that could benefit from any given tool.  We would need to be able to predict user's dreams and imaginations... to do that.  It is an overwhelming amount of work for an all-volunteer spare-time-only documentation team.

If you take the time to "see" just how many wonderful features and demo playgrounds have been made with BJS (and even some that use the 3rd party physics engines, who have their OWN forums)... you would understand.  Core team is a small team.  Why?  Because as soon as someone starts using BJS... they have difficulty getting work done - because the framework is SO MUCH FUN! 

We have seen SOME ragdoll-ish physics-active skeleton/bone walkers, but none with inverse kinematics that can transfer mass, friction, and foot push-away... thru an entire physics active skeletal structure... on non-level ground.  Most... fake it.  But please, feel free to create the skeleton with mass, climbing hills.  Pick your shoe impostors, get your bone-to-bone forces transfer calibrated, and then see if the 3rd party physics engine can properly calculate the amount of foot-slipping on the ground.  Those users who DO make things like that, and get it right, are not always willing to give that work away.  It is part of THEIR company's "trade secrets" and, can you blame them for being that way?  They are competing, and thus, they don't WANT the competition to have that free code.

Yet, I do understand what you feel.  But webGL is still an "unfolding" and evolving tech.  It's bleeding edge.  It runs in a browser and requires no game client to speak-of.  Can you say HOLY CRAP, BATMAN?  Please take a moment to see what a wonderful opportunity has been given, for free, and with SOME very friendly and quick customer service.  Please take a careful look at the tools that are in the semi-trailer that is freely backed-up to your computer room window.  BJS is a pile of tools that can be used (easily) to build game-starter scenes, but generally-speaking, we do not build or provide game-starter scenes.  Be well, party on.

PS:  Here is some recent work by @Raggar, working to advance older @Samuel Girardin demos... to newest BJS, and for future use with CannonJS instead of Oimo.  https://www.babylonjs-playground.com/#G9ZBQ1#6  Keep tapping P, with an occasional H and G.  Here's the thread... a real recent one.  Sammy has over 100 hours into this.  Raggar probably has 40 hours into it, along with his brand new syncBoneWithImpostor framework mod.  Nice of them to give it to us for free, eh?  *nod*  Love thy coder.

[Raggar]

16 hours ago, Mythros said:

This is upsetting.. There should be a correctly working ammo / cannon / oimo demo dealing with walking around a heightmap terrain without fear of FPS drop or fear of walking onto a SMALL slope and experiencing not being able to walk up the smallest of slopes. Need to be able to slowly slide down a VERY steep slope. : (

Mythros

 

I'm not quite sure what you're looking for, but here's a simple example of first-person controls on a heightmap. Use WASD to move and the mouse to look around.

https://www.babylonjs-playground.com/#FZZV7K#4

This is using native CannonJS, but is Just as easily created using the impostor system.

[Aerion]

@Raggar This is pretty close to what I'm after. When holding W on a slope, the "player" for some reason is "bouncing" when letting go of the W key. The character seems to get stuck when colliding with the green wall. When on any slope that is not > 45 degree angle, the character seems to be automatically sliding down without moving. When trying to travel up a steep slope, the "character" should slowly slide down as if the "player" cannot climb the slope at a > 45 degree angle. The player can slowly climb a 45 degree angle. And can normally climb a < 45 degree angle. I hope I was clear. If not, I can explain in depth for you more.

Thank You again! <3

Mythros

[adam]

Sounds to me like a physics engine is more than what you need.  You should probably just be moving the players according to the height and normal of the ground.  This might be difficult if you aren't very good at math.  I'd start out by looking at the code of one of @jerome's ground mesh demos - the one with lots of agents moving on the surface.

Edit:

http://jerome.bousquie.fr/BJS/demos/getHeightAtCoordinates.html

[Raggar]

@Mythros

You'll have to play with mass, fixedRotation, gravity, friction, restitution and all other contact settings and tweak those to get your desired results. You might even have to calculate the degree of the slopes/ramps and then apply forces to get it to work correctly. Based on the type of game, adam's suggestion might be a better fit.

[Aerion]

This demo is exactly what I want, but it's using particles. Is there a demo that can replace the particles with meshes?

Thank you! <3

Mythros

[adam]

https://playground.babylonjs.com/#WYTQJ9

[Aerion]

How to make the player slowly slide down steep slope?

[adam]

This demo was only to show you how you can get the position and normal at a location on ground mesh created from a height map 

I would try this:

Get the position of the ground in the direction the player is moving and then the direction from the player position to that ground position.  Scale that normalized direction by the speed you want to move the player.  Then add that scaled direction to the current player position to get the new position of the player.

[Aerion]

forgive me.. i do not understand.

[Aerion]

anyone?