Best way to collapse a wall with lots of bricks

[PhilT]

Hi all,

I'm trying to figure out the best way to collapse a wall 20x20 boxes all 1x1x1. The boxes are just stacked on top of each other so when applying either cannon or Oimo the wall eventually falls down but I'm only getting around 40fps with Oimo and even less with Cannon.

I'm using instances, no textures. I've looked into SPS but doesn't seem like it'll help here.

Is there anything I can do to speed this up? It looks like it's just the massive computations needed to process all the collisions.

This needs to scale as well. I plan to add a lot more to the scene.

At this point I'm thinking to implement my own engine with drastically simplified physics (for example no rotations).

I'll post a PG later if that's useful. Just wanted to get this out there before I have to shoot off.

 

[PhilT]

Some other ideas: Using web workers - Could I off load the physics calculations to a web worker? It seems possible with the built in collision system but what about with Cannon or Oimo?

Gonna look at built collisions for now.

[Guest]

PG are always welcome

my first question would be: how does it run WITHOUT physics?

[JohnK]

Don't say it is the best way but here is one using Ammo (not a bjs plugin) https://suspicious-ride-8d7b61.netlify.com/dropped boxes/boxes1

Code https://github.com/BabylonJSGuide/Physics/blob/master/dropped boxes/boxes1.html

From 

 

[PhilT]

Hey @Deltakosh, if you mean not even moving and just displaying the boxes then I get 60fps in the PG. With 50x50 things start to drop a bit. http://playground.babylonjs.com/#VSIGKU

That looks interesting @JohnK thanks. I'll give a try with the wall. Like your doc site. I might have to go through that. Great alternative/complementary site.

I tried with `moveWithCollisions` but that's pretty slow as well. Presumably because it's more meant for moving a single object around like a 3rd person perspective.

All good fun experimenting though  Thanks for the suggestions.

 

[PhilT]

Initial tests seem to indicate Ammo is on par with the others. Perhaps a little quicker but I need to integrate it with my code for a proper apples to apples comparison. What is interesting is that it seems quite tweakable although that could just be because it's not a plugin.

[PhilT]

Still not exactly the same set piece but I think it's close enough.

 

Interestingly Ammo.js doesn't drop fps so much as Oimo does when the boxes hit the ground. Oimo drops to around 11 fps whereas Ammo maintains around 22 fps.

Using instances didn't seem to make much difference.

Not processing rotations made no difference either.

These were both done with a 30x30 wall of 900 cubes.

Still trying to understand Ammo API. I'm hoping to post both demos up on my blog on Sunday. We'll see how that goes!

 

[Wingnut]

Hi gang.  This is a cool subject... and a good conversation.  Thx for the demos and perf reports, PhilT/others.  Good info.

Um... what is the reason WHY BJS uses a 24-vert box, and not an 8-vert?  I forget.  Was that because of MeshBuilder?  Other reasons, too?  Flat shaded by default?

Actually, I don't really care why... but I'm wondering if PhilT could use 8-vert boxoids.

https://www.babylonjs-playground.com/#22RW7I#1

Oh wait, that's the wrong PG.  Try this one:

https://www.babylonjs-playground.com/#1UHFAP#198

Yeeeah.  There we go.  The world-famous 8-vert box, likely the BEST cargo-carrying container-shape EVER!

Just try making a pyramid (-scheme) with spheres.  Things just don't stack up!  heh.

All in all, I wonder if PhilT can use 8v, and if he sees some perf changes.  Perhaps, impostors is impostors, no matter which shape is attached.  *shrug*

[PhilT]

Thanks @Wingnut. So do you mean 8v for the box impostor or the box itself? I'm not even sure what the box impostor is (apart from being a box)! I need to confirm but from previous checks most of time is spent in the physics engine. But I did try a worker build of Babylon and couldn't see any noticeable gains.

Still working on the demo for my blog so will post when I'm done.

I'll probably also create my own worker setup so I'll  try all 3 engines as workers to compare. Seeing fps, avg, min, max is quite interesting. 

[Wingnut]

8v for the mesh/boxes themselves.  Essentially steal the box from #198 playground, and see if you can clone/instance it silly.

The impostors... they aren't a render-able thing... essentially like a boundingBox or boundingSphere (or combined = capsule).  Just magical math stuff... that sort of take control of the real mesh. Once a mesh has "signed aboard the forcing system"... it just takes orders, gets ordered-around with force, and fulfills orders, with potential colliding and recoiling along the way.

The actual mesh becomes exactly like a fast-food restaurant employee.    (oh man, bashing servitude THIS early in the morning?)  heh

But yeah, if a wall-o-boxes (bricks?/blocks?) is the final objective (simple shapes)... then why not try to reduce the vertices count by 66%... see what happens?

I think the impostors will be exactly the same, because a boxImpostor will be used in either case.  But you SHOULD gain some speed (and reduce memory usage) in other areas.

Worth a try if you get bored someday. 

Keep in mind... that with only 8 verts/normals and 12 indices... you cannot attain color-per-side or texture-per-side.  The best you can do is a single material color/texture... or color-per-vertex.  In the #198 playground, I was using hemi-light diffuse/ground colors to color the box.  In this #200 playground... I have activated color-per-vertex coloring.  It's kind of pretty... but a wall full of them... might look a little too "hippy". 

Still, vertexColors allow you to make the boxes ANY color... without using a material on them.  That might help keep your speeds up, too.  *shrug*

[PhilT]

Ah of course! So obvious when you spell it out!!

Same color is fine but if that means the lighting on individual sides then that could be a problem. Worth trying out though as you say. Hippy may just work!

