Mesh facet data

[jerome]

This post is the gathering of old posts getting far from their original topic to a new one :

The ability to have some facet data for any mesh, like facet normal data, facet position data, facet area data, etc, etc

For now, it's still a prototype.

Here you have the facet normal and position data used. More over a (naive and simple) internal octree is built by giving its number of subdivisions per axis (because the octree can't know the mesh geometry a priori) at the line 230. I added at the line 234 a simple octree visualizer (no plane on Z else it's hardly visible)

http://www.babylonjs-playground.com/#2KXNQ6

When the little red ball enter one the mesh octree block, a green box is set on the closest facet to the ball in the same block.

It should work with any mesh now (I hope). The code is commented... because I get some holidays and will probably forget everything before I take it back.

Some tests : icosphere = http://www.babylonjs-playground.com/#2KXNQ6#1

different octree (10 sub on x, 2 on other axis) = http://www.babylonjs-playground.com/#2KXNQ6#2

torus knot with a 10 x10 x 10 octree = http://www.babylonjs-playground.com/#2KXNQ6#3

 

actually, the octree size should be chosen in order that no mesh will be bigger than an octree block... else it's not efficient. So set it to have some or many facets inside each block.

more visible = http://www.babylonjs-playground.com/#2KXNQ6#4

There's no use of any ray here.

I intend (next year, now) to make a demo of custom collisions (physics) of plenty of solid particles bouncing against any kind of shape... even against dynamically morphed ones, at 60 fps if possible.

[EDIT] Ribbon test = http://www.babylonjs-playground.com/#2KXNQ6#5

Old related posts :

 

 

[JohnK]

@jerome still playing with with it. Now have added working with individual faces - getFaceData,  tidied up the setFacetColor and added setFaceColor (as you said needs a flat shaded mesh). Also for consistency have changed your nbFaces in getFacetData to nbFacets. Hope my uses of faces as well as facets do not confuse too many people.

http://www.babylonjs-playground.com/#1CRS0Z#3

[jerome]

really nice :-)

 

[adam]

Why is it that you can only color 4 facets?

[JohnK]

4 was just a test you can do from 1 to all

[adam]

Thanks John.  I wasn't setting the colors correctly when testing.

[jerome]

I think you can even set one color in the middle of the array

say, you've got 3000 facets, just create a new Array(3000), called,  say, colors

and set only the i-th element : colors[1500].r = 0.0

this should work, I think ...

 

About getFacetData(), I think that I will refactor it directly in ComputeNormals(). Indeed, getFacetData() shares 98% of its code with ComputeNormals()

So I think, instead of ComputeNormals(positions, indices, normals), we could then now have ComputeNormals(positions, indices, normals, { options})

where options could be :

facetNormals (array) 

facetPositions (array)

facetAreas (array)

facetColors (array) maybe

all optionals and computed then returned, if passed to ComputeNormals()

This would be very fast and a single iteration on all the indices/positions array

[JohnK]

From my point of view I was just playing with facet and face colors and don't expect many people will be interested so happy for them not to be included. 

[jerome]

Let's go :

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

A sphere flies and collides a mesh. When it hits the mesh, it slides on its surface as long it detects a new facet in its current direction.

There's no ray here and no knowledge of the mesh geometry etiher... so it should work with any mesh : http://www.babylonjs-playground.com/#1SZHS3#1

I let you discover the scene code what is quite simple.

I'll provide some other examples soon to check if it fits, as I expect, any mesh shape, even dynamically morphed ones and if it can be stressed to support a great number of collisions per frame.

note : for now, it only works in the local space, so don't rotate, scale or move the mesh

[EDIT] cylinder : http://www.babylonjs-playground.com/#1SZHS3#2

Torus knot : http://www.babylonjs-playground.com/#1SZHS3#3  (funny)

still a bug with the box : http://www.babylonjs-playground.com/#1SZHS3#4 and tetrahedron : http://www.babylonjs-playground.com/#1SZHS3#5 (related to some wrong size octree size, I suppose)

but works better with more facets : http://www.babylonjs-playground.com/#1SZHS3#6

http://www.babylonjs-playground.com/#1SZHS3#7

http://www.babylonjs-playground.com/#1SZHS3#8

the same with an octree 10 x 10 x 10 instead of 4 x 4 x 4 is more performant : http://www.babylonjs-playground.com/#1SZHS3#9

note that the behavior (this one : ball flying, etc, independant from the mesh/octree) could be different with the automtatic octree computation (27 blocs per axis here) : http://www.babylonjs-playground.com/#1SZHS3#10  ... the ball exits quickly the surface, because less facets per block

 

If the mesh has enough facets (dozens or hundreds or more) the automatic octree computation seems to be good enough : http://www.babylonjs-playground.com/#1SZHS3#11

although, when the mesh becomes bigger (in terms of facets) the automatic computation is not that good : http://www.babylonjs-playground.com/#1SZHS3#12

setting manual values (l 49) is then better : http://www.babylonjs-playground.com/#1SZHS3#13

The torus knot is a good example of a difficult mesh to manage because it has external facets inside its internal concave global shape, not only around an external surface like a sphere, a regular polyhedron, etc. The automatic octree computation assumes that the mesh is concave and could be homogeneously projected on its bouding box... so in average the same number of facets on each of the 6 box sides.  This rule won't work for more complex meshes like the torus knot, so a manual setting will be better.

Next challenge to meet : collide a random spherical harmonics 

[jerome]

Spherical Harmonics facet data self challenge : http://www.babylonjs-playground.com/#1AD81E

