We need a new collision system

[RaananW]

My two cents - https://github.com/BabylonJSX/WebWorker-Collisions / http://raananweber.com/webworkerCollision/?scene=gravity

I'm currently away, I'll write a bit more about it a when I'm back home :-)

[jerome]

@Raanan : at last, your X repo  !!!

 

Threaded collision detection  : just huge 

[jerome]

@Raanan : any benchmark with vs w/o webworker ?

 

I'm wondering about the required initialiazation time and about the  float/string/float (and vice-versa) parsing time for the messages ...

 

I'm wondering if would be worth for improving computeNormals()  and others mesh update CreateXXX() methods doing many sequential (but not matricial) computations. 

[joshcamas]

How interesting, and super cool!!!!

I'm going to need to look much deeper. Amazing code!

 

Also, webworkers opens up huge possibilities. AI, Shadows, etc. So cool!

 

Oh, and Wingnut - I don't understand how scaleWithCollision could be a thing. How would that work? As it scales, it gets pushed by stuff near it?

 

One possibility could be to have a function updateDynamicCollisions(). This would replace scaleWith, moveWith, and RotateWith. (although they could be used)... basically it would keep a record of the old location, and compare it to the new one, and do collisions from there.

 

Then updateStaticCollisions would be for updating the position for moving walls, maybe?

[Wingnut]

Great advancing, guys!

 

Josh, the mesh that is being scaled, can push things.  Naturally, no collision would happen if the mesh.ellipsoid isn't being scaled similarly.  But in many cases, the collision ellipse WILL be scaled when the mesh is scaled... to check for scaling collisions.

 

Let's say you built a scene editor where mesh was NEVER ALLOWED to overlap.  If the user mousedrag-scaled a mesh in a way that pushes it against another collision-active mesh, you would want to either STOP the scaling at that point, or change the position of the scaled mesh so that it had plenty of room to do the scaling... without mesh overlap.  The mesh would re-position in some direction... as the collided scaling happens, working to stay out-of intersect condition.

 

Another example is "fat man" game.  Lypo boxes climb onto the small platform (a ground) where fat man (a cylinder) is standing alone (in a king-of-the-hill way).  The lypo boxes keep chewing fat from the fat man, making him reduce scale X/Z... which allows more room for more lypo boxes to climb onto the platform and chew fat.  But fat man can eat lypo boxes, and the more he eats, the fatter he gets.  As he gets fatter, he pushes lypo boxes off the edge of the ground (scale with collision). 

 

The lypo boxes could have code on them (possibly ActionManagers)... that causes them to positionally back-away from intersects.  They try to get themselves out-of intersect condition.  In doing this, they can back-off the edge of the ground.  They got "scaled" off the platform... by fat man's xz scaling belly fat. 

 

A bit off-topic, but... MAYBE Sam Girardin has done some "intelligent mesh" in his character study demos.  (Thanks for making them available for download, SG!  Cool!)  Sam has implemented a BJS version of the University of North Carolina RVO which includes collision avoidance abilities.  It sounds like a way for our poor lypo boxes to avoid being squished into fat man's belly rolls.

 

"Run, boys!  Avoid the blubber!!!  It will swallow you!!!" 

 

And yes, Fenomas... we're right AT 60% of physics engine.  hehe.  Ain't it fun?  Actually, we're only messing-with imposters and intersects.  No velocities, masses, or restitutions (bounce).  We're still quite a ways from the bog of a physics engine... but we'll get there. 

 

What if...  bjsnode.alive = true ... means the object has an IRQ (interrupt request).  (ok, thats SO c-64 old-sounding).    It has a motor (on a WebWorker thread?). That motor can run an on-mesh scheduler, and one of its scheduled tasks... CAN be to check for collisions on itself, and fire its own collision events. 

 

Oh wait... that's what ActionManagers do?  Ok, nevermind. 

[Wingnut]

Btw, RaananW, the camera speeds are too fast for me to properly test your demos.  Is that due to my computer beng so slow?  I suppose, eh? 

 

If you ever do new versions of your test cases, could you please include... maybe a 5-checkbox camera speed control in the "Options" panel?  Thanks.  Feel free to do a camera.inertia on/off option, too.    Pretty cool panel, btw.