I've managed to integrate Cannon, Oimo and Ammo into the demo. Ammo is comparable. It might even have the edge over Oimo.

I will get this posted on my blog this week.

However, the next thing is to have a switch for using web workers. Then maybe 8v meshes. And then make the stats sticky for side-by-side comparisons

[PhilT]

So I just tried web workers with Ammo.js and I'm not seeing any real improvement. Have others seen similar or should I keep digging?

[Pryme8]

If you set things up correctly fps should not be and issue me and @dbawel had a simulation using cannon running I believe over 2k physic importers testing collisions and there was no fps drop.  I even had secondary AABB calculations running to validate the physics response.  So 20x20 should not be an issue.

[PhilT]

Ok that's good to know thanks @Pryme8. It was pretty hackily put together so I'll take another look.

Presumably you bypassed the BJS plugin for that?

 

[PhilT]

I've added Energy to my demo and I'll get it published this weekend.

[Pryme8]

yeah you just kinda do some quick maths on one of the before or after loops of the render and effect the physics directly.  But you should not have to do that... ours was very specific and had to have certain movement characteristics.
 

[PhilT]

The comparison is now live at: http://games-matter.com/assets/enginetest/.

[Wingnut]

Oh, cool idea!  Side-by-side comparisons! 

hmm.  Dead in both my IE and ESR52 firefox. 

No error in my FF... just 'Physic engine : energyJS - All is Ready'.  But no scene.  Blank canvas.  FF ESR 52 has been showing signs-of NOT reporting errors very well, though.

In my non-edge IE v11.0.9600.blahblah...

X  SCRIPT1046: Multiple definitions of a property not allowed in strict mode
File: Oimo.js, Line: 800, Column: 20

exception thrown: TypeError: Object expected,TypeError: Object expected
   at hr (http://games-matter.com/assets/enginetest/energy.js:15:54035)
   at gr (http://games-matter.com/assets/enginetest/energy.js:15:53936)
   at pr (http://games-matter.com/assets/enginetest/energy.js:15:55907)
   at Kb (http://games-matter.com/assets/enginetest/energy.js:8:5153)
   at callMain (http://games-matter.com/assets/enginetest/energy.js:22:18529)
   at doRun (http://games-matter.com/assets/enginetest/energy.js:22:19222)
   at run (http://games-matter.com/assets/enginetest/energy.js:22:19408)
   at Global code (http://games-matter.com/assets/enginetest/energy.js:22:20322)

X  SCRIPT5007: Object expected
File: energy.js, Line: 4, Column: 268

Wingnut tosses both of his primary browsers outside... into the new half-foot of snow (and still falling fast).  Maybe I can freeze-away the browser bugs.  

Perhaps time for Wingnut to DL some spring-time fresh browsers, eh?    I wonder when Spring will come.  *sigh*  (Wingnut hears his snowblower *sigh*, too)

[PhilT]

Yeah I'm using ES6 modules and forgot to transpile as Chrome supports them out of the box.

Will fix shortly.

[PhilT]

Snow?!

[PhilT]

Not sure I'm going to get to it today. The next version of Firefox will support ES6 modules.

[Wingnut]

On 4/15/2018 at 10:21 AM, PhilT said:

Snow?!

*nod*  I think it's almost done, now.  14-18 inches of new stuff... in the last 16 hours (knee deep).  Erf.  And winds... just terrible.  Pretty drifts, though.  French curves.    Currently, mail delivery would require mountaineering gear.  heh.

Snowblowing festival tomorrow.  yay!  Takes about an hour to blow my mail-person trails and back parking lot for this 4-plex.  Toro 1132... 11 horsepower, 32 inch swath... auto-shoveler.  It's my friend.  24 yrs old, starts first pull, and kicks royal butt. 

But the winds will still be here tomorrow... so... yeah... lots of snow blowing back in my face.  I wear something similar to a space-walking suit, so I don't even notice.   

Just gotta be careful not to chow-up a dog or a snow-fort-building toddler.    Remember those toddler mittens... connected to each other by a string?  Well. if you get that string wrapped around the snow auger... well... it can get ugly quick.  heh.  (morbid, eh?)   Same thing for dog-chains... you just hear a yelp, and then see red snow coming from the blower chute.  (ewww)

Myself and a video-producin' buddy once thought-of making a garden roto-tiller climb a standard ladder and crash thru a bedroom window and onto a teen girl's bed... chowing her into the mattress stuffing.  (horror flick).  We decided that the public was not quite ready for "Roto-Tiller Killer"  heh.

And boy, am I off topic. 

Let's talk about this physics comparison thing that Phil-Billy built.  Coooooool.  Gonna add a worldStep slider?  You know... scene.getPhysicsEngine().setTimeStep(sliderValue);

I wonder how worldStep values affect FPS.  hmm.

Snow for sale!!!  By the ton, only.  Cheap!  Free Shipping!!  Inquire within. 

[Pryme8]

Cool comparison demo!

[Guest]

Really cool!

[PhilT]

Haha!! Thanks for that @Wingnut. Or should I say Wingnutter?!

Took a couple of reads to understand what the hell you were talking about (and when you were going to get to the point  ).

Yeah, the snow... I'll take the lot. How long's shipping to the UK?! 

World step slider is a good idea. I'll still learning this stuff. From what I tried before it seemed to just slow things down but I guess I was doin' it wrong! @Samuel Girardin posted an updated collapsing wall PG which is much slicker than my effort. It has some world step stuff in there so will check that and what options ammo and the others have.

Laters.