Sign in to follow this  
JohnK

Containing Bubbles - Now with Added Concave Collisions

Recommended Posts

Just having a play around with sps, wanted to see if I could come up with a simple collision system from scratch. Only designed to work with spheres.

http://www.babylonjs-playground.com/#1C2HFL

http://www.babylonjs-playground.com/#1C2HFL#1

less segments http://www.babylonjs-playground.com/#1C2HFL#2

Have a play around with number of particles, size of particles and max speed. Max speed should be less than radius, too big and the particles escape.

Share this post


Link to post
Share on other sites

Really nice, but don't forget also that the SPS already implements the particle intersections if needed ;)http://doc.babylonjs.com/overviews/Solid_Particle_System#particle-intersections

Maybe, for testing each particle against the other ones, the usage of a prune (or p-prune) algo would be more efficient...

Share this post


Link to post
Share on other sites

This version http://www.babylonjs-playground.com/#ZFF6I   replaces my custom check collision method with the BJS intersects mesh method for SPS.

Out of interest I compared the times in milliseconds to run 100 frames over 2000 frames for my custom method and the BJS method. The trial was carried out under as near identical conditions as possible.

The average results for 100 frames are

custom 7319.55 milliseconds                     BJS 4526.65 milliseconds

So way to go BJS coders you are the best :D

A downside of the BJS method is that it appears that particles can get trapped at the sides.

Share this post


Link to post
Share on other sites

This is really nice :)

I think some things can be improved in your code : there are many particles and each particle process does some new allocations (so the GC will work also). Maybe could you try to replace all the ".add()", ".scale()"(subtract, etc, you see the idea) with some addToRef() or addInPlace() and scaleToRef or scaleInPlace() depending on the current case ?

Share this post


Link to post
Share on other sites
33 minutes ago, jerome said:

This is reall nice :)

I think some things can be improved in your code : there are many particles and each particle process does some new allocations (so the GC will work also). Maybe could you try to replace all the ".add()", ".scale()"(subtract, etc, you see the idea) with some addToRef() or addInPlace() and scaleToRef or scaleInPlace() depending on the current case ?

Wondered why you used addToRef in your facetData code, now I know. Probably wont be until next week but will look at use of variables and trial for new speeds.

Only took me 5 mins to work out GC is garbage collection, I'm improving.

Share this post


Link to post
Share on other sites

sorry, I should be more didactic :-)

Well, it's a good thing to remember that :

Javascript is monothreaded and the variable scope is the function in what it is created.

So if some variables are created each call to a function, they have to be cleared by the garbage collector once this function is over. And the garbage collector will use the same global javascript process than your code, so some precious CPU cycles that you would prefer to keep for yourself.

Thus, in general, we try to avoid to create new objects (vector3, arrays, etc) in the render loop, what is in BJS  a call to the function registred with registerBeforeRender() every 16 ms (60 fps) to keep the allocated memory as constant as possible, so to keep the GC far away our little business :D

Share this post


Link to post
Share on other sites

@jerome thanks for the tips about GC. Changing my code as you suggested I produced two new trials one using my custom method and one using BJS to check when a bounce might be needed.

The average results for 100 frames are now

custom 4572.1 milliseconds                     BJS 4424.25 milliseconds

much closer.

new playground for custom method http://www.babylonjs-playground.com/#205HSN#1

Share this post


Link to post
Share on other sites

WARNING  with  spheresPerShapeNb = 10 the browser page has completely locked after a shot time, when, where and why I do not yet know. So far, for numbers used in this PG, no locking has yet occurred but it may happen.

For those who do not want to read further here is a PG of bouncing concave shapes http://www.babylonjs-playground.com/#WLYB9

TL;DR

Previously I had tried to use facetData to collide moving concave meshes. Having got as far as finding the intersection point of two complex meshes this way

my attempts at colliding them on the move failed, movement was too slow as they approached each other and while on a very few occasions they would collide and bounce on the vast majority they passed through each other. So I tried a different tack and returned to SPS.

In the PGs complex shapes are formed by grouping together particles (spheres) and, using the same method as earlier posts in this topic, bounce two shapes if any one particle in one shape intersects with any one particle in the other. Rotation of the shape is achieved by finding the centre of mass of each shape and rotating the shape about this. This method does not rotate each particle giving a weird but fun result when replacing spheres with boxes. (Note in the collision as before it is the sphere within the box that is used in calculations.)

PG with boxes http://www.babylonjs-playground.com/#WLYB9#1

Adding in extra code to rotate each box PG http://www.babylonjs-playground.com/#WLYB9#2

 

Share this post


Link to post
Share on other sites

Along way from perfect but this forms shapes from given numbers of SPS particles and tries to take into account that because of rotation speed two particles may have collided between frames but when checked are not intersecting in either of the frames. Still a work in progress.  Which do you think looks better  (1) or (2) ?

(1)  http://www.babylonjs-playground.com/#XW6HA#1

(2) http://www.babylonjs-playground.com/#XW6HA#3

How about (3) and (4)

(3) http://www.babylonjs-playground.com/#XW6HA#4 checks for potential collisions before they could happen and adjusts velocity

(4) http://www.babylonjs-playground.com/#XW6HA#5 checks for potential collisions after they could have happened and adjusts velocity

 

 

Share this post


Link to post
Share on other sites

Have now gone back to the drawing board and did some more exploring about when and when not meshes collide. If meshes are moving 'too fast' then they can never intersect during a frame. Even if a number of particles start out slowly it is possible that collisions between them can increase the speed of some particles while slowing others.

This PG shows one particle moving at 8 times its original speed after colliding with others http://www.babylonjs-playground.com/#1DJ7RH#3

My musings on this can be found at http://babylonjsguide.github.io/gamelets.html under the collisions section. This is still under development and slowly I will get back to complex shapes only this time with more consideration.

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
Sign in to follow this  

  • Recently Browsing   0 members

    No registered users viewing this page.