[jerome]

@Raanan : for sending/receiving messages to/from your worker, did you jsonify everything or did you just use structured clone data ?

 

[EDIT] : Well, just tested structured cloned data in my network weathermap application (metrology data are got in another thread sending xhr requests), it just works like a charm

I will probably shift many logical computations in this thread also and keep the main thread to focus on bjs 3D rendering (almost) only.

[RaananW]

So!

I'm back home :-)

 

To your questions - 

@Jerome - Regarding benchmarks - none exist. But since the algorithm is the same, I doubt there is any difference in performance. I have noticed no difference in performance. The idea is not to improve performance. The idea is to allow the main (view) thread to render the scene in 60 fps without letting the collision detection disturb it. So, even if heavy collision calculation are performed, animations and moving objects will still render in high fps.

 

@ Wingy - Not sure what you mean, this is a regular scene with fallback in case web workers or idb is not supported. You mean that the camera moves too fast? Should happen actually, would love to know why :-)

 

@Jerome - I am not moving any objects except for the actions. something like RPC. The data is persisted in an IndexedDB (another repo of BabylonX - https://github.com/BabylonJSX/IndexedDB-Backend , but I will introduce it later). So, so serialization is taking place. I will be testing (tomorrow, probably) if there are better ways to transfer objects between both threads and will update the repo when it will be ready.

 

The feature will hopefully be ready soon - this or next week.

[jerome]

Welcome back 

I implemented a worker in my weathermap program to deal with background xhr request, parse got JSON data and transfer to the main thread via structures cloned data (instead of re-serializing them in JSON) : works like a charm.

As you, it's just to guarantee that the rendering will keep constant fps and won't be disturbed by xhr requests/results parsing.

[Wingnut]

Welcome home, RaananW!  My camera speed issue happens on every BJS scene, so there is nothing particularly wrong with yours.  With freecameras...  I can be what feels like 3 meters away from a collision.  One up-cursor tap, and I'm nose-to-the-mesh in collision condition.  Same with the mousewheel in arcRotateCam.  3-meters away, one tiny roll of the mousewheel, I'm collided.

 

Because of this, I prefer collision demos that collide mesh into mesh with keypesses or drags, and not camera-to-mesh collision testbeds.  I haven't studied debug mode, but it would be nice if camera speed and inertia adjustments were on ALL options panels, if possible. 

 

AND... I think... free cameras should raise/lower (pedestal up/down) with shift-up/down cursor, but we'll save that for a later day and another post.

 

Again, this camera speed problem is with all scenes.  It is not unique to your test scenes.  BUT... collision testing scenes sometimes need tiny movements for accurate testing.  If you look at any of my SH experiments, you'll see that I always use ARC, and I always have the .wheelPrecision cranked-up. This is so I can gently zoom-in on the SH mesh and do examinations up-close (cuz they look cool up-close).  For others who view my SH demos, they probably think their mousewheel doesn't work at all, because it's so slow. 

 

My buddy Bob in Kentucky ALWAYS complains when I show him my demos.  "Got your camera-nav speeds slow enough?"  (sarcasm). 

 

Another example.... Flat2009 demo.  Unusable for me.  Too much camera speed.  One cursoring, and I'm on the other side of the room, pressed against the wall.  My computer is a $500 off-the-shelf Walmart Dell (about 7 years old).  Do we really want to have Flat2009 be unusable for the HUGE amount of people who buy $500 Dell computers from Walmart?  Probably not. 

 

I've tried adjusting SYSTEM mouse/cursor speeds for my computer... no change in BJS scenes.  Settings were factory-set at 1 sec delay before repeat starts... and currently remain that way.  But, maybe the problem is with my slow single-core 2.2 Ghz computer.  Maybe CPU speed affects mouse speeds because mouse speeds are related to frame rates.  Someday I should study WHY this happens. 

 

Back on the webworkers topic:  If I understand webworker threads, they are often assigned to separate MPU cores.... which does nothing for single core computers. 

 

So, will authors have a tendency to use webworkers and think their scene is running at tolerable speeds, when actually, they are making a scene that is unusably slow for single-core computers?  Do we care that authors might not realize that they are ignoring a large user-base?  *shrug*  Maybe LOD will compensate for that.

 

I need to study webworkers more, but, maybe someone needs to remain a "champion of the single core" so that authors don't start making scenes that are too cpu/gpu-heavy for single core folk.  Will we need to have two versions of popular BJS games... one for multi-core, and another stripped-down version for single-core folk?  Fallbacks won't solve anything IF the game is too slow to be playable.... without using webworkers.

 

Or maybe, blaze ahead, don't look back, take no prisoners.  If you can't get your CPU to take-on the swamp trail, then stay on dry ground and cope. 

 

Just thinkin'. 

[reddozen]

Even my phone is a quad core now, so I would find it a little unlikly that in the near future anyone will really be using a single core processor. I would think that the best route would just be to make the web-workers default, but that a flag can be set to disable them by the developer. Then it's a easy switch in a game options menu.

 

"Single core user? Uncheck this box to play"

 

I know from my own experiences so far that my game would be unplayable without the web-workers because my frame rates with collision checks was diving into single digits. My scene does good to run at 30 FPS as it is, and I'll be satisfied with 45 FPS when it's "optimized".

[GameMonetize]

The goal is clearly to default to webworkers if the browser supports them.

 

I was jsut waiting for Raanam to send me a PR

 

@Raanam: did you test integrating it into bjs? (I mainly think about supporting the minified version)

[Wingnut]

 

I would find it a little unlikly that in the near future anyone will really be using a single core processor.

 

  Are you including "third world" countries? 

[reddozen]

  Are you including "third world" countries? 

 

No, but that is a good point. I didn't consider it.

[RaananW]

@wingnut, single core processors have threads as well :-) if your browser supports it, everything's fine.

