Collision checks

[groe]

Is there any best practice for checking against object collisions with KickJS? Picking points with many well-placed cameras and using the calculated distance (pickObject.distance) in the next frame is a a huge workaround I guess. So one could use the underlying models (Mesh, MeshData, etc.) to set up mathematical equations and solve them, right?

While this may not be related to graphics and WebGL in a direct way, I would still consider collision checks a major component of most games being developed. Support or assistence (as in API functions) from KickJS, as a game engine, would be really neat.

[mortennobel]

I agree that a collision detection is an important piece of a game engine. The pick-functionality is not really a general approach to collision detection (on the other hand, the performance of the pick functionality is very good, since collision detection is done on the GPU).

The plan is to integrate some physics engine into KickJS someday (such as BulletJS), however I do not have time to look into the issue in near future.

[groe]

Great to hear that physics will be part of KickJS one day.

What's your opinion on cannon.js? It has a more simple API and was built in JS entirely (no port), but lacks some advanced features (that Bullet-ports as BulletJS or ammo.js would provide). I have already built a demo that uses cannon.js and KickJS and it works perfectly.

Right now this integration consists of

1. some boilerplate code to initialize the physics engine with gravity, solver parameters, etc.
2. declaration of physics objects with x/y/z-coordinates (copied over from gameObject.transform.position) and rotation (copied over from gameObject.transform.rotation)
3. a physics GameObject with a Physics component that steps the physics engine and updates gameObjects with their new position calculated by the physics engine each frame

If your plan is to completely embed the physics engine into KickJS (i.e. hiding its API from the user), (1) would be in the responsibility of Engine or Scene, (2) in GameObject and (3) somewhere we can execute it immediately before all update-functions of components I guess.

However, considering updates of cannon.js (it's still in an early stage of development) and the effort to embed it again and again, a better choice may be to leave it loosely-coupled, simplify only some things (e.g. make kick.math.Vec3/Vec4 and CANNON.Vec3/Quaternion compatible) and provide some example code on how to use these great libraries together.

Let me know what you think about that.

[mortennobel]

First of all, I haven't really looked into physics engines in JS, so I can't really say much of which to use.

I think the physics step should run before the component update calls (at least that the 'common' way physics libraries are used).

With regards to integrating an engine into KickJS, I think you have the right idea. It is probably a good idea to keep the two projects loosely-coupled to some extend. This way I don't hide any features and will give the programmers more freedom. But in the end it depend on which physics library I choose.

I'm curious to see your demo of cannon.js and KickJS. Any change you would like to share the code with me?

[groe]

I'm not yet sure about releasing the source of the project I am currently working on (it's coffee script btw). However, I could set up a quick demo showing the integration of KickJS with cannon.js if you want.

[groe]

I have added the steps to use KickJS with cannon.js here: https://github.com/schteppe/cannon.js/tree/dev/examples