Why does one project have an option for the Legacy Physics Library while the other project does not?
I need the legacy physics to maintain app compatibility with IE 11. Otherwise I’d have no problem using the new WASM components. I understand that the IE 11 fix has been made, but it won’t be available until some future build.
I can confirm that behavior, I think that something along these lines happens:
At least that’s the pattern I see in my projects.
So if you need the feature, you would need to fork an old project.
BTW, slimbuck has reported that the bug on IE 11 has been fixed. But there is no way of knowing when that will be released.
Usually there are weekly turnovers for editor updates.
In that case it may eventually not be much of an issue for me. We’ll see. I’m currently trying to get to the bottom of why my raycasting is not working (with Ermis Outline) for some users but is working perfectly fine for others. Modern browsers are being used and I can’t replicate the problem on any of my machines. Maybe it’s the Legacy Physics? So I wanted to create a simple test project that strips down all other variables and that uses the Legacy Physics Library just as I did on the current version of the app. But the lack of the option has thwarted me. 
Raycasting is a core method of the physics system. It should work legacy or not, on any device.
If you don’t get it working, try creating a simple example that reproduces this issue to take a look.
Yep. Just got confirmation that the problem is still there when using the new physics engine on a super-simple project. So right now it seems most likely that the problem is somehow related to the user’s machine/configuration/browser options. They don’t get a pointer change nor do they get any effect when clicking. So the raycasting is somehow not working in some particular situations.
I can’t replicate the problem myself but this is the simple project that fails for multiple users (fails on Chrome but works on FireFox, iPad, iPhone for the same key user).
https://playcanvas.com/project/644494/overview/ermis-outline-test
Indeed I am unable to reproduce myself.
Just to be sure it is the physics/raycasting the issue, can you direct them to try the following Playcanvas example?
https://launch.playcanvas.com/497357?debug=true
Clicking/tapping on the cube will cast a ray and position on the hitPos an object.
Edit: if that works and the new physics engine fails, most likely it is an issue with the fallback when the new WASM library is trying to run on a browser not supporting WASM (that would be a Playcanvas bug).
By the way @wturber if you are doing only picking, maybe using physics is too much of an overhead for no reason.
Check these two tutorials, they offer alternative ways to select an entity by picking:
The first is the fastest/more performant way but setting it up requires work. The second (Frame Buffer Picking) is a bit easier to setup and doesn’t involve physics.
Our app where the problem first showed up uses the Legacy Physics. I did that because of the IE 11 problem. We didn’t want failures to load. But I went ahead and sent the Outline Test project out using the new WASM library and slightly simpler code and it fails also. So old and new physics both fail.
Then maybe try the picking example I sent above, to check if it is something in the way you implement raycasting or indeed the physics system has a bug.
Also, in general, maybe it is a good idea to try one of the two alternative ways for picking.
OK. Will do. Seems odd that such a bug would go unnoticed for this long though. But it’s probably good for me to look into different raycasting techniques regardless.
Thanks.
Well, I’m surprised and scratching my head. The user says that the blue dots on the cube works just fine. I may just punt and try the the frame buffer picking since it makes no sense to me why one ray cast scheme is working and the other is not.
edit: Just realized that the blue dot app does not have collision on the orange square. So that appears to be the difference. It is collision, not ray casting per se that appears to be the problem.
The blue dot app uses shapes (pc.BoundingBox) to do the raycasting.
That is the fastest way to do it, but the most trickier to implement since you can’t define those shapes in the editor. You will have to create/size them in code, and also they support only boxes and spheres, so you are limited to those types of shapes.
Yep. I may be forced to take the bounding box or frame buffer approach. But I’m still confused as to why collision is failing. My nearly 10 year old laptop with an out of date Chrome browser and a Radeon 5000 series GPU has no problem with collision.
That said, at least it is good to know that Physics/Collision is almost surely at the root of the problem. I’m not sure what that says about using Physics/Collision in future projects though.
Physics run entirely on the CPU, but are not fully deterministic, that means there might be differences between browsers/operating systems/hardware.
If you are targeting performance the frame buffer approach is slow as well, since it has to render each frame twice to do picking. Your best bet will be to do bounding boxes with raycasting.
One thing I usually do is keep using the collision component, to set the size of the box, but without rigidbodies (and also with disabled Enable Physics in settings).
In a script I grab the dimensions of the collision component of each entity by accessing the halfExtents property:
Then I pass that size in the pc.BoundingBox constructor, alongside with the position of the entity:
If you have moving objects, you need to be careful to update the position of the shape when the entity moves. You can do that in the update(dt) method of the script like this:
MyScript.prototype.initialize = function() {
this.myShape = new pc.BoundingBox( this.entity.getPosition(), this.entity.collision.halfExtents);
};
// update code called every frame
MyScript.prototype.update = function(dt) {
this.myShape.center.copy(this.entity.getPosition());
};
Performance is not an issue. I am merely highlighting an array of displayed objects and activating a small panel that gives a description. It is super simple.
I get how physics is not fully deterministic and that objects can fall through objects etc. based on velocity and even mesh density if a mesh is used. We see those issues of approximation in regular 3D animation. But this case is a complete failure only on some specific machines using basic cubes and spheres - and it is failing completely, not partially. And on the same hardware Firefox works but Chrome fails. But that same Chrome works fine on my machine?!?! This seems to eliminate simple browser, OS , and hardware causes.
Oh well. Some questions just don’t get answered. Best to just go a different route.
Thanks for all of your help.
I’ve been using Ammo.js with Playcanvas for a long time and I can say it is pretty reliable. I didn’t have any issue with raycasting, not sure what is the cause of the behavior you report.
If you would like to dig deeper maybe trying posting a bug request with a sample project that reproduces the issue on the Ammo.js repository (make sure to include device models / OS version / browser version where it fails), since this is priority one bug for them, if indeed it is a failure on the physics engine.
Right. And that is what makes it hard for me to let go of this. But my hands are tied a bit since I don’t have direct access to the machine where it is failing. :^(