Hans Posted April 19, 2017 Share Posted April 19, 2017 Hi @all, Is there a problem with the HeightmapImpostor? In my test application dont work the pyhsics anymore. The player and other objects fall now through the ground. let groundFHM = BABYLON.Mesh.CreateGroundFromHeightMap("groundFHM", "textures/heightMap.png", 100, 100, 100, 0, 10, scene, false, function () { ... groundFHM.physicsImpostor = new BABYLON.PhysicsImpostor(groundFHM, BABYLON.PhysicsImpostor.HeightmapImpostor, { mass: 0, friction: 0.2,restitution: 0.3 }, scene); }); In this Demo from @Wingnut http://www.babylonjs-playground.com/#1RKZXB#6 works the physics also not correct at all. Edit: In my older babylon.js alpha version this works by the way Quote Link to comment Share on other sites More sharing options...
GameMonetize Posted April 19, 2017 Share Posted April 19, 2017 Ping @RaananW who should know Quote Link to comment Share on other sites More sharing options...
Wingnut Posted April 26, 2017 Share Posted April 26, 2017 Hi guys. http://www.babylonjs-playground.com/#1RKZXB#8 Hans, I will return the favor (for you fixing onCollideEvent for me). - in render loop, there is no .linearVelocity property on a CannonJS-based ._physicsBody. It is called .velocity. (so much for physics engine standardized property names, eh?) The .angularVelocity property DOES exist. So, now, lines 54-55, OR lines 57-58... can be used to null-out energy/momentum. Not sure WHY "blast-out" on scene load. Box bodies seem to have energy at creation time. Use same methods to null energy just after box.physicsImpostor added.... see if blast is eliminated. Possibly another framework bug... there. MORE likely... your after-box-creation .positioner is allowing mesh to overlap impostors, and they reject that... thinking it is a collision that needs restitution solving (physics engine quickly/instantly de-overlaps the impostors, with high-force, considering restitution = 1.0) --------------------- Now, for other problem. I think there has been recent work happening... on boundingbox 'extends', which is a measuring tool, I believe. As you can see, the heightMap impostor (which I forgot existed, and thus, I have been forgetting to tell others about it, when discussing physics-active terrain)... is working ONLY in front-left "quadrant" of the terrain. hmm. There appears to be a plug in the bugin. Errr... I mean... a bug in the plugin. --------------------- Lastly, let's bother @Temechon and DeltaJesus... about how this demo keeps reporting having no metadata, even though it has some. (Wingnut pushes an Otoscope into the playground's ear, and looks-around in there.) heh (looks complicated, dog got scared, ran under fridge) Hans 1 Quote Link to comment Share on other sites More sharing options...
Hans Posted April 26, 2017 Author Share Posted April 26, 2017 I have also a stange behavior with parenting and physicsImpostor, but i can`t reproduce it for now. The Problem there is: I have a main object (mesh) with pyhssicsImpostor. Many other child objects with own physicsImposter are parented on runtime to the main object. After one two ... it becomes all strage somehow. childobjects appear on wrong positions, some child objects have no physics and so on. AND: the important thing: In some cases the onCollideEvents tells me I hit the main object ... but it hits a child object. Dont know, but maybe it belongs together with the problem from above. Wingnut 1 Quote Link to comment Share on other sites More sharing options...
Wingnut Posted April 26, 2017 Share Posted April 26, 2017 You could certainly be correct on that. Are you remembering to set physicsImpostors on children FIRST, and parent LAST? *nod* Thanks for reports. There's not many people building compound-like impostors... with parent-child mesh. Please feel free to tell everything, even if it seems nobody is listening. Thanks! Good luck. I will try some tests tomorrow, possibly. Forum helpers: Issues remain open. Assistance welcome Hans 1 Quote Link to comment Share on other sites More sharing options...
Hans Posted April 26, 2017 Author Share Posted April 26, 2017 3 minutes ago, Wingnut said: Are you remembering to set physicsImpostors on children FIRST, and parent LAST? i did! I also tried physicsImpostor.forceUpdate(); I also tried to relaod all Impostor on runtime after a main object dispose. This problem unfortunately prevents me from moving forward in my project Quote Link to comment Share on other sites More sharing options...
Temechon Posted April 27, 2017 Share Posted April 27, 2017 17 hours ago, Wingnut said: Lastly, let's bother @Temechon and DeltaJesus... about how this demo keeps reporting having no metadata, even though it has some. (Wingnut pushes an Otoscope into the playground's ear, and looks-around in there.) heh (looks complicated, dog got scared, ran under fridge) Because you didn't fill all fields Wingnut 1 Quote Link to comment Share on other sites More sharing options...
Wingnut Posted May 1, 2017 Share Posted May 1, 2017 Hi guys. http://www.babylonjs-playground.com/#1RKZXB#11 Same playground, same problem with physics active ONLY in front left 25% of heightMap. BUT... this playground has ALL 4 BJS physics-class objects... that get used in this scene... hijacked into the playground (for maximum hacking ease). (All physicsJoint classes, all physicsImpostor classes, the physicsEngine class, and the CannonJS plugin class.) Line 950... reports dim as 250. The terrain is actually 500x500. I force-changed dim to 500 and 1000. No changes on "fall-thru" areas of terrain... but it DID appear that the impostor extended beyond the actual mesh shape... on the left and front edges. So, impostor DID appear to get bigger... but in wrong direction (-x and -z). It needs to extend further +x and +z. We are elbow-deep in the porridge pot now, eh? heh. Fun and scary at the same time. Perhaps we will discover something pertinent to the issue, or at least blaze a trail for big dogs to bring-in the heavy equipment. Hey Hans... remember seeing @RaananW saying something about "extends" in an answer to another physics issue? Might have been you. It was in a thread about a sphere rolling down a simple ramp. We also talked about it in PM. Well... look at line 949. The .extendSize property is used twice in that line. That deserves a chocolate-coated 'hmmm'. Lines 1025-1033 ALSO use .extendSize property... for heightMap. I wonder if .extendSize USE TO return diameter (100% of bounding box 'extent') , but due to some recent changes, now returns radius (50% of bounding box 'extent'). I wonder if controversy and international intrigue... is involved. Maybe there's finger-pointing happening! WOW! A forum search for extendSize... brings some interesting readings. Quote Link to comment Share on other sites More sharing options...
Wingnut Posted May 1, 2017 Share Posted May 1, 2017 WHAT IF... Raanan is intentionally dragging his feet (being hesitant)... on updating all the physicsImpostors... to use the new boundingBox.extendSize... because he thinks changing it was TOO TOO big of a change, and will be reverted after a re-think by the Gods? WOW! Some guy named Professor Cheesegrater... brought in a PR... said... "here are 22,408 reasons why we need to change .extendSize from full-extent (diameter-ish)... to half-extent (radius-ish). Deltakosh, being kind and flexible as we know him to be... said... "well, okay Mister Cheesegrater... I will accept this PR into core, but YOU must answer all the messages about ALL the things that will break... because of this change." Well, the error reports immediately started arriving... and all the custodians of the "affected systems" pretty much asked "whaaacha dooooon?"... and they got grumpy... cuz stuff broke. It was all caused by Professor Cheesegrater's "need". SO NOW... we got drama. WHO is Professor Cheesegrater? That CAN'T be his/her real name. Is it Nockawa? Is it JC Palmer? Is it DeltaKosh'n'Karry himself? Perhaps Jerome? Dad72? Raanan... holding his ground... "NOT gonna change anything yet. I think ya'll are gonna revert to old way. I smell it in the air." Ok, that's all a made-up story, but... wow, huh? Quote Link to comment Share on other sites More sharing options...
Wingnut Posted May 2, 2017 Share Posted May 2, 2017 Nuthin', eh? Not a laugh, not a complaint, not a drop of talk about extendSize, nobody working physics issues except Hans and Wingnut, huh? Phew. It's almost like we asked, publicly, for someone, ANYONE, to quick-test some virtual joysticks. LOL! (inside joke) Whelp, Hans... I found this... https://github.com/BabylonJS/Babylon.js/search?q=extendSize&type=Commits&utf8=✓ 20 days ago. hmm. Line 908 in our test playground... shows it. var extendSize = impostor.getObjectExtendSize(); Interesting. This is for the impostor only. I don't think impostor SIZING is the problem, but perhaps impostor position IS. Move it 250 units northeast, and it is fixed, I believe. Not sure how to do that. (-x and +z? Sorry. I'm not used-to working-with alpha=0 arc cams. I always set my alpha to -Math.PI/2) I think... lines 1013-1036 is the problem area... 1013 //If it is a heightfield, it should be centered. if (impostor.type === BABYLON.PhysicsImpostor.HeightmapImpostor) { var mesh = object; //calculate the correct body position: var rotationQuaternion = mesh.rotationQuaternion; mesh.rotationQuaternion = this._tmpUnityRotation; mesh.computeWorldMatrix(true); //get original center with no rotation var c = center.clone(); var oldPivot = mesh.getPivotMatrix() || BABYLON.Matrix.Translation(0, 0, 0); //rotation is back mesh.rotationQuaternion = rotationQuaternion; //calculate the new center using a pivot (since Cannon.js doesn't center height maps) 1025 var p = BABYLON.Matrix.Translation(mesh.getBoundingInfo().boundingBox.extendSize.x, 0, -mesh.getBoundingInfo().boundingBox.extendSize.z); mesh.setPivotMatrix(p); mesh.computeWorldMatrix(true); //calculate the translation var translation = mesh.getBoundingInfo().boundingBox.center.subtract(center).subtract(mesh.position).negate(); this._tmpPosition.copyFromFloats(translation.x, translation.y - mesh.getBoundingInfo().boundingBox.extendSize.y, translation.z); //add it inverted to the delta this._tmpDeltaPosition.copyFrom(mesh.getBoundingInfo().boundingBox.center.subtract(c)); this._tmpDeltaPosition.y += mesh.getBoundingInfo().boundingBox.extendSize.y; mesh.setPivotMatrix(oldPivot); mesh.computeWorldMatrix(true); 1036 } Remember that I said earlier... when I force-set dim = 500 (line 949 area) , the physicsImpostor extended beyond the terrain... backward (toward camera) and left? Well, it does same for dim = 250, too. (default dim) Go fig. I tried some things. For every X and Z occurrence of getBoundingInfo().boundingBox.extendSize (in the above code), I modified to... getBoundingInfo().boundingBox.extendSize.scale(2) ( no change ) then... getBoundingInfo().boundingBox.extendSize.scale(.5) ( no change ) Oh well, it was worth a shot. I also tried those .scale(.5) and .scale(2) adjustments... in line 1025. No changes. I think the impostor is mis-translated (bad position). Even in the #11 playground (generally un-modified, with non-forced dim = 250), the heightMap impostor is extending beyond the terrain on left and camera-facing sides. Watch carefully.... you will see boxes tumble-across terrain-less areas. The impostor is only mis-positioned, I think. See line 1024? "//calculate the new center using a pivot (since Cannon.js doesn't center height maps)" hmm. That might be a Texas-sized hint to our issue. Sorry, Hans. No progress, yet. I'll keep studying it. Forum Gods, we could use some help, here. Hans, are you pretty good with the matrix translation stuff? Thoughts? I'm really not qualified to work this physics active in back left quadrant ONLY -issue ("back" = closer to camera). Quote Link to comment Share on other sites More sharing options...
Recommended Posts
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.