I think there may be a bug in the interaction between HAVOK and AR.
What I am seeing is that physics collisions takes a seemingly random amount of time once the engine is initialized to actually kick in (and sometimes it just never does), despite gravity and all other physics elements working from the start. I don’t exactly understand what its waiting on. But, if I run the exact same code from a desktop environment, instead of an AR instance (using the default AR helper), everything works perfectly.
Note, when it does kick in, sometimes if the physics elements move out of screen and then return then the next time any interaction happens with them they all lose their collision behavior.
Example:
The new box should just collide with the others and settle on the ground, not cause the other boxes to collapse through the floor. This is reproducible by looking away from the boxes in AR, then looking back and continuing interaction.
My code is fairly stock from the example code using NPM, just merged into an AR scene.
For the first scenario, it looks like the ground doesn’t have a physics body for those initial frames? Can you try adding the physics viewer to see if we have a body there? And yeah, seconding Raanan, the code will definitely help here
I went ahead and implemented “Room Scale” Collisions as I was curious if maybe it was just how I was generating my test collision mesh - a thin mesh rectangle. Sadly, the same issue remains. Its very strange in that the period of “waiting” before collisions kick in has no real rhyme or reason I can tell - and sometimes they just don’t.
But, when they do kick in its really cool!
What is odd about this one is you can see the moment the collisions kick in, right after the second cube spawned passes through the table but before it hits the floor.
@carolhmj I just sent you an invite… RealiBots. Other eyes are welcome.
Once you compile, launch it, move around the room a bit, everything mapped for collisions will get a grid pattern. Once that is done, tap anywhere in the environment. This stops all XR room mapping (Havok can’t live update collision meshes so additional XR plane mapping needs stopped before I grab those planes for collision generation, at least it looks that way now) and brings up the interface to drop the spawn location for the collsion test-cubes. The Ying-Yang button has been temporary hotwired for spamming cubes, but only at the point in the world you tap.
Collision meshes for the room are generated in xrManager.ts, very bottom in addCollisionsToEnvironmentMap().
Cubes get their collisions in robots.ts init() function.
Once compiled using the standard npm run-script build the realiBots.js should auto generate into the dist/src. Move the entire dist folder onto a webserver as this is back to being AR only so you will have to connect in from an AR tablet/phone.
The game launches into mapping (no interface yet) as soon as you smack the Babylon XR goggles on the webpage. Once you get an area mapped (it will overlay with the grid pattern) if you tap the screen when looking at a mapped area it will anchor the test-cube spawner there and bring up the workshop interface. This will also stop AR mapping of the environment. First button a placeholder ying-yang will spam collision enabled cubes. Third button - the second snowflake switches to an occlusion / shadow material . I disabled all other buttons for now.
Ground collision meshes gets their collision at the very bottom of xrManager.ts
Test cubes get their collision in robots.ts in init().
Some compiles work better than others, as in sometimes collisions work right out of the box, other times they kick in after one cube falls through everything, other times they all ignore collisions.Even small changes (as small as a anywhere in the code seems to drastically alter how successful collisions are. Though switching from a basic collision plane to the roomscale collision meshes seems to have drastically helped.
Eoin, whenever you have time, I’d love if you could check this out? It’s a really cool project but I’m a bit stumped as why the collisions sometimes don’t work
Hey, since you mention that it’s working on the desktop, what platform are you seeing that it doesn’t work on? Is it on iOS, by any chance? Before Babylon 6 was released, we hit a bug in the Safari WASM runtime which caused incorrect results, and from your description had very similar symptoms but I thought we added enough workarounds. Can I also ask if you’re calling physics functions or creating physics bodies/shapes from web workers?
This is all Android using BabylonJS’s WebXR AR capabilities through Chrome. Sadly iOS does not have XR support yet, and doubt they will until closer to the shipping of their headset. I am running the latest stable of Babylon, 6.10.
I only temporarily dumped things into a “normal” 3D environment to sanity check / test to make sure I was not doing something stupid with the basic setup using the NPM package. I don’t still have the setup as it was a very quick hack and I did not bother saving it.
Right now I am creating bodies only, but functions (and forces) will start going in in the next few days.
Happy to give you repo access to investigate if that helps, just PM me your git username. Right now things are very early in the process, just proving some basic features out, so quite easy to read the source. All the Havok code to date is probably around 12 lines including the include statements.
It “feels” like something is not having time to download / initialize. The strange thing is the behavior is the individual compile. It behaves identically each time you fire it up until you recompile, but then you make even a tiny change (as small as remove an extra space after a line) anywhere in the codebase, recompile, and then clear web cache on the device clients and launch BabylonJS as a webapp again, and its a roll of the dice what behavior it will manifest. So, it does feel “webish” where something is not downloading / initializing correctly. But, I am fully willing to acknowledge its equally possible I did something dumb with my setup, as simple as it is. I have not touched HAVOK for a few years and this is a different engine.
By the way, do you have a list of devices where you’re testing? I wonder if we can find a pattern by looking at the devices where it works every time and the ones who don’t
I bought a Samsung S6 Lite Tablet (newer common tablet in most USA stores) last week to test if it was a device specific issue. But it had issues with running ARCore video at really low resolution with lots of ghosting, so returned it.
Prime day is tomorrow and plan on grabbing a few ARCore test devices if cheap to test. If nothing good then I will raid a few local stores for tabs / phones.
So, I will have a few devices to test soon. What device are you using to test with that seems to have 100% success?
The intermittency in the the physics failure is what is baffling… Every time you recompile, clear cache and reload the website from scratch is when the behavior changes… But until you do a full recompile cache clear… things stay consistent, no matter if that consistent state is “working everytime” “sometimes” or “nothing is colliding ever” It really feels like something is not downloading, or the Web worker (plugin app) itself is having trouble. It is very strange.
I went ahead and added in an option to the in-game menu to toggle collision meshes on the fly… There is now a check mark in the debug options tab. I can confirm they are 100% there from the get-go. They just are not colliding. Change are all on GIT.
It is making more sense why sometimes they “start” working fine and land on a surface, collide, and stop. But, then when you look away and look back and drop a block the ones nearby the dropped block all start falling forever… (my second post from the top above). It looks like their collisions switch to sleeping mode once they hit the collision surface initially. Then, when the new block is dropped it causes them all to wake up, for some reason don’t register the collision mesh under them, and so start falling again…
If I could not see the collision mesh with the debug I would think ARCore is losing position tracking and moving the collision planes out from under the boxes. But you can see it, and it does not really move. So, why this is happening I don’t quite know. Its likely the same reason they sometimes just never register a strait collision which initiated this thread. It is infuriating though, cost me over a week of progress as its hard to make progress implementing physics assets when the physics system is randomly glitching. Just passing info along that may help us resolve this.
I grabbed 6.11.2 of Babylon’s NPM packages (latest). No change, but the changelog is two days old. Did this go out to Master yet? If not what branch is it pushed to?
Note I also grabbed an assortment of tablets today from all the sales. They arrive by the weekend, so will be doing some testing to see if this is truly device specific.
The old phone still exhibits the same bug behaviors as before. It may be bugging less so. Collisions have worked a few times perfectly on first load and I have never really seen that before. But other times the system manifest the same old delay in collision detection bug, or the sleep wake collision bug, or just does not apply collisions. Hard to tell if its an actual improvement as I am traveling so only very limited testing time until this weekend and this bug is so intermittent I may have just gotten a “lucky compile” where its less noticeable.
I did swing back home before my work trip to break out one of the new tablets (Samsung Galaxy Tab S8+). This worked even better in terms of registering collisions as you would expect durring the five minutes of testing I had. But, that is not exactly exhaustive. I can confirm that the sleep wake collision bug (my second post video) did occur once, so that part of the issue remains, but it did feel like a solid improvement in terms of initial cube spawning registering collisions.
When I get back home tomorrow night I will try other two tablets and do more extensive testing w all devices on Saturday when I can get back to dev.
anywhere in the code seems to drastically alter how successful collisions are. Though switching from a basic collision plane to the roomscale collision meshes seems to have drastically helped.
