webworker collision

[jerome]

Hi,

 

I know he's modest and won't self promote here, but : http://blog.raananweber.com/2015/05/26/collisions-using-workers-for-babylonjs/

Very interesting article !

 

By the way, Raanan, did you investigate inline workers (instead of separate file) with blob technique ?

And what about shared workers for sharing data instead of indexDB approach (maybe shared workers aren't implemented yet everywhere) ?

 

 

More generally, something I don't get  so far about collisions because I didn't give a look until now :

 

In the WebGL hardware acceleration approach, we set the mesh local system coordinates and transformations (scale, rotation, translation) to be applied to them CPU side and we pass all this stuff to the GPU which computes in parallel all the matrix multiplications.

Right ?

 

Considering now the collision topic (I don't even speak about physics engine, just the cam collider), I wonder if :

1 - we need to compute CPU side the world positions of every mesh (at least some AABB bounding boxes) to compare them to the camera position

or

2 - we get back, after GPU computation, all the world positions from the GPU itself since I have no idea if this is possible and what the cost of back data passing compared to CPU local computation if many many vertices to set in the world

 

I guess the answer looks like the #1. Am I right ?

If yes, does it mean we set some bounding box for each mesh and then apply (CPU side, this time) the same matrix multiplications to the bounding boxes than the ones done meanwhile to the mesh vertices GPU side ?

[fenomas]

Hi Jerome,

 

I don't know BJS's specific implementation, but if you're asking about the general case, your 1 is basically right, but usually there is further CPU transformation done as well. To do a broadphase collision check all you need to know is each object's world location and AABB, so this can be done with few or no transformations. But comparing AABBs only tells you which objects might be colliding - to check their geometries (i.e. narrowphase collision detection) you need them in the same coordinate system, so you'd normally have to transform.

 

And yes, this is all on the CPU. Getting data back from the GPU is very costly, and I think many consumer GPUs don't support it.

[RaananW]

Hi Jerome,

I actually address all of your questions in part two which is still being written), but:

Inline worker is actually the way I implemented it. The worker is integrated in the single file of the framework. This is why there is also a no worker version. When the no worker version is used, there is an automatic fallback to the old implementation. There is also a way to use an external file for debugging purpose.

No, I don't use indexeddb. I eventually use transferables. I'll explain exactly why in part two.

The collision test is done on the CPU side and requires both the vertex data and the object's world transformation, which is the way it was implemented before. To achieve that I serialize the meshes and geometries when they are updated and send the data to the worker.

Again, everything is coming in part two :-) I'll update this thread when I finish writing.

[mfdesigner]

A more natural way of performing collision detection on GPU is by solid voxelization.  The problem is then reduced to detecting voxel overlap.

 

See:  "GPU-BASED REAL-TIME SOLID VOXELIZATION FOR VOLUME GRAPHICS: Theory and Practice: Volume Modeling and Volumetric Collision Detection".

[jerome]

fresh new : http://blog.raananweber.com/2015/05/30/web-worker-without-a-separate-file/

 

excellent, as the former one

[jerome]

PART 2 : http://blog.raananweber.com/2015/06/06/collisions-using-workers-for-babylonjs-part-2/

yeeaaahh 

[dbawel]

Hi Raanan,

Has anyone checked Web workers specifically by browser - with the exception of IE10? I can't imagine anyone still needing to use IE10 without huge legacy issues. The difference between IE10 and IE11 are too huge to even fully doc. However, if Web workers are reliable to use now compatability wise, this would be huge. I hope more people begin to thread these into cpu processes so that this might become the norm for making use of all of the under used processing power and memory on the new and standard hardware releasing these days. I don't have the experience with these, so I'm looking for more examples such as yours to prove these are reliable across multiple browsers. I look forward to more uses by you and others in the future.

Thanks.

[RaananW]

hey!

@Jerome, thanks a lot :-) Only finished this article yesterday night and never had the chance to write about it here.

 

@Dbawel - I believe workers are very reliable in all modern browsers. IE10 had a problem with inline workers, but the worker implementation there was not too bad as well.  I think a bigger problem with IE10 is the javascript engine which was relatively slower (relative to other browsers, not to IE9 :-) ) IE11 had improved it, but it still didn't catch up. IE11 is the only browser where the new collision system is not fluent on heavy scenes. But this is due to the Vector3.Dot calculation,and not the worker itself. 

 

The next thing I am moving to a worker is the simplification process, which is a classic worker task. We'll see what comes afterwards. I remember Jerome had some wonderful futuristic ideas :-)

[jerome]

[dbawel]

Please keep us posted- this shows real promise towards optimizing and balancing cpu load and

usage.