plain : http://www.babylonjs-playground.com/#1AD81E#1

runs at 60 fps in Chrome here

[Wingnut]

You're a MADMAN, Jerome!!!  Phenomenal stuff!  Wow!  What a great xmas gift you have given us!  The snow globe project has a definite good chance for success... with snow sliding along slanted roofs and slanted tree limbs.  Yum!

Do you foresee .faceNormal being added to PickingInfo?  (a sister to faceId)

[jerome]

For now, this just a prototype, some work in progress ...

I need to provide many PG examples at first to let people play with it and try to find the weaknesses. I need also to stress the model : I intend to make many solid particles collide a morphing ribbon to check how it behaves, especially in terms of performances and to compare this with the same that would be designed with ray collisions.

Then, I need to refactor this prototype : better var names and probably to embedded it in the function ComputeNormals() so the facetData, the internal mesh octree and the normals would be computed in the same lone iteration over all the mesh vertices, what would be faster (currently there are two : one for normals when the mesh is morphed, and quite exactly the same for the facet data). I also need to ask the experts for a better or smarter octree implementation.

Then only... everything will be possible to inject it in the BJS core (what is actually not a big addition in term of LOC) and to make it interact with any other current parts like pickingInfo

 

[EDIT] different original velocity vector and different octree : http://www.babylonjs-playground.com/#1AD81E#2

I suppose that a fair bounce instead of a slide-and-continue behavior would be more pertinent to understand how the collision is detected

 

[EDIT 2] a SH is not a good candidate to show the facet collision detection, because it's a complex shape, with some concave and some convex parts, with some inverted facets, some quite reduced to zero while others are very big, etc... this demo as just to test the facetData against a complex morphing mesh

[jerome]

The same with a fair bounce on collision instead of slide & quit : http://www.babylonjs-playground.com/#1AD81E#4

[jerome]

little improvement (octree size bigger than the mesh bounding box for 10%) : http://www.babylonjs-playground.com/#1AD81E#5

[gryff]

@jerome : I've said it before, and I'll say it again, your PGs are fascinating (almost hypnotic) to me. One day, hopefully soon, I have to spend time with the SPS system and see if this wimpy coder can understand it

@Wingnut : That snow globe thought takes me back to my first or second Christmas using VRML. Some guys at Sun (I think?) built one. A Christmas tree inside the globe with a model train going around it.  

cheers, gryff

[jerome]

many thanks @gryff 

[jerome]

Hi, in this new year ...

here's (still prototype) a complete refactor of my facet data project : http://www.babylonjs-playground.com/#1AD81E#6

What's different ?

Now, the mesh has new properties : an array facetNormals and an array facetPositions (no longer facetData objects), both containing Vector3. Why two arrays instead of facetData objects ? because now, the facet positions and normals (and the internal octree that I won't speak about for now) are all computed in the same call than the one for the mesh normals, also known as the famous VertexData.ComputeNormals()

A new version of this method is coded under the the code of createScene() at the line 279.

This means only one single loop to update the normals and all the mesh facet data even when the mesh is dynamically morphed.

And more simple methods for the final user. As you can see from the line 145, the function registerBeforeRender() is quite easy now to understand.

I hope I can make you a decent PG soon with some stress on this prototype to check if it behaves like I hope. My challenge : to throw thousands of solid particles on a dynamically morphed moving ribbon and to make them bounce against it at 60 fps.

[jerome]

it looks like I had a bug in the bounce computation, better here : http://www.babylonjs-playground.com/#1AD81E#7

(not easy to check with such strange shapes as SH)

[jerome]

Tadaaannnnnnn

http://www.babylonjs-playground.com/#CNMNR

well, the physics are my own and not that complex (still a little buggy if the mesh is translated or if a ball keeps in the bottom of the convex shape when immobile)... anyway, the goal is just to show a real case of use of facet data : facet normals, positions and mesh internal octree. By the way the octree has been refactored, optimized and simplified.

In this example, you've got 500 solid particles (spheres) falling and collinding a mesh (a ribbon). There's no impostor, the mesh can have any wanted shape and the balls don't know anything about the mesh geometry.

Stress test : same example with 2000 balls, still running at 60 fps in Chrome here when executed out off the playground http://jerome.bousquie.fr/BJS/test/facetdata2.html

[jerome]

This seems to work also with dynamically updated meshes : http://www.babylonjs-playground.com/#1UAOG0#2

more visible : http://www.babylonjs-playground.com/#1UAOG0#3

[jerome]

ultra stress test : http://www.babylonjs-playground.com/#1UAOG0#1

this one runs at 60 fps with 10000 tetrahedrons on my desktop in chrome, outside the PG.... don't click if your PC is weak CPU wise

[GameMonetize]

This is REALLY COOL. PR?

[jerome]

still need plenty of tests, tweakings, etc, etc

 

actually the facet normals and positions are already OK and can be embedded in the function ComputeNormals() at no cost (10 more lines only)

I still need to tweak the octree part

For now, we could do VertexData.ComputeNormals(positions, indices, normals, {facetPositions: array1, facetNormals: array2})

if passed (optional) array1 and arrray2 are populated with the facet normals and positions within the same loop than the mesh normal computation

[jerome]

skull.

skull ..?

skull !

ok : http://www.babylonjs-playground.com/#1WOE6G#4

 

1 skull, 1000 spheres, 2 draw calls, no impostor, no awareness of the mesh geometry

 

tetrahedrons ?

ok http://www.babylonjs-playground.com/#1WOE6G#8

 

(beat this, threejs ! )

[jerome]

I hope that we finally have a way to compute accurate intersections now