lo-th / Oimo.js

Lightweight 3d physics engine for javascript
http://lo-th.github.io/Oimo.js
MIT License
3.07k stars 303 forks source link

Future Plans? #21

Open QuaziKb opened 9 years ago

QuaziKb commented 9 years ago

First off, i have to say after looking around on the web, oimo.js looks like the fastest .js physics engine out there right now. Obviously this speed is a result of it being lightweight, but it is lacking some important features which would be nice to have. I'm hunting around for physics engines to use in my project, and oimo is really my number one pick right now, but i'm a bit discouraged by its lack of support for collisions against triangle meshes / terrain / convex shapes / basic shapes (terrain being the most important) having support for cones / ramp wedges / pyramids, and other basic geometries would also be awesome. Ammo.js and cannon.js are the only real alternatives out there, and they perform very poorly imo compared to oimo.js, nonetheless they have support for triangle meshes / other shapes. In any case I'm considering using oimo.js anyways and possibly extending it to have these features. It's just too good to ignore.

Really it'd be nice to know this project is still alive, but i really just want to know whats in store (or not) for the future, so I (and probably many others in my position) can plan accordingly.

lo-th commented 9 years ago

Yes Oimo is the fastest :) But i have no news from original author Saharan. Complex shape is possible, but i have many projects. Sure i want add triangle, particle, terrain, prevent tunneling... But is big and long work ( if someone want help call me )

for more complex simulation you can use bullet is a strong engine. https://github.com/lo-th/Ammo.lab

QuaziKb commented 9 years ago

that's too bad, it was really shaping up nicely, hope the original author is okay!

I wasn't suggesting you had to do it, was possibly going to try myself. Bullet is quite good too it seems, but i'm not a huge fan of emscripten ports, since they usually involve a lot of bad .js unfriendly memory structures and stuff. with that said, your lab test sells it as pretty good so i'll probably choose ammo for now, and make my project open to using oimo in the future.

lo-th commented 9 years ago

yes emscripten port of bullet is ugly big but have many possibility like car , triangle mesh, terrain ... i hope Kripen update soon better version.

Oimo is strict and clear javascript, original author start by using the structure and physical rule of bullet or box2d. So can we go from one to another.

ghost commented 9 years ago

hi, I was wondering if there are also any plans for a typescript definition for Oimo. Thanks!

lo-th commented 9 years ago

hum no i don't think typed script can improve performance. and after long work with action script I find it painful.

ghost commented 9 years ago

no problem, thank you very much for your reply!

lo-th commented 9 years ago

some news from saharan :) Still development I will continue! Cylinder and triangular mesh of support, because there full of wanted to implement, such as continuous collision detection (CCD) function.. soon

QuaziKb commented 9 years ago

hmm, would you want my fork of oimo to work on? i've already added cylinder support (modified from dev and copied into rev to match the new manifold system) and fixed various little bugs.

lo-th commented 9 years ago

yes sure you can add, i think add more simple property with get set

On Thu, Mar 12, 2015 at 12:28 AM, QuaziKb notifications@github.com wrote:

hmm, would you want my fork of oimo to work on? i've already added cylinder support and fixed various bugs.

— Reply to this email directly or view it on GitHub https://github.com/lo-th/Oimo.js/issues/21#issuecomment-78395228.

LoTh - Freelance javascript / as3 / 3D website http://perso.numericable.fr/chamaslot/ | blog http://3dflashlo.wordpress.com

gillesboisson commented 7 years ago

Hi, I know this post is quite old. But does Oimo support mesh / triangle collision detection ? I didn 't find it on shape classes. otherwise, it looks good and very fast

ghost commented 7 years ago

@gillesboisson I don't think there was anything for triangle meshes done, there are no shape classes that reflect it. I did however, have an implementation ready somewhere that I quickly patched together, but it's kinda (super) broken for the moment. Maybe later, when I have time, I'll be able to fix and upload it in my fork.

gillesboisson commented 7 years ago

I would be happy to give a hand, but I don’t have much experience with physics and collision detection.

@gillesboisson https://github.com/gillesboisson I don't think there was anything for triangle meshes done, there are no shape classes that reflect it. I did however, have an implementation ready somewhere that I quickly patched together, but it's kinda (super) broken for the moment. Maybe later, when I have time, I'll be able to fix and upload it in my fork.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/lo-th/Oimo.js/issues/21#issuecomment-321986934, or mute the thread https://github.com/notifications/unsubscribe-auth/AKymjhqSBQvWhfVD9V7d33noB7c_Bv1-ks5sXb-egaJpZM4DTlFD .

ghost commented 7 years ago

Ok, I uploaded the (original) relevant files on GitHub Gist here. There's a fair amount of code, but most of it is the mass info calculations, which were translated from some C code I found online and should be correct. I'm more worried about the collision detection implementation (see SpherePolyCollisionDetector.js). If I remember correctly though, there was also an issue with the broadphase detection, as the AABB for the polyehdron wasn't accurate and was consequently not triggering the narrowphase (see Polyhedron.js, the updateProxy() method).

I'll probably do some more testing later, just to check my assumptions. For now, feel free to take a look.

ubernaut commented 7 years ago

@lo-th So I was looking through the build and I see that it uses float32Array() about 8 times. I'm working on a space sim on an intergalactic scale where doubles are highly desirable. (With doubles I can get at least to the edge of the solar system before running into precision issues).

Would you be interested in accepting a PR that added optional double support instead of just 32 bit? I was thinking it could be an argument to the world init function.

what do you think?