@dk - I wanted to first check transferable objects and see if it's better than idb. Will work on that soon. Probably later today and tomorrow. The fact that GoT episodes are available won't help :-)

BTW, since workers require an extra js file I won't be able to integrate it to the main js file. Not without big changes to the entire architecture.

[GameMonetize]

 

 

BTW, since workers require an extra js file I won't be able to integrate it to the main js file. Not without big changes to the entire architecture. 

This is why I mentioned it, we still need to stick with only one file. Else the default behaviour will be without your great work and this is a shame

[RaananW]

Ok, - first:

transferable objects vs. idb - Just commited a version that also supports transferables.

Firefox (37) works better with IDB (36 and under don't support the feature), both chrome and IE are a bit quicker with transferables (not very noticeable until you get to a highly-updated scene like the v8). As the IDB dependency has to be added as well, it might be an "extra" option for developers who need that and per default transferables will be used.

For those who want to test as well - 

transferable - http://raananweber.com/webworkerCollision/transferable/ or V8 version  http://raananweber.com/webworkerCollision/transferable/?scene=complex

IDB - http://raananweber.com/webworkerCollision/ or V8 version  http://raananweber.com/webworkerCollision/?scene=complex

 

@DK - Next thing to solve would be integrating it into the framework. I have some ideas how to do it correctly, I need to check what would work the best (as I am also referencing the bjs file from the worker itself for the internal functions). Will update here when I have descent results.

[Vousk-prod.]

Love these buttons!

 

I'll add them directly on PG:)

 

Love these buttons too !!

I often test stuff on mobile phone, those two are just soooOOO usefull! Thanks josh!!!

Nice to have putting them by default on the PG DK!

[joshcamas]

Hey raanan! I found this linky for you:

http://stackoverflow.com/questions/5408406/web-workers-without-a-separate-javascript-file

[joshcamas]

Ok guys. Sorry, I've been super sick and haven't been up to working on this. onwards!!

 

Here's the current playground:

http://www.babylonjs-playground.com/#1REST6#15

 

So. I guess It's time to build, eh? I'm still not sure exactly how to do the mathematics part... sadly I ain't good with that type of stuff. 

So there are two ways of doing it, at least here are two possibilities:

 

1) Have many different types of impostors.

2) Have only box, ellipse and complex.

 

In other words, should I make it easy to add your own impostors or not? There are only so many shapes you can make...

 

Also, I think if we want to make the impostors visible we should just attach a mesh. Yes?