Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Ammo tests #5322

Draft
wants to merge 45 commits into
base: main
Choose a base branch
from
Draft

Ammo tests #5322

wants to merge 45 commits into from

Conversation

MushAsterion
Copy link
Collaborator

Implements tests for Ammo.js

Moved from #5106, use IDL from playcanvas/ammo.js, put as draft waiting for current IDL used by editor or update to latest kripken/ammo.js.

I confirm I have read the contributing guidelines and signed the Contributor License Agreement.

MushAsterion and others added 27 commits February 27, 2023 13:40
Co-authored-by: Martin Valigursky <[email protected]>
@MushAsterion MushAsterion marked this pull request as draft May 12, 2023 09:47
@GSterbrant GSterbrant added the open source contribution Issues related to contributions from people outside the PlayCanvas team label May 12, 2023
@willeastcott
Copy link
Contributor

I wanted to check in on this PR - it's been open for a while! Can I ask where test\ammo.mjs came from? Did you make that yourself by hand? Also, is there any reason not to run tests using the 'real' ammo.js? I'm concerned a stubbed ammo will get out of sync with the actual version of ammo we take from kripken's repo.

@MushAsterion
Copy link
Collaborator Author

I made it myself yes. The initial idea was to replace only few functions however if you declare it once it fires from everywhere so I had to add all functions, which is also a good indicator of which are supported and which are not, especially since the version of Ammo being used is not up to date with kripken's repo (or wasn't last time I checked)

I also have absolutely no background knowledge or skills about tests and it was suggested by @LeXXik in #5106 to do so, and because they seem more aware than me in the matter I went ahead and made that. Honestly I wouldn't mind using Ammo directly either however since it requires the version to be synced it would be a risk as well and mislead users if a contributor add something working only with the latest Ammo version while this version is not the available one in projects from the editor.

@LeXXik
Copy link
Contributor

LeXXik commented Oct 31, 2023

The stubs allow to verify that the engine is calling the correct Ammo methods, correct amount of times and passing correct value types. It is not possible to verify those using an actual Ammo library.

Copy link

vercel bot commented May 14, 2024

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name Status Preview Comments Updated (UTC)
engine ✅ Ready (Inspect) Visit Preview 💬 Add feedback May 14, 2024 2:45pm

@LeXXik
Copy link
Contributor

LeXXik commented Jul 14, 2024

@willeastcott what is the status of this ticket? I want to write some features to collision component, but still can't write tests.

@willeastcott
Copy link
Contributor

I gotta say, I'm still really struggling to see the justification for merging this. Should we be writing stubs for Draco, Basis and whatever other WASM libraries we add in the future? If we merge this, we're essentially committing to maintaining it.

I'm going to summon @slimbuck and @mvaligursky because I really feel like I need other opinions here.

@LeXXik
Copy link
Contributor

LeXXik commented Jul 18, 2024

Draco, Basis and whatever other WASM libraries we add in the future?

Yep, we should. Although, I don't think we need to stub everything. Only the methods that the engine is calling should be enough.

@mvaligursky
Copy link
Contributor

Should we use the wasm libraries themselves instead of stubs?

@LeXXik
Copy link
Contributor

LeXXik commented Jul 18, 2024

The goal of the test is to verify that the engine is calling the correct Ammo methods, correct amount of times and at the right time. It is not possible to verify it with original library (it won't tell us). Stubs serve that purpose - we don't care about Ammo internal functionality during a test, but we (should) care we call proper methods.

Comment on lines +232 to +239
_constructor: (x, y, z, w) => {
if (x !== undefined) {
assertNum(x);
assertNum(y);
assertNum(z);
assertNum(w);
}
},
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I know we do call new Ammo.btQuaternion() without arguments, but technically this is just wrong if you take a look at the actual WebIDL:

https://github.com/kripken/ammo.js/blob/1ed8b58c7058a5f697f2642ceef8ee20fdd55e10/ammo.idl#L62-L64

So in a way if there are actual errors, this won't find it, because you just assume that as things are right now is the definition of "correct", even though there may be bugs?

Sorry for stupid question, but I just still don't understand what this really does or how this helps to find bugs in Ammo?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This doesn't suppose to find bugs in Ammo. Ammo handles its own tests, we don't care about it. This can catch bugs, like the one we had recently, where we were adding a body to dynamics world twice, or an earlier one, where we were destroying the same body twice, etc. This allows to make sure the engine calls correct Ammo methods, correct amount of times and in correct order. What happens inside Ammo is of no importance, thus we stub those.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

About quaternion - we should init those with zeros, as per API. If we don't, those are initialized with garbage, so unless we immediately set values for all components right after, it can introduce hard to debug bugs.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area: physics Physics related issue open source contribution Issues related to contributions from people outside the PlayCanvas team
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants