-
Notifications
You must be signed in to change notification settings - Fork 21
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
What Do We Need To Autogenerate Javascript Bindings? #25
Comments
Help on this would be amazing! The macro at: haxebullet/Sources/bullet/Bt.hx Line 7 in a5a8649
is also supposed to work for JS.
Still a novice on this myself but was amazed how it worked so far. We can basically drop-in any C/C++ lib just by writing the |
OK awesome. If I get the time, I'll look into it. 👍 |
I just got a custom Emscripten build of bullet using the Haxe Webidl library. It looks like it works! I've already been able to get a Haxe extern file from it so that we should be able to cache the externs and avoid generating them every build. Using the WebIDL gives exactly the same bindings for JS and HL which is awesome and takes out all of the Now I'm going to try to integrate the binder into Khamake/Koremake so that you can use it for any Kha project just by adding a WebIDL file and some statements to your Khamake.js file. 🎉 This is going to be so awesome if it works. |
😍😍😍 |
I've now got Khamake building the bindings for you automatically. The next step is getting Kha to load the compiled JavaScript for the Krom and web platforms so that you don't have to manually include and eval ammo.js or anything like that. Things are going really well so far so hopefully I will be able to finish this pretty soon. The way that it is setup is that you just have a library ( for example To use it, all you have to do is add the library to your Kha project like you normally would by adding a I've still got some cleanup and slight reorganization to do, but it is going really well so far. Also, for reference, here is what my {
"idlFile": "bullet.idl",
"nativeLib": "bullet",
"sourcesDir": "bullet",
"chopPrefix": "bt",
"hxPackageName": "bullet",
"hxModuleName": "Bt",
"autoGC": false,
"includes": [
"<btBulletDynamicsCommon.h>",
"<BulletSoftBody/btSoftBody.h>",
"<BulletSoftBody/btSoftBodyRigidBodyCollisionConfiguration.h>",
"<BulletSoftBody/btDefaultSoftBodySolver.h>",
"<BulletSoftBody/btSoftBodyHelpers.h>",
"<BulletSoftBody/btSoftRigidDynamicsWorld.h>",
"<BulletCollision/CollisionShapes/btHeightfieldTerrainShape.h>",
"<BulletCollision/CollisionDispatch/btGhostObject.h>",
"<BulletDynamics/Character/btKinematicCharacterController.h>",
"<BulletCollision/Gimpact/btGImpactShape.h>",
"<BulletCollision/Gimpact/btGImpactCollisionAlgorithm.h>"
]
} |
It works!!! Last night I got an end to end build that successfully utilized the entire workflow! I've still got a little bit of cleanup and slight re-organization, but I should be done today or tomorrow! I'll have PRs for Kha, Khamake, haxebullet, and Armory. |
Sounds awesome, can't wait! |
I ran into some issues, but I'm getting close to finishing. I have gotten most of it working, but then ran into an issue when enabling MODULARIZE for the Emscripten build. I'm also not 100% sure I've figured out how to make sure that JS libs are loaded before the game starts. Right now I'm working on figuring out if there is an alternative to using |
@luboslenco and @RobDangerous I've opened the following PRs for the automatic WebIDL binding system for Kha projects and for Armory's Bullet bindings:
There is kind of a lot changes throughout those repos so tell me if I missed anything. I can give more description of how it works later, but I figured I'd submit these for review. It is looking really cool. I'm so excited about this update! 😃 🎊 |
I created a Gist that documents how to use the new "Khabind" feature: Khabind: Binding C++ Libraries To Kha For JS/HashLink. |
Review NoteEmscripten Bytecode in Haxebullet RepoI included the bytecode generated by Emscripten in the PR for Haxebullet because the way that I setup the compiler cache in Khamake was that it will compile any C/C++ source file that doesn't have a corresponding bytecode file with a newer timestamp. Technically I could add some more logic to the compiler cache so that it would not compile any sources if there is already the generated JavaScript library that has a newer timestamp than all of the source files. It would just add slightly more complication to the build logic so if you don't think it is a problem I will just leave it, otherwise I have no problem making it a little smarter. Error with heap memoryI'm getting an error every once in a while when a physics world runs for too long:
It helped when I increased the TOTAL_MEMORY to the size that the Ammo.js project uses, but it still happens, just less often. It looks like you can set the heap memory to be growable without performance consequences for WASM, but I haven't gotten Emscripten WASM builds to work in Krom ( I don't know why, it just crashes ). It would be best if we could figure out how to run the WASM build in Krom. |
Thanks, this is big! Will have fun this weekend. 🙂 (+ doing a proper haxerecast upgrade is also easier now!) |
Awesome. I can't wait to get some feedback on my code! :) Also, I did manage to figure out what was causing it to run out of memory. The WebIDL binder that comes with Emscripten that is used to create Ammo.js does some sort of wrapping for the C++ pointers that can garbage collect them automatically ( for classes that don't require a destructor ). The bindings that we are generating with our WebIDL binder, though, doesn't do any garbage collecting for you. This left a memory leak in It looks like ncannasse/webidl does have the auto garbage collector option that should work for HashLink, which is good. It is up to you whether or not we want to use it for Bullet in Armory, but I'm also going to do my best to figure out if I can use the trick that the Emscripten WebIDL binder used to get JavaScript to garbage collect it like Ammo.js did. |
Linking: ncannasse/webidl#15. |
Getting more familiar with it! Is it a bad idea to have |
The reason I had it in its own file was because I didn't see a reason to mess too much with how Khamake processes the files when all I needed was some static parameters for the library. |
"sub-projects" are merely more powerful libraries and I think I can persuade Lubos to add a khafile to haxebullet. |
In that case it should be perfectly fine. It would probably be good to make the handling less 'special' so to speak. |
@RobDangerous Does it make any sense to have Khamake automatically add a project if you are adding a library with a |
No, the big difference is that loading a project is async because khafiles require that. |
Just pushed updates to all of the repos to use |
It looks like there actually isn't a way to get JavaScript to auto GC the references. 🙁 ( see emscripten-core/emscripten#8206 (comment) ) I don't know why we didn't see the out of memory exceptions with the Ammo.js version that we used to use, though. 🤔 I'm not sure if it had the heap set to growable or if it was something else, but either way it looks like we will just have to fix the memory leaks. I fixed the major ones, but there is still at least another minor one, because I had it running for an extended time period earlier and it ran out of memory again. |
Growable heap should be disabled in current ammo.js build, so I guess the current one should also crash eventually? How long is extended time period? 🕐 Do all physics enabled scenes run into this? Will try to reproduce. |
At first it would crash within a few minutes before I pushed, armory3d/armory@d43d9c4. After that the only time I've noticed a crash was with a basic rigid body sim that I had accidentally let run for a couple hours or so. Still if the Ammo.js build doesn't have a growable heap, then I can't immagine what is making it not crash if there is no way to auto GC memory. Maybe we should test reverting armory3d/armory@d43d9c4 to make the effect more apparent and then compare Ammo.js and our custom build. Maybe my Khabind script isn't correctly setting the heap size or something like that. This is kind of strange. 🤔 ❓ |
Here is an example that crashes really quick. It lasts less than a minute. ( 400+ spheres ) |
Oh, I found the leak: var p = trans.getOrigin();
var q = trans.getRotation();
var qw:bullet.Bt.QuadWord = q; Just needed to delete those after use. Now the example continues working for an unknown amount of time. I'm going to try testing it with Ammo.js and see if I have the same problem ( without the leak fix ). Edit: I tested the same example with Armory's current Ammo.js and it works without any attempts to fix the leaks that show up for the Khabind build. There has to be some sort of difference between them, I just don't know what it is. For one reason or another Ammo.js doesn't run out of heap memory. 🤔 💭 |
OK, I was finally able to get back to this. 🙂 Good news is, I think it is done! At least the binding part anyway. So I never figured out how Ammo.js magically avoids memory leaks, but it doesn't matter, because the memory leaks are not unique to the JavaScript build, they happen with the HashLink target as well. This means that we have to fix the memory leaks by adding the proper I went through and I found the last memory leak that occurs when doing a pure rigid body simulation ( without cloth, soft bodies, or constraints ). The simulation can run with hundreds of objects without steadily increasing in memory usage, now. There might be some more in the cloth, soft body, or constraint code still. Remaining IssuesI notice that some of the physics behave a bit differently than Ammo.js did with the new bindings. The behavior of Convex Hull shaped objects is sporadic and it seems like the mesh collision shape has some issues when I try to set the floor to use it ( it freezes in Krom and things go through it in HashLink ). I don't really have any experience with the Bullet API so I don't know that I will be able to fix that right now. The good thing about it, though, is that the JavaScript build now behaves the same as the HashLink build, so any issues that we have in Krom are probably just things that we hadn't noticed were already an issue in HashLink builds. @lubos If you could test it out that would be great. I've got a simple blend with some test objects where you can see the convex hull shape issue, and if you set the floor to use a mesh collision shape you can see the mesh shape issue as well. |
Update
Radeon Error:
|
Nope, sorry, I've seen several reports about critical issues in rc2, won't update before rc3. |
See Kode/Kha#986, hoping to revisit in the future. Thanks! |
I was looking around because I needed some extra bindings that I found were not in Bt.hx but were in the WebIDL and I found that the Javascript bindings were not generated automatically yet.
haxebullet/Sources/bullet/Bt.hx
Line 11 in a5a8649
If it is worth your time to explain, I might be able to do the work to get that done. Before I started on anything I just wanted to make sure you haven't already figured out what we need to do. If it isn't worth the time right now, no problem, I don't care either way, I'll just add the extra bindings that I need to Bt.hx for now.
The text was updated successfully, but these errors were encountered: